Extreme syntax

http://www.johndcook.com/blog/2013/05/16/extreme-syntax/

by prajjwal • 13 years ago

51 73 13 years ago

innguest• 13 years 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• 13 years 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.

kbenson8• 13 years 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.

kbenson8• 13 years 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).

webjprgm7• 13 years 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.

lucian19002• 13 years ago

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

draegtun• 13 years 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

lucian19002• 13 years ago

It's impossible to parse in the theoretical sense, since it requires information only obtainable through evaluation.

ionforce7• 13 years ago

To further clarify, only the entirety of Perl cannot be parsed perfectly. There are large subsets of Perl that can be parsed easily.

goldfeld• 13 years 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?

JasonFruit2• 13 years 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.

johndcook2• 13 years 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.

npc• 13 years ago

>I think programming is bound to drop more specific syntax and become increasingly like natural language

Why do you think that? Programming has never been like writing in a natural language, nor would it be useful for it to be. Natural language is inherently filled with subtleties and imprecision, both of which are anathema to the typical process of programming. When I write something for the computer to consume then I want to be able to know with 100% certainty what it is going to do, the probablistic parsers typically used for NLP couldn't guarantee that.

derleth• 13 years ago

> we now favor instant gratification, quick results, getting started easily, all accomodating short attention spans.

This is not new. It is part of being human. Humans, being mammals, are inherently lazy and eager for shortcuts; it's why we have programming languages and computers to begin with. If you want industrious, look at the insects.

grey-area• 13 years ago

Applescript forms an interesting counter-point to your argument - it attempted to use something as close to natural language as possible. As a result it is verbose, complex to debug, and difficult to guess at the syntax as applications often use slightly different concepts for the same things. It's never been a popular language with programmers, and has only seen more widespread use by non-programmers when it was hidden from sight with Automator.

In contrast many (but not all) of the popular languages to program in today are as simple as possible (Ruby, Python, Go, etc...), and have a tightly controlled syntax and limited keywords, partly inspired by the example of Lisp. They may allow constructing simple sentences with verbs (functions) and nouns (variables), but they are carefully limited in the sentences and syntax they allow, and often don't require any UI other than a plain text editor. They certainly don't require NLP or AI and I can't see any move in that direction.

lmm2• 13 years 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.

kbenson8• 13 years 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).

lmm2• 13 years 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• 13 years 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• 13 years 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• 13 years 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• 13 years ago

Concurrency is a prerequisite for parallelism.

dllthomas• 13 years 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• 13 years 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• 13 years ago

Nope. Concurrency and parallelism need different tools.

mrbrowning• 13 years 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.

jerluc• 13 years ago

I completely agree with this. Perhaps expanding the idea further however, it makes sense IMHO to see a multi-staff score (this could mean either a score written for multiple parts, or as something like piano scores which typically have a staff for each hand) as parallelism.

tome• 13 years ago

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

kbenson8• 13 years ago

Example? I'm interested in what you find ambiguous.

snaky10• 13 years 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.

ionforce7• 13 years 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.

johndcook2• 13 years ago

Sure, it takes work. But we expect children to be able to do it and they do.

ionforce7• 13 years 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• 13 years 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.

ionforce7• 13 years ago

What makes it complex and bad?

Daishiman• 13 years 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• 13 years 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)

[2] http://www.slideshare.net/alexmiller/project-fortress

[3] http://skillsmatter.com/podcast/scala/scala-days-keynote-301...

pi18n• 13 years 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• 13 years 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.

taeric2• 13 years 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.

webjprgm7• 13 years 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.

taeric2• 13 years 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.

klibertp2• 13 years 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.

kbenson8• 13 years ago

Yes, but how much of that is learning the language, and how much is learning about programming and/or computer science in general?

smacktoward• 13 years 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.

webjprgm7• 13 years ago

I agree that I'd like to have the chance to get really good in a language that I use for a long time. (As long as it's enjoyable, e.g. I wouldn't want to be stuck in VB forever.) At one point I worked almost entirely in Java (up until around Java 1.5). Another few years it was mostly PHP. But since then it's been a bit of everything.

Useful lessons from learning: - Javascript -> Callback passing for an asynchronous computing paradigm. Object-array duality and prototype-based inheritance. - Ruby -> Rubyists often like to be clever with chaining several functions on one line to do something succinctly. This is kinda like functional programming (operations like map, inject, fold, etc.) but just one small piece of it. Ruby also has lots of metaprogramming magic to make DSLs, but that can bite you really bad when you have to debug RoR GEMs.

klibertp2• 13 years ago

"Is it really something about Ruby-the-language or JS-the-language that made them so compelling?"

Well... It obviously depends on a person. What is compelling to you may not be so for me and the other way around. And in this instance it depends on what you know already.

So, in other words, are JS and Ruby compelling to someone who learned Pascal or C in school and writes PHP for a living? Hell yes! Are they going to make him a better developer? There's a high chance they will.

Ruby sports an object system that is somewhat similar to Smalltalk, with many idioms borrowed from it. That's completely different Object Orientation and learning it can have benefits. If nothing more, it gives you another way of modeling problem domains, which is always a good thing.

JavaScript was an objective-functional mesh long before Scala. Coming from C or PHP, seeing first class functions with implicit state (closures) can open your eyes for yet another way of modeling things. Building, in essence, your own object system when you use a language is a valuable experience, too.

Different languages have different semantics and knowing many of them helps in expressing yourself. I hear that what we think is constrained by the language we know. That's true for programming languages too.

webjprgm7• 13 years ago

It also partly depends on how often you switch jobs that require you to learn a new programming language. So far in my career I've had to learn new languages quite often, esp. on hacked-together projects with 3+ languages. It's not just learning the syntax but also the common idioms. Still, I'm pretty sure at least more than 50% of the time was using the language and not learning it, so the original statement stands.

ohyes• 13 years ago

I'm still here.

I mostly do s-expression -> language, because it lets me do code generation. The thing is, writing your own code generation tools is only really useful if you are capable of applying 'more difficult' to grok computer science concepts. For example, the intersection of 'working programmers' and 'people who really understand state machines' is (sadly) tiny.

I'd even say that the syntax doesn't bother me because I don't really 'write' lisp code. The lisp code I write is solely done in order to generate much more complex code. So I would never actually implement an entire piece of software in common lisp (for example). I implement it in a variety of lisp-like dialects which accurately represent the problems presented by different modules inside the piece of software. Unfortunately this requires some forethought, some skill at language design, and an unwavering faith in ontology.

To me, this is the best type of process for implementing a unique piece of software from scratch, and is the approach that should be taken in any language. (It's basically the logical conclusion of the idea of structured programming... except you don't implement 'loops' and 'if' statements).

kruhft2• 13 years 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.

webjprgm7• 13 years 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.

kruhft2• 13 years 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.

webjprgm7• 13 years 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?

ionforce7• 13 years 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.

Extreme syntax

Related Stories