Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming Java

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.
This discussion has been archived. No new comments can be posted.

Would This OpenJDK Proposal Make Java Easier to Learn?

Comments Filter:
  • #progress (Score:3, Interesting)

    by Coolbest ( 10355800 ) on Sunday April 16, 2023 @10:39AM (#63453736)
    So, java is finally catching up to .net
    • Re: #progress (Score:5, Insightful)

      by ArmoredDragon ( 3450605 ) on Sunday April 16, 2023 @04:03PM (#63454344)

      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.

    • 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)

    by caseih ( 160668 ) on Sunday April 16, 2023 @10:45AM (#63453740)

    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)

      by account_deleted ( 4530225 ) on Sunday April 16, 2023 @11:06AM (#63453772)
      Comment removed based on user account deletion
      • by Z00L00K ( 682162 )

        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.

    • by godrik ( 1287354 )

      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.

      • seems like a reasonable proposal to me!

        Nope. It delays the learning* but it doesn't make it go away.

        (*) By about 20 minutes.

        • by narcc ( 412956 )

          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.

      • by Z00L00K ( 682162 )

        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.

  • 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)

      by Viol8 ( 599362 )

      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.

      • 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 :-/

        • by narcc ( 412956 )

          If you think Java is bloated, you're really not going to like C++.

        • 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'

          • 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

          • by KlomDark ( 6370 )

            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

      • 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.

    • by jellomizer ( 103300 ) on Sunday April 16, 2023 @02:50PM (#63454210)

      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.

      • by gweihir ( 88907 )

        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.

      • by UnknownSoldier ( 67820 ) on Sunday April 16, 2023 @10:46PM (#63454890)

        > 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:

        "Show me your flowcharts and conceal your tables, and I shall continue to be mystified;
        show me your tables and I won't usually need your flowcharts: they'll be obvious."

        A more modern colloquialism would read:

        Show me your code and I'll have to see your data,
        Show me your data and I won't have to see your code.

        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.

        // C way
        typedef struct Image
        {
        int width;
        int height;
        int bpp;
        uint8_t *data;
        } Image;

        void SetPixel( Image *image, int x, int y, int color );
        void DrawLine( Image *image, int x1, int y1, int x2, int y2, int color );

        // C++ way
        class Image
        {
        public:
        void SetPixel( int x, int y, int color );
        void DrawLine( int x1, int y1, int x2, int y2, int color );
        private:
        int width;
        int height;
        int bpp;
        uint8_t *data;
        };

        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:

        Vector a, b, c;
        VecInit( a, 1.0, 0.0, 0.0 );
        VecInit( b, 0.0, 1.0, 0.0 );
        VecAdd( a, b, c );
        VecNorm( c );

        Compared to much more compact:
        vs

        Vector a( 1.0, 0.0, 0.0 ),
        b( 0.0, 1.0, 0.0 ),
        c;
        c = a + b;
        c.normalize();

        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+

      • > 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-

        • 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

          • by sapgau ( 413511 )
            Yes you can use procedural language to model OOP concepts, but like you said, you have to stick to the conventions and rules within the code to make everything make sense.
            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.
      • by Tom ( 822 )

        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.

    • by hey! ( 33014 ) on Sunday April 16, 2023 @02:52PM (#63454216) Homepage Journal

      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.

      • 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

  • JCOBOL (Score:5, Funny)

    by flyingfsck ( 986395 ) on Sunday April 16, 2023 @10:50AM (#63453750)
    I always thought Java is a kind of modernistic COBOL wannabe.
    • 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.

    • by Tom ( 822 )

      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)

    by madsh ( 266758 ) on Sunday April 16, 2023 @10:56AM (#63453754) Homepage
    I was the first generation Java learners, have a degree in computer science and education, and I have thought classes at college level in Java. It is a great little gem of a Hello World program. It introduces a number of important concepts that is gonna stay with you as long as you are writing in an Object Oriented style.
    • 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

      • 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

        • by narcc ( 412956 )

          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

          • 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

            • by narcc ( 412956 )

              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.

      • 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)

      Object Oriented style

      There's your problem.

    • by sapgau ( 413511 )
      Yes but, focusing on getting the syntax right without any context is what people are set against Java.
      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
  • Decided to pass. Never had any reasons to look back. More something is taught in school, the more I want to increase my distance.
    • by HiThere ( 15173 ) <charleshixsn@NOSpaM.earthlink.net> on Sunday April 16, 2023 @11:51AM (#63453868)

      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.

      • The undermining is in the OO religion.

        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.
        • by gweihir ( 88907 )

          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

      • by kiviQr ( 3443687 )
        Every single decision you make is a tradeoff. For some 7bit ASCII is too much.
        • by HiThere ( 15173 )

          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

  • by Viol8 ( 599362 )

    Plus you'll be learning a more efficient language that also has more use cases.

  • Better get out early and look for something else. There is nothing worse than wasting your time because you get coddled, just to figure out later that you don't like what the actual work demands of you. Every bit of that code means something you need to know eventually. If you can't stomach seeing that until you know what it means, you're not cut out to be a developer.
  • by HighOrbit ( 631451 ) on Sunday April 16, 2023 @11:19AM (#63453796)
    The problem with java is the 'conventions' that have arisen on how to use it. The convention in Java is to encourage over-abstraction to the point of absurdity. When you download and look at any project, you must spend considerable time trying to detangle and understand the thousands of lines of spaghetti abstract interfaces and 'helper' classes. It is a huge cognitive load.

    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.
    • by mmogilvi ( 685746 ) on Sunday April 16, 2023 @12:30PM (#63453958) Homepage

      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.)

    • 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

      • 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

    • by gweihir ( 88907 )

      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.

      • I am a Java developer and I agree with you. Simple is better. But it's hard to explain this to the folks who treat OO as a religion rather than a tool.
        • by gweihir ( 88907 )

          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.

          • I wouldn't so much say "incompetent", mostly they are more like developers who can't question an absurdity when they see one because of pressure from others ("our way is the only true way") or they realize the absurdity but are forced to use it anyway because of a boss or superior who foolishly believes that doing that absurdity is the solution to all their problems. Or worse, they are being forced to use a framework that insists on doing things in an absurd way and they are forced to do things in the same
    • Long time java developer here. This is why you should IGNORE these abstractions to the point of absurdity, you can develop simple and functional things perfectly well in Java without having to make factories or abstractions for every single function you need. I am a Java developer and I find it completely ridiculous when I see the very long strings of functions that were called when an error happened into a big Java application developed by someone else and I realize that 90% of them were not needed for the
    • 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 introduce a new concept:anonymous main class.
  • 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.

    • 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

  • One way or another, the first lesson of any programming course aimed at students that don't already know a different language is going to involve them copying a bunch of code they don't understand, running it, and then having the teacher explain what each part of it does. I don't see how omitting the "public static" really helps, because one way or another students won't understand most of the "hello world" program their teacher gives them until the teacher breaks it down, and they're going to have to learn
  • by theodp ( 442580 ) on Sunday April 16, 2023 @11:59AM (#63453892)

    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).

  • In order for Java to stay relevant, it needs to evolve and it does have too much ceremony. Anything you can simplify will help. If you can infer the class name from the file name, that is a step in the right direction, IMHO. Java is a world-class platform and a decent language. (to be clear, the draw of Java is the JVM more than the Java language itself)

    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
  • by carnivore302 ( 708545 ) on Sunday April 16, 2023 @01:25PM (#63454082) Journal

    Just remember 'psvm' (from Public Static Void Main) and hit tab when you are in Intellij. The editor does the rest.

  • "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)

    by bradley13 ( 1118935 ) on Sunday April 16, 2023 @02:26PM (#63454164) Homepage

    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...

    • 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.

    • by trawg ( 308495 )

      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

  • by hughbar ( 579555 ) on Sunday April 16, 2023 @02:32PM (#63454176) Homepage
    It still is. I grew up with COBOL and find it more readable too. Both fail as expressive languages.
  • by joshuark ( 6549270 ) on Sunday April 16, 2023 @02:58PM (#63454232)

    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.

  • Debates like these while manual programming is rapidly being replaced by AI is like bailing a sinking boat with a teaspoon. Enticing students to learn programming is ill advised. Plumbers will be needed for far longer than programmers.
    • 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

    • by Jeremi ( 14640 )

      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)

  • 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.

  • 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#.

  • You're much better off finding ways to bring noobs up to expert level quicker and more solidly. Noobs don't stay noobs. Language features catering to noobs only means a bunch of dead weight when noobs eventually become proficient.

    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
  • 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

  • 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....

  • No one seems to remember the original concept that was supposed to make Java invincible: write once, run anywhere. Deploy same code on the client side or the server or split between the two.

    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

  • Why should students learn Java? better learn another language as Java is just crap. Why should students learn coding anyway, leave it up to the people who actually want to do coding.
  • Hello.

    Looks very familiar to the C program.

    #include <stdio.h>
    int main(void) {
    puts("Hello, World!");
    }
  • The function declaration is just as unnecessary as the rest of it. Also import System static by default.

Fundamentally, there may be no basis for anything.

Working...