Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To understand how and why a C compiler works you don't need all that much algebra. If you thoroughly understand assembly, you're basically good to go.

To understand how and why an FP language compiler works you need to grok the lambda calculus (as a bare minimum). I'd call that algebra. To even understand what problems are being solved by closures, I really had to “learn difficult concepts through prolonged mental concentration and effort”. Giving newbies a heads-up that competent use of such a tool requires nontrivial knowledge is only fair.



eh, i dunno. i think anybody with a decent grip on any language can whip up a scheme compiler way faster than a C compiler. [1] is a very readable guide to scheme and its implementation. Will it be the fastest gun in the west? no. Is it a simple workable foundation that, like, anybody who can put together 100 lines of working code, in any language, can build? for sure. Compilation isn't magic.

Lambda calculus won't hurt. Implementing scheme (which imho is pretty darn close to the lambda calculus) really just requires understanding some operational semantics and you're good to go.

[1] (http://agl.cs.unm.edu/~williams/cs491/three-imp.pdf)


Quite. But pretty darn close is still not close enough to support partial application via curried functions out of the box.


Absolutely.

I'd argue, if somebody has written their own interpreter and compiler, leveraging the interpreter at compile time first for constant expression evaluation and then something more sophisticated for partial function evaluation is a lot more intuitive. You can kinda climb a hill of difficulty rather than be teleported to the top and wish them luck.

(To be totally fair i keep trying to open the pdf, but the browser tab locks up. So maybe my observations are meaningless)

_edit_

There is no royal road. but some roads are perhaps longer, but a little easer to travel.


typed pure functional programming is not "functional programming" in the scheme sense.

It's often approached much more formally, using the terms and methods of category theory -- and that is very much the approach of this book.


Is it really that complicated?

A closure is essentially a function pointer with some additional data about what some of the symbols refer to. It happens that you're able to write the function nested inside another function.


In advanced FP languages with sophisticated type systems, etc, there's a little more to it than that.


Why do I need to understand how the compiler works, at that level of detail?

I don't see why understanding closures requires so much mental effort. Just using them a few times should give you a practical understanding of how they work. Closures are not a complicated concept - a bunch data your function has access to outside of its own scope.


They're certainly no harder a concept than pointers in C! They also don't cause crashes that can be very difficult to debug.


> Why do I need to understand how the compiler works

How do you propose to master the language if you don't understand the principal tool that embodies that language? Of course it's always an option to use a language without really understanding it, if that's your thing.

> Closures are not a complicated concept

The first lectures introducing closures after their discovery had CS professors in the audience who didn't understand what they were good for. Functions could access a bunch of data outside their local scope before that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: