Hacker News Reader

Comment by tormeh | Hacker News Reader

What I've come to realize is that what we need is a language that lets you manage your level of technical debt, as in "langc mysource.lang --technical-debt=5". You generally want to start out writing PHP in the beginning of a project. However, at some point the technical debt will force you to enter maintenance mode. At that point it would be nice if you could turn down the compiler's tolerance from PHP-level to Rust-level, via Python and Java. Simultaneously you usually start caring about performance, so you need to move from interpretation to non-GC'd binary. Wouldn't it be nice if you could scale the strictness and compiledness of the language according to how messy and performance-critical your module or program has become? Granted, we'd need several backends for the same language and the compiler would become really quite messy, but it's interesting to consider.

View on HN

Few points should be mentioned here, mostly because [non]strictness and dynamicity are not the same.

Tunable strictness is already there for languages that use type inference (and nontrivial type system in general). Haskell, Terra, Julia to name a few. In terra you even have two separate worlds and the border is strict; static side doesn't poison dynamic side. Otoh, in haskell once you fix a type, all calls are specialized, so careful typing must be applied even for cases that really never happen.

Dynamicity is the other beast. Dynamic code is not one that was written in dynamic language, but one that uses dynamic approaches to the problem. Metaprogramming, functional programming, complex dispatch programming cannot be converted into efficient code without providing special hints to the compiler (iow writing c++ code). Even jits usually give up on meta paths and provide little-to-no benefit there. So in general we can't convert really dynamic code to its efficient static representation. Otoh, if the code is not so dynamic, then type inference will do everything right for it, no type magic needed.

Edit: I forgot to add julia's details, quick intro is here: http://stackoverflow.com/questions/28078089/is-julia-dynamic...

Larry Wall tried, with some success. A Lisp / Scheme codebase could also be transformed along these little nest.

Can you please give more context on what Larry Wall tried?

Larry Wall created (or, rather, kept on creating) Perl, an ultimately multi-paradigm language, allowing for wild differences in style, approach, and even syntax. (Yes, this does create problems, too.)

I can't agree more. I think a lot of the pieces to enable such a compiler stack are there--gradual typing, extensible parsers, and so on, but nobody has put them all together into a single place.

Common Lisp? Except that the typing could use some extension (probably could be provided through macros).

Gradual Typing is a specific term, what you are looking for is optional typing.

I had a similar thought when using Clojure or Python: as the project matured I wished I could switch to some static typed language. I am very interested in language conversions, so I should give this a thought...

It's called Cython. I had a Python implementation of a sensor fusion algorithm as well as a C version of the same. Python was a staggering 135 times slower. I used Cython on it, typed a handful of variables and the result ran in the same time as the C version.

The speed up always depends on what you are doing, my example was chosen to yield the most extreme differences.

I think the idea of mixing between an interpreter to a Compiler (either or JIT) is a bit stupid.

The only way to realistically be able to statically define an api boundary, then implement library-dependant static analysis inside the language. This is already possible with today's tools except that most languages can't guarantee compile time evaluation or provide enough static reflection.

I'm assuming that by "scale the strictness", you don't mean optional lazyness?

Reply on news.ycombinator.com