CORBA, it got hopelessly complex but it's full potential was never reached as the greed heads took it over.
Ask HN: Abandoned/dead projects you think died before their time and why?
411–420 of 912 posts
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#412CLPM, the Common Lisp Package Manager. The Quicklisp client doesn't do HTTPS, ql-https doesn't do Ultralisp, and OCICL (which I'm currently using) doesn't do system-wide packages. CLPM is a great project, but it's gone neglected long enough that it's bitrotted and needs some thorough patching to be made usable. Fortunately Common Lisp is still as stable as it has been for 31 years, so it's just the code which interac…
Yeah I felt that Quicklisp doesn't have the same features as package managers in other languages, and https is one of them. Also it's run by a single person which doesn't have too much time to constantly update the libraries.
In comparison I found Clojars^[0] for Clojure better and community driven like NPM. But obv Clojure has more business adoption than CL.
Do you use CL for work?
[0]: https://clojars.org/
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#413Adobe Flash / Shockwave. After all these decades, I've yet to see a tool that makes it as easy to make games or multimedia as Flash did. One of many reminders recently (many others in politics) that humanity doesn't just inevitably or linearly move forward in any domain, or even 2 steps forward 1 step back. Some things are just lost to time - maybe rediscovered in a century, maybe never.
Those tools were awesome. But as formats go, they were awful due to bad performance and more security holes than anything else. I still miss Macromedia Fireworks.
> more security holes than anything else.
yeah it wasn't secure
but;
> bad performance
I don't think thats the case. For the longest while flash was faster than js at doing anything vaguely graphic based. The issue for apple was that the CPU in the iphone wasn't fast enough to do flash and anything else. Moreover Adobe didn't get on with jobs when they were talking about custom versions.
You have to remember that "apps" were never meant to be a thing on the iphone, it was all about "desktop" like web performance.
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#414- Photon, the graphical interface for QNX. Oriented more towards real time (widgets included gauges) but good enough to support two different web browsers. No delays. This was a real time operating system. - MacOS 8. Not the Linux thing, but Copeland. This was a modernized version of the original MacOS, continuing the tradition of no command line. Not having a command line forces everyone to get their act together ab…
I love this mismatched list of grievances and I find myself agreeing with most of them. XHTML and proper CPU hypervisors in particular.
People being too lazy to close the tag was apparently a gateway drug into absolute mayhem. Modern HTML is a cesspool. I would hate to have to write a parser that's tolerant enough to deal with all the garbage people throw at it. Is that part of the reason why we have so few browsers?
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#415Earlier quoted context omitted.
The reason XHTML failed is because the spec required it to be sent with a new MIME type (application/xml+xhtml I believe) which no webserver did out of the box. Everything defaulted to text/html, which all browsers would interpret as HTML, and given the mismatching doctype, would interpret as tag soup (quirks mode/lenient). Meanwhile, local files with the doctype would be treated as XHTML, so people assumed the docty…
Isn't that what the tag was supposed to solve?
Yes, I covered that; everyone assumed that you only needed to specify the doctype, but in practice browsers only accepted it for local files or HTTP responses with Content-Type: application/xml+xhtml. I've edited the comment to make that more explicit.
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#416Earlier quoted context omitted.
> but what would be the benefit of having more pages fail to render? I think those benefits are quite similar to having more programs failing to run (due to static and strong typing, other static analysis, and/or elimination of undefined behavior, for instance), or more data failing to be read (due to integrity checks and simply strict parsing): as a user, you get documents closer to valid ones (at least in the rough…
Sure, authoring tools should help authors avoid mistakes and produce valid content. But the browser is a tool for the consumer of content, and there is no benefit for the user if it fails to to render some existing pages. It is like Windows jumping through hoops to support backwards compatibility even with buggy software. The interest of the customer is that the software runs.
> there is no benefit for the user if it fails to to render some existing pages
What if the browser renders it incorrectly? If a corrupt tag combination leads to browser X parsing "" as inline text but browser Y parsing it as a script tag, that could lead to serious security issues!
Blindly guessing at the original author's intent whenever you encounter buggy content is a recipe for disaster. Sometimes it is to the user's benefit to just refuse to render it.
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#417Earlier quoted context omitted.
Isn't that what the tag was supposed to solve?
Yes, I covered that; everyone assumed that you only needed to specify the doctype, but in practice browsers only accepted it for local files or HTTP responses with Content-Type: application/xml+xhtml. I've edited the comment to make that more explicit.
Ah, I see. Yeah, that's a bit silly. They should've gone for "MUST have doctype, SHOULD have content type".
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#418ADSL in the UK.
BT had this grand vision for basically providing rich multi-media through the phone line, but in ~1998. Think a mix of on-demand cable and "teleconferencing" with TV based internet (ceefax/red button on steriods)
It would have been revolutionary and kick started the UK's jump into online rich media.
However it wouldnt have got past the regulators as both sky and NTL(now virgin) would have protested loudly.
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#419- Photon, the graphical interface for QNX. Oriented more towards real time (widgets included gauges) but good enough to support two different web browsers. No delays. This was a real time operating system. - MacOS 8. Not the Linux thing, but Copeland. This was a modernized version of the original MacOS, continuing the tradition of no command line. Not having a command line forces everyone to get their act together ab…
I love this mismatched list of grievances and I find myself agreeing with most of them. XHTML and proper CPU hypervisors in particular. People being too lazy to close the tag was apparently a gateway drug into absolute mayhem. Modern HTML is a cesspool. I would hate to have to write a parser that's tolerant enough to deal with all the garbage people throw at it. Is that part of the reason why we have so few browsers?
Not really. HTML5 parsing is very well documented and quite easy compared to all the other things a browser needs.
Re: Ask HN: Abandoned/dead projects you think died before their time and why?
#420Earlier quoted context omitted.
Nice list. Some thoughts: - I think without the move to NeXT, even if Jobs had come back to Apple, they would never have been able to get to the iPhone. iOS was - and still is - a unix-like OS, using unix-like philosophy, and I think that philosophy allowed them to build something game-changing compared to the SOTA in mobile OS technology at the time. So much so, Android follows suit. It doesn't have a command line,…
On XHTML, I think there was room for both HTML and a proper XHTML that barks on errors. If you're a human typing HTML or using a language where you build your HTML by concatenation like early PHP, sure it makes sense to allow loosey goosey HTML but if you're using any sort of simple DOM builder which should preclude you from the possibility of outputting invalid HTML, strict XHTML makes a lot more sense. Honestly I'm…
But a HTML5 parser will obviously parse "strict" HTML5 just fine too, what value is there to special-case the "this was generated by a DOM builder" path client-side?