Comment by hintymad

> but not in the granddaddy of OOP languages: Java. Still to this day, I have absolutely no idea how people can write Java for line-of-business applications (its bread-and-butter!) and remain sane from having to manually manage data-flow, implementing Java Beans, and manually writing by-hand getter-and-setter methods...

Because... We don't. IDEs and code generators have replaced a lot of the more stupid boilerplate. Not that there isn't a lot of stupid boilerplate in Java but it's been greatly reduced by tooling.

Still, I don't work with Java because I like it, I work with Java because it works and has a great ecosystem, the tooling around it make it bearable and without it I'd have definitely have jumped ship a long time ago.

I'm not only a Java developer, I've worked with Go, Python, Clojure, Ruby, JavaScript, Objective-C, PHP and down to ASP 3.0. Java is still the language that employed me the most and the longest, I have no love for it apart from the huge ecosystem (and the JVM gets some kudos) but it works well for larger codebases with fluid teams.

"The most tedious work I do right now is adding "one more" scalar or complex data-member that has to travel from Point A in Method 1 to Point B in Method 2 - I wish I could ctrl+click in my IDE and say "magically write code that expresses the movement of this scalar piece of data from here to here" and that would save me so much time."

All of this is possible today and not even that hard (though it's harder than meets the eye, there's a lot of issues that description glosses over that you have to deal with, especially in conventionally-imperative languages). The main problem you face is that the resulting code base is so far up the abstraction ladder that you need above-average programmers to even touch it. (I am assuming that this is merely a particular example of a class of such improvements you would like made.) This is essentially the same reason why Haskell isn't ever going to break out of its niche. You can easily create things like this with it, but you're not going to be hiring off the street to get people to work with it.

Or, to put it another way, a non-trivial reason if not the dominant reason we don't see code written to this level of abstraction is the cognitive limitations of the humans writing it.

I know HN doesn't really like this point sometimes, to which I'd ask anyone complaining if they've mentored someone a year or two out of college and fairly average. You can't build a software engineering industry out of the assumption that John Carmack is your minimum skill level.

Rich Hickey and Clojure have a low-tech solution for you: use maps. This “wiring through all the layers” problem is basically self-imposed by the use of static typing for data objects. Instead you should mostly pass around maps, validate that the keys you care about are present, and pass along the rest.

Of course your Java peers aren’t going to be happy about this, so in some ways a new language is needed to establish a context for this norm. But the limitation isn’t physical, not even in Java.

I use java8 at my dayjob.

It's been years since I did any of that, as Lombok and spring boot generate that code for you.

Immutable classes get a @Value and maybe @Builder annotation, muteable ones get @Setters etc.

Springs auto wiring for beans is sadly magical however, so much harder to figure out what went wrong if you have any issues...

> the granddaddy of OOP languages: Java

I disagree with this statement. Java just happened to become popular due to its C style syntax and various accidents of history.

Smalltalk is the true grand daddy of OOP languages and none of the issues you talk about apply there.

> Still to this day, I have absolutely no idea how people can write Java for line-of-business applications (its bread-and-butter!) and remain sane from having to manually manage data-flow, implementing Java Beans, and manually writing by-hand getter-and-setter methods...

Lombok, at the very least, eliminates “manually writing by-hand getter-and-setter methods” (https://projectlombok.org/).

But when you read a novel, it's full of excessive and redundant code.

You don't write code for the machine, you write it for your team. It's fine if it's nice and comfortable, a bit repeated and fluffy, rather than terse and to the point.

Your code is only read by humans.

> Still to this day, I have absolutely no idea how people can write Java for line-of-business applications (its bread-and-butter!) and remain sane from having to manually manage data-flow, implementing Java Beans, and manually writing by-hand getter-and-setter methods...

My long-standing view is that Java's strict and verbose OOP syntax and semantics are an interface for IDEs. People who are hand-coding are practically guaranteed to be baffled by the verbosity, but they forget that Java development was the driver for IDE evolution (afaik), such that now we have ‘extract method’ and similar magic that understands code structure and semantics.

More specifically, OOP works, or should work, as an interface for IDEs that allows to (semi-)programmatically manipulate entities on a higher level, closer to the architecture or the problem domain.

Like you, I wondered if this manipulation can be harnessed and customized, preferably in a simpler way than giving in to the whole OOP/IDE/static-typing tangle and without writing AST-manipulating plugins for the IDE. In those musings I ended up with the feeling that Lisps might answer this very wish, with their macros and hopefully some kind of static transformations. Which are of course manipulating ASTs, but it seems to be done somewhat easier. Alas, predictably I've had no chance of doing any significant work in a Lisp, so far.

FYI for c# you have resharper allowing to add parameters to method and it would automatically propagate passing it through several levels up based on references. Guess sometimes all you need to know are the right tools.

> granddaddy of OOP languages: Java.

Nowhere near. There was a lot of OOP hype in the early 90s with Smalltalk and C++, so Java just went all-in (everything is in a class) on that trend of the times.

Could you give a concrete example of your problem in a gist or something? I'm curious if it's solvable in C# as is. Sounds like it may be the kind of thing I'm approaching with reflection and attributes right now.

If you're writing in Java, why not write in Kotlin? They're sufficiently compatible you can have Java and Kotlin files in the same directory structure, compiled with the same compiler.

this resonates so much to me

Well, in the case of Java there definitely are ways to minimize the boilerplate. Some of the more common ones that i use:

  - Lombok library ( https://projectlombok.org/ ) generates all of the getters and setters, toString, equals, hashCode and other methods that classes typically should have (JetBrains IDEs allow you to generate them with a few clicks as well)
  - MapStruct library ( https://mapstruct.org/ ) allows mapping between two types, between UserEntity and UserDto for allowing mostly similar objects or ones that are largely the same yet should be separate for domain purposes
  - Spring Boot framework ( https://spring.io/projects/spring-boot ) allows getting rid of some of the XML that's so prevalent in enterprise Java, even regular Spring, and allows more configuration to be done within the code itself (as well as offers a variety of pluggable packages, such as a Tomcat starter to launch the app inside of an embedded Tomcat instance)
  - JetBrains IDE ( https://www.jetbrains.com/ ) allows generating constructors, setters/getters, equals/hashCode, toString (well, there are covered by Lombok), tests, as well as allows for a variety of refactoring actions, such as extracting interfaces, extracting selected code into its own method and replacing duplicated bits, extracting variables and converting between lambdas and also implementing functional interfaces, as well as generating all of the methods that must be implemented for interfaces etc.
  - Codota plugin ( https://www.codota.com/ ) offers some autocomplete improvements, to order them by how often other people used any of the available options, though personally there was a non-insignificant performance hit when using it

As far as i know, there is a rich ecosystem for Java to allow treating the codebase as a live collection of a variety of abstractions which can be interacted with in more or less automated ways, as opposed to just bunches of overly verbose code (which it still can be at the same time). Personally, i really like it, since i can generate JPA annotations for database objects after feeding some tools information about where the DB is and allowing them to do the rest, as well as generating web service code from WSDL (though i haven't used SOAP in a while and noone uses WADL sadly, though OpenAPI will get there).

And then there's attempts like JHipster ( https://www.jhipster.tech/ ) which are more opinionated, but still interesting to look at. I think that model driven development and generative tooling is a bit underrated, though i also do believe that much of that could be done in other, less structured languages, like Python (though that may take more effort) and probably done better in more sophisticated languages, such as Rust.

We use Lombok to automatically generate getters/setters in modern Java

And there's been the business process engine craze in between. BPEL comes to mind which also has 'visual editors' for the business people to use.

It's too complex for them and the you pay Software engineers to use BEPL instead. Which is just a worse language to actually program in than the underlying system.

Or any other number of 'process engines' which give you a worse language to describe your actual process in and then you need to do stupidly convoluted things to do simple things. But hey, we didn't have to code!

> Low Code/No Code solutions don’t work because the people involved in implementing solutions are rarely engineers themselves.

In my experience these are usually too complex for non engineers to understand and incredibly frustrating for engineers to use.

I think that's a fair point. The way I see it, going from requirements (even visual ones) to working system would require strong AI, as any sufficiently powerful visual environment would wind up being Turing complete.

Which means that no code is either use case bounded or claiming something roughly on par with a break through. The first is common enough and where I imagine most low/no code offerings fall when the hype is stripped away. The hype seems to promise something on par with the second and I think that's where the dismissive attitude comes from.

True, but on the flip side imagine how many people tried transmuting lead into gold, thinking the previous attempts simply used the wrong approach.

Either outcome is possible.

Many alchemists tried to turn copper to gold as well. They might as well think that their predecessors are just unlucky by using the wrong implementation.

It would have been sad if we had given up on AI/ML ideas due to the failure of AI back in the 80s/early 90s. See: https://en.wikipedia.org/wiki/Fifth_generation_computer

No Code I feel like could be also viewed as a compromise for selling dev tools to mass market. You can sell a "cheap complete*" solution instead for the overhead of also dealing with customer issues / inevitably helping train a dedicated person for them to maintain their app. Then you have customers who need dev tool support as intended

> many of the existing frameworks be described as low-code wrappers around more complex work flows and concepts

Using frameworks, you are still using the language itself to command the frameworks. For example, if someone claims oneself as a React programmer, nobody would assume that someone didn't know Javascript.

So to efficiently use one framework, you should master both the language + framework. In other words, the complexity not only remains, but also accumulates.

But this is contradictory to low/no code's selling point, as they are targeting non-programmers.

I work at Stacker (YC S20) [0] and the approach we're taking to deliver on this promise is to start with the data.

That is, we let you take spreadsheets you already use and build more powerful collaborative tools on top of them, without code.

If you take the premise that a tool has a 'data' part, and an 'app' part, and that the data models the process, and the app more just controls how data is accessed, presented, the UX, etc, you might see why I'm so excited about this approach -- if you take the data from spreadsheets that are already being used to model a process in action, by definition you don't have to change your process at all.

[0] https://stackerhq.com

Salesforce kinda nailing it (and I say that as Salesforce code crafter, not their no code user).

Have any examples? (Genuine question, not an attack!) I've mostly ignored the Low/No Code stuff for a long time.

With the recent Lambda announcement, Excel is going to have a cool escape hatch for doing more complicated stuff right in the sheet without needing to dive into VBA. I honestly thought I would never get excited about a feature being added to Excel, but I was wrong. This looks friggin’ awesome!

https://www.microsoft.com/en-us/research/blog/lambda-the-ult...

> UML, with the exception of flow charts was very OOP centric. In a world where I still come across people who use OO as a synonym for "good" I can see why they created it that way, but a tool that shapes your design space can be limiting.

To be fair, that can’t be the only reason UML sucks, or even the main reason, because the same is true of Java, and while Java sucks, it’s a much better programming language than UML.

I think a lot of it really does come down to a denial of essential complexity. If you designed a visual programming language in such a way as to actually accept and handle essential complexity you’d be on a better track.

> The lack of detail in the models means autogenerators have to have lots of configuration for each item in the diagram. People would brag that 95% of their code was autogen, and I would realize they had spent dozens of hours figuring out ways to use checkboxes and menu selections to generate the code they wanted. Instead of typing it. And all the hideous autogen vode was a nightmare to step through in a debugger. Large labview projects aren't any better really, but they are popular.

I haven’t worked with these systems you’re discussing, but it sounds like people would be better off handwriting more of the code and only using the visual tools for the part that they’re actually better for. In much the same way that a Wikipedia article about elephants includes photographs of elephants instead of merely relying on long-winded textual descriptions of their appearance, while still having lots of text for the sorts of things text is good for representing.

I think maybe GUI interface builders or HyperCard might be another example of this hybrid approach. I think some incarnations of SmallTalk included similar ideas.

What I have found with GNU radio is that pretty soon, you wanna drop out of the 'graph' view, because you want to dynamically reconfigure your graph.