10 ms·

"The intrinsic smallness of the language can be alarming when you come from a bigger language (Ruby, Java)" Bad examples. Ruby and Java are small languages too

by nbevans 13y ago

"The intrinsic smallness of the language can be alarming when you come from a bigger language (Ruby, Java)" Bad examples. Ruby and Java are small languages too, just like JS. This immediately calls into question the credentials of the author. Not a good start. "Null everywhere Attempting to access a property of a JS object that’s not defined gives you… undefined. If it’s important to your program that you know about this: write some code." Or just, you know, use a better language? "‘Callback hell’ isn’t a problem for people who’ve written a lot of JS." So that makes it okay then? It's just another article written by someone so immersed in their own little world that they can't see the wood for the trees. The author probably thinks he has put together a nice a little counter-attack to that "other" article; but really he has just reinforced it.

timruffles 13y ago
Actually Ruby and Java are both large languages compared to JS. Ruby especially - compare its object system with Javascript's, or consider it has 3 flavours of lambda ;) Nice to take 2 quotes out of context of their explanations. And finally, I've written a heap of Ruby, Python & AS3 and enough Clojure, Haskell and Go to be able to say: Javascript is a great little language. We use it because of history, sure, but learn how to use it before bashing it. p.s http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html
- tel 13y ago
  Javascript suffers the curse of popularity in spades. Most of its users today do not use it as a language at all, but instead as very light mechanism for getting a web browser to do weird things. Using Javascript as a language isn't bad and I think that's worth talking about. Especially since putting more effort there may let Javascript take advantage of some of its popularity. Javascript is definitely microscopic compared to Ruby or Java. Lua, Smalltalk, Scheme have it handily beat on size, though. Furthermore, Haskell is absolutely lightyears ahead of Javascript in semantic niceness, but it succeeds there by being a much larger language, so YMMV.
- blueblob 13y ago
  I cannot comment on Ruby. I, personally, think Java is a much bigger language than (base without other scripts included) Javascript. Of the two, I prefer Java for it's strong types. My biggest problem with Javascript is that if I make a typo on a variable name, it can be very difficult to debug. This could perhaps be mitigated by using an IDE, I don't know since I don't use JS that often. I feel like this is not a major issue and work on LLVM+emscripten will let me work in almost whatever language I want and have it end up in Javascript in the near future.
  - candydance 13y ago
    Why do you think Java is bigger? From my perspective, Java has, effectively, structs (well defined groups of data) and a few primitive types, and a class system which is dead simple. It's tiny, comparable to Lua imo. It's more restrictive, sure, but the dynamic-ness of Javascript is a hindrance when it comes to language spec because the base language functions need to be able to interpret all the different primitive types. There's stacks and stacks of corner cases to remember while Java just says "Nope, wrong type".
    - Touche 13y ago
      But all of those things you listed are very different things. In JavaScript they are the same thing.
      - candydance 13y ago
        Please expand your response, I don't understand what you mean when you say they are "the same thing".
        Touche 13y ago
        Just a couple of examples. Arrays and Objects are the same type of structure in JavaScript. Arrays just happen to be indexed by integers and Objects by strings. In Java this is not the case. Another example, in Java Classes are not objects that can be manipulated, they require a special form (generics) for that. In JavaScript a "class" is just a function that has some default properties attached.
- nbevans 13y ago
  Are you the author? The whole article just seems to be missing the point entirely. It pretty much answers everything with "oh but you can write a hack to work around that" or "oh there is some library you can use that plugs that gap". Whilst yes, these may be viable "solutions" for hacking something out. It doesn't refute the claim by the original article that JS is a bad language. It actually just reinforces it with yet more examples. The only positives to take away from the article are where it highlights features coming in ES6 to actually solve some of the problems. But these admissions seem to contradict the premise of the article.
  - timruffles 13y ago
    Yes. No I'm not missing the point: I show how, within a few lines, these 'missing features' disappear. e.g: constants, type annotations, objects as keys. Adding a whole language feature to save a few lines of code - not to my taste. You don't need a new language feature to express an idea if it can be trivially expressed in the language as it stands.
    - nbevans 13y ago
      I didn't like the constants solution for nulls. Why not use a Maybe monad? I'm surprised that you didn't considering your claimed language experience. I guess I just don't agree with your fundamental position on this. That writing yet more code to workaround a bad language is in anyway a long-term solution. At some point you'll want to bring more devs onto your team and then you'll need to explain all this technical debt and hacks to them. Not good. I still believe you're missing the point of the original article you were refuting. It's not about being able to workaround something. It's about not needing to workaround flaws in the language in the first place. That's what defines a good language. Further reading for you (unordered): 1. http://www.codinghorror.com/blog/2007/05/the-best-code-is-no-code-at-all.html http://www.codinghorror.com/blog/2007/05/the-best-code-is-no... 2. "The line of code you don’t write is the line of code you never have to debug." -- Steve Jobs 3. Mythical Man Month (a book)
      - timruffles 13y ago
Swizec 13y ago
What exactly is the distinction between a big and a small language? If you ask me everything looks big compared to Brainfuck or a queue machine.
- tel 13y ago
  I'd think there is a reasonably good metric in there around approximating Kolgomorov Complexity: "What is the size of the shortest written description of the entire spec of a language?" This completely discounts expressivity, of course, so perhaps a related measure would be, given a suitably complex and representative programming task "What is the size of the shortest written description of the entire spec of a language plus the shortest program in that language that solves said problem." None of these things exist nor can be computed. They also still ignore readability (something very important and for which Brainfuck would likely fail), but I would wager a reasonable consensus could be built around the concepts.
- deleted 13y ago
  [deleted]
- Touche 13y ago
  For example in JavaScript you can easily write your own version of new. JavaScript is a just a "bag of properties" and everything else follows from that. Very very rarely do you run into something in the language that breaks that expectation.
scrabble 13y ago
"‘Callback hell’ isn’t a problem for people who’ve written a lot of JS." So that makes it okay then? I don't know of any language that makes it impossible to write bad code, do you? JavaScript is a great language, but it's one that's been full of problems as well. It's great because people who traditionally aren't developers can get some JS snippet running to add something dynamic to a site, but at the same time if you are a developer who has spent time learning the language then you can do a lot more with it. There are also alternatives to callback hell. I do take the method of naming functions instead of using a large number of anonymous functions. It helps significantly. If you prefer, you can easily use promises instead. That's been another effective approach. I've never written any Ruby and can't speak to the comparison at all, but if it's a language that makes it impossible to produce bad code when you don't know the language and its idioms well then it's something I need to be learning.
- chewxy 13y ago
  No, but there are languages that make it hard to write bad code. Go, Erlang, heck, even Python comes to mind.
  - tel 13y ago
    I feel like making it hard to write code tend to correlate with making it hard to write bad code. This is a problem since many programmers do not like languages which make it hard for them to write code. I'm not sure whether it's the effect of "making it hard to write bad code" that makes it hard to write code or whether its "making it hard to write code" that makes you less likely to run into the effects of bad programmers.
    - cuttle 13y ago
      Some people might consider Erlang a puzzle language, but Python and Go most definitely do not make it hard to write code.
      - tel 13y ago
deleted 13y ago
[deleted]

by nbevans 13y ago

timruffles 13y ago

Actually Ruby and Java are both large languages compared to JS. Ruby especially - compare its object system with Javascript's, or consider it has 3 flavours of lambda ;) Nice to take 2 quotes out of context of their explanations. And finally, I've written a heap of Ruby, Python & AS3 and enough Clojure, Haskell and Go to be able to say: Javascript is a great little language. We use it because of history, sure, but learn how to use it before bashing it. p.s http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html

tel 13y ago
Javascript suffers the curse of popularity in spades. Most of its users today do not use it as a language at all, but instead as very light mechanism for getting a web browser to do weird things. Using Javascript as a language isn't bad and I think that's worth talking about. Especially since putting more effort there may let Javascript take advantage of some of its popularity. Javascript is definitely microscopic compared to Ruby or Java. Lua, Smalltalk, Scheme have it handily beat on size, though. Furthermore, Haskell is absolutely lightyears ahead of Javascript in semantic niceness, but it succeeds there by being a much larger language, so YMMV.
blueblob 13y ago
I cannot comment on Ruby. I, personally, think Java is a much bigger language than (base without other scripts included) Javascript. Of the two, I prefer Java for it's strong types. My biggest problem with Javascript is that if I make a typo on a variable name, it can be very difficult to debug. This could perhaps be mitigated by using an IDE, I don't know since I don't use JS that often. I feel like this is not a major issue and work on LLVM+emscripten will let me work in almost whatever language I want and have it end up in Javascript in the near future.
- candydance 13y ago
  Why do you think Java is bigger? From my perspective, Java has, effectively, structs (well defined groups of data) and a few primitive types, and a class system which is dead simple. It's tiny, comparable to Lua imo. It's more restrictive, sure, but the dynamic-ness of Javascript is a hindrance when it comes to language spec because the base language functions need to be able to interpret all the different primitive types. There's stacks and stacks of corner cases to remember while Java just says "Nope, wrong type".
  - Touche 13y ago
    But all of those things you listed are very different things. In JavaScript they are the same thing.
    - candydance 13y ago
      Please expand your response, I don't understand what you mean when you say they are "the same thing".
      - Touche 13y ago
        Just a couple of examples. Arrays and Objects are the same type of structure in JavaScript. Arrays just happen to be indexed by integers and Objects by strings. In Java this is not the case. Another example, in Java Classes are not objects that can be manipulated, they require a special form (generics) for that. In JavaScript a "class" is just a function that has some default properties attached.
nbevans 13y ago
Are you the author? The whole article just seems to be missing the point entirely. It pretty much answers everything with "oh but you can write a hack to work around that" or "oh there is some library you can use that plugs that gap". Whilst yes, these may be viable "solutions" for hacking something out. It doesn't refute the claim by the original article that JS is a bad language. It actually just reinforces it with yet more examples. The only positives to take away from the article are where it highlights features coming in ES6 to actually solve some of the problems. But these admissions seem to contradict the premise of the article.
- timruffles 13y ago
  Yes. No I'm not missing the point: I show how, within a few lines, these 'missing features' disappear. e.g: constants, type annotations, objects as keys. Adding a whole language feature to save a few lines of code - not to my taste. You don't need a new language feature to express an idea if it can be trivially expressed in the language as it stands.
  - nbevans 13y ago
    I didn't like the constants solution for nulls. Why not use a Maybe monad? I'm surprised that you didn't considering your claimed language experience. I guess I just don't agree with your fundamental position on this. That writing yet more code to workaround a bad language is in anyway a long-term solution. At some point you'll want to bring more devs onto your team and then you'll need to explain all this technical debt and hacks to them. Not good. I still believe you're missing the point of the original article you were refuting. It's not about being able to workaround something. It's about not needing to workaround flaws in the language in the first place. That's what defines a good language. Further reading for you (unordered): 1. http://www.codinghorror.com/blog/2007/05/the-best-code-is-no-code-at-all.html http://www.codinghorror.com/blog/2007/05/the-best-code-is-no... 2. "The line of code you don’t write is the line of code you never have to debug." -- Steve Jobs 3. Mythical Man Month (a book)
    - timruffles 13y ago

Swizec 13y ago

What exactly is the distinction between a big and a small language? If you ask me everything looks big compared to Brainfuck or a queue machine.

tel 13y ago
I'd think there is a reasonably good metric in there around approximating Kolgomorov Complexity: "What is the size of the shortest written description of the entire spec of a language?" This completely discounts expressivity, of course, so perhaps a related measure would be, given a suitably complex and representative programming task "What is the size of the shortest written description of the entire spec of a language plus the shortest program in that language that solves said problem." None of these things exist nor can be computed. They also still ignore readability (something very important and for which Brainfuck would likely fail), but I would wager a reasonable consensus could be built around the concepts.
deleted 13y ago
[deleted]
Touche 13y ago
For example in JavaScript you can easily write your own version of new. JavaScript is a just a "bag of properties" and everything else follows from that. Very very rarely do you run into something in the language that breaks that expectation.

scrabble 13y ago

"‘Callback hell’ isn’t a problem for people who’ve written a lot of JS." So that makes it okay then? I don't know of any language that makes it impossible to write bad code, do you? JavaScript is a great language, but it's one that's been full of problems as well. It's great because people who traditionally aren't developers can get some JS snippet running to add something dynamic to a site, but at the same time if you are a developer who has spent time learning the language then you can do a lot more with it. There are also alternatives to callback hell. I do take the method of naming functions instead of using a large number of anonymous functions. It helps significantly. If you prefer, you can easily use promises instead. That's been another effective approach. I've never written any Ruby and can't speak to the comparison at all, but if it's a language that makes it impossible to produce bad code when you don't know the language and its idioms well then it's something I need to be learning.

chewxy 13y ago
No, but there are languages that make it hard to write bad code. Go, Erlang, heck, even Python comes to mind.
- tel 13y ago
  I feel like making it hard to write code tend to correlate with making it hard to write bad code. This is a problem since many programmers do not like languages which make it hard for them to write code. I'm not sure whether it's the effect of "making it hard to write bad code" that makes it hard to write code or whether its "making it hard to write code" that makes you less likely to run into the effects of bad programmers.
  - cuttle 13y ago
    Some people might consider Erlang a puzzle language, but Python and Go most definitely do not make it hard to write code.
    - tel 13y ago

deleted 13y ago

[deleted]