sweet syntactic sugar
consider the following chunk of code: List<Person> people = db.GetAllPeople();
foreach (Person p in people){
console.writeLine(p.Name);
}
Day dreaming during a tech.ed lecture this morning, I thought: Ah, but what if the syntax waz reversed?What if the following code compiled to the same thing under the hood.... List<Person> people = db.GetAllPeople();
in (people visit Person p) {
console.writeLine(p.Name);
}
Okay... it mightn't change our lives... but it's a wacky thought none the less. Don't reject it too quickly. Drink it in. Suck it up. Chew on it. Swill it around before you spit it out. When you type the words "in (people visit..." the intellisense would have a chance to think: people hey?? What type of objects are collected inside that? Person is... You'd get a nice little intelliswiftness in there i thinks. Nextly, whatif, instead of calling a Object.Method(), we allowed the syntax: Method Object, for example, instead of: console.writeLine(p.Name);
Imagine you were allowed to say: WriteLine Console (p.Name);
That's right! Method First, Object Aft!When you write the method name "Writeline" the intellisense then thinks to itself... Writeline hey?? What objects do i have with that method? What static methods do i have with a method like that? This is a different kind of intellismarts you're calling on -- it's about putting verbs before nouns, like that steveyegge article joel spolsky pointed to recently (you know the one). tink about it.
'Ilan Assayag' on Wed, 23 Aug 2006 08:31:07 GMT, sez: Usually I like your ideas, but this time I disagree. Regarding the "method first" idea - I might be too used to the current "object first" approach and reluctant to let go, but I think there is a linguistic explanation to why objects are put first.
The statement: Object.Method(Target)
would be translated in English to: "Object applies Method to/with Target"
Reverse it as you proposed: Method Object (Target)
and you get the phrase: "Method is applied by Object to/with Target"
I'm not a native English speaker, but I think that the second type of phrase is more fluent and understandable.
'Alex' on Wed, 23 Aug 2006 08:57:26 GMT, sez: While I'm not sure if I really like the "in(){}" aproach, the Method-first thing was a great syntacticly valid construct that did wonders for writing poems in Perl (though, I'm not convinced that "it can be made to look like English!" is something one should really strive for in a programming language).
'SimonH' on Wed, 23 Aug 2006 09:41:09 GMT, sez: Ilan,
I think the English translation would be "Method the Object with the Target" which works. For me, at any rate.
Leon,
On the face of it, I like what you're saying, but I smell a rat.
I already worry about how much I rely on Intellisense. Sure, sure, I'm way more productive these days (I even installed the SQL Prompt trickery that, I think, you recommended and that has, frankly, changed my life) but whenever I drop back to a text editor to do something that doesn't warrant the use of the whole IDE, I turn into an idiot. Fingers, brain, method names, parameters, duh. It's only by sheer force of will (okay, and context) that I haven't hit Ctrl-Space in this textbox (yet).
You're trying to make me even more stupid and I'm not likin' that.
I should turn it off. But, damn, I like it. It's like smoking.
'Mark Allanson' on Wed, 23 Aug 2006 10:05:40 GMT, sez: Ah - The problem I have with this is that it forces me to remember the entire object model.
I don't want to have to remember the entire .net object model, or the object model of my own code. Unfortuntely intellisense can't guess the method I want to call on an object I have not yet specified :)
regarind the loop constructs, I like Ruby's way of doing this, using anonymous methods.
--8<------
myCollectionObject.each { |anObject|
// Do some work on the object
}
--8<------
'Thomas Eyde' on Wed, 23 Aug 2006 10:53:57 GMT, sez: Intellisense could do just a good job on looking up methods as it looks up types and variables.
And if we replace 'method' with 'message' we get: Send 'message' to 'object' with 'data'. Sounds nice to me, but I am stuck in C#.
You aren't sniffing on L#, are you?
'Kris' on Wed, 23 Aug 2006 11:16:04 GMT, sez: You could call it Yoda#...
'Zooba' on Wed, 23 Aug 2006 11:19:44 GMT, sez: So we're back to implementing quasi-OO using procedural techniques. Hey, it worked for years until some people got in there and decided that the data was more important than what you are doing to it.
Spot the difference:
void Customer::setName(const char* newName);
void setName(Customer* cust, const char* newName);
Answer:
One is suitable for teaching to students. The other is spaghetti code.
Serious Answer:
Nothing at all.
'Carl' on Wed, 23 Aug 2006 11:27:23 GMT, sez: Like Mark, I like the anonymous method way of doing things, like in C# 2.0:
people.ForEach(
delegate (Person p)
{
Console.WriteLine(p.Name);
}
);
'Roland Kaufmann' on Wed, 23 Aug 2006 11:35:34 GMT, sez: Or what about this syntax (the parenthesis have been moved):
(WriteLine Console p.Name)
Hmm... Seems like we have just reinvented Lisp. :->
'Eber Irigoyen' on Wed, 23 Aug 2006 13:55:37 GMT, sez: check this out, it's exactly how L# does it
http://www.lsharp.org/primer.html
"(writeline console "Hello World")"
'Kurtiss Hare' on Wed, 23 Aug 2006 19:35:40 GMT, sez: The compiler already does some similar magic with properties, so why not just forgo the loop variable altogether:
PersonCollection people = GetPeople();
foreach (people)
{
WriteLine(value.Name)
}
foreach (Range(0, people.Count))
{
WriteLine(people[value].Name)
}
There's no reason for you to have to even consider the type of the loop variable while you're defining the collection over which to iterate...
'lb' on Wed, 23 Aug 2006 20:55:52 GMT, sez: Top responses people!! I am blown away!
I've been reading about F#, but haven't read about L# yet.... it's on The List.
Regarding english language-ness of queries, i think
You might say "Throw the ball" which is more like the code: "Throw Ball" and less like the current "Ball.Throw".
I don't really like the "method first" idea much -- i was thinking though that it might have some kind of relevance to "extension methods"... combined with generics (or even "pattern matching" [my new favourite concept])
You might say -- "hey all of these wildly different types should have a throw method" and write a generic throw method that be applied to say "ball, piano, bottle, shoe" -- and... ah okay, i'm thinking myself off the deep end here, forget it.
cheers
lb
'Mike Woodhouse' on Thu, 24 Aug 2006 07:01:49 GMT, sez: "people.ForEach("
Do we know how far the Queensland University folks are along with Ruby.NET.....?
'JonR' on Thu, 24 Aug 2006 07:47:25 GMT, sez: step away from the IDE.
slowly...slowly....
'WaterBreath' on Fri, 25 Aug 2006 19:34:19 GMT, sez: > You might say "Throw the ball" which is more like the code: "Throw Ball" and less like the current "Ball.Throw".
Since "throw" is not something a ball does, it wouldn't likely be a method on the ball object (at least not for a suitably world-wise OO programmer), but on the object that _does_ the throwing _of_ the ball.... Then we're back to yoda speak if you go method-first.
> I don't really like the "method first" idea much -- i was thinking though that it might have some kind of relevance to "extension methods"... combined with generics (or even "pattern matching" [my new favourite concept])
If we're looking at the goal of making things more English-like (or just about any language that uses the Latin alphabet), then it would be nice not to have to specify the object to whom we are dictating (since face it, that's really what a program is: dictation of imperatives). Imperative sentences in English, and other western languages, often leave off the subject, because it's previously established.
IIRC, the VB language has (had?) syntax for this, something like below:
WITH arm
.throw ball
END WITH
A modern evolution of that could surely be more like a human language, or at least more evocative of human language. Even just replacing "WITH", with a more language-related verb, such as "address", would maybe be nice. Just a thought.
> You might say -- "hey all of these wildly different types should have a throw method" and write a generic throw method that be applied to say "ball, piano, bottle, shoe" -- and... ah okay, i'm thinking myself off the deep end here, forget it.
OR you might say that hey, just about anything can be thrown, contingent upon the thrower's possession of an arm-like mechanism, and the arm's ability to lift the object (which is contingent upon the size and shape of the thrower, and the size, shape, and weight of the throwee.
OO people will see a perfect opportunity to create an Arm base class, exposing things such as size, shape, and strength, as well as a throw method that takes an object exposing a Throwable interface, which exposes things such as size, shape, and weight.
Fucntional-language people will say to heck with inheritance. Just write a throw function that takes two arguments: thrower and throwee. Refer to the presumed properties. If they have them, great. If not: error.
|
secretGeek .:dot Nuts about dot Net:.
Just Wally
Complete secretGeek Archives
The Best Software Writing I
The Business Of Software (Eric Sink)
