This is the Soylent hypothesis. "Processed food" as such is not the problem—it's processed food used as a delivery vehicle for as many addictive sugars, fats, and simple carbs as possible. I would guess that the bad kind of processed food is much more common because it's both easier to make and more profitable (flour is cheap; oil is cheap; protein is expensive).
The same hypothesis (that we can reclaim the idea of processed food for nutritionally complete foods) is also on display in a product like Vite Ramen which explicitly patterns itself after a nutritionally dubious staple food (i.e., instant ramen). I would expect to see more startups in this space in the next few years.
> It's so easy in the vacuum of a single developer with a single application to think everyone should keep up to date, but the reality is most of the PHP sites on the internet are owned by non-technical people
"Non-technical" people who don't plan for maintenance costs to their software (including maintenance to keep up with dependencies like PHP) don't get a ton of sympathy from me ¯\_(ツ)_/¯
I've heard this criticism of Laravel a couple times and never understood it. I've been using the framework for years and have never had an issue with upgrades. There is a clear and comprehensive upgrade guide with each release, as well as a third-party package called Laravel Shift that can inspect your code and perform automatic upgrades in many cases. I've found there are only one or two breaking changes per minor version release (which seems reasonable to me), and they are always well-documented.
Aside from that, I'm glad you've highlighted Laravel, which—despite being the most popular server-side Web framework on GitHub—gets virtually no attention from HN. It's typical to use Laravel in the old server-side rendered Rails paradigm (which is still probably best for some applications), but I've had success using it to develop APIs as well. Core features like the ORM, job queues, dependency injection, email templating, etc, are very solid, and the ecosystem of packages around it is phenomenal. I would recommend it to any Web developer.
PHP has had optionally typed function parameters and return values since the late 5.x releases I think (current release is 7.3). Types are checked at runtime and throw TypeErrors if the declared types are violated. They can also be checked ahead of time by IDEs with code inspection such as PhpStorm.
The 7.4 release is adding typed class properties as well[1].
I maintain a ~75k LOC PHP codebase (using the Laravel framework), and we have almost never encountered type issues. The new style of PHP (and Javascript is heading in a similar direction tbh) is to write it almost like it's Java, but with the option to fall back to dynamic "magic" as needed. If you utilize the dynamic elements sparingly, and following widely understood conventions, the productivity-vs.-reliability tradeoff is highly favorable for many applications compared to languages like Java and C#.
P.S. I like Python, but I would argue PHP actually has a better story to tell about types these days. "While Python 3.6 gives you this syntax for declaring types, there’s absolutely nothing in Python itself yet that does anything with these type declarations..." [2]. Declaring types in a dynamic language only to have them ignored at runtime does not inspire much confidence.
It would be far from the first HN article (or comment) that failed to make a distinction between "poorly designed object-oriented systems" and the very idea of OOP, design patterns, etc
I'm a (primarily backend/API) web developer, with 5 years of experience at this point, and I've been planning to apply to Georgia Tech OMSCS in order to branch out into different specializations like ML and data science. A better foundation in algorithms etc. wouldn't hurt either--my bachelor's is not CS-related.
This article gave me pause, since I've never heard much skepticism expressed about a Comp Sci MS before. Is it really so overrated?
They've addressed this many times. There are different "grades" of maltodextrin with different glycemic indexes. Soylent uses a higher grade with a low glycemic index. Google "low DE maltodextrin." Soylent also uses other low-glycemic carbs such as isomaltulose.
> It always amazed me when someone looks at computer systems of the 70's through the lens of "today's" technology and then projects a failure of imagination on the part of those engineers back in the 70's
True enough, but as a younger programmer, I find it pretty reasonable to look back at computer systems of the 70s and wonder if we can do better today. I feel a little bit gross every time I have to write a bash shell script (or edit config files that aren't JSON/XML/YAML, for that matter), and I don't think that's a bad impulse. That something so inelegant and unsafe is still in widespread use in 2017 really ought to be a scandal. Even if the author didn't frame the issue in the most charitable way for the earlier trailblazing generations, he's calling attention to the right issues.
In other words, if you couldn't justify something being designed a certain way de novo, why be content with the existing design!?
I'm highly curious about Rust as a potential introduction to systems programming. One thing that bothers me is the lack of proper classes. This seems to have become a trend among newer languages, as though traditional OOP is an outdated paradigm.
I have yet to be convinced that this is a good move. The attempted justifications I've seen hand-wave about problems with OOP, "composition over inheritance," etc. Meanwhile, in the real world, 99% of production code is OO and the paradigm continues to do its basic job--helping programmers model domain objects. Older languages like JavaScript and PHP have made their OO constructs more robust over time, which suggests to me that in the end a critical mass of developers will always clamor for this easily understandable and productivity-enhancing paradigm over some theoretically pure alternative.