11 ms·

I think the point of a high-level language is to make your programs shorter. All other things (e.g. libraries) being equal, language A is better than language B

by pg 7y ago

I think the point of a high-level language is to make your programs shorter. All other things (e.g. libraries) being equal, language A is better than language B if programs are shorter in A. (As measured by the size of the parse tree, obviously, not lines or characters.) The goal of Bel is to be a good language. This can be measured in the length of programs written in it. Lisp dialects have as a rule been good at making programs short. Bel is meant to do the same sorts of things previous dialects have, but more so. It's also meant to be simple and clear. If you want to understand Bel's semantics, you can read the source.

agumonkey 7y ago
Hello, do you think you could find time make a table of content ? I like .txt files but a language spec is just a tad too long. Or maybe for the lispers around have a short summary of what was inspiring you to make bel after arc ? what were your ideas, problems (beside making programs more expressive shorter). Thanks
cousin_it 7y ago
Thanks for the response! Which features of Bel do you think will contribute the most to making programs shorter or clearer, compared to other Lisp dialects?
- pg 7y ago
  It's so broadly the goal of the language that many things do, often in small ways. For example, it turns out to be really convenient that strings are simply lists of characters. It means all the list manipulation functions just work on them. And the where special form and zap macro make it much easier to define operators that modify things. The advantage of Bel is a lot of small things like that rather than a single killer feature. Making bel.bel shorter was one of my main goals during this project. It has a double benefit. Since the Bel source is a Bel program, the shorter I can make it, the more powerful Bel must be. Plus a shorter source is (pathological coding tricks excepted) easier to understand, which means Bel is better in that way too. There were many days when I'd make bel.bel 5 lines shorter and consider it a successful day's work. One of the things I found helped most in making programs shorter was higher order functions. These let you get rid of variables, which are a particularly good thing to eliminate from code when you can. I found that higher order functions combined with intrasymbol syntax could often collapse something that had been a 4 line def into a 1 line set.
  - notduncansmith 7y ago
    > For example, it turns out to be really convenient that strings are simply lists of characters. It means all the list manipulation functions just work on them. Why is it preferable to couple the internal implementation of strings to the interface “a list of characters”? Also, since “character” can be an imprecise term, what is a character in Bel?
    - fao_ 7y ago
      > Also, since “character” can be an imprecise term, what is a character in Bel? Exactly. How is unicode and UTF-8 treated by this language?
      - jdc 7y ago
        While we're down here in the weeds[0]... A good way to do it IMO, is for each character to be unicode grapheme cluster[2]. 0. "This is not a language you can use to program computers, just as the Lisp in the 1960 paper wasn't."[1] 1. https://sep.yimg.com/ty/cdn/paulgraham/bellanguage.txt?t=1570888282 https://sep.yimg.com/ty/cdn/paulgraham/bellanguage.txt?t=157... 2. http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Bounda...
        fao_ 7y ago
        > A good way to do it IMO, is for each character to be unicode grapheme cluster[2]. I would agree. However, for the sake of argument, The width of a grapheme cluster depends on whether something is an emoji or not, which for flags, depends on the current state of the world. The combining characters (u)(k) are valid as one single grapheme cluster (a depiction of the UK's flag), which is not valid if the UK splits up, for example. This is only one single example, there are many others, that demonstrate that there is basically no 'good' representation of 'a character' in a post-UTF8 world.
        jdc 7y ago
dkersten 7y ago
"language A is better than language B if programs are shorter in A", so something like APL (not the weird characters, but rather the way each operator operates on entire arrays, and naturally chain together) or maybe Forth (or Factor, for a more modern Forth), since they are a bit more general (I've never heard of a website being built in an array-oriented language, for example) would be the holy grail?
Liron 7y ago
Ya, here's why I think "make your programs shorter" is a good criterion. If a language compresses conceivably-desirable programs to a smaller AST size, then for all N, a higher fraction of size-N ASTs (compared to other languages) represent conceivably-desirable programs. So "make your programs shorter" also implies "make bad behaviors impossible or extra-verbose to write". For example, failing to free your memory is bad code, and it's impossible(ish) to write in managed-memory languages.
- jstimpfle 7y ago
  Make your programs as short as possible, but no shorter. Failing to free your memory makes for a shorter program. Using GC makes for a shorter program, but there is a whole class of problems that just can't be solved with GC.
  - badatshipping 7y ago
    I think deciding to not free your memory or use GC (instead of not) would count as having a different program.
- LrnByTeach 7y ago
  > So "make your programs shorter" also implies "make bad behaviors impossible or extra-verbose to write". It reminds me "The Zen of Python" "There should be one — and preferably only one — obvious way to do it" https://jeffknupp.com/blog/2018/10/11/write-better-python-functions/ https://jeffknupp.com/blog/2018/10/11/write-better-python-fu... https://towardsdatascience.com/how-to-be-pythonic-and-why-you-should-care-188d63a5037e https://towardsdatascience.com/how-to-be-pythonic-and-why-yo...
jblow 7y ago
I have to disagree; this is very clearly too simplistic. There are many dimensions in which a language can be better or worse. Things like: * How debuggable is it? * Do most errors get caught at compile time, or do they require that code path to be exercised? * How understandable are programs to new people who come along? To yourself, N years later? * How error-prone are the syntax and semantics (i.e. how close is the thing you intended, to something discontinuous that is wrong, that won't be detected until much later, and that doesn't look much different, so you won't spot the bug)? * How much development friction does it bring (in terms of steps required to develop, run, and debug your program) ... this sounds like a tools issue that is orthogonal to language design, but in reality it is not. * What are the mood effects of programming in the language? Do you feel like your effort is resulting in productive things all the time, or do you feel like you are doing useless busywork very often? (I am looking at you, C++.) You can argue this is the same thing as programs being shorter, but I don't believe it is. (It is not orthogonal though). * What is your overall morale of the code's correctness over time? Does the language allow you to have high confidence that what you mean to happen is what is really happening, or are you in a perpetual semi-confused state? I would weigh concision as a lower priority than all of these, and probably several others I haven't listed.
- behnamoh 7y ago
  I have a feeling this post got way more upvotes than it really deserves, partly because, duh, it's pg we're talking about. Many other languages have been introduced here (e.g. Hy) that actually solve new problems or have a deeper existential reasons, not just to "shorten stuff".
  - bachmeier 7y ago
    "Many other languages have been introduced here (e.g. Hy) that actually solve new problems" Adding s-expression syntax to Python solves an important program?
    - behnamoh 7y ago
      Don't take my sentence out of context. My sentence continues to state "or ..." which you clearly don't want to understand.
kizer 7y ago
Well, for high-level languages like you say. I guess you could say for two languages of the same “abstraction level class”, as terseness would be valued in two low level languages as well - from the humans POV, though! Since this is all related to easier conceptual expression.
kizer 7y ago
Also don’t brains pursue an analogous, maximally compressed encoding of information via the use of abstractions/ideals and heuristics of probably many many kinds (of course lossy compression would evolve over a “lossless” compression which would grant minimal gains over lossy and be much more sophisticated/energy expensive)? I wonder if psychology in this topic could inform programming language design as to a “natural” step-size of abstraction, or an optimal parse-tree measure which would correspond to an equivalent mental model.
magicmouse 7y ago
I disagree that measuring program length by the size of the parse tree is a good measure of conciseness. To an author and reader, it is the number of words you read that matters, so i use word count as the benchmark value. People who write newspaper articles are given a word count to hit, you type a certain number of words per minute, and people read at a certain speed. So words are the units of measurement that are easily counted and there will be no dispute. A parse tree is not particularly comparable between languages; most modern languages make extensive use of powerful runtimes to handle complex things that are part of the OS. There is typically over a million lines of code behind a simple text entry field. In my Beads language for example, i go to great lengths to allow declarations to have a great deal of power, but they are not executable code, and thus have hardly any errors. Lisp is not a particularly declarative type of language and is thus more error prone. The more code you don't execute the more reliable the software will be, so declarative programming is even better than Lisp. Lisp derivative languages are notorious for their poor readability; hence the avoidance of Lisp by companies who fear "read-only" code bases that cannot be transferred to a new person. Lisp, Forth, APL, all win contests for fewest characters, but lose when it comes to the transfer phase. But like a bad penny, Lisp keeps coming back over and over, and it always will, because 2nd level programming, where you modify the program (creating your own domain specific language basically for each app), is the standard operating methodology of Lisp programmers. That one cannot understand this domain specific language without executing the code makes Lisp very unsuitable for commercial use. Yes there are a few notable successful commercial products (AutoCad) that used Lisp to great results, but for the next 5-10 million programmers coming on board in the next few years, I laugh at anyone with the audacity to imagine that Lisp would be remotely suitable. Lisp is an archaic language is so many ways. It cannot run backwards. It has no concept of drawing; it is firmly rooted in the terminal/console era from which it sprang. With no database or graphics or event model, you have to use API's that are not standardized to make any graphical interactive products, which is what the majority of programmers are making.
- lispm 7y ago
  > i use word count as the benchmark value Words are called 'symbols' in Lisp. Making extremely expressive domain level constructs is reducing the code size a lot in larger Lisp programs. > Lisp is not a particularly declarative type of language Just the opposite. Lisp is one of the major tools to write declarative code. The declarations are a part of the running system and can be queried&changed while the program is running. > Lisp ... all win contests for fewest characters, Most Lisp since the end 70s don't care about character count. Lisp usually uses very descriptive symbols as operator names. Lisp users invented machines with larger memory sizes in the late 70s, to get rid of limitations in code and data size. Paul Graham is favoring low-character count code, but this is not representative for general Lisp code, which favors low-symbol count code through expressive constructs. > understand this domain specific language without executing the code the languages will be documented and will be operators in the language. Other programming languages also create large vocabularities, but in different ways. Lisp makes it easy to integrate syntactic abstractions in the software, without the need to write external languages, which many other systems need to do. For example one can see the Common Lisp Object System as a domain-specific extension to write object-oriented code in Lisp. It's constructs are well documented and widely use in Lisp. > it/is firmly routed in the terminal/console era... Use of a Lisp Machine in the 80s: https://youtu.be/gV5obrYaogU https://youtu.be/gV5obrYaogU Interactive graphical systems were early used in Lisp since the 70s. There is a long tradition of graphical systems written in Lisp. For example PTC sells a 3d design system written with a C++ kernel and a few million lines of Lisp code: https://www.ptc.com/-/media/Files/PDFs/CAD/Creo/creo-elements-direct-5-19.pdf?la=en&hash=9D9E51DAC0A1B291F2807B661109DD90 https://www.ptc.com/-/media/Files/PDFs/CAD/Creo/creo-element...

by pg 7y ago

agumonkey 7y ago

Hello, do you think you could find time make a table of content ? I like .txt files but a language spec is just a tad too long. Or maybe for the lispers around have a short summary of what was inspiring you to make bel after arc ? what were your ideas, problems (beside making programs more expressive shorter). Thanks

cousin_it 7y ago

Thanks for the response! Which features of Bel do you think will contribute the most to making programs shorter or clearer, compared to other Lisp dialects?

pg 7y ago
It's so broadly the goal of the language that many things do, often in small ways. For example, it turns out to be really convenient that strings are simply lists of characters. It means all the list manipulation functions just work on them. And the where special form and zap macro make it much easier to define operators that modify things. The advantage of Bel is a lot of small things like that rather than a single killer feature. Making bel.bel shorter was one of my main goals during this project. It has a double benefit. Since the Bel source is a Bel program, the shorter I can make it, the more powerful Bel must be. Plus a shorter source is (pathological coding tricks excepted) easier to understand, which means Bel is better in that way too. There were many days when I'd make bel.bel 5 lines shorter and consider it a successful day's work. One of the things I found helped most in making programs shorter was higher order functions. These let you get rid of variables, which are a particularly good thing to eliminate from code when you can. I found that higher order functions combined with intrasymbol syntax could often collapse something that had been a 4 line def into a 1 line set.
- notduncansmith 7y ago
  > For example, it turns out to be really convenient that strings are simply lists of characters. It means all the list manipulation functions just work on them. Why is it preferable to couple the internal implementation of strings to the interface “a list of characters”? Also, since “character” can be an imprecise term, what is a character in Bel?
  - fao_ 7y ago
    > Also, since “character” can be an imprecise term, what is a character in Bel? Exactly. How is unicode and UTF-8 treated by this language?
    - jdc 7y ago
      While we're down here in the weeds[0]... A good way to do it IMO, is for each character to be unicode grapheme cluster[2]. 0. "This is not a language you can use to program computers, just as the Lisp in the 1960 paper wasn't."[1] 1. https://sep.yimg.com/ty/cdn/paulgraham/bellanguage.txt?t=1570888282 https://sep.yimg.com/ty/cdn/paulgraham/bellanguage.txt?t=157... 2. http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Bounda...
      - fao_ 7y ago
        > A good way to do it IMO, is for each character to be unicode grapheme cluster[2]. I would agree. However, for the sake of argument, The width of a grapheme cluster depends on whether something is an emoji or not, which for flags, depends on the current state of the world. The combining characters (u)(k) are valid as one single grapheme cluster (a depiction of the UK's flag), which is not valid if the UK splits up, for example. This is only one single example, there are many others, that demonstrate that there is basically no 'good' representation of 'a character' in a post-UTF8 world.
        jdc 7y ago

dkersten 7y ago

"language A is better than language B if programs are shorter in A", so something like APL (not the weird characters, but rather the way each operator operates on entire arrays, and naturally chain together) or maybe Forth (or Factor, for a more modern Forth), since they are a bit more general (I've never heard of a website being built in an array-oriented language, for example) would be the holy grail?

Liron 7y ago

Ya, here's why I think "make your programs shorter" is a good criterion. If a language compresses conceivably-desirable programs to a smaller AST size, then for all N, a higher fraction of size-N ASTs (compared to other languages) represent conceivably-desirable programs. So "make your programs shorter" also implies "make bad behaviors impossible or extra-verbose to write". For example, failing to free your memory is bad code, and it's impossible(ish) to write in managed-memory languages.

jstimpfle 7y ago
Make your programs as short as possible, but no shorter. Failing to free your memory makes for a shorter program. Using GC makes for a shorter program, but there is a whole class of problems that just can't be solved with GC.
- badatshipping 7y ago
  I think deciding to not free your memory or use GC (instead of not) would count as having a different program.
LrnByTeach 7y ago
> So "make your programs shorter" also implies "make bad behaviors impossible or extra-verbose to write". It reminds me "The Zen of Python" "There should be one — and preferably only one — obvious way to do it" https://jeffknupp.com/blog/2018/10/11/write-better-python-functions/ https://jeffknupp.com/blog/2018/10/11/write-better-python-fu... https://towardsdatascience.com/how-to-be-pythonic-and-why-you-should-care-188d63a5037e https://towardsdatascience.com/how-to-be-pythonic-and-why-yo...

jblow 7y ago

I have to disagree; this is very clearly too simplistic. There are many dimensions in which a language can be better or worse. Things like: * How debuggable is it? * Do most errors get caught at compile time, or do they require that code path to be exercised? * How understandable are programs to new people who come along? To yourself, N years later? * How error-prone are the syntax and semantics (i.e. how close is the thing you intended, to something discontinuous that is wrong, that won't be detected until much later, and that doesn't look much different, so you won't spot the bug)? * How much development friction does it bring (in terms of steps required to develop, run, and debug your program) ... this sounds like a tools issue that is orthogonal to language design, but in reality it is not. * What are the mood effects of programming in the language? Do you feel like your effort is resulting in productive things all the time, or do you feel like you are doing useless busywork very often? (I am looking at you, C++.) You can argue this is the same thing as programs being shorter, but I don't believe it is. (It is not orthogonal though). * What is your overall morale of the code's correctness over time? Does the language allow you to have high confidence that what you mean to happen is what is really happening, or are you in a perpetual semi-confused state? I would weigh concision as a lower priority than all of these, and probably several others I haven't listed.

behnamoh 7y ago
I have a feeling this post got way more upvotes than it really deserves, partly because, duh, it's pg we're talking about. Many other languages have been introduced here (e.g. Hy) that actually solve new problems or have a deeper existential reasons, not just to "shorten stuff".
- bachmeier 7y ago
  "Many other languages have been introduced here (e.g. Hy) that actually solve new problems" Adding s-expression syntax to Python solves an important program?
  - behnamoh 7y ago
    Don't take my sentence out of context. My sentence continues to state "or ..." which you clearly don't want to understand.

kizer 7y ago

Well, for high-level languages like you say. I guess you could say for two languages of the same “abstraction level class”, as terseness would be valued in two low level languages as well - from the humans POV, though! Since this is all related to easier conceptual expression.

kizer 7y ago

Also don’t brains pursue an analogous, maximally compressed encoding of information via the use of abstractions/ideals and heuristics of probably many many kinds (of course lossy compression would evolve over a “lossless” compression which would grant minimal gains over lossy and be much more sophisticated/energy expensive)? I wonder if psychology in this topic could inform programming language design as to a “natural” step-size of abstraction, or an optimal parse-tree measure which would correspond to an equivalent mental model.

magicmouse 7y ago

I disagree that measuring program length by the size of the parse tree is a good measure of conciseness. To an author and reader, it is the number of words you read that matters, so i use word count as the benchmark value. People who write newspaper articles are given a word count to hit, you type a certain number of words per minute, and people read at a certain speed. So words are the units of measurement that are easily counted and there will be no dispute. A parse tree is not particularly comparable between languages; most modern languages make extensive use of powerful runtimes to handle complex things that are part of the OS. There is typically over a million lines of code behind a simple text entry field. In my Beads language for example, i go to great lengths to allow declarations to have a great deal of power, but they are not executable code, and thus have hardly any errors. Lisp is not a particularly declarative type of language and is thus more error prone. The more code you don't execute the more reliable the software will be, so declarative programming is even better than Lisp. Lisp derivative languages are notorious for their poor readability; hence the avoidance of Lisp by companies who fear "read-only" code bases that cannot be transferred to a new person. Lisp, Forth, APL, all win contests for fewest characters, but lose when it comes to the transfer phase. But like a bad penny, Lisp keeps coming back over and over, and it always will, because 2nd level programming, where you modify the program (creating your own domain specific language basically for each app), is the standard operating methodology of Lisp programmers. That one cannot understand this domain specific language without executing the code makes Lisp very unsuitable for commercial use. Yes there are a few notable successful commercial products (AutoCad) that used Lisp to great results, but for the next 5-10 million programmers coming on board in the next few years, I laugh at anyone with the audacity to imagine that Lisp would be remotely suitable. Lisp is an archaic language is so many ways. It cannot run backwards. It has no concept of drawing; it is firmly rooted in the terminal/console era from which it sprang. With no database or graphics or event model, you have to use API's that are not standardized to make any graphical interactive products, which is what the majority of programmers are making.

lispm 7y ago
> i use word count as the benchmark value Words are called 'symbols' in Lisp. Making extremely expressive domain level constructs is reducing the code size a lot in larger Lisp programs. > Lisp is not a particularly declarative type of language Just the opposite. Lisp is one of the major tools to write declarative code. The declarations are a part of the running system and can be queried&changed while the program is running. > Lisp ... all win contests for fewest characters, Most Lisp since the end 70s don't care about character count. Lisp usually uses very descriptive symbols as operator names. Lisp users invented machines with larger memory sizes in the late 70s, to get rid of limitations in code and data size. Paul Graham is favoring low-character count code, but this is not representative for general Lisp code, which favors low-symbol count code through expressive constructs. > understand this domain specific language without executing the code the languages will be documented and will be operators in the language. Other programming languages also create large vocabularities, but in different ways. Lisp makes it easy to integrate syntactic abstractions in the software, without the need to write external languages, which many other systems need to do. For example one can see the Common Lisp Object System as a domain-specific extension to write object-oriented code in Lisp. It's constructs are well documented and widely use in Lisp. > it/is firmly routed in the terminal/console era... Use of a Lisp Machine in the 80s: https://youtu.be/gV5obrYaogU https://youtu.be/gV5obrYaogU Interactive graphical systems were early used in Lisp since the 70s. There is a long tradition of graphical systems written in Lisp. For example PTC sells a 3d design system written with a C++ kernel and a few million lines of Lisp code: https://www.ptc.com/-/media/Files/PDFs/CAD/Creo/creo-elements-direct-5-19.pdf?la=en&hash=9D9E51DAC0A1B291F2807B661109DD90 https://www.ptc.com/-/media/Files/PDFs/CAD/Creo/creo-element...