Would This OpenJDK Proposal Make Java Easier to Learn? (infoworld.com) 145
"Java would become easier for students to learn under a proposal to introduce flexible main methods and anonymous main classes to the language," reports InfoWorld.
Details of the plan include enhancing the protocol by which Java programs are launched to be flexible, in particular to allow the String[] parameter of main methods to be omitted and allow main methods to be neither public nor static; the Hello World program would be simplified. Anonymous main classes would be introduced to make the class declaration implicit.
It's currently a disabled-by-default preview language feature in JDK 21 (scheduled for General Availability in September), included to provoke developer feedback based on real world use (which may lead to it becoming permanent in the future). This wouldn't introduce a separate beginner's dialect or beginners' toolchain of Java, emphasizes Java Enhancement Proposal (JEP) 445. "Student programs should be compiled and run with the same tools that compile and run any Java program."
But it argues that a simple "Hello World" program today has "too much clutter...too much code, too many concepts, too many constructs — for what the program does."
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
Anonymous main classes would make the public class declaration implicit (while also sparing newbies the "mysterious" modifier static and the args parameter String[] ). The program is streamlined to:
void main() {
System.out.println("Hello, World!");
}
The proposal argues this change reduces "the ceremony of writing simple programs such as scripts and command-line utilities." And since Java is intended to be a first programming language, this change would mean students "can write their first programs without needing to understand language features designed for large programs," using instead "streamlined declarations for single-class programs". (This allows students and educators to explore language features more gradually.) A Hello, World! program written as an anonymous main class is much more focused on what the program actually does, omitting concepts and constructs it does not need. Even so, all members are interpreted just as they are in an ordinary class. To evolve an anonymous main class into an ordinary class, all we need to do is wrap its declaration, excluding import statements, inside an explicit class declaration.
Details of the plan include enhancing the protocol by which Java programs are launched to be flexible, in particular to allow the String[] parameter of main methods to be omitted and allow main methods to be neither public nor static; the Hello World program would be simplified. Anonymous main classes would be introduced to make the class declaration implicit.
It's currently a disabled-by-default preview language feature in JDK 21 (scheduled for General Availability in September), included to provoke developer feedback based on real world use (which may lead to it becoming permanent in the future). This wouldn't introduce a separate beginner's dialect or beginners' toolchain of Java, emphasizes Java Enhancement Proposal (JEP) 445. "Student programs should be compiled and run with the same tools that compile and run any Java program."
But it argues that a simple "Hello World" program today has "too much clutter...too much code, too many concepts, too many constructs — for what the program does."
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
Anonymous main classes would make the public class declaration implicit (while also sparing newbies the "mysterious" modifier static and the args parameter String[] ). The program is streamlined to:
void main() {
System.out.println("Hello, World!");
}
The proposal argues this change reduces "the ceremony of writing simple programs such as scripts and command-line utilities." And since Java is intended to be a first programming language, this change would mean students "can write their first programs without needing to understand language features designed for large programs," using instead "streamlined declarations for single-class programs". (This allows students and educators to explore language features more gradually.) A Hello, World! program written as an anonymous main class is much more focused on what the program actually does, omitting concepts and constructs it does not need. Even so, all members are interpreted just as they are in an ordinary class. To evolve an anonymous main class into an ordinary class, all we need to do is wrap its declaration, excluding import statements, inside an explicit class declaration.
#progress (Score:3, Interesting)
Re: #progress (Score:5, Insightful)
No, .net actually has decent tooling, proper dependency aliasing, no type erasure, comparison operators that actually make sense, named parameters, and a whole lot of other things that make it not suck total ass like Java.
Re: (Score:2)
If simplifying "Hello World" is the definition of "catching up to" .NET, this proposal has a ways to go. In .NET, Hello World is now just one line:
Console.WriteLine("Hello World");
That's it, the entire source code. Like JavaScript, C# now supports module-level code, that is not inside any function. I personally think this is a bad idea, but they do have it.
Class as namespace (Score:4, Insightful)
Is this proposal just for a special case for main()? Or are they proposing allowing general functions outside of the classes? The decision to use classes as the namespace in Java is an unfortunate one, and it I don't think it would permit the general use of functions outside of a class definition. I much prefer the way namespaces are done in other languages where class structure and OOP can be used where appropriate but not required.
Comment removed (Score:5, Interesting)
Re: (Score:3)
If the filename itself declares the class implicitly then you can have functions too inside that implicit class.
If you want to grow your application into multiple files then it's another issue.
All I hope for is that the main method can take arguments.
Re: (Score:2)
I think the proposal is that functions that come out of a class in file Foo.java would be in public class Foo and would be static without the need to mark them so.
seems like a reasonable proposal to me! But I am not a Java expert.
I talked at SIGCSE this year with someone from Oracle who was working on making Java a better teaching tool. Seems like the Java world is concerned the language is too painful to write.
Re: (Score:2)
seems like a reasonable proposal to me!
Nope. It delays the learning* but it doesn't make it go away.
(*) By about 20 minutes.
Re: (Score:2)
That's pretty much it. I've taught AP Computer Science at a local private school for several years. This is an annoyance, but a fairly minor one. Students will invariably understand what all that cruft means before the end of the course. Not that this doesn't also introduce a bunch of brand-new annoyances...
I've said many times before that you can't reduce complexity by introducing complexity. The proposed change only makes things look simpler ... if you don't think about it too much.
Re: (Score:3)
No, it's not the language that's too painful to write, even though it's a bit verbose sometimes - but many IDEs solves that.
The real pain is the Oracle Licensing minefield.
Twenty-four years later (Score:2, Interesting)
I thought exactly the same thing in 1999 while in high school, learning Java.
It's a high bullshit language full of heiroglyphics
Re: (Score:2, Insightful)
The designers thought they were designing a "better" C++ (sound familiar? Hello Rust team). However they solved some issues while creating far more new ones and C++ these days is a long way removed from the C++ in the 90s and comparing the 2 languages now is like comparing a Ford (java) with an F1 car (C++). Yes the F1 car is much harder to control and requires more work to maintain, but if you want something powerful and fast its no contest.
Re: (Score:2)
Even back then I learned C first on my own time and kind of scratched my head at the bloated feel of Java.
Your comment makes me want to pick up C++, instead of re-learning Java on Eclipse :-/
Re: (Score:3)
If you think Java is bloated, you're really not going to like C++.
Re: (Score:2)
I know enough C++ to know which language I prefer already, thanks
Re: (Score:2)
I didnt learn Java because I did my education before Java was a thing. So I learned OO on Good old Turbo Pascal. I still maintain that thing had an *excellent* OOP implementation (And delphis was even better).
But Java, man that thing just alienated me. It felt like a less capable Object pascal with ugly C semantics that ran slow as arse.
That said just like C++ today is nothing like C++ then, Java is *definately* a lot more capable now than it was back then.
And while I can write the language blindfolded , I'
Re: (Score:2)
First off, I'm re-watching Stargate SG-1. It's actually crazy how much more I get out of it by being sober...
I learned a lot of nuts and bolts programming from Pascal, which is what I did my AP computer science exam in. I think it's very overlooked as a teaching language.
I used Eclipse a little bit at my old job. Having all those auto-suggest features really helps, not to mention the vast library of existing Java code and websites like Stack Overflow that didn't exist in the same way in 1999.
I'm learni
Re: (Score:2)
Turbo Pascal! Ah, those were the days. And the docs that came with, examples for every command. Nothing like that these days.
I don't miss the := operator, and I remember the first time I saw C code I thought it was all comments since Pascal used { } for comments. I was quite cornfused!
But other than that, it was a better time!
And Anders Hejlsberg designed the Turbo Pascal, Delphi, C#, and Typescript. That guy can create some awesome languages. Made it much easier for me to move from Turbo Pascal to C#, same
Re: (Score:2)
We now have Fancy IDE that deal with a lot of the hard work.
Back in the day an IDE was a text editor, that would have a button to compile your code, that would keep track of multiple files in a project, and the fancy ones we may do some syntax coloring.
While the new ones today practically write their own code.
Re: Twenty-four years later (Score:2)
That's basically VSCode. It's far more an editor that looks like an IDE.
Re: (Score:2)
Yuck, not Eclipse. Something like NetBeans or IntelliJ is a much better gift for a fledgling Java dev.
Re:Twenty-four years later (Score:5, Insightful)
I never became a Fan of Object Oriented Programming, that is with 25 years of professional experience working with it.
It went to solve a problem that didn't really exist, and really how many of us really program OO past it being a Record Structure with Functions. No overloadimg operators, or inherenting from other classes, or Using Polymorphism. While I have worked with some code in the past that has, it tends not to stick around for too long, because it just makes debugging, and following the logic more difficult, and normally a Sr. Dev will make it more inline with a procedural based design.
Re: (Score:2)
Indeed. OO is jet another "revolutionary" idea that somewhat works, but not in general and makes things needlessly complicated in many cases. Trying to make everything OO is just foolish. I used to be an OO fan for a while (learned it with Eiffel), but not anymore. Most of its promises, like code reuse, never panned out.
Re:Twenty-four years later (Score:4, Interesting)
> It went to solve a problem that didn't really exist
Huh??? No offense but you really don't understand the strengths and weaknesses of different programming paradigms [wikipedia.org], namely: Procedural, OOP, Functional, and DOD. OOP existed because it solved real-world problems of scalability, robustness, convenience, safety, verbosity, along with features.
While I'm no fan of OOP either (been using it since 1991) but OOP WAS an improvement over bad procedural programming. The main problem is you have people OOP fanatics over-engineer [youtube.com] their design with excessive abstraction. Good procedural programming, with less abstraction, is sometimes the right solution for clean(er) code.
The problem was that as software complexity grew we needed new ways to "scale up" and organize Code+Data. There is a famous quote my Fred Brooks in The Mythical Man-Month [amazon.com] where he states:
A more modern colloquialism would read:
The problem with OOP is that it is shit for high performance [slideshare.net] due to cache misses because it naturally has programmers design for 1 object instead of N objects. This is why the Data-oriented design [wikipedia.org] (DOD) took over for game development and high frequency trading.
In C you would have an implicit pointer to an struct as the first parameter or in any order. C++ made that explicit, renamed it "this", and made it the FIRST argument. This had the effect of making the code less verbose and consistent.
The problem with passing a struct is that sometimes you want to hide the implementation details and only expose the interface portion. private and public give you control over that at compile time.
Operator overloading is syntactic sugar but it CAN make for less "noise". Do you really want to write verbose code like this:
Compared to much more compact:
vs
Mathematicians use operators because they don't clutter up the page with long verbose names. Ditto for C++.
C with classes, aka the first c compiler, cfront, started to fix the annoying things in C, to make programmer safer, by catching more things at compile time.
The problem with C+
Re: (Score:2)
> It went to solve a problem that didn't really exist
This sentence makes me doubt your "25 years of professional experience". OO solves a very real problem: that our brains can't hold all the details of any reasonably complex program (I'm working on a code base with over one million lines of C++). Even if you only use encapsulation, OO is there to help you hide the details you're not interested in.
And every feature is there for a reason. Operator overloading allows writing the C++ expression on the next-
Re: (Score:2)
Having worked on code that was a millions of lines of FORTRAN 77, for a product that I had little idea on what it actually did. I was still able to maintain the software, without having to use Object Oriented. With this now nearly 50 year old code, it was able to be managed and maintained and expanded over the generations, due to a strict adherence to naming schemes, and in code documentation. It had the dredded GOTO statements as well, however it wasn't spaghetti code, as all Goto by policy just went i
Re: (Score:2)
OOP was trying to generalize these rules and conventions so that anyone not familiar with the code could at least picture the class hierarchy and behavior and make sound decisions of where to apply the code changes.
Re: (Score:2)
I've been writing code on and off for longer than /. exists and I know one field in which OOP absolutely is the correct approach - games programming. When the thing you are building consists of a bunch of things (units, buildings, characters, weapons, whatever) then OOP is the best abstraction to express that.
In absolutely everything else I've ever written, imperative beats OOP every single time.
Re:Twenty-four years later (Score:5, Insightful)
None of that stuff means very much though if you're a professional developer though. Declaring an enclosing class for a static method *is* a bit of unnecessary rigmarole, but if that's going to put an end to someone's dreams of being a professional developer, maybe they should find a different dream because there's way more difficult stuff in store for them.
When you choose a language for a project, the language itself probably isn't the biggest concern you have. It's the ecosystem you have chosen -- the libraries and frameworks and platforms that you are going to have to live with as a consequence of that choice.
While the Java language has always been far from perfect, it was never the language itself that was the problem. It was all the over-engineered shit that you got in the bargain that made your life hell.
Re: (Score:2)
Mostly agreed.
IMO, it is important for one's chosen ecosystem to be of reasonable quality, and for dependency management to be considered an important part of a developer's job.
I've generally found that large dependency graphs scale poorly and age poorly as well. Using an external library or framework is a tradeoff. You get to not have to re-invent the wheel. But you also commit to that wheel still being around, and not changing its API, and not changing its own internal dependencies (or those changing t
Re: Twenty-four years later (Score:2)
I was thinking he meant horrible syntax, horrible build tools, and the weight of the JVM.
JCOBOL (Score:5, Funny)
Re: JCOBOL (Score:2)
It started as an iot thing in the mid 90s but there wasn't any money in having your toaster email you when your toast is done back then (not sure there is now either), but there *was* plenty of money in y2k, which is how java found its way into a lot of businesses around that time...taking over from cobol.
Re: (Score:2)
No. Java is what happens when a business dude meets a tech dude at lunch and they chat about market expansion, generalization, abstraction, inheritance, interfaces and a bunch of other buzzwords, only half understanding what the other dude means, and then decide to make a language out of it. ...and the business dude gets to design the low-level features. Aka "I don't understand memory management, let's make that a language feature so it's the tech dude's problem".
Just No (Score:5, Insightful)
Re: (Score:2)
It introduces a number of important concepts that is gonna stay with you as long as you are writing in an Object Oriented style.
Yes and the concepts here aren't actually that difficult. Any instructor should be able to explain, and any student grasp, them in a few minutes. Heaven forbid student should have to actually learn something in their first lesson.
But it argues that a simple "Hello World" program today has "too much clutter...too much code, too many concepts, too many constructs — for what the program does."
Oh please. /sarcasm
Re: (Score:2)
Heaven forbid student should have to actually learn something in their first lesson.
This, unfortunately, is the expectation of "modern" computing: "I don't have to think." We as the old guard have only ourselves to blame for this sad state of affairs but, it is the reality.
As for the "too much" bit from TFS, if they cannot handle a bit of boilerplate code then they need to find another profession to get into. Full stop. That's not me saying that. It's ChatGPT coming to eat their breakfast, lunch, and dinner. It won't complain about "thinking" for the 5 extra seconds it takes to include
Re: (Score:3)
We could try making better languages and tools that don't need so damn much "boiler plate" code. What does a simple C# "Hello, World" project look like when you make it with Visual Studio 2019? 47 files across 15 directories and almost a full megabyte worth of crap. It's ridiculous.
We as the old guard have only ourselves to blame for this sad state of affairs
Speak for yourself. I've been screaming about this for more than 30 years. I've said many times that most 'large projects' are only large because they're poorly designed. The trouble is that the industry has made bad design
Re: Just No (Score:2)
No, most projects are large because they reflect the complexity of the (possibly poorly designed) business problem they address.
I'll take my grad school pile of code for an example. By the end it clocked in at about 140k+ loc. Of those, maybe 3 or 4k was actually the secret sauce and the rest was "boilerplate" to ingest real-world data from a zillion sources and put it all in the correct coordinate system for the secret sauce to do its thing.
The real world is messy, so it stands to reason that code is messy
Re: (Score:2)
No, most projects are large because they reflect the complexity of the (possibly poorly designed) business problem they address.
No, it really doesn't. There is a ton of needless complexity though.
The real world is messy, so it stands to reason that code is messy.
That's absurd. If the code is "messy" it's because it's poorly designed. Full stop. In your own example, if I'm interpreting it properly (I'm assuming you're misusing the term 'boilerplate') there is absolutely no reason why that project should have been "messy" in any way other than absurdly poor design.
Re: (Score:2)
Depends what you're trying to achieve with your language. Yes, it shouldn't take long to explain the concepts, but until the concepts are useful it tends not to "stick." And that's Java's problem all over the back - it solves problems you don't get to until you're part of a large team, possibly geographically diverse, maintaining code bases of millions of lines of code. In my day job I often need tiny programs that do a very specific task, possibly only once, and I can rattle them together in PHP or Python
Re: (Score:3, Informative)
There's your problem.
Re: (Score:2)
To be honest, grading students on getting static void main right is not very useful when the compiler will let you know something is not right. You fix it and you will not change that declaration for the rest of the project.
I would be more interested in seeing the design or general plan in the form of a class diagram, sequence diagram and for extra points a state diagram.
Then you help get it done with J
Looked at Java in the beginning. (Score:2)
Re:Looked at Java in the beginning. (Score:4, Interesting)
Java is a very nice language with a lot of nice features. Unfortunately...
They made a lot of bad decisions. 16 bit chars is one of them. Reasonable at the time, but not big enough for international programs, and too large if all you need is ASCII. Various other similar things. No global constants is one I need to kludge around almost every time I use it. Doing simple things is very inefficient, and many larger programs are composed mainly of doing LOTS of simple things. E.g., you can't store ints in a hash table, you need to convert them to Integers and then you are storing pointers to them. This results in lots of relatively inefficient indirect accesses.
The upshot is if I don't need to code to be really efficient, I prefer Python, and if I do, I use C++ or C or D or something else that's easy to use for the particular problem, but which also generates efficient code. I don't think I've picked Java once in the last decade, though I tried it a couple of time while planning out the code.
Re: (Score:3)
I'm not saying OO is bad, I am saying its religion is bad.
Classes are a fine tool to define data next with the code that processes it, but global variables are too are also a fine tool, and unsigned integers that follow twos compliment are most certainly a very fine tool also.
Java only provides that one hammer.
Re: (Score:2)
Well said. OO is something that has a place as a language feature you use when needed. Requiring everything to be OO is just wrong and that is what the "OO religion" wants. Java was designed at a time where too many people expected OO to deliver many massive benefits it never really could deliver except in very special cases. By now that has become amply clear. As a lot of people have invested a lot of effort into OO, the sunk-cost-fallacy they operate by is very hard to overcome. But the success of, for ex
Re: (Score:2)
Re: (Score:2)
Yeah, but I've yet to have a problem that demanded 5 or 6 bit chars and required high efficiency on modern hardware. If you want to pack things to the bit level there are languages that facilitate that, but most of them work at the expense of efficiency. (I'd say all, but I'm not sure.) The hardware usually has 8 bit bytes, so you don't gain much by trimming beyond that, but if you need to, the are choices. I've never tried, but I think C++ allows one to specify bit position within a struct. Or perha
Or just use C++ instead (Score:2, Insightful)
Plus you'll be learning a more efficient language that also has more use cases.
If that's too daunting, you won't be a developer (Score:2)
The 'Java Way' is absurd complexity (Score:5, Interesting)
There is a joke hello world at http://foreigndispatches.typep... [typepad.com] that really isn't far from the truth about how java programs are actually implemented by some coders. I seems some java coders think: Why just print a string when you could instead instantiate a new string-writer class implementing an abstract string writer factory with a text-writer interface? And instead of hardcoding a constant value, use an xml or json configuration file, even if you will never actually change the value.
Re:The 'Java Way' is absurd complexity (Score:5, Interesting)
Along the same lines, there is also Benji Smith's 2005 hammer factory factory post on the now-defunct joelonsoftware discussion forum. The original is long gone, but there are at least two copies elsewhere:
https://factoryfactoryfactory.net/ [factoryfac...actory.net]
https://medium.com/@johnfliu/why-i-hate-frameworks-6af8cbadba42 [medium.com]
(The original also had some good follow-up discussion, but that is harder to find.)
Re: (Score:2)
There is a question on Stack Overflow asking about what is meant by: Program to the interface not to the implementation.
Most of the answers use Java interfaces as the subject of the explanation, and these are the ones with something like 100+ upvotes. There's only one or two in the thread that explicitly says it isn't about Java interface and references the gang of four. I was looking around for good rants against java interfaces one day when they pissed me off by how people use them everywhere by dogma whe
Re: (Score:2)
I do sometimes, and not other times.
The pros, which become more important as a system grows:
* You can have multiple implementations. It's not unusual for some of our systems to have to talk to multiple databases. It's great if we can build IGetDataTable implementations for Postgres, MSSQL, SQLite, and whatever else we need, and have them work in similar fashion.
* You can much more easily build mocks for unit testing.
* It helps minimize coupling between things t
Re: (Score:2)
Yep, and that is a real problem. Things should always be as simple as possible. Never introduce complexity that is not actually needed. Complexity kills reliability, security and maintainability and not only in code. The Java crowd never understood that and hence continues to create badly engineered abominations.
Re: (Score:2)
Re: (Score:2)
Thanks. Applying a quasi-religious stance to an engineering problem is probably the ultimate failure. And yes, I am aware not every Java developer is incompetent. But a majority seems to be.
OO is a tool. It should only be used when it offers real advantages. Anything else is bad design and stinks of incompetence.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The real joke about that link you provided is the web design.
A 3-column page with fixed width, so there's plenty of wasted screen space in the margins. As a result, they had to use single-space indentation for the Java source to ensure it would fit on the page without wrap-around.
I've been a programmer and designer for almost 30 years. Never mind just Java -- after all this time, and now that the tech industry is "mature", I have lost almost all my love for computing. I'm retired and now just do embedded
It will make it more difficult. (Score:2)
A solution looking for a problem (Score:2)
If you want to write scripts, just use Groovy. If you want sane command line utilities, you're going to need Maven or Gradle to help you incorporate dependencies that handle stuff like command line arguments and help you package a fat jar. Declaring a main method is the least of your problems when starting out with this stuff.
Re: (Score:2)
I found java tractable, maven however really frustrated me and some of the frameworks I found very hard to use - I found it really challenging to follow code written by others using weld for example.
my point is that the ecosystem for java seems to have a steep learning curve as soon as you step away form trivial examples
I think this would actually make it harder to teac (Score:2)
50+ Years of Programming Language Progress (Score:5, Funny)
This is your brain on 2023 Java...
void main() {
System.out.println("Hello, World!");
}
This is your brain on HP's circa-1969 BASIC [stackexchange.com]...
?"HELLO, WORLD"
Any questions?
This has been a public service announcement from the Partnership for a Java-Free America (PJFA).
Re: (Score:2)
Re: 50+ Years of Programming Language Progress (Score:2)
I have a question. How many CPU cycles and how much ram do those two programs use?
Re: (Score:2)
Any questions?
Yes, how does a question mark, of all things, end up as a shorthand form for "print" ?
Re: (Score:2)
Re: (Score:2)
Yes, it will help - less is more (Score:2)
Ceremony is not helpful. In most cases, less lines of code are better, ranging from reasons of intimidating novices to merge complaints or just mak
psvm in intellij (Score:3)
Just remember 'psvm' (from Public Static Void Main) and hit tab when you are in Intellij. The editor does the rest.
"Simple programs such as scripts and command-line (Score:2)
Re: (Score:2)
Re: "Simple programs such as scripts and command-l (Score:2)
Hello World is a dumb KPI (Score:2)
"Hello World" is briefly descriptive of the form of a language. As a metric it is useless since no one is trying to optimize for anything that looks like a "Hello World",
Simplify (Score:4, Insightful)
I have taught Java for a long time. It doesn't matter what the main-method looks like: after the first couple of programs,it's just background noise.
The problem withbJava is the proliferation of language features. Just as an example: yes,the original "switch" syntax sucked. So now we have two allowed switch statements. Dumb. Another example: shoehorning lambdas into a language fundamentally unsuited to them.
You want to fix those problems? Great, move to Kotlin. Or Scala. Or some other, newer language. Gluing more and more features onto Java just creates a mess...
Re: (Score:2)
Gluing more and more features onto Java just creates a mess...
Gluing more and more features onto anything usually just creates a mess, whether you're dealing with hardware, software, or programming languages. Or, for that matter, languages in general - English is a perfect example.
Just about anything which evolves sooner or later becomes an ad hoc collection of emergent characteristics.
Re: (Score:2)
The problem withbJava is the proliferation of language features. Just as an example: yes,the original "switch" syntax sucked. So now we have two allowed switch statements. Dumb. Another example: shoehorning lambdas into a language fundamentally unsuited to them.
I feel like this is a problem in many languages. I have a background in PHP (because of a quirk of timing not because I particularly love it) and I find most of the announcements about modern PHP are "language features" which purport to save time or increase productivity or whatever, but to me they just add more effort and confusion because now there are multiple ways to do the same thing and more always coming.
Most of the examples are like the on in this summary - "look how easy it is to save two lines of
The COBOL of the 1990s (Score:4, Interesting)
The problem using Java to learn... (Score:3, Interesting)
The problem using Java to learn to code, program is that Java requires alot of object-oriented concepts. A newbie has to learn what a class is, encapsulation, constructors, object, access, et cetera.
Learning Java is akin to learning to pilot an aircraft using an Airbus with the myriad of features, controls.
The great thing about BASIC and Pascal was the emphasis on syntax for fundamental ideas--decision statements, functions, recursion, etc.
This proposal is making Java less object-oriented but still object-oriented.
One programming language a friend has been developing that transcompiles to Java is ZeptoN, described in this whitepaper https://wgilreath.github.io/Ze... [github.io], and the source code repository is on GitHub as open-source... https://github.com/ZeptoN-Prog... [github.com].
JoshK.
Call me woke (Score:2)
Re: (Score:2)
Enticing students to learn programming is ill advised.
That's what they said when the IDE was invented. It was supposed to be so easy that the office secretary was going to replace professional programmers.
LLM's have the same relationship to programmers as the IDE did: it's going to be a great assistive tool for generating snippets of code for well-understood problems, but no more.
On the other hand, I've watched people work with LLM's to create programs, and was quite impressed with how quickly LLM's can generate bad code. They create bad code many times faster
Re: (Score:2)
Debates like these while manual programming is rapidly being replaced by AI is like bailing a sinking boat with a teaspoon.
I wonder what they plan is when the AI's program crashes, or sometimes yields an incorrect result, or is found to contain a security hole. Will they bring in a second AI to debug the first AI's code? (I'm only partially being facetious here -- maybe they actually will)
It would make robot programming like Arduino C (Score:2)
There are two types of people.
1. Those that study computer science and fight over multiple inheritance and namespaces.
2. People that just want to make stuff work, like robots.
Arduino C is super simple and works just like described above.
I would never inflict Java on anyone who just wants to get work done.
Additionally, with the rise of co-pilot and AI tools like Bard, Chat-GPT simple, even moderately complex programs are getting much, much easier to write if you have the skills to describe what you want.
Works well in .net (Score:2)
C# has had a similar feature for a while. Tt is called Top Level Statements [microsoft.com]. It goes one step further since you don't even need to declare the main method. The following is a complete C# program:
Console.WriteLine("Hello World!");
It eliminates annoying boilerplate from microservices and small CLI tools. It is optional, and yet it has proven quite a popular feature since a lot of people use it.
This will work for Java for the same reasons it worked for C#.
Catering to noobs is a losing battle. (Score:2)
Of course, the original Java design - everything must be in a class - was just cargo cult thinking. The language designers thought that it would make things easier if everything needs to be a class, even when they don't. No they've gone full circle to what languages like C and C
Hello World is not the problem (Score:2)
Who starts a program from scratch these days? Most of us start with a canned template. It's not necessary to immediately understand every piece of that template. It just works, we start filling in the blanks.
To get newbies started, just make sure the canned template is decent. If the "fluff" code isn't necessary, it should be eliminated entirely from the language. But that's not what's happening here. They're just hiding the fluff. It's not *actually* simpler, it just appears simpler. One might argue that t
I'll add another feature request (Score:2)
Make it so I can split a class defintion across multiple source files without having to refactor a naturally large class into a zillion different classes, instances of which would have to wink in and out of existence, at a performance penalty, for no reason other than aesthetics.
It would still compile into a single .class, but you wouldn't have to navigate a 10kline source file to work on it.
Yeah....it would be nice if Java were more like C++ and less like Java....
What about the boat anchor in the room? (Score:2)
Of course that feature was a complete failure. It flopped for client programming because it was too bloated and took forever to start up. That is still true today. I occasionally use a stand alone Java data analysis package and it is painful. It's slow to start and has a lame GUI compared to current web based platforms
don't... (Score:2)
C in Java-costume (wolf in sheep's clothing) (Score:2)
Looks very familiar to the C program.
#include <stdio.h>
int main(void) {
puts("Hello, World!");
}
Why keep "void main()", and System? (Score:2)
The function declaration is just as unnecessary as the rest of it. Also import System static by default.
Re: Those are not the problems with java (Score:4, Insightful)
Re: (Score:2)
Minecraft is now written in C#, just the old version is Java.
Re: (Score:2)
Yes, what Java really needs is a way to run a Java program inside a web browser. Then you could write little Java scripts to decorate your web page with animations and stuff! :)
Re: (Score:2)
Re: (Score:2)
I'm not a pilot either but I know several, and yes, you need training specific to the type. It'd be great if over time cockpits evolved toward greater similarity to one another. But it would not eliminate the need to train for the specific types, because there is MUCH more than instrumentation that would vary between even similar types such as the 737-800 and 737-MAX.
A few years back, several fatal 737 MAX accidents happened, for reasons that turned out to be related to the MCAS system, incorrect sensor i
Re: (Score:2)
Not sure what you mean there. Pascal was indeed taught in schools for many years and was excellent at teaching students structured programming using a clear and precise syntax with no boiler plate and no cruft. In fact if schools would return to teaching Pascal as a first language it would do new programmers a lot of good and give them a great foundation for moving on to other languages.