thinking in terms of composing 3d objects and their positions is 90% of doing CAD already, if you can do that, you can reproduce any of the objects in OP with 15 minutes of learning the tool
seriously, I think people overestimate how hard basic CAD work is
> seriously, I think people overestimate how hard basic CAD work is
I think this is one of those things that programmers overestimate worse than non-programmers, too. To the point that they reject CAD UIs too early and get themselves stuck in often rather limiting code-CAD environments, because they never get to learn how parametric GUI CAD works.
This belief that only code can be intuitively parametric is obviously not something that non-programmers suffer from.
I think code-CAD has many benefits (though the idea of the various LLM-to-OpenSCAD tools out there makes me shudder; this is the worst possible combination of obscure knowledge-bases).
But just a trivial amount of time learning even FreeCAD (the least-intuitive CAD package, pretty unambiguously) unlocks so much potential.
It does take experience but mostly it takes a little analysis.
I'm still really quite green at CAD; I've come to it late in life and I only make relatively simple things, perhaps; only simple mechanisms.
But when I look at people getting stuck and asking for help in CAD groups it so often comes down to the knock-on effects of very early mistakes, like squandering the benefits of the base planes by choosing the wrong initial orientation, muddling through with primitives when an extrusion of a sketch would do the job, or making a series of complex circular pockets when a single revolve could have done it better.
Basic familiarity with a few principles and their expression in CAD, and a little study of existing objects gets you a long way.
It interests me that programmers are willing to learn the expressive nuances of individual languages or libraries or methodologies, but as soon as it comes to GUI CAD they dismiss the whole thing as too hard or too obscure. The excitement around LLM text-to-CAD seems emblematic of this; as if the wrong conclusions about GUI interfaces have been drawn from bad experiences of dev GUIs.
Asking me or folks that do what I do to create a hardware product that way would be like asking a sculptor to sit down and write NC code for a marble router to cut out the sculpture they see in their minds eye.
When we're using these tools, Solidworks in my case, we're not just clicking with the mouse. We're typing complex commands, creating and using variables, creating scripts and macros, we often use gaming mice with many buttons mapped to complex hockey's, etc.
The graphics interface is just part of it, the part where it shows us 3d geometry so we can put it into our minds eye, and a way to tell the computer what geometry we are talking about before we execute work using what I described above.
Most people don't get it, if you do you do. You do.
The first three parts are just simple extrusions of a 2D sketch. The fourth and fifth parts can be designed with one extrusion and a cut. They are by no means complicated parts.
A beginner using FreeCAD or Fusion 360 can start learning today and will know how to design all those parts by the end of the week.
Oh man, if only it were that simple. A floorplanner has to guestimate what the P&R tools are going to do with the initial layout. That can be very hard to predict -- even if the floorplanner and P&R tool are from the same vendor.
Really? I think an extraordinary claim like "eliminating a whole class of problems makes applications no more secure in general" should also come with extraordinary evidence.
The point of the person you're replying to is that JVM software has far fewer vulnerabilities than it would have otherwise.
The number of CVEs reveals that there is a lot of Java software and that there's a strong culture of importing dependencies. But we also care about the nature of them, the normalized relative frequency of very serious flaws like RCE exploits.
A CVE list says nothing. I made my own language which has no CVEs, that obviously doesn't mean it's secure. The relevant metric is "CVEs per unit of functionality".
This is a nonsense statement unless you note the Java runtime. Java is a language. The runtime is the software that runs the Java code. There's more than one runtime.
My anecdotal experience with mediatek wifi is it's a very flakey, low quality brand. That might be more of the reason. The firmware is probably unpolished, rushed, not maintained by competent people.
In jurisdictions whose ISP laws I'm familiar with, ISPs have a special protection granted: they don't get raided because they're seen as an infrastructure provider, but only as long as they can point to a customer responsible for some given traffic when served a court order.
I don't really get why this is a TUI. Any time I actually hack on this sort of stuff, I'd rather have the outputs (eg. symbols, ELF sections/segments, strings, ...) directly on stdout so I can then further filter stuff or otherwise process it. Especially strings!
The only part of this tool that seems to merit a TUI is the hex view...
Sometimes you really want to make a TUI videogame but can't think of a good roguelike design so you just start hacking away at what you're curious about.
I can see this tool being a fun introduction to many things you would normally want to keep as separate tools you can glue together, and was probably also just a chance for them to exercise the TUI library they also created.
The creator is a maintainer of a major Rust library for writing TUI applications, so it's almost certainly a just-because rather than something that is intuitively or practically better as a TUI.
I should add - the fact that he dogfoods the library so frequently has no doubt improved the library a ton even if he never produced anything useful, which isn't true either. I'm glad he does so.
One of the biggest benefits of a (good) TUI (or GUI) is that it guides someone who doesn't already know exactly what they want to do towards the most relevant information and the most common actions. Once you already know these things, it is usually faster and more powerful to work with code instead. With this TUI, someone who doesn't know very much about the internals of a binary gets that information presented them in a way that helps them learn the parts of the file, and their relations and relevance.
It is also easier for many people to remember how to navigate a GUI/TUI to achieve a task than to use the CLI, likely because it makes use of the parts of our brain for navigating space. This often makes them easier to use for tasks that you only do occasionally (at least until you learn how to take good notes, manage snippets, and work with your shell history).
So why a TUI instead of a GUI? Probably mostly for aesthetic and comfort reasons than for utility reasons - but I prefer staying in the terminal if possible, as I have a lot of control over its appearance and behavior, and TUIs generally have much better keyboard support than GUIs.
> So why a TUI instead of a GUI? Probably mostly for aesthetic and comfort reasons than for utility reasons - but I prefer staying in the terminal if possible, as I have a lot of control over its appearance and behavior, and TUIs generally have much better keyboard support than GUIs.
Also it is much easier to run remotely and doesn't need half a gigabyte of dependencies making it easier on a VPS etc
> It is also easier for many people to remember how to navigate a GUI/TUI to achieve a task than to use the CLI, likely because it makes use of the parts of our brain for navigating space
I'd be very very surprised if this were true for everyone. I'm certainly more symbol oriented than visually or spatially oriented, for instance, and the ways I AM spatially oriented doesn't map at all to common user interface elements.
Besides, many of the best interfaces (eg magit) aren't spatially oriented at all.
That said, I'll never complain at more interfaces even if I do prefer a query-and-response style interaction.
Great reply about TUI/GUI vs CLI! Well-designed TUIs help teach and navigate the mental model of a situation. I try to also have a CLI available for the TUI that helps extract data for terminal pipeline use. You can even have the TUI tell you what the CLI command would be.
> So why a TUI instead of a GUI?
Also, TUI is available in constrained environments and over SSH/serial.
NB: the author's GitHub contribution graph is pure green for several years! https://github.com/orhun
You can even have the TUI tell you what the CLI command would be.
Most of the weird corners I know about Git workflows are because Magit offers the ability to explore via TUI but then see the literal command being run.
does this offer a programming api? what I think is the sweetest approach is if there's a tui/gui to explore and find what you want, and then click a button and have it dump a bunch of code that would achieve the same thing - so now you can play around with the api instead.
Sometimes you find yourself looking for a piece of info over and over again, and you'll lose something in stdout you think you'll remember as you do further analysis.
Ie for this, switching between readelf and objdump options, a handful of operations are already getting you 1000 lines into scrollback. I imagine having one terminal with this up and pre-parsed could be useful on the side while doing other analysis.
I always forget the precise flags for readelf/objdump etc., and in practice I do something like `readelf -a | less` and scroll until I find the info I was looking for. Scrolling around in `less` is pretty cumbersome for large outputs, and I wouldn't mind a TUI for it.
(I also forget the difference between a segment and a section, but I know what I'm looking for when I see it, heh)
reply