3 ms·

It's awesome in its own way. Our emphasis was on • allowing arbitrarily deep call stacks (e.g., deep recursion) • allowing computation to be interrupted • tu

It's awesome in its own way. Our emphasis was on • allowing arbitrarily deep call stacks (e.g., deep recursion) • allowing computation to be interrupted • turning async interfaces into sync ones This means you can't just compile altjs function calls to JavaScript function calls. That's the work that @jpolitz is referring to. The last we checked, ClojureScript did not address these issues as well (though it does other awesome things!).

brudgers 12y ago
I think the PLT group does amazing work in general and in education in particular. The well designed teaching languages hide complexity while providing power for expressing important concepts. And nobody makes installing a full blown IDE and versatile tool chain easier for beginners. My emphasis was on an a Blub->JS alternative for production. I am not sure Pyret is a priority alternative for a green field project due to the language's intended purpose and the directions in which that purpose is likely to drive and not drive its development and tooling. That is to say that features are likely to flow Pyret->Clojure faster than Clojure->Pyret.
- shriramkmurthi 12y ago
  Absolutely. To be honest, we don't want Pyret to stay in the "education cellar" forever. But, we need a set of coherent design constraints, and education is a good one because it prevents premature cruft. The current stack treatment is pretty elaborate for pedagogic reasons. There's absolutely no reason we can't just turn it off for programmers who are willing to write short-running computations, for instance (as production developers are willing to do)—that would be a "#lang"-style configuration. The tooling would, of course, be the bigger issue. Overall, I'm happy for all good altjs projects. The core Pyret team burnt their fingers on a lot of aspects of JavaScript and see clearly its difficulties for education and even for development. By the way, this is one of the reasons we're putting a lot of effort into JS interop. This isn't really important for education but it is for development—and in particular, development for education.
  - brudgers 12y ago
    I think tooling is only theoretically surmountable under the current incarnation of PLT and its culture [and I am not saying that this is a bad thing because that culture is extremely valuable]. By which I mean that PLT culture does not spin off the right tooling in the right direction relative to typical production operations. Racket works well with DrRacket and sorta with Emacs: compare Geiser or Hendershott's M-x racket-mode to Cider. Good luck finding out of the box integration of Racket with Eclipse, Visual Studio etc. The reasons include, I think, the fact that consultants on mutli-million dollar contracts are not going to start with Racket. This means that 1000 hours building a tool for Eclipse that saves 10% on a $4,000,000 contract never happens. What happens instead, and it is a good thing, is that people tend write tools that solve the problems of academia, including implementation of research topics at one end and producing well formatted text on the other, and of course pedagogy on the third end [maths are not my strength, apparently]. As an example, listening to the Flatt interview, the sub-module system makes sense. The extra level of indentation for namespace construction though feels kludgey from a typing code into a box perspective because top-level concepts from the perspective of the enclosing namespace are indented - I look and ask myself, did I miss a right-banana?: The sub-module syntax is at odds with the core principles of pretty-printing as a tool. That sort of design engineering isn't a priority for PLT [and I am not saying it should be, only that it makes moving out of education less likely].
    - matthewflatt 12y ago
      On the subject of tools: I'd like to clarify that Scribble was not designed to solve academic text-formatting problems; it was designed for Racket documentation. It's fair to say that we subsequently improved Scribble in academic-friendly paper- and book-writing directions, but like so much of what the current Racket developers do, it was motivated by programmer experience rather than academic tasks or credit. The current developers can only work so fast, but I hope Racket continues to attract more contributors who build more tools. On the topic of parentheses and submodules: I can understand why some consider parentheses to be an obstacle, but I'm puzzled that you've singled out their use for submodules. Syntactic forms in `#lang racket` use parentheses, and I think they've worked well in practice for submodules. That said, submodules are most powerful when you don't use them directly and instead use (or create) constructs that are implemented as submodules. For the example you have in mind, a new syntactic form may well fit better --- and maybe should be one of the many constructs that are available out of the box.

brudgers 12y ago

I think the PLT group does amazing work in general and in education in particular. The well designed teaching languages hide complexity while providing power for expressing important concepts. And nobody makes installing a full blown IDE and versatile tool chain easier for beginners. My emphasis was on an a Blub->JS alternative for production. I am not sure Pyret is a priority alternative for a green field project due to the language's intended purpose and the directions in which that purpose is likely to drive and not drive its development and tooling. That is to say that features are likely to flow Pyret->Clojure faster than Clojure->Pyret.

shriramkmurthi 12y ago
Absolutely. To be honest, we don't want Pyret to stay in the "education cellar" forever. But, we need a set of coherent design constraints, and education is a good one because it prevents premature cruft. The current stack treatment is pretty elaborate for pedagogic reasons. There's absolutely no reason we can't just turn it off for programmers who are willing to write short-running computations, for instance (as production developers are willing to do)—that would be a "#lang"-style configuration. The tooling would, of course, be the bigger issue. Overall, I'm happy for all good altjs projects. The core Pyret team burnt their fingers on a lot of aspects of JavaScript and see clearly its difficulties for education and even for development. By the way, this is one of the reasons we're putting a lot of effort into JS interop. This isn't really important for education but it is for development—and in particular, development for education.
- brudgers 12y ago
  I think tooling is only theoretically surmountable under the current incarnation of PLT and its culture [and I am not saying that this is a bad thing because that culture is extremely valuable]. By which I mean that PLT culture does not spin off the right tooling in the right direction relative to typical production operations. Racket works well with DrRacket and sorta with Emacs: compare Geiser or Hendershott's M-x racket-mode to Cider. Good luck finding out of the box integration of Racket with Eclipse, Visual Studio etc. The reasons include, I think, the fact that consultants on mutli-million dollar contracts are not going to start with Racket. This means that 1000 hours building a tool for Eclipse that saves 10% on a $4,000,000 contract never happens. What happens instead, and it is a good thing, is that people tend write tools that solve the problems of academia, including implementation of research topics at one end and producing well formatted text on the other, and of course pedagogy on the third end [maths are not my strength, apparently]. As an example, listening to the Flatt interview, the sub-module system makes sense. The extra level of indentation for namespace construction though feels kludgey from a typing code into a box perspective because top-level concepts from the perspective of the enclosing namespace are indented - I look and ask myself, did I miss a right-banana?: The sub-module syntax is at odds with the core principles of pretty-printing as a tool. That sort of design engineering isn't a priority for PLT [and I am not saying it should be, only that it makes moving out of education less likely].
  - matthewflatt 12y ago
    On the subject of tools: I'd like to clarify that Scribble was not designed to solve academic text-formatting problems; it was designed for Racket documentation. It's fair to say that we subsequently improved Scribble in academic-friendly paper- and book-writing directions, but like so much of what the current Racket developers do, it was motivated by programmer experience rather than academic tasks or credit. The current developers can only work so fast, but I hope Racket continues to attract more contributors who build more tools. On the topic of parentheses and submodules: I can understand why some consider parentheses to be an obstacle, but I'm puzzled that you've singled out their use for submodules. Syntactic forms in `#lang racket` use parentheses, and I think they've worked well in practice for submodules. That said, submodules are most powerful when you don't use them directly and instead use (or create) constructs that are implemented as submodules. For the example you have in mind, a new syntactic form may well fit better --- and maybe should be one of the many constructs that are available out of the box.