Lambda the Ultimate

We have plenty of production languages, but precious few languages that try to push the envelope of what is possible in PL. If we just put all our smart people on languages we use today, we will have nothing very interesting for tomorrow.

with anywhere near the sort of power of racket.

And they keep adding more wonderful things too.

If only they also had a production ready fork.

One of the reasons Racket can be so powerful is that they don't nerf themselves for industry.

If someone wanted to cherry pick/polish an industry-friendly version of Racket, I think it would be welcomed.

Given the "documentation doesn't have to make sense to anyone but the implementer and his students" and other code not being documented, who is going to be able to understand this mess well enough to stabilize it?

If you want code/documentation to make sense, you need a feedback loop. If there is no feedback loop...then it just won't. You either help and try to create a feedback loop between the implementers (you know, by taking an interest in the code and asking questions), or you give up and go somewhere else.

Code is a conversation, often it is a one sided one where you are basically talking to yourself.

I would talk about the people who use Racket "for real products", but the tone of your comment doesn't really make engagement seem worthwhile here.

There are many categories of people here: Those who apparently happily already use Racket for real products; Those who tried to use it and failed; Those who never bothered to try; Those who never even heard of Racket; etc.

For Racket, I do not believe the cardinality of the first category of people is going to prove that it is ready for real products. So it might be worth talking with those in the second category to see why they aren't in the first.

I read the tone as actually being the kind of thing I desperately search for and want to find in the world regarding my own projects and efforts. A person who knows enough and is interested enough to have apparently actually tried to use it! And has results to share! Hooray! But that's just me.

I take that as frustration from somebody who likes Racket. Plus, he's not the entire LtU.

https://groups.google.com/d/msg/racket-users/RFlh0o6l3Ls/8InN7uz-Mv4J

Congrats!

source of the web page to find it. You can't click on an empty link

There is the HN discussion.

But I'm busy tacking a nice metalanguage on lua that will run on luajit.

Turning it into something similar to scheme will be little more than a one liner when I'm done, though it will be a language that builds out of arrays and tables instead of lists, but that may turn out to be an improvement.

An a little functional subset with s-expressions would also be easy.

The advantage of luajit is that it's small and already runs on everything. You can't get Racket running your android or ipad game afaik

[edit] I added to the ycombinator thread

The Racket people are very pragmatic, and if Carmack - the meticulous optimizer - takes an interest in it, some wonderful things could eventually happen.

.

If there are particular programs you have that exhibit poor GC behavior, we'd love to know about that. Benchmarks I've run suggest that Racket's GC is quite competitive with other functional languages, although it isn't parallel.

The IDE is utterly unusable, stopping with a garbage collection symbol in the lower right hand corner every minute or so.

This is especially bad if one is editing programs that are larger than toys. I use a small netbook but I've been told it isn't usable on faster machines either.

Actually, I'm using DrRacket as we speak. I've been a heavy user of DrRacket for 15+ years. Furthermore, I use it to edit large programs, including itself. Again, if you have specific feedback, that would be very helpful.

And gave up because the editor stops for up to 15 seconds on a regular basis.

Scrolling through large files without pauses, impossible, searching for completion terms on large files without pauses, impossible.

That is a specific feedback and if you don't like it, then you can read any insult into this comment you'd like.

That's helpful, thanks. There are some known performance issues with scrolling, which are probably exacerbated on a netbook. What do you mean by "searching for completion terms"? Just searching for a string in a file with "Find"?

However, these issues are almost certainly feature-specific, DrRacket-specific, or GUI library-specific, rather than being an issue of GC performance. If a program allocates too much, for example, it will spend a lot of time in GC, which may be what's happening here.

of giving Racket a GC plugin for students to play with gc techniques, but didn't go through the trouble of giving it an acceptable gc in the first place.

Luajit has a nicely tuned incremental gc though not a generational one, that seems good enough.

Granted that the racket gc needs to deal with multiple threads which is a nightmare.

I suspect that Racket being "stop the world" means that they never bothered to make the code generator put in write barriers. That would be a huge change, and who knows, maybe not even feasible... but since they don't even support a lot of platforms they could cludge it by using OS tracked dirty page scanning and rescanning instead of a write barrier.

Sigh. There are flies in the ointment http://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html

Like I said, the things you see are unlikely to be GC problems. Racket already has a generational GC and it certainly uses a write barrier. The write barrier is implemented using page protection from the OS, which works better with C code in the runtime system.

Also, the GC in Racket and the teaching materials for GC in PLAI are written by different people.

of the IDE when it stops.

I'm sorry, but this is the only system I've ever used with frequent, long pauses for gc. The only one.

And I'm hardly the only person who rejects Racket because of this. That the IDE is unusable because of bad GC is well known. And yet the IDE IS the system. It's not worth using without the IDE.

If you're saying that the IDE some part of its design is so bad that NO gc could keep up with it, then you're saying something amazing - in which case you should replace it by a design by a competent programmer. This is a problem that literally no one else has. And no one has seen frequent long gc pauses in other systems for decades.

Also, if they used the write barrier to make the gc generational, but not to make it incremental or parallel, then I guess they used it to solve the wrong problem - either that or it's badly tuned.

If your attitude toward serious problems is to deny them, then by the time you realize that you don't have a choice, there will be no one around who knows HOW to solve them.

And no one has seen frequent long gc pauses in other systems for decades.

This is a pretty remarkable statement. In reality, GC pauses are a major issue on every garbage-collected VM, ranging from large HotSpot server systems to Android.

I think this discussion has exhausted its usefulness.

But I've never run used a program that has a long pause frequently.
Sure, some systems have to do major collections occasionally. But this is ridiculous.
[edit] I will also add that the other systems have this problem as you say, and they've all found much better solutions to it than you have. Because no one else has ever written an editor that can't scroll because of gc.

Let me add that no one else has an editor where it can stop for gc in the middle of typing and be gone for 15 seconds. Really, you think your system is acceptably tuned? Really?

Let me add that one of my favorite programmer's editors (JEdit) is written in pure java.

I've run it on windows, I've run it on unix installed on an android device without much memory. Never had a problem with garbage collection. Never had a problem with large files. Even on a slow arm processor.

Open office is also in Java, also no problems.

Eclipse a full IDE, also java. Acceptable no matter what version of java you run it in, GNU or Oracle - and let me add that I've run that both ways on an arm processor without much memory.

Some versions of Microsoft office are probably written in .net. No problems with gc and scrolling or editing or searching..

Ok, visual studio 2010, written in winforms is a bit on the unacceptably slow side, but pauses for GC while editing aren't the problem... Editors built on IDEA are in java and also a bit heavy and slow, but still no long pauses for gc while doing basic editing.

XMaxima displays equations in full mathematical format, it's written in TCL/TK - it runs a lot better than the PLT ide

I think you have to go to an editor written in Javascript running in a browser to find something as slow and pausing as Racket. And you might have to have multiple pages open in the browser to get that bad.

The problem probably is the GUI library, not the GC. In the past, Java AWT and Swing used to have strange pauses while Eclipse SWT would run very nicely in the same Java VM.

What's wrong with the macro system? Just learned it, seems nice.