HN Theater @HNTheaterMonth

Code should be written first and foremost for humans to understand, and incidentally for compilers to understand. https://mitpress.mit.edu/sicp/front/node3.html

If we can all agree about that then we have to ask ourselves if encapsulating data and behavior at the granularity of classes makes the most sense for human comprehension. In naive OO examples (Animal -> Cat) it does. In practice however, it's debatable (at best).

I highly recommend this video by Brian Will who does a much better job explaining this problem than I could. https://www.youtube.com/watch?v=QM1iUe6IofM

Douglas Crockford also does a good job of explaining some of the trouble with classes. https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s

⬐ Veedrac

> In naive OO examples (Animal -> Cat) it does.

An inheritance hierarchy consists of three things: a taxonomy, behavioural inheritance and structural inheritance. The first is only useful on occasion, and the last two don't even apply to Animal → Cat; "animal" is not a behavioural constraint, and a cat certainly doesn't have a platonic ideal of an animal hidden somewhere inside its gut.

A good place to start is MDN (Mozilla Developer Network): https://developer.mozilla.org/en-US/

MDN Javascript resources: https://developer.mozilla.org/en-US/docs/Web/JavaScript

Before starting the tutorials, take some time to learn what's available in the Firefox developer tools. You won't need most of them at first, but knowing what's available will help as you gain experience.

The two developer tools you'll probably use most when leaning are the Scratchpad (https://developer.mozilla.org/en-US/docs/Tools/Scratchpad) and Console (https://developer.mozilla.org/en-US/docs/Tools/Web_Console)

https://jsfiddle.net/ & http://jshint.com/ will also be very useful while learning JS

I haven't taken any but Udacity has some javascript courses (https://www.udacity.com/courses/all), just tick the "Javascript" checkbox under "Technology" in the left menu

Some additional resources:

https://developer.chrome.com/devtools

https://msdn.microsoft.com/library/bg182326(v=vs.85)

https://msdn.microsoft.com/en-us/library/d1et7k7c(v=vs.94).a...

http://www.ecma-international.org/ecma-262/6.0/index.html

https://github.com/getify/You-Dont-Know-JS

https://addyosmani.com/resources/essentialjsdesignpatterns/b...

Dated but still worth watching:

https://www.youtube.com/watch?v=hQVTIJBZook

https://www.youtube.com/watch?v=bo36MrBfTk4

edit: added addl. resources

One thing I've been waiting for (and if I had the time, I'd love to work on something like this) is scientific javascript. I love es6 and classless oop[0] that javascript provides (and general dynamic-ness) but the lack of operator overloading makes mathy infix operators work with an array-like type not possible in native js. Something that had the "functional", dynamic semantics of javascript with the natural notation that numpy has (with its broadcasting rules) would be fantastic.

Stuff like plotly is great, but as far as I can tell, I'm not going to be able to use it any time soon because I'm not going to write a >10 term expression in javascript when every '+' becomes a 'add(a,b)' or 'a.add(b)'.

[0] https://youtu.be/bo36MrBfTk4?t=33m45s

⬐ netheril96

To do that you first need to have a way of extending JavaScript with C and/or Fortran. No way numpy can be implemented in pure js or python without being excruciatingly slow.

⬐ gh02t

You can do it with the nodejs FFI. It makes me cringe a bit to say that, but you could do it in roughly the same way as how NumPy does it.

Sorry, English isn't my first language, or second.

Here's a link to the talk: https://youtu.be/bo36MrBfTk4?t=3446

Classes are not an improvement. See Crockford: https://www.youtube.com/watch?v=bo36MrBfTk4

⬐ BrendanEich

Out of date, as usual :-P.

⬐ randomguy7788

it used to not be, but with the reversal of the `this` creation and addition and use of `target.new` in constructor functions we are now able to extend Exotic types like array.

⬐ BrendanEich

`new.target` ;-).

/be

⬐ randomguy7788

Thanks for the correction :)

This makes sad, as Douglas Crockford said in this recent talk

> The prototypal school has a lot of advantages particularly compared to the classical school

> So in the classical school you have to create a classification of all the objects that are likely to be in your system. And, it's a lot of work to figure out what they all are and identify them and what their characteristics are and so on and then you have to determine how they are all related to each other, what’s going to inherit from what, what’s going to implement what, what’s going to interface with what, and that’s really complicated. And it usually happens at the beginning of the project before you fully understand what all this stuff means. So it’s likely your going to get the taxonomy wrong. It’s inevitable.

> And then you’ve got two hard choices. One is you have to live with a broken taxonomy and if you do that then with each new class you introduce things get weirder and weirder because everything’s wrong, or you have to refactor and refactoring is hard and it’s error prone and it’s another world of hurt.

> Those are your two choices and people who grew up in the classical school assume that’s just the way life is so no sense in complaining about it since that’s life.

> But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it.

> So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off)

> And so that’s why I think classes in ES6 are a bad part because they lock you into that paradigm.

> applause

> So when you’re locked in a paradigm like that, when you can’t see past it, you just have no understanding how miserable you are. And you’ll never know until you change your model

from https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s

⬐ munificent

> You just make an object, if you don’t like the way it works you make another one and that is literally it.

This is, like jashekanas eloquently puts it, so full of shit.

You're still creating a bunch of objects. Unless you are a mashocist (or a sadist, if other people have to maintain your code), you are still going to want to reuse methods between those objects.

Once you do that, you have to have some organization between what gets reused how. Sure, prototypes give you more freedom to define different ways of organizing and reusing behavior across objects. In practice, single-delegation actually works pretty well most of the time.

> So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off)

It's not that you don't have to create a taxonomy in JS. It's, "First you have to conceive and implement the very idea of a taxonomy itself. Then you get to use that to create a taxonomy."

You need to reuse code somehow. Figuring out a scheme for doing that is metaprogramming. JS basically says, "Well, you have to do this metaprogramming before you can get to the task you actually care about."

Using classes (or any other baked-in reuse scheme like parent slots in Self) just means the language has done the metaprogramming for you and you can use it out of the box.

The flexibility JS gives you is nice when the language's built-in mechanisms for code reuse aren't a good fit. But, so far, most homegrown code-reuse-systems don't seem to be that much better than what classes (with maybe some mixin or trait special sauce on top) provide.

⬐ drapper

> You're still creating a bunch of objects. Unless you are a mashocist (...) you are still going to want to reuse methods between those objects.

Aaaaaaand solution for that doesn't have to be a class (or something pretending to be a class), but for example a collection of functions/methods that you attach to an object, so you for example assign behaviour to data. This is something that Reginald Braithwaite for example advocates.

⬐ taco_emoji

That's called "composition over inheritance" and OO languages are perfectly capable of it.

⬐ munificent

> a collection of functions/methods that you attach to an object

Yes, that's what I meant when I said you have to design your own metaprogramming layer. You can do that. Just like you can invent your own class or prototype layer in C if you like.

The question is "Is having to do that a compelling feature for the language?" Are user's metaprogramming needs so diverse that the language should punt this problem onto users?

I don't see much evidence that this is the case. Most JavaScript libraries end up reinventing something that's within spitting distance of classes and single inheritance, maybe with a dash of mixins. All of that re-invention is a huge waste of engineer time.

⬐ bad_user

I don't get it. I know how prototypes in Javascript work, I can agree that you get a certain degree of flexibility that you don't get with class-based languages, which sometimes is useful, however people are still modeling classes in Javascript and people blaming education have the burden of proof - show problems that could have been solved with classes, but that were solved with a "class free" design instead.

And heck, I'll go further - in my mind, both class-based and prototype-based OOP, at least as present in Javascript or other mainstream languages, sucks because it mixes data with behavior and still suffers from the expression problem, because while you can take any object and modify it for a new interface, a process called monkey patching, that's just a terrible way of doing it.

OOP as a means to achieve polymorphism is simply inadequate for many use-cases. Sometimes it is much better to have type-classes (or similar, like protocols in Clojure). So you know, comparing 2 ways of dealing with OOP, misses the point that OOP on the whole is not enough, even broken as some would say.

⬐ masklinn

> I can agree that you get a certain degree of flexibility that you don't get with class-based languages

That's not even the case. Not in Javascript anyway. The only thing you get is not having a separate hierarchy of class objects.

⬐ kybernetikos

Most class based languages won't let you inherit from an instance, and many won't let you use the same techniques you use to inspect or constrain instances to inspect or constrain classes.

⬐ coldtea

>But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it.

Yeah, which goes to show you shouldn't listen to Douglas Cockford.

First, what he describes is playing in a REPL at best. You don't just "make another [object] if you don't like the way the fist one works" when you write a program, unless you write a structureless blob. You still have to think about your objects and/or inheritance chain, be it prototypal or not.

Second, ES6 classes are nothing more than syntactic sugar over barebones prototypal inheritance.

Third, you already do all that stuff in JS. You have to write a lot of boilerplate code (and usually everyone does a slightly different version) to get the same end result.

⬐ adamlett

I feel like the concepts are being abused here. Prototypical — at least in my understanding — refers to a mechanism of inheritance or delegation, and not as Crockford uses the term to the way you build your objects. Confusingly, JavaScript didn't even have prototypical inheritance until relatively recently, because even though every object had a prototype, it couldn't be set or changed on an individual basis, but was determined solely by which Constructor (read: Class) that created it, which made JavaScript's inheritance mechanism essentially indistinguishable from the classical, albeit with more obscure nomenclature.

⬐ Touche

ES6 classes are just syntactic sugar for constructor/prototypes like we write them today. You can mutate them as much as you like.

⬐ greggman

not in SoundScript they aren't

⬐ UberMouse

Pretty sure they still are syntactic sugar for prototypes, just like in ES6. But SoundScript enforces that you cannot modify prototypes. There's not really a problem with that, it's doing it for speed. So it's not for your average Javascript app where performance doesn't matter as much.

⬐ randomguy7788

although i agree somewhat, prototypal inheritance does nothing to help solve the taxonomy.

the article below i think explains the situation much better: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...

⬐ jashkenas

I don't mean to be argumentative (being argumentative on HN is so passé), but what you just quoted is so full of shit that I feel like someone is obligated to comment.

In the prototypal model — as it exists in JavaScript — you do do all of that. You make a series of prototypes that you intend to use in your application, and those prototypes (or classes), serve as the effective taxonomy for many of the objects you're making in your app.

Classes in ES6 are prototypes. They don't lock you into any such Java-esque paradigm unless you're going to be willfully ignorant about them.

Please don't repeat baloney just because Crockford said it.

---

For example, to be concrete:

    class Crockford {
      speechify() {
        return "...you're going to get the taxonomy wrong. It’s inevitable.";
      }
    }

A class. A terrible, inflexible, prototype-destroying, paradigm-locking-in, JavaScript class. Eww, gross.

But wait! What's this?

    Crockford.prototype.speechify = function() {
      return "...the shape of an object can change at any instant, because \
             someone can fiddle with the prototype.";
    };

You can have your classical cake and eat prototypal cookies too. Because in any decent dynamic language, the two concepts are synonymous.

⬐ greggman

It's not baloney IMO. As someone who's coded C since the 80s and C++ since the 90s I find JavaScript massively freeing.

In C++ (and similar classical languages) in order to be able to pass in different implementations of a class you need to create a base class or interface. You don't need to do this in JavaScript.

In JavaScript you can build objects on the fly. In fact he goes on to say

> so I used to think that the important thing in JavaScript was prototypal inheritance I now think it is Class Free object oriented programing. I think that is JavaScript’s gift to humanity. That’s the thing that makes it a really interesting important language, is that it did that. That we can use functions in order to create objects and it simple and elegant and powerful and fast...

And it's true. Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript. In my own experience I have a mutli-user networking system written in JavaScript and a library in C#. To reimplement the same things in JavaScript in C# is a huge amount of code bloat. I have to make classes and meta classes and all kinds of other indirection just so I can make an Event system that is generic. In JavaScript that's 2 or 3 lines

That we don't actually need all the structure to get shit done is what people are finally coming to realize.

The problem with 'class' in ES6 is that it will prevent people from learning this new, easier, faster, simpler way of working because instead they just bring the classical baggage to JavaScript. That's in fact what most programmers from classical languages do. It's what I did for years until I started actually grokking JavaScript. ES6 "class" will only make it take longer for people to actually get pass their old ways.

⬐ masklinn

> And it's true. Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript. In my own experience I have a mutli-user networking system written in JavaScript and a library in C#. To reimplement the same things in JavaScript in C# is a huge amount of code bloat. I have to make classes and meta classes and all kinds of other indirection just so I can make an Event system that is generic. In JavaScript that's 2 or 3 lines

That does not follow from what you quoted, and what you quoted is a non-sequitur to start with.

What you're raving about can be achieved just as easily in any dynamically typed language. Hell you probably get 80~90% of that in a structurally typed language (OCaml objects, Go).

> In JavaScript you can build objects on the fly.

Which you can do in many other languages, including statically typed ones. Here's an object in Ocaml:

    # let s = object
        val mutable v = [0; 2]

        method pop =
          match v with
          | hd :: tl -> 
            v <- tl;
            Some hd
          | [] -> None

        method push hd = 
          v <- hd :: v
      end

And that's statically typed.

> The problem with 'class' in ES6 is that it will prevent people from learning this new, easier, faster, simpler way of working because instead they just bring the classical baggage to JavaScript.

That's patent nonsense, not to mention ES6's class shortcuts apply to object literals as well, the only thing the class statement does is remove the bullshit and mostly useless boilerplate Javascript demands when creating a reusable prototype due to it being a garbage language, and its "prototypal" object system being there not because it's good and going to save the masses but because it was the easiest way to have an object system working in a week. It's just a sad and pitiful shadow of Self's object system from which it draws so little you have to know the relation's there to find it.

⬐ visionscaper

> That we don't actually need all the structure to get shit done is what people are finally coming to realize.

Getting stuff done until the code base grows and others have to adapt or build up on the code you've written : the idea of bringing in structure is to encode knowledge about the problem you are solving and keeps it all maintainable (admitted, if done right).

> In C++ (and similar classical languages) in order to be able to pass in different implementations of a class you need to create a base class or interface.

And that is a good thing IMHO, see above. However I agree that, particularly in C++, an interface definition is very verbose. Unfortunately it has no pure Interface concept.

⬐ pjmlp

You can always use pure virtual classes, but requires discipline and virtual inheritance.

⬐ the_gipsy

As a javascript programmer, I have perceived es6 "classes" as nothing but syntactic sugar. They should just construct the equivalent constructor+prototype combo. You can still create anonymous objects quickly, and use any object as prototype for another.

⬐ masklinn

> As a javascript programmer, I have perceived es6 "classes" as nothing but syntactic sugar.

That's basically what they are.

> You can still create anonymous objects quickly, and use any object as prototype for another.

Hell you can create anonymous objects even faster with ES6 since object literals also get the short method notation and computed properties.

⬐ drapper

Yes, but let's admit it, the presence of classes will inevitably lead to their ever-presence, if only for the fact that they are what most people coming from other languages are used to.

⬐ masklinn

The absence of class already leads to their ever presence, each project simply reimplements its own instead of using the built-in syntactic sugar. The class sugar is simply a way for the creation of (prototype + constructor) pairs not to be a pain in the ass, nothing more and nothing less.

⬐ discreteevent

" They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript."

You can do that in a language with classes and even one with optional types e.g. you can use jasmine perfectly well to mock typescript objects (because they are just JavaScript dynamic objects)

" I have to make classes and meta classes and all kinds of other indirection just so I can make an Event system that is generic."

I remember reading Gilad Bracha saying somewhere that enabling exactly this kind of system was exactly one of the use cases for Dart which is class based with optional types. You can have your cake and eat it too!

⬐ Touche

I think you're confusing this new Chrome-only thing with ES6 classes that just saves you from using a library to create constructor/prototype objects. In ES6 "class" is just a keyword that makes it easy to contruct objects that are very typical in day-to-day JS. Inheritance is already a thing that happens.

⬐ greggman

I'm not. See above, "class free object oriented programming". You don't need prototypical inheritance to have inheritance in JavaScript. Crockford gives examples. You don't need the "class" keyword. All it's going to do is steer people in the wrong direction.

⬐ Touche

Can you give an example of inheritance without prototypes in javascript?

⬐ Yahivin

Check out Daniel X. Moore's `{SUPER: SYSTEM}`. http://stackoverflow.com/a/3731253

⬐ None

None

⬐ greggman

from D.C.

    function base(spec) {
        var that = {},
            member,
            method = function() {
                // spec, member, method
            };
        that.method = method;
        return that;
    }

    function derived(spec) {
        var that = base(spec),
            member,
            method = function() {
                // spec, member, method
            };
        that.method = method;
        return that;
    }

I'd suggest you watch the talk linked above for this stuff in context.

⬐ aikah

and then how do you implement super with your system? because that's the point of prototypes,the fact that you're not overloading methods but you have access to the prototype chain.much harder to do with your method.

⬐ greggman

You shouldn't need access to the prototype chain. Accessing that chain is an anti-pattern.

⬐ aikah

no it isn't,that's how you implement "super" in javascript.

⬐ Touche

That is not inheritance. `instanceof` doesn't work. There would be no way to know that an object from derive dis of the type of base.

That's also very memory inefficient. The method function gets made for every instance. With prototypes there would be only 1 function in memory. This stuff matters at scale.

⬐ greggman

Watch the talk.

You've got a gig of ram in your pocket. Memory doesn't matter for 99.99999% of apps. The memory taken by your objects isn't where your memory goes. It goes to images and other big stuff. A few extra bytes per object isn't going to kill you. Optimize for programmer time not memory, especially not in memory on things that don't matter.

Why are you using "instanceof". The whole point of inheritance is you shouldn't have to ask. If you are asking your doing it wrong

⬐ wvenable

> As someone who's coded C since the 80s and C++ since the 90s I find JavaScript massively freeing.

I've gone back and forth between dynamic and static and strict and loose in every combination and I don't find the dynamic/loose to be particularly freeing anymore. The problem is you can't really rely on anything. It doesn't so much as solve the problem that Crockford is talking about, it just moves it somewhere else. You don't have to refactor but you're going to end up with two (or more) different things that exist at the same time instead of one.

> Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript.

This is a great point and it's a perfect example of the advantages and the horrors of the JavaScript model. A mock is supposed to be an object that does something completely different (typically nothing) but otherwise looks and functions like the real thing. Maybe just in one slight exceptional way. JavaScript makes this easy. But it also makes it easy to make those same changes outside of mocking and tests and that is just debugging hell waiting to happen.

⬐ greggman

You can write bad spaghetti code in any language. You avoid that with style guides, linters, and code review.

⬐ wvenable

I don't see how strict typing couldn't fit at the end of your list as well.

⬐ greggman

It could but some of us have had the experience of massive productive increases in JavaScript over our decades of experience in statically typed languages.

And note I'm specifically calling out JavaScript. Other dynamic languages IMO haven't provided the same benefits because they're still following old models.

When you truly grok JavaScript and stop trying to use it like your other languages it really starts to shine. It's not perfect but it is different.

Can't quite tell if this is a joke, but here's a related "story about a bug" from Doug Crockford [0]:

    I made a bug once, and I need to tell you about it.  So, in 2001, I wrote a
    reference library for JSON, in Java, and in it, I had this line
    
        private int index
    
    that created a variable called "index" which counted the number of characters in
    the JSON text that we were parsing, and it was used to produce an error message.
    Last year, I got a bug report from somebody.  It turns out that they had a JSON
    text which was several gigabytes in size, and they had a syntax error past two
    gigabytes, and my JSON library did not properly report where the error was — it
    was off by two gigabytes, which, that's kind of a big error, isn't it?  And the
    reason was, I used an int.
    
    Now, I can justify my choice in doing that.  At the time that I did it, two
    gigabytes was a really big disk drive, and my use of JSON still is very small
    messages.  My JSON messages are rarely bigger than a couple of K.  And — a
    couple gigs, yeah that's about a thousand times bigger than I need, I should be
    all right.  No, turns out it wasn't enough.
    
    You might think well, one bug in 12 years you're doing pretty good.  And I'm
    saying no, that's not good enough.  I want my programs to be perfect.  I don't
    want anything to go wrong.  And in this case it went wrong simply because *Java
    gave me a choice that I didn't need, and I made the wrong choice*.

[0] https://www.youtube.com/watch?v=bo36MrBfTk4&t=38m

EDIT: is there a reference for formatting comments? I've never been able to find one.

⬐ gioele

Interesting, this is similar to the discussion going on for "int" in Rust (or the exact opposite, depending on how you view it). [1, 2]

One the one hand "implicit int" are being phased out in favour of explicit int size. Your variables cannot be `int` anymore, you have to sit down, think and choose: u8? u16? u32? i32? u64? i64? This avoids all the pains of programs behaving differently or crashing when compiled on different architectures.

On the other hand, a new "native integer for sizes that do not matter, minimum 32 bits" is being brewed, for example for pointer offsets or collection sizes. The idea is that you will not be able to have a collection with more of 2^32 elements in a 32-bit architecture nor more than 2^64 in a 64-bit architecture.

After this discussion, my hope is to see the introduction of a fast-ish dynamic bigint (that starts native and grow up to 256 or 512 bits) that can be used in all the cases where you do not care about the exact size type, yet you want to be future-proof (this `private int index` fits this case, IMO).

[1] http://discuss.rust-lang.org/t/if-int-has-the-wrong-size/454... [2] https://github.com/rust-lang/rfcs/pull/464

⬐ Narishma

Wouldn't that limit rust to 32-bit or more architectures?

⬐ maxlybbert

16 bit architectures are weird enough that a lot of tools don't support them. And 8 bit architectures are basically only used for things like Arduino nowadays.

However, using a 32 bit number to store values that will never be larger than 16 bits isn't that bad, it's just very slow.

⬐ tinco

It would affect the standard library of rust, not rust itself I think. Second, the word-size matching the architecture has only a slight performance impact, i.e. operations on a 64-bit word on a 32-bit architecture take more cycles/instructions than 64-bit words on a 64-bit architecture.

It's only important for things like pointers that they match the size of the addressing space, and not even that is a very hard constraint, just a very convenient one.

⬐ robert_tweed

I'm guessing (since this is Doug Crockford talking about JSON) that this was in reference to how JavaScript does things differently, in that it just stores everything as floats, which are quite capable of representing integers within the 32-bit range anyway.

However, an overflow to floating point isn't necessarily an improvement because, while a float will hold bigger numbers, it does so with limited precision and sometimes that lack of precision will cause bugs too. Probably more often, in fact.

In the example given it wouldn't be so bad, but you'd only get an approximate indication of where the error occurred rather than a specific line/character. So of course, whatever is reporting the error would now need to understand and handle the much more complex scenario of "fuzzy" location information instead of a simple unique index to a specific character. Depending on what it then needs to do with that information, the complexity could spiral from there.

If you want to just have things work no matter what, you have no choice but to use bignums. I was wondering about this recently, so did some benchmarks in Clojure. The performance was horrible, so frankly this is still not a viable alternative. Maybe in 10 years time, if every CPU has a bignum coprocessor by then.

Also, there are times, particularly in low-level graphics programming or cryptography, where you actually want integer modulo arithmetic, or to be able to do bitwise booleans predictably. In those cases, JavaScript-style loose typing can be a huge pain.

BTW, I've been a big advocate of JavaScript for about as long as Doug Crockford, so my point isn't that JavaScript-style type handling is bad: just that it's very far from a silver bullet.

⬐ cstavish

>> Java gave me a choice that I didn't need, and I made the wrong choice

What if Java gave an arguably more useful choice--whether to use a signed or unsigned integer?

⬐ None

None

⬐ danbruc

But only because asm.js works hard to make JavaScript differentiate between integers and floating point numbers.

⬐ None

None

⬐ danbruc

This is a decision a compiler can never make in a reliable way because it entirely depends on the actual input and is not known until runtime. You may get away with dynamic recompilation when you realize that the input is not what you assumed when you compiled the code but I really doubt that this is a smart and efficient way to go about it.

And asm.js is no evidence for the no side - the information is in the original source code, it does matter and asm.js works around the JavaScript limitation and makes this information available to the JavaScript compiler.

⬐ whyever

If you use an unsigned 32 bit integer instead of a signed one then you run into problems at 4 instead 2 gigabytes.

⬐ vbezhenar

While negative numbers very often provoke exceptions like IndexOutOfBoundException, with unsigned integers error could be uncaught for much longer time. I'm all for signed integers, unless storage requirements so tight that you really need that one bit.

⬐ takeda

But who would have JSON files bigger than 4GB? ;)

⬐ AgentConundrum

4194304 K ought to be enough for anybody.

⬐ onion2k

Not many people. But in another 12 years?

⬐ guard-of-terra

We do have a 18GB xml (daily). I guess it will turn to 10 GB json when we convert it over.

Why is it even a question? Imagine a JSON of all the people on Earth.

⬐ jmtulloss

The parent is joking. "Why would you ever need X?" is a classic question that bites every software engineer at some point. Somebody always needs X.

⬐ tdsamardzhiev

If you are working with files bigger than 2GB, hoping they're smaller than 4GB is NOT a good habit.

And I certainly don't believe there are programmers making only 1 mistake for 12 years. I believe he's just making a joke, or using the example as a means to an end.

⬐ talles

I loved how he ended

  *Java gave me a choice that I didn't need, and I made the wrong choice*

⬐ lerchmo

What if someone else needs that choice? like anyone doing compression?

⬐ phillmv

Let those people eat cake, and in the meantime protect me from my own misbehaviour.

⬐ lukeschlather

When you're storing an integer, ideally "MAX_INT" is not something you have to worry about.

If you're doing compression you should use some sort of raw bytes type.

At least I think that's the platonic ideal.

⬐ aidenn0

Make the default numeric type effectively unbounded, and allow those who need it to choose more compact types when needed. This is what many languages do, and it is possible to both generate efficient code when needed, and correct code is more likely to happen.

⬐ batuhanicoz

Reference for comment formatting can be found here: https://news.ycombinator.com/formatdoc

⬐ Tepix

He's pushing for DEC64 now (http://DEC64.com)

⬐ peterashford

I'm constantly amused how Java is supposedly stupid for protecting programmers from things they shouldn't do and yet also stupid for not protecting programmers from things they shouldn't do.

IMHO Java makes some choices about safety. If you don't agree with those choices, use a different tool. It doesn't make Java wrong for having a different opinion. Likewise I wouldn't berate C for being too low level or Ruby for favouring readability over performance.

⬐ lmm

So for that kind of software you use Python. Doesn't everyone know that? Java gives you that choice because it's for the kind of software where you need that choice.

⬐ ColinWright

This is a FAQ. Oddly enough, the "FAQ" link at the bottom of the page takes you to the FAQ, in which it says:

========

What kind of formatting can you use in comments?

http://news.ycombinator.com/formatdoc

========

Was that what you were looking for?

⬐ danbruc

He did not need the choice but others do. And he is wrong when he says it makes no difference whether you use a byte or eight of them. Yes, it will take the same amount of time to add two of them but it will also cost eight times more cache space and memory bandwidth to move them around. It may not be an issue if you have a single number or ten of them but it certainly becomes one if you have an array with millions or billions of them.

⬐ philosophus

I don't believe he said it makes no difference.

⬐ danbruc

»But in todays CPUs there is no advantage using the short thing. You can add 64 bits or 8 bits, takes the same amount of time. And you look up what is the cash value of having saved seven bytes on a number. When you add that up it is zero. So there is no benefit.« [1]

As long as you are concerned with adding a bit of eye candy and interactivity to a web page this may be true enough to get away with the JavaScript way of making every number a double precision floating point number but there a other domains where this will not fly. And even in the world of JavaScript asm.js is trying hard to overcome this limitation.

[1] http://www.youtube.com/watch?v=bo36MrBfTk4&t=42m17s

⬐ coldtea

>but there a other domains where this will not fly.

Sure, and I believe everybody, including Doug, knows this not so subtle distinction. He wasn't talking about programming HPC for NASA.

⬐ danbruc

He is comparing Java and JavaScript and implies that it is a bad choice of Java to offer several options. And given the broad range of applications Java is used for I don't think this is a justifiable opinion.

⬐ diroussel

But in java (64-bit JVM) this statement is true: "You can add 64 bits or 8 bits, takes the same amount of time."

⬐ rtpg

There are use cases where you need the choice, but most people do not need the choice.

Most programs written in the real world (enterprise-y Java apps) do not need strong control on GC, choice of integer types, or many other things offered to them. Reducing choice will increase code/tool quality.

I think that we should make the uncommon choice reallllly hard to put into place. Make it a pain to configure the GC, give specific integer types really long names. Just stop people from premature optimization and leave these tools to people who know what they're doing.

⬐ danbruc

If you are unable to make good decision between different number types you better don't write software, IMHO. How do you reason about the operations you apply to your data if you are ignorant of the possible values?

⬐ rtpg

I write software, and the amount of times I even have to explicitly manipulate numbers in a given week is very close to zero. Even iteration is done through iterators instead of indexes, so writing a plus sign is done pretty sparingly.

Data manipulation beyond "pull out of database" or "submit user input to database" is a lot rarer in enterprise software like this than in scientific computing. I'm not saying it's bad to be aware of it, but software is more than numbers.

⬐ cbhl

Even if you abstract away the indexes, when working with datasets that large you have to worry about whether the standard implementation makes the same class of error.

For example, using Java's binarySearch on arrays of length over 2^30 was broken until 2006[0][1].

[0]: http://googleresearch.blogspot.com/2006/06/extra-extra-read-...

[1]: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=5045582

⬐ danbruc

I develop enterprise software, too, and I definitely think it matters there, too. You better make sure your database columns have the correct number type or you will get in trouble if your inventory numbers or monetary values start showing rounding errors.

⬐ rtpg

Yeah, you're right, data types matter. Like sibling said, this was more in response to signed/unsigned or different bit sizes. We could get rid of minutiae while still allowing for broad choice when it actually matters.

I do think that the difference between Integer/Fractional is important, but honestly if you're dealing with money you should be using some Money datatype that's smart about this instead of raw numbers.

⬐ ionforce

You are comparing two different types of numbers.

What was originally compared was different sized integral types.

What you are comparing is two numeric types that have a large semantic gulf (fractions vs integers).

So your point is disingenuous in the context of the former.

⬐ danbruc

I just wanted to address your point that enterprise software does usually not involve dealing with numbers.

When it comes to integers you are right - signed and 32 bits is a viable choice in north of 90 % of all cases. And when I wrote you should be able to make good decision about the number type to use I was already thinking of all the number types, however I did not express this well. But then I really don't see a lot of difference between being able to choose between integer, floating point and decimal types on the one hand and various integer types on the other hand.

⬐ coldtea

>If you are unable to make good decision between different number types you better don't write software, IMHO.

Doesn't sound very humble, this "HO".

Do you know how many programmers that run circles around you (and me) have done mistakes similar to what Doug describes?

⬐ danbruc

Being able to make good decisions does not guarantee you will never make a mistake. And he even explains his reasoning behind his choice and it was a justifiable decision when he made it. But I stand by what I said - if you are unable to decide between using 8 bit or 64 bit integers or a floating point type or a decimal type you should not be a professional software developer because it is really a very basic and fundamental skill.

⬐ sysk

Then what do you propose we call the people who write Ruby, Python, Javascript, PHP, etc. code for a living? Have you heard of accidental complexity?

⬐ danbruc

Ruby, Python and PHP all support several types of numbers. But even if they did not this would not preclude people developing in those languages from being able of making such decisions.

⬐ onion2k

In the web industry, which is the biggest part of the software industry by people employed, most developers use dynamically typed languages and very happily never make this "fundamental" choice. Should they all resign?

⬐ danbruc

Dynamically typed does not mean that you don't have to think about number types - 3/2 and 3/2.0 may yield different results in dynamically typed languages.

And how many web developers don't know about or are unable to decide between different number types? JavaScript type coercion is such a mess, how could you get away without thinking about types, even though number types are usually not an issue?

⬐ benaston

"JavaScript type coercion is such a mess" - in what way? Seriously.

⬐ nfm

`" " == 0 == false`, and `"" == 0 == false`, but `" " != ""`.

`"Infinity" == Infinity`, but `"true" != true`.

I could go on for a while like this.

⬐ benaston

That is not specifically type coercion, but the behavior of the equality (==) operator in JavaScript. Type coercion in JavaScript can be very useful, for example !!('foo') is coercive and easily understood (and has an unsurprising result). Thankfully the == operator is completely optional and has a more easily understood === (identity) correspondent, making your point less about a language and more about a specific operator within a language.

⬐ nfm

It is type coercion. The runtime converts both operands to the same type before making the comparison (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...). This is also true of !, <, and friends.

Other operators in JavaScript may behave more intuitively than ==, but I don't think you can really make a good case for JavaScript's type coercion being 'unsurprising'.

⬐ benaston

I suppose what I meant was that you point out that the coercive behavior of some operators is counter intuitive; ergo type coercion in JS is a mess. I dont think that follows because some operators behave in a coercive fashion more convenient than many other languages.

⬐ coldtea

And which of those persist if you use ===?

⬐ tragic

None - because === does not coerce types. Type coercion, not double-equal weirdness as such, is the gripe of the GGP. Non-transitive, inconsistent equality is nothing more than a symptom of JS's rules for implicit conversions.

Language-war disclaimer: I love javascript and everything, it's a very expressive language; but a good wodge of the tooling around it nowadays is to help people avoid things like implicit type-coercion 'surprises'.

⬐ protester

Well, your first line doesn't make sense, since the first two comparisons are using type coercion but the third isn't, so it's like saying `0 == false` but `0 !== false` how can this be? (" " != "" is the same as " " !== "")

The second line at least uses type coercion, but still you are making the wrong assumptions. true could be coerced to many strings 't', '1', 'true', 'yes', 'on', but they chose to use '1' (You may not like it but I think it's a good choice). Infinity on the other hand has not many choices when coercing it to a string I can think of '∞' (which is difficult to type), 'Infinity', and maybe 'Inf.' so I think they made a good choice here.

I'm not saying type coercion in js has no problems, but you said that it's a mess and I just think you chose the wrong examples.

⬐ danbruc

In what way it isn't? Just look at this beauty [1] and its consequences. But probably nobody uses the equality operator anymore because it is such a mess. Less than is even more messed up [2].

[1] http://people.mozilla.org/~jorendorff/es5.html#sec-11.9.3

[2] http://strilanc.com/visualization/2014/03/27/Better-JS-Equal...

⬐ berdario

Thankfully Python fixed that discrepancy about 3/2

Anyhow, I don't agree with you: I think that getting a bug years down the road due to a too small numeric type is something that the programming language itself should avoid.... not because "developers don't ought to know it", but because mistakes happen

Anyhow, even with a dynamically typed programming language like Python or Javascript you can care about the size of your numbers.

Just import the array module (in Python) or use the Int32Array/Int8Array/etc. types (in Javascript)

⬐ markokrajnc

Not only web industry: in Smalltalk every integer can have unlimited number of bits. On 32-bit systems internally 31 bit is used first and with overflow it automatically starts using variable size integers... There is no need to make a choice on the number of bits... Just use integers as they are in the nature...

⬐ TeMPOraL

I guess that most programming languages, with possible exception of COBOL, were not created with boring stuff - like enterprise-y apps or webdev, that compose most of the programming today - in mind.

Douglas Crockford's been making this argument this year at conferences: http://www.youtube.com/watch?v=bo36MrBfTk4&t=19m (linked to the `new` bit, but the whole thing's worth watching).

> These stories get used an awful lot to justify dogma on everything from strict typing to Promises to whatever. I feel that's misguided - there will always be enough rope to hang oneself with in any language, and those errors should have been mitigated by diligent use of static code analysis (linting) and unit testing.

Paraphrasing the talk I just linked to, it's always better to have a language which will guide you away from writing the bug in the first place than to have to come back with a linter and fix it up.

6. Be Douglas Crockford. http://www.youtube.com/watch?v=bo36MrBfTk4&t=19m

I believe he has some experience of JS.

⬐ insin

Argument From Cranky Authority (Whose Lawn You Are On)

⬐ regularfry

Possibly, but it does rather blow a hole in the argument that only people with limited experience in JS would treat `new` as a footgun.