foobarbaz33

I use emacs in the terminal too. macos, iterm2, tmux, emacs.

iterm2 has some options to fix key bind issues that hamper emacs in the terminal.

Negotiate downward. They offer 100k, you counter with 90k. they meet you in the middle at 95 then you counter 85 and stand firm there.

Develop live on production (CI/CD).

No source control, there's only 1 version of the software; the latest version (trunk based development).

You could have an lsp server of infinite speed, but that wouldn't help one bit if the bottleneck is how the client deals with the messaging.

The specific techniques used to send, receive, and parse JSON could matter.

I have first hand experience of painfully slow C# compile times. Sprinkle in a few extra slow things like EDMX generated files (not C# but part of the MS ecosystem) and it has no business being in a list of fast compiling languages.

Possibly yes. Artificially kept going by the Sun and Earth's own molten core. Once those go out out it's game over for earth.

...I keep trying because I'm hoping theres patterns I don't see.

Python's popularity is an accident of timing. If you're digging deep for wisdom and gold nuggets you're not going to find any. The gold of python is the surface level stuff. Easy to type for hunt-n-pec typers. Press tab to indent is easier than {}.

That's all it took for an army of noobs who wanted to be "hackers" to choose Python. Then they grew up, got real jobs and brought Python with them.

It's not literally the age that's the issue, it's just a correlation. Some employers want people they can squeeze more easily and get the most juice out of.

Younger people are more likely to accept orders without push back. Accept lower pay. Work 60+ hr/week for crunch time, etc.

Depends on the employer of course. Google employs an 80+ year old Ken Thompson.

Same but from a C vs Go perspective. Didn't like GC or bundling dependencies into the final binary. But at the end of the day it's still small compared to most other languages deployment artifacts. Despite being a GC language, GO still puts you in the driver seat for how memory is allocated (ie avoid GC in the first place). And goroutines are really nice to use, without introducing colored functions like most other languages do. To top it all off Go keeps the C tradition that error handling should be a first class part of the algorithm, not something hidden off to the side.

So I'm reaching for Go for pretty much everything now days.

I was coming here to say: "grep as IDE". It's dynamic language tooling 101.

Find defs and refs. Master a little bit of regex and you will reduce false positives.

Grep serves as a rudimentary autocomplete. find the definition, open in a buffer, observe fields. This is analogous to an autocomplete popup displayed inline. The buffer can now power your contextual completions, similar to an inline popup.

Web based UI's (javascript baked in) are the only cross platform GUI all the major tech players endorse. Companies like Apple are hostile to alternative GUI frameworks, except web browser. Flash? that threatens the walled gardens so the big tech cartel came together to squash it out. Java graphics? we will not ship a JVM becuase "security". The web was already ubiquitous so the big tech couldn't squash it without squashing their own foot.

Typescript let's you start with a cross platform GUI right out of the gate. Text based HTML GUI is screen reader friendly, battle hardened for many years to get accessibility right.

Type system is advanced and allows for that sweet IDE experience.

And.... the Javascript ecosystem is the only game in town that gets close to the Lisp immediate feedback experience. (no Javascript is not as good as a lisp image, but it's better than nothing). Change a function, see the result instantly in the browser while you're app is still running. I'm not 100% sure this is true for Typescript as it must compile to javascript first, but compiling the TypeScript for 1 modified file with an on-save-hook could still be a pretty quick feedback loop.

Do these reasons have anything to do with AI agents? no but it would explain why people are already using Typescirpt, and thus use it for AI agents.

Another tig user! Proof there are 1's of us out there.

C# supports structs,

That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory.

Go uses a C-like model. Everything is a value type. Real pointers are in the language. Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. That function can be used for all 3 types, no fuss.

True, but running errcheck will catch cases where you accidentally ignore the error. Maybe not as good as having it built-in to the language like Rust, but the goal of error check safety is achieved either way.

And there's a few cases like Print() where errors are so commonly ignored you don't even want to use the "_" ignore syntax. Go gives you the poetic license to avoid spamming underscores everywhere. error linters can be configured to handle a variety of strictness. For non-critical software, it's OK to YOLO your Print(). For human-death-on-failure software you may enforce 100% handling, not even allowing explicit ignore "_" (ie become even stricter than Rust language default)

Yes I think there is a bubble. I think AI may become extremely impressive but still be limited.

A lot of tasks involve having context to produce a correct solution. AI can whip up algorithms in a vacuum. But doesn't know about the custom data format you have to import. It doesn't understand how to map that to the target schema and will blindly import in a way that is subtly wrong. It doesn't have the context provided by chit/chat and vague statements made in an email.

No matter how impressive AI works in a vacuum, the "context" heavy problems are going to be an issue. Someone mentioned "last mile", that's where things fall apart. Same with self driving, it is impressive at first, until a road is blocked and there's some poorly marked detour signs routing you through non-standard paths.

Same with a plumber. You might make a robot that can fix many plumbing problems. But there's always custom nooks and crannies you have to contort yourself into and saw off a pipe in a very specific way that only having a tons of context would let you even know where to begin.

So until AI can consume context the way humans can, it's going to be limited to a "auto completion on steroids". Which is valuable, but not the end of human developers. Only time will tell.

That's a pretty good take. Would make sense for a whole range of apps focused on 1 user or client. Accounting software is personal, company A doesn't need to query/join with data of company B.

line 1: short description. fit on 1 line. put effort into making it as short as possible while still giving the gist of what was done. maybe a github/lab issue #.

line 2: blank

line 3+: long description, paragraphs, details, context for decisions made, rambling

we get customer data exports from legacy systems as CSV or XLSX

Convert the xlsx to csv. Every database system out there has blazing fast import of csv files.

As a sql wizard, I prefer to use sql to clean and re-shape data. So my first goal is to get the data into a sql DB as quickly as possible, no cleaning, no re-shaping. Just a raw dump. Now the data is in my house. I clean and re-shape the data with batch update/insert statements. Finally I batch insert to the target tables.

what’s the most frustrating

Every import job is a custom scenario. I feel special tools don't give you much. You have to understand both the source and destination data to clean and re-shape it. Tools don't have that understanding. AI is less than worthless. At the end of the day you have to roll up your sleeves and start shaping data.

You should have 0 cents. Squash and chill is the way to go.

I find it hard to judge when things are in a good enough state to commit

Work in a feature branch. Commit often. Squash away the junk commits at the end.

...and especially good enough to have a title.

Who needs a title? It's perfectly fine to rapid-fire commits with no comment, to create quick save points as you work. Bind to a key in your editor.

I treat commits in a private branch the same as the undo log of the text editor. No one cares about the undo log of your editor as they never see it. The same should be true of your private feature branch commits. They are squashed away never to be seen by human eyes again.

Free market is not a metric. It's just natural selection. No one needs to understand it for it to run its course.

If you do not trust...

Trust provides no protection.

refuse to review any code updates before installing it, then you are a moron.

I personally do review every line of Emacs code I run. But I'd wager only a small handful of Emacs users do that.

Why SHOULDN'T a color theme be allowed to scrape code from your disk?

Security.

precisely the point you are missing.

Not missing it. nabla9's suggested security measures for extensions. You then asked why security is a concern. You seemed to imply there wasn't any reason for limiting extensions if you trust the author. That's simply not true, as you can easily be sabotaged by the most trusted color theme author.

Sandboxing is used when the host is concerned about running programs that he doesn't trust.

Trust? Trusting criminals doesn't stop them from committing crime.

You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme.

You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party.

Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?

PDF has a proper "page" abstraction. Printing to paper is a first class feature, not an bolted-on afterthought.

A page in an electronic viewer will print out a to a nice and neat page of paper looking exactly the same.

Until someone invents interactive paper, the interactivity in PDF will be limited to "augmentation" of things like filling in forms, that don't interfere with the usefulness of a printed form of the document.

I mean the point is missed in your response. You're talking about the current state of LLMs, but the premise of the question is a "what if" scenario where AI successfully takes over our jobs.

There's no need to define intelligence to point out the misinterpretation of OP's question.

If any algorithm can take over the “engineering”

Well it's already happened. Mindless, lifeless carbon orbiting around a star iteratively configured itself into a machine capable of creative thought. Our human brains. Unless there is some unknown missing ingredient (divine intervention, souls, etc) it may be possible to create new intelligence.

If you ask this question - you fundamentally don’t understand the essence of engineering.

Current LLM's, sure just a tool. They may not be "real" intelligence by some measure of "real".

But the premise of the question is "what if" we do achieve the real thing and it can take over any thought process a human is capable of. With means to observe surroundings and think outside the box, just like we do.

Keeping the mini line alive is good news to me. It's the low cost pathway into the M-chip apple world. I only work at a desk with full monitor/keyboard/mouse so I don't want to pay a premium for laptop form factor.

Much plastic recycling is a sham.

1st world business pays 3rd world business to take their plastic for "recycling" (mandatory air quotes). The 1st world gets credit for being a responsible environmentalist. The 3rd world business then dumps the plastic in a river or other convenient but totally not enviro-friendly dumping spot.

It's sort of an open conspiracy at this point. Putting your plastic in the trash may be better for the environment overall.

Errors as values are winning the mind share war for new languages.

Even if you just pass the error up the call chain, it's good to have that explicitly expressed in the code. For critical software Error paths should be fist class citizens of the logic, not some "magic" path that may not be expressed in the source at all.

mechanism to remove them – if they've been found to have violated the CoC – is seeking a vote from the full Python Community. This is undesirable, because it would "subject members of the community – including people directly impacted by that violator's behavior – to undue distress.

So... down with voting, up with secret police? Wouldn't want to stress the commoners with the power of a vote.