5 ms·

JavaScript (or rather: a subset of it) is a fine teaching language too, especially since it's easy to publish runnable code - even for beginners. However, ther

by Udo 12y ago

JavaScript (or rather: a subset of it) is a fine teaching language too, especially since it's easy to publish runnable code - even for beginners. However, there is no language that can do everything equally well. It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Programming teachers should make a habit of pointing out that writing code is a journey that will require students to learn new tools all the time.

elwell 12y ago
> This can't possibly work well. Not that I disagree, but could you elaborate your reasoning here?
- Udo 12y ago
  There are many decisions that influence language design, it's not just syntax. Differing decisions are made about runtime behavior, memory management, levels of abstraction, and the efficiency of idiomatic data structures. Even objectively, a good language to write an OS kernel in isn't necessarily equally well suited to, say, game development, or web development, or scientific computing. That doesn't mean there won't be heroic efforts to make a language work in every arena, but at some point most people draw a line based on pragmatism. Also, often overlooked, there is the aspect of a language mapping well to a given developer's brain. Different people are drawn to different languages for different reasons, including borderline-intangible ones where they just feel more "at home", which translates into tangible outcomes like productivity.
coldtea 12y ago
>It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Is that some law of nature, or merely a consequence in how we've designed languages thus far? A well designed type-infered statically typed language with a REPL/interpreter, a fast AOT compiler, an optional GC, good documentation and IDE support, and a big API library could work well for all kinds of domains, from scripts and websites, to network application servers and systems programming. Note also that the money we spend on language and tooling development are miniscule and laughable compared to the IT industry's size. When there have been some decent money involved we had good results. Namely: With SUN/Java we got the fastest, more mature VM out there, with very good GC and a ton of tooling available. With Javascript, we got V8/JSC/etc, that made the language 10-100x faster compared to the nineties. With MS, we got C#, a great language that can cover tons of ground for what its designed, modern, with a huge ecosystem of tools and APIs. And from Apple, we got the great Cocoa libs and Swift (still a work in progress but very promising).
- Udo 12y ago
  > Is that some law of nature, or merely a consequence in how we've designed languages thus far? It's a game of tradeoffs, same as everything else in nature, isn't it? I would rarely say that a given language's design or implementation is universally flawed, instead it's the result that comes out of a set of premises and decisions. Yes, some of them may be objectively bad, but mostly they are just decisions made to solve specific problems. In a way the whole point of my post was that languages don't primarily exist on a one-dimensional spectrum of "good" to "bad". They're optimized for different things. The assumption that given a list of possible decisions during language design you just have to select the right one every time is based on the fallacious premise that right and wrong are the actual choices you get. > A well designed type-infered statically typed language [...] ...and those are already some key decisions you made that reflect what's important to you personally. Every time you choose one of these properties, you open doors and close others behind you. While you may personally believe these are the minimum requirements which every "good" language absolutely must have, you should also recognize that you are doing exactly the same thing as every single language designer in history.
  - rtpg 12y ago
    >It's a game of tradeoffs I find that less and less true. The canonical example for me are abstract data types. They're pretty much free on a runtime level, enable clean code, and allow for more static checking. Basically a superpowered version of enums. I can't see any argument against having it in the language unless the express goal is to have no syntax (lisp).
    - Udo 12y ago
      Again, that's a personal preference, not a statement of fact. There is a cost associated with different type systems, and that cost can vary with the problem you are trying to solve. It's not that I argue against the benefits of having such a system in place, but you should be aware of the fact that this too might not represent the end-all-be-all for all programmers. One of the basic mistakes made here seems to be the notion "if programmers only _knew_ about the one true way of doing it, they'd all use the same language and tools, namely: mine".

by Udo 12y ago

elwell 12y ago

> This can't possibly work well. Not that I disagree, but could you elaborate your reasoning here?

Udo 12y ago
There are many decisions that influence language design, it's not just syntax. Differing decisions are made about runtime behavior, memory management, levels of abstraction, and the efficiency of idiomatic data structures. Even objectively, a good language to write an OS kernel in isn't necessarily equally well suited to, say, game development, or web development, or scientific computing. That doesn't mean there won't be heroic efforts to make a language work in every arena, but at some point most people draw a line based on pragmatism. Also, often overlooked, there is the aspect of a language mapping well to a given developer's brain. Different people are drawn to different languages for different reasons, including borderline-intangible ones where they just feel more "at home", which translates into tangible outcomes like productivity.

coldtea 12y ago

>It's a common reaction displayed by the proponent base of many languages, even here on HN, to advocate the use of their language for every conceivable need. This can't possibly work well. Is that some law of nature, or merely a consequence in how we've designed languages thus far? A well designed type-infered statically typed language with a REPL/interpreter, a fast AOT compiler, an optional GC, good documentation and IDE support, and a big API library could work well for all kinds of domains, from scripts and websites, to network application servers and systems programming. Note also that the money we spend on language and tooling development are miniscule and laughable compared to the IT industry's size. When there have been some decent money involved we had good results. Namely: With SUN/Java we got the fastest, more mature VM out there, with very good GC and a ton of tooling available. With Javascript, we got V8/JSC/etc, that made the language 10-100x faster compared to the nineties. With MS, we got C#, a great language that can cover tons of ground for what its designed, modern, with a huge ecosystem of tools and APIs. And from Apple, we got the great Cocoa libs and Swift (still a work in progress but very promising).

Udo 12y ago
> Is that some law of nature, or merely a consequence in how we've designed languages thus far? It's a game of tradeoffs, same as everything else in nature, isn't it? I would rarely say that a given language's design or implementation is universally flawed, instead it's the result that comes out of a set of premises and decisions. Yes, some of them may be objectively bad, but mostly they are just decisions made to solve specific problems. In a way the whole point of my post was that languages don't primarily exist on a one-dimensional spectrum of "good" to "bad". They're optimized for different things. The assumption that given a list of possible decisions during language design you just have to select the right one every time is based on the fallacious premise that right and wrong are the actual choices you get. > A well designed type-infered statically typed language [...] ...and those are already some key decisions you made that reflect what's important to you personally. Every time you choose one of these properties, you open doors and close others behind you. While you may personally believe these are the minimum requirements which every "good" language absolutely must have, you should also recognize that you are doing exactly the same thing as every single language designer in history.
- rtpg 12y ago
  >It's a game of tradeoffs I find that less and less true. The canonical example for me are abstract data types. They're pretty much free on a runtime level, enable clean code, and allow for more static checking. Basically a superpowered version of enums. I can't see any argument against having it in the language unless the express goal is to have no syntax (lisp).
  - Udo 12y ago
    Again, that's a personal preference, not a statement of fact. There is a cost associated with different type systems, and that cost can vary with the problem you are trying to solve. It's not that I argue against the benefits of having such a system in place, but you should be aware of the fact that this too might not represent the end-all-be-all for all programmers. One of the basic mistakes made here seems to be the notion "if programmers only _knew_ about the one true way of doing it, they'd all use the same language and tools, namely: mine".