Are “jets” a good idea? (2017)

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

by networked • 8 years ago

97 75 8 years ago

lambda-the-ultimate.org

paradroid3• 8 years ago

This is basically asm or microcode at a higher level.

theoh4• 8 years ago

It's the opposite.

paradroid3• 8 years ago

That's a stretch. If the only dimension you care about is whether or not the language spec is guaranteed to be invariant, sure, but that's essentially nitpicking. One more layer of abstraction gets you an asm->asm transpiler that never changes.

Jach• 8 years ago

Yeah I was pretty sure I've seen this in both Nim and Common Lisp, but don't compile-time macros in general allow for this? A comment even mentions source-text replacement with C functions. So it seems like the "jet" is just a type of macro that is formally specified to behave as a pure transformation...

derefr6• 8 years ago

If macros are "GOTO", a jet is a "COMEFROM". A programmer knows they're calling a macro, and expects that code to change. A jet, meanwhile, affects code that was written without knowledge of the jet.

refulgentis• 8 years ago

Did this end up going anywhere interesting? As written up, it sounds like an attempt to simplify programming that would just turn into a "turtles all the way down" problem.

akvadrako• 8 years ago

They haven't made a lot of public gains yet but the project has only recently raised enough money to grow beyond a few developers.

core-questions• 8 years ago

Urbit's Nock, which, other than the jet concept, I honestly think is either a strange art project or snake oil, so I won't discuss this further.

Urbit is very real, though whether it will go anywhere or not is a different question. You can run the code today, the language is.... weird as, but there it is, running and doing what it does.

icebraining• 8 years ago

Snake oil != vaporware.

_bxg16• 8 years ago

This is the problem I have with Lisp, but exponentially worse. Languages like this try and stretch ever-closer to an imaginary "perfectly pure language". It's an interesting exercise, but in the process they get further and further away from concepts that are palatable to the human mind, and end up esoteric and minimalist beyond usefulness. We sometimes forget that programming languages are not designed for computers, but for humans who want to express ideas to computers.

bunderbunder• 8 years ago

Do you mean Scheme, specifically? Because I have a hard time seeing that in lisp in general. Racket's small but fairly pragmatic, Clojure is pretty big, and Common Lisp is frankly a bit of a kitchen sink language.

vinceguidry4• 8 years ago

Not your parent, but I personally didn't find S-expression syntax to be superior. Treating code as data and vice versa is metaprogramming, and it should be something you know how to do when you need it, easy enough to where you're not really going out of your way to do it when you do need it, but weird enough so that you can notice it and immediately see that you are going to need to put on your thinking cap in order to proceed further down the road of understanding this program, when you come across it.

I've yet to see a better approach than Ruby's.

_bxg16• 8 years ago

Some Lisps indeed do away with the "minimalist" aspect when it comes to functionality, although I was mainly referring to syntax.

Retra4• 8 years ago

There aren't any concepts here that are "palatable to the human mind." It's ok to have a bias, but don't be so foolish to pretend it is universal.

_bxg16• 8 years ago

There are some very abstract common threads in how the mind conceptualizes the world. See Gestalt Psychology: https://en.m.wikipedia.org/wiki/Gestalt_psychology

There's also this; a fascinating study that investigated the ways people intuitively try to articulate algorithms when they haven't been biased by experience with existing programming paradigms: https://dl.acm.org/citation.cfm?id=373422

wmf• 8 years ago

These really minimal languages aren't intended for programmers; they're compiler targets for higher-level languages. So the debate about jets is really about how best to implement language runtimes.

_bxg16• 8 years ago

I wasn't aware of that, thanks for the clarification

arethuza• 8 years ago

Arguably, that "perfectly pure language" has existed longer than programming has - lambda calculus.

nv-vn• 8 years ago

Unrelated, but have LTU's site admins just disappeared? I signed up for an account probably over a year ago and it still hasn't been verified.

nerpderp83• 8 years ago

Same. Maybe you just have to hijack them at ICFP.

naasking• 8 years ago

There were some issues with the signup process over the past year. You should email them directly:

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

ychen306• 8 years ago

I think the standard term is Idiom Recognition.

valarauca1• 8 years ago

"Are optimizing compilers a good idea?"

Look if you replace 1 representation with another that is _correct_ (to within the human author's reason), but faster. You have the identical discussion, and an answer (yes).

koala_man2• 8 years ago

Well, there's another aspect: "Is it OK to design a language that will be unusable without an optimizing compiler?"

Running any normal language without an optimizing compiler is totally fine and routinely done. Here we're talking about languages that might be thousands or millions of times slower.

setr• 8 years ago

Compared to a optimizing compiler, a fresh implementation for a language would probably also be thousands/millions of times slower, unless the codebase implements the optimizations itself.

And then you end up speeding up the compiler to reach a decent state, to speed up the code

But time to reach initial compiler is much faster with a jet-based one (there's barely anything to the language).

and then you end up adding jets to reach a decent state

I'm not sure there's a significant difference in this regard. The main question, I think, is which is easier/simpler/faster to optimize into a proper state, and in the case of compiler optimization being better, if its sufficiently better to beat the ease of initial implementation for a jet-dependent language

derefr6• 8 years ago

If you assume the program is being passed through a JIT (a thing that is already common for interpreted code, and which also tries to guarantee that it doesn't change the resulting program's semantics), then one can think of jets as simply explicit hints built into a JIT regarding how to optimize particular known idioms well known in the corpus of programs the JIT was designed to work with.

This is exactly how GPU drivers get gradually more optimized for existing games: the driver's shader compiler actually has an ever-growing library of shader-source-code patterns, with hardware-vendor-optimized replacement sections.

redleggedfrog• 8 years ago

What about debugging? Without an IDE and/or a stepping debugger you're in for a lot of no fun.

nils-m-holm• 8 years ago

Are you referring to debugging in insanely simple languages or to debugging in general? Because I have written code in a text editor and debugged with PRINT (or whatever the language offers) for decades. It was a lot of fun!

kjeetgill2• 8 years ago

This is already a standard piece of how JITs work today. See the discussion of Java intrinsics and Array.fill() here [0].

An intrinsic function is applied as a method substitution [...] and the compiler will replace it's apparent source-level implementation with a pre-cooked implementation. In some cases intrinsics are sort of compilation cheats [...]
The intrinsics are all set up in vmSymbols.hpp and if you look, you'll see Arrays.fill is NOT on the list. [...] Because it is something like an intrinsic... [...] What is it then? Arrays.fill is a code pattern substitution kind of compiler shortcut, basically looking for this kind of loop:

``` for (int i = 0; i < arrayB.length; i++) { arrayB[i] = b; } ```

And replacing it with a call into the JVM memset implementation.

[0] http://psy-lob-saw.blogspot.com/2015/04/on-arraysfill-intrin...

shub5• 8 years ago

That has bugged me since the first time I read about Nock. JITs use intrinsics to work around inefficiency of generated code when the maintenance burden of the intrinsic is worth the performance boost, and the grand plan is to make a VM so terrible that you need a shitload of intrinsics for programs to terminate before the heat death of the universe? Years later I still haven't gotten past that initial bafflement. It just makes no sense at all.

JeremyBanks• 8 years ago

Have you taken a math course at any point in your life?

lmm• 8 years ago

JITs use intrinsics to work around inefficiency of generated code when the maintenance burden of the intrinsic is worth the performance boost, and the grand plan is to make a VM so terrible that you need a shitload of intrinsics for programs to terminate before the heat death of the universe?

Put it this way: the JVM is perhaps the most sophisticated JIT on the planet, maybe a million lines of code, the product of decades of programming research and billions of programmer-hours, and it still needs intrinsics to improve performance. So how about we skip the billions of programmer hours and just use lots of intrinsics?

I don't know if it's going to work, but it's interesting enough to be worth a try.

pjc50• 8 years ago

I wanted a reminder of Nock, and looked for an example, but the first hit is the enourmous pile of hoops to jump through to make "decrement" work! https://urbit.org/docs/nock/example/

Reminds me of nothing so much as INTERCAL.

ianbicking• 8 years ago

It occurs to me that ASM.js (before WebAssembly) was full of jets. That is, they wrote weird idioms that the interpreter could understand and optimize, while technically keeping the semantics of the language itself (JavaScript). The most visible example was someVar|0, which was a kind of way to assert that the expression would be an integer. Not really a type declaration, since it didn't ensure someVar would be a number, only that the expression was integer.

In the examples though, clearly the goal is to have some provability in the core language, make that provability feasible with a small language, and keep that as the language becomes further optimized. It seems subtly different than an optimizing compiler.

purity_resigns• 8 years ago

Both BuckleScript and PureScript use the someVar|0 trick.

theoh4• 8 years ago

Somebody mentioned "failure of full abstraction" on HN a few months ago (actually they said something a bit different), which I tracked down to a late 90s paper by Martin Abadi. It refers to a situation where the object code is exploitable because it doesn't fully reflect the semantics of the source code.

One use of jets, in the secure code setting, is to provide a core language that is so simple that it can obviously be compiled in a "fully abstract" way.

That is my understanding, anyway. The notion of fully abstract compilation seems to be quite hot, and it comes originally from Abadi's paper: http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-154.pdf

cousin_it• 8 years ago

The language specification should guarantee that when you implement an algorithm from your algorithm book, you get the same time and space complexity as described in the book, with reasonably small constants. You should be able to hit your big-O target without knowing which "jets" get special treatment by the compiler. That's all I ask for, and it's not too much to ask.

Are “jets” a good idea? (2017)

Related Stories