Hacker News Reader

Comment by blueblob | Hacker News Reader

I cannot comment on Ruby. I, personally, think Java is a much bigger language than (base without other scripts included) Javascript. Of the two, I prefer Java for it's strong types. My biggest problem with Javascript is that if I make a typo on a variable name, it can be very difficult to debug. This could perhaps be mitigated by using an IDE, I don't know since I don't use JS that often. I feel like this is not a major issue and work on LLVM+emscripten will let me work in almost whatever language I want and have it end up in Javascript in the near future.

View on HN

Why do you think Java is bigger?

From my perspective, Java has, effectively, structs (well defined groups of data) and a few primitive types, and a class system which is dead simple. It's tiny, comparable to Lua imo.

It's more restrictive, sure, but the dynamic-ness of Javascript is a hindrance when it comes to language spec because the base language functions need to be able to interpret all the different primitive types. There's stacks and stacks of corner cases to remember while Java just says "Nope, wrong type".

Generics, interfaces, abstract classes, method visibility, statics, different flavours of numbers (and primitives), inner-classes, huge array of data-structures, iterators, checked exceptions, annotations, threads...

Comparable to Lua? :)

I'll give you generics. Statics, method visibility vs global/local/self. Interfaces, abstract classes, inner classes vs metatables. Data-structures apart from array are implemented on top of the language, array vs tables. Iterators are implemented on top of the language vs lua where they are part of the language. Checked exceptions can just be cast to Exception and ignored. Annotations are optional. Threads vs coroutines.

Yes, comparable to Lua. I'd probably not say it's smaller than Lua but I would say it's not greatly larger than it.

I think Java is bigger in terms of the amount of classes/methods that there are to remember. Perhaps I compare them unfairly because I consider everything in the SDK to be a part of Java, whereas the things people might usually bundle in JS (JQuery, etc) I don't consider part of JS because you have to go out and get them separately. I didn't mean bigger in the sense that you need to know more to be able to use it, I meant it in the sense that it is a larger API.

>I didn't mean bigger in the sense that you need to know more to be able to use it

Ah ok, well I can see why we have differing opinions because that's exactly what I mean :)

I mean base language including corner-cases, not any of the libraries (even if they're included in the SDK). I think they'd both be huge if we included libraries, since I'd lump in DOM manipulation and something like JQuery into Javascript if Java gets the SDK libraries.

But all of those things you listed are very different things. In JavaScript they are the same thing.

Please expand your response, I don't understand what you mean when you say they are "the same thing".

Just a couple of examples. Arrays and Objects are the same type of structure in JavaScript. Arrays just happen to be indexed by integers and Objects by strings. In Java this is not the case.

Another example, in Java Classes are not objects that can be manipulated, they require a special form (generics) for that. In JavaScript a "class" is just a function that has some default properties attached.

Just a couple of examples. Arrays and Objects are the same type of structure in JavaScript. Arrays just happen to be indexed by integers and Objects by strings.

This description doesn't tell the whole story, leading people to a false conclusion of simplicity.

When it comes to JavaScript arrays, a lot of magic is happening under the covers that doesn't happen with non-array objects. Good JavaScript developers need to know those details, and that counts as complexity.

You're doing people here a disservice by leaving out relevant information.

The associative arrays in JS are simpler than objects in Java but the expressiveness means you need to be aware of all the different types of type coercion and how it all interacts at runtime. I don't think this is that difficult but it's no more difficult to lay out your data before runtime. I think this is a wash that goes to the dynamic vs static debate which we all know can be argued about for days.

You're leaving out prototypes which I find much more complicated than Java Classes.

But the discussion isn't about complexity, the discussion is about "smallness" and prototypes are definitely small. They are just "bags of properties" like all JavaScript objects. They just have the special function of being automatically applied to a new object's "__proto__" property when using new. Compare that to Java, where Classes are not objects themselves, they are blueprints for creating objects. But the distinction there means if you want to reason about Classes you need a special form in generics.

Reply on news.ycombinator.com