[benbataille]

> All languages are Turing complete, so it doesn't matter?

Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it. Once again it mostly boils down to preference.

If you really need to argue about something go for my compiler/optimisation pass is better that at least does make sense. Note that there is no theoretical bound preventing an Haskell compiler to generate code equally fast than the one of a C compiler for any program.

> Do you program in assembly language then?

I did when I had to (quite a long time ago). While languages don't matter, compilers do when you need efficiency. While enjoying ML-based languages more, I also did some C. As I stated before, C compilers are better. Well, I even used my own little syntax-extension of C for a moment (if you don't have to share the code, you can do whatever you want with it).

[Chattered]

> Syntax is mostly a matter of preference.

And to paraphrase Feynman, mathematics is mostly the invention of better syntax. One thing I'd say which distinguishes Haskellers is that they see their programming language as a piece of mathematics. A Haskell program is a bunch of equations, and the semantics are given by domain theory.

[gits1225]

>>"Precisely. The whole "my language is better" argument is completely void."

You say later that the difference is "only on how you will do it". If you stop to think for a second, you come to realise that syntax, abstractions and the big elephant in the room: how "tuned" a language is for the myriad of computing platforms/operating systems/domains (scientific, business, web) -among many other factors- play a HUGE part in how you can develop software and how performant it can/will be. So languages does matter.

>>"Note that there is no theoretical bound preventing an Haskell compiler to generate code equally fast than the one of a C compiler for any program."

But it won't, because at the end of the day, a machine has to execute the programs written in a language and C was designed for a machine with certain characteristics in mind while Haskell/Lisp and other higher level languages are an exploration in abstractions.

When Abelson & Sussman says: "Programs must be written for people to read, and only incidentally for machines to execute.", there is an implicit understanding that trade-offs are being made and its not the same as C and other lower level programming languages. Until a machine appears that isn't limited by the constrains of the present, making trade-offs is inevitable and that too, does matter.

@jacquesm: Great write-up. Enjoyed every line of it.

P.S: I make no distinction between a language and its implementation here.

[haberman]

> Note that there is no theoretical bound preventing an Haskell compiler to generate code equally fast than the one of a C compiler for any program.

And there's no theoretical bound saying that C is faster than Brainfuck. But no Brainfuck implementation will ever catch C for, say, parsing, and I'd be willing to put money on that.

This "all Turing-complete languages are on equal performance footing" is nonsense. Just because you can't write a proof that shows a result mathematically does not mean that a difference does not exist.

[true_religion]

> Syntax is mostly a matter of preference.

While I halfways agree here, syntax follows semantics.

If a language gives you a syntatical sugar form of something that can only be expressed through many lines of code in another, then it makes a great deal of difference.

[betterunix]

If one language cannot be better than another, why is it so hard to name examples of BF programs that paid their own development costs and decades of research costs? I can think of a language for which there is such an example, by the way:

https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replannin...

[pretoriusB]

>Precisely. The whole "my language is better" argument is completely void. Syntax is mostly a matter of preference. Semantic will make the structure of your program different but in the end there is no actual difference on what you can do only on how you will do it.

That is extraordinarily wrong.

Syntax:

1) affects the structure of a program,

2) affects how we think about it,

3) affects what is easy to do and what is not,

4) adds or removes mental strain on reasoning about the program,

5) forbids or enables certain kinds of errors.

And much more.

The idea that syntax doesn't matter and is "a matter of preference" is completely bogus. The human mind has certain limitations and capabilities. Some syntaxes cater to that, some do not.

No one using Brainfuck will never be as productive as Python, to take an extreme case.

[bgilroy26]

> No one using Brainfuck will never be as productive as Python, to take an extreme case.

Isn't it a good thing then, that no one prefers using Brainfuck to using Python at work? Leaving things up to preference doesn't mean that all the choices are the same. It means that the languages and the use cases are so varied that it isn't a good idea to restrict oneself blindly to a language before evaluating the use case. It doesn't seem like you are really in disagreement.

[pretoriusB]

>It doesn't seem like you are really in disagreement.

Oh, I'm very, very much in disagreement.

It's not just about "preference" as if preference is arbitrary.

Superficial syntactic preference IS arbitrary.

Substancial syntax issues are not.

Brainfuck is not just left alone because people don't "prefer" its syntax. That's reading it in reverse. People don't prefer Brainfuck's syntax because it is objectively, and for reasons related to human psychology, cognition, etc bad.

E.g it makes it measurably difficult to discern different program states.

[bgilroy26]

Preference isn't arbitrary, people make reasoned judgments to determine what tools they will use to get their work done.

No one spends 40 hours a week with a language without knowing its strengths and weaknesses.

[jacquesm]

> No one spends 40 hours a week with a language without knowing its strengths and weaknesses.

I wouldn't take that bet.