I hope that this term catches on sometime soon, but the fact remains that I am
introducing this term. Still, I think that it's a
GoodThing:
Syntactic dark chocolate is a variant of both
SyntacticSalt and
SyntacticSugar that makes things easier to write, but ensures that you know what you are doing, too. Example: A version of a language with
MultipleAssignment (like Python) but not
AssignmentsAreExpressions, might implement
AssignmentsAreExpressions like so:
c += ( _ = a = b)
Which is
SyntacticSugar for
a = b;
c += a # which you would have to do in Python.
and
SyntacticSalt for
c += (a = b) //which is OK in C/C++/C#/pretty much every type of C.
There doesn't seem to be a language that actually has the above example, but differentiating
EqualityOperators,
KeywordArguments, and
AssignmentsAreExpressions would be a good use of
SyntacticDarkChocolate.
Thanks for the term. Per
PythonVsRuby (unread by yours truly), the folks with the least differences always fight the hardest.
Yet everything that Pythonistas scoff that Ruby should not allow you to do (such as the holocaust of
if x = foo() then use(x) end), Ruby is letting you reduce your line count by doing it.
This
SyntacticDarkChocolate is better for you than sugar. It's what gives you 1/10th the lines of code and 10 times the productivity as a
BondageAndDiscipline language. Those "one line of code here and there" is what adds up. At refactor time, you suddenly discover you can keep pushing, and pushing, and pushing, and stuff just vanishes.
--
PhlIp (with two years experience doing
TestDrivenDevelopment in
PythonLanguage and two more in
RubyLanguage)
You provide no cogent reason to believe that
SyntacticDarkChocolate is better than
SyntacticSugar for saving "one line of code here and there", and it isn't as though
BondageAndDiscipline languages lack their own funky syntax mechanisms that can save a line here and there. Certainly
"1/10th the lines of code and 10 times the productivity" is a ridiculous exaggeration, especially if comparing to Python. If comparing to a language with manifest typing, separate compilation and linking, and other sorts of bureaucratic hoops it might be a reasonable assertion. But Python and Ruby (and Perl, and
JavaScript) - primarily procedural scripting languages all - have nearly the same LoC profile when applied to similar tasks (according to
http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html). If you're experiencing such a difference between Ruby and Python, perhaps the difference is in
you (who has more experience), or in your libraries and frameworks (which would be reinvented in the new language with more knowledge, avoiding old mistakes), and not in the language proper.
CategoryProgrammingLanguage