throwaway892238
throwaway892238 on Hacker News
There is no uniform standard of education in the US. Kids in the South are being taught that evolution is on par with intelligent design. Poor black kids in Baltimore have on average a 3rd grade reading level in high school, while rich kids a few counties away are taught when to use a backdoor roth ira. Don't even mention "no child left behind".
Maybe let's calm down a bit with the judgement.
Meanwhile, all the commenters in here are overreacting as usual, clearly not having read any of the terms of the website, like the part where it says your name is not disclosed until you explicitly elect to share it. But hey let's not let facts stop us from freaking out.
- Easy is when something does not require much effort.
- Simple means the least complex it can be and still work.
- Complex means there are lots of components.
- Easy is a concept that distinguishes the amount of work needed to use a solution
- Simple is a concept that distinguishes whether or not there is an excess number of interacting properties in a system
- Complex is a concept describing the quality of having a number of interacting properties in a system
"Deep", in the context of software complexity, probably only makes sense in terms of describing the number of layers involved in a piece of technology. You could make something have many layers, and it could still be simple, or be complex, or easy.
Simple doesn't mean "not deep". It means having the fewest parts needed in order to accomplish your requirements.
If you require a distributed, centralized, replicated, high-availability, high-durability, high-bandwidth, low-latency, strongly-consistent, synchronous, scalable object store with HTTP REST API, you can't get much simpler than S3. Lots of features have been added to AWS S3 over the years, but the basic operation has remained the same.
Planes are good enough for going a long distance fast, and cars/trucks/trains are good enough for going a long distance slow. We could make a flying car, but for what? For individual people to go a moderate-distance fast? To go a short distance really fast? Cars and planes are good enough for our needs today without the huge investment in development of a new tech.
This is exactly the same reason internal combustion engines have ruled the roads for 100 years. Electric cars were preferred over ICE 100 years ago, but gasoline enabled us to go further for cheaper, so we accepted all the downsides, and industry made it convenient. It's only because we're suddenly afraid of our climate killing us that we're switching back to electric.
I actually suspect it's due to them being publicly traded. They literally are not allowed to do things that would jeopardize the share price, so they will hurt themselves and people in order to make a minor profit increase YOY. You shouldn't need to be a capitalist enterprise (with the whole "infinite revenue growth" thing) if your purpose is just to make sure your customers - who won't ever really grow much, because, you know, only so many babies born etc - have power, water, etc. But as publicly traded companies, their first purpose is just to increase shareholder revenue. If you end up (accidentally) burning down a forest, poisoning some communities, or compromising a state election with a fake candidate, that may just be an unfortunate side effect in the service of increasing the stock price.
If CoreOS actually wanted to make distributed computing easier, they'd make patches for the Linux kernel (or make an entirely different kernel). See the many distributed OS kernels that were made over 20 years ago. But that's a lot of work. So instead they tried to go the cheap and easy route. But the cheap and easy route ends up being much shittier.
There's no commercial advantage to building a distributed OS, which is why no distributed OS is successful today. You would need a crazy person to work for 10 years on a pet project until it's feature-complete, and then all of a sudden everyone would want to use it. But until it's complete, nobody would use it, and nobody would spend time developing it. Even once it's created, if it's not popular, still nobody will use it (you can use Plan9 today, but nobody does).
If there were an alternative to Kubernetes that were just 10% less confusing, complicated, opaque, monolithic, clunky, etc, we would all be using it. But because Kubernetes exists, and everyone is using it, there's no point in trying to make an alternative. It would take years to reach feature parity, and until you do, you can't really switch away. It's like you're driving an 18-wheeler, and you think it kinda sucks, but you can't just buy and then drive a completely different 18 wheeler for only a couple of your deliveries.
You probably will end up using K8s at some point in the next 20 years. There's not really an alternative that makes sense. As much as it sucks, and as much as it makes some things both more complicated and harder, if you actually need everything it provides, it makes no sense to DIY, and there is no equivalent solution.
https://www.healthcaredive.com/news/unitedhealth-antitrust-i...
The big problem is it's all self-attestation. I've worked for one of these vendors, and it was a lot of jackass business people who didn't actually care if anything was secure, they just wanted to "pass" their certification as quickly as possible and cut as many corners as they could. Didn't want to spend money on a contractor who knew how to actually pass these certifications, so instead they'd just lean on the IT dude and demand he complete things he didn't know anything about on impossible timeframes, asking him to do things which they might be legally liable for, and basically trying to avoid doing any actual security work if at all possible. Lowers cost, gets their project going faster which helps them land more contracts and get a promotion.
Perhaps the disconnect is his belief that "what I do know is technology and UI/UX." Perhaps he really believes he knows how to build technology like this. But his complaints are those of a person who clearly only thinks of technology, as technology. Not as the stupid redneck in Arkansas who needs to use a shitty mobile connection in order to find out if diapers are on sale yet; but as the lofty technologist, surveying the digital landscape from his 100-gigabit 16-cpu latest-generation pocket powerhouse, flicking through content faster than it can render, concluding that the technological marvel of dreary old-world tech to be wanting.
The poor fools! They don't understand what I, a technology UI/UX expert, want in a mobile app! How foolish that they have not implemented what their competition has. It can only be incompetence. Not to worry though. I, the technological wunderkind, will write a blog post. I will educate them on their shortcomings, and inform them of the correct path to profitability. It's my duty to help these poor sods realize the truth: that they are not yet advanced enough. But with my help, they'll get there.
This chart shows that HTTP2 is more than half as slow as HTTP1.1, and HTTP3 is half as slow as HTTP2. Jesus christ. If these get adopted across the whole web, the whole web's performance could get up to 75% slower . That's insane. There should be giant red flags on these protocols that say "warning: slows down the internet"
1. Layout, format [aka style], and interactivity, is both hard and necessary
2. Interfaces are subtly complex
Number 2 is the reason that "simple" formatting markup, like Markdown, will never be good enough to make a great interface. You can make a poor interface with Markdown, and that poor interface is good enough for very simple use cases. But people quickly get annoyed by simple use cases. They create friction, both for the designer and the user. More useful functionality is desired, and you need something more complex to enable that.
I've written a lot of tech docs. Markdown is one of the worst methods I've found to write them. Not because its formatting isn't intuitive, easy to remember, and easy to use. But because the documents it creates are not conducive to the purpose of the document: making it easy to read and remember information.
As for more general interfaces, the easiest way to understand why you need more elaborate methods, is HTML. When HTML was created by Tim-Berners Lee ~1990, he intended for format and layout to be independent and configurable. However, for years it lacked both formatting and layout options, and lots of people complained. It took six years for CSS to eventually become a standard, and before that, lots of hacks and incompatibility (and it turned out, more of them afterwards). The entire time people were complaining about how any document editor could easily format and layout exactly what the author wanted, but web browsers persisted in being difficult and inferior. Tables were only added in HTML 2.0, five years after the Web's birth.
You can still get by with not-very-good markdown, for not-very-good interfaces. But you will never have a Great interface without the ability to control layout, format, and interactivity, in subtly complex ways.
There is no easy way for a human to do that with text. But there is an invention that enabled users to create complex and rich layout, formatting, and interactivity: the WYSIWYG interface. With this tool, the human no longer needs to remember control characters, markup syntax, or formatting codes. The user no longer needs to spend endless time typing in code, displaying the result, being unsatisfied, and tweaking the code again, trying desperately to just get the screen to show them what they know they want. A WYSIWYG editor enables a human to completely discard any knowledge of how to format or layout content, and instead simply move things around on their screen with a mouse, completely eliminating complexity for the human, and enabling the creation of better content.
I think the reason modern software abandoned WYSIWYG, is that modern software isn't created for users. Most modern software is open-source (or close), and as such, it's created by developers, for developers. Developers don't want to spend time engineering a WYSIWYG, because they have no need for a good interface, and they don't care about wasting their time writing code. To them, writing code is the whole point, regardless of how long it takes, or what the outcome is. That's why Markdown was invented, and why people persist in trying to force Markdown to make something better, without realizing that that's impossible. They want to to build a castle, but they don't want to use anything other than the twigs and rocks lying about their feet.
Developing nations like India need their own time to move through similar processes. There still needs to be people lobbying, doing the work of organizing, and changing the way things work. But it's going to take decades, and maybe even centuries, like it did for other nations.
The paper focuses on microservices, and then tries to avoid claims of "they just don't like microservices" by describing the ways in which microservices are improperly used. Do they go back and compare this to monoliths or other architectures? Nope; it's really just "hey I have another microservices idea", heavily gilded. They mention "monolithic applications divided into logically distinct components", but you could just claim your microservices are divided into logically distinct components.
They also seem to completely ignore the problem that a logical separation doesn't mean your components are better off. In a complex system, often completely separate components still need to be integrated together in order for the system to function at all, much less operate efficiently. It's not a design flaw to combine different things. It depends on the application. So just separating things logically isn't some scientific computing advancement, it's just categorization.
In reality, their solution (a "single binary business logic application" and "an interface that can combine them") is literally a description of shell scripting with Unix tools. Don't get me wrong, that obviously works great, since it's been popular for 44 years (older than IPv4). But if you want to come up with some kind of modern paradigm for distributed computing, maybe we should flush it out a bit more. What we have here is a Google engineer's attempt to make a paper suggesting we make shell scripting for the web, without much to show for it.
(Personally, I think the more people try to control the interface, the worse things get. The best and most long-lived solutions in all of computing have had almost no interface at all; a raw TCP stream, 3 raw file descriptors, a set of random arguments, and a set of random key=value pairs, have enabled all modern computing paradigms to flourish)