> used to [..] you could look at a piece of Swift code and roughly understand
For all the critique of java, I think this is the one thing java got correct. It is (no matter how verbose or clunky) still easy to read and understand.
For all the critique of java, I think this is the one thing java got correct. It is (no matter how verbose or clunky) still easy to read and understand.
Of course one can't make them understand as they are just following "best practices" enforced at employers.
First of all, in most IDEs, it's very quick to jump to a function's actual definition to investigate such questions as "What if both of the arguments are < 0?" or "Is null an acceptable argument?". With annotations, you'll often go-to-definition and be staring at an almost empty class that hopefully has a docstring. This is because the annotations, themselves, don't actually do anything- you have to go find the code that actually checks for the annotation and does stuff.
In my experience, the docs are often not good enough when I run into a problem. I was wrestling with some strange behavior with JacksonXML some time ago, and I had a very hard time figuring out what went wrong because Jackson has so many options and they don't actually all compose well, so it's not even about figuring out what one option/annotation does- it's about figuring out what happens when I set OptX=1 and OptY=4 at the same time. Unfortunately, the docs only tell me what is supposed to happen when OptX=1 and what's supposed to happen with OptY=4, but nobody has decided to document every single combination of every single setting in the library.
And I would add that Go is obviously easier than Java here by design, but anyone could write a horribly over-abstracted Hello World or Fizz Buzz in any language given the motivation.
Nothing in golang makes it easier to understand compared to Java by design, and the opposite is actually true (e.g. no proper enums, no records, no pattern matching, etc.) make it more verbose and harder to get to the underlying logic.
That being said, you should see some of my employer's golang code with their web framework that they wrote and the 80+ line stack traces.
Could you give an example for your point?
It was impossible to properly trace any behavior through. Every method zigged and zagged through the inheritance hierarchy multiple times as you traced deeper. And so:
> It is (no matter how verbose or clunky) still easy to read and understand.
The sentiment is taken well, but it's just not true. Credit your fellow engineers for the positive experience, not any particular language.
The best part was the perfect C/C++ interop. When I was working on iOS apps in Objective C, I found myself writing a lot of pure functional code using C and it was pretty neat to be able to integrate that with the OO stuff from Obj C so easily and with a clear dividing line.
I think that this comment was written with a positive spirit, but that quote-chopping is incredibly meaning-distorting in a way that counters your point. The original poster stated that Swift "used to be the case that you could look at a piece of Swift code and roughly understand how it would compile to assembly pretty easily" -- you chopped after "understand". There are very few languages where it's /harder/ to understand how they compile to assembly than Java. The JIT compilers are both incredibly complex and incredibly varied, and almost all of them have multiple possible compilation outputs for the same code.
Java, as a language, has been relatively successful in making it easy to understand programmer intention when reading code, as your chopped quote implied -- but the same could be said of Python, Julia, and plenty of others. Swift is in the much smaller category of languages where you can understand how the code will /run/ -- along with C, etc. One could argue that Swift's greatest virtue is that it falls into both categories, but that's another discussion.
Not many people these days can read and fully understand the 64-bit assembly code generated by llvm. I think it is less than 1% of Mac developers.
C++ also have a lot of magic going on. Even C can be tricky with an optimizing compiler.
I don't know what percentage of developers can read assembly, but the popularity of tools like Godbolt strongly suggest it's non-zero. In my own experience, all of the most skilled developers I've worked with have been comfortable digging down to the necessary level -- and doing that in Java, or most other JIT'd languages, is just not fun.
You'll notice that I very much didn't put C++ on either the "easy to understand intent" or "easy to understand behavior" lists -- while it's my preferred language and my primary language, ease of understanding is not its virtue. And while I agree that C compiled with a minimally optimizing compiler (CompCert, clang -O1, etc) is easier to understand than optimized code (for me, the sweet spot for understanding is as compiler that does good register allocation and constant folding, but only really does instruction reordering for memory ops), it's pretty rare that I look at the output of highly optimized code and am surprised or find it hard to follow. Some constructs (medium sized switches, for example) can be pain points... but most often reading assembly output from optimized C is either "yeah, that's about what I would have written" or "close, but you missed this optimization/intrinsic, I'll do it myself."