> Pick a language that most programmers consider weird but whose median user is smart
I think this heuristic fails, with my poster-child counter-example being Nock and Hoon, the languages used to implement Urbit. Those languages are unquestionably weird, and I think their median user is pretty smart -- you have to be pretty smart to use those languages because they are intentionally designed to be difficult to use. But I don't see any merit whatsoever in Nock and Hoon, at least not with respect to giving you any leverage in programming. C++ is another example. It's not considered weird, but I think it would be if it were not so widely used. Again, to use C++ you have to be smart because you have to know the locations of a zillion and one hidden land mines. But the appeal of these languages is not the leverage they give you, it's the barrier to entry. Once you invest the time to learn them you become a member of an exclusive club. In the case of C++ at least, being a member of the club gives you leverage and opens up employment opportunities. But that doesn't make C++ a good language.
Putting aside the other controversial things that Graham says in this post, I think we could find common ground and have some fun technical discussion by focusing on this angle:
> What can you say in this language that would be impossibly inconvenient to say in others?
The first experience that comes to mind for me was XSLT. Early on in my technical writing career, I needed to convert the Doxygen output of a C library to a more barebones HTML output (so that the reference docs would have the same branding as the rest of our site). I used XSLT to extract only the bits of HTML that I needed and I transformed them into nice, straightforward, semantic HTML. It took me a while to wrap my head around XSLT's flow but I was amazed to find that a task that would have taken probably 50-100 lines of looping and condition checking could be accomplished in literally 1-3 lines of XSLT.
Would love to hear other's experiences along these lines (i.e. concrete examples).
Yes lots of programming consists of gluing together libraries, but in my experience languages vary dramatically at how well they do even this.
For example, consider logging libraries. It's useful to have statements like log.debug(someSlowFunction()) in your code. In LISPs it's really easy to create a (debug) macro that generates empty code when you don't want debug logging turned on. In other languages, you have to wrap the arguments in a function to avoid extra runtime costs, and even then you can't avoid the "if debug" conditional at runtime. All those anonymous function wraps add clutter, and that clutter accumulates. There are many other cases where having advanced language features greatly helps gluing together libraries.
Another aspect is the tooling. When I am considering a new library, I like to try it out in the REPL. In Clojure I can quickly start calling library functions, and use the (time) macro to get a sense of how long they take to evaluate. Not all popular languages are amenable to this kind of REPL-driven experimentation with libraries.
Not only does the language impact how you use libraries, but it also impacts what libraries may exist. Some libraries are simply not possible to write in less powerful programming languages. In LISP this would include any library that uses a macro. For example, Clojure was able to introduce core.async as a library, providing an async facility similar to what golang offers. But in most languages you wouldn't be able to implement that as a library.
Another major example is reagent vs. react. The concise hiccup representation supported by Reagent is only possible because of design decisions that went into Clojure. JavaScript users are stuck with JSX, which is less concise, and in my opinion far less good.
Another issue that arises when using libraries is whether or not the language has a static type system. Without getting into the age-old flamewar about static vs dynamic typing, I'll just note that popular languages differ in this dimension, and this has a big impact on what it's like to glue together libraries.
So overall, I think this essay undersells the benefits of LISP. Even if you spend all day gluing together libraries, LISP makes that much better by improving how you can call libraries, how you can quickly experiment with them, and even what kinds of libraries can exist.
> 99.5% of programming consists of gluing together calls to library functions.
A common complaint at Google was "all I do is copy one protobuf to another". And I think that sums up programming -- that really is all we think we do. For example, a triple-A game just reads a stream of keyboard events, mouse events, and network packets, and emits streams of video frames, sound samples, and network packets. The rest is just details!
That is obviously not true, of course. We find the interfacing the most tedious, annoying, and painful part and overestimate how much time we spend doing it. Interfacing with anything is painful -- I had the idea for this comment in an instant, but I'm spending 5 minutes thinking of words and sentences, figuring out what order they should be in, and commanding my fingers to press keys on my keyboard to get it to you. But it would be incorrect to say that "99.5% of human cognition is convincing your fingers to press keys", even if that's a strict blocker to disseminating your idea on the Internet.
What that means is that tools can help us eliminate the tedious parts. The fact that tedious parts haven't gone away just means that there is more work to do. When the tools start doing what we need, you'll stop seeing the complaint that all programming is is moving data from one library to another. You'll start seeing the complaint "all I do is stare at the screen figuring out what to build."
> 99.5% of programming consists of gluing together calls to library functions.
First, my own career was not as pathologically skewed as this. I did mostly glued together calls to library functions, but I have done a fair share of algorithmic work, such as parsing and image processing. (And cryptography, though that was mostly done on my free time so Iām not sure that counts). Maybe web dev is like that, but I didnāt do web dev.
Second, this is a huge problem. This means that very few of us actually know how to program. And the problem feeds on itself: if one doesnāt know how to program, it will be easier, more tempting, to take on some significant dependency instead of just implementing the part you need, while tailoring it to your use case. Eventually knowledge is lost.
But a meta-smart engineer that wants to maximise real world impact through a software project would realise that not all āsmartā people agree about what smart āISā.
So for engineering efforts that require large amounts of people to contribute, a more restrictive, less flexible language can yield better overall productivity by expanding the pool of potential contributors and reducing friction arising from pointless differences and āsmartā programming (like macros).
In other words, removing āsmartā programming features like macros probably turns out to be (weirdly) smart in the real world.
I don't have a background on theory of programming languages or history of CS (I'm EE), correct me if I'm wrong but:
1- I have never seen a language that made me wow. Like, to me, this whole concept of making a digital logic architecture do a task should be "solved" in a systematic/mathematical sense. Yet, whenever I read on criticisms of languages, people always talk about stuff like "Go doesn't have generators", "Rust macro is a mistake", "I don't like python's async story", "C's way of things is outdated" etc...
As an analogy, this whole discussion of PLs in CS circles is like complaining about whether we should use `dot` notation or `d/d(t)` notation or whether we should use `t` or `x` in solving a differential equation. Like, we are not solving the actual DE, but complaining about issues irrelevant to the big picture.
2- I have a feeling that https://www.red-lang.org/ is something completely new and innovative.
3- I think concepts like formal-proofs and RTOSes are under-rated.
> A concrete example: Lisp macros.
Who didn't see this coming?
For someone who's constantly extolling the importance of other languages and flexible thinking, Paul doesn't seem to ever be able to get his mind out of Lisp.
> [Lisp macros] by their nature would be hard to implement properly in a language without turning it into a dialect of Lisp.
There are numerous counter examples to this claim, the most obvious one being Rust.
How do you call someone who only knows one language and refuses to learn new ones? Oh right, a blub programmer.
The problem I had is I learned a bit of LISP - just the basics and then thought āhey this is super powerful - I bet it can elegantly solve some great problemsā but then I was stuck! I had no idea what sorts of problems or how to go about it. I guess Iād need to see some motivating examples. The tutorial had a very cool test framework in like 5 or 6 lines of macros so I got a feel for the power but Iād need to see more.
My fear with lisp is that if you use macros it can become obscure what is really going on. Even in C# when Iāve seen metaprogramming done it can kill the discoverability of an app, meaning you have to talk to people who have talked to the person who left the company who knows the mental model. Searching code for keywords no longer helps, or you read the entire codebase to figure out how it works. It was a relief to get off that and work with more familiar CRUD like code. If someone writes a macro, they should write a manual!
i had the following thought the other day, interesting if it has any validity:
The availability of programmers who are proficient in a programming language is the single most important factor in programming language adoption. I think the continued popularity of C++ and Java has much to do with the fact; an enterprise wants to treat programmers as interchangeable screws, and a less widespread programming language would make this practice much more difficult. C++ was designed to be easier to learn by means of backward compatibility with C; This decision was good for programming language adoption; it was a good trade off, even at the expense of being a source of many issues with the language.
Interesting implication: I think that an enterprise with a less common programming language (like Scala or Rust), would have to treat its programmers much better than a competing shop that is using a commonly used platform like Java or C++; they have a greater investment in their workforce, due to the language/platform issue, are probably more likely to raise salaries every now and then and would be less likely to 'hire and fire'...
So adopting a less common programming language might have some non trivial implications on the culture and governance of an enterprise.
On the other hand there would be a lot of pressure to switch back to a more common programming language, in the event that the shop needs to grow significantly, these shops would then be inclined to port their systems back to a more common language...
Ah, this reminds me of the days I spent writing RPL programs for solving electric circuits on my trusty old HP48 calculator. (It is said but nowhere officially confirmed that RPL stands for "reverse-polish lisp".) It was quite enjoyable _then_ and for _that_ purpose (programs designed to run in a specific UI environment) but today I wouldn't even consider starting a "serious" project in a postfix language. EDIT: https://factorcode.org/ is a modern postfix language.
Using weird languages DOES have one merit though: it opens your horizons. It teaches you to see a "conventional" programming language as a collection of mechanisms at your disposal instead of something "intended to be used to do X".
More to the point, I think that there are two types of languages: 1) those that encourage top-down design (that's how I learned programming with Pascal) and 2) those that encourage bottom-up design (such as RPL, these have often an interactive REPL.)
So actively using something like RPL or ML or Scheme (yeah, I've read ca 2/3 rds of SICP) allows you to turn C# "inside out", to apply bottom-up programming techniques. You don't create a class because "some OO principles tell you to do so" or because it came as godsend from some "architect", but because you understand workings of classes and a class is the right tool for the task at hand.
Also, there's no programming in the large without some mechanisms to control accessibility.
> Nor is this all you can do with macros; it's just one region in a space of program-manipulating techniques that even now is far from fully explored.
I like macros. I find myself, not infrequently, thinking about where they would be convenient despite using a language without them.
Nevertheless none of the languages that include them (that Iām aware of) seem very appealing.
Part of this is āprogram-manipulating techniquesā. Less powerful languages are easier for programs to reason statically about, and so usually have great editor refactoring / navigation / static analysis already available. This makes the 99.5% of programming that is mundane more pleasant, and itās hard to imagine special programs that donāt involve at least a good chunk of this.
The alternative to macros is not never doing metaprogramming, you can do code generation, parse and process the AST, or have program behavior be data-directed at runtime up to including an embedded interpreter. These things are surely less convenient than macros, but itās a trade off against making all the other parts of the program less convenient to write.
Another issue is most languages with macros are Lisp/Scheme types, and having linked-lists-of-boxed-objects be the default representation for everything often isnāt great for domains that are performance-sensitive (this probably wouldnāt apply to some languages like Nim).
Of course there are the other downsides of using uncommon languages, like often less mature runtimes / library ecosystems.
It seems technically feasible for a language with macros to address all these issues (and maybe Rust does if youāre willing to give up GC). If I was writing a new language I would probably start by compiling to either the JVM/.NET/Go to get a runtime and libraries, and focus on the problem of incremental language extension while maintaining good editor and static analysis support (I think there are some promising approaches for that but this comment is already pretty long).
> 99.5% of programming consists of gluing together calls to library functions. All popular languages are equally good at this.
This seems to be true in the same way that "99.5% of cooking consists of making food hot. All popular kitchen appliances are equally good at this." is "true".
Technically you can fry bacon in a pressure cooker, but you shouldn't because we have frying pans.
> 99.5% of programming consists of gluing together calls to library functions. All popular languages are equally good at this.
I'm not sure this is so true. I've glued stuff together in a bunch of languages, and some are easier than others. Particularly in how the package manager works. I'd say c++ throws the weirdest integration issues out of the ones I've used. Rust seems pleasant, nothing too odd thus far for me. Python, super easy so long as you got Anaconda for all the math stuff. JS/npm maybe too easy. Swift/Cocoapods smooth sailing.
But also the languages themselves can make it easier or harder to glue stuff together. If you need to play with pointers and allocators, there's more work to do.
> Weird languages aren't weird by accident. Not the good ones, at least.
No true Scotsman? I'm sure once a language gets more than the initial attention, it can end up a strange mess, just like anything that has a bunch of people tugging at it.
> So if you want to expand your concept of what programming can be, one way to do it is by learning weird languages. Pick a language that most programmers consider weird but whose median user is smart, and then focus on the differences between this language and the intersection of popular languages.
I think this is selection at work. Yes, I do consider some coders better than others. But often it's because the kind of person who is good at coding is often the kind who gets to the bottom of things, and part of that is cave diving in weird languages. Probably I rate people higher as coders just from telling me they know Haskell or Lisp, which I perhaps shouldn't (?). But it does appear to me like some of the sharper coders I've met have for some reason been down the Haskell cave, perhaps investigating something to do with the type system.
āPick a language that most programmers consider weird but whose median user is smart, and then focus on the differences between this language and the intersection of popular languages.ā
Any suggestions on which languages could fit this criteria?
I disagree with this at a very fundamental level. I'm not sure how to express my disagreement.
I'll pick a seemingly random point:
> Pick a language that most programmers consider weird but whose median user is smart, and then focus on the differences between this language and the intersection of popular languages.
This heuristic used to apply to Python, but it no longer does. (Partly thanks to the the "Python Paradox" essay I suppose; most people now think learning Python will give you a nice career path).
All this heuristic says is that this language has some novelty that attracts people who are interested in novelty. People who are interested in novelty in the field of computers tend to be smart people, but they are not reprsentative of the "population of smart people working with computers"; they are just a small slice of it.
I might even go so far as to say, it's a slice of people who are just interested in things but not particularly interested in making finished products.
Most of the people who work with or on various linux distributions also fall in this category: they are smart, but they are not interested in building a solid working desktop environment as much as they are interested in just playing around with things for fun.
For them, their subject of interest is like a puzzle game that they spend their time exploring. There's no specific end goal. No specific product to be built. Nothin to be delivered to end users.
That's also the appeal of weird languages: the novelty itself.
This might be a matter of definitions, but to me a good language is one that allows you to deliver a solid reliable end product.
Maybe something you write in 5 lines of lisp will take 30 lines in Go. But this is not an issue at all.
The mental energy it takes to write the 30 lines of Go is probably lower than the mental energy is takes to write those 5 lines of lisp.
That is the number one reason why I have tried languages like Lisp, Haskell or Smalltalk. Even Prolog.
You change your mindset in different ways in each of them. When you come back to your usual tool you expanded your thinking to what you could not conceive previously.
Is there an "academic" subculture of, say, wood- or metalworking that derides craftspeople and engineers as "just glueing stuff together" or is this unique to programming?
Scala is a good example of a weird programming language with smart users. The book Hands on Scala Programming is a great way to learn how to express code and think in new ways.
Paul Graham also talks about the power of different programming languages in Beating the Averages, see The Blub Paradox: http://www.paulgraham.com/avg.html
Powerful / weird languages usually aren't the productivity hack you'd hope. A few team members might be more productive with a weird language, but other folks will have trouble understanding their code, so they'll be less productive.
Weird programming languages also require different types of library support (programmers that are passionate about immutability can't use a JSON library that mutates stuff). So they'll build a separate JSON library, but that fractures communities.
It's great to learn about different languages, but programmers seem susceptible to the allure of extra productivity from weird languages and that's not what I've seen.
...and, then, there are the languages that we need to use, in order to accomplish our tasks.
Most engineers (as opposed to coders) are fairly results-oriented. We may have our differences about how to get the results, or even, what the desired results are; but we always have a deliverable in sight.
It's all about getting satisfactorily-functioning software into the hands of end-users. Put a bow on it. Stick a fork in it. It's done.
Speaking for myself, I write native Apple code (iOS/iPadOS, MacOS, WatchOS, and TVOS). I need to use Swift. I could use ObjC, but Swift is really where it's at, unless I'm doing really low-level stuff. Others may use JavaScript, or even C#, to write Apple software; using hybrid systems.
It is, indeed, mostly "gluing together calls to library functions," but there's a bit of algorithm, mixed in there, as well (not much. Many library functions provide better algorithm support than hand-rolled).
Other platforms have their most effective languages.
I probably could write Apple apps in FORTRAN. I think that there are FORTRAN compilers for Apple systems. I can use existing C or C++ code, to provide "business logic" (I used to run a shop that did just that), so I guess there's a lot of languages that I could use in the backend, and, maybe, some might be better choices, for certain tasks. Again, it needs to be results-driven. If a certain kind of algorithm is most effectively implemented in Lisp, wrapped in system calls, I could embed that in a Swift wrapper.
There's also something to be said for becoming a "native speaker" of a language. That means using it fairly exclusively, over and over again. Step and repeat. I have been writing Swift, almost daily, since the day it was announced, and I still discover new things, almost every day. I think that's pretty cool.
This is stuff that I would never have discovered on a "context switch." I've usually been fairly good at picking up new languages, but I am happy to be sticking with this one, for a while. In the past, I've had to know Pascal, Object Pascal, 68K Assembly, C, C++ (and simplified variants, thereof), and Objective-C, in order to program for Apple (yeah, I've been at it a while).
> [Lisp macros] by their nature would be hard to implement properly in a language without turning it into a dialect of Lisp.
Camlp4, Template Haskell, and Rust procedural macros all serve as counterexamples to this claim.
> And macros are definitely evidence of techniques that go beyond glue programming. For example, solving problems by first writing a language for problems of that type, and then writing your specific application in it.
Is this fundamentally different from "writing your own library to solve a problem, and then using it"?
> So if you want to expand your concept of what programming can be, one way to do it is by learning weird languages.
Isn't the conclusion here "contribute to/write your own libraries" rather than "pick a weird language"? Or "solve problems from scratch instead of relying on libraries when learning"? I feel like the "weird languages" are shoehorned into a discussion about glue programming vs library programming.
In my experience of programming so far, the 0.5% thing is signal in 2 basic directions.
It is either that the problem is really hard and so most popular languages haven't attempted a solution and just make do with what they have.
Or, the problem just isn't that interesting. Like, the solution is cool, but applies very rarely and even then doesn't matter all that much. Popular languages could easily implement it, but choose not to.
I use ML-family languages for most of my work and I simply canāt express my code in mainstream languages in a reasonable way. I could solve the same problems in a different way, but it would be a lot more code and a lot less robust. People I talk to who donāt use these languages arenāt convinced by this claim; they seem to think Iāve joined a cult! Have I? Itās difficult to judge from the inside looking in.
> 99.5% of programming
Pulling numbers out of thin air like this to support an argument is counterproductive. This should read āMost of programmingā, unless thereās research that can corroborate the number.
It's worse than just stringing together library calls: Life seems to be 98% just CRUD apps. What new thoughts do I need for that, and who even has the time? An analogy: There seem to be a lot of smart Russian writers, and there's no question it's a weird language, at least to an English speaker (the alphabet! cases/declensions! idioms!) and furthermore I don't even doubt that I would think new things or in new ways if I learned it. And yet here I am using good old English, because of its popularity and (mostly) because I already know it and I can use it to get stuff done.
I don't want to knock Lisp, or any other exotic language choices. They have their benefits, people have built successful things with them, and learning a different way of doing things can expand your thinking as a developer.
On the other hand, most of the world's most complex systems are built in boring choices like C, C++, Java, or Python. The claim that this or that can only have been built or get to market fast enough if it's in Lisp doesn't pass the smell test for me.
I donāt really see anything new in this essay. I read Beating the Averages a while back and it was pretty eye opening to me at the time. If this post struck you, itās probably worth reading that essay, since it expands more on your Lisp Macros and the ideas being introduced here.
I know Fortran well and Python and R somewhat. Some "weird" languages I have thought about learning are APL and similar languages (J, K, kdb, Q) and Haskell. What else? Matlabe/Octave is widely-used but is not "weird" compared to what I know.
Things worth looking at can be weird in various ways. APL and J show interesting ways of using layout to bind together capable and compact primitives, in a way that avoids naming intermediates. Forth shows another interesting way to connect together primitives and calls, but it also shows how simple a powerful language can be to implement. Haskell shows you how the structures of higher mathematics can be directly used in programming. Clojure shows you how a language can embed the concept of time in distributed systems, and how immutability is compatible with change. Lisp shows you how a program can comprehend its own representation.
You have your programming language. Now, you design a special-purpose DSL (using macros or whatever) in which to express solutions to your problem. Now you have two languages. (apologies to Jamie Zawinski)
The issue is: Management of Complexity, not how to efficiently express complexity. This is why we have layers - layers are a kind of DSL; and this is where most complexity lies. Clear layering -- including defining the functions of each layer -- is how Complexity is tamed. (And this can be successfully done in assembly language, if you want.)
The main reason to master weird languages is: Fun.
I find synchronous languages like Esterel, CĆ©u, or Blech both weird and eye opening. I created a DSL for Swift (called Pappe) to bring some of the ideas to a more mainstream language.
> Pick a language that most programmers consider weird but whose median user is smart
This just comes across as arrogant. You can neither know how smart the median user is, nor does it say much about the merits of the tool. It encourages some weird sense of superiority by putting yourself in a group that's exclusive and think they're smarter than everyone else. There are better ways to pick programming languages than trying to maximise your own pretentiousness.
> So if you want to expand your concept of what programming can be, one way to do it is by learning weird languages.
This is surely the key line here - and the stuff about glue code and median users etc frankly just detracts from it.
It's true in any field. If you want to expand your ways of thinking look for stuff that has been reasonably successful but is outside the mainstream. Put it that way it's sort of obvious but probably easy to forget.
For the non-lisp programmer, can someone explain how the Macro differs from a library call, or other function? If you're building the language, vs building your code, is this really that different?
Having read about this, the best analogy I can think of is that macros are like engineered wood. If you're building a structure, you can build bigger ones with engineered wood, than with run of the mill (literally) stuff.
Most programmers STILL haven't experienced the absolute JOY of live coding languages.
I am extremely disappointed that the only example of a "weird language" is Lisp. These days ā with Clojure, Common Lisp, Racket, Guile, Emacs Lisp, Chez Scheme, Fennel, etc. etc. ā Lisp is hardly weird.
I'd love to see an expanded version of this article written by someone less focused on Lisp advocacy than Paul Graham seems to be.
Apart from the technical benefits of languages like Lisp, OCaml, Haskell, these days one also needs to consider social aspects before one invests too much into a single language.
In terms of influence and earning potential, parochial and closed languages like Python are kind of a pyramid scheme:
The people who were there first occupy many of the top positions in industry, regardless of their contributions or competence. They actively harm and intrigue against dissenters, so be prepared to chant the religion of the day (which the powerful change from time to time).
This sort of thing cannot happen in languages with a standard and multiple implementations like Lisp or C++. Haskell and OCaml seem to be isolated from the most petty forms of intrigue because the average contributors are way smarter and care more about actual technology.
He's made this point before, more than once I think. But never so succinctly - well done.
The only thing his less succinct essays give you is his motivation for liking Lisp and macros in particular - it allowed him to build a successful business that gave him his big break in life.
>So if you want to expand your concept of what programming can be, one way to do it is by learning weird languages. Pick a language that most programmers consider weird but whose median user is smart, and then focus on the differences between this language and the intersection of popular languages. What can you say in this language that would be impossibly inconvenient to say in others? In the process of learning how to say things you couldn't previously say, you'll probably be learning how to think things you couldn't previously think.
or write compiler and experience the freedom
Counterpoint is when you're spending cycles thinking about the weird language you're not spending cycles on creative programming, however adding chaos and restraint is a time-tested path to innovation.
Wouldn't you want a pl that makes that makes your 95% glue code easy to write, easy to code review, easy to debug in anger?
Stuff like "make this gql query, but with account spelled 'akkounte' b/c it's in language X, compute and add tax, then depending on the associated customer's SAAS, maybe stuff it into a REST call that has the account and tax as a CSV.
Or: convert this list of integers into f64, take the running average with a window of 5 entries (unless there's a holiday that week) then shove it into this C function that someone else wrote
I don't get it. Lisp has been around for like 60 years. If these macros were an objectively better way to write code, why have they not taken over by now?
"99.5% of programming consists of gluing together calls to library functions."
This is also a statement about what kind of programming the speaker has done.
I have a funny relationship with Common Lisp macros: I love the great book Let Over Lambdas, and also Paul Graham's coverage of this topic, yet, I hardly ever write macros myself.
For me, using different languages is a statement that I enjoy programming in different languages, and not a value judgement. There are so many great languages and I think some new languages like Swift and Rust are especially fun and useful.
We are moving towards a time where the entire notion of programming languages would be nothing more than compiling a proper dataset.
Programming languages will not become irrelevant but would be more akin to the fate of humanities, likely a personal passion. The economic value of learning programming languages in the distant future would be close to none.
Programmers should view languages as nothing more than a tool to perform some tasks.
languages come with environments and libraries. Some environments are easier to use than others. For me, C/C++ is always painful because there is no standard build system or package manager and certainly nothing cross platform so integrating any random library is always work.
Conversely, I guess ruby, node, python, perl? all have fairly standard package managers so it's generally? easy to grab a library and it just works, no having to learn how to integrate it into your build system, only having to learn how to use its API
I do agree there are big things to learn from different languages. I haven't actually used F# but I did learn from this article (https://fsharpforfunandprofit.com/posts/designing-for-correc...), that I'm missing out on saving myself a ton of work by not using a better language that (a) builds new types for me easily (b) lets me switch on types easily.
I'm also mixed on lisp's macros. What I'd like is a language that can use itself at compile time. I hate that nearly every large C++ project integrates other languages (make, cmake, gn, python) somewhere in the build process. With a language that can run itself at compile time like lisp the build tools themselves can also easily be in lisp. I don't thing C/C++ though is particular good at simple string manipulation so using it to build itself sounds like it wouldn't be so nice. That might be another example where some languages excel over others in certain domains.
The downside to lisp macros is everyone builds their own DSLs and so I have to learn those DSLs. Of course maybe that's just the same as learning some C++ class hierarchy I'm unfamiliar or some template magic so possibly not a valid complaint. It's just a feeling from the lisp I've worked with.
As a corollary:
āA language that doesn't affect the way you think about programming, is not worth knowing.ā - Alan Perlis
Why do people idolize this guy so much?
Languages are (just) tools.
Pick and combine and switch as you go, tweak and create new ones if the availables aren't sufficient or are inaccessible. Worshipping and mantras are dead end.
It's that simple. (btw, a house is a tool to live inside it.. there was some Peter-Gabriel-wrote-music movie around this)
have fun
For those who want to try out a quote unquote weird language, here is a cheat sheet I found helpful for Lisp: https://github.com/ashok-khanna/lisp-notes
So the Sapir-Whorf hypothesis[0] appears true for programming languages.
Russian translation: https://habr.com/ru/company/itelma/blog/575128/
If you think that 99.5% of programming consists of gluing together calls to library functions, you're also not making a statement about programming, but about the kind of programming you've done.
I new to this opinion, but I think more people should try to write non-trivial things in the Hindley-Milner family of languages. Just to get out of the rut.
Would Ada++ be considered weird xD?
99.5% of programming isn't actually about the coding at all. It is about breaking down a process to steps small enough to express in code. It is about figuring out what you want the app to do in the first place, and making it meets the goals of the end users. Or, to be more realistic, making it meet the goals that product owners have handed to you on behalf of the end users.
This whole article just feels like it is talking about code for its own sake, which I admit may be intellectually interesting, but has little to do with what we actually do day-to-day when building software.
Maybe that was really the point he was trying to get to - that building software is not the same thing as doing "interesting" code.
Or just normal languages, used oddly: http://www.ioccc.org/
I think this applies to weird people as well. Some of the most interesting conversations I've had was with people that were misfits.
Languages to a programmer are like tools to a machinist. There's always some new goofy situation that requires yet another tool.
I heard this dude once claimed that lisp could've prevented 9/11. This seems like an elaboration on that claim! Javascript is kinda Lisp already and your glue languages do have their fair share of weirdness. Every industry and everything humans do is gluing crap together. The carpenter doesn't create his own synthetic wood or dig iron ore to make his own needles. He glues crap that was dug and cut with glued stuff.
This whole article is so short and generally vague as to be useless.
Does Paul Graham know Prolog or Wolfram or SAS?
If not then... isn't it ironic?
Nim, Elixir, Rust, Zig, D and Jai would all like a word.
> 99.5% of programming consists of gluing together calls to library functions.
Actually, different languages do make this part different. Because you might glue together something other than "call", i.e. good functional languages have abstractions that blur the code and data boundary.
If all interesting ideas were at the expense of code reuse, learning new programming languages would be a fools errand. Improving the last mile of whatever you are doing is an O(1) improvement of total cost ā it doesn't even show up in productivity expressed as a rate.
The real compelling belief behind programming languages is much more exciting, namely that we can express better ideas together in reusable ways, invest that productivity into better languages and rolls, and repeat that process ad infinitum. This is a crazy railgun of a concept.
Incidentally, this is why startups as PG likes are a failed way to advance technology. Startups, focused on a limited 5 year window and that last mile, are structurally incapable of working on generalized infrastructure. The proliferation of b2b over b2c on recent years belies that, but replacing the current ossified FOSS Monopoly (our commons) with b2b bulkanization could restore competition in the means of production, but that bulkanization will also prevent the code reuse that create enough payoff to power the continued reinvestmemt.
Tl;Dr PG sees good languages as a way to do one-off great man history-style heroic inventions, I see good languages as a way to unlock factorio-style continuous high capital investment.
TL;DR - I only ever used LISP and nowadays I spend my time writing LISP dialects literally no one cares about but me.
"lisp..."
here we go again
"99.5% of programming consists of gluing together calls to library functions"
tell me you never worked on anything more interesting than a website without telling me you never worked on anything more interesting than a website
emacs, lisp, and clojure are all pointless programming languages. Emacs is so bloated it is not funny (eliza mode) Lisp ((((((())))))))))))) to write hello world is stupid. Yes I know my parens do not line up
Clojure: similar to lisp, but also requires an underlying JVM
Lmfao. This whole site is a joke.
It's 2021 and the best example this guy can come up with is Lisp macros?
Really?
Is this an opinion piece or a cry for help?
I prefer to use languages which have been stable for 20+ years.
Disappointed. I thought it was about languages such as Lojban /s
Strange that PG's site is served over port 80. Isn't he technical enough to have HTTPS on his site, surely? Anyway here's an Outline of it served over a secure channel:
This is a line that resonates with me, and the one which some negative comments might overlook (3 hours in, at least):
This is one of the value propositions of language. It's one of the ways we learn new things, and thus become more capable of doing valuable work as people.Criticisms of this essay in comments so far have seemed to fall into these buckets:
(1) and (3) are side points, unrelated to thesis. (2) is the interesting one, and at the heart of what the essay talks about.I've always been in the pg camp on this one. Sure, systems are the thing, we can't be purists, etc -- but saying that languages don't matter, for us, would be like rocket engineers saying that materials don't matter.
If you're building a table, you can make it out of almost anything; a table is a solved problem. Wood, carbon fiber, steel.
But at the limits of what's possible, like a rocket, the material's properties, limitations, and weaknesses in extreme circumstances matter.
You can definitely imagine that important things are happening, in the maker's mind, when they start working with a new material, seeing what others are able to do with it, seeing how the making process is easier, or what steps are unimportant/unnecessary now vs. in their usual materials. And that informs their thinking, going forward, about what's possible in systems they might build.