As I've gotten more experience in tech, I came up with a saying -
"Everything great was created in the '80s, and we've been rediscovering those things every ten years since."
I'm not firm on "the '80s" - maybe this stuff is older than I think - but I think the principle still holds. If it's a problem today, somebody probably thought about it before, and then others came around and wrapped things differently.
It's not BAD to wrap things differently, but the old stuff had more of the sharp corners sanded off, and sometimes we lose that battle-hardened aspect when we rewrite code.
Except for garbage collection/whatever is happening with memory safety today. That's the good stuff.
I tend to find that if there is a software idea, there are good odds that someone once had it before and probably made some code/prototype/paper/blog post/newspaper article on it.
However usually these systems didn't take off because they were "before their time". There were cloud services in the 80s - but PCs got faster and cheaper than internet speeds could keep up. Client side apps looked better than cloud apps. Similarly modern data centers, and cloud computing primitives didn't exist so reliability was more miss than hit.
Now the economics have turned and people need data shared across multiple devices. Cloud services are the defacto method of developing applications.
Even as a different perspective to that - a lot of what AWS/GCP/Azure are doing today, IBM was doing in the 80's with Cobol and DB2 and a bunch of tech that people today are just not interested in.
There's a post that I saw on HN a couple weeks ago[1] talking about what an AWS Lambda service would look like in Cobol and I was blown away. This is the stuff my dad used to work on when he was fresh out of college, and I'm not exactly a spring chicken (as evidenced by the fact that I used the phrase "spring chicken")!
The problem was, undergrads in top 50 CS programs were not using IBM mainframes during the 80's. They were using UNIX.
Same thing today (and a few PC here and there).
Getting access to a mainframe was and still is very expensive. That's why Google, Facebook, everyone post 2000 basically got started on commodity hardware. Because it's cheap, it's what the founders knew and it works. It's also what the top 50 alumni know, and there's no vendor lock-in.
Yup. Its so shocking when something "new" or at least that feels new is actually created. I don't care about the countless companies that will make it slightly easier for me to get something from point a to point b.
I care a lot about companies that actually make something new or popularize something that already existed but didnt have widespread appeal.
Yeah. I remember looking at the Slack IPO and saying to myself, "Your F'ing kidding me. They went public for doing IRC channels in a web browser with emojis?!?!"
This isn't _as_ short-sighted as the famous "Dropbox comment"[1], but it's pretty close.
a) Slack _clearly_ offers a lot of meaningful functionality over-and-above IRC channels. "Searching" - and, implicitly, persistence - is so fundamental to the offering that it's (apocryphally) part of the acronymic name. Threading, bot support, and channel discovery are all useful features. Sure, all of those things _can_ be implemented on an IRC server, but they're not out-of-the-box.
b) Setting up and supporting an IRC server is non-trivial for a non-technical person. Sure, it's easy to you and me - but any system that can allow customers to get access to that functionality _without_ needing a dedicated I.T. team is going to be more attractive to decision-makers.
Sadly, Slack is also missing a whole lot of IRC functionality - starting with a proper desktop client. The logging it provides is a joke, even when you actually pay for it. Its search capabilities are nowhere near grep(1).
> Its search capabilities are nowhere near grep(1).
This is again missing the point. Yes, the statement "Slack's search isn't as powerful as grep's" is true - but many of the prospective users of Slack (and, crucially - most of those who make the decisions about corporate IT) are incapable or unwilling to use grep _anyway_. You are judging a tool by how well it suits your needs, without realizing that you are not its only target audience.
I think you're both missing the point, though. And it surprises me how many people miss this point even on this incredibly smart forum. The idea doesn't matter as much as the execution. The business side matters as much or more than the technology side.
Well, I agree only in part. Their biggest feat wasn't doing IRC in a browser with emojis, it was convincing many companies they actually need it. They also managed to somehow convince the geeks saying "look, you can always use IRC gateways" only to kill them once they secured their position.
One could say that memory safety is exactly the kind of "sanding off" we need on the concept of the traditional coding paradigms that have governed the software industry since there was a software industry(which, conveniently, is something that got started in the 70's and came of age in the 80's). One long period of structural debt and organizational consolidation, most of it piled on the conceptual framework of Unix, C, and core Internet technologies. There's a shift in the cosmology of computing taking place now, where the base layers are getting reexamined.
And now, a period of reinvestment in the bottom layers and signs of a diasporic divergence emerging. Movements that are ideologically different from yesteryear's FOSS, and a tightening of SV's grip on events that increasingly causes sand to pour through, new purposings of old tech and roads previously untaken. It's like Alan Kay put it: The future is the past AND the present.
Security and privacy are another big thing. In the 90s and 200Xs I installed pretty much anything as a native app and didn't worry about it as only "bad" people made viruses/trojans and legit companies had no incentive.
That all changed with big data and marketing. Now, every native app company, and every library those native apps use, has an incentive to mine your machine for data and then use and or sell that data. And further, the vectors for exploits of various native apps have increased as well and the always connected nature of our devices has increased the incentives.
Many people complain about MacOS's new security features. Me, I love them and I don't think they go far enough. Sure I want control of my machine. I don't want to secede control to Apple. But that to me is what MacOS (not iOS) is delivering (or attempting to deliver). Stop every app from doing anything without permission. Give me way to grant that permission if I really want. I wish Windows would do the same. I wish all Steam games were sandboxed.
In other words, getting all that cool tech from the 80s to be secure and privacy respecting is a ton of work.
"Everything great was created in the '80s, and we've been rediscovering those things every ten years since."
I'm not firm on "the '80s" - maybe this stuff is older than I think - but I think the principle still holds. If it's a problem today, somebody probably thought about it before, and then others came around and wrapped things differently.
It's not BAD to wrap things differently, but the old stuff had more of the sharp corners sanded off, and sometimes we lose that battle-hardened aspect when we rewrite code.
Except for garbage collection/whatever is happening with memory safety today. That's the good stuff.