6 ms·

> 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

> 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.

Apocryphon 5y ago
Ditto for Objective-C, which by convention handles verbosity in a more elegant way than Java imo.
- skohan 5y ago
  Objective-C is a neat little language. Don't get me wrong - I would never go back to it, largely because of runtime errors due to duck-typing - but there were definitely things to like about it. 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.
ragnese 5y ago
Not in the real world, though. And for similar reasons, too. Most real Java projects I end up working on/with are littered with annotations that do God-knows-what.
- azth 5y ago
  It's trivial to look up the docs to see what they do. It's not unlike looking up what a function call does.
  - ragnese 5y ago
    In my experience, it's much more of a momentum killer and context switch to research an annotation than a function call. 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.
- geodel 5y ago
  In enterprise Java code is filled annotations from some random half-assed framework. While talking to developers I feel they think annotations automatically reduce code. E.g @Validation annotation somehow magically validate input data whereas right in front of their eyes code is still if/else conditions and strings manipulations. Of course one can't make them understand as they are just following "best practices" enforced at employers.
- mypalmike 5y ago
  Yeah, I would say prior to annotations taking over, the Java codebases I worked with were often quite understandable. Annotations have certainly clouded things though. Spring, for instance, is great conceptually but there's way too much magic and clutter when using its annotations.
  - fomine3 5y ago
    Annotation is the worst one that obscure what happening. Java language needed to be improved before annotation/javaassist based approach getting so popular
jdeaton 5y ago
I cant tell if this is a joke. Have you ever looked at a production java codebase once
- jen20 5y ago
  I was wondering the same. It's usually a game of "find the actual behaviour" among a sea of interfaces, frameworks and so forth. Go, I can see the argument for.
  - azth 5y ago
    Golang is quite bad when trying to find an implementation for an interface, because it is quite easy to accidentally implement an interface even if you're not intending to. This also makes it much harder on the IDE to index everything.
- Qub3d 5y ago
  To illustrate the above point (a little hyperbolically) https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - 0xCMP 5y ago
    But what they're referring to is that none of the code in that is hard to understand... unlike in C/C++. This is like of like the same idea behind Go. You make the language simple and straight forward and even though there may be a LOT of code the code will be be easy to understand. 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.
    - azth 5y ago
      > And I would add that Go is obviously easier than Java here by design 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.
addaon 5y ago
> 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. 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.
- silvestrov 5y ago
  I think that "how it would compile to assembly" is a shorthand for "understanding what the code does". 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.
  - addaon 5y ago
    I'd accept "how it would compile to assembly" as "understanding the machine-level behavior of the code," but again, I find this extremely lacking with Java. 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."
hdjjhhvvhga 5y ago
It really depends. Yes, you can more or less easily what each line of code is doing, but figuring out the purpose of everything in enterprise code can be a real challenge. Sometimes I have a feeling someone really wanted to make it as convoluted as possible since the same thing could have been done in a much simpler way. I remember the time when EJBs were all the rage and still can't understand why.

Apocryphon 5y ago

Ditto for Objective-C, which by convention handles verbosity in a more elegant way than Java imo.

skohan 5y ago
Objective-C is a neat little language. Don't get me wrong - I would never go back to it, largely because of runtime errors due to duck-typing - but there were definitely things to like about it. 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.

ragnese 5y ago

Not in the real world, though. And for similar reasons, too. Most real Java projects I end up working on/with are littered with annotations that do God-knows-what.

azth 5y ago
It's trivial to look up the docs to see what they do. It's not unlike looking up what a function call does.
- ragnese 5y ago
  In my experience, it's much more of a momentum killer and context switch to research an annotation than a function call. 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.
geodel 5y ago
In enterprise Java code is filled annotations from some random half-assed framework. While talking to developers I feel they think annotations automatically reduce code. E.g @Validation annotation somehow magically validate input data whereas right in front of their eyes code is still if/else conditions and strings manipulations. Of course one can't make them understand as they are just following "best practices" enforced at employers.
mypalmike 5y ago
Yeah, I would say prior to annotations taking over, the Java codebases I worked with were often quite understandable. Annotations have certainly clouded things though. Spring, for instance, is great conceptually but there's way too much magic and clutter when using its annotations.
- fomine3 5y ago
  Annotation is the worst one that obscure what happening. Java language needed to be improved before annotation/javaassist based approach getting so popular

jdeaton 5y ago

I cant tell if this is a joke. Have you ever looked at a production java codebase once

jen20 5y ago
I was wondering the same. It's usually a game of "find the actual behaviour" among a sea of interfaces, frameworks and so forth. Go, I can see the argument for.
- azth 5y ago
  Golang is quite bad when trying to find an implementation for an interface, because it is quite easy to accidentally implement an interface even if you're not intending to. This also makes it much harder on the IDE to index everything.
Qub3d 5y ago
To illustrate the above point (a little hyperbolically) https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- 0xCMP 5y ago
  But what they're referring to is that none of the code in that is hard to understand... unlike in C/C++. This is like of like the same idea behind Go. You make the language simple and straight forward and even though there may be a LOT of code the code will be be easy to understand. 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.
  - azth 5y ago
    > And I would add that Go is obviously easier than Java here by design 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.

addaon 5y ago

> 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. 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.

silvestrov 5y ago
I think that "how it would compile to assembly" is a shorthand for "understanding what the code does". 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.
- addaon 5y ago
  I'd accept "how it would compile to assembly" as "understanding the machine-level behavior of the code," but again, I find this extremely lacking with Java. 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."

hdjjhhvvhga 5y ago

It really depends. Yes, you can more or less easily what each line of code is doing, but figuring out the purpose of everything in enterprise code can be a real challenge. Sometimes I have a feeling someone really wanted to make it as convoluted as possible since the same thing could have been done in a much simpler way. I remember the time when EJBs were all the rage and still can't understand why.