joshua.rumbut@gmail.com
- Well, that's why people still have jobs but I appreciate the idea of the post that the neat demo was a coherent paragraph or silly poem. The silly poems were all kind of similar, not very funny, and the paragraphs were a good start but I wouldn't use them for anything important.
Now the tightrope is a whole application or a 14 page paper and the short pieces of code and prose are now professional quality more often than not. That's some serious progress.
- Every time software has gotten cheaper to create the end result has been we create a lot more software.
There are still so many businesses running on pen and paper or excel spreadsheets or off the shelf software that doesn't do what they need.
Hard to say what the future holds but I'm beginning to see the happy path get closer than it looked a year or two ago.
Of course, on an individual basis it will be possible to end up in a spot where your hard earned skills are no longer in demand in your physical location, but that was always a possibility.
- It's poor timing for this article.
The CrowdStrike incident has demonstrated that no matter what you do it is possible for any distributed system to be partitioned in such a way that you have to choose between consistency and availability and if the system is important then that choice is important.
- Is Platonic realism valid? I need to know before I plug in this toaster.
- > we can digitize them
We can, but will we? And will we maintain those collections?
There is some resilience in having collections scattered here, there, and everywhere in addition to having a substantial chunk of history reliant on one charity that is constantly under threat due to copyright law.
History suggests that at some point the Internet Archive will be lost.
Additionally, a digital copy doesn't preserve the physical artifact. The ink, paper, and glue contains information about trade, printing technology, and perhaps the environment as well. We don't know what questions people will ask in the future.
- Collecting usually occurs in a niche community, so who is selling matters.
A well known collector finally parting with their prize pieces everyone has been drooling over for 40 years is going to yield a greater return than a stranger walking in with the same items looking for quick cash.
- > serialised in a version of JS that the receiver understands
I don't think the use case for this is as general as most RPC systems.
The linked site envisions a situation where you had an app running on one server, now you want to break that workload up while making the absolute minimum number of code changes.
All the clients and code would still be controlled by the same team.
- It's especially true because of this line that could have easily come out of a Marquez novel:
> "And we decided, yes, it was a betrayal. But that's what children are for."
- The institutional preservation instinct can cause perverse incentives but it is useful and allows large organizations to be trusted to do things that can't be addressed by startups.
If you have work that requires something to exist in more or less its present form for years or decades at a time it would be a disaster if one of your key vendors pivoted or went bankrupt halfway through.
- > budgets often work differently.
Very differently. Instead of a system you continually iterate on for its entire lifetime, if you're in a more regulated research area you might build it once, get it approved, and then it's only critical updates for the next five (or more!) years while data is collected.
Not many of the IT principles developed for web app startups apply in the research domain. They're less like cattle or pets and more like satellites which have very limited ability to be changed after launch.
- > The biggest issue isn't the software glitch system.
I disagree, the software glitch was the problem here.
We are supposed to be able to rely on computers to store and add numbers or report a system failure. This accounting software showed in black and white that some funds that the sub-postmasters were responsible for had gone missing.
What else was the legal system supposed to do? The broken software was simulating crime perfectly.
- I do think more of them would work from first principles if more (non-programmer focused) programs exposed a set of principles and allowed users to operate on them using their own logic and imagination.
Excel and some image editors do that, and people make pretty cool stuff with them.
- Truth be told I think non-programmers are the experts on using technology. When I have a problem I reach for code, the real power users are the ones who don't have that option.
- > So they want to sleep at your place but are not comfortable having you around?
Yes, this is extremely common. All of my in-laws would go in this category, more or less. I might spend the night at their house, but it would be awkward to wake up with them in the room. Many friends who have moved far away and I don't see them regularly any more would also qualify.
> And if they have back pain they can't sleep on just any mattress either
There is an enormous population that exists between "can't sleep comfortably on a couch" and "needs some specific kind of mattress."
> an entirely unused room
Space isn't at a premium where I live, a whole unused room is no big deal. Plus if I have a another child there is a room ready for them.
That's the source of a lot of guest rooms, they are rooms for future/past children. My own guest room is also an office when there aren't guests.
- > If it's just one guest, they can sleep on the couch.
This works until your friends start getting married, start having back problems, or just want a little privacy while they sleep.
- > But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power.
It's not just business knowledge, it allows the people who are most committed to project success to do the work.
I think that's the real pain point with IT departments in large organizations. They aren't feeling the pain that made you need the software in the first place.
- We forget that favoring composition over inheritance is one of the core ideas of OOP. It's supposed to be, at least.
Textbooks have an example like "Dog inherits from Animal" as a way to demonstrate the concept of inheritance, but people took that as an invitation to become Linnaeus and create a hierarchical taxonomy of their domain.
It might be a useful exercise, actually, but it's rarely the best way to design software and you can do OOP (and do it better) with sparing use of inheritance (by replacing it with extensive use of composition).
- You either end up reinventing foreign keys, your support volume will scale faster than your data, or user experience will suffer.
There may be situations where foreign keys become too much overhead, but it's worth fighting to keep them as long as possible. Data integrity only becomes more important at scale. Every orphaned record is a support ticket, lost sale, etc.
- > Because that single application already exists, in my case its postgres.
This is exactly what postgres was designed for! Tens of thousands of hours of work over decades to solve the problem of relational database management. That's why we call it an RDBMS!
Which isn't to say you shouldn't make your own API ever. There are a lot of situations where you don't want things to connect directly to postgres.
But you shouldn't be afraid of having multiple systems connect to postgres. It has incredibly mature and robust features to accommodate that use case. It's the expected use case.
Regarding any BSD used for any purpose, BSD has a more consistent logic to how everything works. That said, if you're used to Linux then you're going to be annoyed that everything is very slightly different. I am always glad that multiple BSD projects have survived and still have some real users, I think that's good for computing in general.