There are reasonable objections to JavaScript, but this is inane.
He uses an example of someone committing a classic mistake in software design. This error would be the same in JavaScript or Java. I'd like to see how his ActionScript translation magically fixed it.
However, the remedies for the mistake differ in each language.
It is somewhat difficult to fix it in Java's statically typed straightjacket (which I assume is similar in ActionScript). The easiest answer might involve a Feedable interface. I looked this up and it's not clear if ActionScript classes can implement multiple interfaces. So if you want your Toaster to be both Feedable and Heatable, get ready for interfaces extending each other.
In my experience most Java developers don't even do that. They don't think about revising their approach to the problem. They going to write a method that does what they want in the class that they want, come hell or high water. They'll create the BunnyOrToaster class which has methods which all contain if/else clauses testing if this in 'bunny mode' or 'toaster mode'.
In a language like JavaScript, you have other, simpler options, and often more powerful ones. I don't know for sure, but the mere fact that there are fewer tricks to learn might mean that it's better for naive to intermediate programmers. The typical JS way would be to rely on duck typing. If that disturbs you, you could implement a 'getFeeder' method on both kinds of objects that returns a closure, which can be executed later. That's what Java might call a 'Strategy pattern', but it's baked right into the language in JS.
>In my experience most Java developers don't even do that. They...
It's awesome how, on Hacker News, people whose job require them primarily write code in Java are some sort of stupid luddites ready to be easily generalized as the worst kind of programmer. Way to stay objective, guys.
Fair point -- it's unfair to stereotype Java developers. In my mind, I meant "most developers" and I happened to be talking about Java. But that distinction wasn't clear.
It's obvious that (in the OP's case) using JavaScript didn't help the problem either -- but that was my point. Bad design is bad design. I am not making a strong claim that JS is better.
When you think only in A restrictive language, your thinking becomes equally restricted. Any of us would become rigid if we never used or understood dynamic languages and only use java or c++ bog standard OOP.
So the comment is less about the developer than it is about the mindset and the 'easiest path' that emerges from the language design.
Which is t3h awesome, but not an option in either language under consideration, as far as I know. Unless you used a Haskell-to-JS compiler. I apologize if I implied that static typing = Java's kind of typing.
Java doesn't have pattern matching or nice tuple syntax but it does have Algebraic Data Types. Abstract classes are sum types (the dervived classes are the variants) while interfaces are (awkward) product types.
It's not the interfaces that are product types, but the concrete classes which correspond to product types.
Interfaces are a different concept. In functional programming, an implementation of an interface would extend the domain of polymorphic functions that use that interface. The same can be said about Java, if you tilt your head funny and don't need to communicate with other Java programmers, and if you only care about single argument dispatch.
He uses an example of someone committing a classic mistake in software design. This error would be the same in JavaScript or Java. I'd like to see how his ActionScript translation magically fixed it.
However, the remedies for the mistake differ in each language.
It is somewhat difficult to fix it in Java's statically typed straightjacket (which I assume is similar in ActionScript). The easiest answer might involve a Feedable interface. I looked this up and it's not clear if ActionScript classes can implement multiple interfaces. So if you want your Toaster to be both Feedable and Heatable, get ready for interfaces extending each other.
In my experience most Java developers don't even do that. They don't think about revising their approach to the problem. They going to write a method that does what they want in the class that they want, come hell or high water. They'll create the BunnyOrToaster class which has methods which all contain if/else clauses testing if this in 'bunny mode' or 'toaster mode'.
In a language like JavaScript, you have other, simpler options, and often more powerful ones. I don't know for sure, but the mere fact that there are fewer tricks to learn might mean that it's better for naive to intermediate programmers. The typical JS way would be to rely on duck typing. If that disturbs you, you could implement a 'getFeeder' method on both kinds of objects that returns a closure, which can be executed later. That's what Java might call a 'Strategy pattern', but it's baked right into the language in JS.