Racket frustrates me
blog.winny.tech
blog.winny.tech
> Do I want to iterate every 18 hours waiting for the pkgs.racket-lang.org build server to finish building my package? Then do it again because the build failed (my mistake, but now my users have to wait until later that week…)?
( https://pkgs.racket-lang.org/ is one way of sharing an open source package, through a public repository analogous to PyPI. There is a small delay upon uploading a new package/version, because the server builds the package, runs the package's tests, formats the package's documentation, etc.)
I don't know why it would take 18 hours, and I don't see a bug report linked.
Maybe the author was just doing a commit to their own random GitHub repo, without telling the Racket packages repository, and so waited for the packages repository to do a periodic scan of all third-party packages' random Git/Web sources for new versions? (I'd always go to the Racket package repo Web UI, and push a button of some kind there, and the new version would go through promptly.)
> Do I want to worry about packaging and deploying Racket code or could I simply do the same in most other languages without any fuss? I tried packaging Racket in Nix, it did not go well.
What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/
> Do I want to invest trust in a programming platform that considers umask of optional importance? https://github.com/racket/racket/issues/4511
That was a helpful bug report, and looks like Matthew Flatt followed up on it promptly, and the bug report even got Matthias Felleisen's interest.
Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.
> Do I want to force users to adopt an application written in a language that uses at the very least 122M resident memory on my workstation? Or do I consider Python or Guile which both use less than 10M?
I don't know how the author is running their code, so this might be the best Racket can do with the code, or maybe...
DrRacket (IDE) can run code with very heavy debugging instrumentation, and you can also do similar things from the command line.
DrRacket also has a feature that limits memory usage to a specified amount, IIRC defaulting to 128MB, which is great for alerting programmers on workstations with multi-gigabytes of RAM that they might be doing something inefficient.
Code can be run from source files (silently compiling/recompiling on demand and caching for later runs), from the compiled form, or into a more packaged form (which IIRC does some tree-shaking).
What libraries you pull in can also mean surprises (e.g., I see a later comment by author in which they mention a third-party package having inappropriate dependencies).
If you want to run in really tight memory, that will affect how you program, and will include an awareness of the garbage collector.
But also, small executable size probably isn't a top priority for Racket.
> Do I want to force users to package Racket which itself has no clear custody of its build inputs - can you produce a Racket tarball yourself that is exactly like the one on the release site? Who knows what’s in those tarballs!
I suspect the author is talking here about what's now called "reproducible builds".
> Do I want to invest in a community without a mechanism to apply community feedback constructively? RFCs?
The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.
They'll find similar responsiveness on the mailing list.
> Do I want to write 4x the code (in Racket) because I forgot my secret move was actually all the pypi packages that I took for granted in Python?
Depends what you need to do. The normal case, with programmers who are performing at normal levels and with normal practices is just to using PyPI (or NPM, or Cargo, or whatever), and bang out a solution to a normal problem.
But if you need to do something unusual, or you have programmers who are super-effective and can even judiciously bang out that reusable code as needed (better than the reused packages), then consider getting out of their way -- whether they just do it in Python or NodeJS, or they say this will go better in Racket, Rust, or something more exotic.
> Do I want to wonder about what was meant by “contributions welcome” when most of the core racket codebases at best have a README, at worst have no contributor documentation?
Documentation is one of Racket's strengths. From near the top of https://docs.racket-lang.org/ , see, for example, the document "Building, Distributing, and Contributing to Racket".
> Do I want to invest in a platform where leadership is building Rombus a.k.a. Racket2 instead of focusing on making core Racket just that much better and easier to adopt? (see also: Future of Racket.)
That's a good question. Racket is solid for production, has features that other languages still haven't discovered or done as well, and the author saw the prompt attention to their bug report. (The Rhombus thing has been going on much longer.)
> Do I want to wait 10+ minutes for my package to build in CI because some other package maintainer decided to pull in racket or racket-doc (which pulls in the entire big Racket distribution)?
Talk to the developer of that third-party package?
> Do I want to ship multi-gigabyte docker images because of the above kitchen sink package?
Talk to the developer of that third-party package, and there might be additional things you can do.
> Do I want to deal with being blocked due to not understanding how to use the less understood features of racket such as continuations, syntax-parse/syntax-case macros, units/signatures? You’ll want to know about all these things to write effective Racket code.
You'll need to understand first-class continuations to work on all the Racket internals as a compiler developer. But I don't recall ever seeing a non-internals use of that.
For the syntax extension mechanisms, you can learn that as-needed and at your own pace, because it's for things that most languages can't do (and does it better than languages that can). And you can definitely learn them incrementally, and start with the higher-level forms, which might just do what you need.
Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.
> Do I want to add business risk by writing a product in Racket? Does anybody work as an industry Racket coder at all? Would I struggle to hire more talent?
It's probably needless additional risk/unknown to use for business unless you have more or more people who are able to dig in and figure out technical stuff without Stack Overflow. (Though there are helpful forums, but you'll need to rise to the occasion more often.)
And one of the the secret weapons of beloved fringe languages/platforms is that they attract those mythical "10x" programmers on basis of technical/aesthetic/community merits rather than employability, so there's more of them than there are great jobs using Racket...
> Do I…. yeah there’s more but let’s move on ;)
(End of the contiguous block, switching to sparse quoting.)
> Where did the racket-money mailing list go?
https://www.neilvandyke.org/racket-money/
It's quiet most of the time, but picks up when a new person joins or there's a question/idea.
> Or really all the production users? I only found one production user.
There's more than that, including doing spectacular productivity and importance, but there's not many.
One thing the author of the blog post might be realizing is that the Racket professors are generally super-capable, they support production users like most professors couldn't, they'll provide technical support to any random person around the world. They'd love more commercial uptake, but that's been far from their top priority.
Historically all repos were in `racket/racket`. When the repo was split into `racket/racket`, `racket/drracket` etc no readmes were added. This could be improved for sure -- but is it really that hard to ask in an appropriate forum such as Racket Discourse or Racket Discord?
It would be great to have a way of communication again, that does not require JS or Google or Discord or any other closed thing or walled garden. Especially for a programming language. Of those listed JS is probably the smallest inconvenience, so if I had a question now, I would probably prefer going to the damn discourse thing to ask it, rather than joining the Discord server.
I was a long-time skeptic of moving away from the Google Groups list, so I try to be equally vocal in saying that the move to Discourse was handled really well IMO. In fact it is not "a JS-only forum": you do need to sign up in the web UI, but, after that, you can put it in "mailing-list mode" and ignore the website completely, including for starting new threads (see <https://racket.discourse.group/t/how-to-enable-mailing-list-...>). The email interface is important to many Racketeers; if other Discourse instances don't enable it, that's their admin's choice. The Google Groups list had been rendered nearly unusable by spam, and it was never free and open-source software, which Discourse is. (I wrote more detailed thoughts at the time in <https://groups.google.com/g/racket-users/c/RnIAQnZpvh0/m/A78...>.)
On the other hand, I share some of your concerns about Discord (the similar names are unfortunate). But there was never an organized "move to Discord": some people just started talking about Racket there, as people had before, and still do, on IRC and Slack and all sorts of places. People are also regularly nudged to move non-transient conversations to searchable and archived venues.
That's why I put Discourse first.
> I am not sure whether anything from the Racket Discourse forum is findable via search engines.
It is.
> There used to be the Google groups thingy including a mailing list.
The mailing list is still running. But people have moved on to Discourse. You can configure Discourse to send you digest mails, if you prefer mailing lists.
Personally, I liked the mailing list. However, forums such as Discourse have replaced the role of the mailing list. See the forums for Swift, Rust, Processing, etc. They have all moved on to Discourse.
It seem systematic to the current architecture or developer experience - since the build environment is different than the local environment, there's going to be stuff that leaks through. For example, missing info.rktd dependencies, native dependencies, not pushing changes to dependencies that were on your local machine but not on pkgs.racket-lang.org yet (breaking api changes, additions), sometimes one gets 5xx errors from the frontend so that doesn't help.
When one clicks the "rebuild" button it simply queues the package to be rebuilt. Then you wait and hope everything is working. And come back to address the above issues.
> Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.
Bottom line, any language that tries to break away from filesystem semantics of your host OS, is going to cause footguns. Sometimes it's okay to break backwards compatibility.
> What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/
My rule is if it isn't packaged in my OS, it doesn't exist in a redistributable form. Racket isn't quite there yet; there's some effort underway to package Racket packages on various operating systems such as Nix, Gentoo, and so on.
> The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.
It's true, however a formal process to discuss feedback and next steps for Racket would help folks like myself feel confident in the direction of Racket. Otherwise it's just people on the internet saying "trust me".
> Talk to the developer of that third-party package?
Unfortunately I have found not everyone is interested in fixing their packages. I think this problem might be best fixed by making changes to the package manager to improve the developer experience. My usual work around is to vendor code.
> Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.
Is it possible to set up a unloadable plugin architecture without signatures and units?
> There's more than that, including doing spectacular productivity and importance, but there's not many.
I look forward to learning more about these users.
The package server maintains a catalog of available packages.
When you submit a new package, it is more or less immediately registered in the catalog. This means other users can try your package quickly.
What takes time is the build server. The build server builds every package available on the package server.
The build server
- builds the package in a sandboxed environment
- builds documentation
It would be nice for some improvements though:
- getting a mail when the build is done
- incremental build of packages that no other packages rely onRacket is, as far as I understand, a research and teaching language, as well as a viable scheme.
I've used it for some [command line tools and side projects][1], but I never tried to deploy anything with it.
Maybe a new [Chez][2]-based (as Racket now is) scheme is needed: one with much of Racket's nice syntax system, but focused on dependency management, targeted solely at "production" use, and other Serious Business Purposes.
Not it!
I'm not saying that Racket isn't a serious platform -- far from it. But the author's concerns, while expressed as a hot take, might be why Racket doesn't see wider industry adoption.
Or maybe it's a chicken and egg problem.
[1]: https://github.com/dgoffredo?tab=repositories&q=&type=&langu...
Maybe Chicken Scheme is the solution, then?
For this reason Clojure and perhaps SBCL will dominate serious lisp dev.
Racket is a classic example of those peculiarly dysfunctional systems that emerge from an out of touch (dare I say ivory tower) academic community who think hype and prototypes are one step away from being enterprise ready.
Is this sad only when people have to talk about their pain points?
Not the language itself (which I love) I can write code so quickly in it, and I didn't struggle for very long with fighting the borrow checker, which seems to turn so many other people off.
It's everything else. Long build times. "Modern" dependency management, which seems to mean package X only works with 0.6.x of package Z and package Y only works with 0.7.x of package Z and the current version of package Z is 0.8 and has a bugfix you really need. Though I should say that very few languages with a central repository don't have this problem; you make it easy to depend on libraries with unstable APIs and everyone will rush to do it.
I totally agree that nailing everything down to the one particular minor rev causes way more problems than it solves. The worst part is I'm pretty sure you can be more general (give me version 3, or >3.3.1, not =3.3.1) but all of the automatic tools and online guides default to nailing it down to exactly one version because they're so damn paranoid about API changes.
I will say that CPAN somehow avoided this problem. I think that is mostly because Perl programmers are far less liberal with dependencies, you don't typically see programs pulling in dozens or hundreds of modules the way you do in node projects. But it's remarkable how many old Perl programs can still pull the dependencies and start right up.
The fact that CPAN avoids this makes me think it's largely cultural. At least some of it may be that CPAN came of age in an era when internet access was less reliable and slower.
Some of it is also that development "in the open" has become more the norm. When releases are rare and only contributors have VCS access, then there are fewer opportunities to depend on unstable interfaces.
I was surprised when I installed `git` and it pulled a couple dozen Perl packages from the distro repo.
There's definitely something to be said about Linux distro maintainers/packagers being sort of middlemen that help enforce compatibility for popular Perl (or Python2, etc) packages.
That is, there is a nonzero amount of greybeards between the developer and random end user, which cannot be said for your average npm or pip package.
Probably because CPAN existed before SemVer.
Given that patch version bumps of a dependency might break a project, I think giving up on the SemVer paranoia would be the best solution.
If a dependency breaks you just release a new patch release of your software with the version pinned before the breaking version. Add a field to the package manager to hint at the dep solver that it should never downgrade to remove that depedency because it was added due to a breaking change to sort of make it retroactive.
And the failure of many projects to go 1.0 because of paranoia about breaking changes and therefore the failure of SemVer should really be more widely discussed.
It's important to recognize pain points so we do not become complacent with low quality developer experiences. Worse, complacency with software lifecycle at scale - will our product deploy on a cluster? Will our software be maintainable 5 years from now?
Better we look at the pain points now than accept a poor DX for years to come.
(Currently I work in LÖVE, but programs there use at least 100MB, so it probably won't be to OP's taste.)
Many of you will assume I'm a moron for choosing such a retrograde, simpleminded language. It's true! I am a moron compared to most HN readers. And your language is much more sophisticated than mine and had generics long before and didn't need a make keyword and stuff. No disagreement there.
All I know is I can get the job done faster in Go than with Python, and I have type checking too. Plus a sane-ish package manager and a single, stable ecosystem. Plus I can deploy a single executable that even lets me embed assets inside it. It just stays the hell out of my way.
Python frustrates me too, but I just throw poetry and nix at it... keeps me not frustrated. :D
It looks like my LOVE game uses about 99M resident... not too bad given it's pulling in a lot of libraries such as SDL2, luajit, audio decoders, etc etc.
I think my concern is more with how do I embed Racket on low memory systems if a simple "racket script" is going to use a large % of the RAM to issue a `(sleep)`?
I have a low traffic web service and I wasn't happy with ~125 MB of my 512 MB VM's memory being used up by SBCL, but I was able to just drop in CLISP and memory usage dropped to ~25 MB (and for reference: a "hello world" is under 10 MB with CLISP, similar to Python).
I cannot imagine going back to Python, Ruby or PHP after using modern languages like these.
Also, Java performance is good enough. Why did anyone ever abandon Java? It's easy to read, easy to write and pleasant enough to work with. If you need C level performance, by all means go with C, Go, Rust but Java to me is perfect, and Typescript is good enough for everything else.
public void setPints (int pints) {
this.pints = pints;
}
public int getPints () {
return pints;
}
Personally I kinda like Java, despite it having 4 different kinds of brackets and object.method() syntax. Maybe it's the combination of 1 file 1 class and using classes for everything.
Regardless, I'll stick to Common Lisp and C for the time being, they're nice.
It doesn't have the -esque syntax and similar overly verbose constructs.
Because I physically recoil when 80% of the code is "APIAccessConfigurator apiAccessConfigurator = new APIAccessConfigurator(apiAccessConfiguratorToken, new apiAccessConfigurationParameters().class)" and similar crap.
Python remains a lot simpler. It is getting more complex, but it has miles to go before it reaches Java-land.
Java applications (mostly picking on tomcat here) being pretty much their own world of configuration, with lots of different places to look.
Slow startup time pretty much kills it for lots of things I'd wanna write.
It's memory management stuff sucks, from a sysadmins perspective. Any java application I deploy takes easily multiple times more memory than anything similar in a non-JVM language.
Yes, lots of Java apps basically go "lol .... KABOOM" if you give them less than half a gig of RAM to play around in, but IMO that's a tragedy of the commons like thing within the ecosystem where common approaches mean you end up with layer upon layer of libraries none of which thought -their- RAM use was particularly egregious.
At this point, it's not the runtime's fault (G1 is excellent), and while you could argue that the language design led developers to do things wrong I think it's more a culture phenomenom - I think I might consider blaming J2EE and its proponents rather than the language itself.
Of course, from a sysadmin point of view, the runtime+application combination's memory usage is what matters in practice, I'm just saying the reason why you find yourself staring at the screen thinking "wait, it's using how much?!" is more complicated than "Java's memory management stuff sucks"
> Do I want to iterate every 18 hours waiting for the pkgs.racket-lang.org build server to finish building my package? Then do it again because the build failed (my mistake, but now my users have to wait until later that week…)?
I agree it should be improved, but I think that deploying to the package system is something that happens not very often. The idea is to keep only a safe and stable version there.
> Do I want to write 4x the code (in Racket) because I forgot my secret move was actually all the pypi packages that I took for granted in Python?
It would be interesting if the author post in github a feature request for the 3 missing packages that are more painful. (3 is a good numbers to find someone else that care about one of them, more than 3 or 4 would be annoying)
> Do I want to wait 10+ minutes for my package to build in CI because some other package maintainer decided to pull in racket or racket-doc (which pulls in the entire big Racket distribution)?
Sometimes I use minimal-racket, and it's this is annoying. Most people just use the main distribution so this is not a problem. IIUC the author cares about a small footprint, so it's a special case. I use Ctr-C, but I guess there is a trick with raco pkg to do fix this automatically.
> Do I want to deal with being blocked due to not understanding how to use the less understood features of racket such as continuations, syntax-parse/syntax-case macros, units/signatures? You’ll want to know about all these things to write effective Racket code.
You can skip most of them to write effective Racket code.
I use continuations only as an emergency exit inside nested fors, no fancy stuff. (I agree the fancy stuff is weird.)
I think units/signatures is almost deprecated. It will be there forever to keep backward compatibility, but I expect new code to use modules instead of units.
About macros:
If you are programing alone just use syntax-rule. syntax-case is not so difficult unless you want to do weird stuff. I've done weird stuff in the past, but five years later I regretted it.
If you are programing in a team, it's important that the macros have good error checking, because otherwise in case of an error it will expand crap that will expend to more crap and after a few rounds of crap expansion the poor soul that is using it will get a unintelligible error about code they didn't wrote. Here is where syntax-parse is useful, to ensure the initial code makes sense and expand only good code and give a good error reporting otherwise. syntax-parse is almost a separate DSL, so it's a lot to learn. (You can write the same stuff with syntax-case, but syntax-parse automates a lot of stuff.)
here's a few that come to mind.
1. mumble client
2. CLI framework similar to cobra, click, etc
3. Bot framework similar to Cinch
4. WebRTC
5. off the shelf plugin framework
6. ssh library
7. gopher library (or just libcurl)
8. ntlk (natural language toolkit)
9. file/libmagic clone
10. image manipulation library
11. expect-like library for automation
12. probably more, these came to mind
> I use continuations only as an emergency exit inside nested fors, no fancy stuff. (I agree the fancy stuff is weird.)
Part of the racket web server requires continuations to use - so that's a blocker for anyone wanting to check out the racket web server in its entirety.
If one needs to do anything nontrivial with state, one might end up wanting dynamic-unwind, which means understanding continuations. (Example https://github.com/winny-/umask/blob/master/umask-lib/umask/... )
> I think units/signatures is almost deprecated. It will be there forever to keep backward compatibility, but I expect new code to use modules instead of units.
Can you do plugin architecture without signatures/units?
I found this https://pkgs.racket-lang.org/package/remote-shell
> 7. gopher library (or just libcurl)
Is someone still using gopher? It's weird that there is no libcurl wrapper. I expected to find one. (I used the http libraries that are included in the main distribution, but some people may prefer to use libcurl instead.)
> Part of the racket web server requires continuations to use - so that's a blocker for anyone wanting to check out the racket web server in its entirety.
Yes, and the webserver has two kind of continuations. In one type the info is stored inside the memory of the racket webserver. In the other type the info is stored in the URL or something, but you must use a subset of Racket to be encoding friendly.
I use the webserver, but I just ignored both of them. Each webpage is a different rkt file. So fancy servlets, no continuations. All the info is stored in cookies or the hard disk.
Also, doing a rewrite into an Ml style language is really strange when they should probably be trying to become more competitive with other languages by building more batteries for it or fixing fundamental problems that were outlined here.
in what world does racket get classified as a 'small language'? it was one of the originals who focused on the 'batteries included' aspect for the sake of being more applicable in education.
From what I know, Rhombus and Racket are parallel, mutually-beneficial projects. The development of Rhombus has contributed smaller features into Racket, while showcasing Racket's capability for language development. Rhombus is, in a sense, filling in gaps that Racket may be missing.
But from a working-with-other people perspective, imagine opening some code and finding random invented constructs you have to reverse engineer and step through. These days it seems everyone creates yaml or json files, and then implements some kind of declarative engine or interpreter to implement their DSL. This can be both easier to read and debug. For more complicated use cases you can tie it to a graph database that supports reasoning, instead of json/yaml
Even so, is there really something that can be done with macros that can't be done, just as elegantly, with simple state machines, or object composition style in other languages?
This feels just like working with another API to me. Macros can be arbitrarily complicated I suppose, but is the typical usage any more complex than learning an API? I don't really know, I guess, but my experience hasn't shown this to be that challenging.
I can appreciate that programming languages are ultimately codifying a particular way to think about computation, and macros express more idiosyncratic ways of thinkingabout comouting that may not be readily understandable.
I do think Racket has issues, but this isn't the first one I would cite.
Like functions and procedures?
I would pray that a good number of them are compile-time code transformers that execute in the comfortable development environment, so I don't have to reverse engineer and step through them on the embedded target.
Macro expansion occurs at, well, macro expansion time which is prior to compilation (in a compiled lisp, as is the case in the context of Racket). The result of the expansion is what gets compiled. You could certainly express a state machine using macros (or with the aid of macros), perhaps even offering macro/compile time optimizations (hypothetically, you could take a regex in some form and convert it through a macro into straight code removing some runtime overhead). But macros are much, much more than "simple state machines". And I'm not sure what you mean about "object composition style", unless you're talking about the OO sense of preferring composition over inheritance. Which, again, what does that have to do with macros?
Eg somekind of cron-like event library, made from a macro
(wait 6 'hr' (run './myapp'))
Scheduler.create(6,'hr').then(() -> system('./myapp'))
scheduler(6, 'hr', steps= [() => { system(./myapp) }, ...]);
In the end macros save you a tiny bit of typing at the expensive of limiting static analysis tooling, limiting readability since the language can be modified, and most the time the runtime way of doing it 99.9999% as fast, easier to understand, easier to debug by stepping through it. That being said I like using macros, especially in emacs. No one will ever read my dot files, and I can live in my own world.
(wait 6 :hr (lambda () (run "./myapp")))
(wait 6 :hr (op run "./myapp"))https://google.github.io/styleguide/lispguide.xml?showone=Ma...
"You must never use a macro where a function will do. That is, if the semantics of what you are writing conforms to the semantics of a function, then you must write it as a function rather than a macro."
(eval-when (:load-toplevel :execute) ;; don't evaluate functions in compiler
(setf (symbol-function 'add)
(lambda (x y)
(block add (+ x y))))
(defun add (x y) (+ x y))
Usually people whip out the LOOP macro, so let's skip that.
How about pattern matching (TXR Lisp). A simple expression like:
(if-match (:pre :amble (@x) @(oddp @y)) obj
(list x y))
5> (macroexpand-1 '(if-match (:pre :amble (@x) @(oddp @y)) obj
(list x y)))
(alet ((#:g0051 obj))
(let* (#:result-0064
x y)
(if (if (consp #:g0051)
(alet ((#:g0052 (car #:g0051))
(#:g0053 (cdr #:g0051)))
(if (equal #:g0052 ':pre)
(progn (if (consp #:g0053)
(alet ((#:g0054 (car #:g0053))
(#:g0055 (cdr #:g0053)))
(if (equal #:g0054 ':amble)
(progn (if (consp #:g0055)
(alet ((#:g0056 (car #:g0055))
(#:g0057 (cdr #:g0055)))
(if (consp #:g0056)
(alet ((#:g0058 (car #:g0056))
(#:g0059 (cdr #:g0056)))
(progn (set x #:g0058)
(if (equal #:g0059 '())
(progn (if (consp #:g0057)
(alet ((#:g0060 (car #:g0057))
(#:g0061 (cdr #:g0057)))
(progn (set y #:g0060)
(alet ((#:res-0063
(alet ((y #:g0060))
(oddp y))))
(if #:res-0063
(if (equal #:g0061 '())
(progn (progn (set #:result-0064
(list x y))
t)))))))))))))))))))))))
#:result-0064
The optimizer does a good job of reducing that kind of code, and the code walks through the list only once, using temporaries for successive cdr values.
The way I might write it might look terse, but involve redundant accesses to the list from the start.
Common Lisp's simple destructuring pattern operator destructuring-bind is also a macro.
[1]> (macroexpand '(destructuring-bind (a (b c (d))) list (list a b c d)))
(LET ((SYSTEM::<DESTRUCTURING-FORM> LIST))
(IF (NOT (SYSTEM::LIST-LENGTH-IN-BOUNDS-P SYSTEM::<DESTRUCTURING-FORM> 2 2 NIL))
(SYSTEM::DESTRUCTURING-ERROR SYSTEM::<DESTRUCTURING-FORM> '(2 . 2))
(LET*
((A (CAR SYSTEM::<DESTRUCTURING-FORM>)) (#:G3318 (CADR SYSTEM::<DESTRUCTURING-FORM>))
(#:G3319
(IF (NOT (SYSTEM::LIST-LENGTH-IN-BOUNDS-P #:G3318 3 3 NIL))
(SYSTEM::ERROR-OF-TYPE 'SOURCE-PROGRAM-ERROR :FORM SYSTEM::<DESTRUCTURING-FORM> :DETAIL #:G3318
(SYSTEM::TEXT "~S: ~S does not match lambda list element ~:S") 'DESTRUCTURING-BIND #:G3318 '(B C (D)))
#:G3318))
(B (CAR #:G3319)) (C (CADR #:G3319)) (#:G3320 (CADDR #:G3319))
(#:G3321
(IF (NOT (SYSTEM::LIST-LENGTH-IN-BOUNDS-P #:G3320 1 1 NIL))
(SYSTEM::ERROR-OF-TYPE 'SOURCE-PROGRAM-ERROR :FORM #:G3319 :DETAIL #:G3320
(SYSTEM::TEXT "~S: ~S does not match lambda list element ~:S") 'DESTRUCTURING-BIND #:G3320 '(D))
#:G3320))
(D (CAR #:G3321)))
(LIST A B C D)))) ;
T
Defining object, with complex bells and whistles (TXR Lisp):
2> (macroexpand-1 '(defstruct myclass (these are super classes)
(:static static-slot 42)
uninitialized-slot
(initialized-slot 73)
(:method meth (me : optional-arg) (list em optional-arg))
(:postinit (me))
(:fini (me) (put-string `finalizer invoked on @me`))))
** expr-1:1: warning: defstruct: inheritance base these does not name a struct type
** expr-1:1: warning: defstruct: inheritance base are does not name a struct type
** expr-1:1: warning: defstruct: inheritance base super does not name a struct type
** expr-1:1: warning: defstruct: inheritance base classes does not name a struct type
(sys:make-struct-type 'myclass '(these are super
classes)
'(static-slot meth)
'(uninitialized-slot
initialized-slot)
(lambda (#:g0019)
(when (static-slot-p #:g0019 'meth)
(static-slot-set #:g0019 'meth
(sys:meth-lambda
meth myclass
(me : optional-arg)
(block meth (list em optional-arg)))))
(when (static-slot-p #:g0019 'static-slot)
(static-slot-set #:g0019 'static-slot
42)))
(lambda (#:g0019)
(finalize #:g0019 (sys:meth-lambda
myclass :fini
(#:g0019) (let ((me #:g0019))
(put-string `finalizer invoked on @me`)))
t)
(let ((#:g0020 (struct-type #:g0019)))
(unless (static-slot-p #:g0020 'uninitialized-slot)
(slotset #:g0019 'uninitialized-slot
()))
(unless (static-slot-p #:g0020 'initialized-slot)
(slotset #:g0019 'initialized-slot
73))))
() ())
defstruct supports custom clauses you can define using define-struct-clause. There are some predefined ones for declaratively doing delegation between classes and what not.
The implementation of assignable places ("generalized variables") is done through macrology. All the place-mutating operators like setf, incf or push are macros. They analyze the syntax of the place and use the material from the back-end definitions to write the code, ensuring that complex places are not evaluated multiple times. Programs can define new kinds of places.
Object access? In TXR Lisp there is a macro qref. It corresponds to a dotted read notation:
1> '(qref a b c (d arg))
a.b.c.(d arg)
2> (expand 'a.b.c.(d arg))
(let ((#:g0024 (slot (slot a 'b)
'c)))
(call (slot #:g0024 'd)
#:g0024 arg))
12> (expand 'a.b.?c.(d arg))
(let ((#:g0025 (slot a 'b)))
(if #:g0025 (let ((#:g0026 (slot #:g0025 'c)))
(call (slot #:g0026 'd)
#:g0026 arg))))
You should use the quality, documented macros that are already provided. That's why that coding conventions document says that you should use macros liberally, just define them sparingly.
Lisp being built on macros has some nice advantages like if you have to work with an older version of some Lisp which didn't have some language feature, you may be able to backport those macros to polyfill that.
Many simple macro use cases are covered by lightweight lambda syntax, reflection, or language constructs, e.g. Go's defer, Python's with, and C#'s using. Complex macros can create DSLs or rewrite code for optimization, though. Series[0] is a Common Lisp library that rewrites lazy streams into an imperative loop. LOOP[1] and ITERATE[2] are DSLs for iteration. Schelog[3] embeds Prolog inside of Scheme. Serde[4] generates serialization code.
Here are some old threads on the Lightweight Languages mailing list that discuss use cases for macros. Participants include Trevor Blackwell, Paul Graham, Dave Moon, Todd Proebsting, Guy Steele, Dan Weinreb, and many others.
• Macros Make Me Mad [5]
• macros vs. blocks [6]
• how expressive are they [7]
[0] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html
[1] https://gigamonkeys.com/book/loop-for-black-belts.html
[2] https://iterate.common-lisp.dev/
[3] https://ds26gte.github.io/schelog/index.html
[4] https://serde.rs/derive.html
[5] https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...
[6] https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...
[7] https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...
My guess would be a C# using block. I think the Java equivalent is "try with resources" but I don't remember. In Common Lisp it'd be WITH-OPEN-FILE, or a similar macro made on top of UNWIND-PROTECT ...
> or object composition style
builder pattern comes to mind :)
There could be macro for that:
(with-other-people ((bob (lookup :accounting "bob"))
(alice (lookup :human-resources "alice"))
... some workflow about about last payroll ..
) ;; people are nicely disposed at the end of scopeWhen you've put 40,000 lines into the program, and your language is suddenly impacting your productivity more than you like, you can't just drop all that and switch!
Your language has you hostage. "If you don't like the dent I'm putting in your productivity, go rewrite 40,000 lines in something else. Mouhaha!"
I don't know much about scheme or racket, but am aware that continuations is one of its distinguishing features. I've seen people praising syntax-case as a great take on macros. I've never heard of units/signatures, though.
I know this was supposed to be a rant, but I wonder what drew the author to want to use scheme/racket in the first place?
I'm surprised no new languages focus on ecosystem. It is much less fun than making clever syntax I suppose.
Most new languages that I know of have a package manager/inbuilt dependency resolution mechanism and a fairly robust module system to try and support 3rd party dependencies.
Rust, Go, Dart, D. You can expect every language post 2010ish to have this.
So, ultimately, all people are saying when they knock Go's package management is that they don't like how it works. That's fine, I don't like how all sorts of things work. But "nothing" is false, and "hacky" is so subjective as to be practically worthless. Obviously, the reason Go gets picked out in these discussions is that it's quite successful as a language, and, to me at least, it follows obviously that they solved package management to some level of the community's satisfaction, because languages without package management aren't successful.
If we wanted to hash out the pros and cons of different package management strategies, that's all the thread will be: just hundreds of back-and-forth messages about package management. It's a big topic.
When I wrote Go, the official language policy is that you do not need versioning and should not make breaking changes. Throw everything into a vendor/ if you must. For me, that kind of stance on package management definitely warrants attention.
There are lots of things I don't like about NPM. But imagine claiming that Node doesn't have real package management. You can't even write a for-loop in Node without a package. Go isn't quite that far gone, but it's pretty hard to write idiomatic Go of any significance with zero packages.
But they really did launch with no solution and take a fairly long time to figure it out.
The same can't be said of slightly older languages like C#, Java, or python. Perl, for all its foibles, was probably the first language with a more modern package management system (CPAN).
The problem is if you don't consider these things in your initial design, the solution you end up with later tend to be worse.
I think nix might be the way--just have one package manager to rule them all--but I'm not aware of any language ecosystems that are leaning into this.
Yup, the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. You might get lucky like Java did with maven but that's no real guarantee.
> but I'm not aware of any language ecosystems that are leaning into this.
Bazel does. However, bazel (AFAIK) generally does things by leaning on the existing build systems of various languages.
For software, unfortunately we are in a "jack of all trades master of none" scenario. I don't think there's a one size fits all solution.
To be fair, Haskell doesn't have 20. It has two.
But yeah, fair point. And maybe we can rely on newer languages to converge on a package manager faster than the languages of old did due to the internet.
It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different.
They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them.
Learning languanges would be so much fun if I didn't have to learn a new package manager each time.
However, I'd say it's a lot better situation than what exists for C/C++ ATM.
(Package name, version number) -> (cryptographic hash of package bits)
Both is, and ought to be, table stakes for modern language ecosystems. But when it comes to tooling for hosting, fetching, installing, and contributing re: those maps, there's no reason to have each separate language community build an overlapping set of tools that solves those problems.
I understand that when you have a new language, building all of that tooling is probably a fun way to flex it, but it's a bigger problem than most language communities really have the interest in to solve properly. So it ends up being a hack job every time.
I'd argue that the only reason Java doesn't feel like a hack job re: packaging is that they've (wisely) solved a smaller problem. I can use pypi to install a python package with Java dependencies, but I can't (so far as I know) use maven to install a java library with python dependencies.
Better would be to have some lightweight standard for mapping package names to hashes, and then decouple the hosting/trustworthyness indicating/installing/packaging concerns such that language designers don't have to worry so much about those things since they're not really language specific problems.
Frankly, I wish new languages focused more on flexibility and expressiveness even if that made things harder up-front!
Design languages for experts, not beginners. It might be more difficult to get started but if it's well designed it pays off.
Honestly, this is a lot of the draw of Go and Rust for a lot of people; other than debugging (which I can't speak to from experience, but as I understand it, both are on par with C++), the points you hit on above are all things Go and Rust have really solid answers to compared to their contemporaries.
Yes.
I disagree. You can get up and started in most language stacks fairly quickly. Keep focus, learn to sort advice into helpful and unhelpful buckets, and start building with a goal in mind.
For example - I hadn't touched fennel nor Love2d until about a month ago, and we made something happen.
You can do this too.
In contrast, I spent a ton of time trying to build other lisps that are designed to be embeddable on those consoles and got nowhere.
Fennel rocks. Such a pragmatic and well designed mini-language.
The article is about what it takes to really know a language. That's a bigger task. It takes months, if you work fast. That's how you write high-quality, maintainable software.
You can do this too.
In a way it is. After all if i make a new language, i can control what it can do and how it evolves but i can't control other people to force them use it.
All of them?
Go, Rust, Kotlin, TypeScript
I did not learn much in that course.
These are highly restricted teaching versions of Racket which do not include the vast majority of the language features. They also use beginner friendly names such as first and rest instead of the cryptic car and cdr. These languages allow students to learn functional programming and basic concepts such as recursion, linked lists, association lists, higher order functions, trees, and graphs without worrying about programming language details such as side effects, fixed size numeric types, memory allocation, pointers, macros, compilers, etc.
For that purpose, Racket seems pretty hard to beat! For the professors, it also has the (nice) side effect that many students with previous programming experience are less likely to have learned Racket (or any functional language for that matter). This has been argued to put the students with and without programming experience on a more equal footing.
[1] https://docs.racket-lang.org/htdp-langs/beginner.html
[2] https://docs.racket-lang.org/htdp-langs/intermediate.html
For example, consider the program `((+) 1 2 3)`. Racket gives a runtime error "application: not a procedure" because (+) evaluates to 0, which is then applied to "1 2 3", which errors because 0 is not a procedure. But BSL can give a (helpful) syntax error, because it doesn't have higher-order functions.
(I feel like someone's going to tell me that BSL or ISL isn't a subset of Racket for some obscure reason. They're at least essentially subsets.)
To elaborate, one of the further benefits of multiple student languages like these is that concepts are taught incrementally. For instance, in the beginning student language, lists are explicitly shown as `(cons a (cons b '()))` before they are shown as `(list a b)` in intermediate student language.
So many concepts got in the way of actually learning programming: You have to include header files for basic I/O to work. You need to understand functions to get any program to work. Pointer syntax sucks. Strings are complicated.
Coming from BASIC and QB, the barrier to entry in C/C++ was way too high. To be frank, Racket is more suitable, even if it's not the best option.
In seriousness, Racket is semi-commonly used in educational settings. Especially for "functional programming"-type courses.
I’m not doubting you. I’m interested in what parts of Racket could be confusing to beginners, maybe to make better courses
Sure, that’s one of its roles. Racket helps me think. Maybe I’m lucky, and work on genuinely novel problems where a malleable language beats libraries.
So, sure, the Racket ecosystem leaves much to be desired, but getting stuff done is only one of programming’s roles.
I worked at a few companies where, when I needed to model a tricky system and build out an algorithm to do a tricky job, I turned to Racket as a draft. Once I got a POC done, we’d turn around and build it For Real™.
If all you’ve ever done is work as an implementer, then yeah, this flow doesn’t make much sense. But I think for people who work as problem discoverers, this is more common than not.
https://www.youtube.com/watch?v=ydyztGZnbNs
He seemed happy enough with the language.
I have been eyeing racket for a while now, but could never quite make the jump. Racket (the programming language) has definitely a lot of potential, but i do believe the academic side of it and the focus on the "build your own language" part might be an impediment to racket growth.
If i was to suggest some stuff :
- Clearly split Racket (and typed Racket) the language, evolution of scheme and Racket the PLT framework use to build and construct new languages. Racket / typed Racket should focus on more production/libraries for regular programmer - More examples/libraries/package not directly related to PL and PL teaching. Create a website solely for Racket/typed racket, with the academic part. - DrRacket always felt and looked alien to me. I can't really judge the feature set, but having vscode as the defacto IDE i think would be it more welcoming - This one is will definitively be controversial but introduce a "curly brace"/C style syntax for Racket. Something implemented at the reader level. Same semantic/runtime behavior, and a reader/printer to go between Racket and {C|rust}SyntaxedRacket.
That's a lot of effort, so why do this ? I believe the world is looking for a better python. There is a lot of contender right now (julia, nim , etc... etc...). I think racket should also throw their hat in the ring.
It's very much possible to use Racket without interacting with macros and language-building features.
> Racket / typed Racket should focus on more production/libraries for regular programmer
Libraries are dependent on the community, which unfortunately is comprised of mostly academic folk at the moment.
> DrRacket always felt and looked alien to me. I can't really judge the feature set, but having vscode as the defacto IDE i think would be it more welcoming
I do agree -- if I remember correctly, DrRacket was primarily built as a pedagogic IDE, not one meant for more professional use. VSCode, however, does have the "Magic Racket" extension.
> This one is will definitively be controversial but introduce a "curly brace"/C style syntax for Racket.
Not necessarily C-style syntax, but you could take a look at Rhombus. It's meant to have a more approachable syntax compared to S-expressions.
I would say that macros are integral part of Racket, maybe event the best part.
But point is not about what is possible, it's really about what is the default/obvious part. It wasn't a comment on racket the language, but more about the environement around the language.
> Libraries are dependent on the community, which unfortunately is comprised of mostly academic folk at the moment.
I am not sure what point you are making here. Julia has a very very strong academic community, but the library ecosystem seems more production ready and actionable.
> Not necessarily C-style syntax, but you could take a look at Rhombus. It's meant to have a more approachable syntax compared to S-expressions.
Rhombus seems to be more than just alternate syntax. And how is the progress on this thing ?
I think to make racket more mainstream would need more than things that are "possible", or available etc... It probably need a cohesive story and experience around those, and that story to be at the for front on how Racket present itself : vs code extension as the main IDE, alt syntax + better libraries.
This already exists, in a few forms (e.g. Sweet Expressions). I wrote a blog post listing a few, for whenever this topic comes up ;) http://www.chriswarbo.net/blog/2017-08-29-s_expressions.html
So it's not like you can just pick up R8RR (since it's on version 8, and keeping with the naming convention of Scheme standards as in R5RS) and start building something.
Common Lisp also has a standard for implementers to follow, and is about 25 years older than Racket. That's given implementers a bit more time.
Regarding Clojure, what's the status/quality of all the other implementations?
Common Lisp has more than a couple of implementations, especially when we take a historic view. However, say, Steel Bank Common Lisp has only one implementation.
Many other deployments work similarly. Make a docker container and put it anywhere. Are Racket docker containers necessarily that much bigger than lets say Python ones or GNU Guile ones?
Racket is packaged in GNU Guix btw., even, if I have had mixed experiences with the package, it should be mentioned. So someone already succeeded in packaging it in the package manager, that once was derived from Nix.
> Do I want to write 4x the code (in Racket) because I forgot my secret move was actually all the pypi packages that I took for granted in Python?
This really depends on what kind of code you are writing. When I wrote some Racket programs, I used mostly built-ins or perhaps 1 or 2 dependencies. Depending on the project, maybe one needs more of those dependencies and writing them oneself would be too much work. But for simple dependencies that are easy to write oneself, I wouldn't want to use a dependency from PyPI.
> Do I want to deal with being blocked due to not understanding how to use the less understood features of racket such as continuations, syntax-parse/syntax-case macros, units/signatures? You’ll want to know about all these things to write effective Racket code.
Hm, I don't know whether you want to. Do you want to be a capable programmer understanding more language concepts, being able to apply them perhaps in your next project or when learning your next language? Do you want to be able to express things elegantly than possible in Python for example? Do you want to know Scheme things? If not then OK, we all make our choices. I personally don't think it is good to avoid learning about something like continuations and stumble on without such knowledge as a programmer, but in more mainstream languages it probably is sufficient. However, one can also write lots of effective Racket code without going into macros. One does not have to follow the idea of having to make a language.
> But then the real hard truths started to appear. I was losing a lot of productivity. The productivity losses were incremental but certainly slowed down my velocity significantly over the last seven years. Sure the language has a lot of wonderful features, but there’s more to a good programming language than well, its programming language.
This is probably the most important point raised.
I hope though, that people who run into any shortages with Racket consider building the thing they are missing, if they are able to, to add to the ecosystem and to avoid the next person running into the same thing lacking. If no one ever writes their own, we will only ever stick with the status quo in terms of programming languages. (And fortunately people do write their own often.)
Leadership needs to involve the community, then this can happen. Right now it seems that decisions around Racket are made at will - no process or formal discussion.
Anyhoot - I think clojure is the best lisp there is right now, but for better or worse it is tied to the jvm and seems to be stagnating.
All the lost productivity the poster is bemoaning could have gone into mastering hard and useful skills instead and these things compound.