digging

Yes, it is an enormous mistake to equate learning with surprise. I'd ask you to consider answering my above question directly, as I think it will resolve this issue.

Of course, my response as a human to those rules and that prompt would be, "Hey - don't harm anyone."

I do not know if it breaks rule 2 or not; as a human I don't have to figure that out before responding. But all my subconscious processing deprioritizes such a judgment and prioritizes rule 1.

> The rules of ethics laid out are mutually incompatible.

Prioritization is part of the answer, for a human. You cannot ever have 2 equally-weight priorities (in any endeavor). Any 2 priorities in the same domain might at any time come into conflict, so you need to know which is more important. (Or figure it out in real-time.)

> if nobody's surprised, then nobody has learned anything

Really? You're saying that as long as you assume something is true, there's no value in finding out if it's actually true or not?

"The model should ..."

Well, that's the actual issue, isn't it? If we can't get a model to refuse to give dangerous information, how are we going to get it to refuse to give dangerous information without a warning label?

Yes, I did. What's the correct denominator that makes the daily effort worthwhile for you? Would you do x/5? x/10? x/50? After 50 days of continuously spending more effort than necessary, do you make the trade or just accept the ever-increasing loss of productivity? Fortunately for us all, the real number for "configure Typescript" is a lot closer to 1 than to 50.

This has been a sticking point for me since my workplace told us all to start using the new copilot licenses they bought. The ideal workflow for me is usually inline question-and-answer but it tends to insist on editing the code, often in ways that do more than I actually wanted.

It's always difficult to notice features you don't know are missing.

I'm a near-exclusive user of VSCode (or Codium, at home) and like to think of myself as moderately advanced. I continually update my configurations and plugins to make my workflow easier and often see my peers stumble on operations that are effortless for me. It's hard to explain to them what they're missing until they watch me code. So now I'm curious about watching some typical Jetbrains workflows.

I'm out of my depth here, but a high-level response:

First, I don't think the "unconscious" part is a single process, but myriad processes, and I'd bet they wax and wane.

Second, the "conscious" part is the part that can reason about itself and think abstractly. I think it would be correct to say it's doing higher level computations. The important part is that this is more costly - it's not optimized because it has to be flexible, so it would make sense that it's resting as often as possible.

Yes, it's a classic example of the power and skill of your "unconscious" mind - your consciousness is freed up to do novel work because the drive home is so routine that your unconscious mind can do almost all of the work. Should something change - a traffic jam, a detour, a pedestrian crossing the road - your conscious attention will be called back to the more urgent task which is making a decision about how to handle the driving situation.

The eternal question of spending "x hours upfront" vs "x/2 hours every single day"...

Even if that's true (maybe your team is really careful about documentation and data structures even when they don't have types?) - the majority of the "bugs" TS catches are those that would be caught manually anyway, during development.

It's just that instead of measuring those bugs in hours, they don't even exist to be measured.

But murder and manslaughter aren't simply "kill a person with intention", "kill a person without intention", that's why we have different degrees of each. Because you have to define what intention means. Savagely beating somebody to death, while believing they'll probably survive - is that with intention or without? There's also other forms of homicide than just manslaughter and murder!

I think that's why these terms exist, because they become shorthand for longwinded definitions that may need to be very precise.

> more advanced thinking

does not imply

> vague, unspecified notion of "the real creative work" or "the things only humans are good it".

It's just true that increasingly advanced tools enable increasingly advanced work.

I'll look into it, but, it's not true that energy was not used to grow food. Farming is labor, it takes human effort; food has to be eaten to grow more food.

I'd agree with that, because refactoring is hard, especially if you don't intimately understand the domain, and I think "effective government" is much less understood than "high quality software" as a whole, so it's extremely hard to refactor government. Additionally, there are more politics involved in gov't refactoring than code refactoring, so even provably good ideas can get shot down. All the same, I endorse "learn more about the problems and get better at refactoring" over "rip things out" virtually always.

No, math can describe programming, but that's also true of everything. You wouldn't say "Playing basketball without math is impossible" even though it's technically true because you don't need to know or use math to play basketball. You also can do a ton of programming without knowing any math, although you will more than likely need to learn arithmetic to write enterprise code.

Energy is used to grow food, so, no. Keep in mind the context of my first comment.

Context is indeed what narrows the meaning of a word with various or broad meanings.

> they demonstrate that substantive rather than incremental changes are possible at all.

Substantive-not-incremental change has always been possible, but it's mostly avoided for being a bad idea. Only when we identify an opportunity to make substantive improvement, clear and well understood, should it be used; the default is substantive destruction which is rarely more helpful than harmful.

In software terms, they're looking to rip out entire modules, because they don't understand the business logic that demands those modules. Such substantive change would be pretty idiotic in almost all cases. Refactoring is virtually always the better choice, even if it's hard and takes a long time.

Ripping out a module entirely, only to find it was necessary after all, tends to lead to the same module being rebuilt piecemeal as the missing logic is identified and being as bad or worse than before. In the end, you still need to refactor it if you want it to be good. If you can't afford to refactor, (and you don't have well understood problems,) you're better off not changing anything.

Well, all of the conceptual elements it used are in the training set; it just combined them in ways that don't even make syntactic sense. Yes, I know we "just" combine ideas too when we're creating. My point is that I don't think it was producing new concepts, just slamming words together in grammatically acceptable ways. Do any of its absurd phrases mean anything to you? They don't mean anything to me. I could create something conceptually sound based on its absurd phrases, but that's still me doing the work where the LLM is acting as an algorithmic name generator.

I'd be curious if it could explain those concepts and use them in consistent ways. If so, I'd be curious how novel it could really get. Is it just going to be repackaging well-trod scifi and fantasy devices, or studied philosophy? Or could it offer us a story with truly new understandings? For example, to my knowledge, House of Leaves is something truly novel. It's probably not the first book with intentional printing errors, or with layered narration, or with place-horror, etc. But I think House of Leaves is pretty widely considered a sort of "step forward" for literature, having a profound impact on the reader unlike anything that came before it.

(A really serious discussion will require analyzing exactly what that impact is and how it's novel.)

Well, yeah. I avoided the subject of trust because it wasn't the subject of the comment I was responding to. It's a different component of money.

Money depends entirely on trust which is a form of belief. But it only matters because it accounts for energy. Because there is nothing to trust in if money can't be exchanged for energy. We trust that our paychecks will buy food because our society is usually fairly robust in that respect. We trust that the US government will go to war to prevent the USD from being deprecated, which lets us continue to use USD.

There's no trust that Bitcoin can always be exchanged for any arbitrary good or service - whereas USD can be turned into anything you want. Bitcoin will always account for some energy usage, but so will starting forest fires. The difference is that nobody is ever going to trade me anything of value for starting a forest fire. That's the trust element. But starting a forest fire leaves just as real an impact on the universe as mining crypto, as mining gold, as building bombs to threaten grifters with.

> Down votes are interesting when applied to a comment that's an answer to a direct question.

I suspect it's because your answer was indirect and had a fairly proselytizing tone. I found the information interesting, but it was a somewhat irritating read because it was inverted to demand attention, like a story, rather than being upfront. A better-received comment might have read more like:

"I used Clojure. This was mainly because it's my favorite language, so I could work faster in it, and because it has certain features which make debugging extremely fast. et cetera."

Or, they won't say anything about it at all, because they (choose all that apply):

a) are not good communicators,

b) do not respect you,

c) are afraid to admit they don't understand (even if your doc is clearly shit),

d) do not care very much about the project.

Very interesting! Is "tree-house building" a reference to something specific or did you make it up? It strikes me that engineering is either a spectrum, or it's a segment of a larger spectrum (the name of which I don't know). Tree-housing is near one end of that spectrum, the MacGyver end, and dam-building is near the other end (where the problem is thoroughly researched, the goals are calculated, and the designs are all made to serve those calculations specifically).

Do you feel "engineering" could cover the entire spectrum, where your "Engineering" specifies everything on one side of "has a design doc"? If not, is there a name for the whole spectrum? Does crocheting from a pattern sit anywhere on this spectrum, or is it something else, or does it mean that my spectrum-of-engineering is an illusion? Open questions here, not directed at DrNosferatu necessarily.

The crypto industry is extremely untrustworthy, but for me, I don't think "there's no actual value creation at the bottom of it" is more true of e.g. Bitcoin than USD.

Assume USD is somehow attached to food, shelter, and other necessities (for the record, I agree that it is, but only indirectly). Those necessities are the things we need, but we don't need money to create them. We just need energy and physical resources (which, technically, also just require energy). All money is an accounting system built on top of the physical processes that we use to grow, gather, hunt, cultivate, shape, and build matter.

So there's nothing weird, to me, about money being built almost directly on top of energy usage. I think it makes sense.

Most money is built on top of gold or other precious-but-unnecessary materials, which I can't say seems more attached to real value than energy. But even if we assume 1 unit of money is 1 day's worth of food, who's to say that unit of food is actually a necessity for the holder? That food is a specialized form of energy; energy which has been used and which can't be unused. The food itself is an accounting of entropy. But it (mostly) can't be converted into shelter or other necessities, only traded or stored. So, again, I don't see "this money is an accounting of energy used" as outlandish, but reasonable.

Let me conclude, however, by roundly rebuking crypto grifters and the majority of the industry. They're generally not operating on the arguments I've made above anyway.

I think that's actually not unusual or even wildly unreasonable shopping behavior in a market where:

1. Many if not most "customers" (JS devs) don't understand how to evaluate quality deeply (thus, quality signals aren't trustworthy, making evaluation more difficult and resulting in further acceptance of using unevaluated products)

2. There's an overwhelming number of choices, with deprecation, replacement, and eclipsing all being fairly common - potentially even year-to-year

You kinda just have to try stuff out and work with what you've got.

...that pitch is a mess. The majority of it is nonsense and it doesn't sound like a good story to me (I think. I can hardly parse it.)

They're different because they're trying to find the most likely output, and humans usually. You can ask and LLM to make weird combinations and use unusual framings, but it's only going to do so once you've already come up with that.

But the narrators aren't narrators; they're just different settings for the relative frequencies of events. Dwarf Fortress is still a more robust "story generator", as the vast majority of what occurs in Rimworld is still basically random events, disconnected from prior events or context.

Hm, I mostly agree, but I think that's a bit tangential.

It's not like people really get to make that choice and still have a good chance at success. In order to meet any definition of success[1], you need to get hired. And also, if you're in a job that's making you miserable, you once again need to get hired (somewhere else). Networking is the solution to that problem. If you're not someone who can enjoy and/or succeed at networking, your career is at risk. There's not much you can do about that except take a different path.

[1] excluding either "leave the field and succeed somewhere else" or "start your own company"[2]

[2] although starting one's own company without a robust network would probably also be a pretty difficult path