> This cycle of having a few years where the costs of an approach aren't acknowledged, to a few years where the benefits aren't acknowledged, is very lame.
Well said. I do sympathize with some of the criticisms but only insofar as people who didn't have experience with microservices get sold on a lot of hype, the tradeoffs aren't made clear, and they get burned. The cycle seems to be "This is the silver bullet for programming complexity!" for a few years, followed by a few years of "This isn't a silver bullet!" before the Next Big Thing (TM) comes along and the cycle starts over.
> The more hardcore UBI defenders talk about paying Malibu surfers to surf all day, or to write haikus
I've been following the UBI space for a long time and I've never seen anyone use this as an example - that's just a strawman. What people discuss is the work that is valuable to society but is unpaid such as raising children, caretaking for the elderly, community support, and so on.
A few hundred dollars a month isn't enough to live on, but it moves the needle for those most at-risk for going hungry or becoming homeless. And for everyone else, it gives extra breathing room and negotiating power in the workplace.
Anyone who's had to parse free-text international addresses can tell you that this is terrible advice. People type things into computers incorrectly all day long. We prompt users to select things like country from dropdowns with good reason. Imagine having to delete user data for GDPR compliance and needing to determine which of your 1,000,000 users are in the EU from a free-text field. Oh, this user wrote "Czechia" instead of "Czech Republic"? What do you mean they wrote the name with accents? Oh they wrote the name in their native language and not English? Have fun parsing all this:
> always just about 'good enough' to solve the issue at hand
I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.
You're not missing anything, the argument is for how long this duration should be.
The lifetime of the original creator plus $YEARS should be more than long enough for the original work(s) to be made 'canonical'. How is a corporation buying up an IP because it is profitable going to guarantee it remains true to the original author's intentions, or to the desires of fans? If we care about the consumer they should be free to engage with the original works or any derivation thereof as they choose. IP isn't about expanding consumer choice, it's about limiting it - and it certainly isn't a mechanism for guaranteeing the ongoing quality of a series.
I agree libraries are great when dealing with very specific domain problems (who wants to hand-roll a datetime module?). But there are also a ton of libraries that aren't for such specific domains or which attempt to bridge multiple domains (i.e. frameworks).
The argument made by functional languages like Clojure is that by making heavy use of pure function composition, you don't actually need a million libraries to build large/complex systems. You can do it with a much smaller number of libraries where necessary and take advantage of the language's natural extensibility for the rest.
I was just reading an article earlier today on the same subject. I thought the "pedagogy" section was interesting when considering if `mut` is the right term to be using for exclusive references.
> I would strongly advise against using python for anything other than PoC/experimental endeavours.
I agree with your points, but this seems to lean a bit too far the other way. Yes, Python has plenty of limitations and cases where there are better choices in programming language. But saying that it shouldn't be used in real production systems when there are so many examples of it being used effectively for precisely that seems a bit hyperbolic, no? It's like saying Javascript shouldn't be used in production.
- it doesn't work for collaborative efforts unless everyone is using the same linter or IDE with the same configuration. Not friendly to edits outside of that ecosystem (e.g. open source).
- there are other ways of writing SQL (e.g. dbt style guide) which are still very readable while also being much faster to write by hand without the need for an auto-formatter.
- some of these patterns such as the from and join indentations have nothing to do with readability and are purely stylistic. Nothing wrong with that, but there's nothing objectively better about this pattern - it just comes down to how you're used to reading SQL.
Wholeheartedly agree with this. The problem isn't aliasing, it's lazy aliasing which is more I think what GP was referring to (e.g. emp.id instead of employee.id).
Most ML requires collecting, cleaning, and transforming datasets into something that a model can train on for a specific domain. Codex and Copilot aren't good examples of this because they are training on terabytes of public code repos - meaning that there is no code cleaning step. It's relying on the sheer volume of data that is being processed to try and filter the 'unclean' data (think buggy code written by a human) out of the model.
These are really the exception rather than the rule when it comes to collecting data for ML/AI applications.
This is right on the money. Everyone wants to do new and interesting work on a product, which naturally means changing things even if it isn't really an improvement. No one is going to put "maintained system that wasn't broken" on their resume.
One thing that has likely exacerbated this issue in recent years is "data-driven" product design. While I'm fanatical about evidence-based decision making, so many of these products are designed around a vague concept of "engagement" which is all about getting users to interact with the app as much as possible. While this is the natural end state for ad-driven companies, I find it very frustrating that a subscription-based service like Spotify feels the need to take as much control away from the user as possible.
If you're used to writing embedded code then I'm not surprised - you want to be able to fully introspect everything that is happening since understanding performance is so important.
Syntactic sugar is often better in high-level languages because it provides a level of indirection and allows for more flexibility in API design.
Mikovits' claims are bold-faced lies regardless of your opinions on the pandemic.
Probably the most hilarious claim from that video was the line: "The controversial article sent shockwaves through the scientific community, as it revealed that the common use of animal and human fetal tissue were unleashing devastating plagues of chronic diseases".
None of that is true, her [research](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3073172/) had nothing to do with autism or vaccines. Many people tried to replicate her research, which contradicts her claim that she was being shut down by the government/big pharma/the boogeyman.
The fact that people don't care to distinguish between Mikovits and someone like Tyrone Hayes just shows how easy it is for grifters to take advantage of people's strongly-held opinions about the health system. Sorry to say, but if you buy into Plandemic just because you're critical of vaccines/shutdowns/whatever then you fall into that group, and you hurt your position rather than reinforce it by buying into such garbage.
Agreed. I'll admit I didn't notice it on first pass and just thought the Jim Morrison bit was sloppy writing, but reading it again it has all the hallmarks of GPT-generated text. It even talks about the etymology of the word "elite" for no reason!
If it isn't GPT-3, then it's writing at a high school level at best and shouldn't be on the front page.