Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JavaScript Problem

haskell.org

Post reply on HN
Print view View original

91–100 of 183 posts

Re: The JavaScript Problem

#91

Post by gordaco »

wyager wrote: post #29
briantakita wrote: post #23

I accept that I will be downvoted for this. My impression of the Haskell community is its full of snobbery and complaining. This has got to be the 4th javascript ducks post on hn in the past week. I like hearing the positive aspects of Haskell. However, the language x sucks posts are tiresome. Develop an imagination. Javascript can be wielded very effectively. It's just different. I hope that I or someone else wires…

>My impression of the Haskell community is its full of snobbery and complaining. Probably because the Haskell community is used to having a programming language that is, in and of itself, very good. They complain because they know what they're missing when they have to use inferior tools. >Develop an imagination. Javascript can be wielded very effectively. It's just different. The same can be said of x86 assembly. Th…

>>I feel liberated by not having a strong type system restricting my options.

>If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.

I'm always baffled about how people say that using a dynamic language feels "liberating". I feel completely the opposite; I have to be extremely more careful with a dynamic language since either there is no compiler or it can't detect many errors, so I have to do it myself (because, and this is a very important lesson for absolutely everyone without exceptions: you will commit mistakes, no matter how good you are or how good you think you are). Getting rid of static typing feels to me like, above all, getting rid of a lot of very useful guarantees.

Re: The JavaScript Problem

#92

Post by pingec »

camus2 wrote: post #71
girvo wrote: post #10

I've been trying to convince my workmates to try something other than pure JS (with Angular), but am not having much luck. TypeScript seems to have the most buy-in, but most of the guys in the office aren't convinced of the benefits of a proper type system, the just see it as more work for them for little upside. Any ideas?

Typescript is hard. It's module system is a mistake(it should be module system agnostic,not AMD or CommonJS),and very confusing. The biggest problem is javascript is so dynamic you cant create type definitions for every library outthere and expect the typesystem to work. Typescript is good if you are porting something from AS3/C#/Java to javascript,or if You want to model a complex domain,without touching the DOM api…

I could not agree less with your post. I ported a 12k loc JS project to TS and it usese JQuery heaviliy. The result was that the static type system could point out 6 bugs from my original code that unit tests did not find and now I have statement completion and powerful refactoring tools for everything as well. It plays really nice with JQuery if you have the right type declarations and I am more productive now with all the code intellisense I get from the IDE.

Also the module system is module system agnostic and it can compile either to commonjs or amd, it depends on a compiler switch. I am using mostly requirejs and it works well.

Re: The JavaScript Problem

#93

Post by [deleted] »

Swizec wrote: post #34
jurassic wrote: post #31

The people who hate javascript the most are the ones who wish it was something else. I used to be one of those people. Once I decided to accept it as it is and read a few top books on the language to learn the "javascript way", my life got a lot better. It's really not that bad. I actually like it a lot, but there are still a lot of ignorant people who will look at you as if you're not l33t enough to know that foo la…

Javascript's real problem is unfamiliar semantics hidden behind familiar syntax. It throws people off and they hate the language because they think it's weird. Really, they just haven't learned how to actually use it.

[deleted]

Re: The JavaScript Problem

#94

Post by SiVal »

bratsche wrote: post #58
jmspring wrote: post #41

Earlier quoted context omitted.

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

Why do you care what the target of the compile is if you're happy with the language you're writing in? That seems like being upset that some code you wrote in a language you like might be running on some processor you don't like.

because it's inevitably a leaky abstraction

Re: The JavaScript Problem

#95

Post by Kiro »

Peaker wrote: post #72
jurassic wrote: post #31

The people who hate javascript the most are the ones who wish it was something else. I used to be one of those people. Once I decided to accept it as it is and read a few top books on the language to learn the "javascript way", my life got a lot better. It's really not that bad. I actually like it a lot, but there are still a lot of ignorant people who will look at you as if you're not l33t enough to know that foo la…

IMO the biggest problem, even worse than type coercions, is the error silencing regarding wrong argument counts. This can easily hide so many bugs, it's amazing it is acceptable to anyone.

Do you have an example?

Re: The JavaScript Problem

#96

Post by Kiro »

copergi wrote: post #60
djur wrote: post #53

Earlier quoted context omitted.

It's sad that we should expect Haskell users to be chauvinistic about static typing. I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw".

>It's sad that we should expect Haskell users to be chauvinistic about static typing. We don't expect that. We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way. >I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw". Try looking on the internet. Every "static vs dynamic" argument has 99% of the…

You just proved djur's point.

Re: The JavaScript Problem

#97

Post by Kiro »

I'm surprised that lack of module system is the first thing brought up. Is that really such a big deal? It's very much just a nice to have for me and has plenty of third-party implementations if you want it.

Re: The JavaScript Problem

#98

Post by flohofwoe »

AnthonyMouse wrote: post #62
jmspring wrote: post #41

Earlier quoted context omitted.

Browsers should not be multi-lingual -- more bloat. The "compile X to javascript" movement has things half right. Unfortunately the "compile to" is Javascript. I wish the language the browsers implemented was something more modern, strong typing, etc. But I am not sure that will happen.

The issue is that the "compile to" thing shouldn't be another programming language at all. It should be something like Java bytecode. Except not actually Java bytecode, because Java bytecode was made specifically for Java. You want something designed to be an intermediary representation between code in any arbitrary language and native instructions for any arbitrary architecture. In theory you could use Javascript as…

As an example, Portable Native Client is "proper byte code" (simplified LLVM IR), but client-side compilation takes multiple times longer then AOT-compiling the same code from asm.js (the NaCl team is working hard on improving this though). The download size is also almost the same (if compressed). Performance isn't that much better either, so for every practical purpose "real" byte code isn't automatically better then sending (compiled and compressed) "source code" over the wire.

I'm even getting worse startup times for a "cold start" for the same code compiled to native OSX then for starting the same demo as emscripten version, (presumably because the native version first needs to load a lot of DLLs).

Re: The JavaScript Problem

#99

Post by [deleted] »

auvrw wrote: post #87
camus2 wrote: post #66

Earlier quoted context omitted.

clojurescript depends on the JVM.this is a no go for me.Once a cjs compiler is implemented in javascript and can run on nodejs,then maybe i will consider it.

wouldn't it make more sense to implement the clojurescript compiler in clojurescript so it can run on node? i get disliking having to fire up the jvm versus a light runtime like python or node if that's where you're coming from, but i don't mind twiddling my thumbs for a moment when i first sit down to write clojure, because not just the language but also the libraries and tools are more fun/interesting to use than a…

[deleted]

Re: The JavaScript Problem

#100

Post by Peaker »

Kiro wrote: post #95
Peaker wrote: post #72

Earlier quoted context omitted.

IMO the biggest problem, even worse than type coercions, is the error silencing regarding wrong argument counts. This can easily hide so many bugs, it's amazing it is acceptable to anyone.

Do you have an example?

Call a function "foo" that expects 3 arguments with 5 or 2 arguments, instead.

Javascript will gladly accept that and not yield any error, not just at compile-time, but even at run-time!

Unless the function explicitly checks that the argument list is correct, it will simply hide the bug.

When changing function signatures in any language, it is the programmers' collective responsibility to fix all callers (some of which in the same working tree, some hidden in others' branches, etc). In a static-language, it is very easy, you get compile-time errors at some point. In dynamically typed languages, it is slightly harder -- you get an error (ideally under a test suite) and fix it there. In Javascript you get cryptic bugs. No compile-time error. No run-time error. Happy debugging!

Post reply on HN