Anecdotal, but I had an intro to programming class in high school and the teacher was a wonderful woman, but not a programmer. She didn't know that this was a function declaration or its meaning, so she would just have us repeat out loud "public static void main string box args". I get a laugh whenever I think of that. I hope she's doing well.

I had an Excel class 20-25 years ago where a teacher explained click and double click every class, and emphasising "DOUBLE CLICK" out loud every time she did the action... There were a few facepalms.

The next class was assembly programming, where the teacher didn't bother to show for 4 months and then resumed the class as if we "self-taught up until this point". We were utterly lost in that one.

I imagine things have changed greatly today but back then it was a complete roller coaster.

In elementary school we had a "class" with the "computer teacher" once a week. He was just one of the only adults on the school district payroll who knew how to turn on and off an Apple //e. Nice guy (he also volunteered at the same community theatre I did), but "computer class" was just letting us loose with copies of Fraction Munchers and helping us if we jammed the disk drive or whatever.

I remember being 10 and going to a computer lab full of power macintoshes and playing sim city 2000, kid pix, and Carmen San Diego. This was in between looking at a cd encyclopedia (encarta?), old computers were awesome ;)

Wow, you reminded me of two experiences at once.

I wasn't good at getting educated, but I ended up at a community college to "get my generals" - my first class of the day was computer something or other, and the class was led by a man in extremely thick glasses who said that our general approach in the course was going to be:

  * perform actions with the computer
  * take a screenshot
  * paste the screenshot into mspaint
  * print out the screenshot as proof that we had completed the thing
  * put that in a folder
  * he would review the folder for completion 

(for anyone paying attention, anyone could just print out multiple copies)

While it was a significantly younger and less experienced me who quit this bullshit in an absolute huff, I don't know if I could go through it today.

Fast forward a few years later, and I was training folks on tech support(a random reversal) and I had a lady who should have taken his class... every time I told them to click on something she asked "is that right click or a left click?" and each time I would respond "its a left click unless I tell you otherwise" (she didn't last long.)

A lot of Java professors did that in the past, because the "not hello world" parts of "hello world" require a bit more understanding, and in the spirit of getting people started, the idea is to just say "hey memorize this boilerplate stuff, eventually you'll understand what it means."

I haven't written Java in a million years.. so I'm trying to understand better.

But what does this code even mean..? Isn't Java's whole simplifying model that everything lives in "Objects"? This seems to break that fundamental paradigm and makes the language more complicated. If you needed something like global functions then in vanilla Java as I remember you'd stick it into static final Objects that acts as a namespace of sorts. So you don't need to worry about functions floating around in a global namespace soup.

If you're gunna just have free floating functions in your file.. then why not just cut to the chase and have a

    println("Hello world");

floating in your file..? (I mean... you don't have REPL so maybe that wouldn't be too meaningful...)

  > you don't have REPL

(ahem) https://docs.oracle.com/en/java/javase/23/jshell/introductio...

only since 2017 :) people basically judge java based on what you learn in AP CS which is basically (a dumbed down version of) java 6 (released 2006).

It’s honestly the only programming language that will get its 1996 version compared to a new 2025 version of another language. And the only language that will be criticized by someone who last used it in 2006.

PHP gets the same treatment all the time.

PHP and Laravel are amazing.

I have been developing Java for a long time and my brain tends to stay stuck in Java 8 mode a lot of the time.

Definitely not the only language. Other long-lived languages like C++ get this treatment too.

> And the only language that will be criticized by someone who last used it in 2006.

You don't sound like you work with Java. I know for a fact that even some FANGs, with their army of software engineers, still use Java8 for most of their Java projects.

Historically an upgrade could cause issues if the code or dependencies used undocumented functionality (like Byte code manipulation) or calls to native code, or the transitions to modules in v9. Upgrades after version 11 should be less "risky" and be easier to argue to management.

From what I can tell, there are 4 main reasons why some don't upgrade.

1. They have legacy software and are afraid of breaking it, sometimes with good reasons.

2. The devs don't know or care enough about the new versions to bother with it. Noone is promoted because of an upgrade. Work to live, and don't live to work

3. The ones who don't have buy in from management to spend time fixing something that works

4. They are using version 11+ that should be much safer to upgrade than earlier versions, but they are still in the mindset of 1 or 2 above

There have been huge improvements not only in the language itself, but also performance and memory use. They could save money if they upgrade, but in some cases this is acceptable because they can make more money by spending time on a new feature, than an upgrade.

In my last 3 workplaces, they usually tried to use the latest LTS versions. But to be honest, some of the services were in maintenance mode and we didn't get enough benefits to upgrade, so we were sometimes falling behind. Today we have a mix of v17 and v21. Anyone can upgrade anytime they want but noone cares about a service that you seldom work with. I feel kind of bad for that, but not enough to bother. I focus mainly on the services that I work with daily, and make sure they are using the latest versions

> From what I can tell, there are 4 main reasons why some don't upgrade.

You missed the most obvious reason to not upgrade: there is no good reason to do it.

> There have been huge improvements not only in the language itself, but also performance and memory use.

That's debatable, and even if we blindly assume that then it's debatable whether the upgrade justifies the gains.

More often than not, it doesn't.

> That's debatable, and even if we blindly assume that then it's debatable whether the upgrade justifies the gains

This is not debatable. It’s a factual truth. Every single actual performance review concludes that modern Java vastly out performs the decade old Java 8 runtime.

For an example here is a quote from Hazelcast when comparing performance of modern Java on data heavy workloads [0]:

> JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses.

This is from 2020 and the gap has only gotten wider.

[0] https://hazelcast.com/blog/performance-of-modern-java-on-dat...

I work in Java every day and have upgraded my entire companies fleet of services to Java 21. FANGs are nothing special. And every actual survey shows that there are as many people on a runtime > 8 as there are people on 8:

https://www.jetbrains.com/lp/devecosystem-2023/java/

> And every actual survey shows that there are as many people on a runtime > 8 as there are people on 8:

I don't think you even bothered to read the sources you're quoting, and you're just trying to make baseless assertions.

The very first question on JetBrain's survey is "Which versions of Java do you regularly use?", and 50% answered Java 8 with around 2% mentioning Java 7 and 1% answering Java 6. On top of that, Java11 alone comprised around 38%.

And you're talking about Java21? It doesn't even register in the survey at all.

I'm not talking about Java 21 when referring to that data, I was refuting your baseless claim that I don't work in Java. I don't think you even bothered to actually read or comprehend my comment.

The data there clearly shows that the ecosystem has as many users running a modern version. Which directly counters your assertion that everyone is just running 8.

> people basically judge java based on what you learn in AP CS which is basically (a dumbed down version of) java 6 (released 2006).

I don't think people realize Java8 was until very recently the dominant java version in production software, and currently close to 90% of all java projects still run on java11 and earlier.

Edit: after checking New Relic's 2024 report on the java ecosystem, it sounds like java11 and earlier is now at slightly over 60%, with java17 being used in around 35% of the projects.

For software written in that era currently under maintenance mode, I don't expect people to upgrade their java language version though upgrading their JVM is a good idea.

Try doing a cold load of JShell though. Can easily take 2 seconds on a rather fast machine. People will never use it as a quick REPL for that reason.

I use it as a repl all the time. IntelliJ can load your projects classpath into too. It’s really awesome.

Thanks, I'll give it a shot in IntelliJ.

docs if you're interested: https://www.jetbrains.com/help/idea/jshell-console.html

It's implicitly still a class, you just don't need to write all the scaffolding to indicate that. The functions are still methods of that class etc.

But, yes, with static imports, you can just write "println" like that and have it work.

> It's implicitly still a class, you just don't need to write all the scaffolding to indicate that.

did you know that every function in a python script is actually an attribute of that module (which is basically a class). so my point is: who cares.

geokon's point still stands. This is meaningless syntax sugar that does not change anything fundamental about Java except add one more special rule into the language aka it is one more thing to learn. Rather than being helpful, it just becomes friction when an old developer uses the old method and a new developer uses the new method.

You still need to know what a main class is, so that you can reference it in your build.gradle file.

If you're using a build.gradle file then you probably won't see any benefit to this implicit class, yes.

But it's useful for little one-off scripts, where you just go `$ java foo.java` from the command line.

I'm having such a hard time figuring out whether this is satirical.

(My guess: It is.)

I know, right?

> So you don't need to worry about functions floating around in a global namespace soup.

Because having classes floating around in a global namespace soup is fundamentally different and should give no worries to anyone. Yet this was argument made in earnest back when arguments about Java's strengths and weaknesses were much more popular.

There's always going to be a namespace soup but at least in Java there's only one kind of thing in the soup.

The famous "anemic namespace soup" language design pattern.

Hey, it could be Perl!

With the 1:1 intended correspondence of (public?) class names to source file names I get how that could be considered a feature for ease of use, compared to C++ where any file could define any name.

As others mentioned, there is an implicit class here in play.

Basically, imagine a `class Temporary4738 {` and `}` written above and below the .java file's content, that's roughly how it will behave.

It not having a fixed name is deliberate, so if you decide to build a bigger system you won't use this mechanism in a hard to maintain way, and also it needed a good semantic model for "top-level" variables/fields.

But with this implicit class model, top-level definitions are just fields of the class.

> As others mentioned, there is an implicit class here in play.

The same strategy is also followed by C# with their top-level statements. And yes, it's syntactic sugar.

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

Because this is the entrypoint? Having code exec out of an explicitly defined entry point that's an entire file sucks.

> This seems to break that fundamental paradigm and makes the language more complicated

Welcome to the last 10+ years of Java. They're trying to play catch-up to other languages that made fundamentally different and better choices, making Java more and more complicated in the process. They are so deeply entrenched in the enterprise back end space that programmers put up with it, nay, even feel grateful for it. People who are stuck using Java for the rest of their careers are happy to see it grow to accommodate 21st century programming techniques, even if it means that it becomes so complicated and crufty that no beginner will touch it ever again.

In java's defense -- and I share your criticisms -- it offers some very nice things that no other language has.

eg want to run code for 6 months at a go managing hundreds of gigs of data, tens of thousands of threads, at high load, with sustained gigs a second of garbage generation? the jvm will just silently tick away doing just that while being nearly bulletproof. As much as I love ruby and python, you ain't doing that with them.

With hot code loading, introspection, etc. All the stuff that makes developing super-robust long-lived systems way easier.

And the flip side of the clunky language is your code from 20 years ago still works.

Also, conservative feature adoption works in the long term.

Scala mainstreamed a bunch of concepts that java was slow to adopt, but the end result was java only took the good ideas and didn't take the bad ideas.

Fortunately, you don't have to use Java to use the JVM. There's Kotlin, Scala, Clojure, etc., all of which are simpler languages.

It doesn't surprise me; that sounds exactly like how C++ has progressed (sans the enterprise beans, hopefully).

10+ years ago I considered myself proficient at C++. It made sense, I didn't mind the pointers, and while the std library still felt clunky, it was fine. But I tabled these skills, and they indeed rusted a bit, but surely I could bring them out when needed again, right?

Smart pointers with multiple variants, judicious use of macros, rampant use of double colons to ensure proper namespace resolution (which IMHO makes the code an absolute eyesore), to name a few. I won't argue these changes aren't necessary, but it isn't pretty.

> Global namespace soup

Packages still exist.

It’s just not necessary to add an additional level of namespacing.

Statics never were some pure OOP anyway.

Song version: https://www.youtube.com/watch?v=yup8gIXxWDU

what did i just witness....

One of the best metal band Italy has on offer, that's what you just witnessed.

SEMICOLON!!!

Thanks for sharing this. I watched it while both enjoying and cringing at it.

this is actually fucking amazing :D

Really Java has always been kinda okay - the really horrible part of Java was always the "enterprise OOP" programming patterns that were basically a given in any commercial codebase - little things like pointing out the verbosity of a basic single file project are just shorthand for "look at all this shit people have written".

As the adage goes - Java programmers can write Java in any language.

... But if they do make it in Java, at least you have the tools to analyze and refactor it.

You mean stuff like in the 'Design Patterns' book by the Gang of Four? That was originally written for C++ programmers and predates Java by a few years.

Seems 'Java programmers' were already writing Java before Java's release ;)

Python programmers be like:

  from __past__ import JavaProgrammer 

  /usr/bin/python: error: line 0: not a chance

That is something yet different.

Is the problem design patterns or opaque frameworks that rely on a ton of reflection?

Afaik, at the time issue was a lot of programming in xml - where those frameworks are configured in various xmls and hard to understand and maintain. Reflection based frameworks are later development.

“In XML” is neither here nor there.

The massive amounts of indirection which the IDE wouldn’t help you understand was the difficult thing. What encoding you use for that is pretty irrelevant. JSON would have been worse.

The indirection in Java itself matter significantly less, because you ctrl+click and it gets you where the things are. Plus auto completion. Both were part if Eclipse years and years ago.

The problem with xml was that IDEs were unable to help you.

I disagree. Working through each keyword until you understand the full signature felt great when learning.

It’s the Python if __name__ == __main__ trash that was the worst. You’ll never understand it and it doesn’t fit in the language.

Python seems to have started with 'why do those other languages have all this trash' and then spent the time since then learning why and coming up with worse versions.

I use python a lot these days, and like it, but it's pretty funny seeing stuff like the above and type hints.

I hate not knowing what types a function takes and returns.

> Python seems to have started with 'why do those other languages have all this trash' and then spent the time since then learning why and coming up with worse versions.

This seems true to me too. Examples:

* if __name__ == "__main__": main()

* Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature

* @staticmethod as a decorator instead of being a language feature

* Duck typing vs. abstract base classes

* Static type hints got retrofitted to the language gradually, one feature at a time

* Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true

* Having a GIL instead of being truly multi-threaded from day one

* Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references

* Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).

The whole switch/pattern matching thing is a true abomination borne from: Well, things in statement position can't be expressions (or however Pythonistas might phrase it), so clearly switch/pattern matching must be a statement... It's such an own goal and undermines the main point of pattern matching.

(I do realize that there was opposition on this, but that the Clearly Wrong side won out is baffling.)

Same principle behind Python's crippled lambdas.

Yeah, it's a shame for Python. I am extremely impressed that Java 14's switch expression ( https://openjdk.org/jeps/361 ) is a generalization of the switch statement (since Java 1.0); it's like they took a page from Rust's language design. I have found the switch expression to be quite useful in my work.

Probably from ML/Haskell, but yes :)

Your quibbles show either a) a fundamental misunderstanding of Python or b) are just flat out incorrect.

> * * if __name__ == "__main__": main()

So, don't use it. Python is frequently run as a scripting language (something Java is fundamentally bad at) and this stems from that. All it does is box logic off when a file is being run directly vs imported. It's a user convention and not a language one....ignore it if you hate it so.

> * Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature

This is all very well explained in the PEP. The quick run down, Python doesn't do anything to hide logic from users. Contracts are just conventions and python treats it that way; so the developer can say "you shouldn't use this directly, here's a notation to let you know", but nothing will stop a developer from doing what they want. In Java they'll just write a wrapper class, inherit the base class, and expose that logic. Or worse, fork the library just to edit the class' functionality in some minor way. In Python they'll just call it directly.

> * @staticmethod as a decorator instead of being a language feature

@staticmethod is a built-in, it is a language feature. It just doesn't follow your preferred syntax.

> * Duck typing vs. abstract base classes

You can do both in Python:

https://docs.python.org/3/library/abc.html

The concepts aren't mutually exclusive or even directly related. Java just happens to be bad at one of them, due to it's weirdly non-effective (for a VM'd language, at least) reflection system; so you think it's bad.

> * Static type hints

You're complaining about reflective programming and then complaining about a feature that essentially exists because you can't reflect. It's circular.

> * Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true.

GC arguments have run for decades and everyone has their opinions.

> * Having a GIL instead of being truly multi-threaded from day one

Python was created in 1989. Java was created in 1996. Can you guess what major change in computer history was happening around the latter's time?

Everything was GIANT-locked when Python was designed, unless it was specifically intended for SMP mainframes. The entirety of the FreeBSD operating system had a GIANT lock on it at the time, for instance. Linux didn't even exist. Mac OS and Windows both were fundamentally single threaded and cooperatively multitasked. Commercial Unices that supported SMP were only ~4-5 years old and a very small niche.

You might as well be complaining about "why didn't the x86 architecture just have 64-bit capabilities from the outset?"

> * Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references.

In other words: "it's not Java, so it's bad".

Java is a pure-OO language; Python is a procedural language with OO as an optional feature. To that end, it exposes OO-features in an optional manner versus forcing you to use them against your will.

So if the basis of all your arguments is "OO is better in Java", well the the response is "yeah I'd hope so, since you have no other choice as it's the fundamental paradigm". Guess what? Haskell is much better at functional programming than Java; that also doesn't make a valid argument about whether either is good or bad.

> * Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).

Java was developed 7 years later and during a time that Unicode was becoming the standard over ASCII. Python was designed when everything was still ASCII and Unicode a mere glint to the general computer science realm.

As you pointed out, even Java made a bad decision here due to their premature adoption of the standards (as any modern designed language is quick to point out).

And your reply is half right, half wrong. Let me address the wrong parts.

> Duck typing vs. abstract base classes / You can do both in Python

I'm saying that the original intent of Python was duck typing, but then people realized that abstract base classes play an important role - e.g. isinstance() testing, static type annotations. So they still ended up where Java started.

> Static type hints / I don't even know what that means.

I'm saying that Python was designed with no type annotations on variables (though values did have types), and then they realized that people wanted this feature... and ended up where C/C++/Java/C# have been all along. Python became "enterprisey".

And then, Python implemented type hints rather badly from 3.0 through 3.10 and beyond. It doesn't include types in the official documentation, so now you have to guess what open() returns (it's typing.BinaryIO/typing.TextIO). It doesn't have an official type checker, instead relying on third-party tools like mypy. It moved items between typing and collections.abc. It requires `from future import __annotations__` for non-trivial programs. It changed typing.List to just list in 3.9. It introduced the | (union) operator in 3.10. And a bunch more little things I can't recall; it just had a bad out-of-the-box experience and kept tweaking things over the decade. Documenting generics and especially protocols in Python takes effort.

> Python was created in 1989. Java was created in 1996

Wrong. Java was created in 1991, and the first version released in 1996. https://en.wikipedia.org/wiki/Java_(programming_language)

Python 1 was released in 1994, and 2 in 2000. They had their chance to make breaking changes. https://en.wikipedia.org/wiki/History_of_Python

While you're right that Python predates Java, it's not by as many years as claimed.

> Various OOP concepts that are much better explained in Java than Python

To exemplify, here is how you figure out how to override `==`: https://docs.python.org/3/library/stdtypes.html#comparisons , https://docs.python.org/3/reference/expressions.html#express... . Notably, there is no documentation for object.__eq__().

Here is the Java version: https://docs.oracle.com/en/java/javase/23/docs/api/java.base...

Now for __hash__() / hashCode(), the Java version is clearer: https://docs.python.org/3/reference/datamodel.html#object.__... , https://docs.oracle.com/en/java/javase/23/docs/api/java.base...

Python __del__ is buried in the "Data model" page: https://docs.python.org/3/reference/datamodel.html#object.__... . Java's finalize() is easily found on Object: https://docs.oracle.com/en/java/javase/23/docs/api/java.base... . Furthermore, Joshua Bloch's book "Effective Java" has a chapter titled "Avoid finalizers and cleaners" that explains in detail why finalizers are problematic.

Python explains a lot less about weakref than Java: https://docs.python.org/3/library/weakref.html , https://docs.oracle.com/javase/8/docs/api/java/lang/ref/pack...

> Java is a pure-OO language

Extremely wrong. Java has primitive numeric types, which do not have methods or fields, and undergo painful boxing/unboxing conversions to interoperate with the OO world. Whether the performance benefits are worth it or not is debatable, but what's not debatable is that Java is not pure OOP. Some say that Java is a bad copy of Smalltalk, which I heard is fully object-oriented.

> Python is a procedural language with OO as an optional feature

Wrong. Every Python value is an object that can be inspected (dir(), .__dict__, etc.). And in the CPython API, every Python value is a PyObject*. I have ample grounds to believe that Python is more OO than Java.

>Wrong. Java was created in 1991, and the first version released in 1996.

Gosling and others started working on it in 1991, but does it really matter? First public release is when you can learn about it and borrow ideas. It doesn’t make your point less valid, of course - Java made a lot of hype back then.

> Python 1 was released in 1994, and 2 in 2000. They had their chance to make breaking changes. https://en.wikipedia.org/wiki/History_of_Python

You're purposefully fudging dates to make the argument more favorable to your point. If you want to argue initial source release, then you can maybe make the point for 0.9:

> In February 1991, Van Rossum published the code (labeled version 0.9.0) to alt.sources

And say that Python had it's initial release just slightly before Java had begun design specs. But Python was in use before that and Rossum had developed the initial version well before that (again, 1989):

> The programming language Python was conceived in the late 1980s,[1] and its implementation was started in December 1989[2] by Guido van Rossum

It's ironic that you're trying to make that same argument for Java and dismissing it for Python, when Python was very much in public use pre-1.0 and Java was not (outside of internal teams).

> Wrong. Every Python value is an object that can be inspected (dir(), .__dict__, etc.). And in the CPython API, every Python value is a PyObject*. I have ample grounds to believe that Python is more OO than Java.

I feel like, just based on this point, you've done nothing more than open the CPython source code and searched for "object". This naming was in place well before Python even had any of the OO-functionality that exists today (new-style classes derived from the Object type). If you're going to argue for "old-style" classes being OO in any way but name, you're probably going to fundamentally disagree with any OO fundamentalists, the designers of Python itself, and the Java community/designers. You might as well argue that structs with function pointers in C make it an OO-language, as that's functionally all they are.

PyObject doesn't correlate to a Python class/Object. It's a container data structure to allow for their duck/dynamic typing. Object is a type of PyObject; but it contains an additional layer of functionality to make it a Python Object (specifically PyMethodObject and PyTypeObject, and their correlative functionality). Again, to allow for the reflection/introspection and GC that you so bemoan; and due to the lack of C generics at the time (or really, even today). Being able to introspect a type has nothing to do with it's "OO-ness", although it can be very useful in such languages (such as C#).

As to your other point, sure...using "pure" was probably going too far. But by that same argument, even Haskell isn't pure-functional (nor do any really exist) due to it's need to interface with IO. But Java is about 90% there and strives for it. Python most definitely isn't nor does it make any intentions to do so.

Again, fudging the history/facts/topics to try and make your point. It's not worth discussing with someone who so fundamentally converses in bad faith. Especially since I'm making no claims to which is better, just outlining the flaws in your complaints. I really don't care about "better" languages.

In my humble and correct (trumping anyone else's) opinion, they are both garbage.

You're not wrong... but for different reasons :)

you don't need it until you get to importing modules.

hello world in python is literally just print("hello world!")

You don't even need it afterward, unless you want a file to be both an importable module and an executable script.

Arguably you could be a happy Python programmer without this capability.

I never understood why people bother with this when writing their python main file, which is never going to be imported because it doesn't make sense in the first place.

Because I dislike interspersing executable statements at module level with function definitions. I’d rather have all code live inside functions and have one main entry point for the script. It’s just a personal preference, nothing wrong with not doing that though.

But you could have a single main() call without the if statement, couldn't you?

REPL-based development. You might be developing a script, but notice a bug. If you import your script as a module, you can run the function you’re debugging, figure out what’s wrong, edit the file, and then reimport the module (using importlib.reload).

Okay, that's quite convincing, thanks!

Isn't that hugely elaborate compared to languages where top level statements are a function, functions return their last statement, and the return value of the entry function is sent to stdout unless invoked in special ways? That print() around the "hello world!" does not appear any less superfluous than all the public static void you can throw at a javac 1.0

You mean a language like... Python?

  >>> 'hello world'
  'hello world'

Exactly like that (well, almost exactly: if python includes the quotes then it's not really equivalent to print()).

The point was that by including that print(), people already do say yes to including "like you'd do in a real program" ceremony in their supposedly minimal examples.

> than the old "public static void main(String[] args)" thing

you forgot surrounding class definition.

I agree that can serve as terrible intro to programming. But, often when we have tools either designed for a purpose in mind or a dominant paridigm or reaction to existing set of tooling, this can result in understandable yet extreme abstractions.

Java is designed with OOP in mind and it kind of makes sense to have the user to think in terms of lego blocks of interfaces. Every method or class needs to have clear understanding of its users.

public - software handle is for all users

protected - software handle for current and extending classes

default - software is exposed to current package

private - software is restricted to be used in current class alone and nowhere else

So, the beginning of java programming starts with interface exposed to the user or other programmers. Is it weird and extreme. Yes. At least, it is consistent.

>less crufty than the old "public static void main(String[] args)" thing. I always felt that was a terrible introduction to programming

I somewhat agree, but it was kind of exciting to learn what each of those previously meaningless words meant.

Kind of a sneak preview... Tune in for next week when we learn what static means!!

It's a good local improvement, but the other hand that old traditional syntax was a good effective "keep away" sign in Java that saved many CS students from being fed Java as a first language. And it's still a bad first language after this change. I wonder if this small improvement might make things worse in the big picture.

These features are explicitly to make teaching Java as a first language easier. From https://openjdk.org/jeps/463

Goals:

Offer a smooth on-ramp to Java programming so that instructors can introduce concepts in a gradual manner.

Help students to write basic programs in a concise manner and grow their code gracefully as their skills grow.

Reduce the ceremony of writing simple programs such as scripts and command-line utilities.

Do not introduce a separate beginners' dialect of the Java language.

Do not introduce a separate beginners' toolchain; student programs should be compiled and run with the same tools that compile and run any Java program.

I learnt to program using Pascal, then C++ in Highschool.

In collage, CS101 and 102 required me to learn and use JAVA, which I felt was a huge step backwards in usability and a lot of excess typing.

But as I reflect on it now, I think my feeling were because I came from knowing how to do some things and therefore not requiring the framework that JAVA offed to first time programmers.

I think the sins of Java as a first language are twofold:

1. The obvious excess incidental complexity

2. and more important, the enterprisey culture that's much less compatible with the intellectual curiosity, looking under the hood, etc attitude that's needed to become a decent programmer.

And yet it is still the first language taught in many programs.

Although my high school programming class was c++, which is even worse as a first language.

They've also done quite a bit of work to make things such as hosting a web service much much simpler, through the addition of things like SimpleFileServer, as well as some better convenience methods.

It makes it far far closer to the python experience.

You don't need the args!

  void main() {
      println("Hello world");
  }

should work just as well.

You might also like Kotlin script.

   #! /usr/bin/env kotlin

   println("Hello world")

You have to brew install kotlin for this to work of course. But it's a great way for using a lot of Java stuff as well. Kotlin's Java interoperability is excellent if you are using Java from Kotlin.

IMHO Kotlin is underused as an alternative to python currently for data science stuff. It's surprisingly capable out of the box even with just the standard library and there are a lot of nice data science libraries that make it more useful. Not for everyone; but fairly easy to get started with.

Kotlin scripting is unfortunately not necessarily very user friendly (e.g. imports can be a bit tedious and IDE support is a bit meh). But it can be a nice way to embed some kotlin stuff in a script. Generally, Jetbrains could give this topic a lot more love and attention and it wouldn't even take that much to level up the experience.

KTS works in jupyter as well (there is a kotlin engine for that). And that of course is nice if you want to use Java libraries in jupyter. And developing kotlin DSLs for stuff and then using them in a script is kind of a power move.

> Kotlin scripting is unfortunately not necessarily very user friendly (e.g. imports can be a bit tedious and IDE support is a bit meh). But it can be a nice way to embed some kotlin stuff in a script. Generally, Jetbrains could give this topic a lot more love and attention and it wouldn't even take that much to level up the experience.

Kotlin has been pretty bad at scripting and REPL, and unfortunately the team decided to drop both:

https://blog.jetbrains.com/kotlin/2024/11/state-of-kotlin-sc...

Based on that page, they're dropping the REPL in favor of notebooks, but their're not dropping scripts. They are dropping some script-related functionality to focus on others.

Also worth noting that notebooks and kts overlap quite a bit. They use the same mechanism for imports and defining remote repositories, for example. A notebook is effectively a kts script. And of course gradle uses kts as well for its Kotlin dialect. These things actually overlap quite a bit.

Yes, they are not dropping scripts completely, at least because of Gradle, but they are removing some parts of scripting support and advise against using Kotlin for scripting. And I would prefer a true command line REPL instead of the notebooks. IIRC they were promising various improvements in both scripting and REPL for several years, and now they just gave up, I guess because of shifting the focus to K2 and KMP. I find this quite disappointing.

It took almost 30 years to get here. I never thought I'd see the day.

What really threw me for a loop is the article author mentions: "I knew plenty of professors who were bothered by [the public static void main thing]." I could have sworn that OOP die-hards in academia _wanted_ the formal class boilerplate in the original design. Maybe they aged out? Perhaps, times are changing.

One is

    void main(String[] args) {
        println("Hello world");
    }
 
 and the previous one ...

   class HelloWorld {
      public static void main(String[] args) {
          System.out.println("Hello, World!"); 
      }
  }

And that is SO MUCH less? Are you being ironic?

Should we allow somebody who cannot handle the second one, go on and programming because of the first one?