So, I enjoy creating front ends to automatically generate cadd drawings for me. It’s like a lucrative hobby. I started doing it in the early 2000’s using Visual Basic 3, Microsoft Access and AutoLISP. Not cartoons, mind you. Anyone can distribute a generic drawing with notes. That’s not what I’m talking about. A front end so that anyone without cadd knowledge can create a fully vectorized 2D drawing made in seconds and accurate to eight decimal places. I have hundreds of front ends that I use when I need to. I can surely feed it bad data, but it’s faster and never forgets to carry the two. It’s such low-technology, any version of Autocad will do. I still use my version 2010 at home, but they all work with version 2023.

Here is part of a video showing one of the front ends in action (though the audio had to be removed). This is a custom front end in Visual Studio 2007 (with my ultra nerdy paint dotnet/autocad graphics because they refused to give me photoshop) that accepts user inputs for a finished drawing of a self-supported brick dome. The calculations for these domes, if doing manually, takes about an hour per course and domes would tend to average about twenty courses. This required three days worth of math you had to write out for your checker, and then one more to actually make the drawing and bills of material. Checking took another day in most cases, so essentially a week to get a quote out. I changed that process to seconds.

In the video, you see the data entry for the dome geometry and skew line (the base the bricks rest upon) Then, the brick shapes permitted to be used are defined by their chords. In this case, it was a 9x4.5x3 series set of up to five arches and wedges in each of two keys. When used as intended, they create a 9" thick spherical dome. It calculates the best fitting key (4.5"-4.5" or 4.5"-4") and then calculates a three piece combination of arches (3" on the outside tapering to up to 2" on the outside) and wedges (also 3" on the outside tapering but up to 2" on the inside) in a ratio that best forces the ring to close. It then iterates over the courses from a specified starting end until it completes naturally or the geometry becomes a mismatch for the bricks turning potential at a certain spherical radius.

It then creates two reports, a count report and a math report (all engineering documents required checking at the time.). BUT (here’s the nerd coolness) it remembers ALL that glorious data it did during the calculations, and builds a custom lisp file with it, which can then be run on an empty drawing to generate the full vector content, as you notice, pretty quickly. To fully check it, I had it generate a top, front and bottom view as well as the brick count in a handy dandy lil chart. It overwhelms the lil laptop I had to use as it draws EVERYTHING except dimensions (though I would eventually nail that down too). I perform the generation process twice, slightly changing the skew to achieve a different combination.

As a note, the drawing portion became the actual check. You will clearly tell if there is a problem with tilts and closure by just looking at the finished cadd vectors since they do capture the bricks real world symmetrical posture. The math report itself generates a series of checks to ensure the count is appropriate. Volume check, four-point circumference check, key checks, anti-straight checks, negative quantities. Lot’s of crazy things happen in the formula when the bricks aren’t able to find a valid solution to the geometry.

So, I think I make a valid argument that when used properly, AutoLISP is possibly one the best tools an Autocad designer can employ, and it has the potential to outperform any modern cadd program that’s packed with features you’re paying for but never using. In the time it took you to read this, CREO and Inventor are likely still booting up, and Solidworks is having license issues again.

What “spin” are you talking about?

Who is marketing C++?

I don’t fully understand the question, to be honest, but would a purpose-built language like ActionScript qualify? It served only one purpose, and (debatably - AS3 was alright) served it well.

Otherwise, every general purpose language attempts to serve all its uses at once, which means they rarely specialize heavily into one particular domain. For example, while Rust’s stdlib devs could build a HTTP library, many Rust users don’t need one, good community-maintained libraries exist, and the stdlib devs don’t want to sacrifice stability with something that requires as much churn as a HTTP library needs. It serves their goal of stability really well, but requires extra steps from users who need that.

Of course, Python. Just look at the TIOBE language popularity index. The top languages all have some rational for use. Not so popular have less reasons to use or just narrower application range. See https://www.tiobe.com/tiobe-index/ .

Dunno. If it fits the purpose and you get a lot of libraries and tooling around your specific domain… Why not make use of it? Python is easy to learn and has a lot of nice stuff for data science. Or R for statistics… Considering the absence of other complete frameworks when doing embedded programming… wouldn’t you just use C++?

Maybe I don’t the question. Programming languages are never perfect. Nor good for one specific and confined task… They all grew, picked up quirks. Or inherited burdens. People are trying to do 5 million different things with them at the same time… I think I’m more concerned with their usefulness and actual application, than their marketing material.

And some of the stuff they did in the 50s, 70s, 80s and 90s, when these programming languages were designed, is just a bit weird by today’s standards.

Counterexamples.

A simple language like Lua, whose advantages in actually building software rather than homework-level coding are well-documented, and borne out by well-received web servers, editor extensions, network software like Snabb (and Adobe something).

A platform language like Erlang that is not just simple to code in, but also has a mighty capable runtime. Demonstrating the value of that combination are the impressive networking and storage apps shipped with the platform, apart from actual software wins in the wild like ejabberd, Pleroma/Akkoma, etc.

An idea like Objective Smalltalk, which tackles software architecture head-on. https://objective.st/

Ditto for Smalltalk and Lisp.

Squeak Smalltalk and its evolutions, Pharo and Cuis, get talked up for being easy to program and re-program, but the closest to being a useful app is recent: the DrGeo rewrite. Others like Glamorous Toolkit and various proprietary developments with Cuis don’t lead to any useful outcome.

Lisp with its macrology is deified, but its most used variant, Elisp in Emacs, is confounding in terms of comprehending the runtime behaviour of features and in the debugging of what doesn’t work. Guile Scheme has so much written about it, but Guix is just about its only success.

Just as an example, neither the C++ documentation nor its sagely bloggers have ever shown why it is a good fit for, say, systems programming. A really neat way of handling bit-level data is actually in Erlang’s bit syntax.

Separately, I spluttered when I realized that Boost includes 2 statechart libraries which proclaim the approach is widely useful, but nothing else in Boost uses it - not asio or its ilk, not the parser libraries, not the graph library.