klibertp

> wow, i guess you got hooked :-)

Maybe a little :D REBOL line of languages has been on my radar for a long time - I've been a PL nerd for 20 years now - but I always found reasons not to engage with them. So it was a bit of a blind spot: I knew some basics, considered it a pretty elegant and powerful design, but the REBOL3 fiasco, the proprietary nature of REBOL2, and the various facts about Red (pivot to it being a "blockchain native" solution was painfull to watch, dependency on REBOL2 for the toolchain/no self-hosting after almost 15 years in development, etc.) made it hard to dive deeper into the language(s). I had some time yesterday, and your comment touched on something I'm already interested in (interactive CLI/universal REPLs), so I took the opportunity to finally learn more about the language.

> i am not actively trying to create a new shell, but i am exploring languages for their potential to design a shell language without having to reinvent the whole syntax from scratch.

As for me, I tried making shells a few times. All those failed, of course, mostly because I wanted to do something a bit different: a text-based computing environment with network transparency, basically a single-player MUD/MOO that would treat the filesystem as a world. I got quite far with Smalltalk - but GNU Smalltalk that I based it on collapsed under me :( I tried Elixir, Io, and Python, and all would require much more work than I was willing to put in. A pity, because I think that would be the best possible environment for LLMs/agents... I'm still thinking about this idea often, and I started working on a new implementation, using Pharo Smalltalk/GToolkit. Parsing is the easier part, actually: it's the liveness of the whole thing (hot reload, adding functionality from within the environment, mapping the environment back to source code, etc.) is the part I had the most problems with, and Smalltalk seems like the most promising platform for implementing it.

> I think GP is confused why the ftp command also handles http(s) :)

Exactly - I even suspected for a second that `ftp` on NetBSD is something else entirely, not an actual FTP client with HTTP/HTTPS URLs bolted on. It's not - it still accepts a host as an argument and opens a CLI if there's an FTP server to talk to.

Installation instructions:

    ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/setup-env.sh
       !^^^^^!

That's... a bit unorthodox. FreeBSD has a `fetch`[1] utility for this, I wasn't aware NetBSD puts that in `ftp`[2].

Interesting choice. I wonder what led to it.

[1] https://man.freebsd.org/cgi/man.cgi?fetch

[2] https://man.netbsd.org/ftp.1

It looks like it works only on function bodies[1]. I'm not sure I understand why you would want to look at invoked callables code, though. Calling the same set of helper functions is already flagged; repeated code in helpers is flagged as well when those helpers are analyzed. Do you have a specific example where you'd like a function flagged as a duplicate based on the code it calls out to?

[1] https://github.com/rafal-qa/slopo/blob/main/src/slopo/indexi...

Correct me if I'm wrong, but looking at [1] it seems to be specifically using function definitions (I'm guessing this works with functions, methods, and lambdas (the "<unknown>" part)?) as units of repetition. If yes, that's fine, but I would seriously consider adding some settings to allow the user to control that granularity. Sometimes, the repeated code is a conditional branch within larger functions (i.e., "every else:" or "every except Ex:" looks the same). If the functions are large enough, the dissimilarity of the rest of the body would (probably?) cause such things to be missed.

I would also consider - perhaps as a separate pass, with scoring set differently - to analyze comments (especially docstrings in Python). If I read the code correctly, you're currently just stripping them, which is the right thing to do when looking for code duplication, but duplicated docstrings are also often a signal that something is wrong in the codebase. The "different scoring" is because we expect docstring to be structured similarly (at least more than normal code), so some tweaking would be needed.

Finally: very nice project, congrats! :)

[1] https://github.com/rafal-qa/slopo/blob/main/src/slopo/indexi...

I tend to follow the "rule of 3": a second similar implementation is OK, introducing the third triggers a refactor. As with everything, this isn't dogma, and sometimes the second implementation is already too much, while at other times you get tens of similar code sections (in codegen, repeating patterns with almost no changes is a virtue). But it's a good rule of thumb.

On testability: two implementations can be tested against each other, leading to greater coverage with less test code. It doesn't work that way for 3+ implementations, which is another reason not to have that many.

I had a bit of back-and-forth with ChatGPT about the possible implementations[1] - it shows how little I know about Red, unfortunately, but we came to this representation:

    shell [
        var: [cmd1 arg --switch arg2]
        [cmd2 :var]
    ]

as a general shape of the DSL. The need for a separator goes away (and simplifies the grammar a lot) if you require commands to be nested blocks. :var works for interpolation, because it's loaded as get-word! - trying to cram $var there wouldn't work (that's a syntax for `money!` - only digits are accepted after `$`), but if you want A shell, not BASH specifically, I think you can get away with some syntactic changes. I checked some of the things the model proposed in the REPL, and they mostly seem to work. Subshells and piping would probably require more work in this setup, but it should be doable.

Again: really interesting language and seemingly a good fit for an internal shell DSL. It's also trivial to make files written in this DSL execute as scripts. I might have jumped the gun a little with my "why would you" question at the start :) Personally, I would still seriously consider Io, but that's just a familiarity bias: I spent a year hacking Io internals, while I know little about Red.

[1] https://chatgpt.com/share/6a469cbb-1754-83eb-94b8-14bef67735...

Ah, yeah, that makes sense, then.

I tried writing a shell in GNU Smalltalk, but had to mess with the parser - otherwise, the need to parenthesize subexpressions makes it really tedious. I implemented |> as a pseudo-operator that implicitly parenthesized everything before it, which was then removed from the expression. It worked for many simple cases, but wasn't pretty and quickly broke down for more complex ones.

I think the only other language worth investigating in this context is Raku. I avoided it for a long time due to its PERL ancestry, but it's actually a pretty well-designed language, and supports multimethods and overloading of pre-/post-/in- and circumfix operators. The operators support precedence and associativity. If you want an embedded DSL for shell one-liners, I think Raku could deliver. It unfortunately uses the comma for argument separation; you could maybe work around that with quotations and macros, but last I checked, these were experimental and not documented. There was a major effort to move to a better-designed parser that would support AST-based macros, but I'm not sure how far along that is today.

Io would work, though you'd also need to mess with a parser a bit (it's runtime-extensible, though, and also allows circumfix operators and passing unevaluated code as Message objects, which is very helpful in this case). Arguments are normally in parens and comma-separated, but you can simply ignore that. This: `some command --with arguments` is actually a valid Io expression (if `--` is a prefix operator), and since you're not evaluating the code, it doesn't matter if it doesn't make sense semantically. But Io is not very actively maintained (a shame!) It's still a very interesting design. It's described in "Seven Languages in Seven Weeks", if you want a quick intro.

Prolog would probably work, but you'd need to write a metainterpreter - otherwise, threading state in/out of predicates through logic variables would be a nightmare in the CLI. There's also the issue of commas as separators.

You know of TCL, so no need to mention it, though it is a pretty nice fit. A more exotic direction could be concatenative languages: maybe Factor, or Joy, or Kitten. All either experimental or unmaintained, currently. They tend to use whitespace for a separator, and I think they all allow for passing around unevaluated code one way or another.

Looking at the list - Red does look like one of the better candidates, but in normal Red code, all functions know their arity. This means you don't need separators for expressions. It doesn't work that way for shell commands, so you'd probably need to write a Parse grammar, include a separator to allow for variadic commands, and then, after splitting into subcommands, interpret the block command by command. I'm sorry, I'm not too knowledgeable about Red, so I can't give you more details, but that should be the general shape: `shell [ var: cmd1 arg --switch arg2 <some_separator> cmd2 <some_symbol>var ]` where `shell` passes the block to parse, gets a list of commands (including ones that bind results, which would appear as `var_name,command` pair; also, I think path expressions can be used in assignment, so `var/stderr: some command` could be included and handled easily), then walks through the list while setting vars and interpolating them in the following commands. Handling piping wouldn't be much harder than extending the Parse grammar and handling pipelines in the interpreting phase. Finally, you could add refinements on shell for simpler cases (just return exit code, capture all output, etc.) Subshells could be just nested blocks. Thinking about it, it could be a pretty fun way to learn more about Red. Ping me if you end up creating something like that, I'd be very interested to read :)

> btw, your website seems to be down.

I know - I broke my homegrown SSG some time ago and never had the time to fix it :( EDIT: restored some version of the site, 90% of the content still missing.

All that shell scripting needs is the ability to spawn processes and connect their stdin/out/err together. Or at least, that's what distinguishes "scripting" from "shell scripting". Obviously, you can write a library (I like Python's Plumbum) in almost any language you like that provides this functionality conveniently. So, again: yes, Red can be used for that just as well as any other language (and, arguably, it may be better for this use than many others).

For an interactive shell, you also need a REPL, which Red provides. So if you write that library for Red, you get the interactive shell for free.

Yes, Red has many advantages: it can AOT compile to native, it's homoiconic, it has a built-in Parse dialect (so the library can be really ergonomic), the Red executable is tiny and starts up fast, it has native GUI capabilities (if you're in a Red-based shell and want to view an image, it's trivial to create a GUI window and display it there). I'm not saying Red would be a bad choice. I'm just not sure it would be my choice, given the existence of, e.g., Chicken Scheme or Smalltalk/X.

Not sure why it wouldn't be usable for that:

    -▶ ./red-cli-066
    --== Red 0.6.6 ==--
    Type HELP for starting information.

    >> call/console "echo 123"
    123
    == 0
    >> call/console "pwd"
    /home/cji/portless
    == 0

`call` has a bunch of refinements (toggles or switches appended to the function name with a slash; I'm using /console to redirect output to the parent's stdout), but it's a pretty low-level interface. You definitely could define a few simple helpers and get to a usable Unix-like shell pretty quickly. You'd get native AOT compilation for all your shell scripts for free.

The problem is that you could write those helpers in just about any language, and while Red has an edge over many due to the regular and simple syntax, it's by no means unique in that regard (TCL is an obvious alternative, Lisp-likes are also strong, and even Smalltalk could join the chat if you don't care too much about startup time). And 32-bit-only thing doesn't look good, even if it's not an actual problem in most cases.

In short: it can, but why would you? (Don't get me wrong: I like Red! But with so many other interesting languages (if you're willing to look past TIOBE Top 20), it's hard to justify investing more time into learning Red in particular.)

> Have you seen Zardoz?

Oh, yes! Just once, but Connery, in just underpants and boots, battling some surreal head-shaped apparitions, is something I won't ever forget. I have no idea what the plot was about - but that's OK, because I had no idea about that either during or just after watching :D

A movie so bad it's kind of good - though second-hand embarrassment (at the performances, effects, plot, characters) was a bit hard to bear at points.

> How pessimistic you are on this subject depends on how much you believe in domain transfer for these tools.

I tried to force various LLMs to generate many strange languages for the past 3 years. From Raku to Smalltalk, to Common Lisp and Janet, to Prolog, D, Nim, Zig, Elixir, F#, etc.

It's a mess.

They do a mostly good job with language semantics. Agents can also use standard tooling to catch and fix syntax errors. So far so good, though if a given language provides an unusual implementation for a popular feature, the model can get confused. It's usually easy to spot.

The problem is with the ecosystems. They tend to be tiny, and for new languages, they will be tiny almost by definition. As a result, the vast majority of the generated code either reimplements things from scratch or hallucinates dependencies. Since the agents iterate and the hallucinated deps don't materialize, the model fixes that... more often than not by writing from scratch. Or leaving a `// TODO:` comment.

What I found helpful is straight-up vendoring deps as submodules. Armed with grep and sources, they are much more likely to produce working code. But that also means you still need to handle the dependencies yourself, while it'll "just work" for a Kotlin/Gradle project.

It doesn't matter for all projects to the same degree, of course, but it is a pain point that will add to the difficulty (sky-high already) of a new language getting any traction, unfortunately :(

That other post is just plain wrong. LLMs are just about the only thing that can meaningfully benefit from having access to almost all the code your environment is built from. If you're on Linux, the agents not only have all that code accessible in web search, but also almost certainly include most of it in their training data.

If anything, agents are an opportunity for the "Linux year on the desktop". Granted, I don't personally believe Linux needs to have that year; it's just fine without any mass adoption there. It's simply no longer that important a segment. I thought most of the debate around that also died out years ago (perhaps even a decade?)

Still, I recently had the opportunity to compare how Codex configures macOS and Fedora for the same task, and the latter was a bit faster and significantly cheaper (in tokens). That's obviously anecdata - maybe the particular task was overrepresented on one side or something - but I wouldn't be surprised if this was a more general trend.

You're probably not paying nearly enough? IDK, but pricing in tech is stretched on both ends (either way too cheap, or incredibly expensive) so much that it's hard to say anything for sure just because one is a "paying customer".

Too late to edit, I watched the talk. Really well-researched and entertainingly told story.

I'd say games are a bit special, though. Smalltalk works pretty well in interactive applications - while it's true that encapsulation is an important part of the language, it also provides all the tools to pry objects open when needed. Out of the box, it's much better at that than C++. The problem is that video games demand very high performance, and Smalltalk is even slower than normal when you use reflection. If not for that, it's perfectly doable (if not very convenient) to treat a Smalltalk image as a soup of data with behavior attached. Casey also mentioned the focus on education in Alan Kay's projects: it's probably one of the reasons Smalltalk is largely devoid of modules, namespaces, packages, and even files with source code - things that are very useful when collaborating in teams, consuming external dependencies, etc. There are Smalltalk implementations that provide those, but they're either very niche or very niche and extremely expensive... And still slow.

Still, interactive software that doesn't have the performance requirements of games is definitely more convenient to write in Smalltalk than in C++! I have high hopes for GToolkit, I just need to port a few ideas from VisualWorks and figure out how to actually set up a project structure friendly to external agents (the GT agent harness is very nice, but it forces you to use an API, which is way too expensive for the results you get...)

This comment was dead for some reason; I vouched for it. Casey Muratori is a well-known developer with a GUI/game engine background, which gives him a valuable perspective on OOP. In both domains, OOP is both popular and problematic, and his experience suggests that he might know what he's talking about. I didn't watch the whole video, but from the description and intro, it seems to fit the discussion we're having here.

> Lua as implemented by LuaJIT is a fork of the language at this point.

Lua is strange. Lua 5.2 was more of a "fork of the language" than LuaJIT, at the time. 5.3 and 5.4 (especially the latter) changed even more. Lua looks like a family of languages, and it seems to be by design. It probably makes sense in the "embedded scripting" space. Lua is not really meant to be (though it obviously is, if you want) a general-purpose language. It's meant for extending other apps, and scripting engines have different requirements than other language implementations: basically, hardcore backward compatibility. But it's impossible to evolve the language and innovate in its design if you commit to that. This is still an academic project, so hardcore backward compatibility is unlikely to be something the authors would value. Hence, the mixed model - every major version is a new "take" on the language. You're expected to pick a version when you first need a scripting engine, and then sit on that version until the end of time. Meanwhile, PUC releases new versions of Lua, and new projects pick those newer versions (and then sit on them forever).

It looks strange, and it has important downsides (a fragmented ecosystem, huge PITA when trying to write portable libraries, so fewer libraries in general, etc.), but it does seem to work in that Lua still exists and, project after project (not within a single project), it continues evolving.

This:

    var ary = [1,2,3,4]; //Array style declaration, syntax sugar for {}

Is not a good idea. I tried using Haxe with Lua target at some point - the mismatch between what you think you get with [], and what you actually get in Lua, requires either a lot of boilerplate (Haxe compiles [] to Array objects), or a chronic WTF from all the new people reading your code (and from yourself, after a few weeks to months of disuse). If you want [1,2,3], make it behave more like an array - or just leave it out, would be my advice. Lua doesn't have arrays, and adding syntax that suggests it does will be a permanent footgun for your users, I think.

> but then that means other companies would appear in those other countries offering the AI inference service.

That might actually be the goal. A more fragmented market would mean each participant has less money, so they would try to watch their costs a bit more closely. The innovation rate (in non-cost-cutting areas) would probably decrease, maybe even substantially... which some people happen to consistently advocate for. A lot of lost efficiency would be reclaimed in a few years, but the whole system would be more stable, cheaper, and less centralized as a side effect.

Yeah, it would be suicidal to do that when it's your budget that gets the taxes from those giant corporations; who would want to willingly reduce their income for years? The rest of the world would benefit tremendously, but it could be a net plus (socially, politically, if not purely economically) in 5-7 years down the road - even in the country currently benefiting from the corporations the most. But that would be one to two lost elections too late, even if it turned true. So, while it won't happen, if it did, I don't believe we'd be worse for it.

It happens; sometimes it's a misclick, sometimes some automated filter. You can 'vouch' for such comments if you go into that comment's details: https://news.ycombinator.com/item?id=48671561 - in this case, a combination of a new account and maybe posting too quickly could have caused it. I vouched for it, and it should be visible now.

> how do you handle that

It looks like (please correct me, OP, if I'm wrong) it works the other way around: you use sized int types in Nimic code, and their semantics are emulated on the Python side. See here: https://github.com/dima-quant/nimic/blob/main/src/nimic/ntyp...

So I'd say in Nimic Python you get Nim-style integer emulation when run from Python, keeping both paths consistent with each other - but breaking consistency with the rest of Python. Which is OK, I think, given it's explicitly a subset(s) of the language(s). It would be possible to make `int` transpile to some BigInt Nim implementation, but you'd need an external dependency for this, as they are not in Nim's stdlib. However, in the speed-focused context, I'm not sure if defaulting to BigInt every time the compiler sees an `: int` annotation would work well. It's a hard decision to make. Curious what's the OP opinion here?

> That, or maybe you could adjust your worldview, and realise that religious fanatism has been a pretty strong motivator for atrocities throughout history

But I do agree! I'm not trying to say that religion (and culture, more broadly) is not an enabling factor or even one of the important causes for terrorist attacks.

What I'm disputing is the assertion that religion is the sole cause, and the attacks would continue with the same intensity if the policies in the attacked countries were to change.

As I mentioned before, that wouldn't eliminate all the attacks: if your culture is fundamentally incompatible with some other culture, which also praises martyrdom, chances are you will get attacked by religious fanatics motivated by their beliefs. That's the case for Sweden. Germany and Britain sent troops to ME multiple times in the past 20 years alone, at the behest of USA, so they get both the religious fanatics and "freedom fighter" kinds of attacks.

Again, I'm not disputing that some cultures, faiths, and populations have a higher probability of resorting to terrorism. I'm not saying that GTFO of the ME would solve all terrorist attacks. However, I believe the imperialist policy is one of the reasons people try to blow other people up, and that dropping said policy could, in a few decades (!), result in the lower attack rate.

That's all; I'm not trying to say religion (particular kinds of it, especially) is not a factor. It most definitely is. As I mentioned, the sectarian bloodshed is very common and often takes the form of terror attacks. You will always get religious fanatics trying to kill others because they don't fit into their doctrine. However, the foreign policy does matter, and you can reduce the rate of attacks greatly by not antagonizing people who are not religious fanatics, but would still want to blow themselves up to "save their nation", to "reclaim sovereignty", to "destroy the occupiers", and so on.

So yeah: religion is, for sure, a risk factor. But so is foreign policy, and my argument is that the policy is the bigger factor and the one that is much easier to adjust. To get rid of religious-motivated terror attacks, you would need to become Iran (and that wouldn't work: you'd just get Christian terrorists!); to get rid of "freedom fighter" kind of attacks, you just need to stop forcing your way into countries half a world away.

> By historical standard, over the last 10000 years prosperity, democracy and peace have hardly been the norm, don't you think?

Agreed! From my own reading (not a specialist), for example, in Europe, there were only a handful of years (literally) between 3000 B.C. and ~1950 A.D. when there was actual peace on the continent. Wars, rebellions, coups, civil wars, uprisings - every single year for five thousand years there was bloodshed, the borders moved, cities perished, populations starved, and so on.

And yes, this happened both when an empire/global power existed and when none was around. And yes, the Pax Romana (and similar periods) did bring many benefits to the world. At the same time, though, all the empires always incited hatred among the groups under them: the Romans bloodily suppressed quite a few uprisings even during that "Golden Age" (which you know, since you mentioned "zealots" in a previous comment). They wouldn't need to do that were they not an empire, which is my point.

> The pilots who flew planes into buildings 25 years ago were saudis, Saudi Arabia was never part of a western Empire. They trained in Afghanistan which was never part of a western empire (Alexander the Great does not count).

The terrorists don't need to be "part of empire" to feel threatened by that empire. Putting soldiers on the ground, for any reason, half a world away, while demanding special treatment for the troops, assuming their country's jurisdiction naturally follows their citizens in other nations, and so on - just one of those is enough to be seen as an imperialist power by the locals. The USA did all of these and more throughout the world, but especially in the Middle East. They didn't have to act that way, but they did, as it's natural for empires. The violent backlash locally and terror attacks at home are just normal, expected reactions to an empire acting like one. It's also worth noting that the entire Middle East is a fallen, fractured Empire. I'm not sure how much that influenced things, but I can imagine it fueled some ambitions in countries like Saudi Arabia to build another Ottoman Empire, this time centered on Riyadh. (Just a guess - I'm not well-versed in post-Middle Age history of the Middle East.)

> They were able to strike the American empire because, contrary to the common political discourse on the left, the American empire is a rather open and benevolent hegemon by historical standard

Agreed. Though I'd say whether an empire is open and benevolent or strict and brutal doesn't influence the number of terrorist attacks. Yes, if you're benevolent, the hatred may be less prevalent - but then your security is weaker, so you can have the same number of attacks even with fewer "freedom fighters". The issue is being seen as an empire: as long as you can be cast as one, some people will hate you automatically, even if, all things considered, you're actually pretty tame and even beneficial to others.

> I am not apologizing the American empire, I am not even american nor do I like the culture that spews out of the US, especially these days, but one has to put things into historical context if we are to understand the nature of terror attacks.

If America is not attacked by terrorists because it is an empire and acts like one - then why? That's what I don't get in your argument. If the USA didn't maintain military presence across the region (ME), didn't wholeheartedly support the "Zionist regime" (which also acts like an ethnocentric empire - Aztecs come to mind as a comparison), didn't historically meddle in the region's politics by both carrot and a lot of stick, etc., would they be hated enough for people to suicide bomb them?

Apparently, 90% of the terror attacks happen in the context of local instability (a civil war, rebellion, uprising, coup, etc.). You really need something special for the foreign terrorists to be willing to travel half a world just to blow themselves up on your doorstep. If it's not the imperialist policies, then what is it? If I understand your argument correctly, it's all religious fanaticism? But then, why would those fanatics attack the US, instead of enjoying some jolly sectarian bloodshed locally, like they did for centuries? There are enough religions and sects in ME to fuel terror attacks for a few more millennia, I'd guess, and it's not like that infighting stopped completely. How come the US was added as another traditional target for "death to ..." calls? I don't think it would happen without America's heavy involvement there...

> The typical "They hate us because our bad policies" does not explain why every empire (western or not) has had to contend with dissenters

It's interesting that you actually wrote down in this sentence the very explanation you say doesn't exist. It's pretty obvious: instituting an empire is the policy others will hate you for. The fact that you can't imagine this despite spelling out the facts yourself is curious.

Not being an empire is an option, too. That won't save you in all cases, especially if you're seen as a fallen empire, another empire's lackey due to alliances and dependencies, or your culture is simply incompatible with some other culture that happens to be frequently in contact with you. But it will reduce the likelihood of a convincing narrative - one that could lead people to hijack planes and fly them into buildings - emerging.

It's not a topic that can be fully discussed in HN comments, as there are many complexities involved, but "They hate us because we decided on a policy to be an empire" is not that far from the truth, I think.

About as many as bad terrorist groups that began due to catastrophically bad decisions of leaders in the West. I'm sorry to break it to you - the plural you - but all the terrorists that are not traditionally domestic (local leftist/rightist extremists are everywhere, after all) - and the fact they are against the West - is simply a consequence of Western politics. Imperialism and neocollonialism are real, actual policies, and it doesn't take a genius to realize that. If such policies hit locales where it's not culturally wrong to die for a cause, it's obvious you'll get terrorists after a while. I suspect this was calculated risk until it stopped being that: the locals got their own exploding sticks and decided to use them.

It's so incredibly sad to watch: for decades, tons of people made mostly rational (from their point of view) decisions, yet each step inevitably brought us closer and closer to the current situation. Add a few cultural, social, and personal pathological cases into the mix, and what you have is basically a speedrun to 9/11.

Note that I'm not justifying terror attacks, just saying they are a very predictable consequence of decades of policy-making.

A singular human does (or tends to). Humans as a group, where members join and leave a group with time, also do learn, but at a much slower pace - over the years to decades timeframe. "X things programmers should know about Y" is a template for quite a few very influential blog posts, yet for most of them, you find many programmers, even decades later, who don't actually know what they "should".

My experience was always that 90% of code is ugly and clunky. I'm not at all surprised, while reviewing AI-generated code, to see many of the same ugliness we regularly commit. The quality of the output code is now consistently average, which means it's basically shit in 90% of cases, but it tends to mostly work (in the general case). The same kind of shit I've seen people push to production thousands of times in my career.

We don't fully know how to write good code. We don't really understand what good code should objectively look like. Spending more time on code doesn't automatically lead to better code (but costs a lot more). Above all, we don't need good code - the business side is perfectly fine with "good enough right now" rather than "maybe a lot better half a year from now". And that's what the models are trained on. They would, indeed, need quite a lot of "emergent properties" to go from that to consistently good code. ASI-level properties, I suspect.

When I first tried to get a job, I listed three categories of skills: the ones I'm very confident in, the ones I have some experience with, and the niche ones I only dabbled in. The overwhelming advice, from everyone around me, was to never-ever admit that I'm not perfect at something. I found it perplexing, but after a decade or so, I started having to read resumes, and, indeed, I found almost nobody ever admitting they're not an absolute wizard at everything they put on their resumes. Before starting work at a company, I had this naive idea that HR and candidates are there to help each other, and that approaching it with honesty and goodwill is how it should work. Needless to say, it doesn't work that way at all - on both ends. I'm honestly frightened that I will maybe have to go through the hiring process again at some point, especially since my career turned adult and now my "years of experience" are a dead weight of "you're just old"... The whole process is so antagonistic, so brutal and stressful, that I can see myself going full YOLO and just spamming AI-slop resumes until I get an interview, in which - I want to believe - I'll be able to actually say something about myself and, hopefully, convince the interviewer that I can do the job. I know that would have made the whole situation a bit worse (and I'm sorry if I end up resorting to strategies like that), but the emotional burden of dealing with the "hiring process" before an actual face-to-face talk is so great I don't think I could bear it for long.

> Whatever the reason, it's very easy to assert a candidate competency with a 30 minutes to an hour interview in person.

It's not always that easy. Yes; there's a fraction of programmers who cannot code, and yes, it's usually possible to tell them apart with a FizzBuzz-style question. However, the vast majority will have some skill, and testing the limits of that skill (again, assuming we can't just expect the candidate to ever say "no, I'm weak in this-or-that area") in a limited time of an interview is hard at least on two counts: misunderstandings/communication problems instead of skill problems, and the need to wrap the obviously confrontational (instead of cooperative; it would be the latter if we could be honest with each other, but that's a pipe dream) process into something that doesn't look confrontational on the surface. It's indeed a "hiring theatre", and you need pretty solid acting skills and some psychology to pull it off as an interviewer. Of course, very few interviewers have the required combination of knowledge and skill; in effect, over the past year, I was able to form an opinion (good or bad, but at least an informed one) about the candidate's skills maybe half the time. In the other 50% of cases, I just couldn't pry any info about the actual skills from a candidate. It's like they're saying: "hire me if you want to see my cards" - and honestly, I can't even blame them too much! We're not exactly perfectly honest from our side, either, in the end...

Basically, I dread the possibility of being subjected to what has become the prevailing model of hiring in tech; I don't think I have it in me to either game the system or get good at using it, so the only thing I can count on is just dumb luck: that, at the exact time I will need it, some company will show up and either come to me directly, or will have both the process and people staffing it compatible with me by chance. If not that, I don't see myself ever getting hired again.

You're either sarcastic or you missed all of: a) this being in italics, b) this being in quotes, c) this being the only LLM pattern in the post, d) this being quoted explicitly as an LLM marker. Good job in both cases, I guess.

He's the guy from FOOF[1]! I didn't immediately make the connection, thanks. Yeah, that series was kind of fun, even if it kind of reinforced my layman understanding that all chemists are explosion nerds :D

[1] https://www.science.org/content/blog-post/things-i-won-t-wor...

The fact that politics controls businesses there might lead to, but doesn't necessarily ensure, a "brighter future". It's pretty common knowledge that authoritarian regimes can, especially in extreme, disastrous situations on a large enough scale, function better than less centralized and more open organizations. The problem is that there's less resistance to directing that effectiveness toward something that will make at least some people's futures much darker.

Then again, just because business controls politics doesn't mean there's much more decentralization or openness, either. In the end, the main advantage of this model was predictability - sure, we have an "inner circle" that forces its policies in both cases, but the businesses are at least predictable in their decision making, always chasing profit, based on hard numbers, unlike the other side chasing whatever flavor of ideology they believe in (or want to sell) this month... Wait. I just recalled "colonies on Mars" and "metaverse," and the cognitive dissonance made me blank out for a sec here.

In any case: while the Chinese model seems to have some upsides, especially compared to the current situation in a few other places on the globe, I don't believe it has a significantly higher chance of helping us achieve a "brighter future". I may be depressed, but in virtually every scenario from this point, I can only see a bleak future ahead of us. Getting to AGI under current conditions makes for completely unpredictable societal and political chaos, yet not getting there (and fast) risks the bubble bursting (causing, of course, unpredictable economic and, by extension, societal and political chaos). The longer the current situation persists, the lower the probability of finding an off-ramp that won't upend everybody's and their dog's lives. Yet, there is no incentive to back off from the race either.

I really wonder what's next - what kind of poop will finally hit the fan, and when exactly?