12 ms·

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 tha

by 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).
arp242 5y ago
I think the feeling a lot of people have – or at least the one I have – is just tiredness of al the churn. This year all tables need to be in wood, but in two years wooden tables are soooo old, what kind of old coot are you for using wooden tables?! Is there something wrong with you?! All Real Programmers™ exclusively use steel tables now! Two years down the line people start to realize that steel actually isn't perfect either. But wait, now someone made a carbon fibre table and we need to break down all our steel tables and burn the few wooden tables left and rebuild it all in carbon fibre! It's the future, after all! Of course, eventually people figure out that wooden tables are actually quite good for a fair number of use cases and we've come full circle. I'm just tired of the churn-and-hype cycle and suspect a lot of people have roughly similar feelings, which is expressed in the "languages are unimportant; I build systems"-sentiment. Less and less of modern software development seems to be about actually building interesting things to solve real problems.
- mr_luc 5y ago
  I'd agree that it's a totally valid sentiment in our industry. In the specific context of an essay on pg's site though -- look at those graphics! :D This seems to me like a dude who is okay with wooden tables.
- TeMPOraL 5y ago
  In my experience, the churn is on the systems side, not languages side. The churn happens because someone makes a marginal improvement on some API and makes a nicer marketing copy, and boom, the new most popular JavaScript framework/bundler for this year is born. Programming languages don't churn nearly as fast (and some degree of existing churn can be attributed to the business model of a PL funded by a company - they have every incentive to push it, no matter how little improvements or different concepts the language brings.)
- travisgriggs 5y ago
  I resonate with this. The churn I find most demoralizing is in the library/module/component space. I’ve been pushing myself to learn elixir these last few months. This is, by the comments of many, more of a niche language. I like the language’s novelty and it has caused me to think in new ways. So Paul is righ in this pint. But when I want to send an http request, there must be at least 10 choices on hex to choose from. The one that is a hit this year will be passe’ next year. When I watch the traffic in the Phoenix slack channel, the “stack” of libraries combined seems overwhelming. The same goes for people talking about front end apps.
skytreader 5y ago
> What can you say in this language that would be impossibly inconvenient to say in others? Maybe it's just me and my possibly-unreasonable infatuation with the Sapir-Whorf hypothesis (SWH) but I've come to think it also applies to many things in life, PLs especially so. "Weird languages" aren't valuable because you can deploy it in production, rather because it will help you recontextualize a problem (in SWH-parlance, it helps you see the world differently). You can also say, SWH is an academic formulation of the beloved programmer motto "When all you have is a hammer, everything looks like a nail". If all you know is an imperative syntax, all problems look solvable by breaking them down into a series of steps/procedures. In my almost ten years in the industry, there's exactly one time I was able to apply an "unusual" paradigm to solve a problem. GvR might curse me because I sort of made a Lisp-like DSL in Python but I stand by my design decision. The end-result was a small (~200LoC linted with black) DSL parser with some DB access and a lot of rules which actually tried to solve the problem. When I found something wrong I just had to reformulate a rule, not actually wrangle with loops, conditionals, and control flow in order to rewrite logic. Honest negatives: I had to turn over the project to someone whose background is in EEE, not CS, and I had to explain Higher-Order Functions to them. Not ideal! Actually, in fairness, I bet most in that team would have a hard time figuring it out because, hey, I made a Lisp in Python! But I still stand by my decision; it was the best for the problem given the resources and time I had.
- emodendroket 5y ago
  On the other side of the ledger, the Sapir-Whorf hypothesis is widely considered discredited by linguists.
  - skytreader 5y ago
    Has it? I'm genuinely curious to know. "Widely considered discredited" sounds like it's met the same fate as ether or alchemy. I commented on SWH a few months ago in HN too when another user, claiming background in linguistics, replied that it factors in your world view but not as huge a factor as other cultural considerations. That sounded reasonable. So as of the last time I looked up SWH (a few months ago), my knowledge of its consensus is that: - the weak form ("relativism") is true to a certain extent, and definitely not to the extent Whorf originally proposed. - the strong form ("determinism") is largely debated and, personally, I think it's indefensible as a thesis.
emodendroket 5y ago
Rocket materials don't ultimately compile down to the same material though. This makes the analogy somewhat flawed. Also, if a novel language feature is useful enough, it's often stolen by the competition.
- ovis 5y ago
  From the article, > [Lisp macros] by their nature would be hard to implement properly in a language without turning it into a dialect of Lisp Other candidates that come to mind (because I recently learned about them) are effect systems, like in Koka.
  - emodendroket 5y ago
    Yes, I read that, but I don't know Lisp well enough to evaluate the claim.
    - klyrs 5y ago
      I'd highly recommend learning lisp and writing some higher-order functions with macros. You start with an instance of a lower-order function, insert a few backticks and commas where appropriate, wrap that in a defmacro, and boom, you're a metaprogrammer. You can certainly do similar stuff in other languages, but it's almost always a cludge. The rest of lisp is pretty easy if you've done any sort of functional programming, and view the code through a lens that translates (foo ...) to foo(...)
  - Shorel 5y ago
    Mixin macros in D are just about as powerful, and D is not a dialect of lisp. The main difference is: mixins are compile-time only, you can't add them to a running system like in Lisp. In practice, it is a much smaller difference than it looks like.
sanderjd 5y ago
I honestly haven't seen any evidence of this whole "think things you couldn't previously think" idea. The only interesting thing I've seen people be able to do by switching languages, is significantly improving static analysis, in order to save debugging cycles and improve production reliability. But everything else that is "interesting" is just different ways to generate code in order to reduce lines of code written manually, which is convenient, and is certainly fun for nerds like most of us here, but I really don't see it as this superpower that folks like pg seem to believe it to be. A better analogy for new materials is new techniques, like machine learning and higher order abstractions over it, or new algorithms. But those are independent of languages.
- ahefner 5y ago
  It's a real thing, but I think (extrapolating from my own experience) it's much more profound and tangible if you're starting from something like C or pre-modern C++ and then moving to something more modern and FP-flavored. Modern popular language are on a much more even playing field versus 20 years ago. Even so, I still had one of these mind blowing "things I couldn't previously think" experiences when I finally ventured into Prolog and logic programming a few years ago. It's such an order of magnitude beyond my day to day C++ and Python nonsense, at least up until the evaluation model blows up exponentially. I'd still like, as a learning exercise, to build some semi-practical small applications in Prolog, but I feel like I'd need an expert mentor to guide me.
- mr_luc 5y ago
  I agree that there aren't a ton of convincing examples mentioned that aren't relevant to people who already agree w/the value of lisp-style macros -- but if you're interested I used the example of erlang when responding to a comment above: https://news.ycombinator.com/item?id=28343140 https://news.ycombinator.com/item?id=28343140 FWIW I do actually agree w/pg about macros; I use them day-to-day for more mundane things than his impressive fully-bottom-up approach to programming. But each time I do use them, I feel like "thank heavens I don't have to reach for some weird external codegen tool to do this".
  - 5y ago
huachimingo 5y ago
The other problem is the "productive-only" trap. You begin to hate art, essays and everything related with free time because you are not doing anything productive doing those. This can expand to your tastes or everyday life by not wanting to learn X "just for the fun".
- mattgreenrocks 5y ago
  The amount of intellectual curiosity on a site called Hacker News always feels lower than it should be.
klyrs 5y ago
I'd say that (2) isn't a side point... > 99.5% of programming consists of gluing together calls to library functions. All popular languages are equally good at this. In my experience, there are tons of programmers who balk at anything more complicated than a for loop, to the point where they won't even read the surrounding documentation of a short block of code to try and understand what it does. That's the 99.5% of programming that pg is talking about. I'd guess that some 80% of programmers spend their entire lives in this regime. When algorithm/language researchers talk to software engineers about what programming is, sparks fly. Like the parable of the blind people examining an elephant, we're talking about the same thing, but our experiences with it are too different to reconcile.
k__ 5y ago
If someone used Lisp, Elm, Rust, Elixir, Go, or even just JavaScript, they should know that these are SO vastly different in their mental models that "languages are solved" doesn't strike me as a reasonable argument at all.
- deleted 5y ago
  [deleted]
- kaba0 5y ago
  Are they so vastly different? Other than perhaps Lisp and Elm, they are largely equivalent, with different levels of immutability on top of a largely imperative core. At least mention prolog, forth, SQL or the like that are truly different.
  - k__ 5y ago
    They all have distiguishing features that can be emulated in other languages (to a degree) but will throw off even senior developers. Lisp has its macros. Elm has its type system. Go, Elixir, and JS have rather idiosyncratic concurrency models. Rust has its borrow checker. Perl seems to be SO special that even proficient Perl devs aren't able to write performant code in it. /s Sure, Prolog and SQL are much more different than the rest. But I didn't want to strawman here.
  - chrismorgan 5y ago
    Rust’s ownership model (which is more than just the borrow checker, it’s the whole concept of one location actually owning data, and aliasing XOR mutability, and the pervading effects of this design on the language and its libraries) is a really big deal, even if it doesn’t look like it would be at a casual glance. It changes how you approach programming and reason about systems, and truly is (or should be used as) a fundamentally different approach to data flow and what’s possible, a smidgeon like Prolog in that way of being different, though not as much. I miss it very frequently when working in other languages (which is mostly JavaScript these days), because there are plenty of things that just become impossible to express reliably without it. Working in another language you can adopt conventions of writing in this style, but you can’t verify it without representing it in the type system, so the result will be riddled with holes in other languages. (It is, however, difficult to disentangle some features that Rust’s ownership model requires but which aren’t necessarily a part of that ownership model: for example, algebraic data types are essential and expression orientation extremely desirable, but there are other languages which have those features without the rest of the ownership model.) People often think memory safety without garbage collection is Rust’s shtick, but it’s actually the ownership model that’s Rust’s defining feature, underpinning everything and making that possible.
5faulker 5y ago
Not to mention that languages are not just a tool for communicating meaning: it's also a tool for communicating emotions and mannerism as well.
bastawhiz 5y ago
> but saying that languages don't matter, for us, would be like rocket engineers saying that materials don't matter. This is a bad analogy. Programming languages all get compiled to the same machine codes. The human-readable version of that code doesn't actually matter very much, if at all, after compilation. Programming languages are tools for humans: they're either expressive enough or they're not. A better analogy would be rocket engineers saying the CAD tool you choose to design your rocket in doesn't matter—and that has some merit.
ashtonkem 5y ago
My problem with these arguments from PG is that they require that you pretend (or ignore) all the real world evidence we have about what languages are actually useful to make things with. It’s all fine and well to talk about how great X and Y is, but meanwhile most people are actually making things in Java and Go.
- TeMPOraL 5y ago
  But what real world evidence do we have? Mostly that languages "most people are actually making things in" are picked by the business on the basis of popularity, which is determined mostly by what people learn in university - which is determined mostly by what is currently most popular on the job market. It's a self-sustaining feedback loop that has little to do with relative utility of languages for real-world problems (at least discounting languages' library ecosystems).
  - ashtonkem 5y ago
    This argument is self refuting. If inferior programming languages are being picked continuously by “the business”, we’d expect that businesses that pick “superior” programming languages to out compete the other businesses. We don’t see this, so one of the following is true: 1) Programming language quality is a non-factor in business success. 2) People like PG are wrong about what makes one language superior to another. By the by, I have never seen a non-programmer executive demand a “bad” language be used for a startup. What I tend to see is grizzled ex-programmers ignoring the trends and picking the reliable and “boring” choice over the complaints of some IC’s. This is less a “clueless business” issue and more an acknowledgment of an unpopular truth: picking the boring language that lets the business focus on its core domain is better than picking something that excites the most vocal engineers.
    - mst 5y ago
      The claim that learning weird languages will help you learn new ways of thinking about problems that may be helpful in other langauges, and the claim that using 'boring' languages is the correct default for building production systems, in no way contradict.
bob1029 5y ago
> What can you say in this language that would be impossibly inconvenient to say in others? This ideology is why I believe so strongly in the power of SQL (and similarly-expressive functional/DSLs). They are effectively limitless in their ability to describe problem spaces. In SQL, joining 30 different dimensions of data is a matter of the same # of lines of SQL. Doing such a thing in any imperative language would be a medium nightmare at best. Even with LINQ at your disposal, this is not fun. I actually did not realize it was possible to construct a useful piece of business software that exclusively uses SQL for its domain logic until ~18 months ago. Turns out the trick is to go all-in and just make sure 100% of the relevant domain state is represented in the schema. You also have to understand why database normalization is important if you go down this road. The only reason you would fail to model something properly is lack of imagination, experience and/or discipline. These tools are limitless. There is also the benefit to the business. You can print off all of the tables as excel spreadsheets and review them with non-technical stakeholders. I find this much preferable to explaining how procedural code works to non-wizards. So, I would say - Weird languages - Absolutely yes. But, also go check out some of these new tricks you can teach to old mainstream things. If you want to play around with these ideas, getting SQL into your application is absolutely trivial with SQLite these days. We are using it in production for this purpose right now. My project managers are more familiar with the product's schema than I am at this point, because they are authoring BL in SQL today. This is where you really want to be, IMO.
- punnerud 5y ago
  “You can print off all of the tables as excel spreadsheets and review them with non-technical stakeholders.” Try something like Metabase. Just place the SQL in there and you get a URL that gives you dynamically updated “Excel”. I like this way of business development: Prototype some SQL, place it in Metabase, get feedback, update the SQL, when they are happy, make it to an Update that solve their need automatically. And it gets way more powerful when you learn Macros in PL/SQL or PostgreSQL so that you can dynamically change the SQL based on results. One example is to build the Metabase functionality into the business application do that you can easily add/change SQL, and the resulting values automatically is clickable if the data comes from the right tables/views.
AceJohnny2 5y ago
There was this analogy about programming language proponents. Language A has features 1, 2, and 3. Language B has features 1, 2, and 4. Language A user thinks they're superior because they have feature 3, which B lacks. B's feature 4 they don't understand, but they've never needed it so it's useless. Language B user thinks the opposite, of course. (this was much better explained in an article that graced HN a while back, and I can't find anymore)
- Akronymus 5y ago
  https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox
  - AceJohnny2 5y ago
    That's exactly it!
JBiserkov 5y ago
>Languages are solved, not important; I build systems. The language of the System - Rich Hickey https://www.youtube.com/watch?v=ROor6_NGIWU https://www.youtube.com/watch?v=ROor6_NGIWU
jollybean 5y ago
Looking at functional languages helped me understand the point of all a little better, to the point where I write completely different imperative code now. I'm much better at reducing state, leveraging static calls / libs etc.. But I'll probably never use a functional language in production. The Rust borrowchecker is an awesome idea, I don't quite like Rust and don't want to use it, but I'm excited for the concept to be introduced into established or newer languages - and it helped me reason about my own programs a little bit. Even beyond personal curiosity, that was time well spent.
MaxBarraclough 5y ago
> saying that languages don't matter, for us, would be like rocket engineers saying that materials don't matter. It also seems plainly mistaken. We still see a steady stream of security vulnerabilities relating to imperfect use of unsafe languages. Safer languages make those sorts of errors categorically impossible. Even if your position is sure but these languages aren't always practical, that's still a concession that further work is needed on safe languages.
shrimpx 5y ago
In my experience, as you learn more about lambda calculus and type theory (LC, STLC, System-F, System-Fw, CiC) the peculiarities of language designs start to fade. This is because when you see a weird-looking language feature, instead of internalizing it as a unique design with its own unique character, you tend to see it as "syntactic sugar" on elemental theories. That said, some languages are more ergonomic than others, especially when you compare them against particular domains. But IMO that's a problem that transcends language design. All tools, not just a language, should be fit to the domain. And in general you can build APIs and libraries that can reasonably fit any language to a domain. Edit: slight simplification.
- mr_luc 5y ago
  I'd definitely agree with the specific point of both paragraphs, especially because you said 'language designs' in the first. But I think the essay uses 'language' to mean what you do in your second paragraph, 'features'/stdlib/ecosystem -- the whole experience of working with that material in practice. And in that sense, I think the value of 'weird' languages is that they can package so many different mutually-reenforcing design decisions together that they literally can have the 'think different' effect described in the essay. Taking one example that's kinda-weird, kinda-mainstream -- a 'language' like Erlang includes way more than a Prolog-inspired syntax for a simple functional language, and when you look closely at it, it's not simple to just recreate by pulling in features ad-hoc; the language, its stdlib, and its VM complement each other and have informed each others' design. Probably the feature that most comes to mind when we think of Erlang is that it 'goes all-in' on message passing in a functional language. 'All in' meaning that they've made decisions like: being willing to copy a lot if needed, little details like keeping a count of reductions, big things like pulling in concerns that are often left to the OS when working in other languages like process scheduling, preemption, and supervision, and providing a toolkit out of the box that supports building full systems via Nodes with Applications with trees of Supervisors of Processes (all of which are effectively language concepts now), etc. Well, every one of those decisions is eyebrow-raising to somebody or a lot of somebodies. But if you do go all-in on that combo of capabilities, what's it like? A good engineering team with a lot of money can fit another language and another VM to the same kinds of domains that Erlang is a fit for. (Not that you can get people to agree what those domains are, even within Ericcson apparently). But their solution will necessarily look very different, and the difference between what's easy/hard in their approach vs. an erlang-ish approach is what the weird language can teach us.
ankurdhama 5y ago
The whole explanation of your point is just filled with analogies. IMO if you have to use analogies to explain your point then you really don't understand your own point. When programming, I am thinking in terms of data, what processing the data needs, how will you structure the data in memory/disk, what IO/integration is required etc. This thinking has nothing to do with what the programming language allows/makes you to think. If your programming language is supposed to dominate your thinking about programs then you are just constraining yourself to a specific way of solving the problem.
kortilla 5y ago
This rocket analogy falls flat because the languages that have been used to build the most scalable and/or complex systems of today are usually the boring ones (c/c++/Java/python/ruby/JavaScript). Linux, llvm, Android, iOS, git, cPython, numpy, etc, etc. From operating systems, to compilers, to scientific computing, to literal rocket control systems, it’s mostly boring C/C++/obj-C/Java.
- robertlagrant 5y ago
  Is that true? WhatsApp, Discord, and Facebook Messenger are Erlang. Some pretty extreme scale systems, I'd say.
  - kaba0 5y ago
    Some of these companies are so insanely huge that they have dozens of technology stacks, so I would not attribute elixir specifically, to the latter two at least (wasn’t discord rewritten in rust not too long ago?) And facebook itself is historically PHP (where they had to fork the runtime even), but they use plenty of other boring tech (eg. Java), as well as some exotic ones, notably haskell for some query pre-optimization (afaik)
    - steveklabnik 5y ago
      They rewrote some services from Go to Rust, but have always been a huge elixir shop. They wrote some NIFs in Rust too.

by mr_luc 5y ago

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).

arp242 5y ago

I think the feeling a lot of people have – or at least the one I have – is just tiredness of al the churn. This year all tables need to be in wood, but in two years wooden tables are soooo old, what kind of old coot are you for using wooden tables?! Is there something wrong with you?! All Real Programmers™ exclusively use steel tables now! Two years down the line people start to realize that steel actually isn't perfect either. But wait, now someone made a carbon fibre table and we need to break down all our steel tables and burn the few wooden tables left and rebuild it all in carbon fibre! It's the future, after all! Of course, eventually people figure out that wooden tables are actually quite good for a fair number of use cases and we've come full circle. I'm just tired of the churn-and-hype cycle and suspect a lot of people have roughly similar feelings, which is expressed in the "languages are unimportant; I build systems"-sentiment. Less and less of modern software development seems to be about actually building interesting things to solve real problems.

mr_luc 5y ago
I'd agree that it's a totally valid sentiment in our industry. In the specific context of an essay on pg's site though -- look at those graphics! :D This seems to me like a dude who is okay with wooden tables.
TeMPOraL 5y ago
In my experience, the churn is on the systems side, not languages side. The churn happens because someone makes a marginal improvement on some API and makes a nicer marketing copy, and boom, the new most popular JavaScript framework/bundler for this year is born. Programming languages don't churn nearly as fast (and some degree of existing churn can be attributed to the business model of a PL funded by a company - they have every incentive to push it, no matter how little improvements or different concepts the language brings.)
travisgriggs 5y ago
I resonate with this. The churn I find most demoralizing is in the library/module/component space. I’ve been pushing myself to learn elixir these last few months. This is, by the comments of many, more of a niche language. I like the language’s novelty and it has caused me to think in new ways. So Paul is righ in this pint. But when I want to send an http request, there must be at least 10 choices on hex to choose from. The one that is a hit this year will be passe’ next year. When I watch the traffic in the Phoenix slack channel, the “stack” of libraries combined seems overwhelming. The same goes for people talking about front end apps.

skytreader 5y ago

> What can you say in this language that would be impossibly inconvenient to say in others? Maybe it's just me and my possibly-unreasonable infatuation with the Sapir-Whorf hypothesis (SWH) but I've come to think it also applies to many things in life, PLs especially so. "Weird languages" aren't valuable because you can deploy it in production, rather because it will help you recontextualize a problem (in SWH-parlance, it helps you see the world differently). You can also say, SWH is an academic formulation of the beloved programmer motto "When all you have is a hammer, everything looks like a nail". If all you know is an imperative syntax, all problems look solvable by breaking them down into a series of steps/procedures. In my almost ten years in the industry, there's exactly one time I was able to apply an "unusual" paradigm to solve a problem. GvR might curse me because I sort of made a Lisp-like DSL in Python but I stand by my design decision. The end-result was a small (~200LoC linted with black) DSL parser with some DB access and a lot of rules which actually tried to solve the problem. When I found something wrong I just had to reformulate a rule, not actually wrangle with loops, conditionals, and control flow in order to rewrite logic. Honest negatives: I had to turn over the project to someone whose background is in EEE, not CS, and I had to explain Higher-Order Functions to them. Not ideal! Actually, in fairness, I bet most in that team would have a hard time figuring it out because, hey, I made a Lisp in Python! But I still stand by my decision; it was the best for the problem given the resources and time I had.

emodendroket 5y ago
On the other side of the ledger, the Sapir-Whorf hypothesis is widely considered discredited by linguists.
- skytreader 5y ago
  Has it? I'm genuinely curious to know. "Widely considered discredited" sounds like it's met the same fate as ether or alchemy. I commented on SWH a few months ago in HN too when another user, claiming background in linguistics, replied that it factors in your world view but not as huge a factor as other cultural considerations. That sounded reasonable. So as of the last time I looked up SWH (a few months ago), my knowledge of its consensus is that: - the weak form ("relativism") is true to a certain extent, and definitely not to the extent Whorf originally proposed. - the strong form ("determinism") is largely debated and, personally, I think it's indefensible as a thesis.

emodendroket 5y ago

Rocket materials don't ultimately compile down to the same material though. This makes the analogy somewhat flawed. Also, if a novel language feature is useful enough, it's often stolen by the competition.

ovis 5y ago
From the article, > [Lisp macros] by their nature would be hard to implement properly in a language without turning it into a dialect of Lisp Other candidates that come to mind (because I recently learned about them) are effect systems, like in Koka.
- emodendroket 5y ago
  Yes, I read that, but I don't know Lisp well enough to evaluate the claim.
  - klyrs 5y ago
    I'd highly recommend learning lisp and writing some higher-order functions with macros. You start with an instance of a lower-order function, insert a few backticks and commas where appropriate, wrap that in a defmacro, and boom, you're a metaprogrammer. You can certainly do similar stuff in other languages, but it's almost always a cludge. The rest of lisp is pretty easy if you've done any sort of functional programming, and view the code through a lens that translates (foo ...) to foo(...)
- Shorel 5y ago
  Mixin macros in D are just about as powerful, and D is not a dialect of lisp. The main difference is: mixins are compile-time only, you can't add them to a running system like in Lisp. In practice, it is a much smaller difference than it looks like.

sanderjd 5y ago

I honestly haven't seen any evidence of this whole "think things you couldn't previously think" idea. The only interesting thing I've seen people be able to do by switching languages, is significantly improving static analysis, in order to save debugging cycles and improve production reliability. But everything else that is "interesting" is just different ways to generate code in order to reduce lines of code written manually, which is convenient, and is certainly fun for nerds like most of us here, but I really don't see it as this superpower that folks like pg seem to believe it to be. A better analogy for new materials is new techniques, like machine learning and higher order abstractions over it, or new algorithms. But those are independent of languages.

ahefner 5y ago
It's a real thing, but I think (extrapolating from my own experience) it's much more profound and tangible if you're starting from something like C or pre-modern C++ and then moving to something more modern and FP-flavored. Modern popular language are on a much more even playing field versus 20 years ago. Even so, I still had one of these mind blowing "things I couldn't previously think" experiences when I finally ventured into Prolog and logic programming a few years ago. It's such an order of magnitude beyond my day to day C++ and Python nonsense, at least up until the evaluation model blows up exponentially. I'd still like, as a learning exercise, to build some semi-practical small applications in Prolog, but I feel like I'd need an expert mentor to guide me.
mr_luc 5y ago
I agree that there aren't a ton of convincing examples mentioned that aren't relevant to people who already agree w/the value of lisp-style macros -- but if you're interested I used the example of erlang when responding to a comment above: https://news.ycombinator.com/item?id=28343140 https://news.ycombinator.com/item?id=28343140 FWIW I do actually agree w/pg about macros; I use them day-to-day for more mundane things than his impressive fully-bottom-up approach to programming. But each time I do use them, I feel like "thank heavens I don't have to reach for some weird external codegen tool to do this".
- 5y ago

huachimingo 5y ago

The other problem is the "productive-only" trap. You begin to hate art, essays and everything related with free time because you are not doing anything productive doing those. This can expand to your tastes or everyday life by not wanting to learn X "just for the fun".

mattgreenrocks 5y ago
The amount of intellectual curiosity on a site called Hacker News always feels lower than it should be.

klyrs 5y ago

I'd say that (2) isn't a side point... > 99.5% of programming consists of gluing together calls to library functions. All popular languages are equally good at this. In my experience, there are tons of programmers who balk at anything more complicated than a for loop, to the point where they won't even read the surrounding documentation of a short block of code to try and understand what it does. That's the 99.5% of programming that pg is talking about. I'd guess that some 80% of programmers spend their entire lives in this regime. When algorithm/language researchers talk to software engineers about what programming is, sparks fly. Like the parable of the blind people examining an elephant, we're talking about the same thing, but our experiences with it are too different to reconcile.

k__ 5y ago

If someone used Lisp, Elm, Rust, Elixir, Go, or even just JavaScript, they should know that these are SO vastly different in their mental models that "languages are solved" doesn't strike me as a reasonable argument at all.

deleted 5y ago
[deleted]
kaba0 5y ago
Are they so vastly different? Other than perhaps Lisp and Elm, they are largely equivalent, with different levels of immutability on top of a largely imperative core. At least mention prolog, forth, SQL or the like that are truly different.
- k__ 5y ago
  They all have distiguishing features that can be emulated in other languages (to a degree) but will throw off even senior developers. Lisp has its macros. Elm has its type system. Go, Elixir, and JS have rather idiosyncratic concurrency models. Rust has its borrow checker. Perl seems to be SO special that even proficient Perl devs aren't able to write performant code in it. /s Sure, Prolog and SQL are much more different than the rest. But I didn't want to strawman here.
- chrismorgan 5y ago
  Rust’s ownership model (which is more than just the borrow checker, it’s the whole concept of one location actually owning data, and aliasing XOR mutability, and the pervading effects of this design on the language and its libraries) is a really big deal, even if it doesn’t look like it would be at a casual glance. It changes how you approach programming and reason about systems, and truly is (or should be used as) a fundamentally different approach to data flow and what’s possible, a smidgeon like Prolog in that way of being different, though not as much. I miss it very frequently when working in other languages (which is mostly JavaScript these days), because there are plenty of things that just become impossible to express reliably without it. Working in another language you can adopt conventions of writing in this style, but you can’t verify it without representing it in the type system, so the result will be riddled with holes in other languages. (It is, however, difficult to disentangle some features that Rust’s ownership model requires but which aren’t necessarily a part of that ownership model: for example, algebraic data types are essential and expression orientation extremely desirable, but there are other languages which have those features without the rest of the ownership model.) People often think memory safety without garbage collection is Rust’s shtick, but it’s actually the ownership model that’s Rust’s defining feature, underpinning everything and making that possible.

5faulker 5y ago

Not to mention that languages are not just a tool for communicating meaning: it's also a tool for communicating emotions and mannerism as well.

bastawhiz 5y ago

> but saying that languages don't matter, for us, would be like rocket engineers saying that materials don't matter. This is a bad analogy. Programming languages all get compiled to the same machine codes. The human-readable version of that code doesn't actually matter very much, if at all, after compilation. Programming languages are tools for humans: they're either expressive enough or they're not. A better analogy would be rocket engineers saying the CAD tool you choose to design your rocket in doesn't matter—and that has some merit.

ashtonkem 5y ago

My problem with these arguments from PG is that they require that you pretend (or ignore) all the real world evidence we have about what languages are actually useful to make things with. It’s all fine and well to talk about how great X and Y is, but meanwhile most people are actually making things in Java and Go.

TeMPOraL 5y ago
But what real world evidence do we have? Mostly that languages "most people are actually making things in" are picked by the business on the basis of popularity, which is determined mostly by what people learn in university - which is determined mostly by what is currently most popular on the job market. It's a self-sustaining feedback loop that has little to do with relative utility of languages for real-world problems (at least discounting languages' library ecosystems).
- ashtonkem 5y ago
  This argument is self refuting. If inferior programming languages are being picked continuously by “the business”, we’d expect that businesses that pick “superior” programming languages to out compete the other businesses. We don’t see this, so one of the following is true: 1) Programming language quality is a non-factor in business success. 2) People like PG are wrong about what makes one language superior to another. By the by, I have never seen a non-programmer executive demand a “bad” language be used for a startup. What I tend to see is grizzled ex-programmers ignoring the trends and picking the reliable and “boring” choice over the complaints of some IC’s. This is less a “clueless business” issue and more an acknowledgment of an unpopular truth: picking the boring language that lets the business focus on its core domain is better than picking something that excites the most vocal engineers.
  - mst 5y ago
    The claim that learning weird languages will help you learn new ways of thinking about problems that may be helpful in other langauges, and the claim that using 'boring' languages is the correct default for building production systems, in no way contradict.

bob1029 5y ago

> What can you say in this language that would be impossibly inconvenient to say in others? This ideology is why I believe so strongly in the power of SQL (and similarly-expressive functional/DSLs). They are effectively limitless in their ability to describe problem spaces. In SQL, joining 30 different dimensions of data is a matter of the same # of lines of SQL. Doing such a thing in any imperative language would be a medium nightmare at best. Even with LINQ at your disposal, this is not fun. I actually did not realize it was possible to construct a useful piece of business software that exclusively uses SQL for its domain logic until ~18 months ago. Turns out the trick is to go all-in and just make sure 100% of the relevant domain state is represented in the schema. You also have to understand why database normalization is important if you go down this road. The only reason you would fail to model something properly is lack of imagination, experience and/or discipline. These tools are limitless. There is also the benefit to the business. You can print off all of the tables as excel spreadsheets and review them with non-technical stakeholders. I find this much preferable to explaining how procedural code works to non-wizards. So, I would say - Weird languages - Absolutely yes. But, also go check out some of these new tricks you can teach to old mainstream things. If you want to play around with these ideas, getting SQL into your application is absolutely trivial with SQLite these days. We are using it in production for this purpose right now. My project managers are more familiar with the product's schema than I am at this point, because they are authoring BL in SQL today. This is where you really want to be, IMO.

punnerud 5y ago
“You can print off all of the tables as excel spreadsheets and review them with non-technical stakeholders.” Try something like Metabase. Just place the SQL in there and you get a URL that gives you dynamically updated “Excel”. I like this way of business development: Prototype some SQL, place it in Metabase, get feedback, update the SQL, when they are happy, make it to an Update that solve their need automatically. And it gets way more powerful when you learn Macros in PL/SQL or PostgreSQL so that you can dynamically change the SQL based on results. One example is to build the Metabase functionality into the business application do that you can easily add/change SQL, and the resulting values automatically is clickable if the data comes from the right tables/views.

AceJohnny2 5y ago

There was this analogy about programming language proponents. Language A has features 1, 2, and 3. Language B has features 1, 2, and 4. Language A user thinks they're superior because they have feature 3, which B lacks. B's feature 4 they don't understand, but they've never needed it so it's useless. Language B user thinks the opposite, of course. (this was much better explained in an article that graced HN a while back, and I can't find anymore)

Akronymus 5y ago
https://wiki.c2.com/?BlubParadox https://wiki.c2.com/?BlubParadox
- AceJohnny2 5y ago
  That's exactly it!

JBiserkov 5y ago

>Languages are solved, not important; I build systems. The language of the System - Rich Hickey https://www.youtube.com/watch?v=ROor6_NGIWU https://www.youtube.com/watch?v=ROor6_NGIWU

jollybean 5y ago

Looking at functional languages helped me understand the point of all a little better, to the point where I write completely different imperative code now. I'm much better at reducing state, leveraging static calls / libs etc.. But I'll probably never use a functional language in production. The Rust borrowchecker is an awesome idea, I don't quite like Rust and don't want to use it, but I'm excited for the concept to be introduced into established or newer languages - and it helped me reason about my own programs a little bit. Even beyond personal curiosity, that was time well spent.

MaxBarraclough 5y ago

> saying that languages don't matter, for us, would be like rocket engineers saying that materials don't matter. It also seems plainly mistaken. We still see a steady stream of security vulnerabilities relating to imperfect use of unsafe languages. Safer languages make those sorts of errors categorically impossible. Even if your position is sure but these languages aren't always practical, that's still a concession that further work is needed on safe languages.

shrimpx 5y ago

In my experience, as you learn more about lambda calculus and type theory (LC, STLC, System-F, System-Fw, CiC) the peculiarities of language designs start to fade. This is because when you see a weird-looking language feature, instead of internalizing it as a unique design with its own unique character, you tend to see it as "syntactic sugar" on elemental theories. That said, some languages are more ergonomic than others, especially when you compare them against particular domains. But IMO that's a problem that transcends language design. All tools, not just a language, should be fit to the domain. And in general you can build APIs and libraries that can reasonably fit any language to a domain. Edit: slight simplification.

mr_luc 5y ago
I'd definitely agree with the specific point of both paragraphs, especially because you said 'language designs' in the first. But I think the essay uses 'language' to mean what you do in your second paragraph, 'features'/stdlib/ecosystem -- the whole experience of working with that material in practice. And in that sense, I think the value of 'weird' languages is that they can package so many different mutually-reenforcing design decisions together that they literally can have the 'think different' effect described in the essay. Taking one example that's kinda-weird, kinda-mainstream -- a 'language' like Erlang includes way more than a Prolog-inspired syntax for a simple functional language, and when you look closely at it, it's not simple to just recreate by pulling in features ad-hoc; the language, its stdlib, and its VM complement each other and have informed each others' design. Probably the feature that most comes to mind when we think of Erlang is that it 'goes all-in' on message passing in a functional language. 'All in' meaning that they've made decisions like: being willing to copy a lot if needed, little details like keeping a count of reductions, big things like pulling in concerns that are often left to the OS when working in other languages like process scheduling, preemption, and supervision, and providing a toolkit out of the box that supports building full systems via Nodes with Applications with trees of Supervisors of Processes (all of which are effectively language concepts now), etc. Well, every one of those decisions is eyebrow-raising to somebody or a lot of somebodies. But if you do go all-in on that combo of capabilities, what's it like? A good engineering team with a lot of money can fit another language and another VM to the same kinds of domains that Erlang is a fit for. (Not that you can get people to agree what those domains are, even within Ericcson apparently). But their solution will necessarily look very different, and the difference between what's easy/hard in their approach vs. an erlang-ish approach is what the weird language can teach us.

ankurdhama 5y ago

The whole explanation of your point is just filled with analogies. IMO if you have to use analogies to explain your point then you really don't understand your own point. When programming, I am thinking in terms of data, what processing the data needs, how will you structure the data in memory/disk, what IO/integration is required etc. This thinking has nothing to do with what the programming language allows/makes you to think. If your programming language is supposed to dominate your thinking about programs then you are just constraining yourself to a specific way of solving the problem.

kortilla 5y ago

This rocket analogy falls flat because the languages that have been used to build the most scalable and/or complex systems of today are usually the boring ones (c/c++/Java/python/ruby/JavaScript). Linux, llvm, Android, iOS, git, cPython, numpy, etc, etc. From operating systems, to compilers, to scientific computing, to literal rocket control systems, it’s mostly boring C/C++/obj-C/Java.

robertlagrant 5y ago
Is that true? WhatsApp, Discord, and Facebook Messenger are Erlang. Some pretty extreme scale systems, I'd say.
- kaba0 5y ago
  Some of these companies are so insanely huge that they have dozens of technology stacks, so I would not attribute elixir specifically, to the latter two at least (wasn’t discord rewritten in rust not too long ago?) And facebook itself is historically PHP (where they had to fork the runtime even), but they use plenty of other boring tech (eg. Java), as well as some exotic ones, notably haskell for some query pre-optimization (afaik)
  - steveklabnik 5y ago
    They rewrote some services from Go to Rust, but have always been a huge elixir shop. They wrote some NIFs in Rust too.