Wednesday, December 21, 2005
I've been thinking about properties and mixins. Take the following example, with my completely made-up syntax.
Words as (string):
return self.Split(' ', ';', '.', '!') #Doesn't work, no implict conversion to char
As far as code goes, its pretty simple. Infact, this could easily be a method.
def Words(target as string):
return self.Split(' ', ';', '.', '!')
Then you, know, Words("Hello, world!") is just as effective as "Hello, world!".Words.
But sometimes, being able to do something one way doesn't necessarily mean its better than doing it another way. This kind of syntax blends very well with the way of the OOP, and allows for a better visual recognition of what object is being manipulated.
The flip side is, of course, "Is Words part of System.String, or an extension?"
My answer is, "Does it matter?" Do you really need to know wheither its an external function or an instance function? Well, that would be my answer in an ideal system, where extensions showed up when you used reflection on a type. Right now, they don't, though, so knowing the difference between an extension and instance members is important if you plan on doing reflection-based operations on a type at runtime - you'll have to root around in some namespaces for those extensions rather than just checking the members of a type.
Tuesday, December 20, 2005
Monday, December 19, 2005
Ugh. I think I should get a new blog somewhere else. That's ridiculiously pathetic.
The WinFX December CTP has been dropped to the public at large. The one big change I'm sure everyone has noticed by now is that, aside from a few minor tweaks, the "mini language" of XAML has been removed entirely. Bits and chunks have been removed piece by piece, but the December CTP finally sees the removal of the last straggling hold-outs.
If you're not sure what I'm talking about, here's a snippet from Chris Sells' blog:
Or, rather, you would be seeing a snippet, if Blogger's posting control what's it didn't suck an incredible amount of ass. Infact, I just had to copy and paste the text here to note-pad and back, because Blogger's state of the art RTF control forgot to close a tag. Thanks, bitch. Anyway:
Its under the general section.
Anyway, thank God.
By making the format more rigid in terms of syntax it means that XAML won't become the kind of mess the SVG spec turned out to be; and as someone who once wrote a SVG-to-VG transformer, I know exactly the kind of pains in that spec. Taking the "convenience" out of the spec means that there's no ambiguity or multiple ways to parse one attribute.
These file formats aren't meant to be written by hand, damn it. Tweaked? Sure. WRITTEN? No. Its harder to automate this junk when there are seven different *valid* ways to write something. The easier it is to programmatically consume XAML the more tools will crop up that can read/write XAML and modify it.
No, sorry, VIM is not a good example of a tool. I mean *REAL* tools, like Sparkle, Cider, #develop.
Sunday, December 18, 2005
Andrew Orlowski apparently spent several hours on Wikipedia today trying to track down something to make Wikipedia look bad. Took him awhile, but he finally found something in the revision log: vandalism claiming that the Wikipedia founder was murdered by a friend. Like all incredibly bad journalists, he cropped out of the revert time, so even though the vandalism was corrected within minutes, he decided to "only" take a screenshot of the edits, rather than the edit times.
Ahh, quality journalism from The Register strikes again. Tell me why I shouldn't trust Wikipedia more than those guys, again?
Read more at www.theregister.com/200...
Friday, December 16, 2005
For the sake of brevity, I'll model this blog post after the things I don't like about the language, and modifications I would make. There are too many things about the language I really like, so starting off like that would really eat up some time.
To get one thing straight, I'll pop up this disclaimer: I know nothing about functional programming. At all. I just tend to drill into a language, ignoring the design methodologies that went into and whatever. So, make no mistake: I have no idea what I'm talking about.
Things I would change:
- The match construct throws an exception if there is an unmatched item. This is suprisingly useful in theory; in practice however the exception provides so little detail that its barely worth it. It should at least spit out what the match variable was. C'mon man, gimme a hint or something, Christ.
- The match construct syntax. The match construct is powerful - it is easily the sweetest thing I've laid eyes on. But the syntax is the ugliest I've ever seen. Personally, I would just totally rip Boo's "given when" syntax and call it "match when" and whistle innocently. The problem with the match syntax is that its completely foreign to everything else in the language for no apparent reason. I cannot think of one reason for the syntax to be laid out in such a hard to type (finger acrobatics, maximum!) and hard to stare at manner. It looks like a twitchy, "shit, let's just do what the old guys did" implementation. I'd 21st century-ize that sucka.
- Explicit return statements. Recently, a pattern I've developed is using return statements to avoid processing the rest of a method without having to drop an exception. This is extremely handy for methods that can return null, or a default object. This seems thoroughly impossible with Nemerle, unless you're willing to use the match construct at the very beginning of a method. This of course means two or three relatively small match bodies, and then one huge match body for the "rest" of the method. I like implict returns, but I wanna be able to be explicit, too.
- N10005. The reason Nemerle sample code is littered with ignore() functions. The reason sample code scrolls an entire screen of N10005's because nobody wanted to type ignore() everywhere. Man, that might be cool or hip when you're running on a framework where every return value is important, but some of the time all it this return data is, is extracellnous information that we don't need. I don't really wanna type ignore(). I'm sorry. I don't. I'm lazy.
- Fuse braces and indentation. Boo/Python really turned me on to indentation based syntax. Hell, I was going to indent anyway. I would fuse'em in Nemerle: start a block with a brace, end a block with a brace. Otherwise, use indentation for syntax. There we go. Kung-fu with both syntaxes, now. Nemerle offers an -i switch, but that's almost as good as not offering indentation-based syntax at all.
Anyway, that's it. There. I posted a blog entry. Now, don't expect another one for awhile.