4 ms·

That is not at all a good characterization of what was going on. Do you remember what it was like before XML and Java? Could we have built anything on the scale

That is not at all a good characterization of what was going on. Do you remember what it was like before XML and Java? Could we have built anything on the scale of the web with CORBA? (XMPP would've used JSON had it existed in 1998, fwiw.)

jessaustin 11y ago
In what sense was the web built on "XML and Java"?
- dvanduzer 11y ago
  The long arc from "what came before" has periodically involved cleaning up old complexity. There have always been arguments about how simple is simple enough, but these systems weren't designed with complexity as a goal. The web is a lot of things, but broad consumer adoption of web technology also involves boring things like banks. SOAP and WSDL weren't created in a vacuum. They exist because Java / XML made it even possible to bridge the gap from the old world.
  - jessaustin 11y ago
    I don't know what "old world" you're talking about. When the web was first a thing, it was written in C and PHP and Perl. All the Java crap was layered on top later, temporarily, and unsatisfactorily. The enterprise repeatedly misunderstands what the internet is and how to use it, but that is the enterprise's problem, no one else's.
    - dvanduzer 11y ago
      Banks. As much as we like all sorts of features of the web, integrating commerce was what brought the enterprise in, drove down costs, etc etc etc.
acdha 11y ago
> Do you remember what it was like before XML and Java? Yes – in particular, I remember liking the initial promise of XML 1.0 and then being disappointed as the initial simplicity was buried under layers of gratuitous complexity as the enterprise computing crowd jumped on board. Some neat ideas (e.g. XPath) Similarly, my first database-backed web app was a Java servlet in 1996. I assumed it would become richer in the future but it was still pretty easy write and deployment was pretty simple at that point. Instead, the community chased off after more complexity (JavaBeans, the near-pervasive obsession with runtime configuration and the ensuing massive config files, nested abstraction layers, etc.) rather than focusing on basic developer productivity. We got massive piles of code like RMI (i.e. CORBA) before basic features like regular expressions, logging, etc. > Could we have built anything on the scale of the web with CORBA? No. We also failed, repeatedly, to do it with XML for reasons which are obvious to anyone who's ever used SOAP/WSDL/etc. The common theme was seeing complexity and, especially, abstraction as a universal good rather than something with real costs and forgetting how important high-quality implementations are, particularly when you're relying on them to help with all of that complexity.
- dvanduzer 11y ago
  > The common theme was seeing complexity and, especially, abstraction as a universal good rather than something with real costs Rich Hickey did a great service outlining some common problems when thinking about the word complexity itself: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy I don't think it's about the engineers wanting to see complexity, so much as the problems you mention stemming from design-by-committee.

jessaustin 11y ago

In what sense was the web built on "XML and Java"?

dvanduzer 11y ago
The long arc from "what came before" has periodically involved cleaning up old complexity. There have always been arguments about how simple is simple enough, but these systems weren't designed with complexity as a goal. The web is a lot of things, but broad consumer adoption of web technology also involves boring things like banks. SOAP and WSDL weren't created in a vacuum. They exist because Java / XML made it even possible to bridge the gap from the old world.
- jessaustin 11y ago
  I don't know what "old world" you're talking about. When the web was first a thing, it was written in C and PHP and Perl. All the Java crap was layered on top later, temporarily, and unsatisfactorily. The enterprise repeatedly misunderstands what the internet is and how to use it, but that is the enterprise's problem, no one else's.
  - dvanduzer 11y ago
    Banks. As much as we like all sorts of features of the web, integrating commerce was what brought the enterprise in, drove down costs, etc etc etc.

acdha 11y ago

> Do you remember what it was like before XML and Java? Yes – in particular, I remember liking the initial promise of XML 1.0 and then being disappointed as the initial simplicity was buried under layers of gratuitous complexity as the enterprise computing crowd jumped on board. Some neat ideas (e.g. XPath) Similarly, my first database-backed web app was a Java servlet in 1996. I assumed it would become richer in the future but it was still pretty easy write and deployment was pretty simple at that point. Instead, the community chased off after more complexity (JavaBeans, the near-pervasive obsession with runtime configuration and the ensuing massive config files, nested abstraction layers, etc.) rather than focusing on basic developer productivity. We got massive piles of code like RMI (i.e. CORBA) before basic features like regular expressions, logging, etc. > Could we have built anything on the scale of the web with CORBA? No. We also failed, repeatedly, to do it with XML for reasons which are obvious to anyone who's ever used SOAP/WSDL/etc. The common theme was seeing complexity and, especially, abstraction as a universal good rather than something with real costs and forgetting how important high-quality implementations are, particularly when you're relying on them to help with all of that complexity.

dvanduzer 11y ago
> The common theme was seeing complexity and, especially, abstraction as a universal good rather than something with real costs Rich Hickey did a great service outlining some common problems when thinking about the word complexity itself: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy I don't think it's about the engineers wanting to see complexity, so much as the problems you mention stemming from design-by-committee.