191–200 of 259 posts
There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess th…
true
Earlier quoted context omitted.
Everything is wired up using Dependency Injection. So you just state your claims and are given appropriate objects that may be created by some third party factory factory. It's really neat until it isnt.
It's there an unspoken rule about how much dependency injection is too much dependency injection? Like I can see how it could get bad, but how do you know when you've gone too far?
I've not used it since because the project I inherited suffered extremely from nih syndrome.
Earlier quoted context omitted.
Enterprise apps are super complex, frequently a lot more complex than startup apps. Someone basically comes with 1 thick tome worth of business knowledge plus 1 thick tome worth of legal restrictions and you're supposed to codify all of that, to the letter, in software. Some of the business logic can make you cry. Software dev: "But that's not clean/elegant". Business owner: "Reality doesn't care about elegant/clean,…
I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise. I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platform…
The tax reporting system I get bogged down and mired in the literal thousands of edge cases and exceptions due to the interactions of all of the laws, sometimes written maliciously by some political entity, or sometimes some local municipality goes against the federal laws leading to literally impossible scenarios. On top of that you have things like your company booking transactions one way that they shouldn't have and is now too much of a pain to change so it has to get reported differently at the reporting layer (which itself is a problem as to why this wasn't noticed initially). Very often the gov't specs themselves are contradictory.
Here is an example: stocks can sometimes pay debt interest did you know?! That doesn't come up in any of the fixed income documentation I had to read. But right there in some list of bonds the IRS publishes every year are non-bond things. wtf?! So do you fabricate some new type "debt interest paying thing" of which are mostly composed of bonds and once in a while stocks in your data model? Do you keep your data model clean and fabricate an internal bond to represent the debt part of the stock in these cases and link it to the actual stock? You will have to consult with your legal/tax department and realize if you were to misreport this income what would the resultant fines and loss of customer goodwill is (due to higher chance of them being audited, paying more tax etc)? Do you conclude that your internal team cannot keep up with the ever marching and changing tax law (FATCA anyone wtf?!) and outsource this to a tax reporting company? The scope of our tax reporting is nearly unlimited since the US government seeks to capture all of human endeavor. The results of getting this wrong are very real. People get audited and lose money and sue our company and can go under due to litigation costs. In games, if we fuck up, our company goes under and everyone loses their job but I didn't have to worry so much about potentially ruining the jobs of people outside of our company.
This is actual complexity your software will have to deal with no matter your language/platform.
In my, admittedly limited (never AAA), experience with games I always seemed to be bumping up against physics (time, memory, latency/speed of light) but with enterprise apps it's almost always bumping up against the sum total of human stupidity past and present.
Earlier quoted context omitted.
As someone who loves Python/Django, dabbled in Ruby/Rails, learned a multitude of front-end JS frameworks (Backbone, React, AngularJS, and Ember), and currently works with Java in an enterprise environment, I just want to add two points: - If you're going to have config/setup files, make sure they utilize a language that is Turing Complete. YAML looks pretty, but for all practical purposes, is it really better than X…
XML is not any more or less "turing complete" than yaml, is it? They both express static data structures. I suppose you can make turing complete languages that use the syntax of either one (XSLT is one; i'm sure there are others in YAML), although it gets pretty iffy.
Also, trying to shoehorn conditions and loops into a non-Turing Complete language is cumbersome. I would imagine it being a nightmare for platform and framework maintainers, as well. Rather than create a config or dependency DSL for every platform, why not just put the language to work for you?
Earlier quoted context omitted.
Types almost never save the day and they don't add much to the understanding. The code should be structured and documented in such a way that you are able to understand it, reason about it and swap implementations of stuff in the places where such flexibility is handy. E.g. in Clojure, I can trivially test my functions in the context of the application using the REPL. I don't have to reload anything, I do it right in…
> Types almost never save the day and they don't add much to the understanding. There’s a saying in strongly typed languages “make illegal states unrepresentable”. Java doesn’t let you get all the way there but it’s better than nothing. When you look at strongly typed languages with a good type system, often when you compile it just works. Besides hello world, I’ve never written program beyond a few lines that has ju…
Earlier quoted context omitted.
This is absolutely not the case. Enterprise app developers (etc.) are not stupid. The domain and the business problem are often extremely complex and hard to understand.
My observation from my long career of writing enterprise apps is that frameworks are super complicated with many hidden variables, so when you apply them to a complicated business problem you end up with the square of the complications of both systems. We ended up in framework hell. In response, we ditched all the frameworks we were using, went to pure JavaSE, and ended up with a (much!) faster, more reliable enterpr…
Our JEE apps were deployed to these app servers with very little internal support or expertise that very often had devs having to physically log onto production hosts and figure what in the world was wrong, restarting the app server, grepping logs and in general having to learn about these app servers (and usually just shrugging their shoulders at what went wrong). The sum total of things you had to know to keep the JEE deployments up was as much as you had to know about Nix processes PLUS you still had to know all the Nix stuff, except none of the JEE infra was built out since the app servers were just these monstrous processes with hundreds of db connections and thousands of threads.
My team long ago ditched JEE style deployments and have our apps all managed with the batch processing system and have been none of the better for it. Some* of those apps use Spring/Boot but I we've been doing a decent job in the code reviews of just rejecting anything too auto-magikal. Other teams that have stuck with these massive app-servers have stagnated since the deployments are so frail, no one dares make large changes. This is mostly an institutional problem but still the end result was sticking to simpler JavaSE stuff has led to way more productivity.
Earlier quoted context omitted.
Enterprise apps are super complex, frequently a lot more complex than startup apps. Someone basically comes with 1 thick tome worth of business knowledge plus 1 thick tome worth of legal restrictions and you're supposed to codify all of that, to the letter, in software. Some of the business logic can make you cry. Software dev: "But that's not clean/elegant". Business owner: "Reality doesn't care about elegant/clean,…
I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise. I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platform…
What does modern mean in this context?
Probably relative to things like J2EE as mentioned in the beginning, and as mentioned toward this middle: > Non-blocking / reactive is one of the central demarcating elements of “modern” vs traditional.
Earlier quoted context omitted.
Please don't use Reactive in Java. Stick to plain imperative - and you'll be compatible with Project Loom in the future.
I don't see how using Reactive makes you incompatible with Project Loom.
Earlier quoted context omitted.
Maybe the author isn't a fan of explicit pointers? Because yeah, though it's obviously c-like (as is Java), I can't think of anything else one might consider archaic that isn't also in the java language or virtual machine.
There are sooo many nice language features that have proven themselves over the last 3-4 decades and have become popular but are missing from Go that I think archaic is appropriate.
Go is what I'd call minimalist. COBOL or fortran are what I'd call archaic.