Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Racket Manifesto

ccs.neu.edu

Post reply on HN
Print view View original

21–30 of 51 posts

Re: The Racket Manifesto

#21

Post by shriramkmurthi »

616c wrote: post #14
jpolitz wrote: post #8

Earlier quoted context omitted.

(I'm a Pyret core designer/developer.) Pyret started its life as a #lang, which was delightful as a prototyping tool. The demands of running with reasonable performance in a browser led us to switch to a direct-to-JS approach, and we haven't looked back since. The original Pyret-to-JS compiler has been up and running for around a year now; we're still learning how to improve and tune its performance, but it's proven…

Thanks for your work in the Racket world. Thanks for Pyret too, I just do not use it ... yet. I check out your site often enough bc your work comes up a lot here. I am curious how are you typically advising (Brown?) students to use this. I have a work computer, Windows 7, and 8GB of RAM with SSD disk and running Firefox 38.02a Developer Edition. After disabling NoScript, it took somewhere 2-3 mintues to run. This is…

Thanks for the kind comments. Sorry to hear about the crash, etc. We haven't gotten many reports about this; if you could file a bug report the next time (https://github.com/brownplt/pyret-lang/issues/new) we'd appreciate it! [But Firefox is _really problematic_ for various reasons. That may be half the issue.]

Pyret's compiler is actually written in Pyret itself, so that it can run entirely offline. Once you have the initial page (which could be offline), you can literally turn off all networking and continue to work forever. Of course, saving files is then a problem—but I actually do this when I'm on planes (I copy my code to another file to backup).

The _first_ load is indeed a bit of a problem. We're looking into various ways to reduce that. However, you should not have had delays on any subsequent runs. We have students in other universities, and even high schools, using it, so I don't think there's anything Brown-specific at work here. So I'm afraid it may be something to do with your particular laptop )-:.

Re: The Racket Manifesto

#22

Post by 616c »

shriramkmurthi wrote: post #21
616c wrote: post #14

Earlier quoted context omitted.

Thanks for your work in the Racket world. Thanks for Pyret too, I just do not use it ... yet. I check out your site often enough bc your work comes up a lot here. I am curious how are you typically advising (Brown?) students to use this. I have a work computer, Windows 7, and 8GB of RAM with SSD disk and running Firefox 38.02a Developer Edition. After disabling NoScript, it took somewhere 2-3 mintues to run. This is…

Thanks for the kind comments. Sorry to hear about the crash, etc. We haven't gotten many reports about this; if you could file a bug report the next time ( https://github.com/brownplt/pyret-lang/issues/new ) we'd appreciate it! [But Firefox is _really problematic_ for various reasons. That may be half the issue.] Pyret's compiler is actually written in Pyret itself, so that it can run entirely offline. Once you have…

Don't worry, I recognized your name from the PAPL book and I think some Racket stuff. But anyway, I know who you are. :-)

If I get it to crash again, I will definitely contact you and file a bug report.

I guess the self-hosting compiler blurb on the GH repo did not really hit me. I will definitely try it offline and give it a whirl.

So what is the recommended browser then?

Re: The Racket Manifesto

#23

Post by muraiki »

shriramkmurthi wrote: post #10
muraiki wrote: post #5

Earlier quoted context omitted.

I can't praise HtDP enough (disclaimer: I've only done through chapter 4 of the first edition). Still, what I did was sufficient to fundamentally change me as a programmer. When I first began learning how to program I started off with Python using some courses on Udacity. But somehow I found HtDP (I think via HN) and it really taught me, well, how to design programs. It also made thinking functionally my default mode…

Indeed, the first edition is draggy at the beginning. The second edition is meant precisely to dive right in and get cracking, without sacrificing any principles. I recommend people read the second edition instead of the first one. [Why should you trust me? My name's on the cover. <-;]

Thank you, that is good to know.

Also, please know that I am sincerely grateful for all of your work. Without the software and materials that you and your team labored to create -- and which you provide freely -- I might not be a professional programmer today.

Re: The Racket Manifesto

#24

Post by brudgers »

shriramkmurthi wrote: post #19
brudgers wrote: post #15

Earlier quoted context omitted.

The features of Pyret make it the most advanced compile-to-JS language I know of. ClojureScript is pretty sophisticated since it is considered production ready for commercial work and leverages much of Clojure's ongoing library development directly. https://github.com/clojure/clojurescript/wiki Not to take anything away from Pyret.

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…

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.

Re: The Racket Manifesto

#25

Post by shriramkmurthi »

muraiki wrote: post #23
shriramkmurthi wrote: post #10

Earlier quoted context omitted.

Indeed, the first edition is draggy at the beginning. The second edition is meant precisely to dive right in and get cracking, without sacrificing any principles. I recommend people read the second edition instead of the first one. [Why should you trust me? My name's on the cover. <-;]

Thank you, that is good to know. Also, please know that I am sincerely grateful for all of your work. Without the software and materials that you and your team labored to create -- and which you provide freely -- I might not be a professional programmer today.

Wow, thanks. I passed this remark on to the rest of the team. Totally made our day!

Re: The Racket Manifesto

#26

Post by shriramkmurthi »

616c wrote: post #22
shriramkmurthi wrote: post #21

Earlier quoted context omitted.

Thanks for the kind comments. Sorry to hear about the crash, etc. We haven't gotten many reports about this; if you could file a bug report the next time ( https://github.com/brownplt/pyret-lang/issues/new ) we'd appreciate it! [But Firefox is _really problematic_ for various reasons. That may be half the issue.] Pyret's compiler is actually written in Pyret itself, so that it can run entirely offline. Once you have…

Don't worry, I recognized your name from the PAPL book and I think some Racket stuff. But anyway, I know who you are. :-) If I get it to crash again, I will definitely contact you and file a bug report. I guess the self-hosting compiler blurb on the GH repo did not really hit me. I will definitely try it offline and give it a whirl. So what is the recommended browser then?

Go with Chrome, Safari, or IE 10 for now. There's a very complicated interaction with how Firefox handles the stack.

Re: The Racket Manifesto

#27

Post by shriramkmurthi »

brudgers wrote: post #24
shriramkmurthi wrote: post #19

Earlier quoted context omitted.

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…

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 du…

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.

Re: The Racket Manifesto

#28

Post by stcredzero »

PaulRobinson wrote: post #9

I sense the whole area of domain-specific languages is due for a belated renaissance. Everybody shirks away from it, but most languages are not very good for solving most problems and the standard libraries bloat out as more and more gets crammed in. I don't think in a commercial context we can all step back and say "to solve this problem, let's first design an appropriate language" but as a means to define the probl…

The problem with Lisp-like DSL construction, is that the interface doesn't play well with many populations of domain experts. Even Smalltalk, with its syntax designed to be usable by children can fulfill the technical side of constructing DSLs easily, but still leaves something to be desired when it comes to domain expert use. (Various Smalltalks had their rough equivalent to #lang.)

(I know there is at least one Ruby based DSL which made some inroads to mobile device software testing.)

Basically, DSLs tend to only get used by experts who are already programmers or otherwise technically disposed. Maybe we're getting to the point where rudimentary coding is just going to be a new kind of literacy?

Re: The Racket Manifesto

#29

Post by shriramkmurthi »

stcredzero wrote: post #28
PaulRobinson wrote: post #9

I sense the whole area of domain-specific languages is due for a belated renaissance. Everybody shirks away from it, but most languages are not very good for solving most problems and the standard libraries bloat out as more and more gets crammed in. I don't think in a commercial context we can all step back and say "to solve this problem, let's first design an appropriate language" but as a means to define the probl…

The problem with Lisp-like DSL construction, is that the interface doesn't play well with many populations of domain experts. Even Smalltalk, with its syntax designed to be usable by children can fulfill the technical side of constructing DSLs easily, but still leaves something to be desired when it comes to domain expert use. (Various Smalltalks had their rough equivalent to #lang.) (I know there is at least one Rub…

This is a criticism of Lisp-based DSLs but not of Racket-based DSLs. Racket actively enables you to impose different, non-parenthetical surface syntaxes on the DSL. It is not a "this sort of works if you arrange it carefully _and nobody screws anything up_" thing like in Ruby, it really is an explicit language definition.

The easiest way to understand this in action is to read about Danny Yoo's Brainfuck embedding in Racket: https://www.hashcollision.org/brainfudge/

Re: The Racket Manifesto

#30

Post by [deleted] »

stcredzero wrote: post #28
PaulRobinson wrote: post #9

I sense the whole area of domain-specific languages is due for a belated renaissance. Everybody shirks away from it, but most languages are not very good for solving most problems and the standard libraries bloat out as more and more gets crammed in. I don't think in a commercial context we can all step back and say "to solve this problem, let's first design an appropriate language" but as a means to define the probl…

The problem with Lisp-like DSL construction, is that the interface doesn't play well with many populations of domain experts. Even Smalltalk, with its syntax designed to be usable by children can fulfill the technical side of constructing DSLs easily, but still leaves something to be desired when it comes to domain expert use. (Various Smalltalks had their rough equivalent to #lang.) (I know there is at least one Rub…

[deleted]
Post reply on HN