Dear Nota Poin, thanks for your thoughts. If Racket is such a mess for you, why do you bother to participate here? Do you find anything attractive about it or is someone putting a "gun to your head" and says "use it"?
As for your specific pain points, some are right on, some show an understanding of programming of the 1970s, some fail to see that a language is a living organism in search of light, and some more don't accept that Racket is also a research vehicle -- it's not just some random amalgam of stuff but the "living organism" result of serious research on programming languages, based on decades of thought, readings, reflection, experimentation, and brute-force labor. When you look at something like Racket, you need to keep this in mind. -- Matthias On Feb 15, 2016, at 5:40 AM, 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. Like with pypy vs cpython, efficient JIT means > more number crunching at startup. When people are willing to throw out > optimal code for fast startup, maybe racket can support that, but it isn't > exactly a high priority. Complex flexible syntax means even compiled code > takes longer to JIT than say for instance java bytecode. > > Big requirements. Lots of memory, lots of CPU. Not a viable target for > embedded systems or mobile devices. Takes forever to compile. At least it's > not spending 80% of the compilation anymore, creating that massive javascript > blob that they call "documentation". Not such a problem on systems where it's > already compiled, but some people actually like open source. > > Too many ways to do core things. Do you want to use the foof-loop macro? > cl-loop? for? for/fold? foldl? (let loop ([arg arg]))? ((lambda (boing arg) > (boing boing arg)) (lambda (next arg) ...) arg)? (define (recurse arg) > (recurse arg arg))? > > When you take a simple example and try to customize it to your needs, more > often than not (I at least) end up buried in pages of fiddling with the guts > of the algorithm, because as soon as you depart from the norm it quickly > becomes overwhelmingly complex as you expose the innards of whatever system > you're trying to adapt to your needs. > > Too pedantic. This isn't hygenic! That's not allowed! More often than not > it's saving you from screwing up, but with errors like "permission denied" > and "bad syntax" it feels like you're being chided by a 70 year old > librarian. At least it's not as bad as java. Lots of full on phrases, when > typing abbreviations would be easier. (require (only-in a b)) vs "from a > import b" or "import a: b" > > Racket is a _lot_ better at that lately. It used to have things like (eval) > didn't work, because there was no %app syntax transformer by default, because > that would be correct, as opposed to what anybody actually wants. You can > actually throw away hygiene without a lot of horrible overrides, and it's > better at intuiting just what you mean by turning datum into syntax. > > Not bare metal enough. Not because of speed, but because of barriers to > understanding. Okay, so a computer is a bunch of switches, and some switches > turn others on or off. Cool, and that's how you make an adder circuit. Now > what switches will make a lambda? It's abstract, optimized at runtime, > inscrutable, not what you think it is, rewritten, transformed magic? Uh huh, > I'm just gonna go call a function in C thanks. > > Too meta. Flexible syntax is awesome for simplifying and compartmentalizing > logic, but when you have syntax that produces syntax it gets harder to > understand just what you're doing. People don't realize this, so write lots > of crazy racket code that throws away first order functions for the "faster" > syntax transformations when the former would work fine and not leave people > at a loss to figure what the letters you typed are supposed to do. > > Too powerful. It's a language that can define new languages from whole cloth. > It's a compiler of compilers. It's like trying to use a jet engine to propel > your tricycle. > > 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. > > Continuations are slower than jumps. Can't implement the latter with the > former, since you always have to be ready to capture the current > continuation. 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." > > -- > 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. -- 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.
