Do scientists agonize over syntax as much as we do?

[Alexey Zinger]

Given one of our frequently recurring themes of what defines a language: syntax vs functionality, I found it amusing having come across this essay by a mathematician, called Pi is Wrong (http://www.math.utah.edu/~palais/pi.html), where Bob Palais argues in favor of changing the value of π.

I don't think Palais seriously expects all of the world's scientists, teachers, and curricula to switch over to the new π.  Rather, it's more of an illustration of how he feels mathematics got some of its syntax wrong, resulting in so much legacy on top of it.  It is so deeply ingrained in our minds that it will likely continue to cause some undue consternation 'til the end of the human race as we know it.  It's not so much a real limitation of expressiveness, but a certain clumsiness of notation.  Sound familiar?

 

Alexey

[Cédric Beust ♔]

2011/3/14 Alexey Zinger <inlin...@yahoo.com>

Given one of our frequently recurring themes of what defines a language: syntax vs functionality, I found it amusing having come across this essay by a mathematician, called Pi is Wrong (http://www.math.utah.edu/~palais/pi.html), where Bob Palais argues in favor of changing the value of π.

To be accurate, he's not arguing in favor of changing the value of π (which would be silly), he just thinks that the the value 2*π would be more useful. Some reactions in the scientific community that I've read seem to think that this idea has some merit.

I certainly agree that a few people in our community have a strange sense of readability, such as people who think that ":->>" is a fine name for a method (here is my original tweet) :-)

--
Cédric

[Kevin Wright]

On 14 Mar 2011 20:24, "Cédric Beust ♔" <ced...@beust.com> wrote:
>
>
>
> 2011/3/14 Alexey Zinger <inlin...@yahoo.com>
>>
>> Given one of our frequently recurring themes of what defines a language: syntax vs functionality, I found it amusing having come across this essay by a mathematician, called Pi is Wrong (http://www.math.utah.edu/~palais/pi.html), where Bob Palais argues in favor of changing the value of π.
>
>
> To be accurate, he's not arguing in favor of changing the value of π (which would be silly), he just thinks that the the value 2*π would be more useful. Some reactions in the scientific community that I've read seem to think that this idea has some merit.
>

Quite... Anything that would break Euler's identity just has to be wrong!

> I certainly agree that a few people in our community have a strange sense of readability, such as people who think that ":->>" is a fine name for a method (here is my original tweet) :-)
>
> --
> Cédric
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Reinier Zwitserloot]

If you had read the paper, you'd realize that with 'turn' (the proposed name for 2*pi), euler's identity gets prettier. e^(i*pi) is -1, but e^(i*turn) is +1. This is 'prettier'.

Technically this means euler's identity gets mangled to either:

e^(i*turn) -1 = 0

or simply:

e^(i* turn) = 1 + 0

but these manglings get to the heart of the non-perfectness of euler's identity: A 0 in a formula that involves addition / subtraction is kind of trivial anyway.

Certainly this:

e^(i* turn) = 1 is at least as amazing as the original euler's identity.

Getting back on topic: Sure. From time to time an alternative way just looks better, but there's far too much inertia to try and change the world, and there's far too much benefit in an implicit standardization on the old, assumed to be somewhat worse, way. Thus, nothing changes. Also, while the case of 'turn' is quite solid, in many cases its not as clear cut and there are hidden benefits to the old way that might not become immediately obvious.

In other words, the 'old' way has had years (for programming), even centuries (for math) of use, and thus the places where the old construct seems slightly more awkward than the proposed new one are very well known. This does not hold for the new construct - there'd be far less experience with where the new construct ends up being more awkward than the old.

<poking the bear> case in point: at first glance scala looks really cool, but after working with it for a month you realize every compiler error requires a team of rocket scientists to figure out </poking the bear>

This also goes to the heart of my theory about which programming languages end up in the 15%+ popularity zone (java, C, at one point fortran, etc): A language can't simply offer to be just plain better than an older one. It has to be better in a fundamental way, and this new fundamental way cannot be kludged in one of the current 15%+ popularity languages without such extreme pain nobody does it. This better way also has to be clear enough that non-users can actively tell that the grass is greener, so to speak.

Hence, java, which really offered no particular language feature improvements _at all_ and even replicated some pretty crappy ones, still entered the zone, because garbage collection, one standardized library, and (the promise of) WORA were things that C fundamentally could not properly offer, and it all came in a very familiar package (very C like syntax) to boot. PHP entered the zone because at the time it offered a unique option that no other language did: A security model that had the property of allowing very cheap hosting with no setup required at all other than uploading some static PHP files. The fact that these files usually were a copy/pasted mix of spaghetti mess riddled with security holes didn't actually seem to impede PHP's meteoric rise much. I'd think few would argue PHP is a language that really did anything interesting on the language design front (in fact, it's the nickelback of programming languages!), and yet its one of the few post 1990 languages that entered the zone.

Virtually every contender for 'next java' does not offer any single compelling argument to switch to it that's obvious even to casual/non-users. Taking scala as better than java as a given for a moment, then its rather clear to me that scala (or insert any other purported java.next here) is 'turn' to java's 'pi'. Of course we shouldn't just surrender and stop attempting to evolve programming altogether. Maybe I'm wrong :P

[Chris Winters]

On Mar 14, 10:08 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> ...

> actually seem to impede PHP's meteoric rise much. I'd think few would argue
> PHP is a language that really did anything interesting on the language
> design front (in fact, it's the nickelback of programming languages!), and
> yet its one of the few post 1990 languages that entered the zone.

PHP: the nickelback of programming languages. Thank you for adding
this phrase to my vocabulary.

Chris

[Eric Jablow]

On Mar 14, 4:20 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
> 2011/3/14 Alexey Zinger <inline_f...@yahoo.com>

>

> I certainly agree that a few people in our community have a strange sense of
> readability, such as people who think that ":->>" is a fine name for a

> method <http://twitter.com/#!/psnively/status/47304518869848065> (here is my
> original tweet <http://twitter.com/#!/cbeust/status/47151793817403392>) :-)
>

I do wish that Java would allow Unicode equivalents for certain
operators. In a
UTF-8 source code file, if (a ≤ b) seems preferable to if (a <= b).
> --
> Cédric

Eric

[Alexey Zinger]

This is why we need AST-based editors/revision control systems.  Then we can leave language spec's good enough alone and allow people to work with whatever representation of language that pleases them (same as we allow people to set their own editor font or tab length).

 

Alexey

---

From: Eric Jablow <erja...@gmail.com>
To: The Java Posse <java...@googlegroups.com>
Sent: Tue, March 15, 2011 11:11:19 AM
Subject: [The Java Posse] Re: Do scientists agonize over syntax as much as we do?

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsub...@googlegroups.com.

[Cédric Beust ♔]

Well, that's a slightly different debate and I'm feeling a bit more open to that idea. I think it's important for identifiers to contain a minimum number of English words so that you can actually understand and pronounce that name out loud, but non alphabetical characters should make up a very tiny proportion of such names. I can't really come up with a good example off the top of my head, though (e.g. "convertToDegrees()" -> "convertTo°()").

--
Cédric

[Kevin Wright]

There's no clear answer here, API's evolve in much the same fashion as spoken language, with commonly used terms being abbreviated. This is also domain specific, so >>= is perfectly acceptable in Haskell, where it represents a core pattern used in that language.

I reckon it's okay for a concept to have an operator so long as it's widely enough used, and has a pronouncable alternative.

Such as in Cédric's example, where I would read the -> operator as "maps to"

> --
> Cédric

>
>
>
> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.

> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[mP]

For me some people might think that symbols are more appropriate than English keywords, especially as not everyone speaks English, and some roman letter text looks almost the same as some random glyphs. Then again that argument is nonsense as most APIs and documentation are in English however this might change as the web grows in non Western societies, especially in the large world of places like China. If one day China decides to write up java.net and to make all APIs in Chinese (forgetting how hard it is to type w/ Chinese pictographs) what does that mean for language design in the future ? This movement has already started with the standardization that opened up non ascii domain names so people in Russia etc can type in their own alphabets rather than the Roman alphabet.

Should languages prefer language neutral tokens such as symbols over keywords ?

[Roland Tepp]

On Mar 18, 2:11 am, mP <miroslav.poko...@gmail.com> wrote:
> the large world of places like China. If one day China decides to write up
> java.net and to make all APIs in Chinese (forgetting how hard it is to type
> w/ Chinese pictographs) what does that mean for language design in the
> future ?

Funny you should mention this. About a year ago I bumped into an
experimental language called Ioke[1].
Among other things, the language designer concocted a sample
application in Traditional Chinese[2] and since then he has added more
language versions[3]... Apparently just for the fun of it :)

[1]: http://ioke.org/
[2]: https://github.com/olabini/ioke/blob/master/examples/multilang/chinese/account.ik
[3]: https://github.com/olabini/ioke/blob/master/examples/multilang/