5 ms·

This article from 2005 definitely captures some sillyness around dev work at the time, but in retrospect a lot of that was caused more by Big Objects than by fr

This article from 2005 definitely captures some sillyness around dev work at the time, but in retrospect a lot of that was caused more by Big Objects than by frameworks themselves, although Big Objects was definitely enabled by frameworks. Big Objects was the idea that in the future, basic doing stuff level code would be fully replaced by bought or open source objects that would plug in in standard ways to industry wide interfaces. It was nuts, and was largely driven out by ruby and python gaining traction, libraries that were marketed as having more pleasant interfaces than their competition, and 'enterprisey' becoming a bad word. Still, you could take a couple swings through the conference circuit around 2004-2006 by saying that the future was kludging together fungible objects in Java or .NET.

_448 5y ago
> the future was kludging together fungible objects in Java or .NET. And, DCOM and CORBA :)
- parksy 5y ago
  As a web developer in the open source, PHP (YUCK) environment, the single time DCOM has been useful for me was an insurance company who had a government-mandated PDF document they had to send to customers. Could we just generate a document in plaintext? No. It had to be pixel perfect dummy. And PDF! Could we just recreate a pixel-perfect HTML to PDF template? No. That would take weeks and the client only budgeted a few hours. So I asked, how do they do it currently. And they sent over a mail-merge MS Word template. We said, hey, so, we use PHP, open source, Linux. TOO MANY WORDS WE'RE PAYING YOU TO MAKE IT WORK. Could we use the template in an open source framework compatible with the PHP solution we'd built? Yeahhhhhhhh... but no. The open source framework mangled the fonts, layout, and the PDF rendering was bodgy to say the least. And yes, we went back and asked really, trully, honestly, does the government really give a shit if this document is not formatted exactly the same as whatever law they apparently passed said it had to look like. No dice. So we could have used any language I guess, but we were familiar with PHP. PHP has a DCOM extension that only works on Windows. So I spooled up a Windows Server instance (firewalled within the DC of course) and installed XAMPP and did a bunch of config to ensure it stayed updated automatically and rebooted every night at 1am. A small PHP script on the Windows server provided an API the website could call at any time. The Windows PHP endpoint had an unzipped DOCX, the script would copy the folder, search-and-replace based on API inputs, zip it up as a new DOCX file, opened in Word with DCOM to save as a PDF which was then streamed back into the website's logic all in the same POST request that a client submitted. It was a kludge, I could think of other ways to do it today, but at the arse-end of a project with an apparent doomsday requirement suddenly dropped in the mix, in the end it took about three days to implement when at the time we were facing a crisis. So yeah, give DCOM some flak I guess because it failed to launch but it saved one small project for one small insurance company. Edit to add: That solution ran for years without issue until the company merged with a larger healthcare provider.
  - electroly 5y ago
    FWIW, you seem to be talking about regular local COM and not DCOM. DCOM is COM-over-the-network, where you can create an object on another machine remotely and interact with it as if it were a local object. You are describing just using a local COM object on that Windows server. Unlike DCOM, COM is extremely popular and widely used.
    - parksy 5y ago
      Good point, it was a long while ago and I was definitely using COM objects. The network interface was handled by Apache with PHP scripting. I stand corrected, thanks :)
    - _448 5y ago
      > DCOM is COM-over-the-network The hint is in the name: "Distributed COM" i.e. DCOM :) > Unlike DCOM, COM is extremely popular and widely used. My understanding was that DCOM is nothing but data marshaling and registring GUIDs with Windows registry so that the COM object can be created locally/remotely. If COM is widely in use, then DCOM should be as well. The whole gaming(DirectX) and finance(OLE) industry is built on the DCOM/COM infrastructure :)
      - electroly 5y ago
        > If COM is widely in use, then DCOM should be as well I'm not sure what you mean. If you don't actually activate an object on another machine, you're not using DCOM. You're just using regular COM. The distinction is pretty clear; if you need the "Remote Activation" permission on a target machine, then you're using DCOM. Nobody is, for instance, instantiating DirectX objects over the network. It may help to know that COM predates DCOM by several years; they are not the same thing. DCOM adds additional infrastructure to allow it to happen over a network. The distinction here is relevant because DCOM, not just local COM, is the competitor to CORBA. The "distributed" part is the part that didn't work out and that, it turns out, not very many people want.
  - selfhoster11 5y ago
    Thank you for sharing this story. I consider war stories of this caliber to be unironically heroic exercises of thought.
mirekrusin 5y ago
What is "Big Objects"?
- awkward 5y ago
  A colloquialism that I explain in the second paragraph.
  - mirekrusin 5y ago
    Oh I thought it's a real thing, started googling it and landed on Salesforce's Big Object! Thanks.
- bendbro 5y ago
  I suspect the OOP industrial complex like "Big Pharma".
dmux 5y ago
>Big Objects was the idea that in the future, basic doing stuff level code would be fully replaced by bought or open source objects that would plug in in standard ways to industry wide interfaces. Isn't this the same as API's as a service?
brabel 5y ago
Big Objects is explained in detail in the Java Beans Spec: https://www.oracle.com/java/technologies/javase/javabeans-spec.html https://www.oracle.com/java/technologies/javase/javabeans-sp... The idea may have died, but there's still lots of vestiges of it in the Java world. - getters and setters with standardized names - Swing mechanics like EventListeners and PropertyChangeListener - Java Serialization They hoped that a Java bean could be plugged into any UI and be visualized, modified and generally integrated into any app, so you could "buy" beans made by other developers, for example. It was definitely an interesting idea, but things went in a completely different direction, as we know.
- _greim_ 5y ago
  I think sometimes the abstraction moat around an otherwise good idea definitely repels would-be adopters, which an idea needs to ascend to mainstream success, beyond just technical merit.
- the_af 5y ago
  Even though the Swing thing was java bean based, the idea of an "event listener" is a still current and sound idea in software development beyond Java. The funny thing about "standardized" getters & setters is that they completely broke OOP and went against this idea that Java was "object oriented". One of the most known articles of the time was the infamous "getters and setters considered evil".
- eternalban 5y ago
  https://netbeans.apache.org/kb/docs/java/quickstart-gui.html https://netbeans.apache.org/kb/docs/java/quickstart-gui.html It wasn't an "idea". It was/is working tech. How do you think a GUI builder for Java works? In fact, how would you build a UI design tool (in any language) without arriving at the equivalent of a Java Bean (aka Standard Component)? [p.s.] Btw, "Big Object" is a funny way to call a Component. COP is not OOP. (Thus: POJO). So getter/setter naming patterns (so the 'tool' can infer semantics), distinctions made between run-time and design-time, etc. are all perfectly valid concerns for COP and Java Beans a perfectly sensible realization. The problem with the Java community has always been two-fold: 1 - The conceptual disconnect between the target audience of Sun's architects and the said architects. SMI's failing here remains, imo, a pedagogical failure. 2 - A language that facilitates creating complex runnable monstrosities by programmers who would be crushed by the same complexity in other languages. This is an ironic aspect of the Java language. Even newbies can go nuts with complexity.
munificent 5y ago
> Big Objects was the idea that in the future, basic doing stuff level code would be fully replaced by bought or open source objects that would plug in in standard ways to industry wide interfaces. We call them microservices now.
- awkward 5y ago
  You just keep putting stuff in smaller and smaller Matryoshka dolls and then poof! No more stuff.
  - selfhoster11 5y ago
    From "Mortal Engines" by Stanisław Lem: > Pyron invented the wire telegraph, and then he pulled the wire out so fine, it wasn't' there, and in this fashion he obtained the wireless... (https://english.lem.pl/works/novels/mortal-engines/136-introduction-mortal-engines https://english.lem.pl/works/novels/mortal-engines/136-intro...) I always loved that passage and it would always crack me up from the sheer absurdity of it.
    - e3bc54b2 5y ago
      Aside from obviously great quote, thanks for reminding me of Stanislaw Lem and Pyron. I grew up reading translations of old Russian books and (I know he was Polish) your comment was a good walk on the memory lane
- selfhoster11 5y ago
  To be fair, they are a little better than the OG technology.
vaughan 5y ago
Everyone should try to build their own pluggable framework at least once, to realize how difficult it is, and to realize how small design decisions can cause massive headaches. I think a lot of frameworks are the result of someone shipping something, it gets popular, and then its stuck like that and they can't rethink it. Having done this helps you to see things in new frameworks that will inevitably lead to pain. As often as people deride it, the Node.js many-small-package philosophy (inspired by Unix) is what I keep coming back to. If one package doesn't provide the right abstraction to do something, if it's built on top of two smaller packages, I can assemble a new package with these smaller packages to achieve what I want. The smaller the package the better. From the day the first line of code in a project is written, a desire to rewrite from scratch starts to grow - to return to the productivity of having an empty slate. If you compose your app from small single-purpose packages, rewriting becomes trivial.

_448 5y ago

> the future was kludging together fungible objects in Java or .NET. And, DCOM and CORBA :)

parksy 5y ago
As a web developer in the open source, PHP (YUCK) environment, the single time DCOM has been useful for me was an insurance company who had a government-mandated PDF document they had to send to customers. Could we just generate a document in plaintext? No. It had to be pixel perfect dummy. And PDF! Could we just recreate a pixel-perfect HTML to PDF template? No. That would take weeks and the client only budgeted a few hours. So I asked, how do they do it currently. And they sent over a mail-merge MS Word template. We said, hey, so, we use PHP, open source, Linux. TOO MANY WORDS WE'RE PAYING YOU TO MAKE IT WORK. Could we use the template in an open source framework compatible with the PHP solution we'd built? Yeahhhhhhhh... but no. The open source framework mangled the fonts, layout, and the PDF rendering was bodgy to say the least. And yes, we went back and asked really, trully, honestly, does the government really give a shit if this document is not formatted exactly the same as whatever law they apparently passed said it had to look like. No dice. So we could have used any language I guess, but we were familiar with PHP. PHP has a DCOM extension that only works on Windows. So I spooled up a Windows Server instance (firewalled within the DC of course) and installed XAMPP and did a bunch of config to ensure it stayed updated automatically and rebooted every night at 1am. A small PHP script on the Windows server provided an API the website could call at any time. The Windows PHP endpoint had an unzipped DOCX, the script would copy the folder, search-and-replace based on API inputs, zip it up as a new DOCX file, opened in Word with DCOM to save as a PDF which was then streamed back into the website's logic all in the same POST request that a client submitted. It was a kludge, I could think of other ways to do it today, but at the arse-end of a project with an apparent doomsday requirement suddenly dropped in the mix, in the end it took about three days to implement when at the time we were facing a crisis. So yeah, give DCOM some flak I guess because it failed to launch but it saved one small project for one small insurance company. Edit to add: That solution ran for years without issue until the company merged with a larger healthcare provider.
- electroly 5y ago
  FWIW, you seem to be talking about regular local COM and not DCOM. DCOM is COM-over-the-network, where you can create an object on another machine remotely and interact with it as if it were a local object. You are describing just using a local COM object on that Windows server. Unlike DCOM, COM is extremely popular and widely used.
  - parksy 5y ago
    Good point, it was a long while ago and I was definitely using COM objects. The network interface was handled by Apache with PHP scripting. I stand corrected, thanks :)
  - _448 5y ago
    > DCOM is COM-over-the-network The hint is in the name: "Distributed COM" i.e. DCOM :) > Unlike DCOM, COM is extremely popular and widely used. My understanding was that DCOM is nothing but data marshaling and registring GUIDs with Windows registry so that the COM object can be created locally/remotely. If COM is widely in use, then DCOM should be as well. The whole gaming(DirectX) and finance(OLE) industry is built on the DCOM/COM infrastructure :)
    - electroly 5y ago
      > If COM is widely in use, then DCOM should be as well I'm not sure what you mean. If you don't actually activate an object on another machine, you're not using DCOM. You're just using regular COM. The distinction is pretty clear; if you need the "Remote Activation" permission on a target machine, then you're using DCOM. Nobody is, for instance, instantiating DirectX objects over the network. It may help to know that COM predates DCOM by several years; they are not the same thing. DCOM adds additional infrastructure to allow it to happen over a network. The distinction here is relevant because DCOM, not just local COM, is the competitor to CORBA. The "distributed" part is the part that didn't work out and that, it turns out, not very many people want.
- selfhoster11 5y ago
  Thank you for sharing this story. I consider war stories of this caliber to be unironically heroic exercises of thought.

mirekrusin 5y ago

What is "Big Objects"?

awkward 5y ago
A colloquialism that I explain in the second paragraph.
- mirekrusin 5y ago
  Oh I thought it's a real thing, started googling it and landed on Salesforce's Big Object! Thanks.
bendbro 5y ago
I suspect the OOP industrial complex like "Big Pharma".

dmux 5y ago

>Big Objects was the idea that in the future, basic doing stuff level code would be fully replaced by bought or open source objects that would plug in in standard ways to industry wide interfaces. Isn't this the same as API's as a service?

brabel 5y ago

Big Objects is explained in detail in the Java Beans Spec: https://www.oracle.com/java/technologies/javase/javabeans-spec.html https://www.oracle.com/java/technologies/javase/javabeans-sp... The idea may have died, but there's still lots of vestiges of it in the Java world. - getters and setters with standardized names - Swing mechanics like EventListeners and PropertyChangeListener - Java Serialization They hoped that a Java bean could be plugged into any UI and be visualized, modified and generally integrated into any app, so you could "buy" beans made by other developers, for example. It was definitely an interesting idea, but things went in a completely different direction, as we know.

_greim_ 5y ago
I think sometimes the abstraction moat around an otherwise good idea definitely repels would-be adopters, which an idea needs to ascend to mainstream success, beyond just technical merit.
the_af 5y ago
Even though the Swing thing was java bean based, the idea of an "event listener" is a still current and sound idea in software development beyond Java. The funny thing about "standardized" getters & setters is that they completely broke OOP and went against this idea that Java was "object oriented". One of the most known articles of the time was the infamous "getters and setters considered evil".
eternalban 5y ago
https://netbeans.apache.org/kb/docs/java/quickstart-gui.html https://netbeans.apache.org/kb/docs/java/quickstart-gui.html It wasn't an "idea". It was/is working tech. How do you think a GUI builder for Java works? In fact, how would you build a UI design tool (in any language) without arriving at the equivalent of a Java Bean (aka Standard Component)? [p.s.] Btw, "Big Object" is a funny way to call a Component. COP is not OOP. (Thus: POJO). So getter/setter naming patterns (so the 'tool' can infer semantics), distinctions made between run-time and design-time, etc. are all perfectly valid concerns for COP and Java Beans a perfectly sensible realization. The problem with the Java community has always been two-fold: 1 - The conceptual disconnect between the target audience of Sun's architects and the said architects. SMI's failing here remains, imo, a pedagogical failure. 2 - A language that facilitates creating complex runnable monstrosities by programmers who would be crushed by the same complexity in other languages. This is an ironic aspect of the Java language. Even newbies can go nuts with complexity.

munificent 5y ago

> Big Objects was the idea that in the future, basic doing stuff level code would be fully replaced by bought or open source objects that would plug in in standard ways to industry wide interfaces. We call them microservices now.

awkward 5y ago
You just keep putting stuff in smaller and smaller Matryoshka dolls and then poof! No more stuff.
- selfhoster11 5y ago
  From "Mortal Engines" by Stanisław Lem: > Pyron invented the wire telegraph, and then he pulled the wire out so fine, it wasn't' there, and in this fashion he obtained the wireless... (https://english.lem.pl/works/novels/mortal-engines/136-introduction-mortal-engines https://english.lem.pl/works/novels/mortal-engines/136-intro...) I always loved that passage and it would always crack me up from the sheer absurdity of it.
  - e3bc54b2 5y ago
    Aside from obviously great quote, thanks for reminding me of Stanislaw Lem and Pyron. I grew up reading translations of old Russian books and (I know he was Polish) your comment was a good walk on the memory lane
selfhoster11 5y ago
To be fair, they are a little better than the OG technology.

vaughan 5y ago

Everyone should try to build their own pluggable framework at least once, to realize how difficult it is, and to realize how small design decisions can cause massive headaches. I think a lot of frameworks are the result of someone shipping something, it gets popular, and then its stuck like that and they can't rethink it. Having done this helps you to see things in new frameworks that will inevitably lead to pain. As often as people deride it, the Node.js many-small-package philosophy (inspired by Unix) is what I keep coming back to. If one package doesn't provide the right abstraction to do something, if it's built on top of two smaller packages, I can assemble a new package with these smaller packages to achieve what I want. The smaller the package the better. From the day the first line of code in a project is written, a desire to rewrite from scratch starts to grow - to return to the productivity of having an empty slate. If you compose your app from small single-purpose packages, rewriting becomes trivial.