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.
- 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
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.
..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..
- it helps nobody when the form of X drives the analysis of X (though it does; marketing, pressure, context, etc)
- 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.
Related stuff: