This stuff needs to die.
Via God Emperor Lionel Lauer and David Cameron Staples
Originally shared by rone
The original cartoon: http://gunshowcomic.com/471
This stuff needs to die.
Published
This stuff needs to die.
Via God Emperor Lionel Lauer and David Cameron Staples
Originally shared by rone
The original cartoon: http://gunshowcomic.com/471
John Hardy Developer 
I thought you’d appreciate this one. 😉
LikeLike
Even Java has lambda functions these days (1.8). So many nouns (classes) can be replaced by verbs (functions). steve-yegge.blogspot.com.au – Execution in the Kingdom of Nouns
LikeLike
It’s explicit typing that causes this whole thing. Just wait, as optional typing creeps into Javascript, so will this crapoo.
LikeLike
Emotional arguments aren’t really that convincing when applied to justifying or challenging logical approaches. All the mockery, filled with strawmen and bullying style talk… Bad example. It’s difficult to have sensible discussion with people who argue their favorite paradigms like this.
LikeLike
I once had a problem to solve, so I tried using Java, and I ended up with a problem factory.
LikeLike
That happens if you are better at creating problems than solutions.
LikeLike
But seriously though, how often are these levels of abstraction actually useful in real life, as opposed to Comp Sci programming exercises?
LikeLike
If you can’t use a tool, you blame the tool. A developer can choose the right tool and can also work with any given tool within given constraints without blinking an eye.
LikeLike
Sakari Maaranen That doesn’t mean there aren’t better and worse abstractions. ie: if you can choose the tool, don’t choose the bad ones.
Programming languages accrue cultures (sometimes more than one). I think the cultures are mostly determined by the features / grain of the languages, but maybe not entirely.
eg: if Java were invented today, would pattern madness be the signature of its culture, the way it is now? Maybe not: I don’t think C# suffers the same sickness, even though it’s a very similar language.
LikeLike
Sakari Maaranen never assume people can’t use a tool when you hear them criticise it. I’ve been programming with Java for over 20 long years.
There are however better ways and these are only now seeping into Java but have been discussed and used in other circles for over 50 years.
LikeLike
Ramin Honary that one reminds me of this one softwareengineering.stackexchange.com – What is meant by “Now you have two problems”?
LikeLike
John Hardy not a Turnbull fan yeah, that’s another good one! Although to be honest, I use regular expressions almost daily and they usually don’t cause me any problems. (I’m one of those guys who does everything with the command line).
LikeLike
Ramin Honary I’m a big fan of regular expressions too, but I’m also good at knowing when not to use them. 😉
LikeLike
John Hardy not a Turnbull fan so have I, since the first release. And I know all the other paradigms as well. Been programming since I was eight. But this is not a pissing contest, at least not to me.
LikeLike
Java, patterns, etc. sometimes remind me of https://en.wikipedia.org/wiki/Obsessive%E2%80%93compulsive_personality_disorder 😉
LikeLike
It’s more about mathematics Jürgen Christoffel, less about psychology.
LikeLike
Sakari Maaranen I tend to disagree. It’s more about the difference between the real world and some abstract concepts, which sometimes but not always model reality close enough. When I first learned Pascal (a rather long time ago) I wondered why a string had only 255 chars. When I first started with web forms (also a long time ago) I learned that some forms refused to accept e.g. “1234 ” as a valid number. Why? Because certain programmers (or libraries) adhered too much to their programming language’s concepts. Abstraction is fine and useful on a certain level. But, as the comic shows, it should not expose itself to the end user.
LikeLike
Jürgen Christoffel abstraction when used correctly, is about encapsulation of implementation specific unnecessary complexity, exposing a more refined and simpler service to the user. This pertains to all well designed protocol stacks as well as well architected application layers. It’s beginning to sound like you don’t know what you’re talking about.
LikeLike
Of course abstraction can be done wrong, but you can’t blame abstraction itself for the mistakes of people who can’t use it right.
LikeLike
Well it sounds like a pissing competition when you assume that people don’t know what they are talking about. Most of us here were taught how to program using Object Oriented paradigms.
It has become painfully obvious to me over the years of using them that most of the so-called abstraction of modern OO is actually worthless ceremony that can be largely eliminated in a better programming language. Furthermore Alan Kay himself would scarcely recognise languages such as Java as being Object Oriented.
LikeLike
The key abstraction that OO gets wrong is the subordination of the function to the object which means that all tasks need to be attached to classes of data. This gives you one useful trick, late binding of methods through polymorphism. Sometimes that’s a good trick. There are also other ways to do it.
The truly bad stuff starts when you start building class hierarchies and heavily use inheritance. The privileged access that methods have over object state generally leads to bad things and brittle code.
LikeLike
John Hardy not a Turnbull fan that is a problem with overuse of inheritance hierarchies. Any constructive language feature can be overused. You can always create too large constructs that become unmaintainable.
But you need a namespace where to keep your functions anyway. Might as well use objects for that (in a language that is based on them), but you don’t have to bind them to the data objects. For example, in JPA the basic database operations are provided by the EntityManager and the data objects are separate entities that only contain direct manipulation of their member variables. You add more refined business logic in a service layer that then uses a managed EntityManager instance to maintain the data objects’ state in the persistence context that can be any compatible database solution. Java is verbose, but when you use the abstractions properly they provide value by keeping your code organized and maintainable.
The most problems I have seen with Java are people not understanding how to use the myriad already existing Java EE features – or not aware of their existence – therefore reinventing stuff, then trying to integrate their reinvented wheels with standard Java features. This creates a hodgepodge of proper architecture with custom quirks done by various people at various times.
I give you that Java does make you write more code in many cases, but my IDE does plenty of that for me, and in fully fledged business solutions, when you actually need many of the enterprise stack services, it can save you a lot of work. I wouldn’t use enterprise Java for sorting a list of integers or generally for almost any small job, but if you want to create a transactional business application with a selection of APIs, web UIs, and integrations to legacy systems and databases, then Java is a solid contender with plenty of developer resources and commercial support readily available.
LikeLike
Java is a language I used to like but it was ruined in my opinion by the billion APIs Sun threw on top of it. Many of them really poorly designed and even more poorly maintained.
The reality though is that I don’t use the language much anymore once I started using scripting languages initially just to glue bits of the Java machine together and later to do the actual system in, I’ve never really looked back.
Java is safety theatre most of the time. The exception system is constantly abused by programmers (catching nothing most of the time). But even here there are improvements because they finally allowed first class functions and closures. They’re really inner classes but never mind, this allows code that in the Java world usually needs wrapping in a dozen classes and factories to be exposed to their problem domain directly! I expect it will take Java programmers a long time to discover the power of this but at least it’s been done. I believe it was a proposal that took nearly a decade to implement.
LikeLike
I’ve talked about this before, but I really think OOP is inseparable from graphical user interfaces. I’ve been writing a reactive programming reactive wrapper around Gtk+ in Haskell, and all my code ends up looking like OOP, even in Haskell. Once I get the wrapper done I should hopefully just be able to write the functional reactive code and be done with OOP.
But low-level GUIs are like the only place where OOP class hierarchies seem to make any sense at all.
Object -> Container -> Layout;
Object -> Container -> Widget -> Push Button;
It just seems a natural way to organize data and associated code into structures that model GUI elements.
I suppose back in the early 90s when it really came into vogue, everyone had come to think you could do all computing with GUIs, so maybe as a consequence, everyone assumed you could do all programming with OOP.
And Java is still pretty much stuck in that era. It survives nowadays by being what COBOL used to be: the defacto standard of big business logic. But COBOL was ousted eventually, I’m afraid Java will be too (afraid because my job depends on it). It’s really just a question of when.
Java as a technology is still excellent, in my opinion. The JIT and garbage collector never cease to amaze me with how efficient it can be. But even it’s use as a virtual machine is starting to be supplanted by inexpensive Linux virtualization tools like Docker, VMWare, and Amazon Elastic Cloud.
LikeLike
Basically you’re saying it works best with message passing architectures like the kind that Smalltalk was designed to implement. I wonder though whether even that has changed now that UIs are moving toward Redux.
LikeLike