Hacker News Reader

Comment by tikhonj | Hacker News Reader

> In order for a programmer to accept a language with strictly less expressive power

Sort of hard to reconcile this view with just how much more expressive the Haskells and Lisps of the world are compared to Go and Python! I've used all of these extensively and functional languages have consistently let me define more general and flexible abstractions, do a better job of reflecting my conceptual model of the domain in my code... all in substantially less code and less boilerplate (excessive imports aside :P) than primarily imperative languages.

Functional languages don't stop you from writing imperative code, they allow you to write code that isn't—and, either way, that's just one small aspect of what makes a language adaptable and flexible.

View on HN

> Functional languages don't stop you from writing imperative code, they allow you to write code that isn't

Functional languages are definitely about removing things or stopping things. Nothing stops you from naming a new variable everytime in C, but Erlang stops me from mutating variables. Only stack depth/lack of tail call optimizations stops me from using recursion to loop in C, but Erlang can only loop through recursion.

And Erlang is pretty pragmatic; some other functional languages are a lot more opinionated.

LISP isn't a pure functional language, it's a multi-paradigm language that is as dynamic as they come. Its problem isn't lack of expressivity, it's probably that it's too flexible (and of course the syntax throws people off).

As for Haskell, I guess that gets into the question of how you define expressivity, which is admittedly a very fuzzy term. Here I meant it to mean capable of fluently expressing many different kinds of algorithms without having to resort to circumlocution.

Functional programming is natively supported in almost all modern languages. You call a function which calls a function which calls a function which calls a function, return the result. There's no syntactic sugar, just function calls.

In Haskell, while I've seen people argue that do notation may as well be imperative code, it isn't. It's an approximation of imperative code using Church—Turing and a liberal dose of syntactic sugar, and using it effectively still requires you to understand the underlying monadic model.

This seems like an easy fix, re-release LISP with cleaner syntax. Lexers have come so far this seems like an easy fix.

I can't say i've ever read the opinion that LISP's syntax allows more expressive programming; rather LISP itself allows more expressive programming at the tradeoff of the syntax.

> re-release LISP with cleaner syntax.

A lot of the flexibility of lisp relies on there being no difference between a list of symbols and code (for, example, this is how the entire macro system works).

Function calls being inside the parentheses (and, really, all language constructs just being lists of symbols) is generally what people mean when they say the syntax throws people.

These two things are at odds.

You could go with Racket's method of letting people use alternate delimiters, but that's a fairly trivial reader macro in common lisp and probably not worth releasing a language over.

The macro system can just work with an AST instead of a list.

Plenty of successors to lisp have tried that. They gunk up the whole experience.

Let me know if you'd like to give it a shot to see how gunky it is!

I mean, I'd be down to try.

Best I've seen so far (outside of lisp) is elixir, but it really bogs down the entire thing by requiring a bunch of extra information and metadata that common lisp can infer by position and an extra layer of indirection.

Contact form here: https://quil.la/FVZ3PMZC Thanks!

>I can't say i've ever read the opinion that LISP's syntax allows more expressive programming; rather LISP itself allows more expressive programming at the tradeoff of the syntax.

The conventional idea from LISPers is the other way around: LISP's syntax allows for more expressive programming, because code and data are isomorphic (so, macros and rewriting, etc.), and any function you make looks (and is, and behaves) as "first class" as any native one.

LISP's syntax is also said to be a better and more concise way than JSON (and or course XML) to describe arbitrary hierarchical structures.

There is no cleaner syntax than Lisp's. It is essential to Lisp's expressivity.

O-expressions seem pretty good.

Adding different syntax to Lisp has been tried many times. No attempt has ever succeeded. Lisp users basically rejected all those systems, and they didn't gain any traction in bringing new users into Lisp.

The first attempt was Lisp 2. This doesn't refer to Lisp-2 (two namespaces for variables and functions) but to a follow-up to Lisp 1.5, which was tried in the 1960's. Lisp 2, IIRC, featured an Algol-like syntax, with types, for speeding up numeric processing. It went nowhere. In the early 1970's, Vaughan Pratt (of "Pratt parser" fame, I think) created CGOL. That also went nowhere. After that we can identify numerous other things in that vein.

Here we are today and most people using Lisp still have it (looking (like) this).

IMO the thing that makes lisp so powerful is the ability to extend the syntax, and this is only possible because the syntax is represented as a list.

When your syntax can be manipulated like data (in this case lists), macros become regular functions operating on regular data, the data just happens to be syntax in this case. I can take a struct definition for example and use regular, built-in list manipulation functions to walk the definition and transform it into whatever I want.

In something like Rust we can also run macros on struct definitions, but in that case you operate on a token stream, and need specialized libraries and functions to do meaningful transformations. It ends up being much more difficult but still pretty powerful.

Super powered macros is what makes lisp "lispy" to me and the "abnormal" syntax is required for that, so I do think the syntax is what makes is uniquely expressive.

>LISP isn't a pure functional language

In the modern history-rewritten sense of the term to mean Haskell and purity.

In the past LISP was the 100% canonical idea of what a functional language is, including on HN before 2010 or so.

Lisp was never "pure", but yes, there's definitely been a shift in the meaning of the term "functional language". Which makes sense: the things that made Lisp more "functional" or better suited to the functional style have almost universally adopted by other languages. There's nothing particularly functional about it anymore.

Lisp has always been deeply multiparadigm, even if it was the harbinger of FP. It's had support for mutation and OOP since the 70s. If you wanted to (although most Lispers wouldn't), you could view that support as an escape hatch for when the functional paradigm, as expressed in Lisp, was inappropriate or insufficient to solve a problem. It's natural, then, that languages that have taken the functional paradigm and insisted on it, run further with it, are now the ones that are particularly functional. It's how language naturally evolves in cases like this; similar things can be seen with the term "artificial intelligence".

You might be confusing Lisp with ML.

Nope. ML, albeit ancient, was not even on the map on HN until after Haskell picked mindshare. I mean you could find a post here and a post there, but nothing like Lisp's posts and HN-mindshare.

And, sure, HN was from the start a Lisp-built forum, made by a Lisp-advocate, and thus attracting Lispers, but it wasn't that different on the wider internet.

But who said more or less of what on HackerNews, and in what years, bears no relevance to what is pure functional language. Lisp had mutable everything from the earliest beginning, and that has been maintained in the descendant dialects.

We literally cannot go back to a time in which Lisp was the model of what is purely functional; though it may have been used as an instrument (in restricted ways) for conveying or practically making use of the ideas.

There is something called "pure Lisp". Even such backwaters as the Webster Dictionary of Computing seem to know what this is:

http://www.webster-dictionary.org/definition/Pure+Lisp

"A purely functional language derived from Lisp by excluding any feature which causes side-effects."

I think you will rarely see an entire program written in nothing but pure Lisp. Functions or modules can be designated as being in pure Lisp. If the documentation says that a certain module is pure Lisp, that instantly sets certain expectations about what it will be like to interact with.

If you truly think "functional programming is natively supported in almost all modern languages" then you really don't know what modern FP is about.

For instance implementations of monadic control flow, effect systems, higher kinded types, algebraic data types, exhaustive pattern matching etc are all laughably unergonomic or entireley missing in most "popular"/"enterprise" languages. Just having a labmda doesn't FP make.

To me, FP in modern functional languages provides abstractions that enable much more straightforward problem solving and understandable code with fearless refactoring. Haskell and Ocaml are the pragmatic leaders here I think, with honorable mentions for things like Scala3, F#, and (kindof?) clojure.

(edit spelling)

I've spent more time studying programming languages than anyone else I know, and I understand FP very well. The argument that I'm making is not that FP has nothing to offer (I dearly hope that many more features from FP languages make it into the mainstream!), it's that FP comes with a set of restrictions on what can and cannot be done, and those restrictions do not seem justified to the majority of programmers. It is as uncomfortable for them to work with Haskell as it is to work with Rust, but unlike with Rust they can't see why they should bother.

The author of the article hopes to build a new functional programming language that will finally get traction by making a few different choices. I think that this is a mistake because a single-paradigm language will never reach mainstream adoption. Pragmatically multi-paradigm languages have historically been the only ones to get traction, and I believe that the reason is because they explicitly endorse multiple possible approaches, even if their support for any given approach isn't as strong as a specialized tool. They may not support FP as well as Haskell or OO as well as Smalltalk, but by sacrificing purity they buy pragmatism, and allow programmers more flexibility in problem solving.

> They may not support FP as well as Haskell or OO as well as Smalltalk…

The Smalltalk Collection enumeration protocol was probably the first time I'd seen anything like

    (1 to: 100) select: [ :n | n isPrime ]

https://cuis-smalltalk.github.io/TheCuisBook/Fun-with-collec...

(Now I recall, I had been required to write some Tower of Hanoi snippet in either Lisp or Prolog, and I'd used Prolog.)

> For instance implementations of monadic control flow, effect systems, higher kinded types, algebraic data types, exhaustive pattern matching etc are all laughably unergonomic or entireley missing in most "popular"/"enterprise" languages.

You don't need all that garbage in most languages because they allow mutation. In Haskell you can't have a class instance with a few variables so you end up with all these endofunctors, monomorphisms, and applicatives. And I would argue that, say, implementing Chaitin's algorithm, which involves filling and emptying a stack and destructuring a graph is not at all straightforward in a functional language.

> To me, FP in modern functional languages provides abstractions that enable much more straightforward problem solving and understandable code with fearless refactoring.

Maybe, but they remove other abstractions. The lack of Haskell's popularity is a clear indication that the abstractions added are not as valuable to programmers as the abstractions removed.

> The lack of Haskell's popularity is a clear indication that the abstractions added are not as valuable to programmers as the abstractions removed.

No it's not. At most it's an indication that of the group programmers familiar with Hakell's abstractions that they aren't enough to try the language more.

For it to be a clear indication those programmers would actually have to learn to effectively use Haskell's abstractions and compare it to a version in their former language that doesn't utilize the abstractions.

Almost nearly no one does this however... I can recall one instance that comes close:

http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...

However that's not a comparision of abstractions.

> For it to be a clear indication those programmers would actually have to learn to effectively use Haskell's abstractions and compare it to a version in their former language that doesn't utilize the abstractions.

No one tries everything, there's just no time to try all the possible alternatives.

Lack of popularity may not mean that the unpopular thing is bad, but it ain't a indication that further study would reveal it to be good.

In this particular case, Haskell isn't selling painkillers, it's selling vitamins. Few who have tried it go on to adopt it - it clearly isn't solving any immediate problem.

Imperative languages allow you to write functional code, too, but it's clumsier. It's not the strength of the language. In the same way, sure, you can write imperative code in a functional language. But ergonomically, it's not as nice as writing imperative code in an imperative language.

If you're code is going to be 90% imperative, don't write it in Haskell. If it's going to be 90% functional, don't write it in C++.

Reply on news.ycombinator.com