6 ms·

The job of software engineers is to translate a business domain into software. Different languages are better or worse at modeling different domains of problem

The job of software engineers is to translate a business domain into software. Different languages are better or worse at modeling different domains of problems. I have seen the same problem solved in different languages take 2-3x the amount of work and have a large difference in ongoing maintenance costs. Java's reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs. People get good at modeling problems in Java, but that doesn't mean Java is the right language to model all problems in. A problem that is best represented as stateless functions processing data is a miserable fit for Java, a problem that is best represented as thousands of threads going off to do independent work and then unifying results, is a bad fit for Java. Sure Java can be used, and I'm sure as an experienced Java developer you instantly thought of how to model those problems in Java, but experienced users of languages that map naturally to those problem domains don't have to think of how to translate to their chosen programming language, because the language is a natural fit for that particular problem domain. As a trivial example, I once saw Java used to parse a raw binary stream that had a lot of unsigned ints in it. Miserable usage of Java, tons of wasted space. In a language like C/C++, or even C#, it was possible to just directly map a structure onto the raw byte stream, but for Java they had to read each unsigned 32bit INT into a 64bit INT to ensure no overflow. Horrible mismatch, lots of unnecessary allocations, ugly code, wrong tool for the job!

ivan_gammel 3y ago
> Java's reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs. In my career I worked on a really wide range of business domains and have not even noticed the problems you are talking about. The problem of mapping certain types like unsigned int that you mentioned is rather rare integration scenario. There’s not that many domains where numbers with the most significant bit are important, but MAX+1 size numbers are not.
- com2kid 3y ago
  > In my career I worked on a really wide range of business domains and have not even noticed the problems you are talking about. How many other programming paradigms have you explored in depth and built solutions with? Back when I did OO in Java and C# I didn't think twice about it, converting things to an OO paradigm was second nature, but once I stepped outside my comfort zone and learned of other modeling techniques, I realized that I had been jumping through extra hoops to get to where I wanted.
kaba0 3y ago
> I have seen the same problem solved in different languages take 2-3x the amount of work and have a large difference in ongoing maintenance costs I am sure none of this experiences were basis for an objective experience, there are too many variables. But surely, there are (very few) problems that doesn’t fit Java too well, though it is not an OOP-only language, it is a multi-paradigm one, with many FP concepts seeping into it. E.g. for some ultra low-lat audio processing I wouldn’t choose it, your binary stream processing may be another good example, though it depends on a bunch of factors and in many cases java is more than fine for that as well.
za3faran 3y ago
> reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs You don't have to stick to OO constructs. Java has functional programming support and pattern matching. > best represented as thousands of threads going off to do independent work and then unifying results Java has had executor support for a long time now. And if you're talking about IO bound tasks, Java has virtual threads now. > parse a raw binary stream that had a lot of unsigned ints Java has `Integer.parseUnsignedInt()` and other similar operations.

ivan_gammel 3y ago

> Java's reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs. In my career I worked on a really wide range of business domains and have not even noticed the problems you are talking about. The problem of mapping certain types like unsigned int that you mentioned is rather rare integration scenario. There’s not that many domains where numbers with the most significant bit are important, but MAX+1 size numbers are not.

com2kid 3y ago
> In my career I worked on a really wide range of business domains and have not even noticed the problems you are talking about. How many other programming paradigms have you explored in depth and built solutions with? Back when I did OO in Java and C# I didn't think twice about it, converting things to an OO paradigm was second nature, but once I stepped outside my comfort zone and learned of other modeling techniques, I realized that I had been jumping through extra hoops to get to where I wanted.

kaba0 3y ago

> I have seen the same problem solved in different languages take 2-3x the amount of work and have a large difference in ongoing maintenance costs I am sure none of this experiences were basis for an objective experience, there are too many variables. But surely, there are (very few) problems that doesn’t fit Java too well, though it is not an OOP-only language, it is a multi-paradigm one, with many FP concepts seeping into it. E.g. for some ultra low-lat audio processing I wouldn’t choose it, your binary stream processing may be another good example, though it depends on a bunch of factors and in many cases java is more than fine for that as well.

za3faran 3y ago

> reliance on traditional OO means that only a small subset of business domains naturally map to the language's constructs You don't have to stick to OO constructs. Java has functional programming support and pattern matching. > best represented as thousands of threads going off to do independent work and then unifying results Java has had executor support for a long time now. And if you're talking about IO bound tasks, Java has virtual threads now. > parse a raw binary stream that had a lot of unsigned ints Java has `Integer.parseUnsignedInt()` and other similar operations.