Hacker News Reader

Comment by sup | Hacker News Reader

That's coming in es6

I know people are crying out for this, but I can only shudder inside at the unholy mudball messes that will result. Inheritance is one of those things we shouldn't let anyone use until they're 40 or so.

Or, with great power comes great responsibility, and we shouldn't let uneducated and untrained quick-buck "developers" work on our software.

Inheritance is barely ever necessary, or even important, for any software problem, real or imagined.

Well to be fair to myself, I was mainly making a joke. But the simple truth is that inheritance doesn't bring new power to the table, just syntax sugar, and with great sugar comes diabetes and painful death.

Classes is a big enough portion of sugar to change expression level of code. After writing ES6 few months I don't like to write ES5 again, when I have to, and there is a lot of people who think so. Arrow functions is the another (if not first) big thing which makes this feeling stronger, and it's just a syntax sugar also. OO in ES5 looks less readable and less.. "native" than in ES6. Hope in some ES version 'this' insanity will be fixed and all will be just fine with classes.

just for note: I have never used "extends" in ES6.

im rly in love with typescript right now, looking forward to es6!

I just had my first exposure to Typescript recently, and the only part I liked was the fact that it allowed me to mix in plain old, untyped js syntax. TS, used as TS, feels verbose, like java, with lots of extra keyboard-typing to create a simple program.

>with lots of extra keyboard-typing to create a simple program.

When people say this as a knock against a language I can't help but wonder how they got so far in their careers using only two fingers.

Now, if you want to say that verbosity obscures intent and expressivity, then that's a fine argument to make (you'll have an steep hill to climb to show that types are an instance of this however). But if your development is bottlenecked by your typing speed, there's something seriously wrong.

It's both. I'm a poor typist, and more importantly, the terser the better. The less screen noise you have to filter, the clearer the picture becomes. I also put high value on DRY.

With optionally typed languages like Dart and TypeScript, you only have to add types to things like fields and functions/methods to get all the tooling benefits. Type inference takes care of the rest.

Secondly, you should be able to auto-complete pretty much everything.

"you should be able to auto-complete pretty much everything"

Requires tooling.

Eh.. grep is also a tool? Every function you write is a tool. The whole industry is built on tools and tools that make tools..

Sure. But programming languages whose claim to utility lies in an IDE -- they aren't necessarily bad, but it's not a programming language you're selling me, it's a whole environment: MS Visual Studio or whatever. A complex language requires lots of tooling like that, and a simple language doesn't. I have never missed autocompletion in Javascript, but I cannot function without IDE support in Scala. We're off the topic of OO in Javascript, but I wanted to make the point that I don't automatically consider that "IDEs can autocomplete" is a positive feature -- if you need autocomplete, that's a problem.

> but it's not a programming language you're selling me, it's a whole environment

Well, yes, because programming languages don't exist in a vacuum. The currently available libraries, tools, and documentation are very important if you decide to actually do something with that language.

> I have never missed autocompletion in Javascript

A moment ago, you complained about having to press a few more keys for the type annotations.

> I wanted to make the point that I don't automatically consider that "IDEs can autocomplete" is a positive feature

That there are IDEs which let you auto-complete everything is a positive feature.

Being toolable doesn't mean that those tools exist. If those tools exist, you can make use of them if you decide to use this language. This is a good thing.

By the way, JavaScript doesn't lack good tooling because it doesn't need good tooling. It's the way it is, because offering good tooling for JavaScript is really difficult. ES6's modules and classes will help with that though. The tools will make good use of this statically available information.

>> I have never missed autocompletion in Javascript

>A moment ago, you complained about having to press a few more keys for the type annotations."

For Typescript, I dislike the extra typing. I have never missed autocompletion in Javascript. Where is the contradiction?

One would think that 20 additional characters per function don't really matter if you can save 100 keystrokes.

Compared to JavaScript, I have to press fewer keys when I write Dart. (This would be also true without shorthands like method cascades.)

What's with this luddite mentality that pervades some areas of software? This meme that epitomizes terminal-based, mouseless, IDE-less development is just seriously absurd. We of all people should embrace modern tools that make development more productive. Tooling is the future, we should be pushing the envelope not romanticizing the past.

As I explained, requiring an IDE to make effective use of a language is a marker for a complex language. The system as a whole may be an effective way to build programs for some people, but it's now more than a language. The logical extreme is visual programming which reappears every few years. After a while, most people rediscover that languages articulate concepts better than visual metaphors. IDEs aren't as extreme, but sometimes don't merely enhance editing the language, but become almost a required part of the language. I am sure Martin Odersky can write Scala programs in Notepad, but I myself cannot write a Scala program without mouse hovers explaining the inferred type of my variable. It's an effective total programming system, but as a pure language, it's so complex I can only program it in a certain environment.

But why is environment flexibility a requirement? When are you genuinely constrained to use, say, only a terminal? I can think of no situation where this is true by necessity (rather than artificial constraint).

Well, first of all, I am not against IDEs. I use one most days of the week, and I'm productive in it. Some of the above discussion has misinterpreted my remarks. I only ever said, that a language making itself amenable to IDEs isn't a convincer for me, since languages requiring tooling to be effective are possibly less good as languages. So when somebody tells me Typescript is good because IDEs can autocomplete it, it's an unconvincing argument to me, since I prefer JavaScript which, having no type annotations, has less typing and little need for autocomplete in the first place.

I didn't even bring up environment flexibility, or terminals!

Since you asked, though, it is fairly nice to be able to ssh in to a box and make a code change, and recompile, for those languages that require that. Continuing with Scala as an example, I, myself, could not edit a Scala program extensively without benefit of an IDE. So say I have a Scala program sitting on a dev server where I'm building a batch image processing program. If Scala were as simple as Jacascript, I could easily use vi or emacs to iterate the development remotely. As it is, I edit and test locally on my laptop using an IDE, then push this big jar over to the server. So, there are plenty of cases where remote edit, compile, test cycle using a terminal is convenient.

And by the way, hackinthebochs, your line of argument down through this whole thread has been to call me a two fingered typist (accurate) with whom something is seriously wrong; a Luddite; and you erect straw man arguments like this, as if I'd somewhere argued for the environmental flexibility of terminals.

Certainly there was some extrapolation on my part (though I do find it amusing that I got the two-fingered part right). I was using your posts mainly as a jumping off point for discussion seeing as they seemed to be in the spirit of the mentality I was referring to.

The fact is we are being constrained by the past. We still program in plain text files, using languages and environments that are as basic as possible presumably to maximize flexibility of development. I don't see the point. There are those that eschew the mouse, or GUIs because the terminal is cool (or something). The fact is that this field is moving towards more and more tooling, hopefully improved visualization, and soon to be automation (imagine APIs automatically wiring themselves up, or the gruntwork drudgery of programming happening automatically). This is the future we should all be looking forward to, not placing arbitrary constraints on the languages and environments we use for the purpose of compatibility with outdated tools. The more constraints we place on ourselves, the longer this future will take to become reality.

I do appreciate the type inference.

I don't know about you but my experience with Java required me to type either the same or less than JS if we are comparing apple vs apple, not simple front end vs complicated back end.

Are you counting Java IDE keystrokes or actual number of characters on the screen? If it's the latter, I'd be interested in seeing an example since it's very much against the wisdom of the crowds here.

My experience is that the complicated part web app is the part that does the state coordination, which can be either end.

Java IDE of course. Not the number of characters on the screen.

Reply on news.ycombinator.com