3 ms·

I liked the fact that it started with language design too. One of the links points to a Paul Graham essay which touches on the idea that "You Need an Applicatio

I liked the fact that it started with language design too. One of the links points to a Paul Graham essay which touches on the idea that "You Need an Application to Drive the Design of a Language"; that writing a language for the sake of writing a language without an application in mind isn't (edit*) as effective[0]. Things like that, thinking about the reason for creating the language in the first place, is a fundamental starting point imo. [0] http://www.paulgraham.com/langdes.html http://www.paulgraham.com/langdes.html (Number 3)

aaron-lebo 10y ago
So I checked out that link and: This may not be an absolute rule, but it seems like the best languages all evolved together with some application they were being used to write. C was written by people who needed it for systems programming. Lisp was developed partly to do symbolic differentiation, and McCarthy was so eager to get started that he was writing differentiation programs even in the first paper on Lisp, in 1960. ...but can that claim really be supported? Are c and lisp "the best" languages and if that "rule" is true, why does the claim have to be tempered for the two examples (C was written by people who needed to do programming at the time - was PHP not written for needs, too? lisp was only kind of developed for symbolic differentiation, and was lisp 1.6 one of the best languages or do we prefer scheme, common lisp...arc)? He could have at least tried to make us believe it! :)
- fmap 10y ago
  The truth seems to be that we don't know what makes a good language. In academic research we have criteria for what makes a language expressive, and tools for analyzing existing languages and check if they allow for modular development or are fundamentally incapable of building sound abstractions. What we don't have are answers to the "soft" questions. What makes a language pleasant to use (ignoring familiarity)? Which abstractions are easy to communicate and why or why not? What's the best way to communicate intent to a computer? It seems very unlikely that the answer should be "a text editor", but so far all alternatives have turned out to be terrible... What's especially vexing about this is that it looks like a solvable problem. People in the social sciences have been measuring far more ephemeral phenomena, the only problem is one of funding and finding the right people to run such big and extensive experiments.
  - loup-vaillant 10y ago
    > The truth seems to be that we don't know what makes a good language. On the other hand, we do know what makes a bad language. We can spot flaws in a language, and fixing them automatically makes them better —at least in the aspects one is interested in. C for instance has a number of flaws and questionable tradeoffs that are widely known by now: Contextual grammar. While not too bad (the context is easy to maintain in the parser), unknown identifiers can lead to syntax errors, and slightly worse error messages. Complicated syntax for types. Matching declaration and use may have sounded neat at the time, but doing so kills the separation between an entity's name and its type. The result is not very readable. An ML-like syntax would be much better. Switch that falls through by default. The switch statement were clearly designed from an implementer's point of view —it maps nicely to a jump table. In practice however over 95% of switch statements do not fall through. Switch should break by default (Having multiple cases branch to the same code is more common, but is not incompatible with breaking by default, see how ML style pattern matching does it). No direct support for sum types (tagged unions). We have structs , unions, and with them we can emulate algebraic data types. It's a pain in the butt however. Automating this somewhat would be nice, since sum types are so widely useful. Even if they were used just for error handling that would be a nice bonus. No generics. Makes it much harder to abstract away common code. Want to write a generic hash table? Good luck with pre-processor magic. Textual macros. We can do, and have done, better than that. Too many undefined behaviours. In the name of portability, many things that would have worked fine on many architectures are now undefined because some architectures couldn't handle them. And now we have silly stuff such as undefined signed integer overflow. But we can't remove them because compiler writers justify this madness with optimizations! (For the record, I have seen Chandler Carruth's talk on the subject, and I disagree: when compilers remove security checks because of undefined behaviour, it is just as bad as nasal demons.) Silly `for` loop. That damn thing is fully general, we don't need that. We have the `while` loop. A simpler, less general syntax would have allowed optimisations that currently exploit undefined signed integer overflow, and then some. --- Of course, it's easy to criticise a language over 40 years after the fact. But that's kind of the point: we have learned a good deal since the 70's. A language written now could not justify most of the flaws above. This is why so many people (me included) dismissed Go out of hand: not providing generics in a new statically typed language is just silly. Sure, designing a good language is still very hard. But we can avoid more mistakes now than we could some decades ago.
- coldtea 10y ago
  >...but can that claim really be supported? Are c and lisp "the best" languages and if that "rule" is true, why does the claim have to be tempered for the two examples (C was written by people who needed to do programming at the time - was PHP not written for needs, too? lisp was only kind of developed for symbolic differentiation, and was lisp 1.6 one of the best languages or do we prefer scheme, common lisp...arc)? I find most of the questions irrelevant to his point. >Are c and lisp "the best" languages Yes, by many metrics. They might no be the best academically perfect languages, but they both have been hugely resilient, influential, and/or succesful, which is a good metric for considering what's "best". >* (C was written by people who needed to do programming at the time - was PHP not written for needs, too?* Yes, and PHP is also very good for what it does, with huge adoption and powering over 30% of the web. >was lisp 1.6 one of the best languages or do we prefer scheme, common lisp...arc Doesn't matter, those are still Lisps or owe 90% of their existence to Lisp 0.1. Any languages can have multiple updates, mistakes fixed, added cool features, etc, PG talks more about the core of the language being great (the language as set of concepts etc), than about Lisp 0.1 or C 0.1 being great from the start. Whether those languages were later updated with even better constructs is kind of irrelevant.
  - aaron-lebo 10y ago
    Yes, by many metrics. They might no be the best academically perfect languages, but they both have been hugely resilient, influential, and/or successful, which is a good metric for considering what's "best". like JS? Is it a best language? C and lisp are very different examples of success - one has been dominant in business for decades and one was very influential but isn't really a business success today. Those are hugely different metrics - are you talking about popularity or core language design? If you expand the definition for success that wide, then yeah, you'll find that all "successful" languages fit your standard because you don't have a very useful standard. Yes, and PHP is also very good for what it does, with huge adoption and powering over 30% of the web. Yes, but knowing pg's stance on blub, he probably wouldn't agree. But that's the issue with the claim - PG didn't really expand on it so you have no idea what he really means. The fact of the matter is we simply don't have that many examples of successful languages. Maybe n < 29 which means that every example we pick of "this is how language design works" is choosing from a very small sample, perhaps not representative of anything and all successful due to various factors. Not a good way to make "rules".

aaron-lebo 10y ago

So I checked out that link and: This may not be an absolute rule, but it seems like the best languages all evolved together with some application they were being used to write. C was written by people who needed it for systems programming. Lisp was developed partly to do symbolic differentiation, and McCarthy was so eager to get started that he was writing differentiation programs even in the first paper on Lisp, in 1960. ...but can that claim really be supported? Are c and lisp "the best" languages and if that "rule" is true, why does the claim have to be tempered for the two examples (C was written by people who needed to do programming at the time - was PHP not written for needs, too? lisp was only kind of developed for symbolic differentiation, and was lisp 1.6 one of the best languages or do we prefer scheme, common lisp...arc)? He could have at least tried to make us believe it! :)

fmap 10y ago
The truth seems to be that we don't know what makes a good language. In academic research we have criteria for what makes a language expressive, and tools for analyzing existing languages and check if they allow for modular development or are fundamentally incapable of building sound abstractions. What we don't have are answers to the "soft" questions. What makes a language pleasant to use (ignoring familiarity)? Which abstractions are easy to communicate and why or why not? What's the best way to communicate intent to a computer? It seems very unlikely that the answer should be "a text editor", but so far all alternatives have turned out to be terrible... What's especially vexing about this is that it looks like a solvable problem. People in the social sciences have been measuring far more ephemeral phenomena, the only problem is one of funding and finding the right people to run such big and extensive experiments.
- loup-vaillant 10y ago
  > The truth seems to be that we don't know what makes a good language. On the other hand, we do know what makes a bad language. We can spot flaws in a language, and fixing them automatically makes them better —at least in the aspects one is interested in. C for instance has a number of flaws and questionable tradeoffs that are widely known by now: Contextual grammar. While not too bad (the context is easy to maintain in the parser), unknown identifiers can lead to syntax errors, and slightly worse error messages. Complicated syntax for types. Matching declaration and use may have sounded neat at the time, but doing so kills the separation between an entity's name and its type. The result is not very readable. An ML-like syntax would be much better. Switch that falls through by default. The switch statement were clearly designed from an implementer's point of view —it maps nicely to a jump table. In practice however over 95% of switch statements do not fall through. Switch should break by default (Having multiple cases branch to the same code is more common, but is not incompatible with breaking by default, see how ML style pattern matching does it). No direct support for sum types (tagged unions). We have structs , unions, and with them we can emulate algebraic data types. It's a pain in the butt however. Automating this somewhat would be nice, since sum types are so widely useful. Even if they were used just for error handling that would be a nice bonus. No generics. Makes it much harder to abstract away common code. Want to write a generic hash table? Good luck with pre-processor magic. Textual macros. We can do, and have done, better than that. Too many undefined behaviours. In the name of portability, many things that would have worked fine on many architectures are now undefined because some architectures couldn't handle them. And now we have silly stuff such as undefined signed integer overflow. But we can't remove them because compiler writers justify this madness with optimizations! (For the record, I have seen Chandler Carruth's talk on the subject, and I disagree: when compilers remove security checks because of undefined behaviour, it is just as bad as nasal demons.) Silly `for` loop. That damn thing is fully general, we don't need that. We have the `while` loop. A simpler, less general syntax would have allowed optimisations that currently exploit undefined signed integer overflow, and then some. --- Of course, it's easy to criticise a language over 40 years after the fact. But that's kind of the point: we have learned a good deal since the 70's. A language written now could not justify most of the flaws above. This is why so many people (me included) dismissed Go out of hand: not providing generics in a new statically typed language is just silly. Sure, designing a good language is still very hard. But we can avoid more mistakes now than we could some decades ago.
coldtea 10y ago
>...but can that claim really be supported? Are c and lisp "the best" languages and if that "rule" is true, why does the claim have to be tempered for the two examples (C was written by people who needed to do programming at the time - was PHP not written for needs, too? lisp was only kind of developed for symbolic differentiation, and was lisp 1.6 one of the best languages or do we prefer scheme, common lisp...arc)? I find most of the questions irrelevant to his point. >Are c and lisp "the best" languages Yes, by many metrics. They might no be the best academically perfect languages, but they both have been hugely resilient, influential, and/or succesful, which is a good metric for considering what's "best". >* (C was written by people who needed to do programming at the time - was PHP not written for needs, too?* Yes, and PHP is also very good for what it does, with huge adoption and powering over 30% of the web. >was lisp 1.6 one of the best languages or do we prefer scheme, common lisp...arc Doesn't matter, those are still Lisps or owe 90% of their existence to Lisp 0.1. Any languages can have multiple updates, mistakes fixed, added cool features, etc, PG talks more about the core of the language being great (the language as set of concepts etc), than about Lisp 0.1 or C 0.1 being great from the start. Whether those languages were later updated with even better constructs is kind of irrelevant.
- aaron-lebo 10y ago
  Yes, by many metrics. They might no be the best academically perfect languages, but they both have been hugely resilient, influential, and/or successful, which is a good metric for considering what's "best". like JS? Is it a best language? C and lisp are very different examples of success - one has been dominant in business for decades and one was very influential but isn't really a business success today. Those are hugely different metrics - are you talking about popularity or core language design? If you expand the definition for success that wide, then yeah, you'll find that all "successful" languages fit your standard because you don't have a very useful standard. Yes, and PHP is also very good for what it does, with huge adoption and powering over 30% of the web. Yes, but knowing pg's stance on blub, he probably wouldn't agree. But that's the issue with the claim - PG didn't really expand on it so you have no idea what he really means. The fact of the matter is we simply don't have that many examples of successful languages. Maybe n < 29 which means that every example we pick of "this is how language design works" is choosing from a very small sample, perhaps not representative of anything and all successful due to various factors. Not a good way to make "rules".