29 ms·
Generating a Java program with 90% less code
- olavgg 7y agoA lot of the boilerplate can be removed by using Lombok https://projectlombok.org/ https://projectlombok.org/ Another alternative is Groovy
- deleted 7y ago[deleted]
- rb808 7y agoI dont think this is true any more, especially with the changes in the last few years. My beef is with Spring. Spring seems to make simple problems very complicated. Its like you have to learn a second more complicated API on top of the original. Plus when something goes wrong you get some 100 call deep stack trace. I just wish there were more pure Java applications without the Spring magic.
- m0ck 7y agoHave you tried Spring Boot? It reduces lots of the "complicated" stuff to declarative annotations and will provide you with very reasonable defaults for most use cases.
- mrkeen 7y agoI dislike Spring "at the margin". I do prefer Spring Boot because it's less Spring-like than Spring.
- oftenwrong 7y agoAnnotations often bring with them implicit, hard to debug, "magic" behaviour. I prefer boilerplate over annotations.
- 3fe9a03ccd14ca5 7y agoI really enjoy using spring boot. My problem with Spring is that it feels like I’m mostly metaprogramming with annotations. Also I hate that I need to literally use a program to create the boilerplate for a new spring app. And I can’t run my program without special IDE settings.
- tetraca 7y agoWeird, I've never really needed to use special IDE settings for my Spring boot projects at all; I can just gradle run my project, maybe with a different profile set in the environment.
- 3fe9a03ccd14ca5 7y agoThis works for me most of the time. I use a program to generate the build.gradle, and then that file builds my project through my IDE. It’s meta all the way down.
- tonyarkles 7y agoI admittedly didn’t spend a whole lot of time with Spring Boot; I mostly did Ops with projects other teams build with the occasional Dev assistance when they painted themselves into a corner. But I’m hoping you might be able to help with a question I haven’t had much of an answer to: I agree there’s a lot of “metaprogramming with annotations”, but I didn’t ever find a great way to dig into an annotation and figure out what the hell it was actually doing, or how. Do you have any pointers for pulling back the curtain? Edit: for example, Python “annotations” are generally just functions that return wrapped functions/attributes/classes/whatever. Java annotations seem significantly more “magical” than that.
- vbezhenar 7y agoJava annotations are meta-data, they don't do anything. Actual code which uses those annotations is located elsewhere. Usually you can use "Find usages" for a given annotation to find the actual code.
- commandlinefan 7y ago> you have to learn a second more complicated API on top of the original ... that also doesn't actually benefit you in any tangible way.
- itronitron 7y agoI recall a veteran software developer commenting back in 2000 that a class written in Java was less than one third the length of the same one written in C++, so it's compactness definitely fueled it's popularity. Since then, J2EE and EJB led to a lot of boilerplate and now everyone thinks class and member names in Java have to be at least three or four words long.
- MockObject 7y agoI'm always suspicious of people who offer opinions about Java, but then mention "J2EE", a term which has been obsolete since 2006.
- eitland 7y agoYep. And JavaEE that came after has actually made things a whole lot better. Idiomatic JavaEE can easily be <10% boilerplate.
- AnimalMuppet 7y agoThe boilerplate isn't just in writing an individual class, though. It's also in the extra classes and interfaces that you might not create in C++. And I wonder how much of the "compactness" you describe is simply because of Java's library. Library calls are very compact; having to write the code yourself (because your ecosystem doesn't have that library) is much more verbose.
- towndrunk 7y agoHave a look at http://sparkjava.com/ http://sparkjava.com/. Very simple and pure.
- csunbird 7y agoI can identify myself as a strictly Java developer (nowadays) and my experience with Spring can be summarized as either: > I imported that autoconfiguration library and everything works! > Damn it, the imported autoconfiguration library does not work (or I need to change something), now I have to spend a day around Spring docs and stackoverflow to find how to get it working. Than I have to create a new class, override some random methods and inject my ugly code which feels like a hack now...
- krooj 7y agoThis hits home. A lot of my work seems to be mopping up the mess that developers created by doing the former and applying the latter. Autoconfiguration is great for quick demo-days and a literal cancer for everything else. Frankly, after some recent development on ES6 + node + express, I'm starting to question whether staying on Spring + Java is worth it.
- oauea 7y agoJust read the source. You can jump to the implementation of the autoconfiguration in your IDE, and they're usually only a dozen lines or so of bean creation.
- teknopurge 7y agoSpring seems to make simple problems very complicated. This. My god, this.
- ronnier 7y ago> We define the UserProvider interface I'm strongly against creating interfaces for non-library (not shared) code, that will only ever have one concrete implementation. I see it all the time in internal service code, code that will never have a second implementation. It makes code hard to navigate, harder to understand, and tedious to manage as instead of updating one file, now you'll need to update two.
- 3fe9a03ccd14ca5 7y agoI find myself doing this often and it’s annoying. Usually it’s because I want to use some other implementation for testing that never materialized, and then the interface sits there.
- oldmanhorton 7y agoDo you consider test mocks to be a second implementation that warrants the interface?
- ses1984 7y agoThere are test frameworks that obviate the need to do this.
- gautamdivgi 7y agoNot if you use something like c/c++. There are test frameworks but there is no way from preventing testing code from leeching into functional code. But yes - Java/python, etc. you shouldn't need to do this.
- taco_emoji 7y agoNot on all platforms. In .NET you need an interface or virtual method in order to allow the mocking framework to dynamically generate a concrete subclass that mocks out that method's functionality.
- CraigJPerry 7y agoWhat’s cheaper to own though - a whole test library / framework (assuming you don’t use any other feature), or a simple interface? I’m generally hesitant to add test libraries if there’s an easy design choice alternative that keeps the code simpler.
- m0ck 7y agoThe title should be tagged with [AD]
- throwaway13337 7y agoInterestingly, it's the culture of Java that makes it verbose. You can write concise pure Java if you don't rely on libraries, have unit tests, or do things the Java way. It's too bad, too, because there are some things to love about Java, really. It's simple, it's super fast thanks to the jvm, and it's well supported.
- Yessing 7y ago> It's simple, it's super fast to what baseline are you comparing it to?
- ReverseCold 7y agoThis is potentially a bad example, but the current "fastest" web frameworks as per the techempower benchmarks are all Java.
- pkroll 7y agoThey're not: C++ and Rust have winners for some of the tests.
- floriol 7y agoOf course you can write more performant code with lower-level languages, though there is a reason that almost no web framework/application is written in them - the additional burden of managing memory outweighs the (actually surprisingly little) performance benefit. If you look at examples on the site, in basically every other benchmark Java and sometimes Go rank the best.
- ReverseCold 7y agoI should clarify that I sorted by fullstack frameworks with ORMs. Obviously C or C++ can be made faster. Too late to edit now though.
- Yessing 7y agoI'm not familiar with it, do you mean this one? https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ Rust, C, and Go appear to be on the top.
- nine_k 7y agoCompared to the currently fashionable Go, Java has quite little boilerplate. Java 8+ has a number of quite powerful APIs in the standard library, some limited type inference, reasonable interfaces that allow default methods. The compiler has a well-defined custom processing interface (@annotations) which allows for powerful boilerplate-reducing things, from Lombok to Spring to JUnit. 80% boilerplate is a large exaggeration.
- icholy 7y agoIdiomatic Java has much more boilerplate than idiomatic Go.
- bdamm 7y agoif e3 != nil { return _, e3 } over and over and over..
- zzbzq 7y agoControl flow is not boilerplate, that's the application logic.
- nicoburns 7y agoIt's boilerplate compared to languages with exceptions where this code isn't necessary, or Rust where the equivalent code is: e3? ^ Go could very easily add this syntax, but haven't for some reason.
- deleted 7y ago[deleted]
- randomidiot666 7y agoSounds like you're not aware of the changes since Java 8 (2014). This is idiomatic Java nowadays: http://sparkjava.com http://sparkjava.com
- 7y ago
- platz 7y agoThat's RAD
- znep 7y agoTL;DR - "Here is a lot of boilerplate code that doesn't seem necessary for what you are doing in this case..." ... "Hey look another tool that can generate a lot of boilerplate code you then have to deal with and makes the easy stuff easier and the hard stuff almost impossible!"
- injb 7y agoWhen I used to use Java, the thing that I found remarkable was how much stuff you had to write in other languages. You had Spring, Ant, Hibernate, Ibatis, text-based "properties" files etc. It seemed that Java programmers were willing to go to great lengths to avoid writing anything in Java. But if Java was so unsuitable for such a wide range of tasks, what made us think it was a good general purpose language? In contrast, when I started using Python, one of the things I liked was how suitable it was for all the things that Java developers typically used other languages for. Your typically Python project back then contained very little that wasn't Python, because there weren't many things that it wasn't useful for. Things may have changed with Java in the 9-10 years since then but I think that was certainly one of the things that led to Python becoming more popular.
- Nursie 7y agoThis is not really true any longer. Spring, thankfully, seems to be going away. Java itself is now far more feature-rich in terms of lambdas, anonymous classes, stream processing etc. I came back to java about 4 years ago after a long time away and have found it quite pleasant, and quite different to how you describe it. I think I skipped the 'enterprise' years, thankfully!
- Turbots 7y agoSpring is by far the easiest way to write modern web applications with REST APIs, a frontend, database layer, messaging integration, whatever. It basically does all the boilerplate for you and leaves it up to you to just write your business logic. I don't know how you can miss that.
- oftenwrong 7y agoSpot on. Thankfully it is becoming more common to Just Write Java. Java without the frameworks and other bloated crap is actually decent. The language itself has a lot of warts, but the Java ecosystem is one of the best (Python too).
- MH15 7y ago
- CoolGuySteve 7y agoJava seems to rely a lot on IDE tools to autocomplete, autorefactor, generally shovel around all this boilerplate. It always seemed weird to me. Like if my house was really cluttered but instead of building shelves or closets into the house itself, I buy an elaborate conveyor belt and excavator system to rearrange all my things all the time so I can walk through all the mess.
- itronitron 7y agoI am sure many people feel the same way about Python and Javascript. What you described seems to be a result of building larger systems in which multiple people are contributing code.
- nurettin 7y agoI confirm this. I rename classes and move them around, and without a refactoring tool that renames files and changes imports automatically, life would be very hard. Before refactoring tools got to this level, I was running pytest to see what import statements got affected during my refactors.
- dep_b 7y agoWould the language described in the article (Unitliy) be harder to refactor? Why? Python is not static typed, it won’t refactor as easily.
- salawat 7y agoUh. Question. Why are you executing tests to get the compiler to tell you what was effected instead of doing a top level recursive grep to identify any classes or configs with an explicit symbolic dependency? I mean, you get the same result, sure, but I find I can hardly ever rely on test coverage alone as an accurate safety net to clearly indicate whether I've reached an actual stopping point for a full refactor. This is one of the ways in which Java excels, in that that loop is fully accommodated for in most major IDE's. You can still get caught by surprise at runtime, but I've found that for a strongly typed language like Java, the syntax, and necessity of boilerplate makes most bugs obvious until you start getting overly dependent on frameworks you don't understand.
- bonyt 7y agoA lovely ridiculous parody of "Enterprise" style Java: https://www.github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://www.github.com/EnterpriseQualityCoding/FizzBuzzEnter...
- charleslmunger 7y agoLots of the boilerplate they create is totally unnecessary; other boilerplate can be avoided through use of common open source libraries, like AutoValue [1] for equals/hashcode/toString. No need for custom compilers, new ASTs, or a whole new language. Don't create interfaces for classes that only have one implementation, and don't create gratuitous indirection. [1] https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value
- humbleMouse 7y agoSo tired of stupid articles like this hating on java. Java is an extremely flexible language with an insane amount of libraries, frameworks, and design patterns. Furthermore, using groovy is amazing, and can reduce your lines of code quite a bit. The author of this article just sucks at implementing java.
- mrkeen 7y agoSomeone criticises Java for being verbose, and you want to refute that with: > using groovy is amazing, and can reduce your lines of code quite a bit ?
- humbleMouse 7y agoYou just cherry picked one part of my rebuttal. Again, java is an extremely flexible language, and the verboseness is up to the user. You can implement very verbose code in plain java, or you can write extremely concise code in plain java. It’s up to the user.
- jimbokun 7y agoWell, the punchline is they wrote a tool to implement Java for you, with either a GUI tool or a DSL. So you still have those libraries and frameworks, and its a similar strategy to using Groovy, but presumably doesn't have the same performance penalty as it generates idiomatic Java code.
- winstonewert 7y ago"Good code is 90% boilerplate" Have you considered that you might be doing it wrong?
- Nursie 7y agoI find this disingenuous from the outset. No, the class name is not boilerplate. No, using parentheses rather than whitespace to indicate scope is not really cutting out boilerplate. No, defining custom hashcode, equals and toString methods is not boilerplate or even always necessary, that's something you've chosen to do. Much of the complaint about things like constructors and getters/setters can be resolved using something like lombok. Honestly this looks like someone really labouring the truth in order to try to prove a point.
- Turbots 7y agoJava was meant to be read more than to be written. I was a Java/Spring developer for 10+ years and I literally didn't write 90% of the stuff he's referring to in the document. Use IDEs to write faster, manage larger projects and browse through and read the code much faster. It is so standardized by now, you could literally open any Java+Maven project and you would be able to tell what it does in very little time. That's what I hate a bit about Gradle, it removes the standardization and makes every project a snowflake again, like in the Ant days... I'm overreacting, but that's the jist of it.
- UglyToad 7y agoI'd imagine people criticise Java for the same reason they criticise PHP, or C++, or many other languages. It's very easy to attack a strawman based on outdated best practices from more than a decade ago ignoring the fact that both the language and the best practices have moved on and many people are very productive in those languages. When I started learning C#, less than a decade ago, best practices were "Uncle Bob" style nonsense, ultra-fragmentation of the codebase, interface everything, boilerplate everywhere, pointless mocking and testing of components which should have been treated as purely internal. But you look at what changed in C# -- generics, dynamic, LINQ, async, auto properties, etc. -- in the last few versions and it's a brilliant language that can be written as verbose or as golfed as you please (I lean now towards verbosity and loops over LINQ just because while I think LINQ makes you feel clever it's also harder to reason about). Now I don't do Java other than porting a Java codebase to C# but I'm under the impression Java has been on a similar journey with streams and whatever else. Much like PHP or C++, workhorse languages that aren't 'sexy' but are widely used and keep the internet and society running. Different people like different things and that's ok (but assuming this new language from the advertorial doesn't support autocomplete, easy refactoring, whatever else it's going to be a hard sell to get productive teams to switch over to it!).
- pron 7y agoSee records, coming to Java next year: https://openjdk.java.net/jeps/359 https://openjdk.java.net/jeps/359
- dclusin 7y agoA lot of boilerplate can be reduced by using Project Lombok. It obviates the need for a lot of this boilerplate. You can annotate a field with @Getter/Setter attribute and it will automatically generate getters and setters for you. You can also do @RequiredArgsConstructor, @Data class etc. I tried Lombok but didn't end up continuing to use it. An IDE like Intellij makes working with java painless enough to where Lombok didn't feel like this life changing solution. - https://projectlombok.org/ https://projectlombok.org/
- JackFr 7y agoAfter developing software professionally for 30 years, I've come to believe it largely comes down to tastes and fads. I've programmed professionally in Fortran, C, C++, perl, C#, Python and Scala and various SQL flavors. I've dabbled in JS and R and have no experience with Go or Rust. You can write verbose garbage in any language and you can write clean, well factored code in any language. The garbage I'm most familiar with is "Consultant Java" where every class has an interface, every field has a getter and setter, every method (especially the getters and setters) has Javadoc -- oh and the test coverage is 100%, thanks for asking. But you've got 450K lines of code for an app that does CRUD on 3 tables. I've seen virtually the same thing in C#, only with the added magic of the latest MS Framework. And if "boilerplate" is such a bad word, how did Ruby on Rails ever succeed. It's an environment literally built on boilerplate. And don't get me started on perl. There are perl scripts that were healthy until they kept dividing until they were cancerous "systems" throughout the enterprise. C++ pissing contests between developers intent on showing their worth by writing the most difficult code possible. So why do have so much garbage out there? Because programming is a human endeavor. We have tastes. We're often unwittingly subscribe to faddish beliefs. We all suffer from a host of cognitive biases that will always prevent us from seeing things clearly. I can say with certainty that particular tools are better suited for particular jobs. At this point though, you can't pin me down as to which for which. I can say that in the past I enjoyed using C and Java and I didn't enjoy C++ and C#. I was lukewarm over Python. I currently enjoy using Scala and I think I am most productive in it. But that is more about me than the languages. Importantly though, I think they all contribute to the software industry in ways that are not always obvious.
- wefarrell 7y ago> And if "boilerplate" is such a bad word, how did Ruby on Rails ever succeed. It's an environment literally built on boilerplate This is not remotely true. "Don't Repeat Yourself" and "Convention Over Configuration" are the two core tenants of the Rails philosophy[1], both of which are intended to reduce boilerplate. This is why you don't have to specify table names, foreign key names, controller endpoint paths, view file names, etc... [1]https://edgeguides.rubyonrails.org/getting_started.html#what-is-rails-questionmark https://edgeguides.rubyonrails.org/getting_started.html#what...
- mumblemumble 7y agoSo, this catches me in the midst of an effort to try and migrate away from Java (albeit to another JVM language) because I'm sick of the amount of effort it takes to maintain Java code. But, all the same, I want to play devil's advocate and argue that a lot of this mess is really about Java-the-culture moreso than Java the language. You can use `public final` fields instead of private fields with getters but no setter. You can use public fields instead fo a private field plus a getter and setter, too. It'll save a lot of boilerplate, and, if you're doing it right, be functionally equivalent. The only things stopping you are cultural factors. First and foremost, it's taboo. That's, frankly, the usual reason. Second, some libraries that rely on reflection aren't equipped to handle fields. Not because they can't, but because the getter/setter pattern is so culturally entrenched that not following it is almost unthinkable. Finally, and this is the prototypical reason that motivated this idea in the first place, because, 20-odd years ago, some very clever people decided that it should be very easy to do Truly Obnoxious and Anti-Social Things like replacing a simple field access with a database round trip or some spooky-action-at-a-distance state mutation without having to tell any of your colleagues what you'd done. To an approximation, a big motivation for the functional backlash against OOP is the realization that maybe we shouldn't be so quick to enable ourselves to do Truly Obnoxious and Anti-Social Things. Maybe it's even desirable that we not do that. Of course, politeness mandates that we couch that observation in gentler language using terms like "referential transparency." This maybe speaks to another aspect of Java's culture: Perhaps due to its corporate roots, Java developers tend to rely strongly on thought leaders for advice. Regular book authors, conference speakers, bloggers, etc. are the arbiters of best practices. The more books, lectures, and blog posts one delivers, the more name recognition one has, the more trusted ones opinions become. In the limit case, you spend all your time telling people how to maintain code, and no time actually maintaining code. Strip all that mental noise away, and, while it doesn't turn Java into my favorite programming language, it at least gets easier to see how Java doesn't have to be any more of a boilerplate-ridden mess than any other language of its generation. Just don't try actually writing clean Java code at work. That's a path that can only lead to unemployment.
- dougk16 7y ago"...they've developed a way of writing maintainable code, but the language knows nothing about it, and is not expressive enough to describe it succintly." Good quote. I used to struggle with this feeling when I got to roughly the ten year mark professionally and finally started to feel like I knew what I was doing. But, with the help of a little Stockholm Syndrome perhaps, I've learned to embrace the boilerplate as part of my workflow and use it to an advantage. I came up with a saying "write twice, debug once", from the old carpenter's saying "measure twice, cut once". The idea is that if you're writing sort of the same thing twice, the compiler and/or PR reviewers can at least check if those two things are consistent with each other, and debugging is more straightforward instead of a long slog. You may still write the same thing wrong twice, but that's much harder to do than writing it wrong once. I think this is a hidden value of automated testing as well. I could talk for hours about whether automated testing is "worth it" depending on the project/language/team/etc., but one thing most people don't consider is the value in the mere act of writing out some logic that must be consistent with other logic, and the inconsistencies you can find without even having to run the test. Essentially another "write twice, debug once" scenario. I know that's all kind of vague, and I don't have time to get into specific examples, but this encapsulates the feeling I have now working with Java. The feeling that I'm sort of fact-checking myself, even though it's tedious. Sort of a "show your work" thing.
- lexpar 7y agoThis may have a kernel of truth to it, but it's difficult to treat as objective when the article is essentially an advertisement for the language the author is developing.
- manishsharan 7y agoWe,enterprise java dev shops, don't mind because 90% of all enterprise applications are bloody CRUD apps.
- DaveSchmindel 7y agoAbsolutely important to bring up. I don't care how creative you allow your developers to be while they leverage Ruby/Python/etc.; At the end of the day, they're accessing data from a DB and serving it to a client...
- sna1l 7y agoLooking at the youtube video of actually using Unitily, it seems way more complicated to me of having to learn how to use this UI interface. Personally I think with tools like Project Lombok, auto/value, and IDE tools, you can streamline boilerplate code fairly well.
- chopin 7y agoI personally like the explicitness of the language even if it is boiler plate (with some exceptions like checked exceptions in lambdas). It makes average code very readable with only little caveats. More than one time I struggled with my own code at a later point in time because I wanted to avoid duplication at any cost.
- 29athrowaway 7y agoThe toString method does not use a StringBuilder. Each concatenation will create a new string. That is not good. If you find Java verbose, just use Scala or Kotlin.
- miskin 7y agoUsing StringBuffer may be premature optimization. Java compiler will replace simple String concatenation with StringBuffer automatically [1] and you do not need to polute your code with StringBuffer unless you really find that to be performance bottleneck. [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.18.1 https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.htm...
- lostmsu 7y ago90% of this post is BS. They spend most of the characters on overriding toString, equals, and hashCode to never use them.
- DrScientist 7y agoYes - Java spells it out. ie A lot of the 'boiler plate' is stuff that allows the compiler to check for errors, and humans understand the code but at the same time allows you to vary behavior if you want. Java also has language simplicity and consistency [1] ( few syntax short cuts ) - which helps humans understand code - the coding equivalent of 'plain english'. Whether you see that as a good thing or not depends on whether you are writing self contained scripts or large long lived complex systems. [1] the later bolted on generics, not so much.
- hpoe 7y agoJust figured this article (or copy of an article originally posted by Joel on Software Engineering) fit in this discussion. https://pastebin.com/VJUNqsU3 https://pastebin.com/VJUNqsU3
- foobar_ 7y agoJava OOP is embarrassing. Design patterns are inconsequential in FP / Go / Erlang. It should not be taught in schools. Startups should stay as far as possible away from it. Java Enterprise software and programmers need to die a slow death. Ruby style OOP has its place but nothing closed-minded needs to be respected, let alone coddled.
- Nursie 7y ago> Java Enterprise software and programmers need to die a slow death. The Java 'enterprise' era is over. Java 8 onwards is much more expressive, functional and concise. Java is no longer what it once was, nor is it the domain of the enterprise nerds any longer.
- eitland 7y agoI find it interesting how you think I need to die slowly ;-) I have a much more constructive approach: people in this thread should spend as much time and effort learning correct Java as I've spent learning correct Python and Javascript. In fact a lot less should do: I came to Java with a dislike (school did a very poor job lf teaching it and I already knew enough from other languages to see how hopeless what school taught me was). I kept programming my favourite language but after seeing the immense benefit of having a working type system and a good ide I mostly left lther languages behind until modern .Net became cross platform and also I had to start doing frontend work.
- dang 7y agoPlease don't break the site guidelines like that regardless of how strongly you feel about enterprise software and programmers. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- joshlemer 7y agoMy biggest beef with idiomatic Java code is that it is so annotation-based. For example, I recently had to do a small CLI app in Java, and the command line parser library that came up in searches was picocli. Now, I mean no offence to the creators of picocli, it's pretty typical of most java code in my experience, but why does it have to do everything via annotations? Take their example for instance: https://github.com/remkop/picocli#example https://github.com/remkop/picocli#example Not sure why a "just plain data" approach couldn't have been taken so that instead of: @Option(names = { "-v", "--verbose" }, description = "Verbose mode.") private boolean[] verbose = new boolean[0]; You could've had something more... Option<boolean[]> verbose = Option.<boolean[]>newBuilder() .names("-v", "--verbose") .description("Verbose mode.") .default(() -> new boolean[0]) .build();
- eitland 7y agoBecause then people like the ones tearing down their strawman "Java is verbose" would be closer to having a point. Annotations work really well: they are easy to write, easy to write and typesafe enough.
- joshlemer 7y agoBut they are in my opinion really difficult to understand, test or customize. In the example above, the reified Option<boolean[]> can be passed around, transformed, inspected, invoked in tests, etc. The annotation approach weaves together the aggregate class (the overarching config class), the specific field of the class (`verbose`) and how that field should be parsed from command line arguments.
- eitland 7y agoOk. I can try to help: In this particular case, when you test you just set the field to what you want. In other cases where you actually want and need to test that the annotations works at runtime you use a test container (Arquillian was the big thing for integration testing JavaEE last time it was relevant to me, and since we are talking enterprise Java there's a fair chance that Arquillian will still work and maybe even still be the most popular solution.)
- The_rationalist 7y agoKotlin solve everything about it.
- datalist 7y agoGroovy did so long before that ;)
- The_rationalist 7y agoClearly it's sad no big corporation or community is behind this beautiful language. Therefore I believe kotlin has obscoleted groovy. (except if you really want dynamic typing)
- humbleMouse 7y agoBlows my mind how rare it is for anyone to mention groovy on hackernews. Groovy is amazing and turns java into a wild west language where anything is possible.
- zmmmmm 7y agoIt also takes a very opinionated approach in how it does it. That's fine if you want it, but if you just want dramatically less verbose code but otherwise are completely happy sticking with the general principles of Java, something like Groovy is a nicer option.
- SmooL 7y agoJava hate aside, I love the idea of pictorial format for specifying data flow. Haskell is wonderful in its partial application, '.' composing, and other such tools, that really let you quickly and easily specify how your data flows through your functions. My gripe is that it starts getting weird when the order of arguments don't line up, when you have to swap some values, when you have to take a partial result and only apply it 3 steps later.. the Haskell syntax really breaks down from its usual purity in those cases. A flow diagram picture, similar to as shown in the article, makes it immediately obvious what is happening. I wish there was more integration with current IDE's for this sort of different representation styles
- on_and_off 7y agoIt feels like beating a dead horse. There are other options on the JVM like kotlin that are pretty much boilerplate free. I will say this for java though : it has what is in my experience the best IDE support. Kotlin is not that bad but all these generated sugar (e.g. in a data class) make some operations like "find usages" way more complex and slower.
- wrd83 7y agoSo a lot of the complaints are not entirely true anymore. If you onboard lombok, you get data classes, which resolves the property boilerplate. If you use IntelliJ the code is generated. I used Java and Go and I have to admit, that Java feels like the more practical language. Generics and error-handling are really painful in Go. The most painful part in Java is having to deal with other people's code that makes it look weird. Google has a very good set of libraries that make the Java world much more pleasant.
- nostrademons 7y agoKotlin is basically Java without the boilerplate. Some of the code snippets on the page, translated into Kotlin, would be: data class User(val username: String) data class Config(val userTable: DynamoTable, val userId: String) typealias ItemToUserConverter = (Item) -> User class DynamoDbUserProvider( val configProvider: ConfigProvider, val userTableProvider: UserTableProvider, val dynamoReader: DynamoItemReader, val itemToUserConverter: ItemToUserConverter) { fun execute(id: String) = itemToUserConverter(dynamoReader.execute(userTableProvider.execute(config), id)) } Plus it comes with great debugging/refactoring/IDE support, async/await, type inference, and good Java integration.
- pkulak 7y agoI've heard Kotlin described as what Java would be today if it didn't have to maintain backwards compatibility, and I think that's the perfect way to think about it. But it still compiles down to the same bytecode, so there's near perfect interoperability with any other version of Java you like.
- smabie 7y agoAnd, Scala is Kotlin without the boilerplate. Scala is the most expressive and powerful language on the JVM, hands down. Kotlin is just a poor imitation. Of course, Java is way worse than either, but unless you are targeting Android, do yourself a favor and use Scala. Closure is okay, I guess, but I find dynamic typing and the dogma of Clojure counterproductive.
- nostrademons 7y ago> Scala is the most expressive and powerful language on the JVM, hands down. So I'd agree with that statement... > do yourself a favor and use Scala ...but not that one. I've found that Scala gets too expressive, much the same way that writing production code in Common Lisp or Haskell can be slower than just writing it in Python. It offers incredibly powerful abstraction capabilities that can often dramatically reduce the amount of code you write; but at some point you end up spending more time hunting for the perfect abstraction than actually writing the code. The ideal programming language (for productivity at least, not necessarily for fun or erudition) is one that melts into the background when you program so that you can focus on the problem domain rather than the program. That's the main appeal of languages like Go, Java, and Python: they offer just enough power to write the program, but not so much that you can write the program in a dramatically better way and end up tempted to try and find that way. Kotlin embraces the "it's just a better Java" approach: it's a minor re-skinning of the concepts in Java, and to the extent that it introduces new language features (like closures, lambdas, properties, data classes, anonymous objects, type inference, and immutability), they're all concepts that skilled Java programmers would be immediately familiar with but would otherwise have to write lots of boilerplate for. The Java interop story is also better with Kotlin, because Scala introduces abstractions for which there are no obvious Java equivalents, and hence there's an impedance mismatch when you try to envision how your Java libraries might fit into your Scala program. Kotlin's designers took care to make sure that there's an easy, intuitive mapping between Kotlin concepts and Java ones, usually one that had already been enshrined in existing Java conventions (eg. JavaBeans work nicely with properties, functional objects with lambdas), so most Java libraries just work in an obvious way. Basically they intentionally made it dumber so you don't have to think about as much, which is a win for everyday programming.
- raldu 7y agoThe infamous "FizzBuzzEnterpriseEdition" relevant to the topic, https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- DaveSchmindel 7y agoIn my opinion, this is the reason Java still _mostly_ remains the enterprise choice; When things are mostly boilerplate under the hood and following a small set of patterns and principles, it's really easy to onboard/ditch engineers. That said, I like the motif brought up here, and I think the only thing lacking from the piece is how this stifles developers' engageability and creativity.
- datalist 7y agoThats not Java. These are the wet dreams of some CS graduates who fell in love with Spring and Hibernate and take rough OOP guidelines to extremes. Nobody - NOBODY! - used to write such Java code in the 2000s, at least the early ones. This insanity slowly started around 2005 and then really took off late 2000s and then particularly 2010s. Again, thats not Java.
- eitland 7y agoAnd in the late 2010s JavaEE broke through and things are now really really nice if you are working on a modern Java project where people know what thwy are doing.
- Yessing 7y agoThe thing I hate about java the most is: -that generics don't play well with primitives and arrays? I understand that jep218 aims to fix the first one. But it's been quite a few years now and why was this not done the right way from the start? > equals() and == I think these should've been switched. A general principle in languages (not only in programming languages) is that things that are used often should be short. Plus - get() and charAt(), instead of []. just why? - verbose naming conventions: Excessive redundancy does not increase safety or improve maintainability. Having one blinking red light is useful, having a thousand lights of different importance will just make you filter it out. People will simply gloss over and skip long identifiers. we are humans and we can't operate at full attention the whole time. if something has low information content, we simply go on autopilot. Easy things should be short, so that the hard things popout in the code. - Obsession with software engineering and OOP Principles? Instead of thinking about the data structures needed and the alogirthms chosen, time is spent just making a millefeuille of abstractions.
- jayd16 7y agoJava not having operator overloads as a design choice explains the majority of your complaints. Generics are built around type erasure and as such generics treat the type as Object at runtime. Primitives cannot be treated this way. The reason its not a simple fix is because the language designers are not willing to break compatibility to make this happen. The style complaints are an artifact of Java being a popular corporate language but there's no reason you need to write Java this way.
- madhadron 7y agoIf I understand correctly, the author has written a program in their pet language, translated it directly to Java, and complains that you have to write a lot of boilerplate to do 1:1 translation from their language to Java. I think the right consideration is that they have simply done a poor job writing this program.
- jillesvangurp 7y agoConvert your code to Kotlin (idea will do this for you). It won't get rid of the boilerplate automatically but it will de-clutter your code and then put you in a position to refactor to be more idiomatic Kotlin. Once you get that sorted, you can start thinking about creating a DSL for things you do a lot and get smart about eliminating boilerplate. IMHO javascript/typescript looks more boiler plate heavy these days than well written Kotlin. I know bashing java for boilerplate and verbosity is popular but a lot of its reputation is people doing repetitive stuff without reflecting on better ways to do these things. I see the same patterns and mistakes in other languages. The best code is the code you don't need to write. Likewise needless abstractions and over-engineering are a problem in many places. Java certainly has seen its fair share of that and its a reason I avoid the entirety of the Scala ecosystem in principle. Nothing wrong with the language but it seems to provoke over-engineering.
- datalist 7y agoNothing against Kotlin, but please spare us the Kotlin hype. Groovy was streamlining Java long before Kotlin even had a name.
- vbezhenar 7y agoThe only Java boilerplate that really bothers me is getters/setters. Lack of properties in Java is depressing. And even more depressing lack of any plans to add properties. There are records for Java 14 which somewhat solve the issue, but they really aimed for a bit different use-case (which is not even that important for me, personally). Honestly the only reason I would choose Kotlin over Java today is properties. Everything else is nice to have, but absolutely not important.
- wtetzner 7y ago> Everything else is nice to have, but absolutely not important. I would argue the null-checking is important.
- vbezhenar 7y agoThose who need null-checking can use @Nullable @NonNull annotations with static checkers. I've found Idea pretty good and it'll work very similar to Kotlin. Some popular libraries already annotated their interfaces.
- wtetzner 7y agoThe static checkers I found that can check those annotations are very slow. Also, it's not well-integrated into the type system. Sure, you can get by with them, but it's certainly not ideal. It also requires someone to do work to set it up, instead of it just being the default.
- Kiro 7y ago> a program that queries a database, gets a specific user by ID, and prints the number of letters in that user's name to the console I'm not a Java programmer but why would you actually need all the boilerplate for this? I'm under the impression that this should be doable in any language with just two lines of code: fetch and print.
- Nursie 7y agoYeah, they don't need all that, this whole article is basically nonsense, and puts in a lot of completely unnecessary stuff.
- jariel 7y agoJava has zillions of 'not very good' or 'not empowered' developers writing in it, and the perceived safety of frameworks is valued over the ability for devs to actually write decent code. Especially in orgs for which the code/tech is a secondary issue, only seen as a risk, they'd rather higher 5 more low-cost people to deal with the framework cruft than just hire the right people for the job.
- tombert 7y agoThis is something I've been saying for years now; it honestly feels that sometimes the mantra of the language is "why write code when you can just make files?". I feel like Java makes you feel like you're accomplishing a lot, but in reality if half your code is generated by an IDE, and is impossible to understand without the help of a bunch of expensive tools, I do have to wonder how good it actually is. I'm not sure I've ever seem a Java project where I didn't shortly after think "this probably would have been better with Clojure or something". I know a lot of really smart people who absolutely love Java, so I'll admit that it's possible that I don't know what I'm talking about, but I'd like to think I'm reasonably competent at this coding thing now, and Java is routinely the worst part of my day at my current job. To make it clear, I'm not knocking the JVM. That's a pretty cool piece of tech, and enables awesome stuff like Clojure and Eta.
- Nursie 7y ago>> I'll admit that it's possible that I don't know what I'm talking about, I think a lot of people here, and probably out there in the world, have missed the direction java has taken in the last 5 years or so. I'm not saying it's definite that you don't know what you're talking about, just that perhaps the changes to more functional styles, lambdas, function passing, stream processing etc might have passed you by. It's a much more expressive language now. Or it might not, you may be bang up to date and still hold that opinion :)
- tombert 7y agoI actually do use the modern features introduced by Java 8, like Lambdas and Optionals and streams and whatnot, and while I definitely agree that they're a step in the right direction, I think most of my points still stand. The Optionals are definitely useful, but they're a far-cry from something like Scala's algebraic data types. The streams are cool, but compared to virtually any of the list-processing libraries for virtually any other JVM language, they're fairly primitive. Being able to pass functions around is great, but the lambda syntax is pretty messy in Java IMO (the weird dichotomy between Function and Supplier still confuses me occasionally). Not to mention that generics in Java are still really weird and confusing...the dichotomy between the primitives and boxed types is strange, at least in regards to generics. And even with all the improvements, we still have issues like the expression problem without much of a solution; the fact that I can't add to existing types or have something akin to a multimethod means that there ends up being a ton of wrapper classes and "extending but adding one method" classes all over the place, adding to the noise of files. If I have any choice in the matter, since my team is a JVM shop (at least on the server), I typically choose Clojure. With Clojure I get much more concise and clear code, thread safety by default, an extremely fast and interactive development process, hot code reloading, and access to literally every Java library. I will admit that occasionally I would prefer to have a good type system (which Clojure sorely lacks...typed clojure isn't great IMO), but nine times out of ten, I am pretty happy with Clojure overall. TL;DR: I should make it clear, and I realize that I didn't in my previous post, Java (the language) has improved; I definitely won't deny that. It's just not improved fast enough to address all my complaints. The language is still incredibly wordy and noisy, even with the improvements.
- SatvikBeri 7y agoI have a hard time filtering things out, and prefer text that errs on the side of being too concise where I can look things up if needed – e.g. Math textbooks or papers. A lot of people are the opposite – they have an easy time filtering and skimming, and prefer all the details to be there on one page. I think this plays a pretty big role in language choices – I find codebases in more concise languages much easier to parse & work with, but others say the same about Java/C#/etc.
- throwthisaway2 7y agoJava is about great design not minimal lines and concise logic. Java is about design patterens. Its a masters environment not a grunt workers tool.
- fredgrott 7y agono, its because concurrency is hard and most programmers fail at it...
- Barrin92 7y agoPeople in the thread have given a few different reasons why Java is verbose but in my opinion, it's not so much the language specifics or the culture but the combination of static typing together with the inheritance and class-focussed design. A lot of the terseness of other languages is the result of dynamism (Ruby, Python) and so on which basically gives you two thirds of the infamous patterns that people complain about more or less for free, and for other static languages that are predominantly functional a lot of the boilerplate simply does not exist because the primary unit of computation is the function and that spares you a hell of a lot of complication. It's the C++/Java class of languages that all suffer from the same verbosity and complexity and I don't think it's because the particular languages do anything wrong specifically but that the combination of paradigms simply leads to large, complicated structures.
- boterock 7y agoI've always felt that having "private" fields by default (thereby suggesing it is the right way to code), making all code live inside classes, and thinking everything as an object, are dogmatic assumptions that make you write a lot of boilerplate as you move forward (getters/setters, constructors, etc...) If you could write your functions out of any class, you get 3 lines an an indent level less, which I think reduces the cognitive load. you could change your private fields to be by convention instead of forced just by prefixing m_varName or whatever... I dislike java because I feel the language somehow doesn't trust the developer to know well the system he is coding. It is like handing a blunt knife to a chef expecting he doesn't know how to handle it, making his work annoying, but if he has to work for more time, he can bill more hours right?
- vkaku 7y agoYou're free to use many different languages with Java, like the new GraalVM release does. Of course, Java needs some radical improvements, but people are doing that, and I can't wait for the day where these complaints will stop. Verbosity is a personal choice too, and some people would prefer explicit configuration over convention, and that is a choice too.
- enitihas 7y agoThe examples given are full of intentionally created boilerplate. Anyone writing such production code in java has no java experience for sure. For example, the aws sdk for dynamo db contains DynamoDBMapper, which will convert dynamoDBItem to your desired class, so the entire DynamoDbUserProvider is totally unnecessary. It would simply be "dynamoDbMapper.load(key). This also removed the need for Config and DynamoDBTable classes. Also, the entire boilerplate of toString hashCode equals can be easily avoided by using Lombok. I am sure some people will consider Lombok a hacky tool, but I don't know of practical issues with it. It integrates well with IntelliJ and Eclipse, and I think most java build tools. Granted, with python you don't need a class to read from db, and can read into a dictionary, but you also won't get the niceities like auto completion if you do that, and will be much more vulnerable to typos.
- co_dh 7y agoPsql select count(email) from table where name = "foo" What the hell happened to the world.
- mrtweetyhack 7y agoWhat's wrong with boilerplate if it works?
- huherto 7y agoIt is not Java. It is how people over engineer enterprise applications. - Annotations are overused. - Design patterns are overused. - Too many layers, too many abstractions. - Using properties where a constants would be enough. - Using concurrency when you don't need it. Probably a cultural problem more than a technical.
- forinti 7y agoPrecisely! EJB used to be a nightmare (a lot easier now with annotations), but I would see people use them for web apps that had 10 users tops. It was insane.
- theandrewbailey 7y agoI barely remember how EJB used to be, though I recall that it involved a mess of XML and interfaces. Nowadays, EJB is a built-in dependency injection system. Put @Singleton on one class, then @EJB on a field in a Servlet (or what have you).
- username90 7y agoMost code shown here should be refactored from classes to a java functional style with closure capture instead of members. Then almost all the boilerplate disappears, the result is cleaner, easier to work with and the intent of every object is straightforward. Edit: Example rewrite of UsernameLetterCountPublisher as a function since I realized a lot of people here might not be familiar with Java: public static Supplier UsernameLetterCountPublisher( final Supplier<Config> configProvider, final Function<String, Config> userIdProvider, final Function<User, String> userProvider, final Function<String, User> userMessageCreator, final Consumer<String> publisher) { return () -> { final Config config = configProvider.apply(); final String id = userIdProvider.apply(config); final User user = userProvider.apply(id); final String message = userMessageCreator.apply(user); publisher.apply(message); // I didn't bother create a new interface for this so reused supplier. return null; }; }
- martincmartin 7y agoI've always wanted an IDE that would transform Java into a higher level language by "collapsing" the boiler plate. Just like we can collapse comments, I'd like to "collapse types" if I already know the types and just want to look at the logic. Or "collapse exception handling" if my current task involves changing the happy path and the exception stuff is just clutter.
- martincmartin 7y agoFor example, what if an IDE could read Java, but display it in a form that looks a lot like Kotlin? (Or Groovy, or your favourite high level language.) The file would still be Java underneath, so you don't need to convince your colleagues to adpot Kotlin. You can be in a happy Kotlin-esq world while working with their Java code, and they don't need to know or care.
- eitland 7y agoThat is actually a good idea. One idea to get it actually usable: by default it shouldn't update any code you don't touch. (Some systems will load the file into a memory structure and then save it back ignoring the existing formatting, thereby making commit logs much harder to reas if you need to.)
- greenie_beans 7y agoi hardly know java, but have to do something with the legacy system at work. does anybody have any good, canonical resources for learning java? canonical, like the pickaxe book for ruby
- eitland 7y agoEffective Java is the one I see recommended most often. I also wanted to add something I answered on a similar question in another less public forum a few days ago, but it turns out to be in another (human) language so I'll just add a summary: > 1. Java IDEs are way more sophisticated than anything else except Visual Studio with ReSharper. Learn one of them. I disliked Java strongly until someone used a couple of minutes here and there to show me navigation and editing. (Hint for people who come from editors: Java IDEs understand the difference between the same letters i.e. word in different context. If you rename a variable in one method it won't touch other things that contains the same characters elsewhere in the file.) 2. Learn Maven and/or Gradle. You know you've got it right when everything works as expected and there's next to nothing left. 3. Don't trust everyone: people in this thread mention consultant Java. I was exposed to it early and it only took a few months to realize that certain (well paid I assume) consultants knew less than me: adding log statements and rebooting application servers every time they debugged (the correct way is of course to set a breakpoint and single step.) I also cleaned up a lot of their code, including a 6000 lines of XML implementation of a crude authorization framework that they had made because they didn't get Facelets.
- greenie_beans 7y agothank you!
- whack 7y agoA lot of the boilerplate mentioned would disappear if you used a framework like lombok or autovalue. I personally prefer simple verbosity over having to learn the automagic intricacies of multiple different frameworks, but to each their own. The "90% boilerplate" in the title is highly misleading though. If you build an application that contains no business logic at all, then by definition, you're left with nothing but boilerplate. Especially if you insist on formalities like creating interfaces with only a single implementation. In real projects that I've worked on, the vast majority of the code is application specific logic, with heavy use of external libraries to get rid of any generic logic. The Java boilerplate makes up a small portion of the overall code base, and has certainly never been a deal breaker.
- TomVDB 7y agoHas anybody managed to figure out the license and/or the cost of the software that they're promoting? The website has a front page, an applications page with 1 example, and a read the article page with a numerated bullet point list (which turn out to be hyperlinks, but I only accidentally noticed that when mousing over the text.) That's it.
- mcguire 7y ago"Using UnitilyLang we could replace the previous five code sections (3006 characters plus the hidden ConfigProvider and DynamoItemReader classes we get for free in UnitilyLang) with (248 characters)." Let me emphasize that, there: "classes we get for free". "UnitilyLang is designed around abstraction, immutability and composition. It's language agnostic, that is until we have to write logic." Well, language agnostic, but apparently not domain agnostic or framework agnostic. Then, there's workflow DynamoDbUserStore = 4 . (3 (2 1)) Pointfree and nameless. Anyone have any idea what it does? Does the subsequent picture help? Anyone think you could modify what it does without a lot of unpacking? I'll leave it to someone else to figure out what's going on with the "UnitilyLang complete project". Is Java verbose? Yes. Is it possible to be less verbose, especially if you invisibly provide domain knowledge "for free"? Yep. Is it possible to be too succinct?
- tom_mellior 7y ago> Pointfree and nameless. Anyone have any idea what it does? Does the subsequent picture help? Anyone think you could modify what it does without a lot of unpacking? I don't understand why this isn't the only (or at least the highest rated) comment in this discussion. There really is nothing more to say about this article. "4. (3 (2 1))" is not a program. "We apply the second dependency to the result of the first. We then Partially apply the 3rd dependency and compose the resulting function with the 4th dependency." is not an explanation -- what is the "3rd dependency"? Dropping names to somehow implicitly number something does save keystrokes, but it doesn't make for "good code" (the claim from the article's title).
- neonate 7y agoI'm surprised no one has mentioned that this is an ad for a visual code-generating tool.
- jerojasro 7y agoI could not find any link to github/download/trials... any ideas of how can I try this language? or is this just vaporware?
- another-dave 7y agoJava has it's problems, but I think they're mostly on the implementation side (e.g. lipservice to OOP while having a load of AbstractFooHelperFactories or leaking all your inner workings through Getters and doing "Ask, Don't Tell" rather than vice versa) but I don't get why people rail against the "boilerplate" so much. It's just signposting, you can learn to look past it so soon it makes no difference. I play music and don't need the treble clef on the stave to tell me what notes to play — you could call that boilerplate and get rid of it, but I don't think it would make it easier to play or read
- mnm1 7y agoWhat OOP language doesn't suffer from this? Sure Java is infamous for it but C++, JS, PHP, Ruby, Python, etc. all suffer the same issue. The percentage might be a little less, but the amount of boilerplate is staggering in most modern OOP languages. When compared to something like Clojure, it's unbelievable. You can write entire apps in Clojure in the space that most other languages just deal with boilerplate.
- yarrel 7y agoI started programming Java in 1996. It really is a static boilerplate language. I'm wary of going too far in the direction of functional notation for the same use case though. Replacing code that is slow to read with code that is slow to expand in-head may not be the win people expect it to be.
- Glyptodon 7y ago> workflow DynamoDbUserStore > = 4 . (3 (2 1)) > workflow UsernameLetterCountPublisher > = 5 (4 (3 (2 1))) The workflow notation seems a little rough for readability even though its functional meaning fairly clear as you pretty much have to read a specific invocation of a workflow in context to confirm what's happening since the functions in a workflow could be anything and the workflow declaration is so generic. On the other hand, when you see the named picture versions it's very clear. And I can't think of anything to address my minor criticism doesn't just make the notation worse.
- he0001 7y agoI loathe the fact that you need to invent a new class Just for passing some data along or piggyback on strings whenever you do a .map(). Maybe records are going to ease that pain. But why can we just have the compiler be able to construct a container to pass along some data to the next step in the stream?
- rowland_street 7y agoI wrote this article, I'd just like to clear up my intent. Firstly the Java patterns. Obviously it's not really necessary to use them for my toy example, but I don't want to write a blog about a full scale enterprise app. I have seen multiple tech teams at different companies evolve separately towards using similar patterns in both Java and C#. Doing so solves problems in concurrency and maintainability (This is documented in the other blogs on the Unitily site https://www.unitily.com/learning.html https://www.unitily.com/learning.html). I've seen teams be very successful using them. I like Java. Im not criticising it, I'm trying to explain why people do. UnitilyLang doesn't exist, I'm not writing that language, the examples in that article are the only code snippets I've ever written (and probably ever will). The point is that there is a one to one mapping between that representation and the java code using the described patterns. This highlights the extra code you have to write in Java (and similar languages) just to support the clean code patterns. Sure if you used Kotlin or Closure (or any functional language) it becomes less of an issue, and this is exactly the point I'm trying to make. However, its rare you have the option to choose a language, so developers end up coding in Java and complaining about it. I don't like the new title the moderators have created, (perhaps the my initial one was a bit click baity) but generating code is only mentioned once in the last paragraph. The point of this article is to highlight that once you follow a set of coding principles which solve specific problems you are going to have to write extra code to do so. Perhaps something like Writing clean code in Java requires boilerplate, learn to love it. would have been a better title. The video demo at the bottom of the article generates the code from pictures not UnitilyLang. These pictures are tightly coupled to the specific coding patterns, but is (in my opinion) a more natural definition than both Java and UnitilyLang.
- purple_ducks 7y ago> I have seen multiple tech teams at different companies evolve separately towards using similar patterns in both Java and C# Could you give us some background on your professional experience? There is no "About" section on the site.
- rowland_street 7y agoI've been a professional developer for 10 years at several mid size companies. I've led teams for a large proportion of that time. Not claiming to know everything, still learning. I'm just writing up my thoughts at this time, they do change (they often cycle).
- chvid 7y agoI do a bit of work in Angular (2+) at the moment. And that involves a lot of boilerplate code; in fact so much that the framework comes with a tool (ng generate) that generates the code for you. A single component is split in 4 files and needs to be explicitly wired up in another file (the module). An empty test case is more than 20 lines of code. The point is. This is not really due to the language. Angular is written in JavaScript which under other circumstances can be a very condensed language. It is not really the language that mandates verboseness and boilerplate but the conventions, style, framework and so on. Java can be low on boilerplating and a lot more condensed; though one has to look outside the big mainstream frameworks for that.
- ka0lin 7y agoI only flew over the comments but I miss references from the past like Software through Pictures (STP, from former Aonix, riding the wave of CASE-tools) or the even older block oriented software. The latter thought of objects forming blocks that offer or consume interface and join each other through matching like LEGO. Even big companies like Rational tried their best to generate boiler plate code from UML diagrams. Also BPMN incorporated findings from the early days. But after nearly 30 years of programming experience I know one thing for sure: when it comes to real use cases beyond counting letters in a string only dedicated generators or very limited general ones continue to work. If it were the other way around there'd be product turning natural language directly into at least a single formal one. And every (Java-) programmer who still repeatedly writes down lines of code doing the same boring input-processing-output did miss at least aspect orientation, Java agents and this is the most powerful of all: ANTLR. Runs right away with your BNF-grammar from Maven or a plain JDK. But be warned, this is like any other complex craftmanship, you need to start with cleaning the workshop before you can operate the heavy machinery.
- Roboprog 7y agoI wanted to like this, but I struggled with the "s-expression with numeric atoms" dependency injection notation. How do I map the numbers back to their sources?
- iopeak 7y agoHow do I get in touch with the author of Unitily? cc @rowland_street
- rowland_street 7y agoThis twitter account will find its way through to me https://twitter.com/LLambdas https://twitter.com/LLambdas
- agsilvio 7y agoSurprised I'm not reading many comments about Lombok. We use this with great success and predictability and it removes so much boilerplate. More importantly, it focuses on the boilerplate that is truly boring. The projects look great add a result.