LispWorks and Allegro are both interesting, but I've found their IDE offerings to be very limited. I haven't used either since I was playing around with CL during Covid, but from what I recall, even the basic IDE experience of writing code was severely lacking: poor autocomplete, poor syntax highlighting, clunky interfaces. In most discussions I see about them, they're only recommended for their compilers, not for their IDE offerings.
I think LispWorks is fine (also look at these plugins https://github.com/apr3vau/lw-plugins - terminal integration, code folding, side tree, markdown highlighting, Nerd Fonts, fuzzy-matching, enhanced directory mode, expand region, pair editing, SVG rendering…) but I had this feeling with the newer web-based Allegro IDE (the poor syntax highlighting surprised me, did I do sthg wrong?).
This is the perfect way to create a code-base that's incomprehensible. Claude may be good at generating Rails code, but every LLM I've tried to date has struggled immensely with parsing and understanding an existing Ruby on Rails code-base.
I've seen more praise than criticism from employers.
I've seen more positive reflection than regrets from students.
(also true of Scheme based 6.001 and CS61A and HtDP)
This discussion at lobsters suggests the decision to change the curricula was political and business driven, not based on the merits of the "Fundies" course series:
I’ve found LLMs to be severely underwhelming. A week or two ago I tried having both Gemini3 and GPT Codex refactor a simple Ruby class hierarchy and neither could even identify the classes that inherited from the class I wanted removed. Severely underwhelming. Describing what was wanted here boils down to minima language and they both failed.
I feel like I'm living in a totally different world or I'm being gaslit by LLMs when I read stuff like this and other similar comments in this thread. Do you mind mentioning _what_ language / tech stack you're in? At my current job, we have a large Ruby on Rails codebase and just this week Gemini 2.5 and 3 struggled to even identify what classes inherited from another class.
> I think the future of software is going to be unimaginably dynamic.
>...I’m not entirely sure what that looks like yet, but things like this are a step in that direction.
This made me stop and think for a moment as to what this would look like as well. I'm having trouble finding it, but I think there was a post by Joe Armstrong (of Erlang) that talked about globally (as in across system boundaries, not global as in global variable) addressable functions?
> I believe that the benefits of static typing somewhat decrease in the web arena
I’ve seen this sentiment expressed numerous times and have never found it to be true in my own work (e-comm), do you mind mentioning _what_ type of domain your web apps are in?
Edit: or if not domain, what do you mean by “web arena”
I find that if most of my logic is relatively gluey, then the fields in my API boundaries are heavily optional, at which point types add a lot less than they do when most of my logic is more internal, and in cases where what I'm doing is just getting some JSON and doing something with it, I'd rather just have the dynamic shape of the JSON in a lot of cases than have to declare an entire schema/codec.
We have so much boilerplate and tooling to share request/response types between services and it's just... heavy. The same feeling arises when I'm sitting here trying to share a shape between a web app and the backend service, where FINALLY I just want the types to get out of my way instead of having to go through all this ceremony.
And my domain is relatively precise and typeable - streaming video with a deterministic set of parameters.
Generally though I'm more likely to agree with the value of types than to undersell them; I just can't find a ways to describe the above experiences such that they reflect that perspective.
I think it's not that I don't want types, it's that I want simple types that play slightly more dynamically - maps of <string, heterogeneous values>, for example, and reasonable means of interacting with them (like various "safe traversal" operators that some languages have added).
In my experience it's boiled down to the type of data you're working with. Building nested, tree-like structures and then submitting that structure to the back-end as one request is more easily done via the front-end than a bunch of back-and-forth requests followed up by a "commit" request.
edit: I suppose this is different concern than a true SPA, but as another sibling comment points out, its just a matter of time before routing makes its way into the front-end as well.
reply