Two of my kids have worked summers at the local theme part. The headline on this HN post sounds a lot more like what they experienced, i.e., smashed smartphones under the rollercoaster tracks, than it sounds like the actual paper.
One can create amazing ergonomic scripting APIs in TCL; I've done that. One can also rapidly create horrors without end. I've seen that, too. With great power comes great responsiblity.
All of which I used many years to go to write "Snit", a quite nice object system for coding up Tcl objects and Tk widgets. Snit's a TCL library that takes a nice, easily readable description of your desired object type (the instance variables, the methods, and so forth), translates it immediately into standard TCL, and then evaluates that to define your type. Basically, it's a macro system for defining object types. (I say "object types" rather than "classes" because there is no inheritance.)
If it hasn't happened yet, it will happen in the future. There are so many failure modes, from trusting AI outputs too far (see the reports of the death of school children in Iran at the beginning of the war) to bad actors using AI for hacking to AI actors themselves doing unexpected things.
Organizations that don't get hacked, potentially losing data, costing large sums and money, and inconveniencing customers. They benefit. Remember them?
It's not even clear that the AI data centers required to run all this will be economically viable in the long term. But again, the interesting part of the article comes after the discussion of any new kind of economy.
The point of the article isn't that we will have no need to work; that remains an open question. The body of the article is exploring previous societies or segments of society in which no one needed to have a job, and how they lived their lives, as a way of pondering what a post-work world would look like. It's not particular pollyannic in tone once you get past the opening paragraphs.
A craftsman differs from an artist in exactly this: an artist produces beauty while a craftsman produces an artifact that serves its purpose beautifully and robustly. The two can be combined, of course.
Agreed. In my view, using AI to write code is neither engineering nor craftsmanship, but an abrogation of the responsibility to deliver a quality product. It isn’t engineering, it’s management, and these days (given the quantity of code agents spew out) it’s management without responsible oversight. Seriously, I’m distressed at how the industry is drinking the poison kool-aid.
It occurs to me that letting AI agent process your incoming e-mail really isn't that different in principle than letting incoming e-mail include scripts to run at your console. Why are people so eager to rush into this brave new world?
I anticipate a lengthy series of catastrophes initiated by AI agents with too much power and too little sense. Today the agent accidentally deletes your repo; tomorrow we lose a day's worth of banking transactions; Friday the cell phone network goes down. Such things, if sufficiently destructive, could result in widespread hunger, etc.
Have you a source for "billions in profit" as opposed to "billions in revenue"? If so, I'd be interested to see it, especially relative to SCE's current maintenance budget. I don't object to being proven wrong.
My main point, though, is that the regulatory environment here in California has evolved without due regard for the law of unintended consequences.
I have every sympathy for the folks who lost homes here in California last year; it could easily have been my house. But what a lot of discussions miss regarding SCE's role in the Altadena fire is that SCE is a public utility, and California's Public Utilities Commission has not been allowing SCE (or other utilities, like PG&E) to charge rates that would allow them to do the required maintenance to prevent fires. In another case, some years ago, I understand that a fire in Northern California started next to a PG&E substation; the brush had not been trimmed, so I'm told, because environmental regulation didn't allow it.
From where I sit, this is not simply a "power company bad" situation; the state has played a significant role.
The problem here isn’t the rewrite, the problem here is toxic management, massive feature creep, unrealistic expectations, etc., etc. You’d have been doomed without the rewrite.
This is one of those perennial ideas; let's get rid of hierarchical file systems and just keep all the files in a database. Speaking as a user who knows how to keep things organized, I like hierarchical file systems. Store the data in a database if you like, but don't break my metaphor.
The TCL community experimented with an idea like this many years ago; they were called "structured documents" or "starpacks". What we found was that (A) it's usually more convenient to keep the data in a separate file, and (B) virus checkers can get suspicious when your app starts modifying itself, leading to unintentional comedy in operations. YMMV.
Young Americans have been fed a constant diet of “the Modern World is Awful” and “You Are Doomed” for quite some time now. This is just the next round, and as always it is overstated.
I'd not seen the spelling "sike" until today; but I've been spelling it "psych" since I was in grade school in the early 70's. Definitely derives from "psyching someone out", i.e., confusing them or tricking them (in that I first heard "psych" as shorthand for "psych out"). I wouldn't be at all surprised if it's older than that.
The ecosystem makes it feasible to use the language or not. For my personal projects, I won't use a language that doesn't provide some kind of straightforward cross-platform GUI toolkit (nearly) out of the box—which narrows the field enormously.
But it's the syntax and semantics what determine whether I'd want to use the language to begin with, and how maintainable the resulting code is.
I had at least one Gateway 2000 desktop and several laptops over time. All but the last laptop were lovely machines. The last looked good on paper, but it was thicker and heavier than it should have been, and start losing keycaps fairly quickly.
Using `switch` is not a better approach if the design allows for outsiders to add their own shapes at a later time. Using `switch` probably is a better approach if the range is shapes is fixed and new shapes can't be added, especially if the language's `switch` statement requires that all valid cases be included.