131–140 of 145 posts
Earlier quoted context omitted.
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.
Ever heard of Interlisp-D, Lisp Machines?
On a current typical OS (Windows, Android, iOS, macOS, Linux, ...) the chance of ever seeing a Lisp-based device driver in action is near zero.
Earlier quoted context omitted.
Ever heard of Interlisp-D, Lisp Machines?
The problem: this was long ago on an OS written largely in Lisp. On a current typical OS (Windows, Android, iOS, macOS, Linux, ...) the chance of ever seeing a Lisp-based device driver in action is near zero.
Earlier quoted context omitted.
> Functional programming is great because it provides two (new) kinds of glue: function composition and lazy evaluation. Certainly true for composition but laziness is more the exception than the rule in today's FP languages. And it's getting an increasingly bad reputation to the point that even Haskell is slowly (and reluctantly) being dragged in the strict direction (which it will never fully reach because so much…
There's one spot where I like laziness, and that's where it supports composition. I'm gonna hop over to C# because that's where my favorite example lives: LINQ is a functional library that lets you describe queries on data that are executed lazily. The reason why the laziness is great in this scenario is that it lets you separate the tasks of constructing a data processing pipeline, and executing it. The spot where i…
"Why Functional Programming Matters" solved with C#
http://www.oki-osk.jp/esc/cs/whyfp.html
http://www.oki-osk.jp/esc/cs/whyfp2.html
http://www.oki-osk.jp/esc/cs/whyfp3.htmlEarlier quoted context omitted.
Functional programming largely has two schools: Treat "commands" as a separate entity from expressions, and bake "commands" into expressions. The former is largely Haskell, Clean, ... and the latter is exemplified by e.g., Standard ML or OCaml. There are trade-offs between the two, but I definitely belong to the second school: we simply add an imperative subset to our functional language. This means we can exploit an…
The key insight is that immutability is not an end in itself, it's a tool to give us referential transparency. If a language can allow mutability in an area of code without allowing side effects to escape from it we can have all of the reasoning advantage that FP gives us at a level above the mutations. We can also have the performance we want.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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.
Ever heard of Interlisp-D, Lisp Machines?
Earlier quoted context omitted.
The problem: this was long ago on an OS written largely in Lisp. On a current typical OS (Windows, Android, iOS, macOS, Linux, ...) the chance of ever seeing a Lisp-based device driver in action is near zero.
It isn't because those ideas failed to get mass adoption that we should ignore them.
Earlier quoted context omitted.
Ever heard of Interlisp-D, Lisp Machines?
Yes I have. But my context was modern mainstream hardware. We won't convince anyone on the merits of functional programming by pointing out the existence these old machines. My argument was "have your cake and eat it too", use FP and low-level languages together.
To prove a point one is forced to create a system just to prove the others wrong, without any ROI.
Earlier quoted context omitted.
Yes I have. But my context was modern mainstream hardware. We won't convince anyone on the merits of functional programming by pointing out the existence these old machines. My argument was "have your cake and eat it too", use FP and low-level languages together.
The problem is that like Alan Kay states, the industry has become pop culture, and very few believe what can be achieved, rather take what they can see today. To prove a point one is forced to create a system just to prove the others wrong, without any ROI.
A lot of pleas for functional programming give a long list of convincing examples that work well with functional programming. You can do this with almost any language, and this is also quite deceptional, as this is often done to convince beginners to learn another language; "look at how simple it is to program this contrived example in !". In order to be able to use a programming language or paradigm well, it is espe…
> Functional programming does not work well in (cont..) You state earlier that programmers can and perhaps should write functional style (AFA feasible) in the languages that do excel at above problems. So you probably meant that "functional languages" ---rather than "functional programming"--- "does not work well" there. > (..cont) programs which handle a lot of states. It does not work well in programs which have hi…