Racket Is an Acceptable Python
dustycloud.org
dustycloud.org
Lots of "batteries" are included in TXR Lisp: object system with static and instance slots, single inheritance, GC finalization and a form of RAII, exception handling, delimited continuations, byte code compiler for virtual machine, file compilation, macros (of course), regexes, built-in lazy lists, a fantastic set of macros for partial application, a comprehensive declarative FFI, good amount of POSIX wrapage built-in, a decent REPL with history, completion, multi-line editing, visual copy-paste, ...
TXR Lisp has a concept similar to CL's "generalized places" implemented differently. It supports Lisp-1-style evaluation (higher order functions used without a funcall operator), in the middle of a Lisp-2 substrate. Traditional list operations are generalized so they work on other sequences; you can mapcar over a string and such.
Link: https://nongnu.org/txr
I do a lot of shell based work (Linux commands, Awk, Python, Perl, and Powershell) and Lisp has always interested me, so this may scratch an itch.
How easy is this to get setup? Just a few binaries?
Also, one barrier to me has always been learning lisp as it is very different from most traditional scripting languages. I took a look at your examples and it looks neat, but a little complex. Is there a tutorial document that goes over the main functionality and commands. Like with Linux, knowing grep,cut, sort, uniq, cat, and a few others can take you a long way. I should add that although I haven't coded enough lisp to get competent, I've read two books on Common Lisp and have played with Chez Scheme, Racket, and Clojure...so I get the concepts with CONS/CAR/CDR...macros...etc.
From sources, just unpack, ./configure (with --prefix=/your/dest/dir if you don't want it in /usr/local/bin), make, make tests, make install if you're going from source. The dependencies are very low. But one of them is libffi; ./configure doesn't complain about it missing, but you get a build with reduced functionality (which doesn't pass certain tests).
For every release I make tarball packages for for older Debian 5.x (64 bit), Ubuntu 12 (32 bit), Mac OS 10.7.4 (64) and Solaris 10 (x86, 32 bit) as well as Cygwin (32 and 64).
For native Windows, I make a installer. It registers TXR into your PATH environment variable and associates .txr and .tl file associations.
TXR installations are relocatable: TXR discovers its own path and then finds the satellite files relative to its own location; if you keep the relative locations of the pieces as they are, you can move it anywhere in your filesystem. That's also useful for deployment. In the TXR executable there is a 128 byte space where you can embed command-line arguments to the executable. There is a helper function for this called save-exe. https://www.nongnu.org/txr/txr-manpage.html#N-02850687
If you've read books on Common Lisp, you're in pretty good stead. My own Lisp background is heavily Common Lisp, and the CL influences in TXR Lisp are clear; yet it's not CL and will probably mess with your head if you know a bit of CL in ways that it wouldn't if you didn't know CL. The reference manual has some dialect notes in relation to CL, far and few between though.
I don't have a newbie tutorial, unfortunately; I'm hoping someone else will write that. Keeping the documentation complete and at a good level of quality has been a big effort; it's pushing close to 700 pages now if PDF-ed.
Even as a current non user I'm always super stoked by the large effort put into these projects and wish you the best!
I have a private TODO list, in point form, that is over 1300 lines long, so there is no shortage of stuff to do.
There was never supposed to be Lisp dialect, object system, FFI, or any of those things; it really was just a specialized text extraction tool.
A decade and 5200 commits later, it's interesting that I'm the only contributor (of any logic). There have only been doc fixes.
I also didn't think that a decade later, there would be more than 5200 commits, almost all of them from only me. There have been only some half dozen contributions from outsiders: most of them documentation issues, and something in the configure script. Third party code I've brought in, of which there isn't much, I took over as if they were my own. I've kind of gotten used to it being that way; if that ever changes, it will be big adjustment from "everything here is mine".
> I also didn't think that a decade later, there would be more than 5200 commits
Did you originally not plan on working on it for quite so long?
Python and Hy have 100% interoperability. Python can call Hy out of the box, and Hy can call Python out of the box.
Any Python programmer can pick up Hy basics in minutes, and will be productive in a matter of hours. If you are an intermediate level Python programmer and have experience with Lisp macros, you will be writing macros in no time as well. Writing macro wrappers for numerical/scientific applications can increase your code's signal to noise ratio by quite a lot.
docs: http://docs.hylang.org/en/stable/
github: https://github.com/hylang/hy
get it:
pip install hy> Alas, Hy didn't really reach my dream. That macro expansion made debugging a nightmare as Hy would lose track of where the line numbers are; it wasn't until that when I really realized that without line numbers, you're just lost in terms of debugging in Python-land. That and Python didn't really have the right primitives; immutable datastructures for whatever reason never became first class, meaning that functional programming was hard, "cons" didn't really exist (actually this doesn't matter as much as people might think), recursive programming isn't really as possible without tail call elimination, etc
As far as the lack of functional programming semantics go (no tail call elimination is very sad indeed), there is no denying that either, but considering the applications I am recommending (c/c++ inter-op with python wrappers), you are hardly working in a functional domain in the first place.
However, Python does have CLIF[1], which is the nicest solution for calling into C++ that I'm aware of.
(In general, the Boost C++ libraries are well-renowned in the C++ world.)
Yes, bare bones COM is full of boilerplate, however there are more productive ways to use it.
Many languages have FFI. Lua, PHP, etc. https://en.wikipedia.org/wiki/Foreign_function_interface
I don't understand the choice of Python for things like gluing together C programs. Seems like a performant mistake, at the very least.
By picking the performance sensitive areas of the program to code in C one can often code the rest of the program in a slower more convenient language.
https://github.com/racket/racket/issues/2702
https://github.com/racket/racket/issues/2263
There were workarounds (in Racket you can instruct the GC not to move your FFI objects) and I believe the underlying issues have been fixed.
I must add that I got immediate and comprehensive support from the core developers, who not only fixed the bug but also suggested the workaround (so I could continue to support all our target versions of Racket).
Would love to know more about your experiences with doing Racket FFI. How hard were the bugs around GC to discover and workaround? What were you building in Racket?
These bugs were found while working on Herbie <http://herbie.uwplse.org/>. We use the FFI to bind to your machine's math libraries so we can properly evaluate how accurate a floating-point expression is on your machine.
To be honest though, I think the biggest missed opportunity in racket is the single dispatch object system, used particularly by racket/gui. For some reason the core racket folks weren't smitten with CLOS and didn't go the Guile route of implementing something similar to it (Guile has GOOPS, which is related to Tiny-CLOS.)
A runtime multiple dispatch stub is available as a lib, though (https://docs.racket-lang.org/multimethod/index.html)
The Racket class system has seemed fine to me for the GUI tookit (except for me not liking typing `send`). But if you find a limitation for that purpose, please post about it on the `racket-users` email list. The core developers are there. https://groups.google.com/forum/#!forum/racket-users/
FWIW, Racket (when it was still PLT Scheme) got a tiny-CLOS-alike around the time that Guile got GOOPS: Eli Barzilay made Swindle: https://docs.racket-lang.org/swindle/
CLOS is neat, and I'd be interested to see someone make a CLOS (maybe including a MOP?) for Racket, atop the modern Racket `struct` and other features. (If you tune it, try tuning for the tentatively forthcoming Chez backend to Racket, rather than for the current JIT. IIRC, Swindle was written before the JIT.)
No offense to the design team intended, I'm sure they had different priorities for which single dispatch made sense.
When you encounter yet another one, learning it is usually a matter of seeing which set of semantics it provides (probably all of which you've seen before), and the exact way they do it.
Though one nice feature they included with Racket's `class` library, which was unusual (but not new) at the time, is mixins: https://docs.racket-lang.org/guide/classes.html#%28part._.Mi...
I've used Tkinter with python to make a whole bunch of quick utilities (sync tools for non-techies, XML editing stuff for file applications which lack needed tools, etc.) and think it's very under appreciated.
Also the difference between 60MB and 100MB isn't huge, so using the word ridiculous is IMO a bit over-dramatic.
> PyQt is one of the most popular Python bindings for the Qt cross-platform C++ framework.
And why are you comparing an editor to a GUI framework? Or is there a GUI framework also called Sublime?
In my experience, python is used for Tensorflow, or Pandas, or Django, or Flask, or pytorch or something else that runs on top of it. Sometimes it is even more specialized and I need a wrapper for an API to let me talk to some web data. Maybe I need a crawler/scraper and a parser. There is a specialized language on top of the language.
So when someone says, oh this language is better with objects, or has some syntax thing or the other, or I can reason about it I am left confused.
Its like if I were talking to a professional shoe designer and I ask for hiking boots and they tell me that they're really into having at least two tones to offset the lace and the heels or something.
What am I missing? I want to reason about the language too, but doesn't that pale in comparison to being able to run a specialized library?
But if you're talking about Racket, I would want to know what you can do with it. Does it have a data science library? A web app framework?
Libraries make Python better than Lisp for machine learning. Language features make Haskell better than Python for formal verification.
However, writing your own Tensorflow interface would take several human lifetimes to get it right, and Google already has provided it. So it seems that is not the part you would re-write no matter how good the language is.
It's quite possible to also discuss the language itself independently of how much code is available for it, while acknowledging that it's an important factor for many people.
Is this your experience of using python or reading about it? I don't know your background so I apologize for making some assumptions about the source of your confusion. It sounds like you don't have a ton of experience programming, so let me start with a broadly: Python is a language in sense that English is a language, but these "something else that runs on top of it", are more like specialized vocabulary or jargon than "languages on top of the language".
English gives you the grammar/structure/spelling to communicate; it's a foundation. But it also gives you general vocabulary; adjectives and adverbs blend and interact with any new vocabulary that might come into play. It doesn't matter if its a poem, or novel, or a technical documentation, or a text book, there is still a lot of English-ness to it.
In the same way, Python as a language is still the substrate that each of those tools (Tensorflow, or Pandas, or Django, or Flask) are interacted with. I agree with what you're getting at, that maybe the tools are more important than the language. When people talk about their like for python the could talk about either: the language itself or the culture/ecosystem around the language. Some inherent to the language, so a quirk of it's history.
This applies as much to natural language. You might hear someone love the sound of Spanish or French, or praise the regularity of Latin spelling, or love Greek for the wealth of ancient, influential texts that it gives access to.
In the case of python you get a lot of praise from both angles. People love the language for it's ecosystem, sure; but also for how it does white spacing, its brevity, the specifics of its typing, where it does and dosn't need parentheses, REPLability, etc.
But you haven't responded to the argument. If someone urges you to use Racket, and you have task in front of you (say, put up a website), it sort of matters whether Racket has a framework more than if it has brackets, indents or curly braces.
> But you haven't responded to the argument. If someone urges you to use Racket [...] it sort of matters whether Racket has a framework [...]
I guess I misunderstood the question; I didn't realize you were making that argument rather than the actually wondering what other thing people care about. I guess the more direct answer would be that questions like "doesn't that pale in comparison" and "it sort of matters" are kinda presumptions about the motivations of a person "who urges you to use Racket".
Articles like this are as much targeted towards "end-user" programmers as they are for the programmers who built the frameworks in the first place. Flask, Django, etc. exist because people that like Python for things like "if it has brackets, indents or curly braces" wanted those tools in that language.
That's what I was trying to get at before: different people are excited by different things (obviously) but that languages absolutely have draws independent of tools that exist in it. Not for everyone, but not for nobody neither.
That's a still a relatively small corner of programming in general though. For most languages when talking about libraries we talk about the 'ecosystem' - what is the availability and quality of all the bits and pieces that we can build upon. It's a question of many small things, rather than one large thing.
Ecosystem differences are less absolute than 'has tensorflow', and so can be weighed up against other language advantages and disadvantages.
Web frameworks are an interesting case because you (usually) don't use them as simple libraries. The interaction with them tends to be complex enough that good frameworks are built around what the language is good at. If the language is right for the sort of programming you want to do, then the framework will express that.
I think there are quite a few of those people... maybe that gives some hope for contributions
Hackett pushes the boundaries of the Racket macro system, and IIRC through its development has found a number of deficiencies/bugs (I may be misremembering this, however, so don't take it as absolutely true). Besides that, Haskell is a rather complex language, so undertaking the creation of such a thing is no small task. And then we have the issue of what my own personal knowledge is.
I really hope development once again takes off! Its such a cool project. But I know I wouldn't have the first clue of the right way to do certain things that I know are outstanding.
I thank you for your kind sentiments though!
EDIT: I mean in addition to Typed Racket
Racket is an absolute joy to use.
Please, some famous, authoritative figure, say this out loud. I'm running out of ideas to convince people of this.
But, like Reverse Polish Notation, I don’t want to use it.
How about packages to convert Racket to WASM?
If someone out there knows more than I do please let me know because I'd love to be wrong. There is some decent linear algebra stuff, at least: https://docs.racket-lang.org/math/matrices.html
Racket is both helped and harmed by it's popularity in certain academic circles. Harmed, in that a lot of graduate students make a thesis of creating some badass library in Racket only to completely abandon it. But I'm still really rooting for Racket, it deserves more hype.
Exactly, in a few ways. One way is that a number of Felleisen's original grad students got professorships and kept doing systems research (and development) with Racket. But most contributors who don't get professorships, nor the handful of researcher jobs, end up working on other systems where the jobs are, academic or industry. Industry use tends to be one-person projects, often because you have a smart person doing something that can't be done with off-the-shelf (e.g., Naughty Dog's video game narrative DSL, a think tank researcher's work, some complicated data science server stuff that I worked on, and various indie moonlighting projects), and so one-person efforts aren't posting jobs. Bigger industry use would mean more contributors, but top programmers are generally ill-equipped for enterprise sales, so I'd bet on startup success stories to jumpstart greater popularity (even if you use Racket to beta, and then whatever you figured out gets rewritten in a popular commodity-worker platform).
I'm honestly kind of scared to ever learn a Lisp because it seems it permanently alters your brain to the point where it damages your ability to program in other languages (aka ones that you can responsibly use in an organisation can't rely on niche skill sets).
Well I thought I was being diplomatic, but my friend just shook his head and called me a moron. Can you believe the nerve of some people?
(I don't think Lisp damages your ability to program in other languages. But I do think it puts those other languages into context and that context often makes other languages worse than they did before.)
Many people are locked into an ecosystem by, for example, employment. Why make yourself less happy with the tools you need to use if doing so is for no other benefit? Ignorance can be bliss.
Because there is another benefit—what your job required today may not be what it requires tomorrow, and having your head stuck in the sand about everything outside of your current job requirements means your in the worst possible position when that kind of change happens.
However, would you consider venturing outside the cave if you were allowed to leave the cave every evening? I don't use racket at work, but I enjoy using it on the evenings and weekends. For me programming is both a career and a hobby, and for my hobby stuff, racket is more than viable. I can't have fun with racket during the day, and playing with racket during my freetime might diminish the fun I have at work when using some stodgy language, but for me it's more than worth it.
It teaches you how to think about problems in your specific domain more critically, and perhaps more effectively, even if you can't directly translate idioms into another language.
Fortunately, the MIT SICP authors made the book freely available, so anyone can continue to work through it, as a complement to our other learning opportunities.
And Racket's `#lang` support is helping to keep the particular Scheme dialect and library used by MIT SICP running on all the currently popular desktops (Unixes, Macs, and Windows): https://pkgs.racket-lang.org/package/sicp
i really don't fully understand their rationale. as i understand it, just at the time that abelson and sussman grew tired of teaching the course, mit felt the need to restructure their curriculum to meet modern demands and changes in software engineering. of course, things have transitioned from building things up to "poking", but i feel many of the principles of sicp remain unchanged. but even ignoring that, i feel mit made a crucial mistake, in my opinion.
mit is a research and education institute. as a programming language, python is not uniquely suitable for computer science research other than its machine learning and data science library support. i feel it is also not suitable for education either, especially not in the same way a lisp or scheme is. python is what is given to you and thus makes it difficult to explore and implement other paradigms of programming and other ideas in the same language like lisp and scheme can do, and certainly not in the way racket can. now, right next door to mit is northeastern, one of the major racket hubs. racket is a re-envisioned scheme and programming language. it is very much suited to computer science research, building languages for teaching and education (for example, pyret was originally implemented as a racket language), and comes with plenty of library support for general purpose programming. so other than having a lack of libraries for machine learning, data science, and scientific computing, it beats python in every category of comparison. and mit's own language, julia, takes care of those missing components. there's no reason why mit couldn't have developed libraries and teaching packages in racket for their courses.
so imagine if mit had chosen racket as their language. that would bolster racket development and popularity. it could have created a bridge between northeastern and mit and would have taught racket to the thousands of mit students and online students. it could have been a huge leap for racket in terms of popularity and use. and mit could have grown to be an additional hub for racket research and development right next door. and also, racket is an evolution of the scheme language, which would have been a perfect segue from the old curriculum.
but no, mit chose a language that was invented over a period of a couple weeks by a stubborn guy who wanted to replace perl. i strongly suspect that there were political and monetary reasons to choose python. and mit probably has a chip on its shoulder, like it does with everything. mit has also become a university driven by the need to raise money, and i think it has gone all in on taking all the machine learning and "ai" money it can. that later point is probably the real reason.
I don't know all the rationale for MIT's moves to other things, but the decision we can see seems plausible to me. (Python is a lingua franca at the moment, popular in ML and data science, still somewhat popular in Web, and very easy to pick up. Even language-nerd me wrote some production Python code that moves large amounts of important data around.)
I agree that modern Scheme (perhaps starting with Racket) seems like a great platform for much of CS-ish education, and for a lot of research and development. I also agree that putting substantial MIT resources behind building out Scheme/Racket seems like it would've been huge. Maybe that will happen.
A lot of MIT behavior emerges from that of individual faculty members and senior research staff, who have some degrees of autonomy. MIT has also prided itself on being big on "experiments", and not having rules that might get in the way of someone exploring ideas. If you have the opportunity, you can try to use that to help make things happen.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast... [2] https://www.techempower.com/benchmarks/#section=data-r18
For the frontend, there's Clojurejs.
Early on, I started doing an incomplete implementation of Arc more like what one of the parent comments suggested, and the working title was "morc: Mock Arc Programming Language as Scheme Extension". I just wanted to learn Arc, while learning Scheme macros better.
Besides possibly adding to the confusion over the relationship between Arc and Racket (or PLT Scheme), my poor choice of title caused at least one community member to be upset, that I would mock (insult) Arc. When I meant only to be self-deprecating of my own exercise, like a poor-imitation or approximation, and not to seem to presume to be implementing a full Arc this way.
Many have made the statement "Lisp/Scheme is the best programming language ever!"
https://gitlab.com/JoelMcCracken/joelmccracken.com/
My post about why I chose it: https://joelmccracken.com/entries/pollen-writing-semantic-ma...
A really good resource for understanding the motivation behind racket: https://felleisen.org/matthias/manifesto/
For a taste of the build code I wrote: https://gitlab.com/JoelMcCracken/joelmccracken.com/blob/mast... and https://gitlab.com/JoelMcCracken/joelmccracken.com/blob/mast...
Good for use cases where you otherwise might find code written in JavaScript, Python, Clojure or Ruby.
You can do web development with Racket https://docs.racket-lang.org/continue/
One thing that makes Racket somewhat special is that it can be used to build your own languages (e.g. domain specific languages) with it as it comes with the tools and a community that has experience in it.
There also is a great introduction to programming online course with Racket by Gregor Kiczales https://www.edx.org/course/how-code-simple-data-ubcx-htc1x
Probably anyone who would be interested knows it without its needing to be pointed out, but I mention in case it entices anyone that Gregor Kiczales is one of the authors of "The Art of the Meta-Object Protocol" (https://www.amazon.com/Art-Metaobject-Protocol-Gregor-Kiczal... ; edited to remove abbreviation).
Please, what does that mean? I program in Racket, and have enjoyed the vidoes but googling this phrase suggests either Prof Kiczales likes to clean floors in an innovative way, or else he is a member of Hip-Hop group. I'm not finding either terribly credible.
as a small correction though, it really doesn't teach racket in terms of #lang racket. it uses a succession of teaching languages that are implemented as #lang languages in racket. however, you do pickup pieces of racket (basically racket used as just a scheme), some of the libraries/frameworks like 2htdp, and DrRacket, the ide.
I've personally worked on a few industry Web "full-stack" projects in Racket -- including an important large server-heavy system that accomplished something on AWS that no one had yet done before, and a very complex data model HTML5 Offline app (which I did as a mixture of generated and Web services) -- that would not have been possible any other way with the developer resources available. I also used Racket for smaller Web tasks, as a researcher, to whip up a browser-based labeling UI for a large corpus (the corpus was also Web-scraped and massaged by Racket), and to save a big conference demo when the big Java server someone had made could not be deployed on the two-laptop LAN that would be available.
But if a bunch of people hear "Racket is great for Web development" without being more specific, they will run to go look at it, then they will be confused, then they will run at you with pitchforks.
Racket is potentially great for a startup doing a non-cookie-cutter MVP for which they'll have to be clever and invent some things in any case. But Racket is not going to be some variation on some currently-popular framework you already know (maybe it can be backend for one of the frontend frameworks), and you're going to have to write some code to do exactly what you want, not just glue together off-the-shelf components.
Maybe if you provided some examples of how Nim compares to Python or Racket, weighing the pros and cons, etc, I wouldn't assume you're only here to shill Nim.
Edit: Anyone care to explain why my post is flagged and the parent comment isn't? I would like to keep the discussion on topic...I didn't think I was being too harsh.
Would racket’s LOP features make it compelling? Or would you be more inclined to build it in c# since that is the target language?
EDIT: it should also allow Racket to be ported to more backends because the move to Chez is meaning more of Racket is implemented in Racket.