Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being wasted.
Paving the on-ramp to Java
11–20 of 156 posts
Re: Paving the on-ramp to Java
#12This seems to be a weird micro-optimisation. While I agree with some of the goals (classless files, parameterless main exist in Kotlin and are nice to have), they should, in my opinion, not be implemented for the sole purpose of making `main` as minimal as possible. I don't think you need to understand every single character of your very first program right from the beginning. A few of the concepts can be hand waved…
C# just went through this for C# 10, which I find a waste of resources, optmizing for "Hello World" is not what matters in large scale engineering.
Large scale engineering is totally beside the point for this. This is about optimizing for teaching a first language (since many will stick with that).
Read the article, the "static trap" is a real thing for new students (on top of all other ceremony). To solve the issue of main being non-static some students will start to put static everywhere as a 'fix' to their initial issue, a day or two later they'll be asking why every student gets the same name (because they have one static variable to keep the student or name objects).
The verbosity of Java also introduces another more serious problem for learning, not only do the students have problems compiling, they also start putting their mind on focusing on syntax instead of logic once they're past the first few problems. The issue of de-programming students from this affliction is waaay too common to be ignored.
Re: Paving the on-ramp to Java
#13Earlier quoted context omitted.
C# just went through this for C# 10, which I find a waste of resources, optmizing for "Hello World" is not what matters in large scale engineering.
Large scale engineering is totally beside the point for this. This is about optimizing for teaching a first language (since many will stick with that). Read the article, the "static trap" is a real thing for new students (on top of all other ceremony). To solve the issue of main being non-static some students will start to put static everywhere as a 'fix' to their initial issue, a day or two later they'll be asking w…
Back when I was a TA, first year students got along just as well with Pascal, Fortran and C++, many of which lacked a programming background.
I wasn't found of minimal APIs, global usings and implicit Program.cs for C# 10, and share a similar opinion in relation to Java.
No need to try to make it look like JavaScript and Python, each language has its place.
Re: Paving the on-ramp to Java
#14Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being waste…
> Otherwise everybody complains about Java boilerplate.
Do serious people actually complain about this often? I think it's more of a drive-by comment from people who don't like Java for whatever other reasons.
Re: Paving the on-ramp to Java
#15Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being waste…
I agree. Ironically, Java the language doesn't have any more boilerplate than, say, C++ or Go, which people are apparently okay with?
It does however have some stuff that's plain dumb (can't have functions outside classes, public static void main(String[]), ...) some of it isn't even fixable (default visibility should be private, final should be like const in C++, or even better like const in D).
This is a change that takes very little effort and doesn't impact professional development in the slightest.
Re: Paving the on-ramp to Java
#16Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being waste…
> Otherwise everybody complains about Java boilerplate. Do serious people actually complain about this often? I think it's more of a drive-by comment from people who don't like Java for whatever other reasons.
You don't think serious people can be awfully opinionated about the tools in their profession? It's not like it's something unique to Java or even programming. A lot of professionals have dogmatic beliefs about what ideas, tools, etc. they subscribe to and a lot of time is wasted in bickering about it, whether unjustified or not.
Re: Paving the on-ramp to Java
#17I wonder - why he has not take it a step further and propose to get rid of return type (void) also? It would look even more slick (add optional semicolons and we will get javascript out of this :)).
main() { println("Hello World"); }
I know that this notation is traditionally reserved for constructors but I'm not 100% sure why we cannot differentiate between methods and constructors just by looking at class name?
Re: Paving the on-ramp to Java
#18Earlier quoted context omitted.
Large scale engineering is totally beside the point for this. This is about optimizing for teaching a first language (since many will stick with that). Read the article, the "static trap" is a real thing for new students (on top of all other ceremony). To solve the issue of main being non-static some students will start to put static everywhere as a 'fix' to their initial issue, a day or two later they'll be asking w…
Back when I was a TA, first year students got along just as well with Pascal, Fortran and C++, many of which lacked a programming background. I wasn't found of minimal APIs, global usings and implicit Program.cs for C# 10, and share a similar opinion in relation to Java. No need to try to make it look like JavaScript and Python, each language has its place.
Anecdata - I'm self taught. Started my learning on Python.
I wanted to delve into Java. And sure enough, my very first thoughts were "wtf is public static void, why does this even matter, and why is print() so weird and long?"
Shit, I ended up finding it easier to get into F# than Java.
Then I got hired for a Java role, which is proof that the universe has a sense of humour.
Re: Paving the on-ramp to Java
#19Re: Paving the on-ramp to Java
#20Not a Java dev here, at least in part because the amount of ceremony to do trivial things seems excessive.
My understanding is that the ceremony and redundancy is deliberate. You type the same meaning multiple times so the compiler can detect inconsistencies and tell you about them. I.e. it's a feature, not a bug. Slightly analogous to type annotations or unit tests, one wants to write the redundant information in exchange for compiler diagnostics.
Syntactic sugar to make the language less annoying to work in is opposed to that goal, hard to guess if that's better for the target market.