Betting against what is widely considered as “expected”, “reasonable” is such a major source of profit when one can influence the income. Whether it’s a temperature sensor one can breathe on or movement of troops one can control or influence[0], the idea is the same—except in one of the above you can add “death and suffering” in addition to some unfortunate gamblers losing their money.
A depressing thought: it will only tip in favor of common good when the probability of something that we today consider “normal” becomes so small that betting on that finally becomes profitable to insiders with influence. Imagine that world…
[0] No, I’m not going to change my writing style because it is considered a “tell” of LLM use.
I don't mean to detract from your point, but regarding your footnote, you seemingly have. Unless it is in your writing style to make direct asides about how one may infer your message was procured.
I don’t expect most side-projects to be built with LLMs now. I would expect LLM uptake to be higher in the workplace (where it’s mandatory and/or people operate on the “the ends justify the means” paradigm), but outside of that there’s a higher likelihood someone is doing it because they enjoy programming and problem-solving as a process, and why outsource something you like to a black box that will regurgitate you an average of volunteer contributions (often non-consensually obtained) for some corporation’s profit?
The “it does X for you” aspect of technology is not completely without its downsides, for various values of X.
For example, take “X” to be “walking”. Do we have the technology that allows us to pretty much never have to walk? Sure. As far as I am aware, though, we do not generally favour a lifestyle of being bound to a mobility aid by choice, and in fact we have found that not walking when able in the long run creates substantial well-being issues for a human. (Now, we have found ways to alleviate some of those issues for those who aren’t able, but clearly it is not sufficient because we still walk.)
The problem is exacerbated immensely as the value of X approaches something as fundamental to one’s humanity as “thinking”.
Comparing LLMs to movement aids is an interesting analogy. Imagine a world in which they are similarly prescribed to people who legitimately need them to function, and withheld from the general public to keep people healthy and keeping public spaces nice to use.
Setting aside medical movement aids for a moment, I am reminded of places where people commonly ride various kinds of scooters on sidewalks.
There is a particular feeling of unfairness when you are pitted against essentially a small vehicle zipping past you with little warning, easily going double your speed without any physical effort from the rider. I remember seeing people in Seoul, especially older people, being startled by and occasionally having to almost jump out of the way of this sort of traffic having the right of way. I won’t lie, I like that riding those things is illegal where I am now.
Let’s talk about medical movement aids, though.
The analogy gets interesting here. Unlike the various scooters, these aids are normally restricted to average walking speed, though I imagine “jailbreaking” them is probably a thing, too.
On flip side, I know for a fact that there are places
where perfectly able people are known to ride purported medial movement aids (just for the kicks or in protest). Is this a bad thing? Who is to say whether one is disabled or not anyway? If one is physically able but buys this machine, should one have the freedom to drive around on the sidewalk? Why don’t we just do it by default? What about a flipped world where everybody drives a movement aid everywhere and only special people (Olympian athletes, weirdos, etc.) ever walk?
If one claims that an error at a railroad gate can be catastrophic and therefore FSD should be disabled in that situation, how does one ethically reconcile that with enabling FSD on any regular street with pedestrians?
The principal difference that comes to mind is that in the latter case it would be catastrophic to others as opposed to yourself: you are the train in that situation, except pedestrians have no airbags and without the railroad gate equivalent they are not made aware of taking this risk.
That’s a very interesting way to look at it! But my reasoning for continuing to do what I do is that FSD is bad at thin gates and much better at avoiding pedestrians. So it’s not an all or nothing thing for me.
Often (not always) the top bun is the worst offender, but it’s most certainly not just about the buns: if you look closely, the unique characteristic of Japanese McDonalds (separating it both from McDonalds in other countries as well as from other similar chains in Japan) is that in each photo every burger layer (be it bun, meat, lettuce, etc.) is offset by a seemingly-random factor on its X axis.
I’m sure discussions like this is exactly why they did it. Considering other chains in Japan don’t do this, it clearly has nothing with regulations (unless those are really unevenly enforced).
There are very specific reasons to use Django’s class-based views, so much so that it doesn’t really strike me as “multiple ways to do one thing”.
Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a function!
Case 2. You are working on an end project, and you want to take a view shipped by Django or some library and override bits of its behaviour. The view is already shipped as a class, and writing it as a function would be unwieldy because there is a bunch of logic you’d need to repeat. No-brainer: just inherit and go.
Case 3. You are writing a library that is intended to be customised by the end project. You ship a view that performs a somewhat complex sequence of actions as part of handling a request (e.g., validating input, constructing a query, fetching a QuerySet, serializing it in some way). You want to give the end project an easy way to borrow your view and override only specific parts of that logic. Consider writing a class-based view, and basing it on some pre-existing class-based view if possible (the above looks a bit like ListView, for example).
In my experience, your Case 2 plays out a bit differently. "Just inherit and go" and in many cases you end up with more lines of code in total than doing the same thing in my own function with some kind of helper. Even in the dead standard thing, like displaying a list of objects with pagination. But now I don't own the flow!
Any kind of customization and I need to go jump through the hoops, I need to go look at the code what exactly happens there. But this class inherits a couple other classes, and I need to go read them as well. What for? Grug not want read seven basic multiple-inherited class just to display a list of objects.
So I disagree that it's a no-brainer. It's a no-no brainer for me.
As for writing the libraries, I have the same problems with all libraries that provide class-based API, where I need to inherit from libraries' classes to do my thing.
I like my code to be stupid and linear, to own the flow, so I can read the code and understand what happens there. Same is true for agents!
I am also willing to accept some LoC penalty for my approach. But it's shorter in practice, so win-win for me.
I was using Django since 2006 up to ~2012, and then again touched in 2014-2015. Never again.
If it’s easier to just write a function view, then sure, just write a function view. I did phrase it specifically: if you want to take stock logic and just override a specific part, then CBV is a pretty intuitive way of doing it.
My point was mostly: stick to function views by default, don’t bother devising your own class-based views in an end project, maybe do if you ship a library and have carefully thought about extension points that are ergonomical for your users, and do take advantage of a pre-existing CBV if it feels like a natural, sustainable, low-LoC solution.
For example, as a default choice, if I need to show a list of items, I would in fact just write a function view. However, once I need more features (the turning point for me is probably pagination), I’d brush up on the docs, subclass a ListView, and enjoy well-tested logic taking care of things for me. In the simplest case I’d just set class attributes without overriding any methods at all; maybe I’d take over get_context_data() to give the template some project-specific variable that doesn’t make sense in context processor. If I need something significantly more custom, I’d switch back to a plain function view and use in it pagination primitives that Django exposes. Done all of the above at different times and I think it worked pretty well.
Yes, it did come with practice and I did ship some spaghetti at first, but I also was a relative noob/junior when CBVs came out.
Fine, it is subjective, so there is more than one way of doing things here, and it is not great, but I still think CBVs have their place.
> I don't own the flow
Sir, this is a framework, we don’t own the flow. (I’m slightly jesting.)
> I like my code to be stupid and linear
I am in the same boat, but to me overriding a CBV method seems pretty stupid.
I used Django for from pre-1.0 (the latest time was in 2021 and that project is still live), been to one PyCon and contributed some really minor fix or two. While I have seen hairy Django codebases, I still think it’s a very sane and the best-documented framework.
I stated that I would likely migrate eventually, but on my own schedule, perhaps mid year or autumn.
Switching the ecosystem over this is on the cards (I am being essentially handed a different machine than what I dropped off, after all), but wondering if anyone had success forcing Apple to hand you a repaired machine with the same OS, or successfully manually downgraded an MBP that came with Sequoia but got Tahoe post-repair.
Might as well pick it up. I was essentially "forced" to update to get my new XDR display running and I've learned to live with Tahoe.
Tahoe is buggier than Sequoia, but Sequoia was rather buggy already. You'll see a lot of new annoyances in Tahoe, but then it will just feel like typically modern Apple software, just with more and more iPhone UI everywhere.
The one outstanding benefit is that it will now autocomplete codes sent via text messages, just like iOS.
> The one outstanding benefit is that it will now autocomplete codes sent via text messages, just like iOS.
This is not a new Tahoe feature. macOS has done this as long as the iPhone has.
As for OP, the time and mental energy spent fighting it would probably be better spent getting familiar with the OS. It’s not that different, other than the coat of paint. It may not be on your schedule, but neither would the fight. Not picking the computer up is also more impactful to your productivity than an OS upgrade.
While not with Apple, I just spent the last 6 months trying to fight charges from FedEx I felt were in error. I wish now that I would have just paid the money, taken my lumps, and moved on with my life. The stress it caused wasn’t worth it and it’s still not resolved.
Point taken, having a new OS forced on you in the middle of work is stress but trying to fight a big corporation over this may be even more stress.
Honestly, though, after seeing the next Tahoe-only generation of Apple Silicon come out a couple of months after I bought my laptop, I was so happy thinking I get to keep Sequoia for another year.
Technically, any given technology by itself is neutral. However, it tends to amplify some human tendencies or others. Great power, great responsibility, all that.
(Depending on various definitions, to some people specifics of this amplification could warrant taking a mental shortcut and just considering that tech as harmful in itself. After all, if it is neutral and helpful under unattainable circumstances, and harmful under real-world conditions, then it is pointless to draw that distinction.)
Personally, I believe that technological and mathematical underpinnings of LLMs by themselves do not at all imply IP theft or detriment to the environment and society, but the way this technology is being adopted should raise serious questions in anyone with such capability.
Each time I see “cyber” used in a headline (so far it happened once) without any other hints that it’s about security, I am initially confused. What is wrong with the term “infosec”, exactly? Clear, logical, well-known and most widely used term to mean—you guessed it—information security.
There does not have to be a term committee or term police for colloquial use, but to me referring to somebody calling it out when terminology makes no sense as “making a stink” says something about the objector.
Cyber expands way past infosec. And that's the crux of the problem with the complainers these days. You don't understand the full picture. You've convinced yourself you do. And so you tilt at windmills like an idiot.
A depressing thought: it will only tip in favor of common good when the probability of something that we today consider “normal” becomes so small that betting on that finally becomes profitable to insiders with influence. Imagine that world…
[0] No, I’m not going to change my writing style because it is considered a “tell” of LLM use.
reply