Live data from Hacker News

The JavaScript Problem

haskell.org

51–60 of 183 posts

Re: The JavaScript Problem

#52

I take issue with the paragraph about how Javascript sucks: * Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types) and I don't see that as a problem. * Being an entirely interpreted language, JS cannot have static type checking. This has not been an issue in my experience. * I think the syntax argument is laughably ridiculous. Programming languages that live…

> Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types) and I don't see that as a problem.

That's not what any of that means.

"No type declarations" only means just that. Haskell has no obligatory type declarations due to global type inference and nobody is calling Haskell untyped.

Untyped means untyped. None of the APIs or code are built around types, structurally or by name. It's just a one big union type of possible JavaScript values all over the place even if that's not what you meant when you wrote the function.

Being interpreted has nothing to do with type-checking. Haskell's REPL is an interpreter. Using a library (Hint) you can eval arbitrary Haskell from strings in a type-safe manner.

You can even parse arbitrary data from strings in a type-safe manner without resorting to an interpreter:

    -- throws error
    read "blah" :: Int 

    -- returns 1
    read "1" :: Int
via the magical joy that is Haskell typeclasses. Trivial but still very nice stuff.

Type-checking requires statically derivable information. You won't get any of the niceness unless you design your language around it.

I don't care about syntax either. It don't think it really matters and it takes all of an evening to get used to syntax from any language.

Yeah, `this` is freakin' ridiculous.

Re: The JavaScript Problem

#53

> lack of module system ES6 fixes this with, well, a module system. > weak-typing, Yup, this is a problem. > verbose function syntax, ES6 fixes this with arrow functions. > late binding Does this just mean dynamic typing? Well, yes, JavaScript is dynamically typed, but I wouldn't call that a language flaw. Static vs. dynamic typing is a tradeoff. > which has led to the creation of various static analysis tools to all…

> Again, I wouldn't say it "sucks" for this reason, just that it's dynamically typed. That's a tradeoff. This is the Haskell wiki. I would expect most participants to view having a single global implicit union type to be a flaw , not a trade-off .

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".

Re: The JavaScript Problem

#54

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…

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a…

The web was multi-lingual, it's why script tags have a "type" parameter.

I personally think that the death of plugins came about as the result of the iPhone, because x86 binary plugins won't run on an ARM-based phone.

Re: The JavaScript Problem

#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.

Re: The JavaScript Problem

#56

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.

JavaScript and HTML are a lot more bloat than machine language code written to the wire. Writing in a language appropriate to the task is almost always the right tradeoff.

I probably wouldn't invent JS if I were tasked with coming up with a bytecode for the web. But how bad is it, on the overall scale of things? I mean, x86 is not a great ISA, and yet has prospered, despite some real nonsense corner cases and an anemic register set. Is JS bad as a bytecode the way that x86 is bad as an ISA, or bad at a different level?

Re: The JavaScript Problem

#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 later (e.g modules, strict mode). The rest is a matter of taste and use case: late binding allows different things, all numbers as float is tasteless but it's not handicaping and there are ways around it, syntax is a matter of tooling.

I think anyone wanting to write serious applications for a platform should try to be the closer to the native environment, and adding an abstract layer on top of javascript because 'it sucks' feels childish.

Re: The JavaScript Problem

#58

Earlier quoted context omitted.

If you want to build a web app in Haskell instead of the web's true lingua franca, all you're accomplishing is making it harder to hire and harder to collaborate. We should be making the web multi-lingual. It's kind of absurd that we've built these great abstractions over HW and few people ever think about writing machine language. But for the web, an abstraction over several abstractions, we're largely stuck with a…

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.

Re: The JavaScript Problem

#59

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.

And if you want to leverage those functional data structures in a vanilla JavaScript context, there's a pre-compiled ClojureScript library for that!

http://swannodette.github.io/mori/

https://www.npmjs.org/package/mori

Re: The JavaScript Problem

#60
post #53

Earlier quoted context omitted.

> Again, I wouldn't say it "sucks" for this reason, just that it's dynamically typed. That's a tradeoff. This is the Haskell wiki. I would expect most participants to view having a single global implicit union type to be a flaw , not a trade-off .

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 dynamic side arguing that static typing is bad because java's type system limits them and doesn't prevent any bugs.

Post reply on HN