Comment by imgabe | Hacker News Reader

Comment by imgabe | Hacker News Reader

Parent Full thread

I can't speak to every field but in Architecture/Engineering the software became a lot less power user friendly with the switch from AutoCAD to Revit.

AutoCAD had a command line. You could pick commands from the menu, or type them directly. You could make shortcuts for the commands. From there it was a short jump to stringing together several typed commands into a short script. There was a built-in scripting language (AutoLisp, a lisp dialect). The command line was also a repl, so you could type snippets of code and execute them on your drawing and see the effects immediately, making it easy to experiment.

Revit has none of this. Everything is menu driven. There is a macro system, but you have to go hunting for it. There's also a way to build add-ons and extensions by downloading an SDK and learning C++ or C#, but that's not really the same as making a quick script to automate some repetitive task. There's no command line. Even the newer versions of AutoCAD hide the command line in the default configuration. If you don't know to go looking for it, you'll never find it.

I used to know an AutoCAD pro and watching him work was magic. He hardly ever touched the mouse and could type house plans about as fast as I could follow along. It seemed that a great knowledge of the commands combined with some mental math and an uncanny memory for multiples of 12 and 16 worked wonders.

As someone who only has an uncanny memory for the powers of 2... what's important about 12 and 16 in house drafting?

Houses built with wood will place the wood at regular intervals. Walls are usually built with the boards at 16 inch intervals while floors are usually 12 inches and roofs may be 12 inch or 24 depending on loading conditions.

In order to be able to type a house you need to know the multiples of 12 and 16 up to about 30 or 50 x 12.

Also, angles in degrees lean heavily on 2, 3, and 5, and 12 can frequently be found lurking in that crowd and serves as a useful signpost in that way.

My grandpa was an engineer who used AutoLISP a lot to automate away a ton of work they were having to do back in the 80s and early 90s, his coworkers loved him because he got menial things done easier for everyone. I could only imagine tasks like what they were doing involving complex fluid mechanics to be something you'd have to have a programming environment to get at.

Serious apps should come with event logs and command lines, period.

Correction: Event logs should be transaction logs instead and you must be able to travel through it reverting and re-applying actions. It should be branch-able and allow you to jump between those branches.

I can do that with Emacs. What other tools make it easy to branch in history?

For small values of easy: vim. (It is really easy to do I think, doing it correctly instead of just being clumsy and hitting some key that starts it, that is the challenge ;-)

I only learned now that emacs could do it.

I didn't know that vim could do this! I've always assumed that undo/redo (u/^r) were my only options.

For anyone else who didn't know, try ":help undo-branches" or take a look at https://vim.fandom.com/wiki/Using_undo_branches , which has a simple example of use.

GIMP.

This is one thing it does very well, it beats emacs hands down in history visualization (at least without undo-tree, I've never tried it).

Emacs branching got way better with undo-tree, check it out :-)

I feel like from a design and architecture point of view, building an application with the command line as a first class citizen will ensure that the application is well designed.

It ensures separation of concerns is at least minimally applied in order to support two separate presentation layers (GUI & CLI). CLIs are also much more testable in general, so usually it’s easier to write e2e tests if a CLI is present. It might not cover 100% of the code because it doesn’t test the GUI, but does often get you something substantial like 90% of the way there.

It depends on the application, but CLIs can make testing GUIs easier in two ways:

- you can test the rendering layer in isolation by using the GUI to display two pieces of information manipulated by the CLI and comparing the renders, eg blank screen -> add some object.

- you can comparison test the GUI, eg pressing button X produces the same result as CLI option Y.

Properly testing a GUI requires having an internal CLI, in places I’ve worked — eg, app companies.

Have you ever run `rm -f important_doc.txt` instead of intended `rm -f important_doc copy.txt`?

It doesn't matter if it is GUI or terminal interface, software must be _humane_, forgive mistakes and provide a way out. As much as love Unix coreutils and have them in may fingertips, those are the least humane programs I have ever used.

Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.

> Surprisingly, git seems quite humane, even when you screw things up it gives you a lot of safety mechanisms to recover.

You have to earn it. I admit that when I started using git sometimes I made a copy of the repo just in case I ended in a state that made it easier to nuke it and start again

"cp -a" was definitely a huge boon to learning git. Fear-free experimentation is a wonderful thing.

A copy of the repo really? I just check in everything in a new commit then write the SHA1 somewhere.

The point of taking a copy of the repo is that you don't have to use git itself to get back to a known state, which is important when it's a tool that you're experimenting with and you're not sure on its use.

There's also a psychological element to it. If you can verify for yourself that the repo can't possibly contain anything that would mess you up after an earlier mistake, it's much easier to do things than if you have to worry about using the wrong branch name when you don't know how to delete branches, for example.

I totally agree, as long as that interface gives users knowledge as to how it forgives the user.

I use a Mac for work, and one of the first things I did was to alias `rm` to the utility `trash`[0] -- instead of immediately marking the bytes as free like `rm` does, it'll move the file(s) to the system's trash can.

[0]: https://hasseg.org/trash/

Yeah, user facing filesystems should be change-based, and require elevated permissions to permanently delete data.

The problem is that filesystems don't get enough love. There are plenty of more fundamental problems that aren't going anywhere, so do not expect this to change.

It implies that the application is made up of commands, which leads to a healthy separation of concerns.

I'd take a bit less of an absolutist standpoint myself, but, designing your application so that it has this event log (Command design pattern from back when, but I'm sure it has a more modern name nowadays) and its functionality is separated from its user interface are best practices.

Reply on news.ycombinator.com