13 ms·

All Programming Languages are Wrong (2018)

57 points by jashkenas 7y ago

dboreham 7y ago
Hmm...BCPL isn't from the 50s. C++ isn't from the 70s.
- Taniwha 7y ago
  yeah that was my immediate thought, stopped reading at that point. BCPL was from the late 60s, most people were introduced to it in the 70s, C++ from the mid-80s
  - pjmlp 7y ago
    And it was never intended to be used as full programming language rather to bootstrap the CPL compiler, hence the B. https://en.wikipedia.org/wiki/CPL_(programming_language) https://en.wikipedia.org/wiki/CPL_(programming_language) In an alternative universe, had the CPL project not suffered management issues and C would never had happened.
  - deleted 7y ago
    [deleted]
- Rochus 7y ago
  Yes, and Smalltalk certainly hasn't "added dynamic features to Algol".
- gridlockd 7y ago
  Nitpicking. Fortran was designed in the fifties, the precursor to BCPL was designed in the early sixties, and C++ (C with classes) was originally designed in 1979, heavily influenced by Simula which also dates back to the sixties. The time of the design of the language is different from actual implementations being made available. C++ compilers were pretty much unusable until the nineties.
bcrosby95 7y ago
> For example, one cache miss might take as much time as a hundred add instructions. > Today's languages contain far too many features that do almost the same thing but have slightly different performance characteristics, for example regular and virtual functions in C++. Odd example. Virtual functions help enable certain designs, but avoiding virtual functions is commonly recommended when writing cache friendly code.
- spaced-out 7y ago
  Honestly it really hurts the author's credibility. Virtual functions hurt performance (generally not significantly) but allow for OOP design, in theory to make the program structure more clear/organized. Exactly what the author is supposedly advocating.
hr0m 7y ago
I wonder what the author would do, when performance is critical. Today too many people rely on fast cpu and large memory. There are lots of applicants, where you need to optimize.
StreamBright 7y ago
Is there a cached version? I could not find it anywhere.
_bxg1 7y ago
Pretty vague and empty argument (rant?). Doesn't really say anything I haven't seen complained about (and disputed) elsewhere and doesn't really propose any actual solutions.
- gridlockd 7y ago
  > ...doesn't really propose any actual solutions. The proposed solution is the language he designed: http://users.rcn.com/david-moon/Lunar/introduction.html http://users.rcn.com/david-moon/Lunar/introduction.html
  - _bxg1 7y ago
    Ah. That could've been made more clear in the link title
dusted 7y ago
Computation is not almost free and people are doing just fine writing slow code without the language helping them. Taken that we've more or less stalled with regards single core performance, I'd argue that computers are now getting slower (because software is bloating faster than single core performance is increasing).
- gridlockd 7y ago
  > Computation is not almost free... In the vast majority of cases, it is. He's talking about the ALUs actually performing work, as opposed to waiting on memory. He rightly points out that cache misses make the biggest performance impact on modern systems. Most languages these days do not address this, there's tons of indirection by design. > Taken that we've more or less stalled with regards single core performance, I'd argue that computers are now getting slower (because software is bloating faster than single core performance is increasing). Again, if you can actually give your ALUs enough work to saturate them, your problem is most likely embarrassingly parallel, in which case single-core performance is not the bottleneck. Otherwise, you will want to optimize for memory access.
- krzepah 7y ago
  I just watched a talk from Bjarne Stroustrup who told about a biologist who was getting data using python. It's script had to run for 3 month to get that data. The script was re-written and they got it right into 10 min exec time when he couldn't do it in 3 months anymore https://www.youtube.com/watch?v=fX2W3nNjJIo&feature=youtu.be&t=564 https://www.youtube.com/watch?v=fX2W3nNjJIo&feature=youtu.be...
perfobotto 7y ago
What a bunch of bs. There are so many places where computation is far from free and size matters (embedded, HPC for example). And the end of Moore law is just gonna emphasize the need for performance even more. This article just tells me that the author didn’t have to write any performance critical code in his life and he just extended his experience to everything
- dkersten 7y ago
  > There are so many places where computation is far from free and size matters (embedded, HPC for example). Even in more typical use cases, it matters: for example performance or memory use can mean the difference between a small or large EC2 instance which has very real cost implications. Or it affects battery life of my phone app. Or between my application feeling fluid or laggy. All of there’s things have real implications for users. I very much care when I need a top of the line computer to run some shitty application that should be able to run on 20 year old hardware. Yet I also understand programmer ergonomics and recently implemented an interpreter for a domain specific language in an already not the fastest language because productivity mattered more to me and correct easy to write domain code mattered more to me. But the point is that it was a conscious decision made after weighing the costs and benefits, not just because I think compute and memory are free. They’re not, this has a real cost for me being able to run it, in terms of servers, but with the benefit that I can replace complex buggy code that took me months to write, with simple easy to understand code that I could write in a few hours (and a thoroughly unit tested parser and interpreter that took a week to write)
- gridlockd 7y ago
  > There are so many places where computation is far from free and size matters (embedded, HPC for example). The amount of code where the cost of actual computation isn't vanishingly small relative to memory access is so tiny, it arguably should not dominate the design of a general purpose language. This wasn't true forty-plus years ago, when these languages were designed, and it's not true on some microcontrollers, but it's generally true today. The author is completely right in that general purpose languages do virtually nothing to optimize memory access (which is a hard problem), as opposed to optimizing ALU usage (which is relatively easy).
rmist 7y ago
Each programming language is suitable for solving certain type of problems. So when I see a catch-all statement like "All Programming Languages are Wrong", it seems to me the author is implying that "None of the programming languages solve my (or this specific type of) problem." > It does not reflect the realities of modern hardware, where computation is almost free, memory size is almost unlimited ... Well, no, this certainly doesn't apply to all problems! > ... because they seem to be in love with the idea of "object" or "abstract data type." ... Again, there are many different paradigms of programming, OOP being one of them with its own pros and cons.
bedobi 7y ago
IMO the biggest problems with almost all popular programming languages are 1) null 2) exception based error handling such that, when you call foo() where foo is String foo(){ blabla } you can get a String, null OR an exception (!!!) and most compilers happily let you treat it as if it only ever returns a String. I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try etc in the native libraries is the new default.
- makapuf 7y ago
  Ive thought a bit about this, and how is Option types (which I like and prefer to error checking) really different from the compiler emitting an error when you fail to explicitely check for nulls and stdlib returning nulls when you have one ?
  - quelltext 7y ago
    Because it forces (or at least strongly encourages) you/users of such a stdlib/API to explicitly think about and handle the null case and the non-null case if you want to access the contents directly / unwrap. At least that's the idea.
  - pasquinelli 7y ago
    That is what it is, a branch at the type level that the type checker mandates you complete both sides of.
  - bedobi 7y ago
    I think it's better, see the other reply at https://news.ycombinator.com/reply?id=22306638&goto=threads%3Fid%3Dbedobi%2322306638 https://news.ycombinator.com/reply?id=22306638&goto=threads%...
    - deleted 7y ago
      [deleted]
- quelltext 7y ago
  I am probably in the minority here but I think Java was on the right track with checked exceptions.
mogl1 7y ago
Is this just my feeling or this this text completely ignore languages which are of functional / declarative nature? Iirc Prolog doesnt "care" so much about performance (on a language level at least). Haskell knows Integer, Rational, Num etc. Same goes for Idris Languages from that area (lambda calculus) are, by definition, not based on the idea of some specific computer architecture. Totally possible that i missinterpreted something tho.
random_guy1234 7y ago
> Most current-day programming languages seem to be based on the idea that computation is slow, so the user and the compiler must work hard to minimize the number of instructions executed. Instructions executed is not the only metric to consider! It doesn't makes sense to have loads and stores in the program with all of them having a cache miss. Does the author mean that the memory hasn't caught up with the computation here? I don't think so. > For example, one cache miss might take as much time as a hundred add instructions. This is why compiler must work hard! > Today's languages contain far too many features that do almost the same thing but have slightly different performance characteristics, for example regular and virtual functions in C++. This just encourages programmers to waste time on micro-optimization when they could instead invest time understanding the large-scale behavior of their program and optimizing that. Not all programs need to worry about insane performance. But most do. It is totally upto the developers to choose the features of the language which they need. Choosing the right features/language for the right kind of programs is an important skill. Efficient code generation for all possible hardwares and all possible workloads with a restricted language features is not going to work or else Python would have been one of the very few languages to survive. Elon Musk wouldn't have tweeted that he needs C/C++ engineers ;-) It seems the article suggests that neither the hard working compiler nor the hardware friendly language is required to get good performance!
- pasquinelli 7y ago
  There's also energy consumption. Maybe the inefficient implementation isn't noticably slow to me, but i'll be unhappy if it drains my battery.
  - random_guy1234 7y ago
    Yes, there are so many things to consider. Another would be size of the binary.. Different kinds of problems are solved by different languages. Simply rejecting them without stating the details doesn't fly!
mfDjB 7y ago
Does anyone else consider these type of articles the clickbait of the programming world? They tend to all follow the formula of 1. Make over the top statement in title. 2. Vaguely address the over the top statement in content. For example the author hasn't shown us why "All" programming languages are "wrong". They haven't shown how they would fix them to make them "right". Their premises (e.g. "computation is almost always free") are flawed. I wonder, if the title was called "A rant about some popular programming language paradigms" would it be as popular?
- Antoninus 7y ago
  Agreed. Between Lobste.rs and HN its becoming increasingly difficult to filter out worth-while content.
  - dragonwriter 7y ago
    > filter out worth-while content Isn't that the opposite of the goal?
- nuclx 7y ago
  "computation is almost free" actually triggered me. that's the java argument from 20 years ago, now we have go and rust. it implies electron is actually a sane approach to ui development. the author is very vague about why exactly numbers don't fit in the type system, and in which languages. first class types for numbers exist in some languages. is he advocating for default overflow checks, which bloat code size?
  - dragonwriter 7y ago
    > the author is very vague about why exactly numbers don't fit in the type system No, he’s quite specific: “hardware details such as the number of bits supported by an integer add instruction show through in the language semantics.” Now, it's also true that there are quite a lot of languages where this is not true, e.g., Scheme, Haskell (IIRC with the default numeric settings), Ruby, Python, for instance, and many more have numeric types in core language or stdlib that don't face this problem but don't make them the default for simple numeric literals.
lejalv 7y ago
While computation might be sometimes pecuniarily cheap, it is often environmentally costly.
pkolaczk 7y ago
He claims all programming languages are wrong and then he bashes C++ virtual functions vs regular functions, C++ templates, single dispatch and fixed precision arithmetic. Looks like "all languages" means C++ to him. There exist languages with arbitrary precision arithmetic, e.g. Python or languages with much sophisticated polymorphism e.g. Haskell, Scala or Rust.
- lokedhs 7y ago
  Or Common Lisp, where you not only have arbitrary precision by default. You also have rationals.
- lazyjones 7y ago
  > There exist languages with arbitrary precision arithmetic, e.g. Python Floating point numbers are implemented using double in C. All bets on their precision are off unless you happen to know the machine you are working with. https://docs.python.org/2.4/lib/typesnumeric.html https://docs.python.org/2.4/lib/typesnumeric.html
imtringued 7y ago
Yeah exactly, we all know that the most used programming languages like Python and Javascript are way too focused on performance.
terminaljunkid 7y ago
I can't agree about the dot. Dot makes it easy to chain things left to write, and also almost always dot based syntax is more readable than stuffing all arguments in parenthesis. xs.delete(x) vs delete(xs,x) And virtual / regular function distinction exists in performance centered languages for a good reason. Either you have to go out of your way to prevent dynamic dispatch or use clunky function pointer syntax and manage vtables manually. Similar can be said to many features he complains about.
erezsh 7y ago
The author has a good point, although he miscommunicates it: The common use-cases, such as servers, business logic, glue code, etc., don't usually require hyper-optimized performance. It only needs to be reasonable and predictable. They need a language that is easy to work with, and share with others, and there are few that really do that. But of course, there are. Go, Python, Julia and others I'm sure, all prioritize comfort over performance. Although, as compilers improve, they might one day actually become faster -- since the user writes more abstractly, there is a wider search space for optimizations.
- random_guy1234 7y ago
  > But of course, there are Your statements are contradictory. > they might one day actually become faster faster compared to C/C++ ? Of course, Performance is improving day by day. What's the point?
  - erezsh 7y ago
    It's not contradictory. I'm saying that the things he says are true, and there are many languages that follow that line of thought. Yes, faster than C++. Better abstractions can, sometimes, give the compiler more flexibility to optimize.
- eigenspace 7y ago
  Julia does not prioritize comfort over (runtime) performance. The entire language is based around developing clever ways to get zero runtime cost abstractions.
The_mboga_real 7y ago
Hurrah! Now kill your mother for her crimes.
user2994cb 7y ago
To put the original in more context, David A. Moon is a major figure in the Lisp world: https://en.wikipedia.org/wiki/David_A._Moon https://en.wikipedia.org/wiki/David_A._Moon
codr7 7y ago
This is part of the introduction to a language he's been designing since forever. I attended the International Lisp Conference in Boston around 2005 and he did a presentation there of what seems like a precursor to this. Some of his views might be controversial, but he has plenty of Lisp implementation experience and clearly knows his stuff. And from what I've read so far, he writes excellent documentation. I'd recommend anyone to at least skim the whole thing [0]. [0] http://users.rcn.com/david-moon/Lunar/index.html http://users.rcn.com/david-moon/Lunar/index.html
jeffrallen 7y ago
But some are wronger than others. (I'm looking at you, Brainf*ck.)
juancn 7y ago
Computation is definitely not free. I spend a lot of my time avoiding non-essential computation as much as possible. I actually would like more control in many of the current languages.
valenciarose 7y ago
Referring to David Moon namelessly as "the author" in comments about language design (on Hacker News of all places) does not inspire confidence. Whether or not you agree with him, Moon has been involved in language design and implementation for decades. His perspective is directly relevant to discussion that's primarily focused on large scale trends in language design. I don't necessarily agree with everything he says here, but it is definitely worth thinking about, especially where it challenges accepted dogma.

57 points by jashkenas 7y ago

dboreham 7y ago

Hmm...BCPL isn't from the 50s. C++ isn't from the 70s.

Taniwha 7y ago
yeah that was my immediate thought, stopped reading at that point. BCPL was from the late 60s, most people were introduced to it in the 70s, C++ from the mid-80s
- pjmlp 7y ago
  And it was never intended to be used as full programming language rather to bootstrap the CPL compiler, hence the B. https://en.wikipedia.org/wiki/CPL_(programming_language) https://en.wikipedia.org/wiki/CPL_(programming_language) In an alternative universe, had the CPL project not suffered management issues and C would never had happened.
- deleted 7y ago
  [deleted]
Rochus 7y ago
Yes, and Smalltalk certainly hasn't "added dynamic features to Algol".
gridlockd 7y ago
Nitpicking. Fortran was designed in the fifties, the precursor to BCPL was designed in the early sixties, and C++ (C with classes) was originally designed in 1979, heavily influenced by Simula which also dates back to the sixties. The time of the design of the language is different from actual implementations being made available. C++ compilers were pretty much unusable until the nineties.

bcrosby95 7y ago

> For example, one cache miss might take as much time as a hundred add instructions. > Today's languages contain far too many features that do almost the same thing but have slightly different performance characteristics, for example regular and virtual functions in C++. Odd example. Virtual functions help enable certain designs, but avoiding virtual functions is commonly recommended when writing cache friendly code.

spaced-out 7y ago
Honestly it really hurts the author's credibility. Virtual functions hurt performance (generally not significantly) but allow for OOP design, in theory to make the program structure more clear/organized. Exactly what the author is supposedly advocating.

hr0m 7y ago

I wonder what the author would do, when performance is critical. Today too many people rely on fast cpu and large memory. There are lots of applicants, where you need to optimize.

StreamBright 7y ago

Is there a cached version? I could not find it anywhere.

_bxg1 7y ago

Pretty vague and empty argument (rant?). Doesn't really say anything I haven't seen complained about (and disputed) elsewhere and doesn't really propose any actual solutions.

gridlockd 7y ago
> ...doesn't really propose any actual solutions. The proposed solution is the language he designed: http://users.rcn.com/david-moon/Lunar/introduction.html http://users.rcn.com/david-moon/Lunar/introduction.html
- _bxg1 7y ago
  Ah. That could've been made more clear in the link title

dusted 7y ago

Computation is not almost free and people are doing just fine writing slow code without the language helping them. Taken that we've more or less stalled with regards single core performance, I'd argue that computers are now getting slower (because software is bloating faster than single core performance is increasing).

gridlockd 7y ago
> Computation is not almost free... In the vast majority of cases, it is. He's talking about the ALUs actually performing work, as opposed to waiting on memory. He rightly points out that cache misses make the biggest performance impact on modern systems. Most languages these days do not address this, there's tons of indirection by design. > Taken that we've more or less stalled with regards single core performance, I'd argue that computers are now getting slower (because software is bloating faster than single core performance is increasing). Again, if you can actually give your ALUs enough work to saturate them, your problem is most likely embarrassingly parallel, in which case single-core performance is not the bottleneck. Otherwise, you will want to optimize for memory access.
krzepah 7y ago
I just watched a talk from Bjarne Stroustrup who told about a biologist who was getting data using python. It's script had to run for 3 month to get that data. The script was re-written and they got it right into 10 min exec time when he couldn't do it in 3 months anymore https://www.youtube.com/watch?v=fX2W3nNjJIo&feature=youtu.be&t=564 https://www.youtube.com/watch?v=fX2W3nNjJIo&feature=youtu.be...

perfobotto 7y ago

What a bunch of bs. There are so many places where computation is far from free and size matters (embedded, HPC for example). And the end of Moore law is just gonna emphasize the need for performance even more. This article just tells me that the author didn’t have to write any performance critical code in his life and he just extended his experience to everything

dkersten 7y ago
> There are so many places where computation is far from free and size matters (embedded, HPC for example). Even in more typical use cases, it matters: for example performance or memory use can mean the difference between a small or large EC2 instance which has very real cost implications. Or it affects battery life of my phone app. Or between my application feeling fluid or laggy. All of there’s things have real implications for users. I very much care when I need a top of the line computer to run some shitty application that should be able to run on 20 year old hardware. Yet I also understand programmer ergonomics and recently implemented an interpreter for a domain specific language in an already not the fastest language because productivity mattered more to me and correct easy to write domain code mattered more to me. But the point is that it was a conscious decision made after weighing the costs and benefits, not just because I think compute and memory are free. They’re not, this has a real cost for me being able to run it, in terms of servers, but with the benefit that I can replace complex buggy code that took me months to write, with simple easy to understand code that I could write in a few hours (and a thoroughly unit tested parser and interpreter that took a week to write)
gridlockd 7y ago
> There are so many places where computation is far from free and size matters (embedded, HPC for example). The amount of code where the cost of actual computation isn't vanishingly small relative to memory access is so tiny, it arguably should not dominate the design of a general purpose language. This wasn't true forty-plus years ago, when these languages were designed, and it's not true on some microcontrollers, but it's generally true today. The author is completely right in that general purpose languages do virtually nothing to optimize memory access (which is a hard problem), as opposed to optimizing ALU usage (which is relatively easy).

rmist 7y ago

Each programming language is suitable for solving certain type of problems. So when I see a catch-all statement like "All Programming Languages are Wrong", it seems to me the author is implying that "None of the programming languages solve my (or this specific type of) problem." > It does not reflect the realities of modern hardware, where computation is almost free, memory size is almost unlimited ... Well, no, this certainly doesn't apply to all problems! > ... because they seem to be in love with the idea of "object" or "abstract data type." ... Again, there are many different paradigms of programming, OOP being one of them with its own pros and cons.

bedobi 7y ago

IMO the biggest problems with almost all popular programming languages are 1) null 2) exception based error handling such that, when you call foo() where foo is String foo(){ blabla } you can get a String, null OR an exception (!!!) and most compilers happily let you treat it as if it only ever returns a String. I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try etc in the native libraries is the new default.

makapuf 7y ago
Ive thought a bit about this, and how is Option types (which I like and prefer to error checking) really different from the compiler emitting an error when you fail to explicitely check for nulls and stdlib returning nulls when you have one ?
- quelltext 7y ago
  Because it forces (or at least strongly encourages) you/users of such a stdlib/API to explicitly think about and handle the null case and the non-null case if you want to access the contents directly / unwrap. At least that's the idea.
- pasquinelli 7y ago
  That is what it is, a branch at the type level that the type checker mandates you complete both sides of.
- bedobi 7y ago
  I think it's better, see the other reply at https://news.ycombinator.com/reply?id=22306638&goto=threads%3Fid%3Dbedobi%2322306638 https://news.ycombinator.com/reply?id=22306638&goto=threads%...
  - deleted 7y ago
    [deleted]
quelltext 7y ago
I am probably in the minority here but I think Java was on the right track with checked exceptions.

mogl1 7y ago

Is this just my feeling or this this text completely ignore languages which are of functional / declarative nature? Iirc Prolog doesnt "care" so much about performance (on a language level at least). Haskell knows Integer, Rational, Num etc. Same goes for Idris Languages from that area (lambda calculus) are, by definition, not based on the idea of some specific computer architecture. Totally possible that i missinterpreted something tho.

random_guy1234 7y ago

> Most current-day programming languages seem to be based on the idea that computation is slow, so the user and the compiler must work hard to minimize the number of instructions executed. Instructions executed is not the only metric to consider! It doesn't makes sense to have loads and stores in the program with all of them having a cache miss. Does the author mean that the memory hasn't caught up with the computation here? I don't think so. > For example, one cache miss might take as much time as a hundred add instructions. This is why compiler must work hard! > Today's languages contain far too many features that do almost the same thing but have slightly different performance characteristics, for example regular and virtual functions in C++. This just encourages programmers to waste time on micro-optimization when they could instead invest time understanding the large-scale behavior of their program and optimizing that. Not all programs need to worry about insane performance. But most do. It is totally upto the developers to choose the features of the language which they need. Choosing the right features/language for the right kind of programs is an important skill. Efficient code generation for all possible hardwares and all possible workloads with a restricted language features is not going to work or else Python would have been one of the very few languages to survive. Elon Musk wouldn't have tweeted that he needs C/C++ engineers ;-) It seems the article suggests that neither the hard working compiler nor the hardware friendly language is required to get good performance!

pasquinelli 7y ago
There's also energy consumption. Maybe the inefficient implementation isn't noticably slow to me, but i'll be unhappy if it drains my battery.
- random_guy1234 7y ago
  Yes, there are so many things to consider. Another would be size of the binary.. Different kinds of problems are solved by different languages. Simply rejecting them without stating the details doesn't fly!

mfDjB 7y ago

Does anyone else consider these type of articles the clickbait of the programming world? They tend to all follow the formula of 1. Make over the top statement in title. 2. Vaguely address the over the top statement in content. For example the author hasn't shown us why "All" programming languages are "wrong". They haven't shown how they would fix them to make them "right". Their premises (e.g. "computation is almost always free") are flawed. I wonder, if the title was called "A rant about some popular programming language paradigms" would it be as popular?

Antoninus 7y ago
Agreed. Between Lobste.rs and HN its becoming increasingly difficult to filter out worth-while content.
- dragonwriter 7y ago
  > filter out worth-while content Isn't that the opposite of the goal?
nuclx 7y ago
"computation is almost free" actually triggered me. that's the java argument from 20 years ago, now we have go and rust. it implies electron is actually a sane approach to ui development. the author is very vague about why exactly numbers don't fit in the type system, and in which languages. first class types for numbers exist in some languages. is he advocating for default overflow checks, which bloat code size?
- dragonwriter 7y ago
  > the author is very vague about why exactly numbers don't fit in the type system No, he’s quite specific: “hardware details such as the number of bits supported by an integer add instruction show through in the language semantics.” Now, it's also true that there are quite a lot of languages where this is not true, e.g., Scheme, Haskell (IIRC with the default numeric settings), Ruby, Python, for instance, and many more have numeric types in core language or stdlib that don't face this problem but don't make them the default for simple numeric literals.

lejalv 7y ago

While computation might be sometimes pecuniarily cheap, it is often environmentally costly.

pkolaczk 7y ago

He claims all programming languages are wrong and then he bashes C++ virtual functions vs regular functions, C++ templates, single dispatch and fixed precision arithmetic. Looks like "all languages" means C++ to him. There exist languages with arbitrary precision arithmetic, e.g. Python or languages with much sophisticated polymorphism e.g. Haskell, Scala or Rust.

lokedhs 7y ago
Or Common Lisp, where you not only have arbitrary precision by default. You also have rationals.
lazyjones 7y ago
> There exist languages with arbitrary precision arithmetic, e.g. Python Floating point numbers are implemented using double in C. All bets on their precision are off unless you happen to know the machine you are working with. https://docs.python.org/2.4/lib/typesnumeric.html https://docs.python.org/2.4/lib/typesnumeric.html

imtringued 7y ago

Yeah exactly, we all know that the most used programming languages like Python and Javascript are way too focused on performance.

terminaljunkid 7y ago

I can't agree about the dot. Dot makes it easy to chain things left to write, and also almost always dot based syntax is more readable than stuffing all arguments in parenthesis. xs.delete(x) vs delete(xs,x) And virtual / regular function distinction exists in performance centered languages for a good reason. Either you have to go out of your way to prevent dynamic dispatch or use clunky function pointer syntax and manage vtables manually. Similar can be said to many features he complains about.

erezsh 7y ago

The author has a good point, although he miscommunicates it: The common use-cases, such as servers, business logic, glue code, etc., don't usually require hyper-optimized performance. It only needs to be reasonable and predictable. They need a language that is easy to work with, and share with others, and there are few that really do that. But of course, there are. Go, Python, Julia and others I'm sure, all prioritize comfort over performance. Although, as compilers improve, they might one day actually become faster -- since the user writes more abstractly, there is a wider search space for optimizations.

random_guy1234 7y ago
> But of course, there are Your statements are contradictory. > they might one day actually become faster faster compared to C/C++ ? Of course, Performance is improving day by day. What's the point?
- erezsh 7y ago
  It's not contradictory. I'm saying that the things he says are true, and there are many languages that follow that line of thought. Yes, faster than C++. Better abstractions can, sometimes, give the compiler more flexibility to optimize.
eigenspace 7y ago
Julia does not prioritize comfort over (runtime) performance. The entire language is based around developing clever ways to get zero runtime cost abstractions.

The_mboga_real 7y ago

Hurrah! Now kill your mother for her crimes.

user2994cb 7y ago

To put the original in more context, David A. Moon is a major figure in the Lisp world: https://en.wikipedia.org/wiki/David_A._Moon https://en.wikipedia.org/wiki/David_A._Moon

codr7 7y ago

This is part of the introduction to a language he's been designing since forever. I attended the International Lisp Conference in Boston around 2005 and he did a presentation there of what seems like a precursor to this. Some of his views might be controversial, but he has plenty of Lisp implementation experience and clearly knows his stuff. And from what I've read so far, he writes excellent documentation. I'd recommend anyone to at least skim the whole thing [0]. [0] http://users.rcn.com/david-moon/Lunar/index.html http://users.rcn.com/david-moon/Lunar/index.html

jeffrallen 7y ago

But some are wronger than others. (I'm looking at you, Brainf*ck.)

juancn 7y ago

Computation is definitely not free. I spend a lot of my time avoiding non-essential computation as much as possible. I actually would like more control in many of the current languages.

valenciarose 7y ago

Referring to David Moon namelessly as "the author" in comments about language design (on Hacker News of all places) does not inspire confidence. Whether or not you agree with him, Moon has been involved in language design and implementation for decades. His perspective is directly relevant to discussion that's primarily focused on large scale trends in language design. I don't necessarily agree with everything he says here, but it is definitely worth thinking about, especially where it challenges accepted dogma.