3 ms·

Out of all the dynamically typed scripting languages, I prefer JavaScript. Is there something horribly wrong with me? Linguistically, my second choice would be

by mbrock 9y ago

Out of all the dynamically typed scripting languages, I prefer JavaScript. Is there something horribly wrong with me? Linguistically, my second choice would be Scheme, but I still find JavaScript to be more ergonomic for most tasks. It's also way more familiar to more people, obviously, so I think it's a totally reasonable choice for a lot of tasks.

simias 9y ago
I think Javascript is not as fundamentally unsound as, say, PHP. You can see that it was designed by people who had a clue about how languages are supposed to work. The big problem with Javascript is that conceptually it's closer to a functional language than C or Java, yet it opted for a C-style syntax with a bunch of hacks (semicolon insertion being arguably the biggest) so I find that its syntax doesn't really match the way it's used and you end up with rather clumsy looking code even for very idiomatic constructs. Not to mention the super weird type conversions. But that's rather subjective, IMO the biggest problem is simply the lack of a comprehensive standard library even for basic things. I'm not really a webdev but I have to maintain a web interface for one of our products, it uses JQuery, underscore.js and d3.js for various things. There's a significant overlap between these libraries when it comes to standards algorithms and DOM manipulation so you have to learn two or three ways to do the same thing depending on the situation. I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Coding in JS feels like coding in C if it was standardized without stdio.h and string.h. Have fun re-implementing strcat every time you need it.
- throwanem 9y ago
  > I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Been a while since you did need. document.querySelector and .querySelectorAll are everything about jQuery that's worth having, and every browser has implemented them for years. Arrays have a map method that does what you expect it should, although do be aware of the odd calling convention. Objects don't map natively, but their keys do, which I very rarely find fails to suffice. (And for those things that really can't be expressed in stdlib without considerable reinvention, Lodash is a strictly better Underscore.)
  - always_good 9y ago
    It's just a reminder of how incredibly outdated the intel is from HNers weighing in on Javascript in a negative light.
    - simias 9y ago
      I explicitly mentioned that I wasn't a webdev, I never pretended I was some kind of authority about JS. I maintain my point though, so far most sizeable JS projects I've seen depend on JQuery for one reason or an other, so clearly even competent JS coders feel the need to supplement the functionality of the standard library. As for the built in map, the fact that you can't use it on objects is the reason I ended up requiring underscore.js (alongside with the .find and .uniq methods, and probably a few others). I could also have mentioned how hacky and messy it becomes if you decide to split your JS project in multiple files. Or the hack to create "modules", which is at the same time very clever and pretty terrifying.
      - always_good 9y ago
        But you're also conflating server-side and client-side (jQuery) Javascript. Client-side applications have baggage (infinite deploy targets) that you don't have with server-side applications (one deploy target), so the comparison is disingenuous.
        simias 9y ago
        I see your point but that's not really what I meant. I wanted to say that server-side JS is a direct consequence of client-side JS. If Javascript had stopped being a thing in browsers do you really think Node.js would've gained significant traction despite the numerous alternatives? As far as I can tell the main selling point of Node is that you can use the same technology on both ends and even share some code. If you remove this from consideration then Node competes against Python, Ruby, Perl, PHP... And it's not clear how it's better than these.
        9y ago
- Sacho 9y ago
  I don't think you can find the stuff d3.js does in many standard libraries. The things in jQuery and underscore have gradually entered the JS standard lib, I think your information is outdated. > Coding in JS feels like coding in C if it was standardized without stdio.h and string.h. Have fun re-implementing strcat every time you need it. That's a really bad example, stdio.h and string.h are notoriously horrible. Should I use strcpy? That can cause buffer overflows. Maybe I should use strncpy then? Oops, that's a buffer copy function, not a string function(it can result in non-strings)[1]. What about strcat and strncat? Well, strncat actually appends a null character, so you have to keep that in mind. How do I even use gets, getchar, fscanf properly? Here's a compilation of coding standards and pitfalls, many of which involve the standard library https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard https://www.securecoding.cert.org/confluence/display/c/SEI+C... [1] https://www.approxion.com/?p=2565 https://www.approxion.com/?p=2565
- mbrock 9y ago
  I think a big standard library is a tradeoff question, but also, the standard available functionality is something I really like about Node. It's got map, filter, reduce, just like all modern browsers, and it's also got nice and easy builtins for JSON parsing/dumping, HTTP serving, regular expressions, etc. And still the stdlib isn't bloated with lots of weird stuff, it's kind of nicely minimal. Not perfect at all, but in a pragmatic sense it's often very satisfactory. My real favorite language is Haskell, and that language is also both loved and hated, and one of the problems with it is the standard library. There's no regexps, no HTTP serving, no JSON, hell, people even import external dependencies to get convenient records. I'm kind of cynical and picky but tell me a language and I will give you a litany of horrible problems with it—really. Go's type system is stupid; Rust's compiler is slow and it's hard to learn; C is unsafe and has undefined behavior; C++ is a mess; Ruby is full of monkey patching; OCaml's syntax is idiosyncratic; Haskell has problems with laziness, records, the proliferation of language extension, an "im very smart" community, etc; Smalltalk is Unix-hostile and insular; Common Lisp is too mutable; Scheme is too fragmented; and so on and so on and so on. So I think of choosing a programming language as answering the question "Which horrible nightmare seems least awful for the particular thing I want to do right now?" and JavaScript is, for me, quite often a reasonable answer.
mcgarnagle 9y ago
First choice is prefer javascript and second choice is scheme? Can confirm something is wrong with you. Trust me, I'm from the internet. Is this the order you learned programming languages in or something?
- mbrock 9y ago
  Quick, what's the syntax for updating a hash table in Scheme? "Well, it depends on if you mean SRFI-44 maps, SRFI-69 hash tables, R6RS hash tables, Racket hash tables, MIT hash tables, Scheme-48 hash tables, or . . ."

by mbrock 9y ago

simias 9y ago

I think Javascript is not as fundamentally unsound as, say, PHP. You can see that it was designed by people who had a clue about how languages are supposed to work. The big problem with Javascript is that conceptually it's closer to a functional language than C or Java, yet it opted for a C-style syntax with a bunch of hacks (semicolon insertion being arguably the biggest) so I find that its syntax doesn't really match the way it's used and you end up with rather clumsy looking code even for very idiomatic constructs. Not to mention the super weird type conversions. But that's rather subjective, IMO the biggest problem is simply the lack of a comprehensive standard library even for basic things. I'm not really a webdev but I have to maintain a web interface for one of our products, it uses JQuery, underscore.js and d3.js for various things. There's a significant overlap between these libraries when it comes to standards algorithms and DOM manipulation so you have to learn two or three ways to do the same thing depending on the situation. I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Coding in JS feels like coding in C if it was standardized without stdio.h and string.h. Have fun re-implementing strcat every time you need it.

throwanem 9y ago
> I shouldn't need external dependencies to have access to underscore.js's "map" or JQuery selectors. Been a while since you did need. document.querySelector and .querySelectorAll are everything about jQuery that's worth having, and every browser has implemented them for years. Arrays have a map method that does what you expect it should, although do be aware of the odd calling convention. Objects don't map natively, but their keys do, which I very rarely find fails to suffice. (And for those things that really can't be expressed in stdlib without considerable reinvention, Lodash is a strictly better Underscore.)
- always_good 9y ago
  It's just a reminder of how incredibly outdated the intel is from HNers weighing in on Javascript in a negative light.
  - simias 9y ago
    I explicitly mentioned that I wasn't a webdev, I never pretended I was some kind of authority about JS. I maintain my point though, so far most sizeable JS projects I've seen depend on JQuery for one reason or an other, so clearly even competent JS coders feel the need to supplement the functionality of the standard library. As for the built in map, the fact that you can't use it on objects is the reason I ended up requiring underscore.js (alongside with the .find and .uniq methods, and probably a few others). I could also have mentioned how hacky and messy it becomes if you decide to split your JS project in multiple files. Or the hack to create "modules", which is at the same time very clever and pretty terrifying.
    - always_good 9y ago
      But you're also conflating server-side and client-side (jQuery) Javascript. Client-side applications have baggage (infinite deploy targets) that you don't have with server-side applications (one deploy target), so the comparison is disingenuous.
      - simias 9y ago
        I see your point but that's not really what I meant. I wanted to say that server-side JS is a direct consequence of client-side JS. If Javascript had stopped being a thing in browsers do you really think Node.js would've gained significant traction despite the numerous alternatives? As far as I can tell the main selling point of Node is that you can use the same technology on both ends and even share some code. If you remove this from consideration then Node competes against Python, Ruby, Perl, PHP... And it's not clear how it's better than these.
        9y ago
Sacho 9y ago
I don't think you can find the stuff d3.js does in many standard libraries. The things in jQuery and underscore have gradually entered the JS standard lib, I think your information is outdated. > Coding in JS feels like coding in C if it was standardized without stdio.h and string.h. Have fun re-implementing strcat every time you need it. That's a really bad example, stdio.h and string.h are notoriously horrible. Should I use strcpy? That can cause buffer overflows. Maybe I should use strncpy then? Oops, that's a buffer copy function, not a string function(it can result in non-strings)[1]. What about strcat and strncat? Well, strncat actually appends a null character, so you have to keep that in mind. How do I even use gets, getchar, fscanf properly? Here's a compilation of coding standards and pitfalls, many of which involve the standard library https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard https://www.securecoding.cert.org/confluence/display/c/SEI+C... [1] https://www.approxion.com/?p=2565 https://www.approxion.com/?p=2565
mbrock 9y ago
I think a big standard library is a tradeoff question, but also, the standard available functionality is something I really like about Node. It's got map, filter, reduce, just like all modern browsers, and it's also got nice and easy builtins for JSON parsing/dumping, HTTP serving, regular expressions, etc. And still the stdlib isn't bloated with lots of weird stuff, it's kind of nicely minimal. Not perfect at all, but in a pragmatic sense it's often very satisfactory. My real favorite language is Haskell, and that language is also both loved and hated, and one of the problems with it is the standard library. There's no regexps, no HTTP serving, no JSON, hell, people even import external dependencies to get convenient records. I'm kind of cynical and picky but tell me a language and I will give you a litany of horrible problems with it—really. Go's type system is stupid; Rust's compiler is slow and it's hard to learn; C is unsafe and has undefined behavior; C++ is a mess; Ruby is full of monkey patching; OCaml's syntax is idiosyncratic; Haskell has problems with laziness, records, the proliferation of language extension, an "im very smart" community, etc; Smalltalk is Unix-hostile and insular; Common Lisp is too mutable; Scheme is too fragmented; and so on and so on and so on. So I think of choosing a programming language as answering the question "Which horrible nightmare seems least awful for the particular thing I want to do right now?" and JavaScript is, for me, quite often a reasonable answer.

mcgarnagle 9y ago

First choice is prefer javascript and second choice is scheme? Can confirm something is wrong with you. Trust me, I'm from the internet. Is this the order you learned programming languages in or something?

mbrock 9y ago
Quick, what's the syntax for updating a hash table in Scheme? "Well, it depends on if you mean SRFI-44 maps, SRFI-69 hash tables, R6RS hash tables, Racket hash tables, MIT hash tables, Scheme-48 hash tables, or . . ."