5 ms·

> A random old-time Lisp hacker's collection of macros will add up to an undocumented, unportable, bug-ridden implementation of 80% of Haskell because Lisp is m

by jasim 9y ago

> A random old-time Lisp hacker's collection of macros will add up to an undocumented, unportable, bug-ridden implementation of 80% of Haskell because Lisp is more powerful than Haskell. How so? Can we program Haskell's Hindley-Milner based type checking into Lisp with macros and homoiconicity, and have it run during compile-time? I've been dabbling in OCaml and ReasonML recently, and am enjoying pure functional programming a lot. But I never could get into untyped FP like the very practical Clojure before because they didn't seem to offer me too much compared to Ruby and Javascript. Functions in ES6 are more first-class than Ruby's lambdas. The single-line function definition is very concise and you can also do your programming with immutable values if you are careful about references and use something like the immutable-helper. Granted you don't get persistent data structures, but then you have ImmutableJS now. ES6 implementations also have TCO, so a recursion-based programming model should be fine as well. In that context, the differentiating power of Lisp seems to be around macros - a very powerful way to write programs that write programs. I have done my fair share of meta-programming with Ruby and I realized I really didn't want the power to change my program model at runtime. While they made certain things easier - like Rails's ActiveRecord (which is superb btw) - the "inception"-like indirection made things very hard to reason about. For me the secret-weapon language is less about power, and more about structure. We can build equivalent things with any turing-complete programming language, but the test is when the system has to grow, and that is precisely when most codebases fail. So far, statically typed FP with Sum Types and Pattern Matching and Immutability seems to be the cure, and macros and dynamic typing its very antithesis.

Guthur 9y ago
Your final statement is demonstrably incorrect. The world is full of large software projects not using statically typed FP and actually surprisingly little from the likes of haskell beyond self serving academic noodling.
- codygman 9y ago
  > surprisingly little from the likes of haskell beyond self serving academic noodling Your final statement is demonstrably incorrect. Facebook (haxl), Microsoft (Bond), Google (ganeti), Target for supply chain automation, Bank of America (Haskell is being used for backend data transformation and loading), standard chartered, Prezi, Android bump (http://devblog.bu.mp/post/40786229350/haskell-at-bump http://devblog.bu.mp/post/40786229350/haskell-at-bump), At&t (automate processing of internet abuse complaints).
  - pron 9y ago
    > Your final statement is demonstrably incorrect. The final statement the parent responded to was, "so far, statically typed FP with Sum Types and Pattern Matching and Immutability seems to be the cure." That Haskell can be used to write real software, and that it is, in fact, used by a few projects in the real world, is no demonstration of it being a cure to anything any more than Go's use in far more project is a demonstration of it being an even better cure. That those Haskell projects don't seem to do significantly better than others, does, however, seem to demonstrate that it is not a cure. As I read it, the "self serving academic noodling", while too harsh an assertion (as some real-world Haskell users do enjoy working with it), does not refer to Haskell being useless, but to Haskell not seeming to substantiate the strong claims made by some of its fans; at least not in any striking, self-evident way. Haskell is a fine programming language, but touting it as the cure to our problems is a bit premature.
pron 9y ago
> So far, statically typed FP with Sum Types and Pattern Matching and Immutability seems to be the cure If by "seems to be" you mean "claimed but yet to be demonstrated by the style's avid fans". Beyond some compilers -- for which those languages were specially designed and are particularly suited -- there are precious few large, long-maintained software written in such languages, and the few projects out there don't seem to be doing significantly better than the rest. I'm not saying it's not a fine style, but so far it doesn't seem to be a cure, let alone the cure, to anything.
wtetzner 9y ago
> How so? Can we program Haskell's Hindley-Milner based type checking into Lisp with macros and homoiconicity, and have it run during compile-time? I don't see why not. Typed Racket does more or less that (it's not Hindley-Milner, but that's because they wanted a type system that matched Scheme idioms better): https://docs.racket-lang.org/ts-guide/ https://docs.racket-lang.org/ts-guide/ > I have done my fair share of meta-programming with Ruby and I realized I really didn't want the power to change my program model at runtime. While they made certain things easier - like Rails's ActiveRecord (which is superb btw) - the "inception"-like indirection made things very hard to reason about. Lisp macros run only at compile time. You can just ask the REPL (or your editor) to expand a particular macro invocation for you to see what code is generated. Of course, macros are still typically harder to debug than functions, but sometimes macros are the only way to abstract a certain pattern. That's why Template Haskell, CamlP4, OCaml extension points, etc. exist. > So far, statically typed FP with Sum Types and Pattern Matching and Immutability seems to be the cure, and macros and dynamic typing its very antithesis. I would argue that macros complement statically typed functional programming. Again, there's a reason for Template Haskell, CamlP4, OCaml extension points, etc. > For me the secret-weapon language is less about power, and more about structure. Yeah, this is where OCaml's module system shines.
soegaard 9y ago
How so? Can we program Haskell's Hindley-Milner based type checking into Lisp with macros and homoiconicity, and have it run during compile-time? Take a look at Hackett "a fanciful sketch of a programming language from a far-off land with Haskell’s type system and Racket’s macros." https://lexi-lambda.github.io/blog/2017/05/27/realizing-hackett-a-metaprogrammable-haskell/ https://lexi-lambda.github.io/blog/2017/05/27/realizing-hack...
flavio81 9y ago
> How so? Can we program Haskell's Hindley-Milner based type checking into Lisp with macros and homoiconicity, and have it run during compile-time? Not all of us want static type-checking. Some of us do want dynamic typing.
flavio81 9y ago
> In that context, the differentiating power of Lisp seems to be around macros - a very powerful way to write programs that write programs. I have done my fair share of meta-programming with Ruby and I realized I really didn't want the power to change my program model at runtime. While they made certain things easier - like Rails's ActiveRecord (which is superb btw) - the "inception"-like indirection made things very hard to reason about. The difference between metaprogramming in Lisp (lisp macros) and metaprogramming in a language like Ruby, is that writing macros in Lisp is really, really easy. It is simply not much harder than writing a normal function. Thus, while in other languages, doing metaprogramming is a special affair, in Lisp it is a piece of cake, and nothing special at all. Lisp also allows you to "expand" the macro to see what the macro would do when called. This is also very easy to do. So, i do agree with your point, however let me rephrase it: One of the most important differentiators for Lisp is really easy-to-write metaprogramming.
- jasim 9y ago
  I'm now curious to give macros a try. Thanks.

by jasim 9y ago

Guthur 9y ago

Your final statement is demonstrably incorrect. The world is full of large software projects not using statically typed FP and actually surprisingly little from the likes of haskell beyond self serving academic noodling.

codygman 9y ago
> surprisingly little from the likes of haskell beyond self serving academic noodling Your final statement is demonstrably incorrect. Facebook (haxl), Microsoft (Bond), Google (ganeti), Target for supply chain automation, Bank of America (Haskell is being used for backend data transformation and loading), standard chartered, Prezi, Android bump (http://devblog.bu.mp/post/40786229350/haskell-at-bump http://devblog.bu.mp/post/40786229350/haskell-at-bump), At&t (automate processing of internet abuse complaints).
- pron 9y ago
  > Your final statement is demonstrably incorrect. The final statement the parent responded to was, "so far, statically typed FP with Sum Types and Pattern Matching and Immutability seems to be the cure." That Haskell can be used to write real software, and that it is, in fact, used by a few projects in the real world, is no demonstration of it being a cure to anything any more than Go's use in far more project is a demonstration of it being an even better cure. That those Haskell projects don't seem to do significantly better than others, does, however, seem to demonstrate that it is not a cure. As I read it, the "self serving academic noodling", while too harsh an assertion (as some real-world Haskell users do enjoy working with it), does not refer to Haskell being useless, but to Haskell not seeming to substantiate the strong claims made by some of its fans; at least not in any striking, self-evident way. Haskell is a fine programming language, but touting it as the cure to our problems is a bit premature.

pron 9y ago

> So far, statically typed FP with Sum Types and Pattern Matching and Immutability seems to be the cure If by "seems to be" you mean "claimed but yet to be demonstrated by the style's avid fans". Beyond some compilers -- for which those languages were specially designed and are particularly suited -- there are precious few large, long-maintained software written in such languages, and the few projects out there don't seem to be doing significantly better than the rest. I'm not saying it's not a fine style, but so far it doesn't seem to be a cure, let alone the cure, to anything.

wtetzner 9y ago

> How so? Can we program Haskell's Hindley-Milner based type checking into Lisp with macros and homoiconicity, and have it run during compile-time? I don't see why not. Typed Racket does more or less that (it's not Hindley-Milner, but that's because they wanted a type system that matched Scheme idioms better): https://docs.racket-lang.org/ts-guide/ https://docs.racket-lang.org/ts-guide/ > I have done my fair share of meta-programming with Ruby and I realized I really didn't want the power to change my program model at runtime. While they made certain things easier - like Rails's ActiveRecord (which is superb btw) - the "inception"-like indirection made things very hard to reason about. Lisp macros run only at compile time. You can just ask the REPL (or your editor) to expand a particular macro invocation for you to see what code is generated. Of course, macros are still typically harder to debug than functions, but sometimes macros are the only way to abstract a certain pattern. That's why Template Haskell, CamlP4, OCaml extension points, etc. exist. > So far, statically typed FP with Sum Types and Pattern Matching and Immutability seems to be the cure, and macros and dynamic typing its very antithesis. I would argue that macros complement statically typed functional programming. Again, there's a reason for Template Haskell, CamlP4, OCaml extension points, etc. > For me the secret-weapon language is less about power, and more about structure. Yeah, this is where OCaml's module system shines.

soegaard 9y ago

How so? Can we program Haskell's Hindley-Milner based type checking into Lisp with macros and homoiconicity, and have it run during compile-time? Take a look at Hackett "a fanciful sketch of a programming language from a far-off land with Haskell’s type system and Racket’s macros." https://lexi-lambda.github.io/blog/2017/05/27/realizing-hackett-a-metaprogrammable-haskell/ https://lexi-lambda.github.io/blog/2017/05/27/realizing-hack...

flavio81 9y ago

> How so? Can we program Haskell's Hindley-Milner based type checking into Lisp with macros and homoiconicity, and have it run during compile-time? Not all of us want static type-checking. Some of us do want dynamic typing.

flavio81 9y ago

> In that context, the differentiating power of Lisp seems to be around macros - a very powerful way to write programs that write programs. I have done my fair share of meta-programming with Ruby and I realized I really didn't want the power to change my program model at runtime. While they made certain things easier - like Rails's ActiveRecord (which is superb btw) - the "inception"-like indirection made things very hard to reason about. The difference between metaprogramming in Lisp (lisp macros) and metaprogramming in a language like Ruby, is that writing macros in Lisp is really, really easy. It is simply not much harder than writing a normal function. Thus, while in other languages, doing metaprogramming is a special affair, in Lisp it is a piece of cake, and nothing special at all. Lisp also allows you to "expand" the macro to see what the macro would do when called. This is also very easy to do. So, i do agree with your point, however let me rephrase it: One of the most important differentiators for Lisp is really easy-to-write metaprogramming.

jasim 9y ago
I'm now curious to give macros a try. Thanks.