131–140 of 153 posts
Honestly, if you read the idiomatic factorial function and can't understand why no-one writes LISP I think you need a reality check. Nobody thinks natively in nested prefix notation.
I do, but I have ASS, so I basically am a space alien of the type to appreciate alien technology.
Or perhaps, just perhaps, the true higher-dimensional move is realizing that choice of programming language isn’t usually the critical factor in whether a project, system, or business succeeds or fails, and that obsessing over the One True Way is a trap. It might surprise the author to learn that there are many people who: 1) Have tried lisp and clojure 2) Liked their elegance and expressiveness 3) Have read through…
You mean another slick text editor :/
Earlier quoted context omitted.
My point was that you could implement type checking with macros, not that you could type check macros. (Though that would be cool!) As opposed to having to change the language definition first (Python) or implement an entirely new compiler (TypeScript).
Certainly you can implement the typechecker with macros, but it should also work on macros, before expansion. That is, you likely want (-> ...) typechecked as written, not (only) as expanded, and typing errors reported on the non-expanded form.
Of course you can do all of this, but you need to build it yourself: see rewrite-clj. If you want to build a clojure debugger that is able to display or refer to code with the same indentation the programmer is dealing with in his text editor, you need to bridge the gap between clojure expressiosn and their string representation.
Anyway I concur that reversible macros would be great. Tag the output, have those tags propagate to the input by playing the macro backwards. Complex stuff really. That's a job for category theory I guess.
https://cybercat.institute/2024/09/12/bidirectional-programm...
Or perhaps, just perhaps, the true higher-dimensional move is realizing that choice of programming language isn’t usually the critical factor in whether a project, system, or business succeeds or fails, and that obsessing over the One True Way is a trap. It might surprise the author to learn that there are many people who: 1) Have tried lisp and clojure 2) Liked their elegance and expressiveness 3) Have read through…
Clojure is built on dynamic typing. This is pain. I wrote enough Python (pre-mypy), Javascript, and elisp to say this. Past certain size a dynamically typed codebase becomes needlessly hard to wrangle because of that. Hence the success of Python type annotations and Typescript. Instead, the world should have seen the light of Hindley-Milner type systems, ML-inspired languages, immutability, or at least not sharing mu…
Probably not an absolute truth, but definitely a personal truth for you. For me, it's pretty much the opposite, static/fixed types is such a pain when you just wanna solve a problem and you know how to achieve it, all the invariants/constraints but the language tells you "No, you know what, this other person said you cannot use X for Y, so I'm gonna say no" instead of just letting me do that thing.
With that said, I still reach for Rust for about ~30% of new projects, despite the types, because some languages fit other problems better, simple as that. And still a lot more contracting gigs available for various Rust codebases who've fallen into disrepair, so one does what one can.
I feel like big codebases regardless of their size are hard to wrangle not because of the languages used, but because of the programmers having to rush through building proper abstractions, or even considering not adding so much abstractions. I've seen awful heavily typed codebases as much as I've seen awful dynamically types codebases or awful codebases not using explicit types anywhere, to me there seems to be no correlation between "awful" and "number of explicit types used".
Personally, I prefer a big codebase with lots of (good) unit tests in a dynamic program, than a that same big codebase with no unit tests and explicit static typing everywhere, especially when refactoring and needing to ensure everything (from a business logic perspective) works correctly. But again, this is my personal truth, and I'm not trying to claim it's universal.
Earlier quoted context omitted.
Most of the time when someone adds these fancy languages what happens is that they leave and the ones left are the ones that have to deal with the shit that was produced. I'm going through this now, having to deal with code nobody wants to touch because it is overly complex, has no documentation, and is in a language no one else knows. Now, whenever i see an effort like this, to bring an exoteric language for absolut…
> exoteric Best typo ever! Portmanteau of esoteric and exotic :-)
Earlier quoted context omitted.
On the other hand, it would be easier to add type checking to a Lisp than it was to Python or JavaScript, and I don’t know any technical reason you couldn’t. A little Googling shows it’s been experimented with several times.
Well, Typed Clojure is a thing! But the real strength of Lisp is in the macros, the metaprogramming system. And I suspect that typing most macros properly would be a bit less trivial than even typing of complex generic types, like lenses. Not typing a macro, and only typechecking the macroexpansion would formally work, but, usability-wise, could be on par with C++ template error reporting.
I think we (the Clojure community) quickly figured out we don't really want static typing, which is a bit evident by the low uptake of Typed Clojure.
Personally I found it to A) make it a hassle for downstream consumers since your design is suddenly impacting others, because you can "lock things down" and B) have that very same effect on your own codebase, where it becomes a lot less flexible where it needs to be flexible.
Nowadays, I just use another language if I want static types, which happens sometimes but not nearly as often to say that dynamically typed languages are "dead" or whatever.
Homoiconicity is overrated. Python is an acceptable lisp: higher order functions, dynamic types, generators, decorators. If you really need syntactic transformation you can use the ast module.
True lisp adherents view lack of differentiating syntax as an unalloyed good, but that cuts against the grain of how humans have communicated with each other for millennia.
You'd think the current crop of people who grew up texting each other without syntax might be a better fit for it, but then you run smack dab into the fact that the minimal required syntax is, in fact, actually required, and very important, to boot.
Consider e.g. the "with" statement in Python[1]. Someone came up with the idea, found a way to integrate it into python and a year later, people could use it. In Lisp, you write a macro.
Now Python is a rather agile language as these things go. In other languages it would be a lot more than a year. When I was in college, my professor wanted us to use generics, but the school mandated language, Java, lacked generics at the time. So we were told to use a fork of javac that had generics added. Pretty much none of the development tools would play nicely with this, and javac was at least two orders of magnitude slower at compiling than my preferred java compiler at the time (jikes).
None of this is world-ending, but it really is annoying. The argument for macros is just "what is the next generics/with/whatever feature that your language is missing." Most of the features that lisp programmers use macros for have made it into modern languages that continue to evolve, so the leverage narrows. In the late '90s it was probably a much bigger multiplier than today.
Earlier quoted context omitted.
Why are we limiting ourselves to business concepts?
Not GP, but … because the overwhelming majority of programming is done in support of businesses selling things? I’m not just talking about people who program for a living. The majority of academic CS chooses its research directions because of what limits people are running into for business; even privacy-focused software has been commoditized by many business; a large amount of OSS development is by (and often paid f…
But look at historical languages and why they were created:
Algol - to explore writing algorithms
Fortran - to help scientists write programs using typical math formulas
Matlab - to help write programs in linear algebra
Haskell - to explore lazy program evaluation
ML - to explore how to reason about proof automatically
C - to build an OS
Python - to interface with an OS
LISP - to formalize symbol processing
APL - to explore programs defined over arrays
LOGO - to help young kids to program computers
Prolog - to create a language around the idea of formal logic.
Smalltalk - to create an entire programming system, not just a language
(I've left out C++, Java, and JavaScript because I feel like those languages are mostly about serving business interests)
Pretty much the entire computing landscape over the past 50-70 years has been defined by people writing languages for reasons other than "this is for a business to use to make more money". So if we let business-driven interest dictate the future direction, we will have missed out on all the things that could have been. Would Haskell ever have been invented if businesses interests were the only concern for researchers?
Big lisp guy here. Have written tens of thousands of lines of scheme, at least, and common lisp. But I don't get this "Lisp is so much better than everything else," thing. It feels very jejune to me. Most lisp programmers barely use macros and most programming languages these days have most of the features of Lisp that originally made it useful (automatic memory management, repls, dynamic typing*, and even meta-progr…
> If I had one thing I want fixed about Scheme it would be the dynamic typing The ML family or Haskell fit that bill. Both OCaml and Haskell also have an equivalent of macro systems. So does e.g. Rust, for that matter. I agree with your main point. The attitude you’re referring to is largely a relic of a previous era, at this point.