Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I started with Java 1.0 and thought it was great. I still do, although I haven't used it since 2020.

The only thing I don't like is how there is no built-in JSON package which seems like a necessity these days.

Removing the public static void main(String[] args) business seems like pandering to a non-existent audience, or at least a miniscule and insignificant one. Anyone who is going to use Java for a real project is not going to be worried about that, and anyone who thinks that's too difficult to deal with is never going to be a good programmer anyway.



The last part seems like a very 'gate keepy' point of view.

If you want to introduce someone to programming, you probably don't want them to worry about what all those 'magic words' do.

At least for their first steps, they won't need to know what a class is or what `public` and `static` mean.


I think gp is right, and I don't think it's gatekeeping. I thought this about Java, it was easy to criticize its verbosity, but I realized how insignificant this is when actually practicing it. There's probably way more interesting and deeper criticism to make about Java.

About the first steps of a newcomer, there's always going to be some level of "don't worry about this now, we'll see what this means later" for any language. I remember this to be the case for every tutorial I read to learn a language. And it's fine, as long as you can try stuff and it doesn't get in the way.

I'd say it's more important for a language and its vocabulary to be well structured and well documented for a newcomer and Java does quite good on this front.


GP is right. If the words public static keep you from learning how to program you were never going to learn anyway. If I introduce someone to soccer and they quit because they couldn't figure out how to put their shoes on, chances are they werent going to learn how to play no matter what.


I think the converse(?) to this though is that the words public static are inconsequential.

Sure, if you are incapable of learning what a couple adjectives mean you won't go far, but that holds for much more than software.

Rather it's not important that the ball is big and blue so much as that you can kick it across the field - learning what the ball means can come later, but it's just unimportant noise (to start).

Java is pretty bad at this, though, insisting on specifying unimportant details up front rather than allowing for qualification. This is OK for a large monolithic application with complex requirements and a litany of edge cases, but inappropriate for many smaller use cases.


Did you know that the first thing John Wooden did with incoming freshman collegiate basketball players at the most prestigious program in the country was teach them how to properly put on their socks?


Agreed.

I still feel like the author is missing the forest for the trees. Bash is not great to write e.g. a red black tree in or do complex image processing, but you don't have to maintain a Java install, download libraries, or setup an editor with an LSP (and really, calling java script.java 10 asdf? Why do I need to invoke Java at all? At that point, I'm probably going to wrap it in a script anyways...)

Python has its own issues but it's a small, embedded install that you don't have to accept 5 different licenses for and worry about it being able to get the same version...

And bash? That's what pacman -S jq is for - anything I can't easily do in bash or batch I just offload to a small utility written in python or rust.

Java is, at it's core, just too heavy, IMO.


pacman -S jdk-openjdk, this is the reference java implementation and it has the exact same license as the Linux kernel. And java has never done such a breaking change as python did.

There is also jre-openjdk-headless, for 140 MB. How is that any different than Python?

This "java too heavy" is like 30 years out of date, if it has ever been true.


Quick check via msys2:

"error: target not found: jdk-openjdk"

> And java has never done such a breaking change as python did.

I'm not really sure that's true? Java 8 to afterwards, there are breaking changes that mean a lot of old enterprise stuff can't easily move forward, or worse, bytecode incompatibilities mean source-code-less stuff can't be used anymore...

The whole thing about Graal is mentioned almost as an afterthought, my point is that the language etc. is so poorly designed as to be prohibitive to interface with unless...well you're on Java. Yes there are bridges etc, but a big point of the shell, bash, etc. is easy interoperability between many programs, etc.

Java is still today stuck in a mentality of "it doesn't exist if its not in Java", which is why yes, 30 years later, it is still "too heavy". Assuming you are the effective Operating System is an extremely heavy assumption.


> and it has the exact same license as the Linux kernel

Also, I neglected to touch on this point more, perhaps license is not the right word, as much as distribution - I don't know if you have ever tried building the JDK (not simple), or worked with the official JDK vs the open one (not the same functionality), or tried to access old versions of the SDK on the official websites, or had to deal with their installers, etc.

Giant headache and all around.

Not to mention, even if your pacman command works, this is still simply not comparable, the example I used was for installing a jq binary because JRE simply doesn't include this functionality by default...

And now you need the overweight pom/gradle mess to interface with the Java libraries because <insert technical debt reasons here>


The official JDK is the OpenJDK for several years.

Under Sun there were differences, but Oracle open-sourced every last difference and now there is only some Oracle branding logo as the only difference (and maybe some tiny proprietary codec, but your code will run on both the same way).


Some people write programs that do more than simple scripts


> If you want to introduce someone to programming, you probably don't want them to worry about what all those 'magic words' do.

I learned Java when i was 15 or 16, reading some random book first and then I stole 35 euros from my mother's purse and bought a copy of "Java how to program" by deitel and deitel[1]. The recommended version at the time was Java 5, and the SJCP certification was still issued by Sun Microsystems.

I can tell you, "public static void main" is not going to be the problem.

[1]: looking back (i'm in my 30ies now) sometimes I wonder if i would have been better off buying weed or alcohol (or both)


So you believe that your experience is a universal one for all learners? Cognitive load is a real consideration in teaching, and having to ignore and filter text is challenging for some folks.


The boilerplate around a main function is 10 units of load. Everything else you have to know to write a simple program is 500-600 units of load. The boilerplate is a rounding error, and just does not matter.


Yes, all people are different, and some are smarter than others. Education funding won’t change that.

Way to disparage a random person on the internet.


Mostly yes. Given how much there is to learn, public static void main is not going to be “the problem”.


As mongol said in a top-level comment, Java isn't a great language for programming "in the small". It's not a great language for a casual user - or rather, there are languages that are significantly better. If you want to introduce someone to programming in a semester course, "public static void main" isn't going to be a significant hurdle. If you want to introduce someone to programming as a 14-year-old, maybe don't start with Java.


Why? Java is a small language with not many concepts, that is typed so many of your first attempts will be caught with helpful messages at compile time, and it fails safely at runtime with error messages pointing to an exact line number. Besides, it is a language that is actually used in the industry and has one of the biggest ecosystems. It's also plenty performant, can be low-level enough for learning about all kinds of data structures/algorithms, including concurrent ones and has probably the best tooling (IDE, debugger, etc)

What other language would you start with?

And isn't it easier to introduce concepts one at a time? For that reason implicit classes makes sense, and also for the occasional scripting, as in doing something one-off, but it is not as trivial that I can do it with piping 3 commands together.


> Java is a small language with not many concepts

True. But you need to know too many of them to get anything to run.

> that is typed so many of your first attempts will be caught with helpful messages at compile time

But it doesn't feel that way. It doesn't feel "helpful", it feels nitpicky. It feels like I have to get everything exactly right before anything will run. For a raw beginner, that's very frustrating. It is (emotionally) better to have something run as far as it can run, and then crash. (I agree that exceptions pointing to the line number are very nice.)

Again, for a semester class, the startup overhead for learning Java is too small to worry about - it's maybe a day or two. But for someone on their own, not in a class, a day or two is a huge investment to put in before they can get something running!

What would I start with? Something with a REPL. (It could be a language that is normally compiled, but there needs to be a REPL. Raw beginners need to be able to get something, anything, to work as quickly as possible.)


Yeah, you want to start with basic imperative programming with as little cargo-cult nonsense in the way as possible.

Your csci 101 kids will not benefit from unpacking what it means to compile an object-oriented language down to bytecode to run on a virtual machine. It's not that it's not valuable knowledge, they just won't have the context to make meaningful heads or tails of it.

related: I still puke a little remembering the requirement that students work on assignments in emacs on terminal machines rather than their text processor of choice(which was fine for me, but why on god's green earth would you put usability warcrimes like 'hjkl' in the way of someone just starting to learn? No wonder nobody in the early naughts wanted to learn to program...).


A lot of people learn to program from declarative languages like spread sheets. We should all be happy we have access to defective versions of assembly at too high a level but be angry that we had to use too low level an editor?


You shouldn’t try any modern programming language until you’ve mastered GOTO and GOSUB and know why lines are numbered in multiples of 10.


I think this is a really important point, even though I suspect you're joking.

Along with all the BS boilerplate text this specific post talks about eliminating, which is great, we simply forget how much legacy tech BS we just assume.

Beginner programmers should not have to know what a "file" is, or what an "editor" is, or that they need an "editor" to "edit" a "file". This is technical debt: these are implementation details which should be invisible.

This goes double for "compilers" versus "interpreters" and "source code" versus "binary code". FFS the noun _code_ means _a system for rendered text unreadable_.

You have a computer. You are talking to it in words, words which resemble English because that is one of the simplest world languages when you think about scripts -- writing systems -- as well as sounds. Hangeul is easier but only works for Korean which is harder than English. Grammatically Chinese is simpler, but spoken Chinese has tones which are very hard, and written Chinese is insane. Typed Cyrillic is no harder but handwritten gets weird and complicated and Russian is much harder than English. And so on.

English wins and so we talk to computers mostly in English.

So, you have a computer, and you type on it in English. That is all you should need to know: how to enter text, how to correct it when you get it wrong, and that is it.

BASIC has a great virtue which all the Unix and even the Lisp fans forget:

It's designed to work at a command prompt. Type a command, the computer does it. Give it a number, it remembers it for later.

This is a profound and important metaphor. It eliminates all the 1960s/1970s legacy BS about "files" and "folders" and "editors" and "compilers". Beginners don't need that. Let them learn that later if they prove to have real aptitude and want to pursue this.

Type a bare expression, the computer does it. Number it, the computer remembers it for later. That is all you need to get writing software.

And just like Python sorted out the problem of spoiled whiny little baby C programmers whinging about their pathetic obsessions with indentation patterns by making indentation semantic so everyone has to comply, line numbers in BASIC are a vital simplifying unifying mechanism, so lean on them: for beginners, make line numbers syntactic.

Don't force kids to learn pro tools like nomenclature and hierarchies. Give them a toy that they can get started with.

At first, they can structure their programs with line numbers, and they learn about leaving space, about RENUMBER commands, about LIST x TO y ranges, and stuff like that, because we are not using a bloody Commodore 64 any more.

But give them IF...THEN...ELSE and WHILE...WEND and REPEAT...UNTIL and named procedures so they can learn structure and not GOTO.

All the rest is baggage and should be deferred as late as reasonably possible.


The reason we use the words "code" and "coding" how's the history behind it. Originally it referred to translating an algorithm description into machine code. Indeed something less readable. The first compilers were called "automatic coders". I.e. their input wasn't code, their output was. Originally the word "compiling" referred to putting together an image of library functions. Something more similar to linking. The terminology shifted and drifted as time went on.


Emacs doesn't use 'hjkl'. I think you weren't there in the 90's...


Evil mode ;-)


I'm of two minds about it. On the one hand, the verbosity is arguably noise if you are first learning to program, or just want to write something quick, so I can see why people dislike it.

On the other hand, viability, classes, and "staticness" are all fundamental structural concepts in Java. Hiding them for a special case is sort of like lying, and, in the long term, I can actually see this special case causing more confusion for new learners. It's sometimes better to be upfront and transparent and force your users to work with the paradigm and semantics they chose to adopt, rather than pretend it doesn't exist. If Java had been designed to allow for top-level functions from the start, it'd be a different story. I think special casing is a generally bad way to evolve a programming language.


But there is absolutely no hiding, the design is very smart!

You simply get an unnamed implicit class like `class Tmp367 {` written at the top, and the runtime loader has been modified to be more accepting of main methods. There was basically a tiny language change, and no bytecode change, java semantics are just like they always were.

The Main loader just simply will accept an instance method named 'main' for a class with an empty constructor with no args, instead of psvm.


It's hidden from the newbie who never used java before, that's what we're talking about. As you said, all that stuff is done implicitly. The user never sees any of that unless they go digging.


> Removing the public static void main(String[] args) business seems like pandering to a non-existent audience, or at least a miniscule and insignificant one.

Perhaps the audience doesn't exist because of that business. There are many times when I would have used Java over Python to write simple programs for no other reason than having the ability to create a GUI without resorting to third-party libraries. Yeah, Python has tk but it has never clicked with me in the sense that Swing does. Unfortunately, cramming every last thing into an OOP model means that simplicity is rapidly lost. (The same can be said of Python, except Python has not forced it. Java, historically did.)


I agree that for experienced programmers working on large projects a little bit of verbosity around `main` is insignificant. But first impressions matter, especially when there is pervasive word of mouth about "verbosity".

Pretend you are a college student and you are taking your first programming class (e.g. CS 1) and your friends have told you that Java is "verbose". You start with "hello world" and you have to type `public static void` etc. One of your friends shows you the same code as a Python 1-liner.

Or similarly you're a beginning programmer in the workforce and your employer asks you to solve a problem using Java. You've heard Java is verbose and when you start with "hello world" you find that what you heard was true.

This is not a non-existent/minuscule audience. They should have fixed this decades ago. Better late than never.

I've been impressed with the modernization of Java over the last 10+ years. Simplifying "hello world" is a minor change relative to the others, but still an important one.


> But first impressions matter, especially when there is pervasive word of mouth about "verbosity"

I watched most of my comp sci 101/102/201 classmates fail out because they didn’t want to understand how things worked, they just wanted to make a lot of money.

Edit: hn even helped me prove the point: https://news.ycombinator.com/item?id=42457515

Teach that to a 10 year old, where their primary keyboard experience is a phone.

More than that, if rust is the future, which I have seen espoused before, picking on the Java keywords and syntax is highly amusing.


I did cut my teeth on Java back in middle school-ish. It never bothered me at all, I was too busy having fun learning to program. I agree with GP, the mandatory class is a completely overblown complaint about Java.


If you think Java boilerplate is bad, wait until you have to learn about ELF file formats in order to execute almost everything else.


The problem is when java is used as a first language, this is needless complexity that gets in the way of the actual fundamentals of programming. Access privileges are irrelevant for a beginner who is hopefully not writing libraries that will be consumed by anyone. The distinction between an instance and static method is also confusing and irrelevant. It's just pointless ritual for the student.

Now, if one is learning java as a second language, that's a different story.


javax.json has been around since Java 7.



> It's part of Java/Jakarta EE.

If it's part of J2EE, it's in practice "part of Java" since the JDK comes with the J2EE packages built-in...

That is, it came with the J2EE packages built-in, until Java 11 decided to break everything, and force people to get each piece of J2EE from a separate upstream project, with AFAIK no "all of J2EE" uber-jar you could simply copy into your project to restore the status quo. It's no wonder so many projects are to this day stuck on Java 8.


> since the JDK comes with the J2EE packages built-in...

Are you sure about that? I just downloaded the Java 8 JDK, and javax.json is not there. And the documentation doesn't mention it either. What am I missing?


The JDK doesn't include all the J2EE goodness: https://docs.oracle.com/javaee/7/api/javax/json/package-summ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: