Just love of whimsy is part of it, not denying it. But other parts of it are that a generation or two on, a lot of the straightforward names are taken.
(Also, I wouldn't say `awk` or even `grep` are good examples (as the OP admits) -- they were definitely chosen for whimsky, with, if not actually backronyms, still acronyms deisgned for whimsy).
And another part of it is that so many people now have dreams of commercializing their product, so you need a "brand" name. (I guarantee the namers of the tools had no designs on commecializing grep or awk). (I have little sympathy for this one, but it's the world).
I do agree with OP it is a problem for accessibility. Newcomers who haven't already memorized the mangagerie have a lot to figure out; some people's brains work differently than others and it's easier or harder for some people to remember these arbitrary names naturally; I'd guess it can be especially hard for non-native English speakers, but maybe it's all Greek (ha!) to them anyway, so.
When i have tried to name things plain though, I often have trouble -- we want something clear, but also relatively short (especially if it's going to be in namespace or other identifier names and be typed a lot!) -- and not already taken in popular consciousness or the package managers we'll need etc, and often I have trouble finding such!
Perhaps your smug feeling can cancel out the smug feeling the author/publisher had when picking a font before even knowing what they even want to write.
It's important to keep the smugness balanced, thanks for doing your part.
The government has laws saying people under 16 can't drive cars, do you think that's part of the slippery slope that has led to all of those happening-in-practice bad things?
> The government has laws saying people under 16 can't drive cars
We did, though. The chances of getting caught were slim to nil. Will kids (and adults for that matter) have the same easy opportunity to evade enforcement here?
I thought the point of laws was not that enforcement is perfect but rather that the consequence of getting caught created a counter-incentive to doing the thing?
The point of laws is to document what everyone in a community has come to agree on, assuming a democracy. Or, in a dictatorship, what the dear leader has decided upon. Any punishments encoded into those laws may serve as a counter-incentive, I suppose.
But baked into that is the idea that enforcement isn't perfect so you can still disappear into the night when you have that urge to do whatever it is that is technically illegal. This allows acceptance of laws that might be considered too draconian if enforcement was perfect. However, it seems in the case of these digital-centric laws that enforcement will become too close to being perfect as, without the need to hire watchful people, there is strong incentive to make it ever-present.
Or maybe not, but that is why the question was asked.
That's what this discussion made me think of. To take it further -- if you were going to design a language expressly for AI-generated code, what might some of it's features be?
I think strong static typing probably? Which is, well, not javascript in fact! (And I have bucked the trend on this previously, liking ruby -- but I'm not sure I'd want AI-generated code without it?)
Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FAUST (for audio DSP)?
None of our existing programming languages were designed for quite the circumstance in which contemporary programming now finds itself; they all address an ergonomic situation in which there are humans and machines (not humans, machines, and LLMs).
It's possible, I suppose that the only PL that makes sense here is the one the LLMs "knows" best, but I sort of doubt that that makes sense over the long term. And I'm repeating myself, but really, it seems to me that a language that was written entirely for the ergonomic situation of human coders without any consideration of LLMs is not addressing the contemporary situation. This is not a precise analogy, but it seems to me a little like the difference between a language that was designed before vs after multicore -- or before vs after the internet.
The problem with creating a programming language for LLMs, goes back to, what are LLMs? They are trained on masses of human written code, that is written in human readable form.
So even if you make a better programming language for a LLM, it has nothing to train on. Unless we start to transcode human language code to the LLM code.
Are the vectors/tokens/whatever, not already LLM code at this point? Technically, LLMs not are doing what Haxe was doing (haxe.org) but in a more advanced form?
Even if we make a more LLM like programming code, in a sense, we are just making another code that needs to be translated into the tokens that consist in a LLM model, no?
Feels like we are starting to hit philosophical debates with that one lol
factories definitely are the cause of my test suite being slower than I'd like, I've been thinking of switching to fixtures. Good to see some context of what challenges I might be dealing with instead if I do.
Author here. I'm a big fan of factories but the slowness is a real drag on large test suites. If you're considering switching, remember that you can do it gradually, there's no law against using both fixtures and factories in the same project, in some cases (mostly on very complex domain data models) even makes sense: fixtures for the base setup that all tests share, factories for additional test specific records.
Thanks! While I have you, since you seem to know what's up with this stuff, I'm going to ask you a question I have been curious about, in Rails land too.
While I see the pro's (and con's) of fixtures, one thing I do _not_ like is Rails ordinary way of specifying fixtures, in yaml files. Especially gets terrible for associations.
It's occured to me there's no reason I can't use FactoryBot to create what are actually fixtures -- as they will be run once, at test boot, etc. It would not be that hard to set up a little harness code to use FactoryBot to create objects at test boot and store them (or logic for fetching them, rather) in specified I dunno $fixtures[:some_name] or what have you for referal. And seems much preferable to me, as I consider switching to/introducing fixtures.
But I haven't seen anyone do this or mention it or suggest it. Any thoughts?
I use the pattern you describe, but not in Ruby. I use code to build fixtures through sql inserts. The code creates a new db whose name includes a hash of the test data (actually a hash the source files that build the fixtures).
Read-only tests only need to run the bootstrap code if their particular fixture hasn’t been created on that machine before. Same with some tests that write data but can be encapsulated in a transaction that gets rolled back at the end.
Some more complex tests need an isolated db because their changes can’t be contained in a db transaction (usually because the code under test commits a db transaction). These need to run the fixture bootstrap every time. We don’t have many of these so it’s not a big deal that they take a second or two. If we had more we would probably use separate, smaller fixtures for these.
Your thinking is sound. At the end of the day Rails default fixtures is nothing more than some code that reads yaml files and creates records once at the start of test suite run.
So you can definitely use FactoryBot to create them. However, the reason I think that's rarely done is that you're pretty likely to start recreating a lot of the features of Rails fixtures yourself. And perhaps all you need to do is to dynamically generate the yaml files. Rails yaml fixtures are actually ERB files and you can treat is an ERB template and generate its code dynamically: https://guides.rubyonrails.org/testing.html#embedding-code-i...
If that is flexible enough for you, it's a better path since you'll get all the usual fixture helpers and association resolving logic for free.
I feel like i don't _want_ the association resolving logic really, that's what I don't like! And if it's live ruby instead of YAML, it's easy to refer to another fixture object by just looking it up as a fixture like normal? (I guess there's order of operation issues though,hm).
And the rest seems straightforward enough, and better to avoid that "compile to yaml" stage for debugging and such.
We'll see, maybe I'll get around to trying it at some point, and release a perversely named factory_bot_fixtures gem. :)
What I feel is really missing from factories is the ability to do bulk inserts of a whole chain of entries (including of different kinds). That is where 95% of the inefficiency comes from. As an additional bonus it would make it easy to just list everything single record that was created for a spec
I have a large rails app that was plagued with slow specs using factory_bot. Associations in factories are especially dangerous given how easy it is to build up big dependency chains. The single largest speedup was noting that nearly every test was in the context of a user and org, and creating a default_user and default_org fixture.
there's a profiler that can show you what to focus on, probably fprof here: https://test-prof.evilmartians.io/ (been a while and I don't remember exactly what I used)
(now maybe that's what you used to see what was causing the slowdown, but mentioning to for others to help them identify the bottlenecks.)
I work for a non-profit, and have found a very good place where we are treated well and where I can work on mostly interesting stuff mostly in the ways that seem best to me (not all non-profits are like this, for sure) -- and also make probably 1/2 to 1/3rd (or less?) what some of you make.
I worked for non-profits my whole career, and the hiring scene is completely fucked right now.
I've never, in nearly 20 years in the sector, been unemployed for more than a few months at a time. It's been a year, half my LinkedIn contacts are also looking for work.
I took a 66% pay cut to work at a nonprofit once, and it was hell.
The problem is that not many folks are willing to take a pay cut like that, so the level of employee talent was abysmal.
Years and years of the “Dead Sea” effect made it a thoroughly incompetent work environment where they were oblivious to how bad it was because the managers had never seen what’s real job was like before
Yeah, I've experienced a couple different kinds of non-profit hell, but been lucky enough to find a good place. So maybe it's no easier to find a good place in nonprofits than anywhere else, I dunno!
I'm tickled by the idea of someone using that flowchart and determining -- can I contribute a unique perspective? Absolutely! Does my unique perspective have value? No way!
Been there with a team that ignores important advice, has an issue that was avoidable, ask for help fixing it, then forget all about it when you give another advice.
(Also, I wouldn't say `awk` or even `grep` are good examples (as the OP admits) -- they were definitely chosen for whimsky, with, if not actually backronyms, still acronyms deisgned for whimsy).
And another part of it is that so many people now have dreams of commercializing their product, so you need a "brand" name. (I guarantee the namers of the tools had no designs on commecializing grep or awk). (I have little sympathy for this one, but it's the world).
I do agree with OP it is a problem for accessibility. Newcomers who haven't already memorized the mangagerie have a lot to figure out; some people's brains work differently than others and it's easier or harder for some people to remember these arbitrary names naturally; I'd guess it can be especially hard for non-native English speakers, but maybe it's all Greek (ha!) to them anyway, so.
When i have tried to name things plain though, I often have trouble -- we want something clear, but also relatively short (especially if it's going to be in namespace or other identifier names and be typed a lot!) -- and not already taken in popular consciousness or the package managers we'll need etc, and often I have trouble finding such!
reply