Hacker News Reader

Comment by laichzeit0 | Hacker News Reader

After doing this shit professionally for more years than I could care for anymore, when I see programming language or framework comparisons I immediately think of something like[1]:

"Why Klein Cushion Grip screwdrivers are better than Wera Kraftform screwdrivers", or in this case "The myth of using Kraftform as a better screwdriver".

And then I imagine myself going back to using my shitty old Phillips screwdriver set to screw in a few screws in a non-optimal fashion and someone might say "Wow, thanks for hanging my door!" and I imagine the surprise on my face as I realize that people want functioning doors and are not too bothered about which brand of screwdriver was used to achieve that.

[1] http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-...

View on HN

What a crap, supercilious comment. Yes laypeople want functioning doors, but this is not an article for laypeople, it's an article for engineers. What we want are tools that allow us to build performant, maintainable, reliable code.

Besides, if all you do is to fix a door than you may be right. But we build entire tower blocks, with doors, windows, elevators, ventilation systems, structures able to hold up tons of material, and all the rest. Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.

When you're building a 'tower', what is more important? The strange new hammers and screwdrivers you're using, or the architecture, algorithms and data structures?

Please don't compare a programming language to a hammer. They're not similar in complexity, and it makes a really bad metaphor. Besides, unless you write entire applications in assembler, you DO care about programming languages.

I completely agree. Bricks would be a better metaphor and still completely contrived. And turns out, you can't build skyscrapers without concrete and steel :)

And just to be pedantic: When I bought my first SwissTools Insider[1], I realized that it's actually still possible to innovate in screwdriver design. That doesn't make them better for every task, but hey, that's the way it is.

[1]: http://www.pbswisstools.com/de/werkzeuge/quality-hand-tools/...

They are similar in outcome.

Do u care about what language Amazon uses to write S3? Do u believe it is the language that make S3 succeed, or fail?

Even as a programmer, as to the other services I am calling, things I do care about involving their stability and correctness that affecting my work. I care shit about what how they write their service underneath, may it be cool or dumb.

If we're going to insist on the carpentry tools metaphor ... hammer vs nailgun; a hammer can do everything a nailgun can do and more ... but if you're banging together a timber-frame for a house the nailgun will let you get through the task far far more quickly. If you're running a business, and time is money, which tool would you want your carpenters using for this task?

If I'm running a business that lets say develops an ecommerce platform I won't be too impressed if my developers are using assembler. Java good, but if Scala gives them an edge and cuts my costs so much the better!

Yeah, so choose what works best for u, not assuming the same thing for others without understanding the specific problems they are trying to solve. Maybe they need a hammer, not a nail gun, because they work in specific environment that don't have sufficient power supply? or for the work they are doing, hammer is good enough, it is better for them to invest elsewhere.

I'm kind of making the point that in many environments you'll need both? A nailgun (battery or gas powered) for the "bulk" jobs and a hammer for the finer work. I can't imagine anyone being effective in Scala without first having a good knowledge of Java. Or at least without having Java expertise near to hand.

I used to think so too, but at work I've met programmers who code in Scala without having learned Java first, and it's enlightening. They are proficient in Scala. Whenever they touch Java code, they are upset that the niceties and modern features of Scala aren't there -- whatever we thought was reasonable in Java or "not mainstream" in Scala are exactly the opposite to them. "Why do I have to write all this needless code in Java?", they ask (for example), nicely countering the common but unwarranted notion that Java's verbosity somehow makes code more understandable to regular joes.

It's enlightening to me because a lot of what we consider "hard" or "too academic" is actually our own prejudices speaking. Of course it looks like that to us, coming from Java, but try talking to someone who learned Scala first :)

I also find it encouraging. Maybe some day we will be able to finally take advantage of the JVM without the weight of Java-the-language.

You've met programmers who know scala but not java but tell me this: Were they in an environment without java expertise "to hand"? To me scala is more akin to a skin over java. Particularly when using 3p libraries that were written in java (this ecosystem is one of scala's key advantages over other fucntionalesque programming environments). When you work with scala you'll always need some java guys nearby to deal with the "nitty gritty" details.

No, that's precisely the thing -- I've met programmers who learned Scala as their first language for the JVM (some guys I'm thinking about coded in C and PHP before that), they are pretty proficient, and they absolutely do NOT need Java programmers "at hand". It's interesting that they "get" Scala; they don't try to use it as if it was Java++ (in my experience, this attitude you describe that Scala is merely a "skin" over Java is mostly due to prior knowledge of Java). When these people eventually need to learn some Java, they do so on their own -- and curse the language!

I think we're starting to see a new phenomenon: people who don't start on the JVM with Java. It's interesting because it shows (in my opinion) that the whole "Scala is too difficult" thing was mostly a misconception. What it was truly all about was: it's hard to give up old ways of thinking :)

I honestly can't see the point in scala if you're not integrating with the the javaverse ... I'd have thought you'd be far better off cutting a clean break and using a "proper" functional language like Haskell or Go

Obviously, one big draw of Scala is that it can interoperate with Java and take advantage of existing libraries. But that's a far cry from saying it's mostly a wrapper around Java. New code, including libraries, should be written entirely in Scala. The JVM is itself a valuable target, regardless of Java-the-language.

That said, I love Haskell and would definitely enjoy using it at work, but it's a no go for "political" reasons, which is sort of reasonable even if disappointing. Scala scares management way less than Haskell!

I don't personally care what S3 is built using, but that doesn't mean the people who built S3 shouldn't care. Java, Scala, etc. are all tools with different strengths and weaknesses. Use the best tool for the job, considering the experience and capabilities of the team you have.

Just because end users don't care about the language used to implement S3 doesn't mean the developers at Amazon don't care.

_I_ don't care what they use to write their platform, because it's a black box to me. But _they_ care and spend a lot of time debating it, and that's when discussions like the one in the article are important and shouldn't be dismissed.

> unless you write entire applications in assembler, you DO care about programming languages.

That's true, but we've been in the region of diminishing returns for programming languages (I'm not talking about runtimes) for a long, long time now. To go back to the (bad?) tools metaphor, it's like saying that unless you're using nothing but your fingers, you DO care about tools. Well, yeah, but once you have a decent screwdriver, innovation in screwdriver technology -- short of a revolution -- is likely to yield diminishing returns on investment, especially as the cost of adoption remains high. Switching from, say, Java to Scala is not much cheaper (if at all) than switching from, say, assmebly language to FORTRAN or C. This does mean that the effort spent on switching languages (or screwdrivers) should decline.

Just cause one thing is more important than another, doesn't mean the other thing is unimportant. You appear to be arguing against discussing tools, because they aren't as important as other things.

Modern skyscrapers would certainly not be reasonable to build without "strange new hammers and screwdrivers" (read: tower cranes, super-powered concrete pumps, etc).

Algorithms and data structures will be mostly the same regardless of what language you use.

Architecture will generally not be. Scala and Java encourage building applications in different ways. That doesn't mean one is better than the other (though I'd argue you could make that claim), but some problem domains are better modeled with Scala, and likely some with Java. And some programmers work better tending toward a pure, immutable, functional style, while others work better with OO, side effects, and mutable data.

While choice of language/framework may not be as important as many other choices you need to make when building an application, but it's not something that should be dismissed as irrelevant, either.

The point is that you have to care about your tools and know them really really well if you want to be able to build good software.

That's something that holds across all fields of engineering and art.

I used Angular Material to build a website. I dunno if you've ever been to the Angular Material website *https://material.angularjs.org/latest/), but check it out if you haven't. You see that nifty looking navigation bar on the left? You can't actually build that using Angular Material given all those wonderful components they list there. There are entire blog posts created so you can make a similar looking navigation menu [1][2]. There are so many things missing or incomplete in this framework that you'll only realize when you try and build a "real" application with it. Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2. Yay for the people who just want functional doors.

[1] http://blog.vizuri.com/creating-your-own-angular-material-na... [2] http://stackoverflow.com/questions/28389671/create-a-menu-li...

Let's talk about Material Design Lite. Go check that website, especially the components page (https://getmdl.io/components/index.html). It's really nice and responsive, try changing the size of your browser window and see how the navigation bar collapses to the top. Damn this looks like a great framework, I'd like to do the same thing in my app. Imaging the surprise when you can't actually do that using the framework out-of-the-box. Oh by the way, forget about MDL, all the developers have moved on to Material Components for the Web (https://github.com/material-components/material-components-w...). So much for the guys who just want to hang a door, there's a new brand of screwdrivers on the block.

It would be great if the so-called "engineers" could spend some more time creating a complete toolbox instead of reinventing new screwdrivers every month.

In my experience, this is a much bigger problem in web programming than elsewhere. Take the JVM, for example, since it's the subject of the article- it's been around for decades and while things have changed, you can still pretty just just keep using whatever you're using without fear of the developers jumping ship for something shiny.

Indeed. Also, in more sane / stable areas of the industry, the code doesn't rot so fast. Java is relatively backwards compatible down to version 1.5 or so. In Common Lisp world, the code written more than years ago works perfectly fine without need for any change.

I think I'm in love.

You're forgetting that this is every web developer's dream. To always keep learning new frameworks (to do the same fucking thing) over and over.

I get that this is the easy way to see it from the outside, but:

- You don't have to learn every new framework. Google has 10k+ Angular 1 projects, this stuff doesn't go away after hitting critical mass.

- This constant iteration has lead to multiple production-ready UI paradigms that were just relegated to FP research. Try using Angular 1 or vanilla React, and then do something with vanilla Android. Or GTK+. Do we want GTK to be our baseline for UI work? Qt is nicer, but it's definitely playing catch-up.

You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.

> Everyone opts for electron

And I’m just sitting here, using https://github.com/ReactiveX/RxJavaFX

Is JavaFX okay? Or maybe even good? What's wrong with it? (Not polished enough, not maintained enough? Not updated fast enough?) RxJava seems pretty okay.

Seems perfectly fine for building desktop applications in Java (which is what I've been doing for the last 1.5 year at my $dayjob).

Java has problems on OS X and Linux. It is not truly cross-platform like Electron is.

Don't know about the OS X problems much, but on Linux it's workable with FX (our product is actually used on both Windows and Linux). OTOH, Electron achieves its portability by shipping the whole Chromium browser with your application...

There is actually one issue JavaFX has on Linux: It uses Gtk to determine renderscale, so it can’t handle HiDPI at all (Gtk only scales in integer amounts, so everything is either 96dpi or 192dpi)

Could you talk a little bit about these problems? I was not aware of any serious issues on non-Windows platform, and would like to hear about them. As Java/Kotlin is generally my go-to language for making things in my off time, that would be helpful to know about.

Off the top of my head: misses some UI elements / widget types (spinner / numeric entry). UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).

And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).

> misses spinner

https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...

> UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).

You can use String.valueOf, but usually don’t want to do that. And how do you want to represent the float? With Scientific notation, Engineering notation, or purely decimal? This is not simple.

> And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).

Or you use the FXML bindings for creating them from XML?

The constant iteration has definitely led to more production ready UI platforms. But once they are in production they are largely abandoned in favour of "shiny new thing 2.0". The rate of change on the web development side is simply too fast to keep up with especially with regards to tooling.

> You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.

I'm not convinced it's particularly good reasons. I think ignorance of native GUI coding and the old, "When all you have is a hammer, every problem looks like a nail" mentality has a whole lot to do with it.

Wouldn't really say that I am seeing it from the outside. Have done some web frontend projects last couple of years and also used Electron for a project. Starting an Angular 1 project now is comparable to doing Windows desktop applications in MFC, and Angular 1 is what, 6 years old?

And the only satisfying thing about Electron, is hitting package and getting three platform-specific binaries. Otherwise, it is still web frontend development. In contrast, I have had the pleasure of doing desktop development in Qt and WPF, which was quite enjoyable (and the ecosystem has not changed a lot since I left it years ago).

Also, MVC and MVVM were UI paradigms before web frontend development. And I am quite sure I heard about ReactiveExtensions before Facebook React.

Yes, vanilla Android is terrible.

The primary reason to learn new web framework all the time is that current are still not quite there yet. It needs more maturation till it can stabilize into something good enough.

"Why would you want a 2017 car? I have a Model T here that does the exact same thing"

It's a free and open source project and you're still complaining. And browsers and the web, JS and a lot of things changed between Angular 1 and Angular 2.

Yes, Google could have handled those projects better, they could have put up big warning signs that they are "deprecated".

I think it was a good move to recognize how unmaintainable things (can quickly and usually) become with angular1 (or with anything that is a mess of a hundred semi-external JS libraries), hence TypeScript.

Maybe marking them deprecated when they're launched?

So we've moved past the 'forever in beta' phase to the 'deprecated at launch' phase?

Man I smelled that "horrendous complexity" odor on Angular a mile away. Made me glad I can do mostly backend work.

You're not wrong. I am an Angular 1 dev who's in the process of moving to Angular 2 and even that is an up-hill battle. However, I think it's about picking the right tool for the job in that the batteries-included / opinionated nature of Angular is great for once you start scaling a team AND/OR you have a product that you need to keep shippable at all times.

I've done a few projects with Angular Material, and I actually ran into that exact same issue of trying to re-create the documentation's sidebar, only to realize the components weren't in the framework.

> Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2.

I think an important lesson from this is to be careful about the tools you use. If a particular company puts out great tools but changes them in incompatible ways, you might end up having to go back and rehang a lot of doors.

But for a sufficiently expert programmer Java and Scala are as different as two brands of screwdriver.

Not really at all. A sufficiently expert programmer may be able to switch between Java and Scala with the same ease of switching between brands of screwdriver. But that same programmer would certainly not use Java and Scala in the same ways, as they would with two different brands of screwdriver.

I thought it was a very pertinent comment tbh. Done in a tongue in check way, but definitely applicable to "engineers"

Not to put words in the parent's mouth, but I think he is suggesting that we (developers) should spend less time creating / analyzing / debating / choosing frameworks and more time thinking about actual end user functionality.

If this is what parent meant, than that's true - we do bicker too much about it in the industry (I'm guilty of it too). Discussions about tools are important, but ultimately what's important is what those tools are used to build.

> Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.

The screwdriver analogy is right on a lot of levels. Is it so hard to accept that software developers is not some unique snowflake position that cannot be compared to any other job?

>What we want are tools that allow us to build performant, maintainable, reliable code.

Virtually any mainstream language is capable of building performant, maintainable, reliable code. Virtually no developers are capable of creating performant, maintainable, reliable code. After decades in the industry and generations of new whizbang tools, libraries, and languages I've come to terms with the fact that the problem is "us." I've seen exactly one significant sized application keep those 3 qualifications for more than a couple of years. Once all the original core developers on the project moved on, it was less than a year before the code base was a total mess.

I think what you're really asking for is a tool that forces you to build performant, maintainable, reliable code. I'm not sure that's entirely possible until we get AI writing and maintaining its own code. Humans suck.

Plus, we have to pad our rèsumès so we can move on to another job before anyone realizes how bad this pile of horse-dookey is and we have to figure out how to maintain it.

Minor nit: résumés. I generally need to look it up myself.

Don't tell me, tell the Android spell checker. That was it's suggestion. :-)

Your example is looking at it from completely wrong way. Computer software users don't care about programming languages and frameworks either, because they know even less about them than they do about screwdrivers. Imagine your surprise if I came to you after you hung my door and said to you "thanks, but no thanks - that screwdriver of yours totally sucks!".

On the other hand, if you worked as a carpenter (or even did some more door hanging on the side), you'd find yourself debating the tools and techniques of your trade with your fellow craftsmen, maybe even engaging in heated debates about their relative performance. The same is true about programming languages - they're tools of our trade. They have different performance characteristics. The discussion about that (and the flame wars) are between the craftsmen, not between the worker and the buyer.

In my experience, no they don't spend much time debating the tools with their fellow craftsmen. And if you look at the tools themselves, they don't change much. They do tend to spend money on good quality versions of the same old tools though and just get on with it. It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week.

To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. When Carmack wrote Doom he didn't use half of what C++ had to offer. It was just boring C with classes. But the application (Doom) was more than interesting at the time.

> To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools.

That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now.

That's why I like hobby projects - you get to choose problems that are interesting.

I like the idea behind your post because it's true for lots of people - when you're so close to it, you don't realise that you're arguing over maybe 10% efficiency in lots of cases.

But i think programming is kind of unique in this respect too.

The tools sometimes let you approach a problem in a different way; sometimes "just getting on with it" means you're wasting a lot of time dealing with stuff that wouldn't be an issue in a better language.

To give you a concrete example, it's like when you do a CRUD application with a properly normalised database and then you need to add auth. And then you realise a transaction made at a certain date has messed up all later transactions. And then you realise you need to add an audit trail. And then you realise that needs to scale its services independently and you have to add micro-services. And then you realise you've got yourself into consistency issues because your services are sharing state through your db, etc etc.

Or you just implement CQRS and all those problems go away (yep you have different problems).

But i'm just saying that tooling matters, and picking the right tools can be worth hundreds of thousands of dollars.

I think the C / C++ argument is a strawman, it's not using all the features of a language that matters, it's picking the right ones.

Your point about "picking the right ones" is fair enough and of course the language can make some difference but not anywhere near the difference the architecture makes. Which is exactly what your point about CQRS outlines.

Google and Amazon built businesses on Java, a tool that is as boring as a hammer. It was the architecture that mattered.

"In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice."

- Peter Norvig

https://news.ycombinator.com/item?id=1803815

Yep I agree that architecture plays the largest part.

But I really don't think it's about a language being boring vs not!

Pure functions are easier to reason about. So it makes sense that a language that encourages their use will be easier to reason about - which will help with maintainability.

Same goes for concurrency patterns - the closer they are to the language, the less room for mistakes.

I think the same for testing, but a lot of the time it's up a layer of the stack with a framework.

"It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week."

That seems to depend on the language. Django seems to be the established framework for Python, Rails for Ruby, there are plenty of choices if you have some special need.

JavaScript on the other hand....

To counter with an alternative tool comparison: drills and impact drivers look very similar. I'd bet that most of my friends don't really know the difference. But for some situations, an impact driver is an entirely more capable tool.

If you use a drill all day, professionally, you'd be a fool not to take a serious look at an impact driver and see if it makes your life easier.

I don’t think using different tools (which a drill and impact driver really is) is what the OP mean’t. He was more along the lines that must people don’t care whether you picked a Bosch impact driver or a DeWalt impact driver to fix their problem.

And if you explain to someone the difference, they usually get it. Even my daughter when she was five could understand why I had two similar looking things when I was working with them..

But, again - if you're the person using those tools, you care about the difference. The difference in reliability, usability, power, whatever.

That may be the point the OP was making, and if that's so, I'd counter that the point is irrelevant to make. Sure, the user of your software doesn't care what it's written in. Duh. Why should they? If they did, it'd be weird. But the people actually writing the software should care about choosing tools that fit the problem. Not because the end-user will care, but because choosing a more appropriate tool will allow them to build software that gets to market faster, and has fewer bugs and is easier to maintain.

The language as physical tool metaphor is meaningless as far as I'm concerned. Physical tools and programming languages have very little in common. The reason so much is written about programming languages on HN and Reddit is because a language shapes the way you think and anything that alters your way of thinking is a serious matter. Some are expressive, others are not. In that sense a programming language has more in common with a political ideology or religion than something found in a garden shed. That's why programmers - at least those with a soul intact after x years in a Java shop - often obsess over the pros and cons of a programming language. To a craftsman it matters.

DHH once made an excellent defence of programmers as writers rather than engineers and it's perhaps no coincidence that the language he was referring to has ancestry with Perl which was designed by a linguist. Try Clojure/Lisp sometime if you haven't already. Then you'll experience programming as closer to expressive linguistic art than engineering.

My first programming language was Perl and I had to choose between Java and Perl at the time. If you haven't read Larry Wall's "Programming Perl" I recommend it regardless of the status of Perl in the current scene. It's a classic, written in a warm, witty style. 5 minutes with Deitel and Deitel's turgid Java tome and I was sold on Perl. The point I'm making is that choosing Perl over Java as my first language made a huge difference to how I programme today having learned many languages since. I still keep my use of objects to a minimum, prefer functional over OOP and love Clojure with a passion.

Sorry, "just a tool" is meaningless.

As someone who used to put in dozens or hundreds of screws in a day, sometimes:

Yeah, if you're hanging one door maybe you don't care so much. But on door #100, when your hand is covered in blisters, and your screwdriver has rounded off to the point it can no longer put in screws, maybe you'll care which screwdriver you're using.

Philip Greenspun made a similar comment.

"Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can't represent the information that the users need, the application doesn't do what what the users need it to do, and instead of writing code, the "engineers" are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they'd leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet." http://blogs.harvard.edu/philg/2003/08/12/

I don't think this a fair analogy, or that it plausibly explains the wage gap between programmers and doctors. I'm sure doctors discuss the merits of different medical techniques at conferences. In a similar "emergency" situation (e.g. customer demands bug fixed by tomorrow) I have not see anyone agonize over the right tool for the job. In both industries there is a time and place to discuss best practices and how we can improve them. I admit that the programming world seems to have these discussions more frequently.

This is exactly how I feel. Too many developers lose sight of what they actually valued for. Sure there are a subset who we need to be at a higher level to do the leg work on building tools etc, but 95% of developers really are far too involved in issues and obsess over things that distract from their actual role.

Despite what a developer is mostly valued for (delivery), his professionalist on picking the best tools for the job (obviously to his knowledge) should also be expected, so that his client has the best outcome from his work: Deliverable suitable for the use case, performant, scalable if required, maintainable, etc

Comparing the decision of a type of screwdriver to use with a programming language is disingenuous at best, given the vast differences in complexity, switching costs and effects on productivity.

A more honest comparison would be screwdriver choice vs whether to use 80 or 100 character column limits.

So I take it you develop in QBASIC?

to be fair, that would be like using a shovel to hang the door. Just doesn't make sense :)

Indeed. Maybe the original point is better analogized as saying "shovels are better than screwdrivers" rather than comparing two brands. Of course, it's even more meaningless to debate the merits of shovels vs screwdrivers than it is to debate the merits of two different screwdriver manufacturers.

Depends. Is there a web framework for it? ;)

FreeBASIC is actually still around ... and used ...

... for whatever reason ...

In theory, you're right, Java versus Scala is just small difference in how you express the same things in two different languages. In practice, you're wrong. Choosing Java or Scala makes a huge difference in style and culture.

The mere existence of Scala (and Clojure, and Go) as a viable alternative has intensified the bad tendencies in Java culture, the tendencies responsible for the stereotypes of overabstraction, OO overkill, framework bloat, and gratuitous "enterprisiness." In the past, large numbers of people who did not have a high tolerance for those things worked in Java for good pragmatic reasons. They served as a loyal opposition that called out and pushed back against excesses, saying things like, we can't make every call over CORBA, it's asinine to need reams of XML to configure a simple web application, and Hibernate is harder to get right than the thing it's supposedly protecting us from.

The loyal opposition are dwindling as more developers choose Scala and Go for application development. More and more the people sticking with Java are people who were perfectly happy wiring their applications in XML and learning "best practices" from Sun's marketing department. The Java ecosystem isn't going to regress overnight back to those bad old days, but that's the culture you adopt when you adopt Java as a language for application development.

Ah, as my father used to call a hammer 'an American screwdriver'.

> people want functioning door

Sure! And people want functioning software, too. The biggest difference between the two worlds being that maintenance is an exceptional event for a door while being the essence of its lifetime for software.

> They also sell a step-up model whose main difference seems to be that it is made of stainless steel. What will the Germans think of next?

Only stainless steel tools on stainless steel work pieces and vice versa. Don't mix stainless/non-stainless tools and non-stainless/stainless work pieces. Hence stuff like screw drivers will be needed in both variants.

What if screwdriver choice affects how quickly you can deliver your hung door, and how well it will scale and be maintainable in the future?

You COULD write a website in pure ASM[0], but should you?

https://asm32.info/fossil/repo/asmbb/index

That message board is actually amazingly fast. I do think it is possible to do in a language with automatic memory management, though.

I agree, and feel compelled to link this old gem. I never tire of it. http://discuss.joelonsoftware.com/default.asp?joel.3.219431....

Reply on news.ycombinator.com