[yyyk2]

The GUI situation in Common Lisp is pretty pitiful. AFAIK the best you get is ECL+QT5 or cffi-cl-gtk (which is GTK 3). I don't see a very favorable comparison for Racket at all in anything else though. When people talk about the benefits of Lisp, they are usually talking about the benefits of /Common/ Lisp. Other languages often misunderstand what makes Common Lisp so great, like in the case of Scheme's overly complex pseudo-macro system.

[lispm]

The best GUI support for Common Lisp one gets from the commercial implementations Allegro CL and LispWorks. Both have cross-platform GUI libraries (ACL for Windows and Gtk, LispWorks for Windows, Gtk, macOS and Motif). Both have their IDE implemented with their respective GUI library. If one would wants to write a substantial GUI application in Common Lisp, that's one of the reasons people pay quite a bit money for those implementations and for commercial support.

There have been very substantial GUI applications implemented with both systems.

[rscho]

I'd argue that the brightest minds in computer science understand what makes lisp great perfectly.

In the lisp tradition, they made a lisp geared towards their use case, specifically. It's called Scheme... which sports much more than 'a pseudo-macro system'.

[yyyk2]

> I'd argue that the brightest minds in computer science understand what makes lisp great perfectly.

That is your personal opinion. Personally, I consider the design of Common Lisp to be much superior.

> In the lisp tradition, they made a lisp geared towards their use case, specifically. It's called Scheme...

If by "their use case" you mean teaching CS, then I would agree.

> which sports much more than 'a pseudo-macro system'.

Well, Scheme doesn't really have many features. It's meant to be a simple (and by extension limited) language. I mentioned their pseudo-macro system since it's one of the parts where Scheme (badly) disconnects from its Lisp lineage.

[zelphirkalt]

> Well, Scheme doesn't really have many features. It's meant to be a simple (and by extension limited) language. I mentioned their pseudo-macro system since it's one of the parts where Scheme (badly) disconnects from its Lisp lineage.

A language does not necessarily become limited, when it is simple. If the right simple concepts are available, all kinds of stuff can be build with them, bootstrapping more complex concepts or features. It becomes rather a question of how much is already there, done by others, or how much work oneself want to put in to have some concept in ones language. So I wouldn't necessarily say, that it becomes a limited language.

[yyyk2]

Simple languages tend to be very unportable. This has been a plague on Scheme since the beginning, and which the R6RS / R7RS standards have tried to rectify (it's debatable how successful this effort has been). This is one way in which simple languages are limited. (The fact that there are many different Scheme standards certainly doesn't help).

Another part is stripping of useful features to ease implementation. The Scheme language is full of uncomfortable, low-level constructs for the sake of simplicity. In contrast, Common Lisp is far from simple but it contains many high-level constructs which are nonetheless simpler to use.

[zelphirkalt]

> Simple languages tend to be very unportable.

On the contrary. A simple language can be relatively quickly implemented on another system, because there is not much to implement. If we look at how many Schemes there are, implemented for various platforms, and compare that to how many Common Lisps there are, we quickly see that difference. Of course CL is also more geared towards being "the one" language, rather than "make your own version of CL", exactly because of the effort required to do so. In that way one could argue it cannot even get close to the portability of a simpler language.

> Another part is stripping of useful features to ease implementation.

With useful features, you mean things, which reduce work of implementing things? Of course a bigger language will have more stuff built-in – That's in the definition of bigger language. The point is though, that Scheme does enable you to build these things. Once there is a library for it, you can use it just like other in-built things in CL. Whether that always happens to happen (a library existing), is another question. There is nothing in the language, that would prevent you from building that thing though.

> The Scheme language is full of uncomfortable, low-level constructs for the sake of simplicity.

I find them very comfortable. I also find its simplicity refreshing and a pleasure to use. It enables me to gain more understanding of concepts, which I might implement or copy from others.

[rscho]

Scheme is geared towards two things: research and teaching. It's a lingua franca for demonstrating implementations of new CS concepts in ways that members of the community understand. Being easy to implement from scratch is a must for both uses cases. Being a less imperative language also makes Scheme closer to the math.

[yyyk2]

Is it really? I haven't read many papers where new algorithms or techniques were demonstrated using Scheme.

> Being easy to implement from scratch is a must for both uses cases.

If you are teaching how to write a compiler or an interpreter, yes. Otherwise I would have to disagree.

[rscho]

Ok, I shouldn't have said 'algorithm'. Let's restrict that to 'untyped programming language theory'.

[_ph_]

There are also TK bindindings https://github.com/herth/ltk

[vindarel]

yeah… there are good IUP bindings, and embedding a CL web app into Electron (or Neutralino) is easy, once you have your standalone binary (I'll blog about that). https://github.com/CodyReichert/awesome-cl#gui