Hacker News Reader

Comment by owenversteeg | Hacker News Reader

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 in glass houses shouldn't throw stones. Just today, I've seen three links to guides "to learn basic Haskell syntax", two of which contradicted each other.

* I agree with their statement on `this` behavior. This (pardon my pun) is one of the places where JS's well-intentioned DOM-manipulation features cause problems with it as a language.

View on HN

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

> Javascript is actually untyped, not weakly typed (untyped means no type declarations, not that it has no types)

I've never really heard the term untyped before -- I guess I'm old school and still call that dynamic typed. But JavaScript is also weakly typed. It will automatically convert strings to numbers, etc. Some languages, like Python, are dynamically typed but also strongly typed: No type declarations but no automatic conversions.

It's been popping up lately. It's meant as a smear on dynamically typed languages, because dynamic has a positive connotation and untyped is decidedly negative. Pretty similar in intention to uni-typed.

http://stackoverflow.com/questions/23282683/is-clojure-uni-t...

Edit: Sorry, learned something new just now. I'm very, very wrong.

Untyped is where operations are valid on everything because it's all a sequence of bits.

Dynamic is completely different and refers to when the type is discovered.

Sorry. However, Javascript is definitely dynamically typed.

Uni-typed is actually a very specific technical term. Mathematically you can prove type theorems about languages regardless of whether they implement types as language features. Dynamic languages are thus modelable like this and when you do so the first approximation is to say that a dynamic language is a language with a single type (uni-typed).

The reason this is valuable is it opens up directly the techniques for "hybrid typing" such as PHP->Hack and Javascript->Typescript. It also is the basis for the compiler using type inference to accelerate certain portions of the code.

* Being an entirely interpreted language, JS cannot have static type checking. This has not been an issue in my experience.

This doesn't mean it isn't an issue, just you haven't encountered a situation where it is.

And you've never seen three guides to "learn basic Javascript syntax" which contradict each other?

You can argue it both ways, as far as I am concerned. Javascript like any other language has issues, what exactly those issues are... depends greatly on what you use Javascript for.

>This doesn't mean it isn't an issue, just you haven't encountered a situation where it is.

You're right, but it seems to be fairly rare. I've only once ever seen static type checking help find bugs in rarely-used code paths, and that was a single occurrence five years ago.

>And you've never seen three guides to "learn basic Javascript syntax" which contradict each other?

No, I haven't. The only things I can think of off the top of my head that a JS newbie would find contradictory are semicolons and declaring arrays with [], both of which are used by the vast majority. I've only seen one codebase ever that used new Array(), and only a handful that didn't use semicolons unless necessary.

>You can argue it both ways, as far as I am concerned. Javascript like any other language has issues, what exactly those issues are... depends greatly on what you use Javascript for.

Good point. Claiming Javascript is issue-free is as ridiculous as claiming that (to quote this guide) "Javascript sucks".

On the `this` feature: This is mostly a "problem" with the DOM-interface, which is not part of the language. But there is even a solutions for this in JS: Object.handleEvent() -- Why is everyone complaining on the lack of a feature that is in fact already built in? Just start using it ... Also, since functions and objects are first class entities, you may just store references and make use of them as you like. (But, please, don't use "var self = this;", since `self` is already a predefined variable pointing to the global object.)

This is well put, but I can't offer the same concession about "this" ... what exactly is the problem? It provides access to the state of the object on which you are working, if utilizing OO paradigms within JavaScript. Sure "this" values when executing pure functions in some runtimes make little sense but if you understand what "this" means with respect to OO, you wouldn't be trying to access it in that situation in the first place.

> untyped means no type declarations, not that it has no types

I found this to be a very bizarre statement, given the existence of dynamic typing. For anyone else confused, this is the best discussion I could find of the issue:

http://stackoverflow.com/questions/9154388/does-untyped-also...

There seem to be a few different viewpoints on the matter. This is the one I go with (as well as Brendan Eich and other high-profile JS people.)

The programmer theorists view of what a "type" is will always differ from a programmer's view. If I'm talking to a bunch of theorists, I know that types are absolutely static entities, and everything else in the dynamic world are actually tags. If I'm talking to programmers and am careful to make this distinction, they will find me to be overall pedantic and verbose.

So unless one is having a discussion with someone like Bob Harper, dynamic typing absolutely makes sense and is not a misnomer.

Untyped, however, is a bag of worms that you can't really get out of. To some it means no type declarations, in which case Haskell is untyped to some extent with its excellent support for type inference. To others, untyped means the complete absence of types and type checking (static or dynamic)...like doing something completely unchecked at run time with a void* in C. The views are diverse among programmers, let alone theorists! So I just avoid this term in any case.

I guess the Haskellers noticed this HN thread. One moment my comments were at 2 points, the next they are at zero. It seems to be the same for other non-anti-Javascript comments.

If you're trying to solve the perception of being snooty and unpleasant (as mentioned in this thread), downvoting everything isn't going to get you far.

Could you clarify on `this`? I find how it works very obvious and natural to me, therefore not quite sure why everyone consider it broken and not 'different'?

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.

Are you using strict mode? It doesn't fall back to the global object as `this` (except for setTimeout/setInterval, which are specified that way) - since I've started using it, I find out pretty quickly if I was missing a `.bind(this)` when passing a callback function.

The problem appears to be, some tend to get confused, who is the caller and who is the callee. For this, please just consider that the DOM-interface is not part of the language, but just -- as the name suggests -- an interface to a separate environment. From the point of view of the DOM, the element is the callee, which applies itself to a callback function (the event-handler). Makes quite some sense.

In case you've issues with this, you may just use `Object.handleEvent()`, and the this-object will be your object (or function). Why is everyone complaining about this behavior, but no one is using the built-in feature that would be the perfect solution to the problem?

Javascript is weakly typed. And untyped does not mean no type declarations. It means no types, just like it says. Assembly is untyped. Javascript is dynamically typed. Very different. http://en.wikipedia.org/wiki/Programming_language#Typed_vers...

Javascript does not define the implementation details. It does not have to be interpreted, and in fact I don't believe any modern implementation is interpreted. Javascript is generally compiled to byte code which is then run in a VM, or native machine code (V8 at least does this). There is no reason javascript could not have a static type system, there are statically typed scripting languages. It is dynamically typed by deliberate decision, not "we can't do it any other way".

Reply on news.ycombinator.com