Hacker News Reader

Comment by seertaak | Hacker News Reader

Racket is such a cool project. I keep telling myself I'll find the time to do something serious with it, but I never get around to it.

One minor bit of criticism - would be it be so hard/expensive to hire a designer to do some minor touching up of the DrRacket GUI? It looks like a toy, and the icons didn't even look good in 1998.

I'll balance this criticism with the remark that any language/platform that manages to a) add, ex-post, a type system, b) fix the Gordian knot of modules and macros, and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance, deserves my respect. In addition both Flatt and Tobin-Hochstadt give excellent presentations where it's impossible not to notice their passion for Racket. They're definitely among my nerd heroes right now.

View on HN

I just want to point out that you can use other editors: emacs, vim, vs code. If you really want to stay with DrRacket, feel free to open a feature request about this on the github racket/DrRacket repo.

Actually, not using paredit (or equivalent) for editing Lisps is something I'm unable to do anymore. I sometimes use DrRacket for debugging, but racket-mode and paredit make Emacs hundreds times more efficient for me.

I used to (and sometimes continue) to think that way, too. DrRacket does look terribly retro or unpolished at times. But despite appearances, DrRacket offers unique power tools for working with Racket programs that's hard to replicate at the terminal or in Emacs/Vim/etc. I work with multiple (Racket) languages, and DrRacket shines there because it supports Racket's "multi-lingualism" out-of-the-box. What's also not immediately visible is DrRacket's extensibility. Take a look at Laurent Orseau's quickscript (https://docs.racket-lang.org/quickscript/).

Currently working with DrRacket 7.2 on Mac OS X. What bugs me is that everything becomes unresponsive while executing heavy stuff or code that does not terminate. The stop/kill button usually does nothing and force-quitting the app is the only option. I tried the latest Racket-on-Chez build which seems much better in this regard, but is over-all rather sluggish. Hope this will improve.

I test drove Racket-on-Chez the other day by attempting to use the pict3d module (since 3d is an application that needs speed). My experience was as follows:

1) Install pict3d through DrRacket's built-in package manager - sudden, silent crash. Luckily I ran it from a terminal, which indicates an out of memory error.

2) Raise DrRacket's memory limit to "unlimited" and retry. Same result.

3) Google how to install packages from the command line. Wait for package to build. Build hangs during documentation. Eventually give up and ctrl-c. Hopefully it still works without docs? Racket packages aren't transactional, so every failed build leaves Racket thinking a package is installed, but it's actually broken.

4) Run DrRacket. Load pict3d and type oneliner. Incautiously press an F-key I assume will run the program. DrRacket crashes.

5) Run DrRacket. Load pict3d and type oneliner. Carefully run the program. Scene is incredibly slow but works! Then DrRacket hard crashes and locks my entire desktop so I have to go to a TTY to recover. My graphics are corrupted in a minor way. I haven't rebooted since then, and they're still corrupted.

I really, really like the look of Racket and want to use it in anger for a project, and I have a specific one in mind that would benefit from 3D, but this user experience is singularly bad. It's probably pict3d's fault, but there's no indication of this module being of "pre-alpha" stability. Or maybe it's an interaction with Racket-on-chez and C library interfacing. Let's hope it gets better.

Out of curiosity, is there a particular reason you were trying to use Racket CS for this?

AFAIU typed Racket currently adversely affects performance on Racket CS (in certain cases) and pict3d looks like it's a non-base package written in typed Racket so it's likely not the best candidate for running on Racket CS right now.

You should try again from non-Chez Racket.

> It's probably pict3d's fault, but there's no indication of this module being of "pre-alpha" stability. Or maybe it's an interaction with Racket-on-chez and C library interfacing.

Racket-on-Chez is what's pre-alpha. I don't think there's been requests for anyone to test it unless they were going to dig into the guts and try to fix things.

> since 3d is an application that needs speed

if the slowest part of your 3D is how quickly you can make calls into OpenGL, you're in a pretty good place.

Correct, it is early code.

Racket on Chez runs my code so I switched over but for most people it might be better to wait.

python comes with IDLE. Which looks dated w.r.t current IDEs. I guess for most languages, stability is the key - changing UI also means maintaining two different UIs(the old and the new)- that time could probably be better spent on language features.

> changing UI also means maintaining two different UIs(the old and the new)-

Why would you need to maintain the old UI? Backwards compatibility isn't an issue, since no one is screenscraping and doing image recognition to interact with the UI.

Besides, what we're discussing are relatively minor changes to update appearance, such as different font, color scheme, graphics assets, etc. No significant changes wrt UX--with how the user interacts with the program.

For more extensive changes, I imagine a whole load of screenshot-heavy documentation would need updating (probably a load of course notes, inherited from long-gone lecturers too).

I agree that shouldn't be an issue though. Those who don't want any change (e.g. lecturers) can stick with an old version.

DrRacket is a bigger deal to Racket than IDLE is to Python. Specifically because it provides a graphics capable REPL, which is used by a lot of the pedagogical languages and intro to programming courses that racket is perhaps best known for.

(Personally I use xrepl instead, mostly because I don't like DrRacket's text editing. https://docs.racket-lang.org/xrepl/index.html)

> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance

Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain.

Based on their most recent blog on the subject (https://blog.racket-lang.org/2019/01/racket-on-chez-status.h...), the new backend is almost uniformly slower to load, takes up twice as much memory, takes more than twice as long to build, takes twice as long to compile Racket code, and the compiled code generally runs slower than it used to. (They expect that this last one will improve, but they have never indicated that they expect it to actually match or exceed the speed of code compiled with the old backend.)

Also, the new back-end, by design, permanently removes support for the Racket C API.

This trade-off is hard for me to understand. I don’t maintain Racket, so I don’t have any idea how much effort this will ultimately save those who do. But I do know that I the main thing holding me back from investing more development time in Racket is its poor performance compared to languages like PHP, Python or Go; and I have never seen explained, and can’t even imagine, what new features the maintainers will now be able to implement that would actually make Racket development more productive or enjoyable.

I think the smaller example Matthew Flatt used in a talk about the expander is a better example. From the old expander's conception (many many years ago) only 2 people commited any changes and one of those only committed smaller instrumentation changes.

Since the rewrite (that was about 1.5 to 2x slower) less than a year ago 6 people had made commits.

What one could hope for would be some chez scheme interoperability for the really speed demanding parts.

The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance).

http://blog.racket-lang.org/img/posts/2019-01-29-racket-on-c...

According to them, fixing things takes much less time and is much easier to understand. For a system where lots of development is free, ease of understanding and fixing is extremely important.

> But I do know that I the main thing holding me back from investing more development time in Racket is its poor performance compared to languages like PHP, Python or Go

Racket is slower than Go because racket is dynamically typed, is a much higher-level language, and has to implement continuations. Racket is much faster than python or PHP.

My big issue with racket is dev tools. DrRacket isn't very good IMO. They need to make a server that implements the Language Server Protocol with some additional hooks for more dynamic lisp stuff. At that point, devs can choose to use all kinds of actually good editors (sublime, VS Code, Vim, Emacs, IntelliJ, etc) for coding. They can even add the LSP to DrRacket and continue to use it.

https://langserver.org/

At least for people who want to use Emacs and Racket, it seems like this Emacs project provides the client/server kind of setup you're talking about. Or no?:

https://www.greghendershott.com/2018/10/racket-mode.html

It's here: https://pkgs.racket-lang.org/package/racket-langserver

    The new backed is overall faster according to that post.

No, according to that post, the new back-end itself is massively slower than current Racket by every single measure shown. To reiterate, I’m talking about startup and load times, memory use, expand and compile times, and build times (i.e. time to compile the back-end itself). All slower. (Are you sure you're not referring to code compiled using the new back-end?)

I grant that there is some benefit in that the longer compile times result in an improvement in some benchmarks, but that doesn’t negate that the new back-end is still slower than the old one by every measure.

> Racket is much faster than python or PHP.

This is funny because although you will find benchmarks out there to support this point, in my experience of writing and using Racket programs it has never hold up. Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution.

I love the Racket language, and there are some DSLs like Pollen that do things I simply can’t imagine attempting anywhere else. But it’s for sure my last choice for speed, based on personal experience.

> Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution.

Can you point me to some examples of this? I haven't done AoC and so don't know where to find solutions posted to compare. It should be very rare for idiomatic python or php to be faster than idiomatic racket.

First they need to make it correct, then they will make it faster.

A major mistake in any porting is to do big refactoring changes during the process.

As for why they are doing it, to remove the dependency in C, have a safer runtime that everyone in the Lisp/Scheme community would enjoy contributing to and have a bootstraped environment, removing the 2 language syndrome that plagues a few runtimes.

I came here to say the exact same thing (but just quickly scanned to see if someone'd said it already).

Call me a snob, but I think it's a bit eclipse-ish to have a splash screen. I'll stick with tmux + vim + parinfer + rainbow parens.

Favourite Scheme implementation. Offline searchable docs, libraries for everything. And developers are making it faster now with Chez?

You might want to also try VSCIDE and Emacs - decide what works for you.

Reply on news.ycombinator.com