Old tech.
New software development is 99% aimless churn.
We don’t need more new tech. We need better applications of old tech. There is so much software that works perfectly fine already. What’s missing is connecting it to real world problems.
New software development is 99% aimless churn.
We don’t need more new tech. We need better applications of old tech. There is so much software that works perfectly fine already. What’s missing is connecting it to real world problems.
"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.
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.
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")!
1: https://news.ycombinator.com/item?id=25989454, link to article submitted for the lazy: https://developers.slashdot.org/comments.pl?sid=18156250&cid...
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.
I care a lot about companies that actually make something new or popularize something that already existed but didnt have widespread appeal.
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.
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.
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.
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.
Like looms.
Robotics is actually generally pretty slow. Regular (serial) robot arms are usually significantly slower than a human arm. Some parallel robots (ie where the motors are mostly stationary and don’t have to be waved around by other motors), like a SCARA or Delta robot, can go about 2-3x the speed of a human, but the difference isn’t massive (60 vs 150 picks per minute?).
But looms are insane. Their task is simpler, but they can do over 2000 picks per second (!). The yarn in air jet looms can be moving over 200 mph. And even mechanical looms like Rapier looms or projectile looms are super fast. The mechanisms are also super advanced and hard to wrap your mind around. Centuries of optimization of the first really good industrial automation instance will do that, I suppose.
It makes me think we haven’t reached a completely flat plateau in mechanical development. Our robots today are actually pretty primitive compared to where they could... where they really should be. It also shows just how hard I think a lot of futurists have underestimated human mechanical capability. Human dexterity and force density is crazy impressive. Humans are actually super strong, fast, AND precise.
And hard automation like looms are also underestimated vs “robot arms.” Hard automation is so much more effective if you can do it. Just robot arms aren’t that great vs people
Are they too far ahead of the curve? Or is it just rare that your task remains identical enough (i.e., textiles) for the decades it takes to optimize hardware?
There's also a ton of engineering needed to go into how to make better robots.
It's also appropiate to put this comment under some other mentioning old tech. Because robots have become steampunk. Very dear to first sci-fi writers, now they're démodé.
As soon as NLP gets another frog leap, we'll start seeing a comeback.
* Better in this case would be a fundamental design to prevent spoofing, provide S2S encryption maybe E2E encryption, fixing MIME typing issues, fixing Rich Text/HTML display, etc. Basically an actually good faith replacement of e-mail instead of a vendor co-opting.
Support for MNM by way of Patreon is requested on the home page.
There's also JMAP, with credible standards people involved:
https://datatracker.ietf.org/wg/jmap/photos/
Serious industry involvement however appears limited to FastMail.
TMTP is an alternative to the entire email protocol stack. It will be standardized after it's been proven in a range of real-world scenarios.
The mnm client & server, which implement TMTP, work well today, and have nearly all the features most users need. See docs menu in the online demo.
https://mnmnotmail.org/demo.html
Re "serious money", could you elaborate?
"The best under-the-radar car? It's a horse and buggy I tells ya!" Every one of these posts on HN has to have a hot take that's contrarian.
I’m also genuinely excited that there is growing momentum away from software churn, because we’re not going to solve the complexity crisis with another framework.
Some form of tablets and smartphones were there years before the iPhone or iPad.
And sometimes the tech we need is "out there" and has been for a while, but just hasn't hit "critical mass" yet.
Take @kroltan's answer. I am also extremely bullish on RDF, Wikidata, and the like. But most of this stuff is pretty old now, especially in "Internet years". Which leads, of course, to the question of where the line is between incremental refinement of "old tech" and actual "new tech" as a discrete thing.
We need to find more/better ways of integrating people with tech.
Tech on its own is 10% of the solution. Integrating humans with technology is underrated.
(I say this as the owner of various enterprise SaaS businesses but I'm sure it applies in all aspects of software)
https://medium.com/@adamagb/nintendo-s-little-known-product-...
In some circles, you might even be accused of being a boomer for using SQL. I think a lot of developers are missing out on just how much runway you can get out of SQL and libraries like SQLite. You would also be missing out on one of the greatest breakthroughs in the history of computer science with regard to our ability to model problem domains and perform inhuman queries against them with millisecond execution times. But hey, maybe machine learning and mongodb are working for your shop.
The final thing a lot of people miss are old ideas. Put your entire application on a single server somewhere, and all of its dependencies live in the same box. Optimize the vertical before you rewrite for horizontal, because 99% of the time you will go bankrupt before you get as big as Netflix so it wont matter anyways. Plus, you would go bankrupt faster anyways by chasing delusions of web-scale grandeur when you could have had the MVP done 3 years ago with just a simple SQLite database back-end and a T3a.micro. More likely than not you would have discovered it was a bad idea to start with and could more quickly move on to the actual thing you should have been focusing on.
Worse case, you'll get bottlenecked by the DB and move it to a different (bigger) server.
Emacs and org-mode (and many things GNU) have started to make more and more sense to me in this day and age.
I suppose you're writing this on a 1982 Commodore 64...
“Better application” + “old tech” ≡ “new tech”.
Group permission, PAM, SSO, etc. It's like these developers have never been exposed to Active Directory ever in their life...
> Because back in the day I didn't know even one developer who wouldn't curse when working with DCOM/Corba implementations because of convoluted complexity, bugs, and problems with debugging.
Yeah, I got that impression about COM through osmosis over the years. But come to think of it, isn't the exact same thing happening with the current trend of microservices, and super-convoluted stacks of Docker containers and Kubernetes? So perhaps the problem ultimately wasn't with COM per se :).
So you get new grads that are re-inventing the wheel.
Group permissions predate AD by decades, PAM by a few years. SSO in today's form is a web phenomenon, so a web-oriented solution makes more sense, and there is a lot of work being done in this direction.
And LDAP, and some DNS, and certs, etc. It's not just Kerberos; you're sounding ignorant here.
>Group permissions predate AD by decades
No one said otherwise, but it goes beyond basic POSIX groups with things like nested groups, delegated group permissions, etc.
>SSO in today's form is a web phenomenon
So is AD's...
Basically, you're proving my point.