5 ms·

We learned borland pascal and borland c in high school. Java is perfectly fine.

62951413 3y ago
Don't get me wrong, I miss Turbo Vision-based UIs and an IDE that fits onto a single floppy disk. But the JVM is a professional tool to begin with. So if you cannot start with a toy such as golang or python at least go with Kotlin. Borland Pascal already had reasonable static types, classes, pointers, modules with a public API, and blinding compilation speed in the early 90s. All the basic building blocks to grok. Golang seems to be the closest modern-day approximation.
bedobi 3y ago
I went to a university where Java was the main language for most of the basic programming courses I've been making a living coding in Java for 10+ years I'm a strong believer in types etc etc I still don't think Java is a great language to teach programming lol too much pointless boilerplate and abstraction to achieve the simplest things lots of footguns and objectively bad standard practices built into the language and the native libraries to me Python and Kotlin seem like probably better choices (though they too have massive flaws)
- esafak 3y ago
  What's Kotlin's massive flaw?
  - bedobi 3y ago
    To me the whole point of Kotlin is fixing all the things that are wrong with Java lol But idiomatic Kotlin is still too close to Java, they call it "direct programming style" and it's basically already obsolete Null safety is great but the way they've implemented it with weird syntax like ? and ?.let is not great, it would have been a lot better to just have a regular Maybe type in the native library from the start. Like sure the nullable type is in some ways functionally equivalent, but it doesn't implement map, flatMap, applicative etc like a Maybe does, and when it behaves like it does, it's mostly kind of by accident, not by any real understanding of those operations (and, fatally, it's completely disconnected from map, flatMap etc on lists etc - those should be interfaces that everything that can be mapped, flatmapped etc on implements, not methods that get hurr durr added here and there, sometimes as a regular method called map, sometimes built into the compiler called let) They've completely dropped the ball on error handling - they don't even know themselves whether the language or people using it should use sealed classes, exceptions or their shitty Result class (which, again, this is a solved problem, they could have just included Maybe, Either, Try etc in the native library from the start) Coroutines and structured concurrency are powerful but their API is so extremely confusing and full of footguns that virtually no codebase using them ever uses them correctly to reap the benefits I could go on - don't get me wrong, I love a lot about Kotlin and it's a massive massive improvement on Java but it's not a great language unless you run it with Arrow and learn to completely sidestep large parts of the language (just like you had to do with Java)
- shadowgovt 3y ago
  I've written enough Java at this point to think of it as the assembly of OOP languages. You can write code in it, but in industry almost everything I see is basically a DSL built out of annotations that tries as hard as it can to not involve writing actual Java. When more of your application is annotations than lines of Java code, the language is probably a bad fit for the problem domain.
shadowgovt 3y ago
I learned assembly in high school, and programmed my first FRC machine in NBASIC (a variant of BASIC built specifically for the robot controller back in the day that, among its other delightful quirks, had if statements that were only allowed to be followed by a label and no else clause). Java is "fine" in the sense that NBASIC was "fine." There's definite room for improvement in matching the abstraction to the problem domain.

Don't get me wrong, I miss Turbo Vision-based UIs and an IDE that fits onto a single floppy disk. But the JVM is a professional tool to begin with. So if you cannot start with a toy such as golang or python at least go with Kotlin. Borland Pascal already had reasonable static types, classes, pointers, modules with a public API, and blinding compilation speed in the early 90s. All the basic building blocks to grok. Golang seems to be the closest modern-day approximation.

bedobi 3y ago

I went to a university where Java was the main language for most of the basic programming courses I've been making a living coding in Java for 10+ years I'm a strong believer in types etc etc I still don't think Java is a great language to teach programming lol too much pointless boilerplate and abstraction to achieve the simplest things lots of footguns and objectively bad standard practices built into the language and the native libraries to me Python and Kotlin seem like probably better choices (though they too have massive flaws)

esafak 3y ago
What's Kotlin's massive flaw?
- bedobi 3y ago
  To me the whole point of Kotlin is fixing all the things that are wrong with Java lol But idiomatic Kotlin is still too close to Java, they call it "direct programming style" and it's basically already obsolete Null safety is great but the way they've implemented it with weird syntax like ? and ?.let is not great, it would have been a lot better to just have a regular Maybe type in the native library from the start. Like sure the nullable type is in some ways functionally equivalent, but it doesn't implement map, flatMap, applicative etc like a Maybe does, and when it behaves like it does, it's mostly kind of by accident, not by any real understanding of those operations (and, fatally, it's completely disconnected from map, flatMap etc on lists etc - those should be interfaces that everything that can be mapped, flatmapped etc on implements, not methods that get hurr durr added here and there, sometimes as a regular method called map, sometimes built into the compiler called let) They've completely dropped the ball on error handling - they don't even know themselves whether the language or people using it should use sealed classes, exceptions or their shitty Result class (which, again, this is a solved problem, they could have just included Maybe, Either, Try etc in the native library from the start) Coroutines and structured concurrency are powerful but their API is so extremely confusing and full of footguns that virtually no codebase using them ever uses them correctly to reap the benefits I could go on - don't get me wrong, I love a lot about Kotlin and it's a massive massive improvement on Java but it's not a great language unless you run it with Arrow and learn to completely sidestep large parts of the language (just like you had to do with Java)
shadowgovt 3y ago
I've written enough Java at this point to think of it as the assembly of OOP languages. You can write code in it, but in industry almost everything I see is basically a DSL built out of annotations that tries as hard as it can to not involve writing actual Java. When more of your application is annotations than lines of Java code, the language is probably a bad fit for the problem domain.

shadowgovt 3y ago

I learned assembly in high school, and programmed my first FRC machine in NBASIC (a variant of BASIC built specifically for the robot controller back in the day that, among its other delightful quirks, had if statements that were only allowed to be followed by a label and no else clause). Java is "fine" in the sense that NBASIC was "fine." There's definite room for improvement in matching the abstraction to the problem domain.