I thought this was going to be about a car being uncomfortable to have sex in.
Such a car would make for a great product to sell to parents of teenagers, so you can lend them the car but at least make it difficult to fornicate without consent of the king.
That is high risk, don't ask people to do that, especially when it's completely unnecessary for what the language is, and the language isn't providing value, it's just esoterical.
>2. "Glupe isolates AI logic into semantic containers, so your manual code stays safe."
Watchout for light-AI psychosis. This existed before AI to be fair, but using words in a way that doesn't convey meaning. Maybe what's going on is that you use them with ChatGPT and it either understands or doesn't but follow along. So make sure to prioritize language that you develop with humans, not AI. And try to simplify your language and the message you were trying to convey, because you missed bigtime with that sentence.
>3. The language itself misses the mark. It looks like it's C++ with some modifications?
4- it's also not a language but a terminal? Try to get the trust of your users by doing one thing well before promising to do it all. A bit of humility pays off, you can't do everything anyways.
>3. The language itself misses the mark. It looks like it's C++ with some modifications?
I may have misunderstood, but my interpretation was that the "language" is really just the `$${ }$$` blocks, and the code outside of that is just written in whatever "real" (traditional?) language you want the blocks to be implemented in.
While running Doom on X is typically a show of personal hacking skills, and a display of the turing completeness/power of X,
I think that running Doom on X can also be a criticism of X, certainly the opposite of the intention in some cases. Consider a config mechanicsm, if I prove that I can run Doom on .md or .ini, or notepad.exe, most people should be concerned, not just for bloat, but for security reasons.
The value of some tech is precisely in what it cannot do, not just what it can do.
"Okay, so the reason I initially did this was because I didn’t want to pay Contabo an extra $1.50/mo to have object storage just to be able to spawn VPSes from premade disk images."
I think there's a sweetspot between " I spent 50 hours to save 1.50$/mo" and "every engineer should be spending 250K$/mo in tokens".
Host employees still need to eat, if we can't afford 1.50$/mo, then we aren't really professionals and are just coasting on real infrastructure subsidized by professionals that pay for the pay-as-you-go infrastructure.
It's still possible to go even further to these extremes, there's thousands of developers that just coast by on github pages and vercel subdomains. So at least having a VPS puts you ahead of that mass competitively, but trying to save 1.50$/mo is a harsh place to be. At that point I don't think that the technical skills are the bottleneck, it's more likely that there's some social work that needs to be done, and that obsessing over running doom on curl is not a very productive use of one's time in a critical economic spot.
I write this because I am in that spot, but perhaps I'm reading a bit much into it.
That sounds like something I would've done... When I was a kid, the 5€/month for a VPS was a massive expense, to the point where I occasionally had to download my 10GB rootfs to my mom's windows laptop, terminate the instance and then rebuild it once I had enough money. Eventually I got an old Kindle that was able to run an app called Terminal IDE which had a Linux shell with some basic programs like busybox, gcc. Spartacus Rex, if you're out there, thank you for making my entire career possible.
And I think this point is heavily under-appreciated in the cloud Vs. on prem debate.
The cost for 1 hour of cloud CPU time is the same (barring discounts), no matter who you are. THe cost for 1 hour of engineer time varies wildly. If you're a non-profit or a solo dev, you may even consider that cost to be "free."
If your engineer costs are far lower than what AWS assumes they are, going with AWS is a stupid decision, you're far better off using VPSes / dedicated servers and self-hosting all the services you need to run on top.
The author did write that, yes. But it's very obviously a joke. The real reasons are literally the very next paragraph:
> I thought it was a neat trick, a funny shitpost that riffs on the eternal curl | sh debate. I could write a blog post about it, I tell you about how you can do it yourself, one thousand words, I learn something, you learn something, I get internet points, win win.
> it's more likely that there's some social work that needs to be done, and that obsessing over running doom on curl is not a very productive use of one's time in a critical economic spot.
It can be a problem but it can be also just a human following their special interests that give them joy.
For me as a ADHD person engaging with my special interests is a hard requirement to keep my mental health in check and therefore a very good use of my time.
> if we can't afford 1.50$/mo, then we aren't really professionals and are just coasting on real infrastructure subsidized by professionals
This is a strange claim.
Whether someone is getting paid or not to do something is what determines who is a professional, not whether or how much they're paying someone else. (And that's the only thing that matters, unlike the way that "professional" is used as a euphemism in Americans' bizarre discursive repertoire.)
I think the sense of the word professional here is not as a boolean professional/amateur, but the sense of professionalism, the characteristic of taking business seriously, not letting personal matters intervene, and in this case, investing into tools.
To put an example, suppose you hire a painter, and they show up with non-work attire, no ladder, no brush, they ask you to buy a can of paint for them and a brush. Compared to a contractor that bills you flat and brins their own ladder, has work clothing and shoes, an air pneumatic spray painter, a breathing mask. Who is more professional?
It's part of a broader debate for sure, OP seems to have done it more for the experience than to actually save 1.50$.
It always depends on results. It can be unprofessional to design a system that takes an external variable like S3 for granted, especially if it's not needed. As long as the hack isn't worse than the official $1.50 happy-path, you might as well save the end-customer a monthly fee and reduce your attack surface.
I think hacks like these have a positive effect on the industry. It pushes back on meaningless, encroaching monetization and encourages Conatbo to reevaluate their service offerings to ensure they justify the price.
Nope. There's no broader debate. "Professional" means "X is getting paid for this", not "X is paying something in order for X to be able to do this". It's that simple.
> To put an example, suppose you hire a painter, and they show up with non-work attire, no ladder, no brush, they ask you to buy a can of paint for them and a brush. Compared to a contractor that bills you flat and brins their own ladder, has work clothing and shoes, an air pneumatic spray painter, a breathing mask. Who is more professional?
Literally meaningless. Are both getting paid? Yes? Then they are both professionals.
You can insist on using "professional" in a strained way to try to facilitate some attempt at being judgmental and gatekeepy, but "professional" means what it means. If you mean something else, then say what you mean and leave out the euphemisms.
You can't just conveniently ignore that "professionalism" is a concept that exists and is pretty clearly what the original author meant based on context and content. Refusing to interpret things in the most plausible manner just wastes everyone's time.
For example the phrase "unprofessional professional" means a professional (ie getting paid) who is behaving unprofessionally (ie exhibiting a lack of professionalism).
There's no ignoring it. It was raised pre-emptively in the very first comment: "the way that "professional" is used as a euphemism in Americans' bizarre discursive repertoire".
> the phrase "unprofessional professional" means
That's just an oxymoron.
> a professional (ie getting paid) who is behaving unprofessionally (ie exhibiting a lack of professionalism)
A professional who is getting paid, the (only) necessary and sufficient condition for being "professional", is by definition exhibiting professionalism. That's a fact, and it's not any more complicated than that.
Why not bother to check a dictionary before responding? Your "raised pre-emptively" was nothing more than you being preemptively wrong. It can be used as either a noun or an adjective and has multiple well established definitions for each. You are fixated on one of them.
I'm not hiring that plumber again as he was rather unprofessional.
Your attire doesn't look professional.
> ... is by definition exhibiting professionalism.
Nope, wrong again.
I found the lack of professionalism during my recent visit alarming.
... I think you're reading a bit much into it. It's less that I couldn't afford to pay that, and more that I didn't want to pay that, and iterating on the solution I used to dodge that led me down a giant rabbit hole of learning more about Linux while solving stupider and stupider problems posed for myself.
I really get that, and I value these otherwise pointless hack articles as much as the next guy. But I think I was specifically getting at the fact that these might actually turn into an economically useful skill just by finding a sweetspot in the amount of money they can save.
1.5$/mo is still in the toy realm, (and games can be very good for practicing before the real stuff), but using tricks like this to save 50$/mo or 500$/mo or 5k$/mo or 50k$/mo and so on can definitely cross the threshold into actually (massively) useful.
The biggest challenge in crossing that bridge is matching up clients with bad engineers but good budgets, with good engineers with no budget. There's probably thousands of engineers that are currently spinning 5$/mo into impressive architecture for their blog or their 2 user startup, and clients throwing buckets of cash into tokens and zapier/n8n. The world needs Cupids that match those together.
Modern software regularly takes like 1 second to load anyways.
200ms is the minimum human reaction time, so adding 100ms would only add like 50% to the REPL user interaction. Something like 10Hz might be quite usable while minimally contributing to lag.
The idea of having a 60Hz screen is nice, but in practice it turns out that display refresh rate is not the bottleneck for most software.
I've seen something like this before, here's the Argentina constitution as a git repo, with reforms as commits. Much shorter in scope, but this was pre LLM coding
Most agricultural plant had a "Lucas key" [1] which meant you could use any key to start any machine.
I used to have one on my house keys long after I actually needed it, kind of an agricultural/industrial shibboleth. It's also how many many years ago I came to be drink-driving an eight tonne excavator through streets of Glasgow at 3am, with some rather grateful Strathclyde Police traffic cops keeping my way clear, but that's a whole 'nother story.
I used to have a keyring with the dozen or so different keys we have for network and equipment cabinets. One day I left it at home, and when I got to site realised that the cabinet was almost certainly one of the ones I didn't have a key for anyway.
I pulled the thin stainless strip out of an old wiper blade I'd thrown into the boot of my car to put in the bin later (and six months later, still had not), chopped two lengths of it, bent one into an L-shape and filed the little notch at the end of the other a little deeper and rounder. At some point muuuuch later I welded a little stainless washer to the ends of them both to put it on a keyring.
Yes, it was quicker and easier to just rake the wafer locks in the rack than find the right key.
Nice feature. However uv is suspect at the moment, in the sense that it is designed as a pip replacement to overcome issues that only exist when supply chains are of a size that isn't safe to have.
So any project that has UV and any developer that tries to get uv into a project is on average less safe than a project that just uses pip and a requirements.txt
It is a bit of a leap. They are saying that if you are using uv, then you likely have a broad set of dependencies because you require a dependency management tool, therefore you are more susceptible to a supply chain attack by virtue of having a wider attack surface.
Ahhhhhh thanks a ton. Now I get it. Meaning I get what you are saying. Not what they were implying. But yeah. I can understand at least how one could arrive at that idea.
To me personally this idea still sounds a bit off - but as a heuristic it might have some merit in certain circumstances.
I really am not able to follow this line of reasoning, I am not sure if what you said makes sense and how it relates to uv having a security feature to be on average less safe :/
I believe they are saying that by the time you need something like uv, your project already has too many dependencies. Its the unnecessarily large supply chain that's the problem, and uv exists to solve a problem that you should try to avoid in the first place.
I think uv is great, but I somewhat agree. We see this issue with node/npm. We need smaller supply chains/less dependencies overall, not just bandaiding over the poor decisions with better dependency management tooling.
I agree with it that dependency management should be made easier. To be honest, I really like how golang's dependency and how golang's community works around dependencies and how golang has a really great stdlib to work with and how the community really likes to rely on very little depenendencies for the most part as well.
Maybe second to that, Zig is interesting as although I see people using libraries, its on a much lower level compared to rust/node/python.
Sadly, rust suffers from the same dependency issue like node/python.
This line of thought is honestly a bit silly - uv is just a package manager that actually does its job for resolving dependencies. You’re talking about a completely orthogonal problem.
> uv is just a package manager that actually does its job for resolving dependencies.
Pip resolves dependencies just fine. It just also lets you try to build the environment incrementally (which is actually useful, especially for people who aren't "developers" on a "project"), and is slow (for a lot of reasons).
The (not very convincing, IMO) argument is that pip becomes unergonikix for a certain dependency tree size leading people to use uv instead. Of course that's not the only or main reason people use uv, presumably.
Such a car would make for a great product to sell to parents of teenagers, so you can lend them the car but at least make it difficult to fornicate without consent of the king.
reply