TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The Rise and Fall of CORBA (2006)

85 pointsby rdpintqogeogsaaalmost 2 years ago

34 comments

tragomaskhalosalmost 2 years ago
The old adage: &quot;the first rule of distributed objects: don&#x27;t distribute your objects&quot;. DCOM and EJB also came unstuck by failing to observe this rule.<p>It&#x27;s impossible for young&#x27;uns to appreciate just how obsessed the software world was by &#x27;objects&#x27;, OO and the chimera of reusability in those days; I subscribed to &#x27;Object&#x27; magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. The fact that such blatant silliness actually met with knowing nods gives the insight into how technologies that promised to wire this brave new world together became hot properties almost regardless of their details.<p>It is telling that J2EE became at least mildly sane when people started ignoring entity beans and working exclusively with session beans, inching towards the realisation that the api was the thing that needed to be remote. Imo the current status quo with REST (in its usual bastardised guise) and json as the language neutral representation, alongside aids like Json schema and OpenApi, while by no means perfect, are workable enough and certainly light years ahead of these earlier fumbling efforts.
评论 #36550849 未加载
评论 #36547674 未加载
评论 #36549755 未加载
评论 #36547680 未加载
评论 #36547555 未加载
评论 #36548919 未加载
评论 #36547584 未加载
评论 #36547545 未加载
评论 #36553558 未加载
评论 #36551831 未加载
lelanthranalmost 2 years ago
I remember how CORBA was all going to be the future.<p>I wrote dozens of programs in C++ and Python using IDL.<p>Funny, though, that we now find ourselves doing the exact same thing but it is &quot;an API&quot;, has no type-checking, no error handling, requires more work, is limited to particular languages and is slower.<p>Distributed objects were ahead of their time by maybe 15 years. Now we&#x27;re stuck in async API-over-JSON hell forever.
评论 #36547544 未加载
评论 #36547402 未加载
评论 #36549884 未加载
评论 #36563132 未加载
评论 #36550483 未加载
评论 #36547498 未加载
评论 #36547650 未加载
derrizalmost 2 years ago
The article doesn&#x27;t spend enough time on the fact that actual _interoperability_ didn&#x27;t actually come to CORBA until it was already past its peak. So a key feature of the technology never really worked.<p>I worked at a CORBA vender for a year or two in the 1990s and even interoperability between languages, platforms and versions OF OUR OWN CORBA implementation was barely supported and down to luck more than anything else.<p>Note that CORBA existed as a spec for years before actually specifying an actual wire protocol (IIOP) which you&#x27;d imagine would be a fairly fundamental part of any distributed tech which had the goal of offering interoperability. And even years after IIOP appeared, getting CORBA to work between vendors&#x27; products was basically impossible.<p>&quot;Interoperability&quot; in effect meant buying 100% into a single vendor&#x27;s offering and paying a load of money to consultants to manage version upgrades, getting fixes for &quot;niche&quot; platforms, etc. CORBA&#x27;s notion of &quot;interoperability&quot; was more along the lines of the way old IBM offered &quot;interoperability&quot; between their different mainframes and minis, and not in the way understood today which is vendor neutral and open.<p>Another poster says that IONA (one of the biggest vendors) believed that they were going to topple Microsoft. In my opinion, it was actually IBM and the old &quot;big vendor&quot; model where they saw their future. They started offering (mostly broken) Transaction Managers, Service Discover agents, a Message Broker, etc. - as what they hoped would be alternatives to the then dominant big-enterprise tech like CICS&#x2F;MQ. They imagined a future for big enterprises based around C++&#x2F;CORBA replacing COBOL&#x2F;CICS&#x2F;MQ.
bhaakalmost 2 years ago
I have some sketchy memories for which I have trouble filling in the blanks about an internship at a bank where I wrote a Java POC for getting data from one of the other departments.<p>It must have been in 1998 or in 1999 and I was brought in to solve a specific problem, only to find out that the higher ups had no idea that there was a problem and there was no documentation. Eventually I wrote a specification and that POC.<p>While doing that, I learned that the Java CORBA implementation they used at that time was not yet able to talk to the C++ CORBA implementation from the same software producer. How is that even possible? That&#x27;s the whole raison d&#x27;être of CORBA.<p>As I said I can&#x27;t get the details together. I&#x27;m pretty sure the hardware was Sun but I&#x27;m not sure who made the CORBA implementations. Possibly IBM? It would fit the landscape.
js2almost 2 years ago
The Wikipedia page says the most recent version of the standard is 3.4, published in 2021:<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Common_Object_Request_Broker_Architecture" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Common_Object_Request_Broker_A...</a><p>In my 25+ year career I haven&#x27;t seen it in use anywhere. I only ever encountered it while getting my CS degree.
评论 #36547391 未加载
评论 #36547381 未加载
评论 #36549857 未加载
评论 #36547559 未加载
评论 #36547546 未加载
评论 #36553703 未加载
评论 #36547450 未加载
评论 #36547408 未加载
AlbertCoryalmost 2 years ago
&gt; SOAP had serious technical shortcomings, but, as a market strategy, it was a masterstroke.<p>Wrong. SOAP descended quickly into the &quot;whatever happened to&quot; category. Like CORBA. I&#x27;m happy to say I threw out SOAP and used REST instead at Google, in practically my first act there:<p><a href="https:&#x2F;&#x2F;albertcory50.substack.com&#x2F;p&#x2F;working-at-google-enterprise" rel="nofollow noreferrer">https:&#x2F;&#x2F;albertcory50.substack.com&#x2F;p&#x2F;working-at-google-enterp...</a><p>The Internet had no time for multi-company, political garbage like SOAP and CORBA.
评论 #36551628 未加载
Animatsalmost 2 years ago
We might see a comeback of something like CORBA. One of the things CORBA was supposed to do was to enable a mechanism to ask a server &quot;How do I talk to you&quot;? While that wasn&#x27;t really used much, it has real potential for the LLM era. We need technologies where a client asks the server how to talk to it, then generates the appropriate requests automatically.<p>For example, you should be able to ask anything with a shopping cart how to buy stuff. Especially for B2B E-commerce.
评论 #36549266 未加载
spaintechalmost 2 years ago
My first exposure to CORBA was 1996&#x2F;97 where it was used to deploy a major distributed infrastructure. It worked quite well to manage and integrate this large scale deployment, some of it expanded beyond just one datacenter, so it was nice to have a really good control system to manage thousands of services across such a large estate with minimal user intervention. Applications were patch and upgraded through the CORBA services and we scaled the system to provide national and international infrastructure services. I would wager <i>nearly 20 years since I had insight into how that infrastructure worked</i> that this is still running… Obvious use case is telcos.
longemen3000almost 2 years ago
CORBA is used in the chemical industry (CAPE-OPEN standard) <a href="https:&#x2F;&#x2F;www.colan.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.colan.org&#x2F;</a>
michaelteteralmost 2 years ago
There have been many Silver Bullets in software development, and they probably all had some real value. But it seems they get latched onto and over-hyped, particularly for decision makers and funders.<p>In reality, what is probably most missing is consistent effort toward better organization and complexity management of problems (leading to effective solutions).<p>Without naming current 2-letter hype trains, we&#x27;re doing it again after the blockchain stuff finally fizzled. Blockchain didn&#x27;t magically solve our organizational and complexity problems, and so we need a new great hope.<p>New tech and patterns are exciting (probably mostly because of the promise of making our lives easier), but eventually one stops accepting them with big expectations. Ultimately it seems like instead of addressing the real difficulty in our technical solution development we create new distractions and use them to hide ourselves from the bigger problem that we can&#x27;t seem to deal with.
MichiHenningalmost 2 years ago
We still don&#x27;t have anything in common use that can do what CORBA could do. gRPC doesn&#x27;t even come close.<p>If you are interested in this type of technology, I recommend looking at ZeroC&#x27;s Ice. <a href="https:&#x2F;&#x2F;zeroc.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;zeroc.com</a><p>It&#x27;s CORBA with all the warts removed, and a lot of other useful stuff added.
评论 #36556853 未加载
hackandthinkalmost 2 years ago
&quot;In the early ’90s, persuading programs on different machines to talk to each other was a nightmare ... (Other early middleware, such as Sun ONC... was tied to C and Unix and not suitable for heterogeneous environments.)&quot;<p>I disagree here. SUN RPCs (ONC) based on XDR worked well and were quite enjoyable to use.<p>CORBA was victim of the Second-system effect.<p>And CORBA meant C++ in the early 90ies. Memory management was a nightmare, C++ and CORBA Apis don&#x27;t go well together.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Sun_RPC" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Sun_RPC</a> <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;External_Data_Representation" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;External_Data_Representation</a>
b800halmost 2 years ago
I was about to opine that this title was an homage to the 2009 GI Joe movie, but then I realised it had been written prior to the film&#x27;s release. I can only assume that in actual fact, &quot;GI Joe: The rise of COBRA&quot; was in fact an homage to this article.
评论 #36547633 未加载
评论 #36551236 未加载
bwanabalmost 2 years ago
It is being overlooked that one of the big impediments to CORBA was the literal cost of license from the vendors. They all wanted to make big bucks. It kind of reminds me of the early days of LISP and smalltalk. Venders were more interested in cashing in than spreading the technology. To be sure, for a big company it wasn&#x27;t that huge, but when the Dot-com boom went bust and company&#x27;s were trying to find ways to save money, that was a big flag on the expense sheet given that alternatives were becoming available.
评论 #36554773 未加载
nabla9almost 2 years ago
Marc Andreessen was all about CORBA. James Gosling said that JVM (Java Virtual Machine) was more important than Java itself. Remember EJB.<p>In the end it did not matter if the technology was good or bad. Microsoft effortlessly killed everything that was not theirs to control.<p>Now we have n:th iteration, more simple with less ambition. WASM, HTTPS, REST, json...
评论 #36547660 未加载
Simon_O_Rourkealmost 2 years ago
My father&#x27;s business partner was one of the founders of Iona Technologies, the makers of the Orbix Corba Request Broker. Back in the mid 1990s they had visions of being bigger than Microsoft, but events and progress overtook them, and the company was sold for a pittance in the mid 2000s.
garganzolalmost 2 years ago
I still use CORBA with huge success. For example, it is a backbone of several commercial systems that connect vending units in different regions and even countries.<p>For what it&#x27;s worth, CORBA is hard to use from languages without a proper reflection. But with something like Java or .NET - it&#x27;s a breeze.<p>And before you start asking questions why - no, REST or gRPC do not cut it. They are too primitive and come with poorly defined semantics. Their HTTP&#x2F;1.1 transport is rudimental, though HTTP&#x2F;2.0 made it better by allowing multiplex streams with an elusive possibility of a proper bidirectional communication. But CORBA already had all that, and more, since 2005! And I use it to the fullest extent in the distributed systems my company designs.
评论 #36552298 未加载
评论 #36550027 未加载
mannyvalmost 2 years ago
I worked with what was arguably the first large-scale CORBA product (IBM&#x2F;Tivoli&#x27;s TME10 product).<p>The main problem with COBRA was speed. At the time, authentication was brutally slow...and there was a separate problem with figuring out which object was canonical.<p>OTOH, being able to patch&#x2F;override any function with any language was pretty handy. Of course, that because a configuration and operational nightmare, because custom configured overrides would get wiped out when upgrades happened. And it made it difficult for support to figure anything out, since many places were heavily customized by consultants.<p>It&#x27;s an interesting idea that foundered on the technological limitations of the era, like OpenDoc, Telescript, etc.
hinkleyalmost 2 years ago
I interviewed with AT&amp;T for a job and the interviewer was sure a piece of concurrent code was sound and I was sure it was not, but couldn’t articulate it at the end of a long day.<p>I would have been working in CORBA when it was already on its way out. Silver lining that was a bullet I dodged entirely, except of course having the pay the opportunity cost all early Java devs paid because there was an ORB in the JDK for ten+ years.
评论 #36551373 未加载
pachicoalmost 2 years ago
Damn dyslexia, I was expecting an article about G.I. Joe...
评论 #36551102 未加载
srhtftwalmost 2 years ago
I played with various orbs on and off for many years. The only system I ever found that somewhat worked was VNC which used omniORB. However VNC is mainly about remote frame buffers so I think it&#x27;s fair to say VNC achieved a modicum of success in spite of using CORBA.
MichiHenningalmost 2 years ago
BTW, a more readable and better formatted version of the article is here:<p><a href="http:&#x2F;&#x2F;www.triodia.com&#x2F;staff&#x2F;michi&#x2F;queue&#x2F;queue_doc2.html" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.triodia.com&#x2F;staff&#x2F;michi&#x2F;queue&#x2F;queue_doc2.html</a>
amatwlalmost 2 years ago
I literally worked on a project two years ago that was still using CORBA. Oof.
评论 #36550877 未加载
评论 #36549669 未加载
projectileboyalmost 2 years ago
The biggest problem I ran into was that ORBs from different manufacturers just didn’t play nice with one another. And then SOAP and Enterprise Service Bus repeated the whole damn thing.
nologic01almost 2 years ago
I am pretty sure ten years from now people will be rolling their eyes on the acronyms of today: so-called REST, json schema and whatnot.<p>Lets face it, the problem that people try to solve (frictionless, large scale exchange of complex information between computing devices) and the conditions in which they try to solve it (as part of a few dominating corporations with random business models) are making for a very difficult challenge.<p>There <i>is</i> pressure to find workable solutions as the benefits are tremendus but so far it has not worked.
davidwalmost 2 years ago
CORBA is one of the first technologies that I came across and saw that it was kind of &#x27;hot&#x27;, but decided I&#x27;d learn it if I ended up really needing it. And I never did.<p>It&#x27;s important to learn when to ignore things in this field. It&#x27;s never possible to be 100% sure, but there are always going to be &#x27;new! hot!&#x27; things.
MollyRealizedalmost 2 years ago
I honestly thought what most contributed to their fall was that &quot;Corba-la-la-la-la-la!&quot; thing while they attacked.<p>(sorry)
Nihilartikelalmost 2 years ago
Just this headline is triggering repressed memories of building a component in a simulation federation for a defense subcontractor in the early 2000s on an awful realtime CORBA system.<p>My first grey hairs started popping out during that project.
weaponeeralmost 2 years ago
The best described and documented useless thing ever, perhaps excepting PHIGS...
评论 #36553729 未加载
NelsonMinaralmost 2 years ago
And been replaced with a zillion microservices with gRPC interfaces. Not sure that&#x27;s an improvement.
corba_v2almost 2 years ago
platforms like Cadence and temporal reminds me of CORBA - basically when you think about it, they are CORBA or EJBs just in a new flavor.
DonHopkinsalmost 2 years ago
COM vs SOM: The Component Object Model and Some Other Model (1999) (archive.org) DonHopkins on June 24, 2019 | hide | past | favorite | 22 comments<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20266450">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20266450</a><p><a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;19990127184653&#x2F;http:&#x2F;&#x2F;www.develop.com&#x2F;dbox&#x2F;COM_vs_SOM_Summ.htm" rel="nofollow noreferrer">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;19990127184653&#x2F;http:&#x2F;&#x2F;www.develo...</a><p>Also:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34127174">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=34127174</a><p>DonHopkins 6 months ago | parent | context | favorite | on: The Dawn and Dusk of Sun Microsystems [video]<p>&gt;Sun started to turn into DEC when the manufacturing people started getting hired from DEC into Sun.<p>That is precisely what happened. Sun also hired a whole bunch of frat boy brogrammers and incompetent bozogrammers from HP and AT&amp;T, too.<p>I have a lot of respect for the old HP and DEC, but the charlatans that Sun hired from HP and DEC who perpetrated Project DOE (Distributed Object Everywhere) and CORBA were a completely incompetent turkey farm who sabotaged Sun and dragged it into the ground.<p><a href="https:&#x2F;&#x2F;techmonitor.ai&#x2F;technology&#x2F;sunsoft_taps_object_design_to_do_persistent_engine_for_project_doe" rel="nofollow noreferrer">https:&#x2F;&#x2F;techmonitor.ai&#x2F;technology&#x2F;sunsoft_taps_object_design...</a><p>We used to call it Project DOPE (Distributed Object Practically Everywhere), and the OMG (Object Management Group) was better described as OMFG, then it took so long to ship NEO that they should have called it NEOLD.<p><a href="https:&#x2F;&#x2F;gunkies.org&#x2F;wiki&#x2F;Solaris" rel="nofollow noreferrer">https:&#x2F;&#x2F;gunkies.org&#x2F;wiki&#x2F;Solaris</a><p>&gt;SunSoft is delivering the first component against its vision of Project DOE. In February 1991, SunSoft and Hewlett-Packard (HP) developed the industry&#x27;s first Distributed Object Management Facility (Distributed OMF). This was submitted to the Object Management Group (OMG). In June, SunSoft added to its object technology foundation with the introduction of ToolTalk. The product has been endorsed by a number of leading software vendors including Lotus Development Corp., Cadence, Valid and Clarity Software. Other elements of Project DOE will be introduced later this year.<p><a href="http:&#x2F;&#x2F;sunsite.uakom.sk&#x2F;sunworldonline&#x2F;swol-10-1995&#x2F;swol-10-doe.html" rel="nofollow noreferrer">http:&#x2F;&#x2F;sunsite.uakom.sk&#x2F;sunworldonline&#x2F;swol-10-1995&#x2F;swol-10-...</a><p>&gt;New York City -- Perhaps the only vaporware touted for a longer period of time before its release than Windows 95 was Sun&#x27;s Project DOE. This ambitious object-oriented programming toolkit and distributed operating environment that offers built-in network awareness has arrived at last. The company chose a hastily planned morning press event during Unix Expo to offer details on the software Sun&#x27;s talked about for almost five years.<p>&gt;The software and programs making up Project DOE (Distributed Objects Everywhere) are now under the umbrella term &quot;Neo,&quot; a word Sun CEO Scott McNealy joked doesn&#x27;t stand for anything in particular except it being the last three-letter word not trademarked in the US. (Apparently, the second to the last was &quot;JOE,&quot; a term Sun picked up for its Java application development tools.)<p>Then once Java became popular, Sun was overrun by enormous hoards of minions jumping on the Java bandwagon, who just wanted to work effortlessly for a successful company instead of working hard to make a company successful (just as JWZ observed about Netscape, too).<p>McNealy&#x27;s worst enemies weren&#x27;t at Microsoft, they were only himself and the other useless idiots he hired after selling out to AT&amp;T, letting all those DOEZOS on the bus, and rolling out the Java Juggernaut.<p>The only misguided lesson Scott McNealy learned from his tragic failure driving Sun into the ground was to put all his wood behind one arrow of Putin&#x27;s useful idiot Trump, instead of so many useless idiots from AT&amp;T, DEC, and HP.<p>I wrote:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22460313">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22460313</a><p>DonHopkins on March 1, 2020 | parent | context | favorite | on: Sun&#x27;s NeWS was a mistake, as are all toolkit-in-se...<p>Yes you&#x27;re definitely in the ball park with a beer and a hot dog -- there was a huge amount of corporate baggage. The hype and corporate bullshit that surrounded Java is a good example of what that corporate baggage would have been like if it had been deployed for NeWS&#x27;s benefit instead of Java&#x27;s.<p>If Sun had put as much energy into promoting and supporting NeWS as they did with Java, we would probably live in a very different world today.<p>Sun turned a corner when they abandoned their Berkeley hippie BSD roots and got into bed with AT&amp;T &#x2F; SVR4 &#x2F; Solaris, and that changed a lot of stuff for the worse, making it a lot harder to do things like give away the source code to X11&#x2F;NeWS. A lot of people from different companies who used to be Sun&#x27;s enemies, and who had extremely different philosophies and antithetical approaches to &quot;open software&quot;, joined Sun and started influencing and managing its policies and projects. A disastrous example was the Distributed Objects Everywhere project and CORBA fiasco, which was originally the crazy idea of a bunch of people from HP and DEC, Sun&#x27;s former nemesis&#x27;s, who then came to Sun and started pushing it into everything, to the detriment of NeWS and other older projects at Sun. Some of the problematic people and armchair architectural astronauts that Sun imported and put in charge of DOE&#x2F;CORBA, like Steve MacKay and Michael Powell, were worthless corporate bullshitters whose main goals were to establish and maintain a hegemony, and they kept their grandiose plans in their head and never wrote anything down or made any hard decisions or came up with anything concrete, because they didn&#x27;t want to be pinned down to committing to something, when they were actually in way over their heads. The whole point of the incredibly complex software they finally developed was interoperability with other company&#x27;s compatible software, but in reality none of it actually worked together. It only talked to itself. SLOWLY.<p>Since DOE was intended to run everywhere and talk to everything but actually didn&#x27;t, they should have called DOPE for Distributed Objects Practically Everywhere.<p>DOPE was a complete failure at its stated mission, and it had ridiculously costly overhead and complexity. When they finally delivered something years behind schedule and lacking crucial promised features, it actually required TWO CDROMs to install. (You&#x27;d think they could have distributed a distributed network object system over the network, instead of via CDROM, but nooooo: it was just too big to download.) And in the end, nobody actually used &quot;DOE&quot; or &quot;NEO&quot; for anything consequential. They wasted a spectacular amount of time, energy, money, careers, and good will on that crap.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Distributed_Objects_Everywhere" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Distributed_Objects_Everywhere</a><p><a href="https:&#x2F;&#x2F;www.javaworld.com&#x2F;article&#x2F;2077168&#x2F;distributed-object-computing-with-joe-and-neo.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.javaworld.com&#x2F;article&#x2F;2077168&#x2F;distributed-object...</a><p>And then when Java finally came along, the same meddlesome corporate baggage handlers and armchair architectural astronauts went into overdrive to evangelize and promote the Java Juggernaut. And even more of them flocked in droves to Sun to jump on the Java bandwagon. If it was bad after the invasion of System V &#x2F; AT&amp;T &#x2F; HP &#x2F; DEC minions, things got much worse once the Java zombies started arriving in teaming brain-eating hoards to get their part of the action in response to all the hype. The original Java team was brilliant, and there were some extremely excellent people working on it, but they were totally outnumbered by the dead weight of all the hangers-on who didn&#x27;t want to work hard to make a struggling company great, but just wanted an easy job at a secure company that was already great.<p>If Sun had shown the commitment and dedicated the resources to NeWS that they did to DOE and Java, things would be a lot different. And it would have probably also turned out terribly, for all the same reasons.<p>JWZ said the same kind of thing happened at NetScape, too.<p><a href="https:&#x2F;&#x2F;tech.slashdot.org&#x2F;story&#x2F;05&#x2F;03&#x2F;10&#x2F;146234&#x2F;mozilla-foundation-in-more-development-trouble?sdsrc=next" rel="nofollow noreferrer">https:&#x2F;&#x2F;tech.slashdot.org&#x2F;story&#x2F;05&#x2F;03&#x2F;10&#x2F;146234&#x2F;mozilla-foun...</a><p>&gt;This is starting to sound familiar (Score:4, Interesting) by gothzilla ( 676407 ) on Thursday March 10, 2005 @11:10AM (#11899790)<p>&gt;I remember reading JWZ&#x27;s blog back in the Netscape days. I remember one entry in particular where he noted that Netscape had changed. It used to be full of people who wanted to help create a great company. It turned into a place full of people who just wanted to work for a great company. The people who live to help create get replaced by those who want to ride on their coat-tails. This happens when businesses become successful. Everything changes. Like the band that was good friends and partied together every night. They get signed, shit gets serious, and suddenly they&#x27;re fighting and arguing about things till they break up and go their separate ways.<p>&gt;From an old post in his blog:<p>&gt;What is most amazing about this is not the event itself, but rather, what it indicates: Netscape has gone from ``hot young world-changing startup&#x27;&#x27; to Apple levels of unadulterated uselessness in fewer than four years, and with fewer than 3,000 employees.<p>&gt;But I guess Netscape has always done everything faster and bigger. Including burning out.<p>&gt;It&#x27;s too bad it had to end with a whimper instead of a bang. Netscape used to be something wonderful.<p>&gt;The thing that hurts about this is that I was here when Netscape was just a bunch of creative people working together to make something great. Now it&#x27;s a faceless corporation like all other faceless corporations, terrified that it might accidentally offend someone. But yes, all big corporations are like that: it&#x27;s just that I was here to watch this one fall.<p>&gt;Perhaps the same fate awaits Mozilla. Hopefully not, but when your product becomes as successful as Mozilla and Firefox have, things do change and change is inevitable. It all comes down to how the people involved with the projects handle the change.<p>&gt;Mozilla did rise from the ashes of Netscape though. Hopefully some of the original Netscape people are still around to help lead Mozilla in the right direction, using their experience from the crashing and burning of Netscape in the late 90&#x27;s.<p>&gt;JWZ&#x27;s rantings can be found at <a href="http:&#x2F;&#x2F;www.jwz.org&#x2F;gruntle&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.jwz.org&#x2F;gruntle&#x2F;</a> [jwz.org]<p>(Just click on the testicle!)<p>``I have yet to come across so much self-righteous bullshit as when I gaze upon the massive heap of crap that is the jwz web experience.&#x27;&#x27;<p>-- an anonymous poster to slashdot.org, 1998.<p>I&#x27;m not saying it always has to end in tragedy: C# and TypeScript turned out beautifully, given the constraints they had to deal with, in spite of the fact that they came from a giant corporate behemoth like Microsoft. (Although I&#x27;m sure there&#x27;s a lot of bullshit going on behind the scenes, the trend is to make them more open and community driven.)<p>----<p>Chuck McManis also wrote:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4993818">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4993818</a><p>ChuckMcM on Jan 1, 2013 | parent | next [–]<p>Yes, I am aware. I was at a Usenix conference where Rob Pike presented a paper on it, back when it was a bright idea out of Bell Labs. It is the curse of brilliant people that they see too far into the future, get treated as crazy when they are most lucid and get respect when they are most bitter [1]. I was working for Sun Microsystems at the time and Sun was pursuing a strategy known as &quot;Distributed Objects Everywhere&quot; or (DOE) but insiders derisively called it &quot;Distributed Objects Practically Everywhere&quot; or DOPE, it was thinking about networks of 100 megabits with hundreds of machines on them. Another acquaintance of mine has a PDP 8&#x2F;s this was a serial implementation of the PDP-8 architecture, Gordon Bell did that in the 70&#x27;s well before serial interconnects made sense. It was a total failure, the rest of the world had yet to catch up. Both Microsoft and Google have invested in this space, neither have published a whole lot, every now and then you see something that lets you know that somebody is thinking along the same lines, trying to get to an answer. I suspect Jeff Bezos thinks similarly if his insistence on making everything an API inside Amazon was portrayed accurately.<p>The place where the world is catching up is that we have very fast networks in very dense compute. In the case of a cell phone you see a compute node which is a node in a web of nodes which are conspiring to provide a user experience. At some point that box under the table might have X units of compute, Y units of IO, and Z units of storage. It might be a spine which you can load up with different colored blocks to get the combination of points needed to activate a capability at an acceptable latency. If you can imagine a role playing game where your &#x27;computer&#x27; can do certain things based on where you invested its &#x27;skill points&#x27; that is a flavor of what I think will happen. The computers that do shipping, or store sales will have skill points in transactions, the computers that simulate explosions will have skill points in flops. People will argue whether or not the brick from Intel or the Brick from AMD&#x2F;ARM really deserves a rating of 8 skill points in CRYPTO or not.<p>[1] I didn&#x27;t get to work with Rob when I was at Google although I did hear him speak once and he didn&#x27;t seem particularly bitter, so I don&#x27;t consider him a good exemplar of the problem. Many brilliant people I&#x27;ve met over the years however have been lost to productive work because their bitterness at not being accepted early only has clouded their ability to enjoy the success their vision has seen since they espoused it.
DonHopkinsalmost 2 years ago
&gt;To create quality software, the ability to say “no” is usually far more important than the ability to say “yes.” Open source embodies this in something that can be called “benevolent dictatorship”: Even though many people contribute to the overall effort, a single expert (or a small cabal of experts) ultimately rejects or accepts each proposed change. This preserves the original architectural vision and stops the proverbial too many cooks from spoiling the broth.<p>“Focusing is about saying no.” -Steve Jobs, WWDC ‘97 -- As sad as it was, Steve Jobs was right to “put a bullet in OpenDoc’s head”.<p><a href="https:&#x2F;&#x2F;donhopkins.medium.com&#x2F;focusing-is-about-saying-no-steve-jobs-wwdc-97-ff0174c171d0" rel="nofollow noreferrer">https:&#x2F;&#x2F;donhopkins.medium.com&#x2F;focusing-is-about-saying-no-st...</a><p>And also:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16227249">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16227249</a><p>DonHopkins on Jan 24, 2018 | parent | context | favorite | on: Ted Nelson on What Modern Programmers Can Learn fr...<p>In the ideal world we would all be using s-expressions and Lisp, but now XML and JSON fill the need of language-independent data formats.<p>&gt;Not trying to defend XSLT (which I find to be a mixed bag), but you&#x27;re aware that it&#x27;s precursor was DSSSL (Scheme), with pretty much a one-to-one correspondence of language constructs and symbol names, aren&#x27;t you?<p>The mighty programmer James Clark wrote the de-facto reference SGML parser and DSSSL implementation, was technical lead of the XML working group, and also helped design and implement XSLT and XPath (not to mention expat, Trex &#x2F; RELAX NG, etc)! It was totally flexible and incredibly powerful, but massively complicated, and you had to know scheme, which blew a lot of people&#x27;s minds. But the major factor that killed SGML and DSSSL was the emergence of HTML, XML and XSLT, which were orders of magnitude simpler.<p>James Clark: <a href="http:&#x2F;&#x2F;www.jclark.com&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.jclark.com&#x2F;</a><p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;James_Clark_(programmer)" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;James_Clark_(programmer)</a><p>There&#x27;s a wonderful DDJ interview with James Clark called &quot;A Triumph of Simplicity: James Clark on Markup Languages and XML&quot; where he explains how a standard has failed if everyone just uses the reference implementation, because the point of a standard is to be crisp and simple enough that many different implementations can interoperate perfectly.<p>A Triumph of Simplicity: James Clark on Markup Languages and XML:<p><a href="http:&#x2F;&#x2F;www.drdobbs.com&#x2F;a-triumph-of-simplicity-james-clark-on-m&#x2F;184404686" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.drdobbs.com&#x2F;a-triumph-of-simplicity-james-clark-o...</a><p>I think it&#x27;s safe to say that SGML and DSSSL fell short of that sought-after simplicity, and XML and XSLT were the answer to that.<p>&quot;The standard has to be sufficiently simple that it makes sense to have multiple implementations.&quot; -James Clark<p>My (completely imaginary) impression of the XSLT committee is that there must have been representatives of several different programming languages (Lisp, Prolog, C++, RPG, Brainfuck, etc) sitting around the conference table facing off with each other, and each managed to get a caricature of their language&#x27;s cliche cool programming technique hammered into XSLT, but without the other context and support it needed to actually be useful. So nobody was happy!<p>Then Microsoft came out with MSXML, with an XSL processor that let you include &lt;script&gt; tags in your XSLT documents to do all kinds of magic stuff by dynamically accessing the DOM and performing arbitrary computation (in VBScript, JavaScript, C#, or any IScriptingEngine compatible language). Once you hit a wall with XSLT you could drop down to JavaScript and actually get some work done. But after you got used to manipulating the DOM in JavaScript with XPath, you being to wonder what you ever needed XSLT for in the first place, and why you don&#x27;t just write a nice flexible XML transformation library in JavaScript, and forget about XSLT.<p>XSLT Stylesheet Scripting Using &lt;msxsl:script&gt;:<p><a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;standard&#x2F;data&#x2F;xml&#x2F;xslt-stylesheet-scripting-using-msxsl-script" rel="nofollow noreferrer">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;dotnet&#x2F;standard&#x2F;data&#x2F;xml&#x2F;xs...</a><p>Excerpts from the DDJ interview (it&#x27;s fascinating -- read the whole thing!):<p>&gt;DDJ: You&#x27;re well known for writing very good reference implementations for SGML and XML Standards. How important is it for these reference implementations to be good implementations as opposed to just something that works?<p>&gt;JC: Having a reference implementation that&#x27;s too good can actually be a negative in some ways.<p>&gt;DDJ: Why is that?<p>&gt;JC: Well, because it discourages other people from implementing it. If you&#x27;ve got a standard, and you have only one real implementation, then you might as well not have bothered having a standard. You could have just defined the language by its implementation. The point of standards is that you can have multiple implementations, and they can all interoperate.<p>&gt;You want to make the standard sufficiently easy to implement so that it&#x27;s not so much work to do an implementation that people are discouraged by the presence of a good reference implementation from doing their own implementation.<p>&gt;DDJ: Is that necessarily a bad thing? If you have a single implementation that&#x27;s good enough so that other people don&#x27;t feel like they have to write another implementation, don&#x27;t you achieve what you want with a standard in that all implementations — in this case, there&#x27;s only one of them — work the same?<p>&gt;JC: For any standard that&#x27;s really useful, there are different kinds of usage scenarios and different classes of users, and you can&#x27;t have one implementation that fits all. Take SGML, for example. Sometimes you want a really heavy-weight implementation that does validation and provides lots of information about a document. Sometimes you&#x27;d like a much lighter weight implementation that just runs as fast as possible, doesn&#x27;t validate, and doesn&#x27;t provide much information about a document apart from elements and attributes and data. But because it&#x27;s so much work to write an SGML parser, you end up having one SGML parser that supports everything needed for a huge variety of applications, which makes it a lot more complicated. It would be much nicer if you had one SGML parser that is perfect for this application, and another SGML parser that is perfect for this other application. To make that possible, the standard has to be sufficiently simple that it makes sense to have multiple implementations.<p>&gt;DDJ: Is there any markup software out there that you like to use and that you haven&#x27;t written yourself?<p>&gt;JC: The software I probably use most often that I haven&#x27;t written myself is Microsoft&#x27;s XML parser and XSLT implementation. Their current version does a pretty credible job of doing both XML and XSLT. It&#x27;s remarkable, really. If you said, back when I was doing SGML and DSSSL, that one day, you&#x27;d find as a standard part of Windows this DLL that did pretty much the same thing as SGML and DSSSL, I&#x27;d think you were dreaming. That&#x27;s one thing I feel very happy about, that this formerly niche thing is now available to everybody.
sgt101almost 2 years ago
ORMs...<p>&quot;Hold my beer!&quot;