41–50 of 126 posts
You powered it on, and it landed you in a BASIC environment. Apple IIs, C64’s and Ataris all had a full-screen editor environment where you could type code, run it, pause it, inspect variables, and continue running. It wasn’t LISP, sadly, but it was great as an introduction and moving to “more professional” environments and tools took away a great deal of freedom away from us.
Lisp really is an eye-opening experience when learning to structure programs and computations. Stumbling on Lisp in college was a fascinating experience for me in particular because I had been raised around C++ and Java, and my programming life up to that point had been a struggle understanding how to abstract a program into objects and how to build those objects' interfaces. Once I started down the path of functiona…
The OO patterns are still quite popular in enterprise software, where people mostly work in large teams. Hiding implementation details is terribly annoying for a single developer, but can be a great way to reduce complexity for other team members. The same consideration applies to other powerful constructs, such as static typing, garbage collection, operator overloading, and macros. Whether you work alone or in a tea…
This is exactly why I exclusively write Perl, C, and Lisp, simply they are fun to write, and provide me with the capabilities to feel powerful as a developer. Most software written these days lands in languages that make me feel like a drone, endlessly fighting a system in place or a pattern for some arbitrary theoretical gain that is never realized in the real world anyways, OOP, Type-Systems, FP, whatever, why woul…
- Perl: prototype to C, short things to not spawn awk/sed/sh, or silly things from CPAN
- C: Sadly, C is to computers what English is to science/tech/world: maybe not the fanciest or easiest language, but it's everywhere on low level business and everyone being educated has at least basic competences.
- CL: Crazy things you wont see IRL until 20 years have passed from now.
Having programmed professionally in 36 languages, I must agree with this. I am having so much fun with Lisp, that I am not likely to go back. > Often developers say how you can make a mess of a Common Lisp codebase because of such freedom it provides. But isn’t that the same with any language? There is a story about the code behind the terminal interface for Tops-10 for the PDO-10. It had been tweaked over the years…
I wish you could use Genera. If you like emacs/slime. You would see how much we lost :(
I can relate. I read Graham's book on Common Lisp more than 20 years ago and was entranced. But opportunities to use it in the day job are few and far between, and I would have qualms about recommending it, in most contexts. For a lot of purposes, its libraries are just nowhere near as good as Python or JavaScript or Java. And some of its superpowers (macros!) can also be used really, really badly. There was an essay…
I write Go for a living. I run Emacs. I read the first part of the article, thinking about how Lisp used in a personal project makes so much sense because you can build the meta-language to your liking and not make something so weird you confuse your coworkers -- and then I got to the section on Go and I thought wow! This guy really doesn't get it! >On average, most shops have average people Yes, hello, that's me! I…
I don't think a person needs to be a genius to do well in Lisp. As a long-time C and Fortran and Python programmer (and many other languages) it took a long time for me to adjust to the different way of thinking necessitated by Lisp.
Also if Copilot or LLM write Go code, why do we think it can't write Lisp code?
I've dealt with code in many languages that were written by "geniuses" and find that they can be as hard to understand as any Lisp program. Often this depends on the problem being solved. There is a story about Donald Knuth and Edsger Dysktra working on a problem that required no less than four stacks to process. (If memory serves correctly, they found a solution using iteration rather than stacks that was much clearer to understand.)
The solution of Sudoku by Peter Norvig (https://norvig.com/sudoku.html) is a bit of a genius solution but it is written in Python.
It would be a disservice if the article's distinction of smart vs average were to dissuade anyone from learning a new language.
Having programmed professionally in 36 languages, I must agree with this. I am having so much fun with Lisp, that I am not likely to go back. > Often developers say how you can make a mess of a Common Lisp codebase because of such freedom it provides. But isn’t that the same with any language? There is a story about the code behind the terminal interface for Tops-10 for the PDO-10. It had been tweaked over the years…
I wish you could use Genera. If you like emacs/slime. You would see how much we lost :(
A PG article about "doing what you love" was recently shared and discussed on HN [1], and I think a lot of the same logic applies. The nature of a job is that someone is paying you to do what they want you to do. If we're talking about what makes you happy in your free time, then sure, learn any obscure language that appeals to you. If you find something cool that you can do in CL and nowhere else, that's an amazing…
I didn't give any career advice at all. Why did you think this was it? My career advice would be to keep developing in whatever established and practical language you are using and get paid to use if that's what you want.
Having programmed professionally in 36 languages, I must agree with this. I am having so much fun with Lisp, that I am not likely to go back. > Often developers say how you can make a mess of a Common Lisp codebase because of such freedom it provides. But isn’t that the same with any language? There is a story about the code behind the terminal interface for Tops-10 for the PDO-10. It had been tweaked over the years…
If you’re working on a project (on its code), then you can (obviously) see its code as well.
Statically typed languages make exploring the code a lot easier, especially with an IDE which leverages the type information to assist in code exploration.
> The second thing is if there is an error, it displays the stack with the ability to see what the local variables are in any function on the stack.
This works with debuggers (and is easy with an IDE) in most popular languages.
> The third thing is that one can patch a running program, either once a breakpoint ('break) is encountered, or by doing control-C at the repl. And then resume it.
You can do this with most major languages today as well.
Earlier quoted context omitted.
The OO patterns are still quite popular in enterprise software, where people mostly work in large teams. Hiding implementation details is terribly annoying for a single developer, but can be a great way to reduce complexity for other team members. The same consideration applies to other powerful constructs, such as static typing, garbage collection, operator overloading, and macros. Whether you work alone or in a tea…
There’s nothing stopping you from hiding implementation details in a functional paradigm, no need for objects or other OO patterns.
When you completely separate routines from the data, you end up coupling the code that calls the routine with the data it’s passing. I don’t see how it would be possible to maintain that level of separation while achieving the same level of isolation that’s possible with objects, where it’s possible to truly know nothing about the data in a given interaction.
I’m referring here to the purest aspect, in terms of pure functions. At some point, the data has to come from an impure source, and honestly, I don’t see why a closure would be better than an object—practically, they’re the same thing.