Hacker News Reader

Comment by initplus | Hacker News Reader

Any programming language represents limitations placed on the underlying expressiveness of the hardware. By this argument raw x86 asm is "more expressive" than any higher level language.

The whole point of a programming language is to provide you with common patterns/designs to simplify reasoning about your program. Even base concepts like a "function" or "struct" is really a limitation on the underlying expressive power.

Immutability/purity does solve real problems for programmers: it means that you only have to reason about mutability at the margins of your application. I think people who don't have experience with functional style don't realise how helpful this is. I choose to use functional languages because it makes me a better developer - I am able to write code that I am not diligent/smart/disciplined enough to write in an imperative style.

View on HN

That's not really how I - and I think most engineers - understand the term "expressiveness". In Haskell I can express "a side-effect free function that consumes a String and produces an Int", for example; it's impossible to express this in x86 assembly language. You can certainly write a block of code that has the same operational qualities, but the code itself doesn't in any way express any of that denotational information - it's all just implied or inferred, not something encoded in the language itself; you can't even express the idea of a "function", in fact!

Right, what parent called "expressiveness" is probably more accurately described as "flexibility". And flexibility is not always a good thing.

I agree completely about immutability and purity—for my own code I strongly lean that way and try to outsource as much of my thinking to the compiler as possible.

However, there are times where impurity and mutability are beneficial—whether within a single function or at the margins. Functional programming languages do not tend to have good support for these cases, because their whole thing is representing everything in a functional style.

I think this is why functional languages don't tend to get traction while the multi-paradigm languages do. Given a choice between purity and pragmatism, most engineers will pick pragmatism. The alternative is to intentionally remove tools from your toolbox, and unless those tools are demonstrably more dangerous than they are helpful that's a tough sell.

My ideal language is a multi paradigm language which has robust, statically analyzable support for objects, imperative code, and functional code.

> I think this is why functional languages don't tend to get traction while the multi-paradigm languages do. Given a choice between purity and pragmatism, most engineers will pick pragmatism.

Well, it's obvious to the working corporate-employed programmer, not so obvious to the ivory-tower theorist.

The short argument is that the entire point of a program is to take inputs and produce outputs. Making the consumption of inputs and the generation of outputs a second-class citizen in the language with the goal of "purity" just makes it that much harder for a program to perform its primary task.

> Making the consumption of inputs and the generation of outputs a second-class citizen in the language with the goal of "purity" just makes it that much harder for a program to perform its primary task.

You have this backwards. I/O is second class in every language except Haskell and languages with type and effect systems. Those are the only languages where it's a first-class citizen, which is to say that I/O computations are values that can be passed around, interpreted and otherwise recognized or operated on in various ways.

The problem is that people are used to the second class status and don't understand the additional power first class status gives you, or the patterns needed to make it extensible and maintainable.

I mean, you can write mutable code in Haskell, too. Parts of it can even look quite imperative. I think there are other cultural problems with the language, though.

>it means that you only have to reason about mutability at the margins of your application

Functional programming threads state throughout the execution of the program instead of just putting the state into variables you now have to track what data gets passed where.

Reply on news.ycombinator.com