fastest recompilation statically typed language/paradigm?

[Raoul Duke]

how best to reduce the lag/delay/suck of efit-compile-wait-wait-ohtyposhoot-repeat ad infinitum?

[David Barbour]

Incremental compilation, i.e. the ability to reuse cached outputs from prior compilation efforts, can significantly mitigate compilation cost issues because we usually edit only a small part of a program before recompiling. 

Unfortunately, the granularity of 'modules' is not adequate for languages that use a lot of metaprogramming or compilers that perform many cross-module optimizations (such as inlining and constant propagation across abstract function calls). 

So, I've been approaching this with the idea of supporting explicit memoization of functions via program annotations. This would also apply to compile-time functions, e.g. maintaining a persistent memo-table based on secure hashes of the functions and their parameters. Programmers could use this feature for metaprogramming (macros, templates, static eval, etc.). Compiler writers could use it within optimization passes.

I don't know how well it will work out, yet. I haven't gotten that far in my language implementation, so it's still just an idea. However, assuming it works out, this would suggest a functional paradigm - at least for the compiler itself - is a very good idea because we cannot conveniently take 'secure hashes' of or memoize mutable object graphs and inputs from side-effects. 

[Raoul Duke]

handwavingly, take a slow to recompile mainstream language like swift, how much final runtime performance is lost if we stopped doing slow things like slow optimization passes in the compiler?

which existing languages & paradigms give us the best perf there? i assume it ends up being reductio ad absurdum: writing in assembly. 

are there better sweet spot goldilocks languages?

[David Barbour]

I know that languages such as Rust and Red are both in the goldilocks zone. Both of them have developers that pay a lot of attention to compilation times.

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAJ7XQb7Oni3GbKcjgO3t_wHqHbx4fpw376VDmnp01_P9Ks8X-Q%40mail.gmail.com.

[paul tarvydas]

Oh, the irony!

The premature-optimization clique convinced programmers that interpreters were "too slow" and that compilers should be used instead.

Now, 50+ years down the road, we find that premature-optimization has resulted in:
- workflows that are too slow
- Mb of bloatware
- techniques that are so complicated that they can't be explained to the majority of professional programmers (think website makers, game makers, JS crafters, etc.)
- acceptance of buggy products - programmers just ship and update weekly, forgetting Q/A

The implication is obvious:
- don't use compilers until you have designs fleshed out and fully working

Use compilers only when you need to Production Engineer a Design.

Failing that, buy a faster development system and keep complaining...

[more discussion here](https://publish.obsidian.md/programmingsimplicity/2022-06-06-Compilers+Too+Slow)

[Raoul Duke]

meh, "we" can inevitably make bad build systems for anything, trust me. i know plenty of interpreted environments that started out maybe less bad but hardly ideal. the entire js ecosystem is not that great. any setup lacking good safe robust hotswapping is already a dunderhead i feel. and ocaml or haxe sure do 'compile' things fast. 

i think it requires not doing bad things death by a million cuts at all levels. 

eg a certain build i am forced to use is slow extra because one or more of the build steps are stupid and always run. 

so i'd wonder more about (a) culture (b) language paradigms and (a again)very picky software engineering angles on it. i mean, why do we inevitably create bad (slow) build steps at all?

[David Barbour]

On Mon, Jun 6, 2022 at 1:04 PM paul tarvydas <paulta...@gmail.com> wrote:

The implication is obvious:
- don't use compilers until you have designs fleshed out and fully working

There are a lot of languages that support this, i.e. using an interpreter or JIT-compiler during development then switching to ahead-of-time compilation with full optimizations for a deliverable. Even Haskell's GHC has an `-fdefer-type-errors` option, which turns type errors into runtime errors to simplify rapid prototyping.

[David Barbour]

On Mon, Jun 6, 2022 at 2:08 PM Raoul Duke <rao...@gmail.com> wrote:

why do we inevitably create bad (slow) build steps at all?

Have you heard of Parkinson's Law? 

[Raoul Duke]

>  of Parkinson's Law? 

i just dream of mythical systems that do a better job of making more people fall into the pit of success and good code instead of what all my day jobs have been like :-)