Pyret has lots of nice ideas, looking forward to see it evolve.
That said, the title of this post is a bit misleading so I wanted to correct it. The group of people who develop Racket and Pyret are mostly disjoint. I'm not trying to diminish Pyret at all, but wanted to make sure the right people get the credit. You can find out who develops Pyret here: http://www.pyret.org/crew/
Typed Racket definitely doesn't add a "Java-style static typing" system at all. Its type system is quite specifically designed to accommodate the kinds of programming idioms you find in Racket programs (via occurrence typing, function intersection types, and so on), and comes with local type inference.
I don't use racket obviously, but looking through the docs on typed racket it certainly looks like it adds java-style static typing. Having crappy partial type inference doesn't make the type system powerful or expressive, C# has that too and it certainly falls into the java-style type system camp.
> but looking through the docs on typed racket it certainly looks like it adds java-style static typing
It's unclear what you mean by "Java-style static typing" then, because the Java type system and Typed Racket's type system are completely different.
One actually has local type inference (which is not "crappy" type inference necessarily; HM-style type inference is notoriously brittle), the other doesn't. One has nominal class types, the other has no class types (yet). One has intersection types, occurrence typing, "true" union types, and so on, while the other has none of those. One has bounded polymorphism, the other has System F-like polymorphism. One of them has variable-arity polymorphism, while the other doesn't. The list goes on.
In fact, aside from being explicitly typed, there are few similarities.
Which is totally orthogonal to the power and expressiveness of the type system. I specifically gave an example that C# also has crappy limited type inference too, and is still java-style static typing.
>HM-style type inference is notoriously brittle
Yeah, obviously no languages could possibly exist that use it with no problems.
>One has nominal class types, the other has no class types (yet)
What does being OO have to do with anything? I am talking about the expressiveness of the type system. The amount of things you can express in the type system.
>One has intersection types, occurrence typing, "true" union types
So racket has a partial implementation of ADTs? And that's it? Ok, you win, racket has java + 0.1 level of static typing, hooray! The point is, using static typing in racket gets you virtually nothing, because it is such a primitive type system. Go use ML or haskell and then compare it to typed racket.
> Racket is really very complex thing with many man-decades of research behind it and even where it is being advertised, it looks like a typical "academic" thing.
As a fellow Racketeer, I'm curious: what do you think can be done to shake this "academic" image?
It does[1], but it's not necessarily preferred. The whole point of Typed Racket is that you can write your program in (untyped) Racket originally (maybe starting out as a small script), and then add types if you need your program to be more robust. Since typed and untyped modules interoperate smoothly, you choose whatever combination works for your project.
That said, some libraries start out typed too (e.g., the Racket math library[2]) and do benefit from type-driven optimizations and type-checking.
I use emacs with evil-mode (very good vim emulation) to program in Racket. The advantage of emacs is that it has paredit, geiser, and other useful plugins.
Racket's macro system and Kernel's fexprs are pretty fundamentally different, so I don't think the comparison is very apt. In particular, Racket's macros can be entirely compiled away.
While true, I was comparing macro APIs from a usability perspective and should have avoided the term 'abstract model'.
My point was the mental model I refer to when using $lambda is simpler and easier to understand than my mental model for syntax-case, syntax-rules, syntax-parse and friends. The very fact that 'Racket's macros can be entirely compiled away' complicates my mental model which must now accommodate 'phases', compile-time/run-time dichotomies, require for-syntax, etc.
It's an excellent free undergraduate-level PL textbook that covers a lot of ground and is informed by both research and practice. There's a 2nd edition linked from there as well.
That said, the title of this post is a bit misleading so I wanted to correct it. The group of people who develop Racket and Pyret are mostly disjoint. I'm not trying to diminish Pyret at all, but wanted to make sure the right people get the credit. You can find out who develops Pyret here: http://www.pyret.org/crew/