nrr

There are some details here about the history of how generics finally came to Go: https://golang.design/under-the-hood/en/part2lang/ch08generi...

The tl;dr boils down to a combination of valuing both compilation speed and execution speed.

I'm unsure that I agree. History has borne out a lot of evidence that people will jump to other means of paying for things in the face of the local currency collapsing, even in the face of amped up (but nonetheless impotent) enforcement.

As it turns out, I'm not making up my own definitions here. The view of a free market being a market with equitable access is attributable to Adam Smith from his Wealth of Nations. He bases his understanding of this freedom on the absence of private rent-seeking and absence of monopoly privilege (though in 1700's vernacular).

Henry George in his Progress and Poverty makes similar gestures toward defining a free market this way.

Part of the reason why it's important to consider other definitions (and other economic models) is that there is an important result in economics from the 1970's that, more or less, establishes the lack of a guarantee that the demand curve in an aggregate demand model (a macroeconomic model) will slope downward. This makes the aggregate demand model less than useful for a priori arguments about supply and demand in the macro context; they must instead be approached a posteriori.

It's also the big reason why I'm uninterested in a colloquial definition that is heavily filtered through von Mises and Friedman.

I fear that this conflates open and closed access with exclusive property rights. It isn't untrue that asserting exclusive property rights on something makes it closed access[0], but there are other mechanisms for achieving closed access of a resource, like enforced regulation.

Slightly more formally, an assertion of exclusive property rights is a sufficient condition for something to be closed access, but it isn't necessary.

Though, admittedly, that does depend on what one's definition of a free market is. Is it unfettered commerce, consumer protections and suchlike be damned? Is it a system of commerce that ensures equitable access? I'm personally of the mind that, as long as I trade with certificates that bear Caesar's face (or trade with proxies for such certificates, like a MasterCard), he gets to make the rules in exchange for my being able to lean on his legal system to protect my interests, so I find that the equitable access angle is nice.

(Likewise, trading with Bitcoin or Ethereum or whatever the in-vogue cryptocurrency is today means that the code makes the rules, and I get to pay for the privilege of having my transactions indelibly entered into the distributed ledger and for the code governing those transactions to be buggy and exploitable. I'm still scratching my head at it.)

At the risk of building a strawman here, I'll caution that it's logically inconsistent to expect the state to enforce exclusive rights while also urging that strict regulation of a shared commons is an illegitimate market intervention.

--

0: That is, unless the title holder grants license, but that's a whole other conversation.

Not at all. Tithing[0] is contributed as one is able, but assistance in the face of hardship is no questions asked. For my congregation in particular while I was growing up, this extended even to non-members, and there was a strong thread of volunteerism.

--

0: Tithing can take many forms beyond giving cash. I tithed my RSUs.

My remark was a rebuttal to the assertion that these contributions were guaranteed. That notwithstanding, I'm unsure that I agree that it amounts to about the same thing; we tend to take care of each other as a matter of due course and not as a transaction.

The mainstream Anglo-American attitude around this kind of support leaves me scratching my head a lot of the time.

Not so. I'm part of a religious community for whom FICA is something we can opt out of via IRS Form 4029, and I can avoid contributions to FICA more broadly (not just SS taxes!) by handing HR the approved 4029 that I receive in response to filing.

I don't know how available this is to folks who aren't Mennonite or Mennonite-adjacent, but it's there.

I can entertain you since no one else has so far. I've been using Fossil since 2009.

> My dream "forge" would just be nice-looking frontend for displaying repos on the web, a public issue tracker (with per-issue permissions), a public way to submit issues, and essentially a single canonical root for repositories that users on the team work on.

Fossil will get you the frontend (for some value of nice-looking) for displaying repositories on the Web. It will also get you the issue tracker, which can optionally be public[0].

For products you're developing that involve multiple repositories, it's possible to use a "meta repository"[1] to establish what's called a login group in a way that's vaguely reminiscent of using, say, Kerberos as an adjunct to /etc/passwd. You still have to ensure that the users exist in the user information table on the joined repositories[2], but the password information will at least be synchronized.

> I don't want individual user repos or pages, organizations, or any social stuff. I definitely don't want open registration.

There's some social stuff if you find later that you want it. Fossil development moved from a more traditional mailing list to a self-hosted forum a while ago, but it isn't enabled by default.

You can use tech notes as a sort of micro-logging facility in the same vein as snippets if you're familiar with how Silicon Valley companies sometimes have cultures of personal status updates. I'll admit that I've gotten a fair amount of use out of this.

I'm honestly not sure if open registration is possible. I've never had an excuse to try it.

> How limiting is the custom theme support? It looks like you can just straight up write your own HTML/CSS for everything. If I really want a custom design, will I be disappointed in the long run?

If you stick just to HTML and CSS, you should be fine. The functionality is pretty spartan.

> Also, it looks like it follows that user model I want, where it's "repositories with users" instead of "users with repositories". Is that correct?

Yep. The repository itself is what has the user information.

--

0: This is governed by the capabilities assigned to a user. See https://fossil-scm.org/home/doc/tip/www/caps/ and the therein linked https://fossil-scm.org/home/doc/tip/www/caps/ref.html for details.

1: At least, I tend to name mine "meta."

2: Funnily enough, it shares the same pain as administering Plan 9's fossil(4) fileserver. See https://fossil-scm.org/home/doc/trunk/www/caps/login-groups.... for details.

My (actuarial) read on this is that pre-Microsoft GitHub acknowledged that the complexity inherent in their technology stack imparted a lot of change risk, and that probably informed their decisions around shipping new features.

My (not-so-actuarial 1990's-experience-colored) feeling is that this is Microsoft doing what Microsoft does best, namely including a lot of seemingly compelling features in a product to get people hooked and to keep competitors in a position of trying to keep up.

Forgive me. Did I advocate for not understanding data structures and algorithms?

Not really. I'm typically less concerned with how much someone costs than I am with how much time they'll wind up wasting, but I'll admit that this perspective is colored by my experience having run a kitchen in a restaurant.

The secondary challenge in the kitchen (beyond the challenge of hiring someone who'll simply show up when scheduled, ha) is hiring someone who has a genuine interest in cooking as a craft. It's true that being a line cook isn't especially glamorous work, but I absolutely need someone who has enough love for it that they're proud to show off what they can cook when it isn't my menu.

I interviewed someone who made nothing but scrambled eggs, hash browns, and grits, but they were cooked and seasoned to absolute perfection. This individual was one of my slower line cooks starting out, but the fact they had the drive to learn this level of cooking was good enough for me to invest time in them to improve that speed.

I look for the same love for the craft in software. Literally everyone who's worth their salt has something they've worked on that they will happily show off, or some technique (like, e.g., abusing generics to implement monads in Ada and why this is more interesting than the typical approach using interfaces), or some pet data structure (e.g., critical bit trees and what their pathologies look like vis-à-vis hash tables) that they try to shoehorn into everything, or some bit of code they've read (e.g., SQLite and the Tcl interpreter) that left a lasting impression on their practice.

There's a snag though: being worth one's salt only starts at being able to cut code. I need to witness a candidate write about and walk me through that very technical aspect of the craft that they want to show off.

Assessing craft requires interviewers who understand craft, and the literal only reasons I can see for using LeetCode are when the interviewer is themselves not an expert in the domain (perhaps for reasons of scale, among others), the interviewer cannot (or will not) engage in heavily technical conversation with a candidate, or the job is plainly not about writing software that works.

Nothing.

No, I left the industry.

dang seems to have outright banned him just over a fortnight ago. https://news.ycombinator.com/item?id=42653007

On Hacker News, banned accounts can still comment, but those comments are immediately dead until vouched.

"There's no foresight. There's no planning." Couple that with "as an expression of agility," and it really rings true to me. I've worked in enough shops where the contractual obligations preclude any ability to slow down and put together a plan. A culture where you're forced to go from an angry phone call from the suits to something running in production in mere hours is a culture that finds building bookcases out of mashed potatoes acceptable.

The best environment I've ever worked in was, ironically enough, fully invested in Scrum, but it wasn't what's typical in the industry. Notably, we had no bug tracker[0], and for the most part, everyone was expected to work on one thing together[1]. We also spent an entire quarter out of the year doing nothing but planning, roleplaying, and actually working in the business problem domain. Once we got the plan together, the expectation was to proceed with it, with the steps executed in the order we agreed to, until we had to re-plan[2].

With the rituals built in for measuring and re-assessing whether our plan was the right one through, e.g., sprint retrospectives, we were generally able to work tomorrow's opportunity into the plan that we had. With the understanding that successfully delivering everything we'd promised at the end of the sprint was a coin toss, if we were succeeding a lot, it gave us the budget to blow a sprint or two on chasing FOMO and documenting what we learned.

0: How did we address bugs without a bug tracker? We had a support team that could pull our andon cord for us whenever they couldn't come up with a satisfactory workaround (based on how agonizing it was for everyone involved) to behavior that was causing someone a problem. Their workarounds got added to the product documentation, and we got a product backlog item, usually put at the top of the backlog so it'd be addressed in the next sprint, to make sure that the workaround was, e.g., tested enough such that it wouldn't break in subsequent revisions of the software. Bad enough bugs killed the sprint and sent us to re-plan. We tracked the product backlog with Excel.

1: Think pairing but scaled up. It's kinda cheesy at first, but with everyone working together like this, you really do get a lot done in a day, and mentoring comes for free.

2: As it went: Re-planning is re-work, and re-work is waste.

I've had a lot of experiences like this, and I wound up ducking out of the industry entirely in 2021 after having had my skillset reduced to dogmatic use of the infrastructure buzzword of the day.

A lot of newer[0] US domestic market manual transmission cars do, in fact, have an interlock that prevents the starter motor from getting power without the clutch pedal also being depressed. Of particular note, my 1984 Ford Bronco II, 1991 Mitsubishi Galant, and 2004 Honda Accord all had such an interlock.

0: This is basically everything after the three-on-the-tree/four-on-the-floor era. I have yet to drive anything with an overdrive gear that didn't require popping the clutch to crank the starter.

Georgia HB 87 (2011) and its unintended consequences say otherwise. While the H-2A is indeed popular, there are still a staggering number of people working these jobs who are here illegally.

https://www.forbes.com/sites/realspin/2012/05/17/the-law-of-...

https://www.npr.org/sections/thetwo-way/2011/05/27/136718112...

https://www.theatlantic.com/business/archive/2011/06/georgia...

https://www.politico.com/story/2011/06/ga-immigrant-crackdow...

https://www.timesfreepress.com/news/2013/jul/07/immigration-...

It's all part of the actuarial mindset. The entire point of the exercise is to arrive at a model of reality that has some degree of predictive power.

> For me the only things that scare me are in the "I have no data on that" category.

I feel exactly the same way. It means that I have no idea what those things will wind up costing me, and that's the anxiety trigger as far as I'm concerned.

I'm also on team Keep An Eye On Things™, and approximately none of it really feeds into an anxiety loop. (There's a tiny sliver of the pie that does, but it's easy enough to talk myself off that ledge and go engage in a Weltschmerzspaziergang[0].)

I know it's stuff I can't control, and that's sort of the point. I want to know what I can't control so that I can know what I can control, if that makes sense.

0: Otherwise known as "touching grass."

> There's something very, very wrong in the way we write programs nowadays.

I largely agree, but...

> ... the database is you main source of invariants.

I guess my upbringing through strict typing discipline leaves me questioning this in particular. I'm able to encode these things in my types without consulting my database at build time and statically verify that my data are as they should be as they traverse my system with not really any extra ceremony.

Encoding that in the database is nice (and necessary), but in the interest of limiting network round-trips (particularly in our cloud-oriented world), I really would prefer that my app can get its act together first before crossing the machine boundary.

> If your unit tests have some overlap on your integration tests, that's nbd especially seeing as you can run your unit tests in parallel.

Exactly.

Another upside I've run into while doing things this way is that it gets me out of being relational database-brained. Sometimes, you really do not need the full-blown relational data model when a big blob of JSON will work just fine.

> The only thing enforcing these invariants in production is the interplay between your database schema and the queries you execute against it."

I'm unsure that I agree. The two examples you gave, establishing that IDs are unique and that updates to entities in the system are serializable (and linearizable while we're here), are plenty doable without having to touch the real database. (In fact, as far as the former is concerned, this dual approach to testing is what made me adopt having a wholly separate "service"[0] in my applications for doling out IDs to things. I used to work in a big Kafka shop that you've almost certainly heard of, and they taught me how to deal with the latter.)

That said, I'd never advocate for just relying on one approach over the other. Do both. Absolutely do both.

> I'm pretty sure "don't repeat yourself" thinking has led to the vast majority of the bad ideas I've seen so far in my career. It's a truly crippling brainworm, and I wish computer schools wouldn't teach it.

I brought up WET mostly to comment that, if there's one place in software development where copying and pasting is to be encouraged, testing is it. I'd like to shelve the WET vs. DRY debate as firmly out of scope for this thread if that's alright.

0: It's a service inasmuch as an instance of a class implementing an interface can be a service, but it opens up the possibility of more easily refactoring to cross over into running against multiple databases later.

I think it's probably worth mentioning that the principal concern for tests should be proving out the application's logic, and unless you're really leaning on your database to be, e.g., a source of type and invariant enforcement for your data, any sort of database-specific testing can be deferred to integration and UAT.

I use both the mocked and real database approaches illustrated here because they ultimately focus on different things: the mocked approach validates that the model is internally consistent with itself, and the real database approach validates that the same model is externally consistent with the real world.

It may seem like a duplication of effort to do that, but tests are where you really should Write Everything Twice in a world where it's expected that you Don't Repeat Yourself.

Starlark is Turing-incomplete, which makes it somewhat unique among embeddable languages. It's definitely a draw for me for something I'm working on.

It was! I've, however, gotten way more use out of saddling whoever is most senior with the role of making sure the team as a whole is on track. This way, it's a little more familiar with the way Western management hierarchy operates without turning it too much on its head. It's something of a leadership billet without removing the ability to be technical, which is important for a lot of folks.

It tends to work pretty well in an environment that both lacks a bug tracker (so that individual people aren't assigned things) and has a culture of pairing or mobbing.

I'll push back in defense of Scrum, but it probably bears a little explanation because my conceptualization of that framework is very likely a lot different from yours. (As something of a bonus: I'll bring in the military given the whole "wartime" trope.)

In particular, Scrum is only there to establish rituals that enable empiricism in decision making. A sprint is a reporting period to keep the team from spending too much time in the weeds. A standup is there to keep the team working together. The andon cord (which is often missing I find) is there when the facts have changed so utterly profoundly that everyone needs to regroup.

Anyone who's been through RTC ("boot camp"), and even some who haven't but have lived vicariously through others, understand that being constantly yelled at by RDCs ("drill instructors") on how you make your racks and fold your clothes is all about building certain habits and only tenuously related to what you'll be doing after A-school. It all has more to do with building trust that the rest of the folks in your ship will help carry you when the going gets tough. Scrum, at its core, is kinda like that.

I really dislike the term "Scrum Master." They're a team captain. The more military-minded might be keener to use "gunnery sergeant" or "chief petty officer:" they're just the most senior person in the rating group^W^W^W^Won the team. (Though, I'd probably take more inspiration from the Marines than the Navy here: a culture of servant leadership seems to bring out the best in people.)

The most popular implementations of Scrum tend to come with a ridiculous amount of meeting and tool baggage, and it's so unnecessary.

Use Excel. Hold your standups at the close of the day so people can go home. Write your product backlog items in delivery order so that sprint planning is less about sitting in one room playing poker and more about just getting valuable shit done.

That said, what isn't unnecessary, however, is kneecapping command a little: the engineering officer of the watch has comparatively little understanding of the actual operation of the machine. They just know that they want operational excellence. However, that excellence also sometimes comes with the watch supervisor—a subordinate—publicly calling out mistakes that the watch officer makes.

cmd.exe is largely still concerned with starting processes and hooking them together in much the same vein as Bourne shell, so I tend to use it for that.

(I actually use Yori[0], but it's pretty much to tcsh what cmd.exe is to csh.)

PowerShell leaned a little too hard into the structured data to be useful for me as a command shell. It's a pretty decent competitor to the Python REPL though.

0: https://github.com/malxau/yori

"A depressed person often wants to be depressed ..." I'd caution against expressing it this way. It's less a want and more a ground state.

I am one of these depressives, and I definitely do not want to spend all day in bed. It is, however, a ground state that takes an amazing amount of energy to escape, so my usual inclination is to conserve energy and not escape. It may outwardly look to non-depressives as a strong desire to spend the day in bed and away from the world except through whatever portal the Internet gives us, but it's my experience that having someone to come by to help with the parts of living that fatigue me is direly, overwhelmingly underrated.

And, like, it isn't often chores or errands that are the most helpful. (Indeed, when my depression saps me enough, I find that just going on a cleaning binge is a cheap way to recover for a while.) No, rather, it's stupid shit like having someone make decisions for me so that I can get un-stuck from whatever mental hell I've fallen into. The challenge is usually articulating which decisions I need made because merely unpacking them has a high energy cost.

It's only when I've gotten a handle on the fatigue each day that I'm truly able to get moving.

In practice, at least in my experience, only up to 13. (Though, I have the sequence memorized up to 21 because of a sign outside Chattanooga[0], which is what gave me my "hey, wait" moment about this.)

A combination of both the fundamental theorem of algebra and Zeckendorf's theorem has allowed me to fill in the rest so far. For example, 25 mi = 5 * 5 mi, which yields 5 * 8 km = 40 km. As it turns out, that is how far Cleveland, TN, lies from Chattanooga.

0: https://usma.org/metric-signs/tennessee