Hacker News Reader

Comment by jasonhanley | Hacker News Reader

You make a fair point.

I have been programming for a long time now (~26 years) and I do tend to roll my eyes every time some fancy "new" language/framework/library comes out that's just a re-re-re-implementation of something 20, 30, or 40 years old.

It's simply not practical to keep rewriting large, stable applications using a completely new language and architecture for marginal benefits on an ongoing basis.

I've programmed in everything from BASIC to Pascal to C/C++ to C#, Lisp, Python, PHP, Java, Javascript, can't even rememeber what else and let's be honest -- there's no silver bullet.

They all have their strengths and weaknesses, and they all compile down to machine code.

I just have trouble understanding why people refuse to work with language or framework that's more than a year old.

View on HN

I don't roll my eyes at new tech, but I do roll my eyes at the idea that new tech can fundamentally solve problems, because the hard problems aren't language problems. I do, however, roll my eyes at using crufty old tech for new projects when better tech is available. I dayjob in the enterprise Java world, but I'm working on a startup at home. I'm still not quite settled on all my tools for the startup code, but I'm definitely settled on the 12 Factor App approach (http://www.12factor.net), and it's led me to the conclusion that mainstream enterprise middleware as expressed in J2EE is fundamentally wrong. Application servers are an inherently bad idea.

That said, my own coding is currently leaning toward Node.js for server stuff. I'm using Neo4j for data and it turns problems right on their ear - for my space (not all spaces), it's a million times better than relational and a thousand times better than document databases. So I'm looking for languages/frameworks that make my particular use of Neo4j more graceful. Started with Rails, but gave it up as the ActiveRecord ORM is kind of Neo4j-hostile in practice. I expect this is true of most ORM solutions (hence the R, for "relational"), so maybe I can make it better in a lighter-weight system.

At any rate, there are no silver bullets, but plenty of wooden ones. I lump PHP in that category. If there's an existing PHP app, then by all means maintain it, but don't use it for new projects!

Well that's insightful. At least I realize the problem I have is perhaps not the problem that I thought I had.

It may just be a strong bias against PHP.

But even if we did choose to rewrite at some point, how do you choose?

Java is "enterprise-y" and people generally hate it.

As you mention, Ruby has fallen out of fashion, and it's always had a reputation for being a resource hog.

Python is a great language overall, but was never really meant for web programming so ends up being a bit kludgy.

Node is super popular with the bleeding edge crowd, but it's only been around for 3 years and speaking of wooden bullets -- Javascript has more language pitfalls than PHP! And there's still no clear winner in terms of framework stack.

Meanwhile, Google has invented its own proprietary languages , which seems like a real Microsoft in the 1990s kind of move.

So even if we started over, it's pretty unclear what we'd choose to build with.

> But even if we did choose to rewrite at some point, how do you choose?

I'd pack my bags tomorrow for a Lisp job.

I have a question about "Application servers are an inherently bad idea." This is the first time I see such statement, but it's stated as a fact. Could you point me to some online resources I can read up on, didn't find anything in google yet.

Reply on news.ycombinator.com