On Mon, 15 Feb 2016 02:40:28 -0800 (PST), Nota Poin <notap...@gmail.com> wrote:
>On Saturday, February 13, 2016 at 5:35:09 PM UTC, Saša Janiška wrote: >> So, at the end I just wonder how is it that such Wonderland is not >> discovered by much more people? > >Startup is slow. Intractable problem, JIT compiling just takes time, and >can't be cached beforehand. Hardly an intractable problem: look at NGEN in dotNET. >Big requirements. Lots of memory, lots of CPU. Not a viable target >for embedded systems or mobile devices. That's more a matter of runtime architecture than of language. >Takes forever to compile. ... You typically don't run an embedded device *while* compiling its code. In many cases you wouldn't even want to. >Not such a problem on systems where it's already compiled, but >some people actually like open source. "Open source" is a different issue than is "portable distribution". It used to be fairly common for commercial Unix applications to be delivered in shrouded (i.e. unreadable) source format. You could compile/link and install the application, but you couldn't read the code. Portable (compiler IR and similar) binary distribution formats have been around for decades. Bytecode is perhaps the most compact distribution format, but it is not the only one possible. Nor is it a modern idea. >Not bare metal enough. Not because of speed, but because of >barriers to understanding. Whose understanding? IME the average programmer is incapable of bare metal programming. And again, this is not a source language issue. There are some Schemes and Lisps available that target bare metal ... Racket does not. But there's no inherent reason Racket could not serve as a cross-development system for a bare metal device. >Too interdependent. Writer of cool module A sees cool module B, >uses that, which uses cool module C, which uses D, E and F, etc. >It's not as bad as perl, and not nearly as bad as C++, but reducing >module interdependency, at the cost of redundant code, is a slow >process to get right. The answer is NOT to try to eliminate dependencies by glomming everything into every module. The answer is a proper version control system that supports having multiple versions available - or better, in use - simultaneously. Java's class file structure at least tries to address this ... though IMO the mechansim is overly complex and harder to use than it could be. YMMV. >Continuations are slower than jumps. That's an implementation centric over-generalization. A continuation is nothing but "the next thing to be done". At its most basic, it is nothing more than the address of the next instruction to execute. >Can't implement the latter with the former Of course you can. >Racket's one of the best schemes at fast continuations, but every >scheme except bigloo (which cops out by disabling continuations) >faces the problem that "create a closure, and jump" is more >expensive than "jump." Because you *chose* to capture a continuation and invoke it rather than use a branching construct. That isn't the compiler's fault. A continuation with arguments does not necessarily *need* to be any more expensive than an indirect function call. It is people wanting heavy handed things like winding environments that complicates implementations of continuations. It would be nice if only those who want a feature should have to pay for it. But that isn't always possible - there always are some things that need to be built in at the lowest levels. Not even C is completely uncoupled in this respect. As Matthias Felleisen said already: >>If Racket is such a mess for you, why do you bother ... ? George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
