Takes me back to simpler days when Java was THE language to learn and book like this was interesting. It seems the author took each day in the book as an inspiration for a blog post, which gives it value beyond the book itself.
Takes me back to simpler days when Java was THE language to learn and book like this was interesting. It seems the author took each day in the book as an inspiration for a blog post, which gives it value beyond the book itself.
I taught students in Java and Python and noticed that Python is actually harder. Things you don't even notice, like breathing, make a lot of confusion for newcomers.
The biggest one is types -- students think in terms of meaning, not types, e.g. "this my variable contains first name", but they don't realize it's a string. Or "this is products in checkout cart", but the variable is an integer, so it's products count, not a list of product. Once students get idea of getting an item of a collection and getting a field of that item, while watching every type along the way -- that's a major breakthrough during learning.
The easiest to learn would be a language where you have to define all variable types on top, like Pascal (a language created specifically for learning). But Java is still better than Python, as it doesn't even run wit messed types.
Java would be fine if it and it's community wouldn't force OOP and GOF patterns everywhere.
2003 called and wants its arguments against Java back.
Modern Java can be OOP, functional or procedural where useful. GoF patterns were never enforced by the language.
I'd say GoF patterns were pretty enforced by the language if you include the standard libraries.
Or maybe that's even a bit rude to GoF. Some OO patterns - pretty questionable ones - were pushed pretty hard especially in Java EE.
Java EE practically reinvented itself over the last 20 years using the more popular frameworks as inspiration for better or worse.
Even then, you were never forced to use Java EE if you didn't need it.
Java EE is pretty darn retro right now, and it was never core Java
Does the name of the class inside the file still break the wall and force what the name of the file needs to be?
There is an argument for that being an opinionated part of the Java language, and as i hear it, opinionated programming languages are all the rage.
Fwiw, I like that class names and file names must match. In python codebases I have had annoyances with this when I adopted others work.
Unless you write everything from scratch, you are forced to deal with 20 years of bad design. I really wish people would just stop beating this dead horse.
A lot of de Java standard library is actually quite nice to program with. Of course there are less good parts, but Java is committed to compatibility so you can choose between dealing with an old design versus continually refactoring code to the standard of the day. I prefer having a choice.
As far as Java use in companies is an indicator, the horse is still running.
Well I don't want to come along with you, as while Java might be an ok language, and a great runtime, the cultish Clean Code middle management, and design patterns, with intentionally obscure control flow paths thanks to stuff like dependency injection, and state smeared across dozens of objects (hidden behind interfaces ofc).
Javas biggest engineering upside was that its JIT compiler allowed the runtime to see through this mess and extract decent performance out of 5 layers of dynamic dispatch that shouldn't have been there in the first place.
Add to that the unclear licensing, which meant that there wasn't a single Linux distro that shipped it out of the box, and the development culture it fostered which required 10x the people each spending 10x the time to build features, and single-handedly was responsible for coining the term 'code monkey'.
As for the software - remember Eclipse? I sure do, but I haven't seen it in like half a decade or more, and that certainly doesnt make me sad.