You can return from a function from within a lambda (and I believe this works on any number of levels), for example:
fun go(list: List<String>): Boolean {
list.forEach { if (it.isEmpty()) return@go true }
return false
}Smalltalk, and I believe ruby, allow non local return from blocks.
Anyone here have any recent practical experience in this direction who would confirm this in Lisp vs in other programming languages? Does effort in Lisp really compound/produce great code and great applications that much faster than other languages? (For web development primarily)
I feel that the lisp code was easier to write and reason about, the being able to hot reload code from the repl significantly decreased the time to completion. I also 'connect' to a networked repl when sentry reports an unhandled error to figure out what has gone wrong.
You might be tempted to believe that CL repl is "similar enough" to python's repl, however this is NOT the case. Being able to redefine functions, variables and macros while working on the code (without a restart) allows you to deal with errors.
The syntax is a 'no brainer', Extreme consistency in function calls means that you don't need to think about it. Other languages which SOMETIMES use infix, sometimes require brackets, that is just crazy.
Lisp libraries have less churn than 'modern languages', some libraries have not been touched for some time, unlike python/ruby/js. The code does not seem to rot and old lisp code runs on modern implementations.
I work in emacs, lem, I know people who use vscode and alive, and vim. There is no 'hard' requirement to use emacs, you will get by as long as you have 'emacs like' repl integration.
All in all, I do not regret working in lisp. It doesn't have the cult of the other languages and I'm fine with that.
The only other language like that I can think of is smalltalk.
We have a choice of libraries, but no big batteries-included web framework, so you must be ready to assemble pieces (or simply, to know web development). Ex: a login system? There are examples to look at, not a use-and-forget library.
A CL webserver coupled with a client library like HTMX is great. I don't recommend Reblocks (weblocks) or CLOG yet for serious stuff.
resources: the Cookbook, my lisp-journey #web content, my last youtube video (@vindarel channel).
SBCL is blazingly fast, CL abstractions are profound yet practical. The type system gives you power without pettiness. Language-oriented programming is a superpower in a world of cut and paste library-oriented programming. Image-based computing often allows one to skip the impedance mismatch with DBs. In many cases and you can just persist the data structures as they are or serialize them where needed. The tooling with Roswell, Quicklisp, Qlot, Doom Emacs, and Sly make prototyping and exploratory programming wiz by. CLOG, Reblocks and Hunchentoot provide powerful abstractions for web programming, but Phoenix with Liveview is probably better for most. The debugging experience is so insanely powerful it freaks me out and makes other systems look rudimentary. CLOS, the object system, is best of breed and makes most of the standard criticisms of OO programming moot. The homoiconic list-based syntax and prefix notation are beautiful and never get in your way. Parentheses are invisible. The condition system makes flow control and error handling in other systems seem rigid and convoluted. Aspect-oriented programming is just what we do, not a thing tacked on. Macros and the meta-object protocol allow you to build a language on top of Lisp that allows users to conceptualize problems using nouns and verbs they already know.
Drop into Coalton or Shen for strong, static typing where necessary, or April (hosted APL) for array wizardry that makes NumPy look like data-flow programming in Basic on a Timex Sinclair with a cassette drive. You can slice and dice whole datasets in a few characters of code. Bundle existing C libs with CFFI when you find a good one you need. Lisp-based systems are alive and grow and change as requirements do. It's harder to program yourself into a corner. Refactoring is continuous and mundane. In-source documentation is the right place for it, but Lispers tend to be shamefully lax in providing it. Shaaame! Newer Lispers tend to be better about docs--the culture is changing. Often you ask a question and get no response. Other times you get a detailed response from a legendary mind and just sit there in awe working your way through their thinking and feeling your inadequacy. The code is about as succinct as it can be to maintain readability. There are two camps on readability, some experienced Lispers find it harder, and most find it much easier to parse than ALGOL-derived syntax.
Once mastered, quick things are quick, hard things are straightforward, and impossible things are doable. This is a system for people who need, not want, to change the world. It gives single programmers and small teams the power to take on armies of bureaucratic programmers. But you have to be willing to break the mold, handle charges of elitism, not be required to justify your choice to managers, tolerate a small hiring pool, train newbies hard and long, not get freaked out using some libs that are stable and haven't been updated in years, deal with the pace of development of a small community, have the patience and joy in problem-solving to handle frequent bafflement, read a ton of source code rather than search the forums, and be willing to roll your own when needed. If you can handle all the idiosyncrasies and have a burning need for elegance and power, then CL will reward and surprise into until dementia takes you.
In short, all the good things you've heard are true, many of the standard critiques are uninformed, and problems people talk about that apply to most languages often don't apply.
Do you have a blog where you share your learning experiences?
So far the language I've experienced the most power with is Python, and your description of Lisp's power and tooling are very intriguing. I will take note of your recommendations and play around with the tools you described. It is worth the investment if it means unlocking something even more powerful than Pythonic thinking and code.
Do you find that one needs to be well-versed in Emacs to fully appreciate the CL stack you described and the capabilities of the language itself? Would you learn Emacs separately/after spending time building things with CL, or is building things with CL in Emacs part of the entire experience?
In this vein, it’s great that decades-old Common Lisp books are still current. The paucity of Web content is not as bad as it seems: you can get a real book.
Your comment left me with a strange sentiment. I'm somewhat disheartening because it implies that learning Lisp might be redundant given that contemporary languages have already incorporated its best aspects.
Ah, and most relevant, many folks still believe that writing OSes in what was once a macro Assember for PDP-11 is the only way.
It was as kitchen sink as having POSIX (basically a full blown UNIX specification), to be expected to fill in the stuff missing from ISO C standard library.