Re: Magic features of programming languages
On 22/05/2011, at 11:17 PM, Frank Wales wrote: Blimey, are we top-posting or bottom-posting in this discussion? Anyway... The original question was about whether there were studies on the effect of 'magic' features, but we seem to have devolved into a show-and-tell of them instead. I wonder whether one person's 'magic' is another person's failure to RTFM, Case in point: in Erlang an anonymous function can have more than one clause, e.g., fun (X, Y) when X = Y - X ; (X, Y) when X Y - Y end There has recently been a long thread in the Erlang mailing list triggered by one user's exposure to this. Amongst other things he was highly critical of the Erlang documentation for not explaining that this was possible. If you look in the Erlang reference manual, the very first example in the section on anonymous functions shows multiple clauses. It even precedes any of the text in that section. Apparently the Erlang documentation was not, by that programmer, thought to include the reference manual. Perhaps it's possible to discover when the benefit of magic is outweighed by the curse of the confusion it also brings. But the real trick would then be to get language designers to pay attention to the results of such work, and to make their languages more usable by being less magical. A sufficiently advanced technology is indistinguishable from magic. A serious question: how do we -tell- whether something should count as a really useful feature and when it should count as magic? Should we always be thinking about the needs of people working in a language they have not studied thoroughly, or is it ever acceptable to say well, you have to read this ~200 page book first, and keep dipping into it until you feel comfortable? Some of he examples I've seen mentioned in this thread are clear discontinuities in the language, where are some arbitrary point things of the same kind stop working one way and start working another. The Erlang example above is not one of those: it's a case where _every_ control structure in the language allows multiple clauses, and anonymous functions are _not_ an exception, even though that's unusual across languages. Can something like that count as magic? -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England Wales and a charity registered in Scotland (SC 038302).
Re: Magic features of programming languages
PDP-8 had auto-increment locations down in low memory in similar style. I suppose the device addressing through memory on lots of machines counts as magic too, L. Sent from my iPad On 22 May 2011, at 06:39, Thomas Green green...@ntlworld.com wrote: Kevlin Henney wrote: To really demonstrate autoboxing you need to allow the compiler to convert from int to Integer: Integer x = 1000; Integer y = 1000; However, if you are after interesting counterintuitive corner cases, change the constant to 100: Integer x = 100; Integer y = 100; A direct equality comparison will now compare true because, by default, the JVM caches the Integer objects for values from -128 to +127 (the range can be extended as an optimisation). In other words, your corner case has a corner case. Magic. Back in the sixties, the autocode for the Atlas machine at Harwell had a fine piece of magic. As an outsider, I could book for an occasional week there, and while I was there I could run programs twice a day iirc. I once spent two of those 7 days trying to find out why my program wouldn't work, panicking desperately about meeting my target, before discovering that of its 128 registers (called B-lines), the one I had chosen to use was fitted with a hardware conversion to return log-2 of any quantity stored in it. All the higher-numbered B-lines silently did special things, apparently. Great if you knew about them. Tough otherwise. (For those of you who came late to the party and missed the early days, an 'autocode' was a slightly-Englished version of machine code. Bit like a penny-farthing - if you stayed on, people admired you, but when you fell off it really showed.) Thomas -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England Wales and a charity registered in Scotland (SC 038302).
Re: Magic features of programming languages
Blimey, are we top-posting or bottom-posting in this discussion? Anyway... The original question was about whether there were studies on the effect of 'magic' features, but we seem to have devolved into a show-and-tell of them instead. I wonder whether one person's 'magic' is another person's failure to RTFM, and if the question should really be about accepting that it is inevitable that helpful defaults and syntactic short-cuts will also be seen as unexpected traps and incomprehensible flakiness by those who don't have time, or inclination, to read before they write. Particularly now, when programmers often have to dip into a language that they're not deeply experienced in to do something quickly, it's hardly surprising when they get confused by Javascript's apparently non-commutative comparison operators, perl's veritable buffet of syntactic exceptions, or CSS's hyperdimensional boxes. Perhaps it's possible to discover when the benefit of magic is outweighed by the curse of the confusion it also brings. But the real trick would then be to get language designers to pay attention to the results of such work, and to make their languages more usable by being less magical. Lindsay Marshall wrote: PDP-8 had auto-increment locations down in low memory in similar style. I suppose the device addressing through memory on lots of machines counts as magic too, L. Sent from my iPad On 22 May 2011, at 06:39, Thomas Green green...@ntlworld.com wrote: Kevlin Henney wrote: To really demonstrate autoboxing you need to allow the compiler to convert from int to Integer: Integer x = 1000; Integer y = 1000; However, if you are after interesting counterintuitive corner cases, change the constant to 100: Integer x = 100; Integer y = 100; A direct equality comparison will now compare true because, by default, the JVM caches the Integer objects for values from -128 to +127 (the range can be extended as an optimisation). In other words, your corner case has a corner case. Magic. Back in the sixties, the autocode for the Atlas machine at Harwell had a fine piece of magic. As an outsider, I could book for an occasional week there, and while I was there I could run programs twice a day iirc. I once spent two of those 7 days trying to find out why my program wouldn't work, panicking desperately about meeting my target, before discovering that of its 128 registers (called B-lines), the one I had chosen to use was fitted with a hardware conversion to return log-2 of any quantity stored in it. All the higher-numbered B-lines silently did special things, apparently. Great if you knew about them. Tough otherwise. (For those of you who came late to the party and missed the early days, an 'autocode' was a slightly-Englished version of machine code. Bit like a penny-farthing - if you stayed on, people admired you, but when you fell off it really showed.) Thomas -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England Wales and a charity registered in Scotland (SC 038302). -- Frank Wales [fr...@limov.com]
Re: Magic features of programming languages
Kevlin Henney wrote: To really demonstrate autoboxing you need to allow the compiler to convert from int to Integer: Integer x = 1000; Integer y = 1000; However, if you are after interesting counterintuitive corner cases, change the constant to 100: Integer x = 100; Integer y = 100; A direct equality comparison will now compare true because, by default, the JVM caches the Integer objects for values from -128 to +127 (the range can be extended as an optimisation). In other words, your corner case has a corner case. Magic. I consider that just poor design on the part of the Java designers. Any language that has multiple distinct representations for the same set of values, that aren't entirely semantically equivalent without explicit conversions, is just broken. In Java's case, it's just a performance hack embedded into the language that wasn't a good idea to start with, and that's just sprawled and mutated over versions into something clumsy and brittle. Now, if you want examples of magic, probably the best place to look is perl, which is filled with the stuff, as tasty cheese is filled with mould. Here, let me show you it: http://stackoverflow.com/questions/161872/hidden-features-of-perl -- Frank Wales [fr...@limov.com] -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England Wales and a charity registered in Scotland (SC 038302).
Re: Magic features of programming languages
Kevlin Henney kev...@curbralan.com writes: In other words, your corner case has a corner case. And they let children play with this stuff? Peter. -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England Wales and a charity registered in Scotland (SC 038302).
Re: Magic features of programming languages
Kevlin Henney wrote: To really demonstrate autoboxing you need to allow the compiler to convert from int to Integer: Integer x = 1000; Integer y = 1000; However, if you are after interesting counterintuitive corner cases, change the constant to 100: Integer x = 100; Integer y = 100; A direct equality comparison will now compare true because, by default, the JVM caches the Integer objects for values from -128 to +127 (the range can be extended as an optimisation). In other words, your corner case has a corner case. Magic. Back in the sixties, the autocode for the Atlas machine at Harwell had a fine piece of magic. As an outsider, I could book for an occasional week there, and while I was there I could run programs twice a day iirc. I once spent two of those 7 days trying to find out why my program wouldn't work, panicking desperately about meeting my target, before discovering that of its 128 registers (called B-lines), the one I had chosen to use was fitted with a hardware conversion to return log-2 of any quantity stored in it. All the higher-numbered B-lines silently did special things, apparently. Great if you knew about them. Tough otherwise. (For those of you who came late to the party and missed the early days, an 'autocode' was a slightly-Englished version of machine code. Bit like a penny-farthing - if you stayed on, people admired you, but when you fell off it really showed.) Thomas -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England Wales and a charity registered in Scotland (SC 038302).
Magic features of programming languages
Hi all,
When a construct is ambiguous, sometimes language designers will provide
a default which (they hope) does the right thing in the common case. An
example is XPath. When = is called on two sets, the semantics are that
there is at least one pair of elements (one from each set) that compare
equal, i.e. that their intersection is non-empty.
This is arguably counter-intuitive. For example, if an XML node
represents an item from a catalog that comes in multiple colors, and you
ask whether item1.color = item2.color, in some situations you'd be
surprised that {Red, Green, Blue} was considered the same as {Red,
Yellow}. Other times it's natural, e.g. when you want all items that
come in Red.
I have a hunch that, when a concept is genuinely ambiguous, providing a
default leads to copy-and-paste programming where programmers don't
really understand how a feature works, so they just use it in a few
canonical forms. Even though there is a simple semantics that's easy to
describe, they won't find that semantics unless they look in the manual,
and many people don't. Instead, they just think it's magic and become
confused when they try to do complicated things with it.
Have there been any studies that include a look at such magic
features? Scripting languages typically favor conciseness, and thus can
have a fair bit of magic.
Thanks,
Martin
--
The Open University is incorporated by Royal Charter (RC 000391), an exempt charity
in England Wales and a charity registered in Scotland (SC 038302).
Re: Magic features of programming languages
John Daughtry brings up a much better example: autoboxing in Java. My
favourite corner case:
Integer x = new Integer(1000);
Integer y = new Integer(1000);
x y // Compares the underlying integers: false
x y // Compares the underlying integers: false
x == y // Compares the two objects: false
Best,
Martin
Original Message
Subject:Re: Magic features of programming languages
Date: Fri, 20 May 2011 12:31:53 -0400
From: John Daughtry j...@daughtryhome.com
To: Martin C.Martin mar...@martincmartin.com
I don't have a reference, but a more general example...
A great well-known example of this problem being introduced to a
language is auto-boxing in Java
... and the problems it creates when combined with the collections
classes. Bloch outlines this in detail in Java Puzzlers. Why doesn't
this work?
1 myList.add(10); //we now have {10}
2 myList.add(1); //we now have {10,1}
3 myList.remove(1); //we now have {1} but we expected {10}
Line 1 uses autoboxing to invoke the method add(Object) while line 3
just calls remove(int).
The magic, once combined with other features, turned into an
unintuitive mess. It gets even crazier
John
On Fri, May 20, 2011 at 11:46 AM, Martin C.Martin
mar...@martincmartin.com mailto:mar...@martincmartin.com wrote:
Hi all,
When a construct is ambiguous, sometimes language designers will
provide a default which (they hope) does the right thing in the
common case. An example is XPath. When = is called on two sets,
the semantics are that there is at least one pair of elements (one
from each set) that compare equal, i.e. that their intersection is
non-empty.
This is arguably counter-intuitive. For example, if an XML node
represents an item from a catalog that comes in multiple colors, and
you ask whether item1.color = item2.color, in some situations you'd
be surprised that {Red, Green, Blue} was considered the same as
{Red, Yellow}. Other times it's natural, e.g. when you want all
items that come in Red.
I have a hunch that, when a concept is genuinely ambiguous,
providing a default leads to copy-and-paste programming where
programmers don't really understand how a feature works, so they
just use it in a few canonical forms. Even though there is a simple
semantics that's easy to describe, they won't find that semantics
unless they look in the manual, and many people don't. Instead,
they just think it's magic and become confused when they try to do
complicated things with it.
Have there been any studies that include a look at such magic
features? Scripting languages typically favor conciseness, and thus
can have a fair bit of magic.
Thanks,
Martin
--
The Open University is incorporated by Royal Charter (RC 000391), an
exempt charity in England Wales and a charity registered in
Scotland (SC 038302).
