Hacker News new | ask | show | jobs
by rabc 5630 days ago
I agree with UML and CASE tools, it was always a time-waster that produce too many things and never used.

But I disagree with XML and OOP. XML was necessary for the first web APIs we had (they were called SOAP, in case you wasn't a developer that time). And OOP is everything you do, it's a way to write code more clear and maintainable (just forget everything about the 'reuse your code' and 'speed you development', OOP isn't just about this).

6 comments

OOP is everything you do

OOP may be everything _you_ do, but it is not everything I do, and there are large vibrant software development communities using paradigms and tools that are not particularly object-oriented. Beware of making over-generalizations like this.

"XML was necessary for the first web APIs we had"

People were building systems that had APIs exposed via HTTP a long time before XML.

And what's so special about HTTP? Communicating over the network is old - things like RPC have been around for a long time (first spec in 1976, according to Wikipedia.)
That statement isn't strictly true as raganwald pointed out but it's also too broad: the current OOP item makes a far more defensible position: "...in the sense that we are still writing lots of new OO code instead of just plugging together reusable objects to design new systems". Using OOP to cleanly contain related code and data is far more defensible than the decades of claims that programmers would just plug things together like lego bricks, which is finally dying out but has left behind a wasteland of overly-ambitious projects which will never be used by more than one project but all carry the burden of trying to be as general as Java.
"Over-hyped" doesn't mean the technology doesn't have merit. Both XML and OOP have great merit but were very much over-hyped for years as being always applicable and the ultimate answer for everything.

There were some fanciful things said in the past 15 years about both of these and others. Articles in Wired with apparently smart people bubbling with enthusiasm for the limitless potential. Even at the time I thought, fer gosh sakes, XML is an encoding. The really hard problems are still unsolved.

I still hear "we'll use XML" instead of concrete architectural plans, like it's a magic wand you wave over your project and all your dreams come true.

Saying "We'll use XML" about a software design is like saying "The building will use steel, concrete, and glass."
"We'll use JSON" is the 2.0 version I ran into during a recent project. Sigh.
UML diagrams have one redeeming quality: when they allow direct full-code generation. I always saw jaws dropping when demoing ArchGenXML for making Plone products.
Some of the stupidest code I've ever seen was auto-generated from UML. People get all excited by seeing code generated from a picture and forget to check if the code produced is actually sensible or not - in most cases I've seen the code produced is abominable.
That's what I liked with ArchGenXML. The code is quite good.

At least as good as code for Plone components can be. I heard it has improved a lot since I left Plone-land, but, when I worked with it, there was a required level of confusion in your code for it to work with all layers of Zope and Plone.

I assume UML diagrams can render very clean code for Django and Zope 3.

Before SOAP we had... XML-RPC. And before that other ways (albeit not as formalized) for over-network communication. XML did bring some ease of cross-platform exchange to the scene, no doubt, but don't give SOAP too much credit. :/