Hacker News Reader

Comment by dkarapetyan | Hacker News Reader

I'm looking forward to day when instead of endlessly comparing languages against each other everyone just shuts up and builds stuff so that merit of your language choice can be judged by what can be built with it.

View on HN

Before they shut up and build something they need to go pick their tools. This is about picking the tools.

If we look at tools used in practice, we should be picking C,C++,Java,C#,VB,Python. If we look at functional languages we should be picking -- not sure, Erlang perhaps.

The way to know how good Erlang is, is to start writing an MMO in a different language, trying to fit as many concurrent users on the same hefty multi-core cloud instance in the same shard. Then, after you've come up with about a dozen clever tricks and made several key insights, read up on Erlang and discover that it already takes most of that into account. (I did this with Go and plan on learning Erlang now.)

So are you going to pick F# now? None of the arguments in that post have convinced me to switch.

I might. I really like F#, I was hesitant about the .NET and Microsoft infrastructure. There was minimal interaction with it on the business side (all Linux). Only recently have started playing with Mono. Now that .NET open source, I might give it a second look!

Ah but you see your reasons are entirely pragmatic. You're worried about the ecosystem and vendor lock-in. None of the arguments in the post even come close to mentioning those things.

Ok you are right, I see your point.

I guess the assumption here is "all other things being equal" which is often not the case. There are large team, difficulty in finding libraries, legacy code, performance/testing/deploy-ability considerations.

Erlang, like Ada, is a very serious language for very serious applications. People use those languages for all kinds of things, but they belong to the class of critical application languages and therefore they're both kinda weird.

The only benefit of Erlang is built-in actor model. Other than that being dynamic is killing it as a general-purpose language.

Yeah, I hear what you are saying. Some of the comparison seems like simple "mine is better than yours" childishness and elitism.

However, I don't think all of the comparisons are without value, and I would not want all of the discussion to go away. But a little more emphasis on "here's this useful thing I build with language 'X'" would certainly be welcome.

Yup. That would be much better than look at this "hammer" it does a hammer's job but it's better because the handle is curved slightly differently. I mean that's how I see these discussions. Tools are for doing and building.

There are more factors than 'what can be built' with a language. A more popular language will have more projects written in it, and popularity is not necessarily based on merit (think about the promotion Java received because of commercial reasons).

Java is a perfectly adequate language. I'm not saying network effects don't matter. I'm saying the focus should be on building things instead of some other metric like language purity.

Java is an acceptable programming language, but far from perfectly adequate. Its inadequacies are very well documented.

> Its inadequacies are very well documented.

Which is a very useful trait for a tool to have.

Yeah is not like you're forced to use JavaScript right?

Complaining works cause it makes the shit more visible so they can fix it in later versions of the standard.

You are indeed not forced to use JavaScript. Currently I can count PureScript, Elm, Scalajs, GHCJS, Opal, TypeScript, Amber Smtalltalk, and I don't know how many other languages that compile to JavaScript but are not JavaScript. So who's forcing you?

Even if you compile to JavaScript from another language, you'll end up eventually debugging the compiled JavaScript in some cases. Painful times debugging GWT code compiled to JavaScript suggest that the development tools aren't sufficient to avoid the need to do so.

In comparison if you write Objective C for iOS, you can debug the Objective C, as opposed to needing to debug in the compiled assembler.

I've never had to debug actual JavaScript whenever I've used TypeScript. Source maps are pretty nice and both Firefox and Chrome developer console are a joy to use when debugging. There have been plenty of times when dropping down to the assembly level and looking at obj dumps has been the right way to debug a problem so abstractions leak no matter where you are in the stack.

Your employer or your team can force you, in fact it's pretty common.

I rather use CoffeeScript instead of JavaScript, and I've forced teams to use CoffeeScript, but the fact that all browsers use JavaScript and everyone "knows" JavaScript make it easier for teams to stick with it.

You can do it sneakily but it could be a problem when you need to follow certain code conventions stablished by the team.

So is your employer currently forcing you? If you don't enjoy the experience so much then it's not like you don't have options. You could literally have another front-end job tomorrow working with your compile-to-js language of choice if you wanted to given the state of the developer market.

I'm just explaining the reason why people complain about that language that YOU can't understand, besides, the job my pay really well and you like to keep it, not everyone is like you man, and you're not right all the time...

Chill, you don't have to be a confrontational prick every single time of the day. Then when people call us jerks we don't understand...

Reply on news.ycombinator.com