4 ms·

Many newer programming languages have focused on reducing hidden control flow and ugly text macros in favor of more transparent metaprogramming, which may help

by jchw 5y ago

Many newer programming languages have focused on reducing hidden control flow and ugly text macros in favor of more transparent metaprogramming, which may help to illustrate one of the bigger issues with Lisp. Lisp itself is simple and elegant, but that doesn't mean it's easy to write simple and elegant Lisp code. Imperative programming is maybe less elegant and beautiful than functional programming, but imperative programming is easy to understand by humans. Sure, C code may not literally execute line by line, but this is how C programmers mentally model execution, to the point where sometimes people are befuddled to learn it’s not the case. It's such an effective approach that CPUs also provide an as-if illusion of in-order execution. And sure, Lisp macros are powerful, but it feels like nobody ever stopped to consider if maybe there's an upper limit to how powerful you really want a programming language to be. Well, I have. I want languages more like Go and Zig. People will always hate at least Go, but it didn't hit TIOBE top 10 out of sheer baseless hype and corporate sponsorship. Simple, easy to understand, perhaps even "stupid" code works. I could be wrong—perhaps the Lisp renaissance is just around the bend. But realistically, I'm not running into any problems where I wish to deal with more clever and elegant code. In fact, I'm running into problems where I wish to deal with dumber and more obvious code. That these ideals often conflict is probably a great source of debate and strife.

BoiledCabbage 5y ago
Programming languages don't win because they are inherently better. Programming languages win because they fill a need better, or are more familiar. There are better languages than other, that help people to write better code, have bugs be easier to find, push better paradigms. But thats not what decides a programming language winner. A winner helps someone do X faster or with less effort. If better languages want to win they need to both be better, and be first to tackle niche X before a worse / familiar language does. And do it sufficiently significantly better to overcome the "familiarity benefit" a worse language will get that enters the same space. A not perfect example - typescript is almost the exact same language as JS and it took almost a decade for people to realize that unless you're writing small solo projects TS is better in just about every way. That is a best case scenario for comparison. Identical syntax, fully backwards compatible. On "language" a complete subset of the other (so no wars about losing a to gain be so is the trade off worth it), almost no new paradigm to learn and it still took our industry almost a decade to agree that it's universally better. If it takes that long to evaluate a clear cut case, its strong evidence that language benefit is not what primarilt drives language adoption. I've been around since the arguments about how Python would never be adopted because "white space was significant and that's a terrible syntax choice." That its distracting and takes mental focus. I've seen all the arguments. When a syntax is different it slows adoption drastically. Not because its worse but people we're humans. People don't like change. Then Python solved a need bettet then everything else and it took off. And once you use Python regularly you see how absurd those whitespace arguments were. JS and its approach took over because that's what the web was written in. If the language of the web had been chosen to be Lisp (as almost happened), everyone would be using Lisp right now without giving it a second thought.
fooofw 5y ago
This reminds me of the "Principle of Least Power" and variations [1, 2] in relation to the design of various languages of WWW. Although that is supposed to describe languages that are not programming languages. E.g. [1]: > Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person. [1] https://www.w3.org/DesignIssues/Principles.html#PLP https://www.w3.org/DesignIssues/Principles.html#PLP [2] https://www.w3.org/2001/tag/doc/leastPower.html https://www.w3.org/2001/tag/doc/leastPower.html
tikhonj 5y ago
> imperative programming is easy to understand by humans It's interesting that you choose C as an example because the absolutely immense numbers of bugs and security vulnerabilities directly due to C should, alone, lead us to question this. People might feel they understand C, but they're empirically wrong! We can argue about why this is the case or whether it applies to other imperative languages, but it's pretty depressing we're still arguing about whether it is the case...
- lordgrenville 5y ago
  > the absolutely immense numbers of bugs and security vulnerabilities directly due to C Isn't this simply a result of the absolutely immense amount of C being used in critical systems? Are functional languages empirically more secure?
  - chillpenguin 5y ago
    The immense number of C bugs is not merely due to C's popularity. Other languages lead to less buggy and more secure code. This is largely due to memory safety. However, immutability is also known to reduce bugs and be more secure (as many security related bugs are due to mutability). Lastly, superior concurrency constructs also have this bug-reducing effect. That said I haven't looked into empirical studies. But I feel like it is just factually the case, at least for memory safety, that in most other languages you literally are unable to create entire classes of bugs that are possible in C. So just logically thinking about it, I don't even see why you'd need to see empirical studies. It should be quite obvious! Although it'd be cool to see the empirical research too! Maybe someone else can reply with links to studies.
    - mpweiher 5y ago
      > But I feel like it is just factually the case, Aka truthiness. [1] Or when this is asserted for safety, safyness. [2] [1] https://en.wikipedia.org/wiki/Truthiness https://en.wikipedia.org/wiki/Truthiness [2] https://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html https://blog.metaobject.com/2014/06/the-safyness-of-static-t...
dgb23 5y ago
I read about this notion often and the deeper truth behind it seems to be that abstractions are hard and they tend to be harmful if done wrong. At the same time there are clear, obvious benefits of abstraction, which is why we don't typically write in machine code. This means that the goal is to create the right abstractions and not just throw our hands up in despair. Using the popularity of Go as a metric is interesting, because it is a language that was designed in an environment with very large amounts of code and high fluctuation. It was targeted at the programmers that are replaceable cogs in a very large system, so it has to accommodate the lowest common denominator. One of the great features of the language is how easy it is to learn. (But they went too far, leaving out parametric polymorphism which is a feature they are now working on for years.) Something that is easy to use and understand typically has a broader appeal. However, other environments want different things from programming languages. The appeal of a Lisp for example is its expressive power, programming expertise scales with the language more strongly. At the other end of the spectrum we have languages like Rust and statically typed functional languages that have very strong guardrails, stronger runtime guarantees can be made in exchange for agility. Again, certain types of programmers who face certain problems are drawn to these. So creating good abstractions is both hard and desirable and programming languages are itself abstractions and facilitate the creation of abstractions. But what is a "good" abstraction depends entirely on perspective, which includes problems, domains and people. This is why languages like Lisp are not going away, languages like Go are popular and why there is plenty of diversity in language design.
goatlover 5y ago
But then again, C++ has been top 5 TIOBE since the index began. And C++ is the poster child for complexity.
- deleted 5y ago
  [deleted]
pjmlp 5y ago
> Well, I have. I want languages more like Go and Zig. People will always hate at least Go, but it didn't hit TIOBE top 10 out of sheer baseless hype and corporate sponsorship. Given how succesfull Oberon-2 and Limbo have been in the market without someone like Google behind them, or having a biased Go advocate at the same company push for a project rewrite from Java into Go, yes it did.

by jchw 5y ago

BoiledCabbage 5y ago

Programming languages don't win because they are inherently better. Programming languages win because they fill a need better, or are more familiar. There are better languages than other, that help people to write better code, have bugs be easier to find, push better paradigms. But thats not what decides a programming language winner. A winner helps someone do X faster or with less effort. If better languages want to win they need to both be better, and be first to tackle niche X before a worse / familiar language does. And do it sufficiently significantly better to overcome the "familiarity benefit" a worse language will get that enters the same space. A not perfect example - typescript is almost the exact same language as JS and it took almost a decade for people to realize that unless you're writing small solo projects TS is better in just about every way. That is a best case scenario for comparison. Identical syntax, fully backwards compatible. On "language" a complete subset of the other (so no wars about losing a to gain be so is the trade off worth it), almost no new paradigm to learn and it still took our industry almost a decade to agree that it's universally better. If it takes that long to evaluate a clear cut case, its strong evidence that language benefit is not what primarilt drives language adoption. I've been around since the arguments about how Python would never be adopted because "white space was significant and that's a terrible syntax choice." That its distracting and takes mental focus. I've seen all the arguments. When a syntax is different it slows adoption drastically. Not because its worse but people we're humans. People don't like change. Then Python solved a need bettet then everything else and it took off. And once you use Python regularly you see how absurd those whitespace arguments were. JS and its approach took over because that's what the web was written in. If the language of the web had been chosen to be Lisp (as almost happened), everyone would be using Lisp right now without giving it a second thought.

fooofw 5y ago

This reminds me of the "Principle of Least Power" and variations [1, 2] in relation to the design of various languages of WWW. Although that is supposed to describe languages that are not programming languages. E.g. [1]: > Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person. [1] https://www.w3.org/DesignIssues/Principles.html#PLP https://www.w3.org/DesignIssues/Principles.html#PLP [2] https://www.w3.org/2001/tag/doc/leastPower.html https://www.w3.org/2001/tag/doc/leastPower.html

tikhonj 5y ago

> imperative programming is easy to understand by humans It's interesting that you choose C as an example because the absolutely immense numbers of bugs and security vulnerabilities directly due to C should, alone, lead us to question this. People might feel they understand C, but they're empirically wrong! We can argue about why this is the case or whether it applies to other imperative languages, but it's pretty depressing we're still arguing about whether it is the case...

lordgrenville 5y ago
> the absolutely immense numbers of bugs and security vulnerabilities directly due to C Isn't this simply a result of the absolutely immense amount of C being used in critical systems? Are functional languages empirically more secure?
- chillpenguin 5y ago
  The immense number of C bugs is not merely due to C's popularity. Other languages lead to less buggy and more secure code. This is largely due to memory safety. However, immutability is also known to reduce bugs and be more secure (as many security related bugs are due to mutability). Lastly, superior concurrency constructs also have this bug-reducing effect. That said I haven't looked into empirical studies. But I feel like it is just factually the case, at least for memory safety, that in most other languages you literally are unable to create entire classes of bugs that are possible in C. So just logically thinking about it, I don't even see why you'd need to see empirical studies. It should be quite obvious! Although it'd be cool to see the empirical research too! Maybe someone else can reply with links to studies.
  - mpweiher 5y ago
    > But I feel like it is just factually the case, Aka truthiness. [1] Or when this is asserted for safety, safyness. [2] [1] https://en.wikipedia.org/wiki/Truthiness https://en.wikipedia.org/wiki/Truthiness [2] https://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html https://blog.metaobject.com/2014/06/the-safyness-of-static-t...

dgb23 5y ago

I read about this notion often and the deeper truth behind it seems to be that abstractions are hard and they tend to be harmful if done wrong. At the same time there are clear, obvious benefits of abstraction, which is why we don't typically write in machine code. This means that the goal is to create the right abstractions and not just throw our hands up in despair. Using the popularity of Go as a metric is interesting, because it is a language that was designed in an environment with very large amounts of code and high fluctuation. It was targeted at the programmers that are replaceable cogs in a very large system, so it has to accommodate the lowest common denominator. One of the great features of the language is how easy it is to learn. (But they went too far, leaving out parametric polymorphism which is a feature they are now working on for years.) Something that is easy to use and understand typically has a broader appeal. However, other environments want different things from programming languages. The appeal of a Lisp for example is its expressive power, programming expertise scales with the language more strongly. At the other end of the spectrum we have languages like Rust and statically typed functional languages that have very strong guardrails, stronger runtime guarantees can be made in exchange for agility. Again, certain types of programmers who face certain problems are drawn to these. So creating good abstractions is both hard and desirable and programming languages are itself abstractions and facilitate the creation of abstractions. But what is a "good" abstraction depends entirely on perspective, which includes problems, domains and people. This is why languages like Lisp are not going away, languages like Go are popular and why there is plenty of diversity in language design.

goatlover 5y ago

But then again, C++ has been top 5 TIOBE since the index began. And C++ is the poster child for complexity.

deleted 5y ago
[deleted]

pjmlp 5y ago

> Well, I have. I want languages more like Go and Zig. People will always hate at least Go, but it didn't hit TIOBE top 10 out of sheer baseless hype and corporate sponsorship. Given how succesfull Oberon-2 and Limbo have been in the market without someone like Google behind them, or having a biased Go advocate at the same company push for a project rewrite from Java into Go, yes it did.