5 ms·

There's an old quote, "Greenspun's tenth rule" https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule :

by retrac 7y ago

There's an old quote, "Greenspun's tenth rule" https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule : "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

turk73 7y ago
Unlike LISP, C is still #2 on TIOBE vs. LISP which is #27, aka no place.
Const-me 7y ago
An old quote indeed. In modern world, any sufficiently complicated C or C++ program embeds a runtime of some higher level language. More often than not, that language is formally specified, well-supported, and fast. Sometimes it’s indeed LISP like in AutoCAD, but more popular choices are JavaScript (all web browsers), LUA (many video games and much more, see Wireshark), Python, VBScript or VBA (older Windows software), .NET runtime (current Windows software and some cross-platform as well, like Unity3D game engine). These days, it’s rarely a custom language runtime, but it still happens, like Matlab.
- deleted 7y ago
  [deleted]
- d33 7y ago
  Which of those is actually formally specified? Also, calling Python or JavaScript any effieicnt sounds a bit unwarranted. Consider any JavaScript desktop application, its power and memory usage... it's a mess.
  - anchpop 7y ago
    > Consider any JavaScript desktop application, its power and memory usage... it's a mess. I'm running VSCode right now with many tabs open and extensions running, and it's using less than 100mb of memory. Doesn't seem so bad to me
    - diego_moita 7y ago
      > using less than 100mb of memory. Doesn't seem so bad to me You know... any embedded programmer reading that comment is probably laughing hysterically. In most cheap or energy efficient microcontrolers, more than 4 Mb is considered a luxury.
      - lispm 7y ago
        A friend of mine has been developing a small Lisp which starts at 2Kbytes RAM: http://www.ulisp.com http://www.ulisp.com
      - airza 7y ago
        I mean sure, but he's talking about desktop applications.
      - Const-me 7y ago
        Depends on the exact numbers. For instance, Allwinner R328 chip has 2 ARM cores running up to 1.2GHz, includes 64MB or 128MB RAM, and the price is around $3.
      - UncleMeat 7y ago
        Ok. There is no virtue in using less memory for the sake of it. If a desktop application is taking 100mb, you can have a lot of those running before modern boxes start to struggle.
        deleted 7y ago
        [deleted]
      - mntmoss 7y ago
        Whether 100Mb usage is unacceptably large is mostly dependent on the precise features in play: * 32-bit vs 64-bit application(64 bit will bloat all pointers) * Methods of loading and editing documents(modern editing attempts a lot of introspection based on highlighting syntax or project environment) * Character encoding support(Supporting current Unicode rendering would almost immediately take you beyond 4Mb) Interactive editing is a pretty memory-hungry task compared to a simple viewer or batch processor. There's more reason to keep things cached. If you actually go back to old text editor versions from the days of 4Mb desktops, you'll find yourself missing stuff. Not so much that you can't get by, but enough to give pause and consider taking the hit.
  - Const-me 7y ago
    > Which of those is actually formally specified? Many of them are international standards, see ANSI INCITS 226-1994 for LISP, ECMA-262 and ISO/IEC 16262 for JavaScript, ECMA-334 and ISO/IEC 23270:2018 for C#. Lua and Python aren’t standardized, but even so, they both have a comprehensive formal spec. > calling Python or JavaScript any efficient sounds a bit unwarranted Both are much slower at number crunching compared to C or C++ but they aren’t that bad, either. Most JavaScript VMs feature a good JIT compiler. Some Python runtimes have JIT too. > Consider any JavaScript desktop application, its power and memory usage. There’re good ones, like VSCode. On average they’re indeed not great, but I think it’s just an unfortunate consequence of low entry barrier. It’s easy for inexperience people to get started with the technology. And the ecosystem is misjudged based on the output of these inexperienced developers.
    - jacquesm 7y ago
      Python is actually scary fast because anybody that uses it for serious numerical work will use numpy.
      - jkoudys 7y ago
        ie "python is scary fast because anyone who uses it is mostly running C"
        jacquesm 7y ago
        Yep. This goes for a lot of environments. It's going to take many many decades to get rid of C. Probably more than it has been here up to now.
        jkoudys 7y ago
        Doesn't always mean it's particularly performant, unfortunately. The JSON lib in PHP is still C (part of Zend), but it's very susceptible to malloc failures (one big contiguous request for the whole shebang), and it's generally way faster to serialize arrays into a .PHP file you load than into JSON if you're storing it locally. I compared what I read there to the serde stuff for rust and the difference is stark. Maybe having most of this stuff in c libs with scripts wrapped around them will make it easier to migrate. Keep the same py but swap out the lib from C to some rust that's still useful in a crate for pure rust projects.
- coldtea 7y ago
  >In modern world, any sufficiently complicated C or C++ program embeds a runtime of some higher level language. More often than not, that language is formally specified, well-supported, and fast. More often than not? Almost none of the languages mentioned are "formally specified", and most of them are hardly fast either...
  - Const-me 7y ago
    > Almost none of the languages mentioned are "formally specified" They all have written specs. Many of them even have these specs standardized, see ANSI INCITS 226-1994, ISO/IEC 16262 and ISO/IEC 23270:2018. > most of them are hardly fast either It’s borderline impossible to be fast compared to C or C++. By that statement I meant 2 things. (1) They’re likely to be much faster compared to whatever ad-hoc equivalent is doable within reasonable budget. People spent tons of resources improving these runtimes and their JITs, it’s very expensive to do something comparable. (2) On modern hardware, their performance is now adequate for many practical uses. This is true even for resource-constrained applications like videogames or embedded/mobile software, which were overwhelmingly dominated by C or C++ couple decades ago.
FpUser 7y ago
Sure, sure. "...there is but one God, the Father, from whom all things came ..."
- zbentley 7y ago
  BCPL?
fsckboy 7y ago
the first rule with no spin: "Any portable, formally-specified, bug-free, quick implementation of all of Common Lisp contains at its core a fair amount of nicely indented C."

by retrac 7y ago

turk73 7y ago

Unlike LISP, C is still #2 on TIOBE vs. LISP which is #27, aka no place.

Const-me 7y ago

An old quote indeed. In modern world, any sufficiently complicated C or C++ program embeds a runtime of some higher level language. More often than not, that language is formally specified, well-supported, and fast. Sometimes it’s indeed LISP like in AutoCAD, but more popular choices are JavaScript (all web browsers), LUA (many video games and much more, see Wireshark), Python, VBScript or VBA (older Windows software), .NET runtime (current Windows software and some cross-platform as well, like Unity3D game engine). These days, it’s rarely a custom language runtime, but it still happens, like Matlab.

deleted 7y ago
[deleted]
d33 7y ago
Which of those is actually formally specified? Also, calling Python or JavaScript any effieicnt sounds a bit unwarranted. Consider any JavaScript desktop application, its power and memory usage... it's a mess.
- anchpop 7y ago
  > Consider any JavaScript desktop application, its power and memory usage... it's a mess. I'm running VSCode right now with many tabs open and extensions running, and it's using less than 100mb of memory. Doesn't seem so bad to me
  - diego_moita 7y ago
    > using less than 100mb of memory. Doesn't seem so bad to me You know... any embedded programmer reading that comment is probably laughing hysterically. In most cheap or energy efficient microcontrolers, more than 4 Mb is considered a luxury.
    - lispm 7y ago
      A friend of mine has been developing a small Lisp which starts at 2Kbytes RAM: http://www.ulisp.com http://www.ulisp.com
    - airza 7y ago
      I mean sure, but he's talking about desktop applications.
    - Const-me 7y ago
      Depends on the exact numbers. For instance, Allwinner R328 chip has 2 ARM cores running up to 1.2GHz, includes 64MB or 128MB RAM, and the price is around $3.
    - UncleMeat 7y ago
      Ok. There is no virtue in using less memory for the sake of it. If a desktop application is taking 100mb, you can have a lot of those running before modern boxes start to struggle.
      - deleted 7y ago
        [deleted]
    - mntmoss 7y ago
      Whether 100Mb usage is unacceptably large is mostly dependent on the precise features in play: * 32-bit vs 64-bit application(64 bit will bloat all pointers) * Methods of loading and editing documents(modern editing attempts a lot of introspection based on highlighting syntax or project environment) * Character encoding support(Supporting current Unicode rendering would almost immediately take you beyond 4Mb) Interactive editing is a pretty memory-hungry task compared to a simple viewer or batch processor. There's more reason to keep things cached. If you actually go back to old text editor versions from the days of 4Mb desktops, you'll find yourself missing stuff. Not so much that you can't get by, but enough to give pause and consider taking the hit.
- Const-me 7y ago
  > Which of those is actually formally specified? Many of them are international standards, see ANSI INCITS 226-1994 for LISP, ECMA-262 and ISO/IEC 16262 for JavaScript, ECMA-334 and ISO/IEC 23270:2018 for C#. Lua and Python aren’t standardized, but even so, they both have a comprehensive formal spec. > calling Python or JavaScript any efficient sounds a bit unwarranted Both are much slower at number crunching compared to C or C++ but they aren’t that bad, either. Most JavaScript VMs feature a good JIT compiler. Some Python runtimes have JIT too. > Consider any JavaScript desktop application, its power and memory usage. There’re good ones, like VSCode. On average they’re indeed not great, but I think it’s just an unfortunate consequence of low entry barrier. It’s easy for inexperience people to get started with the technology. And the ecosystem is misjudged based on the output of these inexperienced developers.
  - jacquesm 7y ago
    Python is actually scary fast because anybody that uses it for serious numerical work will use numpy.
    - jkoudys 7y ago
      ie "python is scary fast because anyone who uses it is mostly running C"
      - jacquesm 7y ago
        Yep. This goes for a lot of environments. It's going to take many many decades to get rid of C. Probably more than it has been here up to now.
        jkoudys 7y ago
        Doesn't always mean it's particularly performant, unfortunately. The JSON lib in PHP is still C (part of Zend), but it's very susceptible to malloc failures (one big contiguous request for the whole shebang), and it's generally way faster to serialize arrays into a .PHP file you load than into JSON if you're storing it locally. I compared what I read there to the serde stuff for rust and the difference is stark. Maybe having most of this stuff in c libs with scripts wrapped around them will make it easier to migrate. Keep the same py but swap out the lib from C to some rust that's still useful in a crate for pure rust projects.
coldtea 7y ago
>In modern world, any sufficiently complicated C or C++ program embeds a runtime of some higher level language. More often than not, that language is formally specified, well-supported, and fast. More often than not? Almost none of the languages mentioned are "formally specified", and most of them are hardly fast either...
- Const-me 7y ago
  > Almost none of the languages mentioned are "formally specified" They all have written specs. Many of them even have these specs standardized, see ANSI INCITS 226-1994, ISO/IEC 16262 and ISO/IEC 23270:2018. > most of them are hardly fast either It’s borderline impossible to be fast compared to C or C++. By that statement I meant 2 things. (1) They’re likely to be much faster compared to whatever ad-hoc equivalent is doable within reasonable budget. People spent tons of resources improving these runtimes and their JITs, it’s very expensive to do something comparable. (2) On modern hardware, their performance is now adequate for many practical uses. This is true even for resource-constrained applications like videogames or embedded/mobile software, which were overwhelmingly dominated by C or C++ couple decades ago.

FpUser 7y ago

Sure, sure. "...there is but one God, the Father, from whom all things came ..."

zbentley 7y ago
BCPL?

fsckboy 7y ago

the first rule with no spin: "Any portable, formally-specified, bug-free, quick implementation of all of Common Lisp contains at its core a fair amount of nicely indented C."