The JavaScript Problem • Hacker News Board

Re: The JavaScript Problem

#131

Post by copergi » Sun, Apr 27, 2014, 2:51 PM UTC

BugBrother wrote: post #106

gordaco wrote: post #91

Earlier quoted context omitted.

>>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 languag…

This is why unit testing took over the dynamic language world more than a decade ago. And at least in Perl, which have a bit of extensible syntax, you can declare parameter types of methods/functions. That is especially a good idea for external APIs to libraries, etc. All tools have quirks, which forces a bit of change in how you use them. You have to look at the total sum of these effects. How much extra days will i…

>This is why unit testing took over the dynamic language world more than a decade ago.

So you have to spend a ton of time writing redundant and in-exhaustive tests to work around the lack of a type system, but the complaint leveled against having a type system is that "satisfying the type checker takes too long"?

Re: The JavaScript Problem

#132

Post by teacup50 » Sun, Apr 27, 2014, 2:53 PM UTC

jkrems wrote: post #84

copergi wrote: post #60

Earlier quoted context omitted.

>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…

> We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way. Obvious - because you just said "with better defined as has more static typing, static typing is better". That's an empty statement if I ever saw one.

That it's better to accurately and reliably modeling complex systems and invariants through provable assertions is objectively is no more an empty statement than to say that it's better to apply informed materials and structural engineering to the design of complex physical products than to build ad-hoc designs of unknown parameters through guesswork.

Re: The JavaScript Problem

#133

Post by implicit » Sun, Apr 27, 2014, 3:09 PM UTC

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?

Guess the result of this fragment:

    ["1", "2", "3"].map(parseInt)

Re: The JavaScript Problem

#134

Post by somebehemoth » Sun, Apr 27, 2014, 3:43 PM UTC

teacup50 wrote: post #130

somebehemoth wrote: post #127

Earlier quoted context omitted.

Bold claims and strong language do not make up for a lack of citations. You prefer static typing because you admit it is the only hope you have of understanding your complex code. However you dismiss other peoples' preferences by claiming they are ignorant of the systems they are building. Are you, perhaps, the one true Scotsman?

It's not possible for anyone to build complex software in a unityped language while having a full, complete, and verifiable understanding of their own system invariants at any given moment. Claims otherwise are the literal equivalent of making complex mathematical assertions without a single condensed proof . This isn't opinion, any more than a formal proof is opinion.

You are making an opinion as to the definition of complex software. "Complex software" means different things to different people. Additionally, you've inserted a requirement of understanding one's systems that seems arbitrary and not universally applicable. Whatever happened to each his own?

Re: The JavaScript Problem

#135

Post by chrisdone » Sun, Apr 27, 2014, 3:54 PM UTC

masswerk wrote: post #107

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…

Just upvoted the post, sorry. ;-) These rants really seem to be based on the degree of respect some languages are enjoying in a certain community. Take weak typing / type coercion for an example: This is a common feature of scripting languages of the time, e.g.: Perl. I never read Perl being complained on for the same issue, which might well be, because it is a "serious" system language and because you might have to…

Horses are okay, but they're expensive, require much more maintenance, can only go about 40mph for a brief period of time, and can only seat two people, uncomfortably. And you're telling people who want to build roads to put cars on “why not just think in horses for a change?”

Re: The JavaScript Problem

#136

Post by chrisdone » Sun, Apr 27, 2014, 3:54 PM UTC

masswerk wrote: post #109

WoodenChair wrote: post #25

Earlier quoted context omitted.

Here's the problem with your post - and it has nothing to do with what you think it does. It attacks two things at once and quite distinctly. On one hand you're defending JavaScript - and that's separate from your attack on the Haskell community. It's just unfocused and confusingly conflated. I'm not going to down vote you, but you need to organize your thoughts a little more coherently if you don't want to get down…

But by doing so, the post marks a real problem: The critique of JS seems to be mostly based on the prestige the languages is enjoying -- or rather the lack thereof -- in a community. Any of those features is to be found in highly respected languages, too. Most of the rants are about respect and not being willing to respect the specifics of the language. Why has JS to be built to suit test suites and tool chains origi…

Nope. JS has technical problems which were all stated clearly and with references to academic works and industry examples (Google). You simply choose to ignore my carefully worded criticism calling it a “rant” and an “easy answer” and “à la mode”, with talk of irrelevant things like C/C++ and platitudes about Turing machines.

Re: The JavaScript Problem

#137

Post by chrisdone » Sun, Apr 27, 2014, 3:59 PM UTC

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…

This wiki page is 2 years old, I assure you the Haskell community settled this debate years ago and have moved on with our lives. We've since implemented a bunch of compilers to JavaScript. I suspect, rather, that you are criticizing the part of the HN community that submits links and those that upvote them.

For what it's worth, for someone calling people “snobbish” and “complaining”, it's quite rich to make a comment which is complaining and to say “develop an imagination.” :-)

Re: The JavaScript Problem

#138

Post by chrisdone » Sun, Apr 27, 2014, 4:04 PM UTC

hrktb wrote: post #57

The things that gave most of javascript quirks were auto comma insertion, this, and global variable declaration. It's the same as how HTML has horrible parts because from the start it bending backward to be as fault tolerant as implementable. That's why it succeeded and why a strong staticly typed language with very strict error enforcement wouldn't have made it in the first place. Some things are added bits by bits…

Using words like “sucks” is a bit of fun. Seeing obvious deficiencies in a language and putting up with it for years instead of doing some work and using a better one is childish.

Re: The JavaScript Problem

#139

Post by michaelsbradley » Sun, Apr 27, 2014, 4:05 PM UTC

jkrems wrote: post #86

michaelsbradley wrote: post #74

Earlier quoted context omitted.

Would you articulate why it's a "no go" for you? Leiningen[1] takes away 99.9% of the pain of having to work directly with javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-driven approach to compiling and testing. It's perfectly possible to create setups where node (plus grunt, gulp, shell scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I contributed such a setup[3…

Because if other parts of your stack don't depend on Java, you have the overhead of having to install a complete java environment (on dev machines, CI, ...) just for compiling your front-end code. It also makes "language independent" tooling for javascript harder. Then again: I guess most people who use clojurescript are already using clojure so it wouldn't be a problem for them.

Getting the JVM installed requires very little effort. On ubuntu linux, for example, apt-get can be used to install openjdk or Oracle's distribution. Travis CI provides java (with a choice of JDKs) in its testing environments.

So, I understand your point, but the installation "overhead" seems more like a mole hill, hardly amounting to even a speed-bump sized obstacle.

Re: The JavaScript Problem

#140

Post by chrisdone » Sun, Apr 27, 2014, 4:08 PM UTC

fiatmoney wrote: post #55

Clojurescript is an excellent solution to most of the problems mentioned. In particular, functional data structures & approaches are a great fit for coordinating dependent updates to a UI based on events happening to a base state - for a concrete example, the Om wrapper around React is very slick, performant, and idiomatic.

Really the only thing missing from Clojurescript, as all Lisps, is static types.