SA9G

We should immediately deactivate all particulate filters and DEF injectors on large trucks!! Problem solved :-)

My first language, 1980 in CMU, was Pascal... quickly followed by LISP in CS/AI courses and C for EE courses. I was a big fan of MacLisp at the time, the MIT version that GLS worked on (could see his comments all over the sources). Of course GLS moved on to Scheme and wrote a few definitive papers on closures. Yeah, that was before PC's everywhere... a loooong time ago. (C++ came years and years afterwards, not a fan. I would have stayed with hardware if the ++ version of C was forced on me all those years ago.)

GLS moved to CMU in the early 80's... I remember taking "Comparative Programming Languages" from him. Good teacher and impressive guy. In addition to the obvious, he also covered SNOBOL and APL in that course. Memories :-)

I love the "Tornado" term and "software debt"... worked with a few over the years, fixed the bug but broke the paradigm. Well articulated wisdom.

Biggest problem in working at home: neighbors giant barking rodent!

Lower and lower S/N on the internet.... and businesses adding to the N so they can charge for the S. If enough become aware of this, they will vote with their $$ and Amazon (et al) will lose market share. But sadly the TicToc generation doesn't seem to notice :-()

If by "bold" you mean daft, then you are right :-)

Mark/Sweep GC is easy, well contained, and simple to test. RefCounting affects everything, obviously does not work for circular refs, and is an incredible pain to test/debug. While RefCounting gives you generally continuous smooth performance, it can stop the world if a particularly large/complex data structure is being collected. So all in all, I would skip RefCounting next time. (scScript does have a compile option to turn it off.)

Yes! That is why the 3rd line says: "...or to see sample code (Intro 1)." You just had to click on "Intro 1".

No (scripting) language with 2 parameter lists, the second all Var (to use the Pascal syntax). I could have included a Var keyword instead to differentiate, but a) that would complicate the variadic nature of scScript parameter lists and b) didn't quite look C-like to my eyes. (Then again I also have two Map functions in there for arrays and dicts.... so I should not claim purity.) (Yes, I stole them from LISP :-)

So you want to generate C code instead of ByteCodes.... and then compile the C? I suppose, if you broke out the runtime memory management (and a few other things) into a library. But I am not sure why you would....

If you want pure speed, then you would rather have it generate machine instructions instead of higher-level ByteCode ops. But you would not be using a scripting language if you want pure speed.

Perhaps if you only want a double-arglist variant of C (you must call it scC!) then you could write a front end processor! And by you, I mean not me :-)

May Odin smile upon you :-) And thanks for not laughing at my art!!

You could run C that way... but scScript is a scripting language using C-like syntax with features designed for scripting. For example, it provides dual variadic parameter/arg lists. Turns out having "in" (pass-by-val) and "out" (pass-by-ref) parameters are more pleasant (at least to me) than trying to return N values out of a function (especially since script languages run away from pointers). Perhaps it is a testament to my ignorance, but I am not aware of another language that does this.

The difficulty in designing a language is not so much implementing a compiler, but the iterative process of implementing and fine-tuning a given aesthetic... a given flavor as it were and it has to work well. Of course the other side is testing the damn thing... so my hats off to QA!

Nevertheless, I am sure good tool users could save a lot of time instead of hand implementing everything, as I would. So thumbs up to LLVM.

I wanted to write a love note to C... and if you hate it, it is all my fault.

Capital needs a safe harbor, so there is always demand for treasuries.... But on the other hand, we all know these debts will never get repaid, just traded and rolled over into the next batch of bonds. Government will also do all it can to keep interests low, including the treasury itself buying its own debts and setting them aside. 40 Trillion is hard to conceive... ok, I think in terms of address space anyway :-)