skydhash

> There are a few big projects that redirect the compiler output and attempt to print only one line per output file, so when all goes well there is much less output text, but with those it is usually more difficult to debug failures.

Why? If you use something like tee(1), you can get the full log in a file and then filter line according to what you want.

> Compiling any big software project produces far more text output than can be stored in any pty buffers.

The reason of my skepticism is that, according to your statement, reading a source file, then writing the compiled object file is way faster than a few printf through a kernel object in memory. Even for the terminal consuming the characters, parsing, and displaying the lines should not be a computation hog for most terminals

There's a wealth of packages and the documentation for emacs-lisp is quite extensive. It's not some esoteric language. But what I'm talking about is that the code for the packages can be quite simple and readable.

> Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?

I tried but most of my config is just variable settings (with the use-package macro). I don’t really have custom code there. If I do think about a feature, I tried to build a package instead (like one for bridging subsonic and emms).

Most of emacs is lisp. The actual C part is quite small considering the capabilities of the system. Lisp being what it is, it’s moslty about domain knowledge than language expertise.

> A reason why the terminal emulator speed is important for me is that I frequently compile big software projects and I find it unacceptable for a compilation to be slowed down by the low speed at which the compiler output is displayed on the terminal window

I’m strongly skeptical of this as pty are character devices and buffered. Programs and terminal are very loosely connected.

You can rewrite all of the cli utils to fit your preferences. There’s no hard standard for piping (some utility pipe binary) and bash is not a requirement either (a shell is just a program).

No need to push it to people. Do it for yourself and create your community around it.

Also no need to do it from scratch. It’s just the interface part that needs to be rewriten.

We should follows the real world model and design constant interfaces instead of wishing for a changeable one. It’s not like there’s a multitude of tasks people wants to do constantly.

You can install stuff--with tic(1)--inside your user account (you do have one, right?) and be happy that way.

This days I don't really care about the terminal I use. It's xterm on OpenBSD, konsole on Fedora KDE, terminal.app on MacOS,... As long as I can use cli and the few TUI software I use.

> It's totally fine for basic UNIX tooling, but pretty painful if you're trying to make nice interactive TUIs.

The latter seems always to be about aesthetics, not about UX.

> I just try to spend as much time as I can in a terminal

GUI are useful, but I spent so much time trying to find the perfect ones while I could quickly draft a quick CLI script for my specific problems. These days, I focus on finding libraries and utilities that solves the core of my problem, then wire them up in a way that solves my workflow. After a while, you just find that most of your computing needs are solved.

What about reliability and simplicity? First, what is your definition of productivity? Does it leans towards more output or more value.

I used Balsamiq for that. The “pencil” render of the shapes make it obvious to not discuss aesthetics issues and only focus on flows.

It’s like discussing a fully rendered concept art. You will get lost in the picture. And there’s always the slight suggestion “it’s already looking so nice, why think harder”. Which is why sketches and roughly painted thumbnails are best for brainstorming. Easier to think out of the box that way.

Same with demo. Do a rough wireframe or something with default bootstrap style and it’s way easier to target the meat of the problem. Not so much on a full site

Speaking of screen waste, I think 4:3 is way better than 16:9, especially for laptop screens.

I’ve replaced the android headunit with a buttons and segmented display one (kenwood) because it was just horrendous. Now, it’s easy to switch sources, skip back and forth, and adjust volume with minimal looking. Tactical feedback and location memory is great UX.

I have my iPhone 13 in a $10 cover for years now. I don’t like the bump, but I don’t think it’s a scheme to buy covers.

Also my favorite smartphone was a motorola with a cloth back (ballistic something) and a metal frame. No cover was needed for this one.

It’s pretty much the same. If product has no new ideas and the software is working well, then only light maintenance and monitoring work is left.

> Claude was able to identify the approach that worked, and even the long Python command that was needed. In, yes, probably about 10 seconds.

> For me to figure that out myself, it probably would've taken something like a year of study. Of the entire stack of machine learning and all of the Python tooling associated with it

It wouldn’t take that long. Maybe a few days of playing around. It’s not like you’re trying to create a new model from scratch. No need to understand linear algebra fully to learn how to do a dot product.

Same thing here. I gave up on gaming all together because my library grew too much. As a kid, I didn’t even own a console, I had to borrow gameboy or go to my friend house and even then it was just an handful of cartridges. Even now, I plan to just focus on small sample of programming languages and ecosystems, and learn them inside out. There’s just too much stuff out there.

> AI is, apparently, very good at producing proofs.

Proofs of what? Defining the problem is the part that is hard, not the actual writing of the proof.

That also assumes that your axioms are correct and the verification code is also correct. It's also a lot of work to update your system, when assumptions are challenged.

> humans refuse to spend effort on writing more formal specifications.

Code is formal specifications. It's just that programming language semantics has no domain related value of correctness. So you overflow an unsigned integer variable and got a lesser number which does violate addition rules. Or increase account A without decreasing account B, which violates accounting rules (and all kind of closed systems).

So it's up to the programmer to encode all of those rules. While we do have some tooling like type checking and memory safety, they are nowhere near enough. And encoding such thing in a language like Lean or TLA is brittle in terms of maintenance (which you do need to do as the real world evolves).

I think those are mostly technical issues (accidental complexity) and those are either documented or there should be someone experienced with the technology on your team (even if that experience came from trying it out).

Critical thinking is essential for nailing down your essential complexity (the core solution of the problem). You can try to define invalid and edge cases alongside the happy path in the pseudo code diagrams version, even if it's a TODO comment.

It’s often wild that people not building something and people not using something are trying to design it. You can’t be surprised that it’s always governed by fads and hype.

Do those RFPs come from the users or the buyers?

We had RAD tools like Access and we still have Excel. Even if they do lack some capability, you can do implement most of the core ideas of whatever features you’re trying to prototype. Actual coding is then to translate that to another platform and solve some accidental complexity.

Those core ideas are what’s valuable and they do not change often over the lifetime of a business. If the software has a good architecture, maintenance cost can be quite low.

The thing is, if you’re good at designing and breaking down problems and coming up with a good system, code is not likely an hindrance.

You can take any idea and try to flesh it out with pseudo code. Once that’s done, try to convert it to real code and you’ll see that process is fairly mechanical. This is why people says that coding wasn’t an issue for ages. Coming up with the algorithm is the hard part.

People that have an issue with coding either are not familiar with the language/platform or is trying to think with real code instead of pseudocode or diagrams.

ADDENDUM

There are techniques to think with real code, moslty the Edit-Compile-Run workflow coupled with a good editor, or the REPL workflow (also helped by a good editor). Then add a good integration with a documentation system (manual pages?) and you’re golden.

But I’ve been on projects where a dev cycle relies on a 20 minutes local rebuild or one hour CI run. So it can be very hard to try to apply those workflows to legacy projects.

> I'm going to take the contrarian view and say that formalism without jargon, friction and gatekeeping is just natural language

Try to define a specific item like the closest cat to you so that anyone, just from reading the definition, can recognize that cat anywhere. You could write a whole book and not be done. Or you could stamp the cat with some id (symbols) in and refer to that. As long as that id is not repeated (rule), the system is ok.

Formalism is defining stuff, and add rigid rules that are consistent with each other. Once that done, it allows anyone to reach the same thinking location as the original person. Formalism is a knowledge transfer tool.

> My tech career was just converting specs from clients and employers into machine code, with extra steps.

If all you did was that, I’m quite sad for you as yourself should have automated your job to remove that tedium.

I would describe my job as designing a system that respect all the constraints of the situation. Some of them comes from specs, some comes from the technical platform, and some are just future possible interactions. The system is what I modify, coding is just how I do it.

When I see people abandon their work to AI, the other consequence is that they abandon their control of the system as well. They can’t explain how it works, what’s its reliability, and whether it can be improved (or part of it reused in another context).

That’s three examples of software that are way more complex than they should have been for the general use cases.

Yes, a lot of software do continuous development, but in a more stable manner, where they introduce some features, takes time to iron bugs out, and then release a new version. Meanwhile, the users only have to care about some small security fixes every now and then. When there’s no new features (especially when you’re not creating a kitchen sink), things can be calm for months and years.

> I have observed several samples where the business, when provided with a natural language configuration opportunity, will wind up staring blankly at the textarea until the original developer gives them a complete starting point.

A lot of people lack “system thinking” when they can break down something into a set of elements and describe the relation between them. Once that done though , they can understand a part and manipulate it.

For some “system thinking” is innate. It can also be learned. But it’s a required quality in engineering where you need to create a solution where there was none.