tabtab

There's an interesting job interview question: do you want to be more like Woz or S. Jobs? Elon Musk's management style is very Jobs-like: Motivates via manipulation and wow-factor of cutting edge, has grand visions, yet knows what factories and the market can and can't handle, tries odd drugs, etc. However, Jobs rarely stuck his nose into politics; Jobs mostly just trolled about tech.

GittoffmylawnGPT ;-)

I think the point is that anyone can enter the AI cloud market to compete with the fat cats if they get too pricy. NVIDIA's de-facto standards are the closest thing to a market moat. If AI ends up highly tied to NVIDIA's standards, then NVIDIA could become the Microsoft of AI. It's hard to know how tool chains will evolve to answer that though, it's new territory. (It could be all moot if the bots take over and eat us humans. I taste like chicken.)

I don't think anyone is arguing it's giving zero value, only that the total value is not keeping up with investments. Look at the recent smart-speaker bubble: people indeed use them, but not often enough for profitable activities, and so the speaker market popped. Trying to goad people into shopping with them failed.

Making AI pictures of Pee Wee Herman riding a shark blindfolded is indeed fun, but not profitable for Microsoft because it's too hardware intensive for ads to cover. I gotta make more goofy pics before the bottom falls out...

Objective info is currently hard to come by, but my horse sense is that Big AI is subsidizing it for many projects, including those in other companies, to gain both market share and investor excitement (deserved or not).

If one looks at most the bubbles of the past, the writing is on the wall. AI won't go away, but will probably take longer to make profitable than anticipated, just like dot-coms and smart-speakers. Force feeding it is causing indigestion, and it's likely to PukeGPT.

Similarly, those of us who cannot afford high-end AI have to use Photoshop to fake the AI look for our memes, like gluing extra toes on people.

"Sorry Grog, you weren't horney enough"

Many companies are merely blaming layoffs on AI, when in fact it's due to poor sales. Investors seem to fall for this lie.

If you simply had my personality, your pickle would never be at risk of getting used.

End result of horny people watching "A Christmas Story".

Once I coughed, sneezed, and farted at the same time. Very painful.

That would have made a good Silicon Valley plot: they discover they accidentally put a trade secret in their logo, and have to jump through hoops to collect, hide, and delete the bad version without making competitors curious about their effort.

Small dinosaurs are very worried.

CP/M is the Yahoo of OS's: had a mile-wide opening of opportunity to step into, but blew their chance through greed, short-term thinking, and suits-gone-wrong. CP/M and co. could have been Microsoft, and Yahoo could have been Google.

IT Fad Detection Kit: https://www.reddit.com/r/DilbertProgramming/comments/q3k1cb/...

The Orange Man was right!

What about embracing forms of tent cities rather than disparaging them? Homo Sapiens have been sleeping in teepees and portable huts for roughly a hundred thousand years; we have evolved to survive in such. Have shared showers, restrooms, washrooms, etc. I can't say it would work in all climates, but in many.

In the end it may be easier to reprocess the synth version with AI trained on acoustic sounds, ideally with options to select different performers' styles. The long list of algorithmic tips there may indeed work, but could be expensive to code, test, debug, and tune.

The nice thing about line numbers is that you didn't have to learn a different code editor for different computer brands. I could walk up to any computer that had BASIC in a department store, and program up my favorite childish prank on every brand:

         10 PRINT "This computer is overheated."
         20 PRINT "WARNING: Computer about to EXPLODE!..."
         30 GO TO 10
         RUN

had no idea what a pain it is to make an iPhone app. I’d tried a few times and never got beyond something that half worked. I found Apple’s programming environment forbidding.

What's missing these days is domain-specific languages (DSL). Maybe domain-specific API's (libraries) can be made better, but I have not seen it done well yet.

Domain specific languages made it easy and DIRECT to do things you wanted done in that domain, no weird-ass reverse dependency factory visitor injection design patterns or whatnot, you only had domain-oriented commands and the basics of functions, loops, and conditionals to glue them together.

Sure, they didn't scale well to "enterprise", but if that's not what you want, so be it! Global variables didn't kill kittens at that scale like "real" software engineers warn against. I barely had to read the manual when learning VB classic, Microsoft Access (pre XML), Paradox, etc. it was so intuitive and almost everything related to the domain (desktop GUI's and small-ish CRUD).

It was almost like pseudo-code! That's the secret, the closer it is to domain-specific-pseudo-code, the easier it is to learn and the less bloated the code.

Wanna make a successful tool for non-giant orgs or groups? Focus on the domain and only the domain; don't let fads and buzzwords and mega-scaling distract you.

The only "good" programming language is the language I make! Everybody thinks different and wants to optimize for different things. There is no existing language I've found that I "love"; they each have features I like but none have all the features together.

I've drafted up a language called "Moth" that has a lot of "meta power" to program block scope any way you want, as most languages hard-wire scoping rules, which I find limiting. Things like "classes", "functions", while-loops etc. would be defined by libraries, NOT the language. It's like lambda's on steroids and without bloated arrow syntax. But it may run slow as molasses, as scoping meta power adds lots of compiler/interpreter indirection.

However, it may turn out that only a few scoping rules are practical in most cases, and the compiler could then optimize for those. It would then only be slow if you are doing something "weird" with scope. Stick to a fixed known set, and things zip along. But finding that set requires R&D and road testing.

It's been neutered. Poor "g".

Already invented, it's called "porn".

Thanks for the tip! Everyone's physiology is different so one has to try many different things to see what works for them. I'll add this to my list of suggestions.

Wikipedia: "[The mantle] is predominantly solid but, on geologic time scales, it behaves as a viscous fluid, sometimes described as having the consistency of caramel."

GOP: "Oh shit, Hunter's laptop is now a pile of goo! What are we going to rant about all day now?"

I thought the Earth is rather fluid inside such that stuff gets mixed around over time. That such blobs can stay intact for billions of years seems far-fetched.

Oligopolies ruin everything. There are a few industries where they make sense, but most, not.

re: e.g. raising water or rocks.

I toldja the Flintstones were ahead of their time.

Indeed! I've long been a fan of "table oriented programming" where the common CRUD objects are specified mostly as data. You could also create them in code by calling a RAM-table constructor, so it's not either/or. Most the data fields, navigation structure, and event handlers (or handler stubs) could be readily table-ized.

Code is a lousy place to store boat-loads of attributes. You can do data-oriented transformations and filters on them if in a data structure. Hierarchical file systems are limiting and messy, because grouping by one factor de-groups another. I want to be able to "query" dev code units via SQL or similar. CRUD patterns are pretty consistent across industries such that most CRUD idioms shouldn't need custom re-invention, and thus should be attribute-tized.

You will still need occasional code-based tweaking, and this can be accomplished by having the attributes generate "runtime draft" UI markup and/or SQL clauses, which can then be tweaked via code as needed.

I'm building a proof-of-concept that uses what I call "fractal rendering" to be able to intercept the "draft" construction of screens and SQL clauses at a fine level or course level, depending on need. This avoids the all-or-nothing problem of prior attempts per attribute-vs-code debate. Ya git both! (Dynamic SQL generation should probably be avoided for public-facing sites, per injection risk, but limits the wonderful power of query-by-example.)

I don't claim it will be as performant as the code-centric approaches, but if it catches on, performance tweakers will find a way to scale it. (For CRUD apps, the performance bottleneck should usually be the database, not app code anyhow, unless you doing something wrong or special.)

The CASE tools of the 1980's and 90's started going in this direction, but were too expensive & clunky, and then the OOP push ended the idea by favoring attributes-in-code, back to square one, sigh. (CASE tools don't have to be proprietary.)

It's ripe area for groundbreaking R&D. CRUD may not be sexy, but it runs the world.