10 ms·

Extreme syntax

51 points by prajjwal 13y ago

innguest 13y ago
"What if programming notation were more like music notation?" -> if you look at the denotational semantics listings on the latest Scheme Reports you will see something that could be equated to music notation (i.e. they're both instructions on how something should work, and they're sufficient information to get there). I oftentimes think about these same issues regarding the syntax of different languages. I work in Ruby and I think it's a comfortable language to express ideas in. Scheme is also comfortable and I like it more conceptually, since it gives me this strange comfort of thinking "well, if Scheme disappears forever, at least I have books that can help me make another one", which I never think of languages like Ruby and Perl. That's why I'm now finally learning Perl; I want to have a better perspective on what I actually like. If it turns out I'm a thousand times more comfortable with Perl than I'd ever be with a Lisp, then I guess I'll just learn to accept that I can't (or don't need to be able to) build the language I use from scratch. It's just a weird feeling and I'd be curious to know if it's just me. It's this sense of bootstrapping that if I'm not using my own tools all the time (including the language) that I at least need to know how to make them.
- jeffasinger 13y ago
  What would actually stop you from building a language like Perl or Ruby from scratch? Once you've parsed them (which is admittedly much more difficult than Perl), writing a relatively slow interpreter for the core language in C or similar wouldn't be that difficult.
  - kbenson 13y ago
    What would actually stop you from building a language like Perl or Ruby from scratch? Perl currently has no specification, other than the latest release of the interpreter. What the interpreter does may be decided to be incorrect by consensus at some point, and changed (although Perl has a very strong history of backwards compatibility so it's unlikely to change unless it was unuseful before), but there is no external resource besides the code and the compiled interpreter to explain how it should behave in every case.
    - webjprgm 13y ago
      No, but I have my own mental model of how it works, and if I were trying to preserve my own Perl code I'd only need the subset of Perl that I understand and use. I could reconstruct that from scratch with no reference other than my own Perl source code.
      - kbenson 13y ago
        That's true. And with CPAN Testers and the output of the tests of all the modules against the latest version, you have a pretty damn good reference to go by.
- kbenson 13y ago
  If it turns out I'm a thousand times more comfortable with Perl than I'd ever be with a Lisp, then I guess I'll just learn to accept that I can't (or don't need to be able to) build the language I use from scratch. You can also see how you like Perl 6, which has a specification and multiple implementations being built. It's not the same as Perl 5, but it's not meant to be (think of it as a sibling, not a successor).
- webjprgm 13y ago
  I get the same feeling. That's why I always have this idea in the back of my head that I should learn to make a computer from the sand on a beach in case I'm ever marooned on an island on an alien planet. But I recognize that it's entirely impractical to start from literally nothing. I also keep around my old computers and/or make sure I have emulators that can run my old stuff. E.g. a TRS-80 emulator for the Basic II programs I first learned to write. Or a Mac OS 9 emulator to open Claris Works 4 files I wrote in high school. I rarely use such things, but I feel better knowing my data is not truly lost.
lucian1900 13y ago
As a bit of trivia, Perl actually happens to be impossible to parse http://www.perlmonks.org/?node_id=663393 http://www.perlmonks.org/?node_id=663393
- draegtun 13y ago
  >Perl actually happens to be impossible to parse Not actually true otherwise no Perl code could be run at all :) A more accurate description would be - Perl cannot be parsed unambiguously without runtime information. For more detailed|interesting discussion about that Perlmonks post see this HN submission from 3 years ago - https://news.ycombinator.com/item?id=761103 https://news.ycombinator.com/item?id=761103
  - lucian1900 13y ago
    It's impossible to parse in the theoretical sense, since it requires information only obtainable through evaluation.
    - snaky 13y ago
      And that's a necessarily a bad thing?
      - ionforce 13y ago
        For varying contexts of bad. It impedes on things like static analysis. You don't want the surface area of your programming language confined to 1) runtime 2) being run by a specific binary. Where is the offline tooling? Where is the variety? This handicap makes me despise Perl. And I say that as a long time professional Perl engineer.
        snaky 13y ago
        What the point of static analysis for dynamic language? >being run by a specific binary That's a not so appealing argument in particular case of Perl which level of reverse compatibility is hard to beat.
goldfeld 13y ago
The notion that programming languages would accumulate more syntax as the discipline of software engineering matures and more conventions become universal, while appealing to me personally, is, in my opinion, naive. These times are not like the past centuries over which Mathematics matured, our culture has changed and it's pervading on the progress of science, we now favor instant gratification, quick results, getting started easily, all accomodating short attention spans. Of course, that says nothing of academic and niche languages; those will develop in every way possible. But as for what's to become popular, I think programming is bound to drop more specific syntax and become increasingly like natural language. This will be facilitated not only by our culture, but by advances in AI and natural language parsing. Much like the text editors themselves will tend to be increasingly facilitated by visual and audio input, and by intelligent computer assistance, in ways envisioned by Bret Victor, instead of going the way of the full control beasts that are vim and emacs. Which is a shame just the same. EDIT: Care to make a counter argument instead of just downvoting?
- JasonFruit 13y ago
  Counter-arguments: I take it as axiomatic that if someone says our times are different from all the rest of history, they are wrong. I can't imagine that our need for unambiguous syntax is going to decline, since our programs are still going to need to be precise in a way that is not well-served by natural language. I think your whole argument is hand-wavy and, in my opinion, naïve.
  - johndcook 13y ago
    I don't think that human nature changes over history, but culture does. I agree that attention spans have become shorter, but I don't see how that relates to whether programming languages will expand their palette of symbols.
    - JasonFruit 13y ago
      Maybe the top-level comment was suggesting that more symbols implies a higher learning curve, and requires longer, more attentive initial study.
lmm 13y ago
As a scala user/fan I spend a lot of time thinking about this; I think the scala community is at a crossroads in terms of syntactic convention. Personally I feel symbols make a language less readable, and I'd hold up python as the best example. It's more readable than either perl or lisp; the larger-scale structure of a program is immediately apparent (partly thanks to "the whitespace thing") as with perl, but then in the small the use of words rather than symbols ("or", "in") makes it readable without learning, like lisp. One has to rely on syntax highlighting to show the differences between values and operators - but even in a language that uses symbols for operators, one needs to be able to distinguish between values and functions (and in scala in particular, a visual distinction between functions and operators would be actively unhelpful). I know usability studies have found buttons with text are easier to understand than those with icons; I wonder if the comparison extends to symbols.
- kbenson 13y ago
  but even in a language that uses symbols for operators, one needs to be able to distinguish between values and functions Which is the whole point of sigils in perl, and a different sigils to denote the different core types. They hint the type for the reader. Some people are very adverse to the idea of sigils, but really it's like any other bit of syntax in a language, once you know what it is and can pick it out, you can then use it as a useful additional channel of information when reading and writing code (channel of information to future readers of the code, that is).
  - lmm 13y ago
    Firstly, the sigils on variables are only a small part of perl's legendary unreadability; there's also a plethora of operators called things like <=> and ~/, along with a bunch of magic implicit variables ($_ is common enough to be memorable, but it's not the only one). And the sigils are a bad idea for the same reason that operators with sigil names are a bad idea: it creates this artificial distinction between what's built-in and what's user-defined (though in this case we're talking about types rather than methods).
siamore 13y ago
The article says that having the syntax is not a bad thing but doesn't really say what it has over LISP's simple syntax, expressiveness? easy to read for people unfamiliar with the language? AFAIK the one thing it definitely allows is to be able to write a program and common tasks in just a few characters, which is great and all but not the strength of perl and definitely not needed in all situations. LISP syntax OTOH is as he said easy to pick up and parse while still allowing all the expressiveness any other language can have (even without more syntax like the lambda character). But there is a similarity between the two, the outstanding syntax. I don't know about others but I'd attribute it to C's popularity more than anything else and with most other languages following it (JS, C++...) it seems like it should be standard or something, I've seen far too many people avoid learning languages due to syntax without realizing something much more important: They might be turning down a language that can save them tons of trouble later if they just get past the one time step of learning the syntax, so listen to the author, perl is a great CGI language, and if that's what you need just learn it. other languages may be easier to learn, may be what's hip now but I'd bet perl is still better.
mazelife 13y ago
The concluding question—"What if programming notation were more like music notation?"—is an interesting one. Music notation achieves a pretty impressive information density when you think about it. And it offers an interesting way of describing concurrent processes. (edit: I should say it offers an interesting way of describing parallel processes) I suppose it would be closest to a declarative programming paradigm? But there are going to be some inevitable problems when drawing comparisons to programming languages. One of which is that music notation occupies a kind of hybid position between a natural language and a machine language. Certain aspects of notation like pitch and rhythm are totally unambiguous (at least in the abstract) but others (volume, timbre, attack, phrasing) are more connotational and thus up to performer interpretation. Then there's something like tempo which may be a mixture of both: a metronome mark is unambiguous but an accelerando isn't. Also, although I agree that "people learn to read it fluently with a little training," I don't think it follows that they can write it correctly with a little training. It's actually an enormously subtle, complex mode of expression. Take just one example: enharmonic spelling. Even in a purely diatonic harmonic context, understanding when to use a g-sharp versus and a-flat requires a pretty extensive understanding of music theory. Take a bit of time to peruse something like Gardner Read's "Music Notation: A Manual of Modern Practice" with its 400+ pages detailing all the edge cases and tiny details and you'll see just how hard it can be to notate music properly.
crntaylor 13y ago
Music notation does not express concurrency easily. It expresses parallelism easily. It can do this each part can be played in isolation - in other words, they are pure.
- danbruc 13y ago
  Concurrency is a prerequisite for parallelism.
  - dllthomas 13y ago
    "Music notation does not express concurrency easily [in enough generality to do most of the interesting things that aren't simple parallelism]. It expresses parallelism easily."
  - btilly 13y ago
    I'm not sure what the right words are for the post you replied to, but they are honestly different and have different capabilities. For "concurrency" think of the operation, "You go off and take care of that. I'll take care of this. We might meet up later." For "parallelism" think of performing a sequence of operations in lock step, while standing next to each other. That these are independent can be seen in programming when you compare multi-threaded programming (concurrent but in no way parallel) with programming for the GPU (very parallel, but none of the type of concurrency that I'm discussing). Returning to music notation, it is like a GPU - everything goes in lock step. Stuff happens simultaneously, but not independently.
  - Gonzih 13y ago
    Nope. Concurrency and parallelism need different tools.
- mrbrowning 13y ago
  There's an analog in music to the notion of concurrency, which is the polyphonic melody -- a single melodic line that, by jumping between disparate registers, expresses the simultaneous sounding of two (abstract) voices moving against each other. Of course, this depends on the assumption that pitches can be implied even at times when they're not sounding, which intuitively seems to hold: see Bach's Cello Suites for a canonical example of this practice in action.
tome 13y ago
The problem with Perl is not the syntax, it's the semantics, or more accurately the loose connection between the two.
- kbenson 13y ago
  Example? I'm interested in what you find ambiguous.
  - snaky 13y ago
    I think this will be rant about the list/scalar context or scalar/array/hash context. Like a pointers in C that are extremely useful features and at the same time are surprisingly hard to understand for many people.
    - kbenson 13y ago
      If so, that would be a shame. There's already far to much "Hey, that's not how C behaves! [insert lang here] is stupid because it doesn't do what I expect, and I expect it to be C."
      - snaky 13y ago
        I've lost you here. My C pointers analogy was relevant only in that is surprisingly hard to get by many people, and I don't know why is that so. The only thing in Perl that clearly imitates C pointers syntax and semantics is a hash/array reference element access '->' and I like it because it clearly distinguish from actual hash/aray access '.' and understandable for any person who knows C.
        kbenson 13y ago
        Oh, I understood your meaning, it was just similar enough to another theory of mine[1] that I sort of launched into that frame of mind immediately. In short, people often expect other languages to act like C, and where they differ they get a bad rap (even through they often differ at that point for a reason, and it's often considered a strength by proponents). For example, caring about return context in Perl. [1]: https://news.ycombinator.com/item?id=5657901 https://news.ycombinator.com/item?id=5657901
ionforce 13y ago
As a musician, I would disagree heavily with the author's statement that "people learn to read [musical notation] fluently with a little training". A few certain individuals can be musical without being musically literate but understanding musical notation definitely requires training. It's like literacy, it's not something you just pick up out of nowhere. It's intentional, it's practiced, and it is honed.
- johndcook 13y ago
  Sure, it takes work. But we expect children to be able to do it and they do.
  - ionforce 13y ago
    Surely not all children? You mean children enrolled in music class, which I don't think qualifies as a small amount of training.
- nfoz 13y ago
  Both as a small child and as an adult, learning music I'm suuuuper distracted by the complexity and the badness of traditional music notation.
  - ionforce 13y ago
    What makes it complex and bad?
- Daishiman 13y ago
  In my experience the vast majority of popular musicians cannot read musical notation, and it doesn't really seem to impact much. It seems like it's more important to read Fruity Loops or Ableton filter notation nowadays.
octo_t 13y ago
Consider Fortress'[1] syntax, its designed to completely typeset and look amazingly readable. [2] has a pretty nice rundown of the syntax, with [3] being a talk at ScalaDays 2012 on what Fortress and Scala can learn from each other syntactically. Fortress has the concept of juxtaposition: things like: 2 3 evaluate to 6, because thats the scientific convention. Integer types are also represented as the mathematical symbol for Ints etc, the language looks beautiful and how you'd write it on the whiteboard. [1] - http://en.wikipedia.org/wiki/Fortress_(programming_language) http://en.wikipedia.org/wiki/Fortress_(programming_language) [2] - http://www.slideshare.net/alexmiller/project-fortress http://www.slideshare.net/alexmiller/project-fortress [3] - http://skillsmatter.com/podcast/scala/scala-days-keynote-3018 http://skillsmatter.com/podcast/scala/scala-days-keynote-301...
- pi18n 13y ago
  I like the simplicity of the big operators and the ideas on parallelism they were considering. What a huge disappointment that they aren't going to continue work on it.
- Too 13y ago
  Also take a look on mathematica. It has both a textual and a mathematic representation for everything making it both look good while it cooperates with existing source control tools. It's a shame more languages aren't designed like this. I would like to call it extreme syntax highlighting rather than extreme syntax. Some might argue that 'sum(myArray)' is both more readable and occupy less vertical space than the mathematical sum-operator but when it comes to skimming through large pieces of code having distinctive characters can really help. Where it really shines is when you are editing large matrices that automatically get aligned. Long mathematical expressions involving division is also a good example, here you get fractionals displayed nicely instead of having to nest everything in paranthesis.
taeric 13y ago
The music analogy is tempting, but has a serious problem. The same music when interpreted by different people, results in a different sounding piece. There is some level of control on this, but not as much as I think would be necessary for most programs.
- webjprgm 13y ago
  That just means the semantics are not precisely defined. Have a look at the C specification for things that are left undefined. The same C program, when interpreted by different compilers (esp. on different architectures) will have different behavior.
  - taeric 13y ago
    Right. I had thought most folks wanted less "undefined" behavior in a program. And, most of the type of "undefined" you are referring to are in places where folks are supposed to avoid, right? That is, I thought most were "undefined" and generally considered programmer error.
klibertp 13y ago
And what with "syntax doesn't matter" people? You know, the ones that now both Perl and at least three Lisps, and then twenty other languages, the ones that say that syntax is just a minor detail, and if you're irritated enough you can always write a "transpiler"? Where did all these people go (long time ago)? Also, I prefer maths from before 20th century. You could get knowledge out of it without relying on an additional skill, which math-reading nowadays is. On a related note: I don't believe that "you spend more time using the language than learning it". I need to think it about it some more, but I have a feeling that almost everything we do as a programmers is learning.
- kbenson 13y ago
  On a related note: I don't believe that "you spend more time using the language than learning it". I need to think it about it some more, but I have a feeling that almost everything we do as a programmers is learning. Yes, but how much of that is learning the language, and how much is learning about programming and/or computer science in general?
- smacktoward 13y ago
  But how much of that learning is really empirically necessary, and how much is just keeping up with industry fads and trends just to stay marketable? I've learned way too many languages over the last fifteen years just in the process of being a web developer. I'm not sure if any of them by themselves made me a radically better at web development. More frequently they were learned to get access to a bit of tooling or some other benefit that only one language had. Think of all the people who learned Ruby in order to use Rails, for instance, or who learned JavaScript to do front-end scripting. Is it really something about Ruby-the-language or JS-the-language that made them so compelling? Not really. It was the productivity gains you could get by getting access to their ecosystems, rather than the languages themselves. For this reason I have some envy for the folks you meet who've been working in Lisp, or Perl, or C, or COBOL, or some other language consistently for decades. They get to reach a level of proficiency and sophistication in how they use their tools that are out of reach when you're constantly bouncing from language to language.
  - 13y ago
kruhft 13y ago
Common Lisp actually has a suprising amount of syntax, from the obvious ', to all of the standard dispatch reader macros starting with # (#', #., #=, ...), to block comment syntax #| ... |#. Pure lisp has no syntax, but practical lisp has quite a bit. Trying to read arbitrary symbols from external sources can lead to quite a shock without hacking the reader to disable many of it's syntactical features.
- webjprgm 13y ago
  Which further proves the author's point that adding syntax makes things easier, since even the pure Lisp land is speckled with extra syntax to make it work.
  - kruhft 13y ago
    When you have 2 extremes the real solution is almost always somewhere in the middle. I think a good solution to the syntax amount problem is Python, but I still don't like significant whitespace.
webjprgm 13y ago
One comment on the article mentioned that programming languages need to have many concepts, and concepts built on concepts, and concepts built on those. So you can't have a new symbol for each concept since you build more and more concepts. I think Lisp has too few symbols. I completely agree with the author on this. I think there's a balance where we use enough symbols to make the structure of the code stand out but don't try to make everything into a symbol since the language is essentially extensible by the user in building the tower of concepts. Next question: is operator overloading good? It lets you write extensions that feel like they are part of the language, but it also makes the code difficult to evaluate mentally since you might not know that an operator means something different now. I've always found it rather annoying to use collection APIs in Java, or big num libraries, since you have to call long-named functions for simple operations. In C++ you can overload operators to concatenate, iterate, and inspect collections. But this can be misused (in C++, Lisp, and other languages) to make code harder to figure out. Math notation, though, does have overloading. "+" is not just add two integers, it can be used for set operations sometimes. Also some notation is used differently in different disciplines, like math-like notation in some computer science papers (e.g. describing a type system or Lambda calculus evaluation) look similar to operators used in logic or calculus but mean different things. So operator overloading is common. Is it good?
- ionforce 13y ago
  Operator overloading is good if the operator continues to mean the same thing across domains. If I have two integers and I want to add them together to create a new integer, that's pretty clear. It's still clear that if I have two complex numbers or fractions that I would want to immutably add them up and create a new number. And so on with things like lists and sets, which as you pointed out are set operations. I would be less inclined to extend this to domains that aren't about numbers or sets, like genie + bottle What exactly does that do? It's kind of like implementing an interface. The implementation should do what it says on the box. In this case the box is the sign for addition.

51 points by prajjwal 13y ago

"What if programming notation were more like music notation?" -> if you look at the denotational semantics listings on the latest Scheme Reports you will see something that could be equated to music notation (i.e. they're both instructions on how something should work, and they're sufficient information to get there). I oftentimes think about these same issues regarding the syntax of different languages. I work in Ruby and I think it's a comfortable language to express ideas in. Scheme is also comfortable and I like it more conceptually, since it gives me this strange comfort of thinking "well, if Scheme disappears forever, at least I have books that can help me make another one", which I never think of languages like Ruby and Perl. That's why I'm now finally learning Perl; I want to have a better perspective on what I actually like. If it turns out I'm a thousand times more comfortable with Perl than I'd ever be with a Lisp, then I guess I'll just learn to accept that I can't (or don't need to be able to) build the language I use from scratch. It's just a weird feeling and I'd be curious to know if it's just me. It's this sense of bootstrapping that if I'm not using my own tools all the time (including the language) that I at least need to know how to make them.

jeffasinger 13y ago
What would actually stop you from building a language like Perl or Ruby from scratch? Once you've parsed them (which is admittedly much more difficult than Perl), writing a relatively slow interpreter for the core language in C or similar wouldn't be that difficult.
- kbenson 13y ago
  What would actually stop you from building a language like Perl or Ruby from scratch? Perl currently has no specification, other than the latest release of the interpreter. What the interpreter does may be decided to be incorrect by consensus at some point, and changed (although Perl has a very strong history of backwards compatibility so it's unlikely to change unless it was unuseful before), but there is no external resource besides the code and the compiled interpreter to explain how it should behave in every case.
  - webjprgm 13y ago
    No, but I have my own mental model of how it works, and if I were trying to preserve my own Perl code I'd only need the subset of Perl that I understand and use. I could reconstruct that from scratch with no reference other than my own Perl source code.
    - kbenson 13y ago
      That's true. And with CPAN Testers and the output of the tests of all the modules against the latest version, you have a pretty damn good reference to go by.
kbenson 13y ago
If it turns out I'm a thousand times more comfortable with Perl than I'd ever be with a Lisp, then I guess I'll just learn to accept that I can't (or don't need to be able to) build the language I use from scratch. You can also see how you like Perl 6, which has a specification and multiple implementations being built. It's not the same as Perl 5, but it's not meant to be (think of it as a sibling, not a successor).
webjprgm 13y ago
I get the same feeling. That's why I always have this idea in the back of my head that I should learn to make a computer from the sand on a beach in case I'm ever marooned on an island on an alien planet. But I recognize that it's entirely impractical to start from literally nothing. I also keep around my old computers and/or make sure I have emulators that can run my old stuff. E.g. a TRS-80 emulator for the Basic II programs I first learned to write. Or a Mac OS 9 emulator to open Claris Works 4 files I wrote in high school. I rarely use such things, but I feel better knowing my data is not truly lost.

lucian1900 13y ago

As a bit of trivia, Perl actually happens to be impossible to parse http://www.perlmonks.org/?node_id=663393 http://www.perlmonks.org/?node_id=663393

draegtun 13y ago
>Perl actually happens to be impossible to parse Not actually true otherwise no Perl code could be run at all :) A more accurate description would be - Perl cannot be parsed unambiguously without runtime information. For more detailed|interesting discussion about that Perlmonks post see this HN submission from 3 years ago - https://news.ycombinator.com/item?id=761103 https://news.ycombinator.com/item?id=761103
- lucian1900 13y ago
  It's impossible to parse in the theoretical sense, since it requires information only obtainable through evaluation.
  - snaky 13y ago
    And that's a necessarily a bad thing?
    - ionforce 13y ago
      For varying contexts of bad. It impedes on things like static analysis. You don't want the surface area of your programming language confined to 1) runtime 2) being run by a specific binary. Where is the offline tooling? Where is the variety? This handicap makes me despise Perl. And I say that as a long time professional Perl engineer.
      - snaky 13y ago
        What the point of static analysis for dynamic language? >being run by a specific binary That's a not so appealing argument in particular case of Perl which level of reverse compatibility is hard to beat.

goldfeld 13y ago

The notion that programming languages would accumulate more syntax as the discipline of software engineering matures and more conventions become universal, while appealing to me personally, is, in my opinion, naive. These times are not like the past centuries over which Mathematics matured, our culture has changed and it's pervading on the progress of science, we now favor instant gratification, quick results, getting started easily, all accomodating short attention spans. Of course, that says nothing of academic and niche languages; those will develop in every way possible. But as for what's to become popular, I think programming is bound to drop more specific syntax and become increasingly like natural language. This will be facilitated not only by our culture, but by advances in AI and natural language parsing. Much like the text editors themselves will tend to be increasingly facilitated by visual and audio input, and by intelligent computer assistance, in ways envisioned by Bret Victor, instead of going the way of the full control beasts that are vim and emacs. Which is a shame just the same. EDIT: Care to make a counter argument instead of just downvoting?

JasonFruit 13y ago
Counter-arguments: I take it as axiomatic that if someone says our times are different from all the rest of history, they are wrong. I can't imagine that our need for unambiguous syntax is going to decline, since our programs are still going to need to be precise in a way that is not well-served by natural language. I think your whole argument is hand-wavy and, in my opinion, naïve.
- johndcook 13y ago
  I don't think that human nature changes over history, but culture does. I agree that attention spans have become shorter, but I don't see how that relates to whether programming languages will expand their palette of symbols.
  - JasonFruit 13y ago
    Maybe the top-level comment was suggesting that more symbols implies a higher learning curve, and requires longer, more attentive initial study.

lmm 13y ago

As a scala user/fan I spend a lot of time thinking about this; I think the scala community is at a crossroads in terms of syntactic convention. Personally I feel symbols make a language less readable, and I'd hold up python as the best example. It's more readable than either perl or lisp; the larger-scale structure of a program is immediately apparent (partly thanks to "the whitespace thing") as with perl, but then in the small the use of words rather than symbols ("or", "in") makes it readable without learning, like lisp. One has to rely on syntax highlighting to show the differences between values and operators - but even in a language that uses symbols for operators, one needs to be able to distinguish between values and functions (and in scala in particular, a visual distinction between functions and operators would be actively unhelpful). I know usability studies have found buttons with text are easier to understand than those with icons; I wonder if the comparison extends to symbols.

kbenson 13y ago
but even in a language that uses symbols for operators, one needs to be able to distinguish between values and functions Which is the whole point of sigils in perl, and a different sigils to denote the different core types. They hint the type for the reader. Some people are very adverse to the idea of sigils, but really it's like any other bit of syntax in a language, once you know what it is and can pick it out, you can then use it as a useful additional channel of information when reading and writing code (channel of information to future readers of the code, that is).
- lmm 13y ago
  Firstly, the sigils on variables are only a small part of perl's legendary unreadability; there's also a plethora of operators called things like <=> and ~/, along with a bunch of magic implicit variables ($_ is common enough to be memorable, but it's not the only one). And the sigils are a bad idea for the same reason that operators with sigil names are a bad idea: it creates this artificial distinction between what's built-in and what's user-defined (though in this case we're talking about types rather than methods).

siamore 13y ago

The article says that having the syntax is not a bad thing but doesn't really say what it has over LISP's simple syntax, expressiveness? easy to read for people unfamiliar with the language? AFAIK the one thing it definitely allows is to be able to write a program and common tasks in just a few characters, which is great and all but not the strength of perl and definitely not needed in all situations. LISP syntax OTOH is as he said easy to pick up and parse while still allowing all the expressiveness any other language can have (even without more syntax like the lambda character). But there is a similarity between the two, the outstanding syntax. I don't know about others but I'd attribute it to C's popularity more than anything else and with most other languages following it (JS, C++...) it seems like it should be standard or something, I've seen far too many people avoid learning languages due to syntax without realizing something much more important: They might be turning down a language that can save them tons of trouble later if they just get past the one time step of learning the syntax, so listen to the author, perl is a great CGI language, and if that's what you need just learn it. other languages may be easier to learn, may be what's hip now but I'd bet perl is still better.

mazelife 13y ago

The concluding question—"What if programming notation were more like music notation?"—is an interesting one. Music notation achieves a pretty impressive information density when you think about it. And it offers an interesting way of describing concurrent processes. (edit: I should say it offers an interesting way of describing parallel processes) I suppose it would be closest to a declarative programming paradigm? But there are going to be some inevitable problems when drawing comparisons to programming languages. One of which is that music notation occupies a kind of hybid position between a natural language and a machine language. Certain aspects of notation like pitch and rhythm are totally unambiguous (at least in the abstract) but others (volume, timbre, attack, phrasing) are more connotational and thus up to performer interpretation. Then there's something like tempo which may be a mixture of both: a metronome mark is unambiguous but an accelerando isn't. Also, although I agree that "people learn to read it fluently with a little training," I don't think it follows that they can write it correctly with a little training. It's actually an enormously subtle, complex mode of expression. Take just one example: enharmonic spelling. Even in a purely diatonic harmonic context, understanding when to use a g-sharp versus and a-flat requires a pretty extensive understanding of music theory. Take a bit of time to peruse something like Gardner Read's "Music Notation: A Manual of Modern Practice" with its 400+ pages detailing all the edge cases and tiny details and you'll see just how hard it can be to notate music properly.

crntaylor 13y ago

Music notation does not express concurrency easily. It expresses parallelism easily. It can do this each part can be played in isolation - in other words, they are pure.

danbruc 13y ago
Concurrency is a prerequisite for parallelism.
- dllthomas 13y ago
  "Music notation does not express concurrency easily [in enough generality to do most of the interesting things that aren't simple parallelism]. It expresses parallelism easily."
- btilly 13y ago
  I'm not sure what the right words are for the post you replied to, but they are honestly different and have different capabilities. For "concurrency" think of the operation, "You go off and take care of that. I'll take care of this. We might meet up later." For "parallelism" think of performing a sequence of operations in lock step, while standing next to each other. That these are independent can be seen in programming when you compare multi-threaded programming (concurrent but in no way parallel) with programming for the GPU (very parallel, but none of the type of concurrency that I'm discussing). Returning to music notation, it is like a GPU - everything goes in lock step. Stuff happens simultaneously, but not independently.
- Gonzih 13y ago
  Nope. Concurrency and parallelism need different tools.
mrbrowning 13y ago
There's an analog in music to the notion of concurrency, which is the polyphonic melody -- a single melodic line that, by jumping between disparate registers, expresses the simultaneous sounding of two (abstract) voices moving against each other. Of course, this depends on the assumption that pitches can be implied even at times when they're not sounding, which intuitively seems to hold: see Bach's Cello Suites for a canonical example of this practice in action.

tome 13y ago

The problem with Perl is not the syntax, it's the semantics, or more accurately the loose connection between the two.

kbenson 13y ago
Example? I'm interested in what you find ambiguous.
- snaky 13y ago
  I think this will be rant about the list/scalar context or scalar/array/hash context. Like a pointers in C that are extremely useful features and at the same time are surprisingly hard to understand for many people.
  - kbenson 13y ago
    If so, that would be a shame. There's already far to much "Hey, that's not how C behaves! [insert lang here] is stupid because it doesn't do what I expect, and I expect it to be C."
    - snaky 13y ago
      I've lost you here. My C pointers analogy was relevant only in that is surprisingly hard to get by many people, and I don't know why is that so. The only thing in Perl that clearly imitates C pointers syntax and semantics is a hash/array reference element access '->' and I like it because it clearly distinguish from actual hash/aray access '.' and understandable for any person who knows C.
      - kbenson 13y ago
        Oh, I understood your meaning, it was just similar enough to another theory of mine[1] that I sort of launched into that frame of mind immediately. In short, people often expect other languages to act like C, and where they differ they get a bad rap (even through they often differ at that point for a reason, and it's often considered a strength by proponents). For example, caring about return context in Perl. [1]: https://news.ycombinator.com/item?id=5657901 https://news.ycombinator.com/item?id=5657901

ionforce 13y ago

As a musician, I would disagree heavily with the author's statement that "people learn to read [musical notation] fluently with a little training". A few certain individuals can be musical without being musically literate but understanding musical notation definitely requires training. It's like literacy, it's not something you just pick up out of nowhere. It's intentional, it's practiced, and it is honed.

johndcook 13y ago
Sure, it takes work. But we expect children to be able to do it and they do.
- ionforce 13y ago
  Surely not all children? You mean children enrolled in music class, which I don't think qualifies as a small amount of training.
nfoz 13y ago
Both as a small child and as an adult, learning music I'm suuuuper distracted by the complexity and the badness of traditional music notation.
- ionforce 13y ago
  What makes it complex and bad?
Daishiman 13y ago
In my experience the vast majority of popular musicians cannot read musical notation, and it doesn't really seem to impact much. It seems like it's more important to read Fruity Loops or Ableton filter notation nowadays.

octo_t 13y ago

Consider Fortress'[1] syntax, its designed to completely typeset and look amazingly readable. [2] has a pretty nice rundown of the syntax, with [3] being a talk at ScalaDays 2012 on what Fortress and Scala can learn from each other syntactically. Fortress has the concept of juxtaposition: things like: 2 3 evaluate to 6, because thats the scientific convention. Integer types are also represented as the mathematical symbol for Ints etc, the language looks beautiful and how you'd write it on the whiteboard. [1] - http://en.wikipedia.org/wiki/Fortress_(programming_language) http://en.wikipedia.org/wiki/Fortress_(programming_language) [2] - http://www.slideshare.net/alexmiller/project-fortress http://www.slideshare.net/alexmiller/project-fortress [3] - http://skillsmatter.com/podcast/scala/scala-days-keynote-3018 http://skillsmatter.com/podcast/scala/scala-days-keynote-301...

pi18n 13y ago
I like the simplicity of the big operators and the ideas on parallelism they were considering. What a huge disappointment that they aren't going to continue work on it.
Too 13y ago
Also take a look on mathematica. It has both a textual and a mathematic representation for everything making it both look good while it cooperates with existing source control tools. It's a shame more languages aren't designed like this. I would like to call it extreme syntax highlighting rather than extreme syntax. Some might argue that 'sum(myArray)' is both more readable and occupy less vertical space than the mathematical sum-operator but when it comes to skimming through large pieces of code having distinctive characters can really help. Where it really shines is when you are editing large matrices that automatically get aligned. Long mathematical expressions involving division is also a good example, here you get fractionals displayed nicely instead of having to nest everything in paranthesis.

taeric 13y ago

The music analogy is tempting, but has a serious problem. The same music when interpreted by different people, results in a different sounding piece. There is some level of control on this, but not as much as I think would be necessary for most programs.

webjprgm 13y ago
That just means the semantics are not precisely defined. Have a look at the C specification for things that are left undefined. The same C program, when interpreted by different compilers (esp. on different architectures) will have different behavior.
- taeric 13y ago
  Right. I had thought most folks wanted less "undefined" behavior in a program. And, most of the type of "undefined" you are referring to are in places where folks are supposed to avoid, right? That is, I thought most were "undefined" and generally considered programmer error.

klibertp 13y ago

And what with "syntax doesn't matter" people? You know, the ones that now both Perl and at least three Lisps, and then twenty other languages, the ones that say that syntax is just a minor detail, and if you're irritated enough you can always write a "transpiler"? Where did all these people go (long time ago)? Also, I prefer maths from before 20th century. You could get knowledge out of it without relying on an additional skill, which math-reading nowadays is. On a related note: I don't believe that "you spend more time using the language than learning it". I need to think it about it some more, but I have a feeling that almost everything we do as a programmers is learning.

kbenson 13y ago
On a related note: I don't believe that "you spend more time using the language than learning it". I need to think it about it some more, but I have a feeling that almost everything we do as a programmers is learning. Yes, but how much of that is learning the language, and how much is learning about programming and/or computer science in general?
smacktoward 13y ago
But how much of that learning is really empirically necessary, and how much is just keeping up with industry fads and trends just to stay marketable? I've learned way too many languages over the last fifteen years just in the process of being a web developer. I'm not sure if any of them by themselves made me a radically better at web development. More frequently they were learned to get access to a bit of tooling or some other benefit that only one language had. Think of all the people who learned Ruby in order to use Rails, for instance, or who learned JavaScript to do front-end scripting. Is it really something about Ruby-the-language or JS-the-language that made them so compelling? Not really. It was the productivity gains you could get by getting access to their ecosystems, rather than the languages themselves. For this reason I have some envy for the folks you meet who've been working in Lisp, or Perl, or C, or COBOL, or some other language consistently for decades. They get to reach a level of proficiency and sophistication in how they use their tools that are out of reach when you're constantly bouncing from language to language.
- 13y ago

kruhft 13y ago

Common Lisp actually has a suprising amount of syntax, from the obvious ', to all of the standard dispatch reader macros starting with # (#', #., #=, ...), to block comment syntax #| ... |#. Pure lisp has no syntax, but practical lisp has quite a bit. Trying to read arbitrary symbols from external sources can lead to quite a shock without hacking the reader to disable many of it's syntactical features.

webjprgm 13y ago
Which further proves the author's point that adding syntax makes things easier, since even the pure Lisp land is speckled with extra syntax to make it work.
- kruhft 13y ago
  When you have 2 extremes the real solution is almost always somewhere in the middle. I think a good solution to the syntax amount problem is Python, but I still don't like significant whitespace.

webjprgm 13y ago

One comment on the article mentioned that programming languages need to have many concepts, and concepts built on concepts, and concepts built on those. So you can't have a new symbol for each concept since you build more and more concepts. I think Lisp has too few symbols. I completely agree with the author on this. I think there's a balance where we use enough symbols to make the structure of the code stand out but don't try to make everything into a symbol since the language is essentially extensible by the user in building the tower of concepts. Next question: is operator overloading good? It lets you write extensions that feel like they are part of the language, but it also makes the code difficult to evaluate mentally since you might not know that an operator means something different now. I've always found it rather annoying to use collection APIs in Java, or big num libraries, since you have to call long-named functions for simple operations. In C++ you can overload operators to concatenate, iterate, and inspect collections. But this can be misused (in C++, Lisp, and other languages) to make code harder to figure out. Math notation, though, does have overloading. "+" is not just add two integers, it can be used for set operations sometimes. Also some notation is used differently in different disciplines, like math-like notation in some computer science papers (e.g. describing a type system or Lambda calculus evaluation) look similar to operators used in logic or calculus but mean different things. So operator overloading is common. Is it good?

ionforce 13y ago
Operator overloading is good if the operator continues to mean the same thing across domains. If I have two integers and I want to add them together to create a new integer, that's pretty clear. It's still clear that if I have two complex numbers or fractions that I would want to immutably add them up and create a new number. And so on with things like lists and sets, which as you pointed out are set operations. I would be less inclined to extend this to domains that aren't about numbers or sets, like genie + bottle What exactly does that do? It's kind of like implementing an interface. The implementation should do what it says on the box. In this case the box is the sign for addition.