Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
andreineculau: Programming is not only syntax/semantics. Leave that to a readability/simplicity benchmark. Focus on models, patterns, higher level stuff

rambling re: tweet

By no means do I want to sound assertive. I lack a lot of knowledge in the area, so please slap me and set me straight, teach me a thing or two. The only thing that I standby is that it is stupid to explain syntax, to re-invent syntax, to argue about syntax, to have a liberal syntax, etc. Whatever does not matter (i.e. produce added value) should be standardized IMO. Eliminate mundane topics from the discussion to elevate the quality level. There are better things to do. That said readability, performance, simplicity, portability, ... still matter. A lot, I'd say.

Dictionary to level-off the communication

  • syntax - something that a parser can recognize e.g. PEG; the string 'function'
  • semantics - something that a parser can associate syntax to. e.g. AST/parse tree; the fact that the string 'function' is associated with the concept of a function
  • higher level stuff - paradigms (OOP, FP, LP, etc), models/concepts (monads, classes, etc), patterns (fluent, reactor, matching, etc). This higher level stuff also has semantics, but of a different kind

One thing well

Currently, programming languages (as well as, and probably derived from, human languages) grasp two sides of the story - form and content. Form (syntax and semantics) and content (higher level stuff). The good thing about human languages is that most are rather forgiving, and you end up with Swenglish, Spanglish, etc. You may keep the vocabulary, and change the construct, or the other way around, and the message may still go through. It's not the same with programming languages - both form and content need to be strict. And that's not a bad thing - it's even better.

Most of the talk is around the former side of the story - the form, and mostly from a thin and esthetic perspective. "This is how it looks in JavaScript, this is how it looks in CoffeeScript". That is not to say that form is not important, through the lense of readability and the shift of focus from boilerplate/pattern-driven-coding to real coding (solving the problem at hand; the algorythm). The other extreme doesn't take you far either IMHO - "syntax is the easiest to learn". I don't know what question that answers, but I think the question here should be what does that newer syntax give me? Why the learning curve when most programmers don't do the hard things?

Somewhere in the background comes the content, and most of the times, the content is the same. It's enough to take function. Now think of the variability of its definition/calling syntax across some languages that you know.

Use the right tool for the job

..except that today the job has a rather harsh deadline: yesterday. In this situation, I've heard enough talks: "we knew X, so we did it in X", or even worse skipping the "why?" altogether. Sometimes it goes a tad better: "we researched X, Y, Z, and Z was the best option, and X was the worst, except we had no experience with Z, but we knew X, so we did it in X". The walk-the-talk scenario is almost off the map, or at least I'm seriously unlucky and should get out more.

The spirit of the motto is IMO: you want to prototype, then the recommendation is paradigm X, VM x.1, syntax x.1.1, because of a, b, c. It can be the adoption level, the concepts, the requirements, etc. It is not IMO: you want to prototype, use whatever you know best, because that's the quickest. "Yeah, hmm, I know Latin, now lets sketch a tweet message in Latin."


I agree with, and I think I'm not in minority "Syntax is easy bit of learning new language, it's a RTFM. Semantics and practices the difficult bit.". That said, it's also pretty easy to have a shitty syntax that you cannot grasp, despite being 100% familiar with the rest.

The subtle addition is the variability of the syntax to be specific. If we look at OOP, the noise (=form) is rather obvious, though they share a great deal in both form and content.

So yes, syntax is the easy bit of learning a new language, but not if you have 100 languages around you. What we have today is a paradox of choice on the level of programming languages, and in that state of undecisiveness only two things predominantly win: convenience and form. Those are the easiest choices, unless you feel the guilt, the pressure, and then you make a random choice.

I have no Erlang hat to put on, but I'll take the plunge anyway: Elixir. Most of the Elixir tweets that I've encountered build the image that Elixir is a transpiler. It is not, but the form of the language is the one that hits first. And a great part of Joe's post on Elixir is about form as well. Then what am I missing: why invest energy into this, if it's all just RTFM? Why overly discuss or enforce comma-first styles? Oh, we inforce style guides in order to make diffs more readable, the code easier to change, etc. Well, in that case, change your PEG/other parser to allow only comma-first, provide linting and formatting tools. It is in that (automated) scenario that syntax will be the ignored bit, and not just the easy bit. If needed, in one commit you could rewrite the entire codebase because you switch the style, or you switch to a different "language" altogether, etc. This is NOT the same with a textual blind rewrite, or a grep/replace. It is a sound meta-programming exercise.


I am not a language nerd. I don't try a new language as soon as it sees the light of day. I coded in some, but way too few languages IMHO to say "I know what the f* I'm talking about". In terms of the paradox of choice, I escape the anxiety by not constantly looking for something better. I didn't design a language, I didn't write a compiler.. Nada. So anyway, by all means, I should probably just shut up.

It is going to be a roller-coaster implementing a rather scoped project in multiple languages, and I've realized that most of the work will be focused on the boring stuff - the form (syntax, stupid filesystem filenaming conventions, different package managers, etc). That was the cherry on the cake that made me realize this is nonsense. Programming languages are parsed strictly into a set of instructions, oftenly based on the exact or similar concepts. Translation to/from a syntax is trivial.

Above all, despite being raised in a liberal and western-minded family, I still lived 6 years under communism, and then some more in post-communism. The dictator-gene is alive and kicking, though it has mutated: when I do not know right from wrong, I want some expert to research and show me the way. I do not care if having or not having curly braces, comma-first or comma-last, defun or function, etc will make it better - easier to read, faster to parse, etc -, but if we agree this is not the important bit, then just freakin' decide as objectively as possible, rather than subjectively tweaking, feed the Did you drive a Volvo? interviews, and then also complain about it..


  1. it helps nobody when the form of X drives the analysis of X (though it does; marketing, pressure, context, etc)
  2. analyzing myself shows that if I really value X, then I need to minimize the variability of X's form (don't buy the new Coca-Cola bottle; the content is still the same as fill-in as before)

I'm pretty sure that just like in human cultures, there is more that unites our languages than stuff that keeps us apart.

Signed: a naïve rookie dreamer

Let me give more examples of bad understanding what is syntax and what is semantics.
"Use the right tool for the job" is a great motto. I read text translation from Erlang Factory and where was a report about this. But sometimes specialists (especially young specialists or students) don't get it. Once I heard question from a student: "Why should I use Erlang if Java is mainstream?". I think that Java is overrated language. Another student's phrase: "Learning Java I learn a ton of other languages like Java Script because of syntax, if I have time I'll probably learn other languages".
Another problems is "higher level stuff", as you named it. Students from previous examples don't understand why philosophy or paradigmas are so important. OOP is a little bit overrated too. I can see such situation: student, who know language X and learning language Y, solve the problem using language X first and then convert solution for language Y. It's wrong IMHO.
I have a little experience in Erlang, only about a year. But after Erlang some C++ constructions looks ugly for me.

Most of the people I come across that are willing to spend a lot of energy arguing about syntax minutia seems to know only some combination of these languages: PHP, Javascript, Ruby, Python. Since syntax is the largest (but not most important) difference between them, that's what they cling to.

For these languages I agree with you when you write "Programming languages are parsed strictly into a set of instructions, oftenly based on the exact or similar concepts. Translation to/from a syntax is trivial."

But if you've learned Forth, if you've built something real in a lisp and experienced the power of homoiconic macros, if you've used Erlang to the point that you see immutability as a feature and not a hinderance, if you've used Haskell to the point that you see its type system as a feature and not a hinderance, then you'll no longer consider all languages the same with only a veneer of syntax on top. And you'll discover more interesting things to argue about.

I still believe the broad strokes of syntax matters though, because I believe in the Sapir–Whorf hypothesis, and I believe it's very important for a programming language to let you express yourself succinctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment