ltta

Totally agree, ML-style languages are great for writing compilers.

I tried to get into various CAD applications at various points in time and never managed to "get it". It was mostly about the interface, you just have to invest a lot of time (more than I was willing to spend) to get even remotely useful results.

OpenSCAD on the other hand immediately clicked - at least for me as a programmer. I just had to look up the available primitives and combine them to my liking. This totally jibes with my mental model of the thing I want to build and parametrizing your models is pretty easy.

My main gripe with OpenSCAD is that it is missing good features to generate more "organic" shapes, i.e. beveled edges and rounded corners require a lot of work. They are possible (i.e. with Minkowski sums) but the resulting complex shapes quickly bring the engine to its knees.

OpenSCAD is decently reliable up to a certain amount of objects/vertices. Once I reach a limit rendering becomes too slow and sometimes makes OpenSCAD crash. What I ended up doing is to model individual parts (which is a good idea anyway, and OpenSCAD parametric modules work great for that) that I render to STLs individually, then import the STLs for everything but the part I am working on.

Speaking of SSA and optimizations, I just remembered that Andy Wingo (core contributor to Guile scheme) has a treasure trove of great articles, e.g. a fun intro to SSA [1] or CPS as used in Guile [2]. His blog is totally worth just browsing around.

[1] http://wingolog.org/archives/2011/07/12/static-single-assign...

[2] http://wingolog.org/archives/2014/01/12/a-continuation-passi...

Much of the frontend is pretty much the same: parsing, semantic analysis, type checking. LLLVM mostly comes into play when generating the code. Instead of generating assembbler or opcodes directly, you call into LLVM to create data structures that represent low-level code and then a final call to gen machine code or JIT.

There are several versions of the LLVM Kaleidoscope language tutorial where you build a compiler that supports numeric operations, it is often based on Pratt parsers (at least the official C++ version[1]), but there's a C version on github [2].

In my opinion, you could get pretty far by reading the "Compiler design in C" or "Modern compiler implementation in C" up to the point of optimization and then applying the code generation from kaleidoscope tutorials. LLVM takes care of many optimizations.

[1] http://llvm.org/docs/tutorial/LangImpl1.html [2] https://github.com/benbjohnson/llvm-c-kaleidoscope

If you are interested in a printed version of a great beginner's compiler book, I can highly recommend Andrew W. Appel's "Modern Compiler in C". There are also versions of the book written for SML or Java. I have read and partially implemented the C version and I really enjoyed the book, basic enough to follow yet full-featured enough to be useful.

The book starts with parsing (I prefer PEG or Pratt parsers for their simplicity (and tool independence) to be honest and skipped some of that chapter) but then goes into semantic analysis, type checking, code generation, optimization passes, even mentions basic type inference.

There is some code online at http://www.cs.princeton.edu/~appel/modern/c/ .

This is not necessarily a language-level decision (except for GC, it helps in this case spread out the deallocations when using incremental GC).

You just have to be aware what happens in the destructor when you manually free an object. Libraries can make knowing this more difficult.

I guess you could build incremental alloc/release pools (even with reuse) or such things but it comes down to being aware of the problem as described and avoiding cascaded releases.

And to be honest this is not a super common problem but it can happen.

Modern architectures really necessitate a good understanding of the instruction pipeline and caches to squeeze out the best performance.

If I remember correctly, Python's hashtables are initialized with 8 buckets that are linearly searched and then switched to a real hashtable implementation when grown past that size.

I have worked with the L4 microkernel where sooo much emphasis was put on keeping instruction and data footprints as small as possible every time the kernel is entered in order not to dirty i- and d-caches.

And I have also seen game engine developers do amazing things in this regard. An interesting development in the gaming space is data-oriented-design that deviates from OOP among other things for performance and parallelization. See http://www.slideshare.net/mobile/cellperformance/data-orient... (though I don't agree with the three "lies" mentionened, I do like the data-centric approach).

And also check out this paper comparing reference counting and GC, and the accompanying discussion on LtU.

http://lambda-the-ultimate.org/node/2552

(Although I think the paper has problems and bias)

As far as I know ARC (like manual memory managenent) can lead to release cascades that can also cause application delays in games eg. Something you have to watch for. Malloc() and free() and equivalents do quite a bit of work under the hood (check today's linked tcmalloc article for example) that takes time.

Smalltalk is a little shrewd in some ways as outlined here. Self has already been mentioned as a great alternative (and the related papers are amazing IMO and influence most modern JITs).

But there are some other really interesting alternatives that IMO keep with the spirit: Io (io-lang.org), Ioke (defunct now, ioke-lang.org - some awesome ideas IMO) and Squeak which is being actively developed.

I'd recommend checking out some of these, I think you can easily install io via brew on Macs and used to be able to install joke as well. They improve syntax and/or add significant language features.

Java probably won because of its C-inspired syntax. At that point smalltalk was falling behind and C++ started to take off. To me Java was always meant as a better C++. At least that is my guess.

A lot of the people behind Self went on to work on the JVM JIT and later the Chrome V8 engine. Self produced many influential ideas in the JIT space like polymorphic inline caches and deoptimization and stack rewriting. Some of the papers published by the Self group at UCSB are fascinating.