impulsivepuppet

> I think nobody would accept their manager being an LLM

this depends heavily on what is easier to do: social engineering or prompt engineering.

this isn't uniquely pythonic and JS isn't a great counterexample.

https://nodejs.org/api/esm.html#importmetamain

node also has __dirname and __filename from the good old days.

the frontend team can write a BFF to make all pages render server-side. there is an advocacy group for keeping oauth2 clients out of browsers which gives this idea some _political_ merit. in ways more than one, SPA is not the only solution when a dedicated _frontend team_ is employed.

what is often overlooked in corporate culture: if you take a step back, two coworkers refusing to cooperate, regardless of the reason, is a typical "corporate kindergarten" scenario for the manager to take care of.

To avoid rushed or incorrect decisions, conflicts intentionally move through gradual escalation. If someone behaves unprofessionally, for example by submitting a code review they do not understand, the first step is to establish the likely cause.

They may ultimately be at fault, but that does not absolve the surrounding environment. The culture may be toxic, deadlines unrealistic, or communication poor.

The best course of action for someone directly affected by uncooperative coworkers is to avoid assuming ill intent. Get them on a call and let them explain their pull request, however trivial the issue may seem. Even if the gesture is misinterpreted, you still have a far stronger position than righteous indignation.

While I circumstantially agree, I hold it to be self-evident that the "optimal amount of grift is nonzero". I leave it to politicians to decide whether increased oversight, decentralization, or "solution X" is the right call to make.

I can't help but think that this is a "I have nothing to hide" argument. It's quite sisyphean to keep accounts perfectly segregated, therefore there's always a chance that personal information can be traced back and pieced together; which, in turn, has "boring-old security" implications: i.e., now someone possibly knows your habbits and times when you are at work

Related and likely inspired by the related thought: https://www.mattmahoney.net/dc/

On the topic of working hours, flexitime is highly addicting and I cannot imagine anything that's better for a software developer. Clock in, have meetings, write code, commit, clock out. Overtime? Just leave early without asking your boss. It just makes sense. Plus, the negotiated working hours per week / working days / mandatory hours can be set to whatever value that makes sense.

Nobody is paying you to sit, people care about the working product.

I find it quite intriguing to introduce "language-native" matrices and 2d blocks (which I still find difficult to wrap my head around.)

The reason why most people would more intuitively consider a music score as multidimensional has to do with parallelism or concurrency.

In theory, nothing is stopping you from creating a hyperarray language a la BQN++ (or dare I say QRP). Maybe I glossed over an example, but having proper pointwise application to hyperscalars feels like a must-have.

Second idea is to introduce process parallelism, which could actually make this form of syntax into an execution graph of sorts--could be quite promising!

Looking at the software development today, is as if the pioneers failed to pass on the torch onto the next generation of developers.

While I see strict safety/reliability/maintainability concerns as a net positive for the ecosystem, I also find that we are dragged down by deprecated concepts at every step of our way.

There's an ever-growing disconnect. On one side we have what hardware offers ways of achieving top performance, be it specialized instruction sets or a completely different type of a chip, such as TPUs and the like. On the other side live the denizens of the peak of software architecture, to whom all of it sounds like wizard talk. Time and time again, what is lauded as convention over configuration, ironically becomes a maintenance nightmare that it tries to solve as these conventions come with configurations for systems that do not actually exist. All the while, these conventions breed an incompetent generation of people who are not capable of understanding underlying contracts and constraints within systems, myself included. It became clear that, for example, there isn't much sense to learn a sql engine's specifics when your job forces you to use Hibernate that puts a lot of intellectual strain into following OOP, a movement characterized by deliberately departing away from performance, in favor of being more intuitive, at least in theory.

As limited as my years of experience are, i can't help but feel complacent in the status quo, as long as I don't take deliberate actions to continuously deepen my knowledge and working on my social skills to gain whatever agency and proficiency that I can get my hands on

Org mode offers so much more than just syntax. You can use org files as a calendar, a todo/issue tracker with time accounting, a diary/knowledge base (zettelkasten, org-roam), as a literate programming tool (think jupyter code notebooks but for practically any programming language with org-babel), or a publishing tool (static site generator, latex/pdf export) all at the same time.

To be quite frank, Org mode is a lifestyle which existed long before Notion or Obsidian did. Saying that it has a barrier to entry is a bit of an understatement.

Having said all that, quite ironically, I've migrated over to Obsidian because I started using Intellij more for work, meaning that I don't need Emacs for its other capabilities all that much.

Since I don't often write raw SQL, I can only assume the author named their CTE `deleted_tasks` to elucidate that the query might delete multiple items. Otherwise, it makes little sense, for they intended to "pop" a single row, and yet their aptly named `deleted_tasks` ended up removing more than one!

The query reads to me like a conceptual mish-mash. Without understanding what the innermost `SELECT` was meant to accomplish, I'd naturally interpret the `WHERE id IN (...)` as operating on a set. But the most sacrilegious aspect is the inclusion of `FOR UPDATE SKIP LOCKED`. It assumes a very specific execution order that the query syntax doesn't actually enforce.

Am I right to think that not avoiding lock contention, i.e. omitting `SKIP LOCKED` would have actually produced the intended result?

I admire your deontological zealotry. That said, I think there is an implied virtuous aspect of "internet vigilantism" that feels ignored (i.e. disabling a malicious bot means it does not visit other sites) While I do not absolve anyone from taking full responsibility for their actions, I have a suspicion that terrorists do a bit more than just avert a greater wrong--otherwise, please sign me up!

I find it hard to believe that vigilance can be opted out of, unless—sarcastically speaking—you leave the company before the lack of vigilance becomes a problem.

I somewhat agree with your take but that "free lunch" is paid by a disciplined use of lifetimes, somewhat contradicting the claim of "removing vigilance and discipline by using Rust's type system/borrow checker". In my worldview, type systems are in fact a compiler-enforced discipline, but I see how productivity can be boosted once problem areas become more visible / less implicit. Problems don't really disappear, they only become easier to scan through.

There are more interpretations of "OO" than there are people, but the overall direction is that OO isn't a panacea for code maintainability, and some frameworks ahem Spring create a mental model at times so distant from OOP, that I might as well have written everything in Python. I gain nothing from having classes when one half are records and the other half are singletons.

This is mostly the case because most solutions provide more than the bare minimum of DOM rendering and event binding that a web view originally entails. Once you "accidentally" ship an entire browser inside your app, you've opened up more vectors for vulnerabilities—such is the price of humanity's hubris in attempting omnipotence.

Then second aspect is the "well-hidden" JS runtime or the general dislike of Javascript, but this point has been explained by other commenters well enough.

I resonate with skepticism for perhaps a different reason -- I just don't see how the censorship discussion is ever about helping China, when the whole discussion is "thinly-veiled" ritualistic anticommunism and an attention-stealing boogeyman that relativizes more pressing political issues, like a higher risk of another world war or the climate crisis. With so much tension in the air, I can't help but notice the sabre-rattling and retreat towards a reductionist description of geopolitics.

It might seem less credible to encounter English in a place where it’s less expected, but think of it this way: would a Yandex-developed ClickHouse database be adopted by Chinese devs if everything in it were written in Russian?

There is some merit in asking your question, for there’s an unspoken rule (and a source of endless frustration) that business-/domain-related terms should remain in the language of their origin. Otherwise, (real-life story) "Leitungsauskunft" could end up being translated as "line information" or even "channel interface" ("pipeline inquiry" should be correct, it's a type of document you can procure from the [German] government).

Ironically, I’m currently working in an environment where we decided to translate such terms, and it hasn’t helped with understanding of the business logic at all. Furthermore, it adds an element of surprise and a topic for debate whenever somebody comes up with a "more accurate translation".

So if anything, English is a sign of a battle-hardened developer, until they try to convert proper names.

blaming Neanderthals for most things is a gross over-simplification and misdirects reader's attention towards genetics. While there is some humour to it, I would be cautious of giving into unwarranted fixation towards genetics, as we no longer live in the world where it needs to be defended against Lamarckism and like.

I posit that the "runtime environment" i.e. epigentics, among other things, has a far traceable cause than the smidge of related species. The nature and consequences of autism land me to believe that it's more likely a consequence of a compiler error, although shoddy source code could be a secondary/compounding cause for it. Take Down's Syndrome as an prime example of genetic disorder, and it becomes clear why such categorization does not work for autism: autism is too broad, it describes the effect rather than cause, and I'd argue that autism is far less debilitating (pronounced) and definitely not inherited.

As a worthless junior dev, thank you for the post. I am seeing a general sentiment of reluctancy towards an introduction of yet another dubious metric in an environment where "software quality" is hijacked to mean something else.

This lead me questioning how good is it to judge a project by its age + last commit (+ project size/complexity + funding/community), as this is what I do in practice. I agree that SemVer isn't really designed to be human-readable and is a rather meaningless / deceiving metric due to divergent practices of different developers.

Don't tell the corporate about it, but using charcount/80, excluding newlines and whitespace is the _improved_ pseudoscience.

Additionally, excluding 'imports', namespacing, and other boilerplate helps too.

Written language is like the outer skin layer, a product of a living organism consisting of dead cells. Being a good translator is to have a good sense of what those organisms are.

Using Tinder as analogy for bandmate-finding works quite well, as the end goal can be abstracted away as some "intimate relationship".

Whether the mechanics of Tinder are worth parodying is another question, I need to try the app first.

Before ChatGPT, human language translation had a similar problem but people weren't as vocal about it.

What I find frustrating that it's increasingly challenging to have DeepL translate thou -> du, as this was my go-to "hack" to overcome the incompatibility of the English language due to its missing features.

To somewhat remedy the "yes man" problem, one needs to become a pedantic mathematician about posing your questions and I don't believe that LLM technology alone is capable of overcoming it entirely. As silly as it sounds, I must concede to the existence of "prompt engineering" as I can forsee the development of abstractions aimed to decompose questions for you.

A strongly-related topic would be Curry–Howard correspondence, that is to say that programs and mathematical proofs have a lot in common. Proving an assertion is chaining transformations, without managing some underlying state / side-effects.

Big difference is that concepts in Mathematics are very immutable -- it's unlikely for us to redefine what Euclidean Space is and if we find some other framework to be more useful, we'd rather give it a new name. I am inclined to say it's a difference in discipline and conventions and in the scope and span. Programmers will create more when Mathematicians will try to cram their discovery into an already packed library, rather than open a new one -- the latter happens by accident in the world of Maths.

The workplace of a programmer differs in such a way that a lot more mutation (codebase, not just variables) is going on, the work isn't purely novel, e.g. will contain mundane parts [2]. Also, contractual obligation is different from formalism and it does appear that programmers work in strictly formal environment to achieve goals while mathematicians have goals and vibe but have to become correct machinelike interpreters and conjure up a formally valid extension on the basis of accepted assumptions. Furthermore, there is a disconnect and reconsiliation between code and processes, because code resides on layers of abstraction. Mathematicians work more cleanly with abstraction because immutability allows you to do so.

Programming does toy with pragmatism because the assumption is that problems can only be discovered once a prototype is made -- an earlier version of code is the instrument that enables deeper insight and understanding of the underlying project. Math has a weird "human brain fetish" that's a bit difficult for me to articulate.

Those would be my 2cc to this discussion. I think the overall picture has become more clear about what programming and 'theory building' is, comapred to the 80s. As computation "broke off" from Math and had to reconsile with physics a bit, it's starting to enrich the parent discipline a lot more by providing avenues and interesting fields of research.

[1]: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspon...

[2]: writing LaTeX and verifying would be mundane but it isn't doing maths per se as one could get away with handwritten text, unlike programmers having to ultimately compile their code into binary and making sure all env variables are set up correctly.