Also, you broke the site guideline asking people not to go on about downvotes in the comments. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to them in the future? We'd be grateful.
Whether or not Java is the best one for this purpose is up for debate, but I think it's no longer a bad one
I'm surprised you would say this, as it is the exact opposite of my experience as university teacher. I think we should teach concepts, and concepts appear much more crisply in small and focused languages. I think students gain more from being exposed to specialised languages than to more muddled multi-paradigm languages. For example, functional programming is much clearer in a language such as SML or Haskell than in Scala or F# (although the latter isn't that bad), because you can actually teach the whole language without any part of it muddling the concepts. Similarly, I would rather teach object-oriented design and implementation with, say, Smalltalk than OCaml.
Now, industrial usage is a different matter - here I have no problem with multi-paradigm languages.
Another advantage of laying this kind of foundation is that even if the initial course stuck to a limited set of features, students could then go out and use the things they've learned and explore other features adjacent to them at their leisure, without going too far outside of that initial comfort zone (and - maybe most importantly - using the same tooling/environment setup, which can be the biggest barrier to new programmers who want to try out different technologies)
I'll admit though that this is mostly speculation on my part
There can be many reasons for this, but I think people completely new to programming do not have the maturity to juggle multiple paradigms within such a short period of time, and within the same language. Perhaps switching to a materially different language when switching concepts actually helps them, so they don't mix up things too much.
But I guess when you're just trying to figure out what code is, it helps to be able to form very consistent and concrete understanding around basic atoms like "what is a variable?". So if a language has different syntaxes that look similar but don't follow the same rules, that could get bewildering fast. Especially in languages that have sprawled over time and have competing ways of doing the same things.
Maybe the best answer is a language that was designed holistically to be cross-paradigm from the outset? In contrast with a kitchen-sink language that's gathered features over the years
Edit: Another thought; there may be a distinction to be made between "mixed-paradigm" and "cross-paradigm", where one takes the best pieces from multiple paradigms and works them together into a complete whole, while the other just dumps multiple entire paradigms into the same language. Rust for example does a great job of mixing-and-matching without sprawling (not that it would necessarily be a good first language, but for the sake of example)
I didn't get as lost in the incidental differences between languages like how do I print or import function, etc. but just how I might implement just one part of my program more functionally, how it'd help me reason better about that chunk.
I suppose it shows that I rep Java and Python all day, the champions of compromise, jack-of-all-trades languages.
How about a multi-paradigm language that isn't muddled?
It's still very much an OO language with borrowed features.
> a multi-paradigm language is exactly what should be the defacto language in curriculums
Debatable. Multi-paradigm languages without a strong focus can overwhelm someone completely new.
Like there is no one definition of most paradigm’s, but what used to be the most FP language, LISPS definitely don’t conform to the more strict FP-definitions like pureness, strong type system, etc. What remains is simply having functions as first class citizens and you can very much save functions into maps or whatever in Java.
having some sort of syntax for lambdas does not a function programming language make.
There's nothing about the Java syntax or design that lends its self to FP. Lambdas were bolted on to the language after the fact..
That's like saying Scheme is Object oriented because its trivial to make objects from closures, and should one decide to go deeper, you could easily define macros for classes, methods, etc.
It's grossly disingenous to call Java functional, or even compare it to other functional programming languages.
Languages should be dumb. Standard libraries should be smart. Not the other way around. The number of syntax constructs that generate standard library calls when compiled should be minimized as much as possible.
Edit: one more thing, operator overloading is extremely harmful for readability.
As for prior knowledge, that argument doesn’t fly. A lot of the verboseness of Java could be addressed VERY easily with clear syntax that doesn’t require a lot more prior knowledge. An example is getters and setters, which are very easy to understand in languages that have built-in support for concise syntax but Java has somehow ignored the advantage of concise syntax for 25 years.
Besides, if your argument is that Java doesn’t require “prior knowledge,” I beg to differ. E.g., correct usage of arrays vs. ArrayList.
The difference between arrays and ArrayList is simple: an array has a constant size known at the time of allocation.
Arrays vs lists is a thing in all languages, not Java. They just have different names (list, vector, sequence...)
Kotlin isn't terse.
This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures.
Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: it’s fundamentally a sequential list of things or a key/value map of things. Everything else is a special case that only your program cares about, and it gives you the tools to build a system to work with them as generally or specifically as you need it to.
What makes a WindowLayoutEngine “a state-holding object with proper structures?” How is it different from “a data tree with proper structure,” except that the former includes methods inside the class instance while the latter relies on functions to operate on the data tree?
Solving problems and formulating a problem solving approach takes time. This is the important part of writing software. A few extra keystrokes are relatively minor in comparison.
"I want to write software, but I don't want to type too much", never made sense for me.
Such as?
"Java, by virtue of being more verbose, requires writing everything out explicitly, so you really have to expend some extra effort to make your code unreadable."
Boilerplate is what makes code unreadable. Getters, setters, backing fields, all that noise, takes lots of space getting in the way of grasping the meaning of the code. Java is too much about how instead of what.
The things that I write in a computer program’s code should correspond as closely as possible to what the program means - nothing more and nothing less. Java is terrible at this.
Is it really the point to teach OO though?
Java is being used everywhere. And you get to learn the basic as well as the huge ecosystem behind it. Apart from possibly Python, are there any language that get you both in terms of market and learning?
And Java have make huge improvement in every part of the ecosystem, from languages, standard library, VMs. While I still dont like the language much, but I have gotten off the so called busy and verbose code view as I age. As they do serve some purpose. We need better balance, right now languages design are binary and polarised options.
It's sad that people see the primary teaching language of a CS course as somehow important for this purpose. Sad that students see it this way, sad that their parents see it this way and particularly sad that would-be employers often see it this way too.
Particularly languages favoured by industry are unlikely to offer CS students anything to be passionate about. Yes, it's true that lots more of them will get jobs maintaining code written in a then-current Java in 2005 than will be writing green field Haskell. But if we just wanted code monkeys a three (or four) year degree is massive overkill.
literally anything else.
You can get work in those other languages, nor is an understanding of Java a prerequisite for understanding how to use those other langs, etc.
and you don't need 10 lines of code to print hello something to the screen.
and JavaScript(ES6) is actually multiparadigm.
don't get me wrong, JS has its warts (and oh my god that is indeed the case.) but you can literally run it in any browser any where, which makes for an excellent teaching aid.
Elegance isn't the first word I'd reach for when describing Java
Jshell
> As per single core performance, javascript is faster and has had first-class-functions from the beginning
Doubt. And no matter how I count, Java had first class functions for 8 years now, at the very least. Does it really matter when exactly did a language feature got implemented?
> and you don't need 10 lines of code to print hello something to the screen.
jshell: System.out.println(“hello world”)
> and JavaScript(ES6) is actually multiparadigm.
That hardly means anything. There are entirely FP libs available for Java.
and ugly and verbose and all the things you mentions are bolted on after that fact or not even apart of the core programming language. which hurts your agreement of its being "elegant" or "designed well"
Also, a JIT compiler written in Java running on top the JVM interpreting (though in a clever way) javascript can match the speed of V8, just saying. Look up TruffleJS!
1. no unsigned integers
2. no freestanding functions
3. pom files are a huge pain
4. the com.blah.blah.blah ridiculously long package path precedent makes it awful to work with if you don't have an ide
5. you can't actually use javac to compile your code. everything is so big and complicated you have to use ant, gradle, maven, etc.
6. too much boilerplate. "public static void main" etc.
There's a few more, but they'd take more than a sentence to explain.
technically, char is unsigned. For practical purposes use ByteBuffer.
>no freestanding functions
you can "import static" all the static functions you want; it's not any different than C, where you need to include the headers.
> pom files are a huge pain
That has nothing to do w/ java, itself, like at all.
>you can't actually use javac to compile your code. everything is so big and complicated you have to use ant, gradle, maven, etc.
If you use ant, how did you get to use pom? That's pretty much saying that using 'make' is terrible. For personal projects that involve no web, I don't quite need anything else but the JDK, itself. In that case, it's totally doable to call javac form the command line.
Write class Hello { public static void main(String[] args) { … }} into a Hello.java file and issue java Hello.java and it will compile and run your code. It hardly gets easier than that.
Also, it’s a bit unfair mixing in build tools for beginner courses - I doubt beginners start with python virtual envs either. And then don’t get me started on the multi giga node folder hell that you get from a simple Js project.
You could say the class should've been taught better, or that the students just weren't good enough, but I think a good tool (programming language) should help users, not be a barrier to overcome. Programming in Java doesn't require too many concepts, but you have to start with all of them at once, and I think some students just never got over that initial step.
It's of course debatable whether another language would have been better or whether Java really contributed to the problem, but I think we can agree there are languages that better lend themselves to teaching complete beginners.
public class Main {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
print("Hello, world!")
Or where is the import to get "System" into scope? It's imported globally everywhere (just like all everything from java.lang).
So the only question is: should "print" be burried under layers or not. I don't think the advantages of burrying are really worth it.
Apart from that it is really unintuitive to have something "static" within a class (which is commonly understand as a template), it is not encapsulated because it is static _and_ public. _And_ now you can search for this thing everywhere - and what happens if you find two of them?
Yeah no, the idea of "public static void main" wasn't a great one, no matter how I look at it.
It's much better to be explicit and ask the user to decide which file they want to use as the starting point.
> Of course implicit imports are needed, like what else would you have without
They are of course not needed. You could also just import everything manually. Okay, Java's import suck, but in a better language you could do "import prelude._" in the beginning of every file and otherwise you are left with keywords only. Not saying that's a great idea, but it certainly can work without implicit imports.
https://en.wikipedia.org/wiki/Criticism_of_Java#:~:text=The%...
https://www.quora.com/Why-did-Alan-Kay-dislike-Java
https://vic.nightfall.moe/2016/04/03/Some-reasons-why-I-hate...
https://developers.slashdot.org/story/08/01/08/0348239/profe...
I agree with those reasons and I’ve always felt Java sucks because of them. When Java first came out I was a C/C++ programmer and was excited to learn it. Very quickly became disillusioned because it was incredibly verbose. I hoped the language would evolve quickly but it took FOREVER. Meanwhile Microsoft introduced C#, whose v1 looked like a copy of Java, and very quickly evolved the language to make it much better. They did what I hoped Sun Micro would do. But Sun just sat there and twiddled their thumbs.
Java is also a good base for looking at other JVM languages, and for looking at the JVM itself. That's gotta be part of a good curriculum too, doesn't it?