30 ms·

Weird Languages

• cpach 5y ago
  “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?
  • firloop 5y ago
    Zig is one that’s been on my list for Paul's stated reason.
    • deleted 5y ago
      [deleted]
    • meheleventyone 5y ago
      Is Zig weird though? I find it eminently pragmatic and a lot of the interest in it comes from people migrating from popular languages like C and C++ (not that C++ isn't itself pretty weird).
      • nlitened 5y ago
        From what I’ve seen, Zig has no built-in polymorphism features (no vtables/interfaces/traits), which is _pretty_ weird for a modern language in a good way.
        • ncmncm 5y ago
          That is just because it is new. If it survives it will end up with everything.
          • judofyr 5y ago
            “Adding everything” is definitely not a part of Zig’s philosophy. https://github.com/ziglang/zig/issues/130#issuecomment-706011442 https://github.com/ziglang/zig/issues/130#issuecomment-70601... > However, at this point the plan is to not add an additional dynamic dispatch language feature.
            • ncmncm 5y ago
              Key phrase: "at this point".
          • alserio 5y ago
            Isn't that forecasting a trend with too few data points? The field is still young and changing.
            • nlitened 5y ago
              Oh, I don’t think it is a trend. I rather see it as a curious phenomenon that makes one reflect on the trade offs we usually make when using polymorphism, and whether it’s worth all the time, not only in terms of performance, but also in terms of program architecture.
              • alserio 5y ago
                Interesting. What are the program architecture tradeoffs you are suggesting?
                • nlitened 5y ago
                  To be honest, I have zero experience programming with Zig. But I imagine programming with Zig would lead to more literal style and fewer, simpler abstractions (no IoC, no frameworks). That might be beneficial for certain kinds of focused-scope projects.
                  • alserio 5y ago
                    I see. They say you can solve every problem with an other indirection, and ad hoc polymorphism is an instance of that. But there are other ways to enable composition that are seldom reached for when your language makes that easy
                    • ncmncm 5y ago
                      Every problem, except those caused by too many indirections. Each solution uses only a few language features. Different problems call for different subsets. Not using a feature on your favorite sort of problem says nothing about its value. "Ways to enable composition" poorly supported are reached for less. Poorly supporting one of them that has proven frequently useful does not improve a language.
          • sullyj3 5y ago
            It has compile time programming designed to subsume those features. So eg a generic struct becomes instead a compile time function that takes a type and returns a struct
            • ncmncm 5y ago
              That is a wholly other set of language features, for a different purpose, and is thus no substitute. Practical languages accumulate features to better address a multitude of common real-world problems. Toy languages don't. Sometimes a toy language is adopted and grown to practicality. People always complain about that.
      • judofyr 5y ago
        Zig uses explicit allocations everywhere (if you want to allocate something you need a reference to an allocator) which is pretty unique even for low-level languages (e.g. C, Rust)
    • joppy 5y ago
      Zig is certainly not weird in the way that something like prolog or scheme are.
  • jhbadger 5y ago
    Besides Lisp, languages like Haskell and F# would probably fit. As would Forth and modern stack languages like Factor.
  • OliverM 5y ago
    The APL/J/BQN family of array languages, or Prolog & other Horn clause languages. Both will change your idea of what’s expressible in a programming language.
    • account-5 5y ago
      I'm not a programmer/developer by trade but I do like writing scripts to make my job easier. I'm looking into APL and Lisp type languages basically to expand my mind as up to now I've really only being using "traditional" type languages. It's like starting from scratch again.
      • mst 5y ago
        That's true for everybody, I think. I find "thinking in lisp, then writing the program out in X" where X is whatever 'mundane' language seems most suitable to the task is often a very effective technique. Array languages I've tried to learn repeatedly over the years and always ended up bouncing off, so have no opinion there except "personal aha moment not yet reached".
  • xendo 5y ago
    Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell which are covered in "Seven Languages in Seven Weeks" are quite nice for start.
    • csmpltn 5y ago
      > "Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell" Do they offer any meaningful differences to an otherwise "mainstream" language - anything beyond syntax, tooling ecosystem and the usual functional vs. procedural vs. OOP paradigms? Anything I can't just whip up in modern C#, C++, Java or Python if I wanted to constrain myself to a specific subset of features or a specific paradigm? I get the "it's fun to try something new every once in a while" part but people tend to forget that the distinctions between programming languages have blurred significantly over the last 10+ years.
      • anonymoushn 5y ago
        Haskell's laziness gets you all sorts of control flow that is awkward in or missing from most languages. So I think it's worth checking out.
      • yesenadam 5y ago
        Well, Prolog for one seems very different. In functional/procedural/OOP you have to write a program describing every step of the way. In Prolog you just have to describe the destination.
      • yakshaving_jgt 5y ago
        Yes, there are plenty of meaningful differences. It's true most mainstream languages in industry are essentially syntax swaps of each other, but Prolog and Haskell are not that at all.
      • wues 5y ago
        In the case of Erlang the answer to your question about meaningful differences is: oh yes! I could list more, but there are two: - support for concurrency. After tasting it you never will want to go back to techniques normally used in the languages you listed - data immutability, which makes reading code so much easier.
  • xendo 5y ago
    TLA+, AWK, jq are also interesting choices.
  • saagarjha 5y ago
    For 'pg it's just an excuse to talk about Lisp.
  • koolba 5y ago
    The max I’ve seen in both categories is Brainfuck: https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck
  • amelius 5y ago
    Any highly experimental language that is used only by a small group of programming language experts would fit the bill!
    • cpach 5y ago
      Sure! Just curious about what specific languages would fit this description.
  • ellis0n 5y ago
    Check ACPUL 1.0 pure programming language for mobiles. ACPUL have 99.5% common features. No keywords, only 2 statements (if/while), no strings in code but bulitin i18n. Here is EBNF grammar https://github.com/d08ble/acpu/blob/master/acpul-EBNF-cocor/acpul.atg https://github.com/d08ble/acpu/blob/master/acpul-EBNF-cocor/... Here is demo project https://github.com/web3cryptowallet/Web3CryptoWallet https://github.com/web3cryptowallet/Web3CryptoWallet But powerful like LISP and I am building mobile OS, IDE and nocode environment with ACPUL https://twitter.com/acpustudio https://twitter.com/acpustudio
  • philipswood 5y ago
    I'd add Smalltalk to the other odd list suggestions given.
  • mikewarot 5y ago
    Metamine - it seems to have been pulled from the internet by its creator, after having given some really cool demos. What's weird: it allows a mix of declarative and imperative syntax in a style that seems like normal procedural programming. You have a "magical equals" that is actually reactive programming... if any of the terms change, ever, the result gets updated. Here's a previous thread about it https://news.ycombinator.com/item?id=27555940 https://news.ycombinator.com/item?id=27555940
  • ThrowawayR2 5y ago
    Assembly language for ARM or RISC-V. It will provide a better appreciation for what's going on under the hood. You'll also see which high level languages fit (or don't fit) this underlying fundamental model which may help cut through the marketing fluff from their various proponents and provide an unpleasant appreciation of the performance costs of popular programming paradigms.
• jstx1 5y ago
  > 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.
  • cpach 5y ago
    Yeah that sentence felt quite weird. I’m not sure I would say that “smart” is a rigorously defined term.
  • ncmncm 5y ago
    Agreed, it is self-congratulatory. Paul Graham essays decline in value exponentially with the number of times he mentions Lisp in them. He had one that went below 2^-20.
    • gotts 5y ago
      Why do you think Paul Graham essays decline in value exponentially with the number of times he mentions Lisp in them?
      • andybak 5y ago
        Eliza. Is that you?
        • bqmjjx0kac 5y ago
          Do you feel like it is?
    • pontus 5y ago
      I think a similar thing can be said about time. There were a lot of novel things to share in the early days, but these days it seems like his essays have taken a turn toward trite elitism. To be clear, I don't think this is specific to PG, but rather the case whenever someone feels the urge to continue producing for the sake of producing, nor am I saying that I'd be able to do any better. PG obviously has orders of magnitude more wisdom to share than me or most other people.
• aserafini 5y ago
  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.
  • jstx1 5y ago
    Go is one of my favorite languages exactly for the reason you describe - it focuses on getting things done and it scales to collaborating with many people. At the same time I enjoy tinkering with different new languages every once in a while and I think that's what the article talks about. There's a place for experimenting and trying out new things, that doesn't mean that you need to rewrite everything in Haskell.
    • kaba0 5y ago
      But not having enough abstraction is also problematic and Go does cross that line for me at least. Eg. on my current CRUD app, we use Spring’s aspects to implement some permission checking before specific HTTP requests. The alternative - copying a function call to each place - would be much more bug prone, a change in one will not be propagated, etc. While it may not be the best example, there are many similar cases where I feel that less abstraction would just make it unmaintainable.
      • pphysch 5y ago
        No need to embed function calls everywhere. The integration of authorization middleware should only be as complicated as your routing: mux.Handle("/", middlewareOne(middlewareTwo(finalHandler))) https://www.alexedwards.net/blog/making-and-using-middleware https://www.alexedwards.net/blog/making-and-using-middleware
  • 5y ago
• loup-vaillant 5y ago
  > 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.
  • Const-me 5y ago
    > Eventually knowledge is lost There're thousands teams all over the world working on various projects which require people to program. At the very least, someone needs to write and maintain these libraries. Also there're interesting domains like game development, CAD/CAM/CAE, HPC, embedded. Knowledge is transferred within such teams.
  • TchoBeer 5y ago
    Why would it be better for tens of tthousands of people to rewrite the same bit of code over and over again, ? This amount of code reuse sounds excellent to me.
    • loup-vaillant 5y ago
      Because then they would learn to write that code. Because it’s not the same exact bit of code, but just a part, or a different version depending on the exact context. Because taking on a dependency is just as costly as rewriting the thing, if not more… Code reuse is good, but we should not forget that its costs are not nil.
• ducktective 5y ago
  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/ https://www.red-lang.org/ is something completely new and innovative. 3- I think concepts like formal-proofs and RTOSes are under-rated.
  • jstx1 5y ago
    > 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 Until you start manipulating the 'dt's on their own which wouldn't occur to you if you were using the dot notation. (And then some people tell you that it's illegal, or maybe okay but only if you've taken real analysis... it gets confusing)
  • EamonnMR 5y ago
    This is one that blew my mind back in the day, compare these two quicksort implementations: https://rosettacode.org/wiki/Sorting_algorithms/Quicksort#C https://rosettacode.org/wiki/Sorting_algorithms/Quicksort#C https://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Haskell https://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Ha...
    • akho 5y ago
      The C code implement quicksort, the Haskell code does not. It has different (worse) space characteristics. Proper quicksort in Haskell is not a two-liner.
• forgotmypw17 5y ago
  I prefer to use languages which have been stable for 20+ years.
  • namaria 5y ago
    Such as Lisp?
  • quickthrower2 5y ago
    Common Lisp is ok then?
  • nabla9 5y ago
    Common Lisp, Prolog, APL, Fortran, C, OCaml, Ada.
    • quickthrower2 5y ago
      Java, Python, Ruby, Haskell, C++, VB, C# too!
• Zababa 5y ago
  > 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.
  • oriolid 5y ago
    > Isn't the conclusion here "contribute to/write your own libraries" If you write your own library for a popular language, you're both competing with everyone else who has written a library to do the same thing and picking fights with those who just want tell you to not reinvent the wheel.
    • Zababa 5y ago
      The article is mostly about learning. When learning, it's fine to do things people already did. I don't like the expression "reinventing the wheel". I don't know much about engineering, but I think most of our job as developers would be closer to finding a wheel for a specific case, mostly by adapting existing solutions to fit our use case, and sometimes designing a wheel form the ground up.
      • oriolid 5y ago
        In serious engineering wheels are reinvented everywhere, but somehow in software you're supposed to use existing parts that do 90% of what you need and then struggle with the remaining 10%.
  • einarfd 5y ago
    You can express things with macros that you can not with normal code. But with the advent of decorators and templates that gap has shrunk, and with C++ templates for example. It might almost be possible to do everything with templates that you can do with macros. That code might end up looking weird though.
• codingdave 5y ago
  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.
  • mdp2021 5y ago
    I think he meant that "there exist mental frameworks much more expansive for one's intellectual keyring than conditionals and loops («gluing [...] library functions») - for example «Lisp macros» -, so, «if you want to expand your concept of what programming can be» [presumably to acquire further hold of complexity, and new ways to navigate the solutions space], then explore weird languages with credentials".
  • le-mark 5y ago
    Paul Graham’s MO is using language as a startup secret weapon to outmaneuver established companies or lesser rivals (see his earlier writings about Viaweb). Spoiler they used lisp to implement multi tenant online store. He’s talking to startup founders, potential yc applicants. The reality is today, a lot of what they did in lisp is common functionality in every popular web stack out there. In my view this programming language grand standing hasn’t been compelling for a long time, and now just seems kind of silly. Unless you’re working on really interesting problems, which the vast majority aren’t, judging from recent yc classes.
    • chubot 5y ago
      Yeah it's kind of funny that there was a "controversy" in the very FIRST YC batch, when Reddit switched from Lisp to Python (~15 years ago!) And there was data that showed that like 90%+ of YC startups use either Ruby (often Rails) and Python, including all the most valuable ones like AirBNB, Stripe, Doordash, etc. So basically it's been 15 years since Ruby and Python have been acceptable (or even better) Lisps, according to PG's own metrics. Ruby and Python both have garbage collection, REPLs, and enough reflection/metaprogramming to "compress" your code.
• ChrisMarshallNY 5y ago
  ...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).
  • Abhinav2000 5y ago
    Agree with you, and Swift is also such a great language. I went from it to Lisp, sometimes I ponder about returning back (however my use case currently is for Lisp).
    • mark_l_watson 5y ago
• quickthrower2 5y ago
  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!
  • Abhinav2000 5y ago
    I think this is a very valid viewpoint. Typically its better not to learn / use macros until one is sufficiently advanced, functions will do for 99.5% of the circumstances, to call a famous author ;-) You should try it out. The book Common Lisp Recipes by Edi Weitz is really good and practical - you can get web servers up and running in minutes, and has many other practical uses (I have to check the contents again, but its about 750 pages long and covers stuff like interfacing with C and Java), highly recommended if you want to get productive in Lisp!
• lexicality 5y ago
  > 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.
• MrPowers 5y ago
  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 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.
  • yawaramin 5y ago
    > but other folks will have trouble understanding their code, so they'll be less productive. This assumes, you know, that other folks are incapable of learning anything new.
• klelatti 5y ago
  > 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.
  • toolslive 5y ago
    Yes: If you want to become good at something, practice something harder.
    • macintux 5y ago
      Except the point isn’t to practice harder, but to learn harder.
      • toolslive 5y ago
        maybe I was not making myself clear: "practice something that is more difficult" is a less ambiguous formulation.
• lordnacho 5y ago
  > 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.
• davnicwil 5y ago
  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.
• rlag 5y ago
  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.
• slim 5y ago
  Disappointed. I thought it was about languages such as Lojban /s
  • myWindoonn 5y ago
    u'i xo'o xu la pygy ku jai logji .i pe'i so'i valsi .iku'i na'e logji
• throwaway34241 5y ago
  > 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).
  • brabel 5y ago
    > Another issue is most languages with macros are Lisp/Scheme types, Rust, Julia and Zig (if you consider comptime to be a specific type of macros) don't look Lispy to me but all have macros. In Rust I would consider them essential to the language (don't know the others well enough to say), without them Rust would be terribly verbose. > having linked-lists-of-boxed-objects be the default representation for everything often isn’t great for domains that are performance-sensitive Disagree, there are extremely performant Lisps out there, including Common Lisp and Chez Scheme. They run as fast as, or faster than, any language that's not a systems-language (C, C++, Rust, Zig).
• mark_l_watson 5y ago
  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.
• syncurrent 5y ago
  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.
• nathell 5y ago
  > 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.
  • elliekelly 5y ago
    I think this is a common type of hyperbole and 99.5% of people who read it will understand it isn’t intended to be taken literally.
• germandiago 5y ago
  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.
• dnautics 5y ago
  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
• codesections 5y ago
  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.
  • brabel 5y ago
    I agree. Lisp should be considered one of the most successful languages ever invented given the number of descendants it has sprout, as you mention. It's not a weird language at all. Incredible projects like Guix, Emacs and Datomic are proof that Lisp is still alive and well and can create great things. I would give Prolog or maybe Forth as examples of weird language that still have a "smart userbase".
  • Abhinav2000 5y ago
    Ummmm sorry to burst your bubble, all those languages you mentioned are considered part of the lisp family (I'm not sure what Fennel is, so can't comment), so actually you interpreted Paul's statement incorrectly - he didn't say Common Lisp or Scheme in particular, he said Lisp so was referring to all of them. For what its worth, he's writing his own Lisps (Bel, Arc), is highly proficient in Scheme (just check out the book On Lisp), and is a true lisp polygot. I can't speak for him obviously but I don't think he has a super strong affiliation _just_ to Common Lisp.
• mr_luc 5y ago
  This is a line that resonates with me, and the one which some negative comments might overlook (3 hours in, at least): "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." 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. Lisp? Macros? Boo. (Not novel/too weird/etc) 2. Languages are solved, not important; I build systems. 3. I don't like the tone of this essay. (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.
  • jhgb 5y ago
    > Languages are solved, not important; I build systems. This argument always gets funny when sufficiently complicated systems start themselves looking like languages (and their implementations).
    • jstimpfle 5y ago
      I'm not sure it's getting funny. I find it's getting interesting. If the best mechanisms the developers could find to solve a certain problem could be implemented in a language + compiler, does this mean the project should be implemented in this language is? What does this even mean? Maybe it already is implemented in this language? Or is it not, because of the missing syntactic abstraction? The thought I have related to this is that languages are much like GUIs in this regard. They enable a certain process using some built-in features, but it's next to impossible to abstract over those feature to optimize further. And I think that is why I stay with a simple language that gives arrays, structs, and function calls - basically tools to manipulate data / memory, I'm not sure that more features are all that useful to write "well-compressed" programs (but I can imagine that it's often hard to see why certain useful seeming features will be detrimental down the road).
• zvrba 5y ago
  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/ 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.
• Bostonian 5y ago
  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.
  • skruger 5y ago
    Anyone interested in learning APL, I can recommend https://xpqz.github.io/learnapl https://xpqz.github.io/learnapl Disclaimer: I'm the author
• h2odragon 5y ago
  Or just normal languages, used oddly: http://www.ioccc.org/ http://www.ioccc.org/
• mcguire 5y ago
  "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.
• itsmefaz 5y ago
  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.
  • kbrtalan 5y ago
    Why exactly? Current mainstream programming languages have just started to move away from the “fancy C” paradigm (only named functions, classes, imperative control flow constructs) to “prototype ML” paradigm (lambda functions, records, user-defined operators). These features make languages way more expressive (enabling things like SwiftUI), so understanding language nuances will become even more important as more advanced language features find their way into popular languages. Obviously you do not need to be a an expert on compilers, but most powerful languages need some time investment in order to be used at their fullest potential.
    • itsmefaz 5y ago
      OpenAI Codex.
      • wittycardio 5y ago
        Ah so you're a moron
• emodendroket 5y ago
  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.
  • teataster 5y ago
    A) I would say lisps are rather boring. Clojure, one of the most recent ones hasn't changed in 15 years. B) most systems are built in C, Java, Python. So no wonder most complex systems are written in those.
  • dunefox 5y ago
    There is significant 'political' pressure to use whatever is already used and has the libraries. That's C, C++, Java, etc. most of the time. If the libraries and tools were truly language independent then I'm certain more companies would choose languages like CL more frequently for their merits.
    • emodendroket 5y ago
      Well, as the Italians say, "yes, and if my grandmother had wheels she'd be a bicycle."
    • AnimalMuppet 5y ago
      "Whatever already has the libraries" isn't political. It's technical. It's thousands of lines of code that you don't have to write, and don't have to debug, and don't have to maintain. And having relevant libraries is (at least part of) "the merits".
      • erik_seaberg 5y ago
        There's a huge ecosystem of old Java code that is fully usable from Scala or Clojure, including stuff like bindings for native SQLite. Good FFI lets us move beyond old languages.
• kaycebasques 5y ago
  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).
  • sthatipamala 5y ago
    The whole tidyverse set of packages for R. Its a DSL for data analysis that makes heavy use of R macros. The vocabulary and mental model that it has about data transformation is superior to any other analysis package I've used. Pandas/Numpy is close but R's macro/custom operators make everything much more seamless.
    • shepherdjerred 5y ago
      Is it really better than python? I'm not too much in the data analysis space, but it seems like with python's dominance in machine learning that R's days are numbered.
      • sthatipamala 5y ago
        Strictly speaking about data analysis, tidyverse is way better. Even in adjacent spaces such as plotting and interactive data, tools like Shiny [0] are ahead of the Python ecosystem. R is definitely weird language, not as useful for general purpose computing, and has far less marketshare. But that's kinda the point of pg's essay. [0] https://shiny.rstudio.com/ https://shiny.rstudio.com/
• b_emery 5y ago
  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.
  • AlexCoventry 5y ago
    Macros let you change the syntax, roughly speaking. With a library, you're still calling the library with standard syntax. E.g. https://en.m.wikipedia.org/wiki/Anaphoric_macro https://en.m.wikipedia.org/wiki/Anaphoric_macro
  • thibran 5y ago
    A macro is a bit like a template in web programming. You define a structure and some variables that will be filled in. The difference to a template is, a template does not respect context, a macro does. For example, let's say your language had 'if' but not 'case', then it would be possible to write a case macro that in the end transforms at compile time into a bunch of ifs. Macros allows you to create new language syntax and express your intent more clearly.
  • Abhinav2000 5y ago
    Macros let you construct expressions at compile time (not run time). So one can basically create their own programming language in macros, which at compile time expands into the standard language (e.g. lisp). In this way they are powerful for being expressive and also for being highly efficient (as its compile time, not run time). There are many other nifty things you can do as a result, but I am myself not that great. Paul Graham actually wrote the book on macros ('On Lisp'), he's legit :-)
• lisper 5y ago
  > 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.
  • PaulDavisThe1st 5y ago
    > But that doesn't make C++ a good language. TFA is about weird languages, not good (or bad) languages. It's about aspects of a programming language that are not part of the intersection of "95% of all programming languages".
    • lisper 5y ago
      The thesis is: > if you want to expand your concept of what programming can be, one way to do it is by learning weird languages. Implicit in this advice is that programming is actually a useful endeavor and not just a puzzle like sudoku that you engage in mainly to pass the time. And I'm saying that the weird-language heuristic is as likely to lead you to something sudoku-like, where you face a lot of interesting intellectual challenges, but at the end of the day you don't actually get any leverage towards doing anything that is actually useful, as it is to lead you to something with actual utility.
      • PaulDavisThe1st 5y ago
        Absolutely. However, I don't see a path from that to "XX is a (bad|not good) language".
• skadamat 5y ago
  Most programmers STILL haven't experienced the absolute JOY of live coding languages. https://news.ycombinator.com/item?id=28274069 https://news.ycombinator.com/item?id=28274069 https://en.wikipedia.org/wiki/Live_coding https://en.wikipedia.org/wiki/Live_coding
• xtat 5y ago
  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.
• pharmakom 5y ago
  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.
  • kaba0 5y ago
    Just another data point: I have written largely the same tetris program both in Haskell and C++. At first, I was blown away how short the Haskell one was, but later someone wrote that actually, world-count-wise they were largely the same, and indeed he was right. So in certain cases, ML languages are not terser, just more wide, rather than long.
    • yawaramin 5y ago
      But surely word count is not the only criterion that matters. What about safety properties of the two programs, or maintainability/refactorability?
    • pharmakom 5y ago
      Length of code is probably the wrong metric. What I mean is readability or intelligibility or code. Long code is rarely readable (too many files etc) but short code can be hard to read too (e.g. code golf). However, the most readable solution will tend to be short.
• kizer 5y ago
  "lisp..." here we go again
• pphysch 5y ago
  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?
  • christophilus 5y ago
    I’ve run into this attitude among artists, musicians, and woodworkers, so I don’t think it’s particularly unique.
  • the_doctah 5y ago
    Only on this site will they take the word of PG as gospel
  • nso95 5y ago
    rapping (sampling), DJing
• jeffreyrogers 5y ago
  So the Sapir-Whorf hypothesis[0] appears true for programming languages. [0]: https://en.wikipedia.org/wiki/Linguistic_relativity https://en.wikipedia.org/wiki/Linguistic_relativity
• amznbyebyebye 5y ago
  Why do people idolize this guy so much?
  • pphysch 5y ago
    He makes us feel smart
• dfranke 5y ago
  > [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.
  • kaba0 5y ago
    Also, Scala.
    • yawaramin 5y ago
      And Elixir.
  • kazinator 5y ago
    Are you saying that they were easy to implement, and that it was done properly?
    • dfranke 5y ago
      Implementing a modern, production-quality compiler is not easy as a baseline, but nothing in the design of OCaml, Haskell, or Rust adds any significant obstacles, relative to Common Lisp, to supporting this feature. Slinging an AST around and dropping it into a quasiquoted template is a well-understood problem. The simplicity of Lisp's syntax is not a prerequisite and hasn't been since the parsing techniques that were developed in the 1970s. Done properly? I can't speak to camlp4, but at least in the case of Haskell and Rust, certainly. Incidentally I just had my first occasion to write a Rust procedural macro last weekend. I had a significantly complex transformation written and working in half a day, learning curve included, and I found it all pretty frictionless.
      • deleted 5y ago
        [deleted]
      • kazinator 5y ago
        The litmus test is being able to remove any phrase structure in the language and replace it by a macro.
• aaroniba 5y ago
  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.
  • tekacs 5y ago
    > All those anonymous function wraps add clutter, and that clutter accumulates. Another great example of this is feature flags -- adding/removing an entire chunk of code in most languages tends to be limited to (for example) the inside of a function. (when-feature :something (def some-constant ...) (defn some-function [...])) ... is not possible in most languages, where you end up intermingling conditionals into the body of definitions and functions all over the place, creating dead code and issues besides. > JavaScript users are stuck with JSX, which is less concise, and in my opinion far less good. And a key aspect to it as well is that JSX is a fully-custom extension, not something that can be implemented in JS as a library -- whereas Hiccup is 'just another library' allowing for fast iteration and experimentation by the community.
• Abhinav2000 5y ago
  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 https://github.com/ashok-khanna/lisp-notes
• mark-r 5y ago
  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.
• tester756 5y ago
  >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
• rdiddly 5y ago
  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.
• systemvoltage 5y ago
  I think this applies to weird people as well. Some of the most interesting conversations I've had was with people that were misfits.
• rcgorton 5y ago
  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
• sbochins 5y ago
  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.
• hota_mazi 5y ago
  > 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.
  • deleted 5y ago
    [deleted]
  • chrismorgan 5y ago
    I wouldn’t care to claim that Rust has Lisp macros. Lisp macros you define just like any Lisp function, and allow you to create new syntax constructs indistinguishable from any built-in constructs, which can execute whatever code they like as part of the process. In Lisp, macros are evaluated at run-time and can do anything, including access program state (if you play your cards right). They consume something that’s very roughly an AST, and emit something that’s very roughly an AST, and the language makes doing that quite easy, largely because it’s all structural in nature. In Rust, you’ve got macro_rules! which provides convenient syntax for simple structural macros, and then after that you have procedural macros which have the full power, but have to be written in a completely different place and get evaluated at compile-time only (so no dynamic macros), in a completely different context to the code that calls them (so no program state). They’re a lot harder to work with, consuming a stream of token trees (e.g. `if`, `3`, `.`, `{ … }`, `(…)`) and emitting a stream of token trees, a representation that’s clumsy and prone to error (especially since it’s not structural) though this can be mitigated a lot with crates like syn and quote which can make the process at least somewhat more structural, but it’s still way more clumsy than Lisp, where you can’t really distinguish between structural and procedural because they’re basically the same thing. Also Rust macros look different from built-in language constructs, all being like `foo!(…)`, `foo![…]` or `foo! { … }`. I can’t comment about any other languages; they may have things much closer to Lisp macros. (I write this as a Rust expert who writes structural macros regularly but procedural macros only once every year or two at least partly because of how painful they are to write, and a Lisp outsider who’s familiar with all the concepts and written a little here and there over the years but never anything serious.)
• yumaikas 5y ago
  Nim, Elixir, Rust, Zig, D and Jai would all like a word.
• jmugan 5y ago
  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?
  • yawaramin 5y ago
    Because humans are funny creatures that take hundreds of years to convince about seemingly obvious (in hindsight) things? E.g. heliocentrism.
    • jmugan 5y ago
      Good point, but you can't make money with heliocentrism.
      • yawaramin 5y ago
        OK, how about the flat-earth theory? Surely you can make a lot of money if you know the world is a sphere and how to get across it more efficiently than flat-earthers?
        • jmugan 5y ago
          Another good point. But you need additional technology to profit from that knowledge, which could explain why that came slowly.
          • yawaramin 5y ago
            Not really. All you need is a ship, which you've had (at that point) for hundreds of years already.
        • TchoBeer 5y ago
          which is why globe-earth took over as the dominant view at least by 0 AD?
          • 5y ago
• ronenlh 5y ago
  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.
• 0xDEEPFAC 5y ago
  Would Ada++ be considered weird xD? http://www.adapplang.com/tutorial.html http://www.adapplang.com/tutorial.html
• MichaelMoser123 5y ago
  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...
  • chrismorgan 5y ago
    Fairly closely related: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
    • jk7tarYZAQNpTQa 5y ago
      It's fascinating how my (our?) opinion on Google has changed since 2004.
    • MichaelMoser123 5y ago
      related, though observed from different perspectives. But yes, they adopt 'weird languages' for hope of 'hiring the best', but that does that mean? The best according to what measure? I mean few people are 'the best' according to each criteria, there are so many of these criteria.
• JulianMorrison 5y ago
  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.
• lurdawg2 5y ago
  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?
• greggman3 5y ago
  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-correctness/ 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.
• GeorgeTirebiter 5y ago
  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.
• mikewarot 5y ago
  Languages to a programmer are like tools to a machinist. There's always some new goofy situation that requires yet another tool.
• deleted 5y ago
  [deleted]
• sysadm1n 5y ago
  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: https://outline.com/HY6aeR https://outline.com/HY6aeR
  • eimrine 5y ago
    Any reasons for PG's site to use HTTPS? Do you really want your ISP not to eavesdrop what PG has written about Lisp? It is slower than HTTP if a connection is really poor. It may be important for someone who wants to read anything while travelling.
• jumelles 5y ago
  This whole article is so short and generally vague as to be useless.
• martininmelb 5y ago
  As a corollary: “A language that doesn't affect the way you think about programming, is not worth knowing.” - Alan Perlis
• Ericson2314 5y ago
  > 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.
• xiaodai 5y ago
  Does Paul Graham know Prolog or Wolfram or SAS? If not then... isn't it ironic?
• jrockway 5y ago
  > 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."
  • Lamad123 5y ago
    True and Shakespeare spent his life only gluing words together!! The only valuable thing he did was coining a few new words when he dared chasing weirdness!
    • tmsh 5y ago
      Shakespeare invented how we think in post-Shakespeare English by transforming language, not to mention what is important to focus on in life (and sometimes the importance of focusing on important things). 99.9% of programming is a lot more of just plugging together library and API calls. We plug them together to user interfaces which is the apex of the age we live in: technology, empowering people to change the world in exciting new ways (as hackneyed as that sounds). It's just true. Our age involves a lot of globalization (in the Peter Thiel sense), but it's still very squarely part of a technology revolution. Viaweb might've been a way to just make money for the most part. But that's not what impactful SaaS or other software is about. What the APIs / library calls are being connected to is of utmost importance. And similarly, the ideas that Shakespeare came up with - the hundreds of ideas, that help us focus on what's most important to live a meaningful life, those are also helpful. And yes the language plays a role. That said there is a grain of truth to this parent comment and PG's post. But there's also a lot missing. Both words and C++/Java-esque languages are super basic. But with enough of a fixed idea in mind, over time, they're good enough for getting at some really important things. And that is what matters.
• ekampf1 5y ago
  TL;DR - I only ever used LISP and nowadays I spend my time writing LISP dialects literally no one cares about but me.
• Lamad123 5y ago
  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.
• hsn915 5y ago
  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.
  • smnplk 5y ago
    >> 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. I would use more mental energy to write 30 lines of Go, than 5 in lisp. Also if you take into account that you have a true REPL and you can do REPL driven development, which spares you some extra mental energy. But to be fair, Paul is talking about macros, which Go doesn't even have.Macros are more complicated, but are often oversold and over hyped. Yes, they are great, you can extend the language and all, but macros are not that often used, you can probably pick a random lisp codebase and search for macros, I bet you won't find any or less than 2% of the entire codebase. If macros in lisp didn't exist I would still use it, because I love building expressions vs building statemets.
• Ontol 5y ago
  Russian translation: https://habr.com/ru/company/itelma/blog/575128/ https://habr.com/ru/company/itelma/blog/575128/
• z0ltan 5y ago
  Lmfao. This whole site is a joke.
• svilen_dobrev 5y ago
  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
  • tluyben2 5y ago
    You can worship languages and build languages not because they are tools but because you have fun with them independent of them being tools.
• clownpenis_fart 5y ago
  "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
• HighCo 5y ago
  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.