Hacker News Reader

I agree with the gist of your comment, but this:

> Let's face it, people who go to work with Java projects are not exactly cream of the crop

is a bit of a weird take.

If you're saying that most people working in software engineering aren't "exactly cream of the crop" to begin with, then you probably have a point (I'm a java dev as well, by the way), but I don't see how the programming language changes the equation.

http://www.paulgraham.com/pypar.html

True in 2004, probably still true to some extent in 2021.

So how do you resolve the paradox where a person works in Python and Java? Trust me, they exist. And not only those languages, but a bunch others.

That's still likely to be somewhat true, but it isn't really about programming languages, it's about new/niche technologies vs. established technologies.

By the same logic, Python would now also be in the 'uncool' group, since everyone and their mother uses it.

I think that it was never true. People always find ways to feel superior over random things and the above article was written to please certain kind of readers.

> if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it.

During whole my career, I have found that there are always new things to learn. Learning is not limited to picking new language. And if you work in more popular language, no matter which one, there are always new framerworks, libraries, security issues, performance optimizations, approaches, tools to integrate with, algorithms, you name it.

What he is saying there is either that picking new language matters more then the above. I don't find that convincing.

> So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.

Is a programmer with aesthetic preference against java really inherently superior? I find that whole section low on arguments and high on colorful emotions appealing metaphors.

Not coding in java is often about preference and choice. Not sure where the superiority comes from.

So weird that back in 2004 Python was the "hot new niche language". I guess the modern parallel would be Rust, and now I wonder if rust will eventually be the same as python is now.

Indeed.

* Most software is done in teams.

* If the code is good, it will be in use for a long time.

* Hence if you want to work on software that matters, you will often work with a language that is not your one true love.

Me and my extremely brilliant collegues in my current project write Java, because that's the language the team has chosen. The language, when it's one of the major ones, has no significance.

>>> Let's face it, people who go to work with Java projects are not exactly cream of the crop

You can apply that saying to any language or project. The fact you are biased against Java is a bit disturbing. I know it is cool to be a Java hater but why?

Your comment reminds me of this:

https://xkcd.com/378/

At the university where I teach we used to have two year 1 intro to programming courses: Java and OCaml. The weaker students overwhelmingly preferred Java and the stronger students OCaml. I don't think that was a statistical anomaly in a 200+ size class.

With all the due respect, that's apples to oranges.

It's unsurprising that stronger students prefer OCaml, because it's objectively the more interesting (or at least the more intellectually stimulating) language.

When we're talking about programming languages as engineering tools, a whole lot of ancillary issues must be taken into account. Is the language performant enough? Is the tooling good enough? Does it have good library support? What about C integration? Is it easy do build and deploy?

Java vs. OCaml is precisely a great example of this conundrum: OCaml is objectively the better language by a mile, Java has objectively better support by a mile.

I think you both agree, you just guys don't see it.

I don't know if OCaml is better than Java because I don't use OCaml.

But in general, the better you are at development the greater choice you have. And also better developers on average prefer more powerful tools because for them the steep learning curve is not prohibitive and because they can recognize value of using more powerful tool.

Weaker developers are basically happy they can program at all and most weak developers to settle on the first programming language they learn.

Want to filter out poor developers? Don't hire anybody who only knows single programming language well.

Not because knowing two languages makes you better but because you put effort in learning another language which means you had the curiosity, perseverance and ability to do it.

Learning a programming language when you are good developer is no issue -- I do it in passing just to solve some particular problem and move on. If you are poor developer learning a language might be major effort and accomplishment you may not want to pay for again.

I personally know of no good developer who only knows single language.

In our school, everyone knew that Java is for lesser programmers before they ever wrote a line of it. I actually thought that too and being ambitious, I would go for different course.

Then I matured (both as person and as programmer) and now I don't hold the same views.

I don't want to say that "java is for lesser programmers". What I want to say is developers and companies sort themselves by making individual choices.

The end effect being that if you work for a company and you don't have a huge hiring budget you don't go looking for developers in esoteric languages.

Because then availability of developer is much more important than showing they can pass steep learning curve.

On the other hand developers who can't pass steep learning curve will gravitate to a language without one, where they can be hired more easily.

Does steepness of learning curve mean a language is better or worse? Not necessarily.

Does a person getting into Java development mean the person is bad developer? Of course not.

> The end effect being that if you work for a company and you don't have a huge hiring budget you don't go looking for developers in esoteric languages.

The salaries breakdowns I have seen did not worked like this at all. Esoteric languages paid less. I think it was mostly because those companies were in unstable businesses and because people who like those languages accept pay cuts more often. The salaries for boring languages were higher.

And second, the assumption that only difficult thing that can possibly attract people is difficult/esoteric language is odd. If you are in that situation, then you are in fundamentally easy situation. In fact, forums are full of developers for whom frameworks used in jave world are impenetrably complicated to learn. I can't square that with supposed superior willingness to learn. (I can easily square not liking these.)

> The salaries breakdowns I have seen did not worked like this at all. Esoteric languages paid less.

That's because salary is only one part of the cost. You are looking as if it was the only cost, which is not true.

Finding people for the project costs. Finding people with exotic abilities costs a lot and takes a lot of time which may complicate your plans or require you to have extra staff just in case somebody leaves.

It may pay less because in some specific niches people will work for less just to be able to do what they like to do. If I had ability to join a serious Common Lisp project I might do the same.

> When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin.

I've never used Kotlin, but this is exactly my experience with Groovy. Ten years ago, my department had some Groovy enthusiasts that pushed it heavily, but now we have a bunch of Groovy systems where the majority of the development staff are NOT Groovy enthusiasts, and many are either new hires or low-cost offshore devs with only Java backgrounds. Now all Groovy provides us is the opportunity to experience new classes of bugs that we probably wouldn't see if they systems were written in Java [1].

Generally, I think long lived systems should be written in some kind of "lowest common denominator" language. That's likely to be more easily maintained long in the future. They especially should NOT be written in some other language where someone can get by by pretending it's the LCD language, since that an invitation for bugs wherever the other language violates LCD language assumptions.

[1] My favorite is one where a previous entry-level guy wrote a loop, declared the control variable as a STRING, then used ++ to increment it. Instead of failing fast, Groovy "made sense" of this by interpreting that last char of the string as a char, incrementing that, then coercing the whole thing back to an int for the comparison. This worked, UNTIL the control variable had to go past 9, after which the increment resulted in a ':' and the coercion back to an int started failing in prod.

The name Groovy brings back some old nightmares. Any time a language has syntax reduction as a main feature, it's just optimizing the generation of tech debt.

(Real advances come through safely bundled abstractions, not typing speed)

>My favorite is one where a previous entry-level guy wrote a loop

I'll be honest. I barely write any sort of loop in groovy.

I just checked. One of my projects had 1 for loop and zero while loops. Everything else was done with findAll, collect, each etc.

Findall/collect/each are not replacement for for loop. They only replace special case of for loop where you are not interested in the value of index.

In general, applications that just process collections of items and running some logic on them can most of the time get away without using for loops, as is probably your case.

>"Let's face it, people who go to work with Java projects are not exactly cream of the crop"

Here, fixed it for you: Let's face it, people who go to work with any software projects are not exactly cream of the crop.

This is natural. You have bad performers, meh performers (a majority) and top performers (a minority) and it goes like this in almost every area of human's productive activity.

Different type of developer is drawn to different types of languages and different types of projects.

Developers who barely can write loops don't go write games in C++. They are much more likely to go write corporate backends in Java because corporations are notoriously very bad at sorting who is good and who is bringing negative value.

Game developers have their own meh level. It is just different from that of corporate backend developers.