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

71–80 of 183 posts

Re: The JavaScript Problem

#71

Post by camus2 »

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(or node api).

It sucks as soon as you try to use jQuery with it.You end up with any everywhere which defeats the purpose of that language.

In my opinion,if you need to pick a js alternative,choose Traceur.

Re: The JavaScript Problem

#72

Post by Peaker »

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.

Re: The JavaScript Problem

#73

Post by camus2 »

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…

> The people who hate javascript the most are the ones who wish it was something else.

Ask yourself,how can a single language can fit every use cases,for every developpers? We cant agree on what we should use on the server,but we are basically forced to use 1 language in the browser,of course some people are going to hate it.

I shouldnt have to adapt javascript,javascript should adapt my coding style.But aint gona happen.

Weak typing and Type coercion are imho the biggest flaw of javascript,I can live with the rest,but not that.

Proxies will help a bit though.Devs will definetly abuse them.

Re: The JavaScript Problem

#74

Post by michaelsbradley »

camus2 wrote: post #66
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.

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.

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] to David Nolen's mori library.

[1] http://leiningen.org/

[2] https://github.com/emezeske/lein-cljsbuild

[3] https://github.com/swannodette/mori/blob/master/package.json...

Re: The JavaScript Problem

#75

Post by hamburglar »

hippich wrote: post #48
hamburglar wrote: post #33

Earlier quoted context omitted.

I assume it's referring to the fact that 'this' changes in a given piece of code depending on how it's called, whereas other vars are lexically scoped, so you are often forced to work around the issue by making your own lexically-scoped equivalent, aka the old "var self = this;" trope.

and this is perfectly fine. it allows you to do more if you know how to use it. and if you don't - it is really simply to understand. again - this is how js different from many (all?) languages out there, but why it is bad - i am not sure. extra line of code in some cases? I don't think this is really that bad.

I won't say it's good or it's bad, but I will say that it bites me on a pretty regular basis. You start with some code that says this.something() and you decide to move it into a callback and miss converting the 'this' references to 'self' because in the previous incarnation, it didn't matter, but now you're calling out to code that helpfully fixes up the 'this' reference when calling your callback. I literally fixed one of these today.

Re: The JavaScript Problem

#76

Post by baddox »

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…

If there exists a tool that compiles your language of choice to JavaScript, and the stuff you write in your language of choice works on modern browsers and is stable and performant, why do you care that it's JavaScript being compiled to and not byte code?

Re: The JavaScript Problem

#77

Post by baddox »

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.

Doesn't that argument get weaker as JavaScript gets more widely used? It's already one of the most prominent languages in the world, and is probably increasingly the first programming language encountered and learned by beginners.

Re: The JavaScript Problem

#78

Post by jnbiche »

coolsunglasses wrote: post #50
jnbiche wrote: post #2

I'm surprised that Elm is not mentioned: http://elm-lang.org/edit/examples/Reactive/ZipCodes.elm True, it's not Haskell, but it's clearly highly-influenced by Haskell. Besides, they mention Fay, which isn't Haskell, either. If the Haskell wiki didn't require a log-in and registration that requires special, personal permission, I'd add it myself.

I don't recommend Elm because it's not Haskell and it's too boxed into its way of doing things. Elm is really, really far from being an acceptable substitute for Haskell. It's a gap comparable to that of what Java and Scala can do. PureScript is a better choice for a Haskell'ish language that is generically applicable to both browser and node-backed JS. Importantly, you can decide how you want to do FRP/callbacks/wha…

I would agree that there are probably more "Haskellish" compile-to-JS languages, but the wiki mentioned CoffeeScript and TypeScript. Surely Elm ranks above them in your book?

Besides, Fay doesn't have typeclasses, either, and it's mentioned.

I wasn't making the claim that Elm was somehow better than those options, just that I was surprised it wasn't included. I've just played around with Elm, nothing serious.

You're correct that Elm seems more like a DSL in some ways with its required FRP, and I agree that typeclasses and HKTs are nice, but if I could choose between doing my day job in Elm or staying with JavaScript, I know which I'd pick (hint: it's not JS).

Re: The JavaScript Problem

#79

Post by acqq »

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…

If you think about it, bytecode you wish just doesn't exist, whereas JavaScript does and it works:

http://mozakai.blogspot.co.at/2013/05/the-elusive-universal-...

Re: The JavaScript Problem

#80

Post by coolsunglasses »

jnbiche wrote: post #78
coolsunglasses wrote: post #50

Earlier quoted context omitted.

I don't recommend Elm because it's not Haskell and it's too boxed into its way of doing things. Elm is really, really far from being an acceptable substitute for Haskell. It's a gap comparable to that of what Java and Scala can do. PureScript is a better choice for a Haskell'ish language that is generically applicable to both browser and node-backed JS. Importantly, you can decide how you want to do FRP/callbacks/wha…

I would agree that there are probably more "Haskellish" compile-to-JS languages, but the wiki mentioned CoffeeScript and TypeScript. Surely Elm ranks above them in your book? Besides, Fay doesn't have typeclasses, either, and it's mentioned. I wasn't making the claim that Elm was somehow better than those options, just that I was surprised it wasn't included. I've just played around with Elm, nothing serious. You're…

Do not underestimate how powerful and useful HKTs and typeclasses are until you've used them in anger.

I have a guide to learning Haskell here: https://gist.github.com/bitemyapp/8739525

You should give it a whirl.

Just use PureScript if you're fortunate enough to know alternatives to JS exist :)

Post reply on HN