You can program functional in almost any language. Its more a mindset. I can not emphasize this enough, keep it simple.
I think what you mean by "functional" and what the author means by "functional" are distinct. Are you aware of the distinction?
Why Functional Programming Matters (1984) [pdf]
121–130 of 145 posts
Re: Why Functional Programming Matters (1984) [pdf]
#122The top link on /r/haskell right now [1] is someone complaining that their program runs out of space due to a subtle interaction between laziness and IO. I think it's safe to say that we have tried laziness as the default and have learned that it's the wrong default, because it plays havoc with space and with IO. [1] https://www.reddit.com/r/haskell/comments/5h6emf/haskell_run...
I'm not sure why we keep pretending Haskell is supposed to work well. It's half prorgramming environment, half research environment. This shows in MANY ways. And don't get me wrong, the Haskell team tries, but ... There really isn't a serious attempt to build an industry-friendly programming language with functional features and laziness as a default. You'd make many different decisions than Haskell: - No more langua…
I believe PureScript solves most of these problems.
Re: Why Functional Programming Matters (1984) [pdf]
#123Earlier quoted context omitted.
The key insight is that immutability is not an end in itself, it's a tool to give us referential transparency. How about a programming environment tailored for small simulations or games? I could imagine such an environment maintaining referential transparency without strict immutability. Rather, such a system could provide a kind of "poor-man's" immutability by only allowing pure functions that take state from tick…
Are you familiar with Urbit [0]? [0] urbit.org
Is anyone?
Re: Why Functional Programming Matters (1984) [pdf]
#124Earlier quoted context omitted.
I'm not sure why we keep pretending Haskell is supposed to work well. It's half prorgramming environment, half research environment. This shows in MANY ways. And don't get me wrong, the Haskell team tries, but ... There really isn't a serious attempt to build an industry-friendly programming language with functional features and laziness as a default. You'd make many different decisions than Haskell: - No more langua…
I believe PureScript solves most of these problems.
Thanks! After your comment I finally got around to checking out PureScript, and it looks nice (aside from the crazy tooling requirements which are typical for 2016).
Re: Why Functional Programming Matters (1984) [pdf]
#125Earlier quoted context omitted.
It seems to me that part of the problem he was having is that he didn't really understand how these methods were being implemented internally. I know that all languages inevitably have these problems but how do the amount of leaky abstractions compare in Haskell to other languages?
I don't think Haskell is worse than any other language in that regard. What perhaps sets it apart is how much of its functionality is implemented in third-party libraries, which may be difficult for a beginner to come to grips with. "Why should I download a library to use efficient arrays? Shouldn't they be built in, like in Python?" I can come up with two explanations for this reliance on third-party libraries. 1) H…
>"Why should I download a library to use efficient arrays? Shouldn't they be built in, like in Python?"
Python does in fact use a third-party library for efficient arrays (Numpy) and its use is so widespread as to be a defacto language unto itself.
Re: Why Functional Programming Matters (1984) [pdf]
#126Earlier quoted context omitted.
A kernel spends most of it's time managing mutable state. Here's a table of processes. We want it to be an array, rather than a linked list, for efficiency reasons. When a new process is created, we don't want to copy the array, also for efficiency reasons. So we mutate the array. > So does every computer programmer though. Not really.
> Here's a table of processes. We want it to be an array, rather than a linked list, for efficiency reasons. At least in Linux, the table of processes is implemented as a (doubly) linked list.
TIL.
Re: Why Functional Programming Matters (1984) [pdf]
#127Earlier quoted context omitted.
I don't believe many are advocating functional programming as a replacement for hand-crafted C, but it is a good alterative to imperative high-level languages which often make big performance sacrifices but offer only small improvements in reliability and abstraction/composition. I absolutely believe the correct way to build software is with language layers. Ideally using FP or declarative languages where you can. Py…
Why not? Lisp did it before C was even born.
How many device drivers have ever been written in Lisp?
I'm not necessarily advocating C as the best way to write high performance, non-allocating code either.
Re: Why Functional Programming Matters (1984) [pdf]
#128Re: Why Functional Programming Matters (1984) [pdf]
#129Earlier quoted context omitted.
Why not? Lisp did it before C was even born.
How many device drivers have ever been written in Lisp? I'm not necessarily advocating C as the best way to write high performance, non-allocating code either.
Why, all of them, in a Lisp machine.
Probably zero of them, in any non-Lisp machine.
Lisp is a fairly nuts-and-bolts language suitable for device drivers, depending on what you include in it. The
The basic Lisp evaluation model is close to machine language: Lisp values readily map to words (32 bit, 64 bit, whatever) stored in registers, and pushed onto a conventional stack during function calling.
Lisp compilers can optimize away environments: they can tell when some local variables or function parameters are not being captured by a closure and can live on the stack.
Lisp can compile to re-entrant machine code.
Dynamic memory allocation in contexts such as interrupt time is not off the table. In the Linux kernel, ISR's can call kmalloc; they just have to pass the GFP_ATOMIC flag. Similarly, a Lisp interrupt service routine can still cons up cells or other objects, probably in a limited way that can't trigger a full GC, or block for a page fault.
Parts of such as system can be written in a Lisp notation for a non-Lisp language. Such as, for instance, a "Lispified" assembly language. Thus the saving of registers on entry into an interrupt can still be notated in Lisp; it's just not the normal Lisp, but some S-expressions denoting architecture-specific machine instructions (register to memory, and register to register moves and such). When the system is built, an assembler written in Lisp converts that to the executable code.
Re: Why Functional Programming Matters (1984) [pdf]
#130Earlier quoted context omitted.
I don't think Haskell is worse than any other language in that regard. What perhaps sets it apart is how much of its functionality is implemented in third-party libraries, which may be difficult for a beginner to come to grips with. "Why should I download a library to use efficient arrays? Shouldn't they be built in, like in Python?" I can come up with two explanations for this reliance on third-party libraries. 1) H…
> > how do the amount of leaky abstractions compare in Haskell to other languages? > I don't think Haskell is worse than any other language in that regard. Many Haskellers are happy about this kind of stuff: min = head . sort which is the very definition of a leaky abstraction. The blame lies with laziness, because it allows code to depend on implementation details of other code in crazy ways: "sort is O(n log n) unl…
I wouldn't depend on invocations of sort to be anything but the worst case.