Just wanted to say thanks to the Mozilla folks for having the guts to put Ogg in the browser. I know it won't have a deep impact overnight, but I think it might have deep long-term impacts.
Project idea for the willing and able: Make the video tag work cross browser. Swap via JS to Flash (or Silverlight or Quicktime or Java or ...) if video's not supported, automatically picking a different source. And make the paired sources easier to prepare on the server.
I guess the down side is that no one distributes video themselves, due to the large size, but maybe such a project would encourage the Vimeos, Hulus, and YouTubes of the world to consider support for open video. The goal in this case would be to make it easy for them to swap to Ogg (or whatever) video when Flash is unavailable.
Bonus points to Firefox if they ever get Canvas 3D in there. Even better to have an additional integrated mode for content inside and out of a 3D scene graph. (I suppose shouldn't get my hopes too high for Bullet physics ...)
Tuesday, June 30, 2009
Thursday, June 25, 2009
Fan vs. Scala: Type System
It's been a while, but here's my next installment of detailed discussion of my personal reasons for preferring Fan to Scala. Here is my next claimed advantage:
2. In Fan, you don't have to figure out existential types or other complex typing. Fan will even do your casting for you in many cases.
There's a huge debate about dynamic vs. static typing. I like static typing (because of easier toolability, performance, and hints for the programmer but yes I know there are pros and cons). I don't like typing to get in my way. That means I only want to say as much as I want to say. That is, infer where possible, and sometimes I just don't care what's co or contravariant. (Oh, the blasphemy!) I also don't want the type system to tie me in knots. Sometimes static enforcement blocks me from doing something correct the way I want to do it, even if other times it catches my mistakes.
Both Fan and Scala (and C# and others) do limited type inference. Usually, you have to specify types for public methods and such. Sure, they could be inferred in some cases. Some languages do that, but I like it to be explicit. The exact limits of type inference differ among these languages, but most of the focus is on local vars. For example (in Fan):
In Fan, ':=' is used for var initialization as opposed to the 'var' keyword in Scala or C#. You even use it when specifying an explicit type for the var, just for consistency. I like either style better than the "guess where the var is defined" behavior you get in Python or Ruby. (Actually, Python has fairly simple rules, but they can get annoying sometimes. I've heard Ruby is cleaning up their ambiguity in this arena, too.)
But, anyway, my discussion had more to do with this list of features from Scala.
1. Abstract Types
2. Existential Types (officially not recommended except for interoperability with Java, is my understanding)
3. Generics
4. Type Bounds
5. Variances
6. Views
And probably things I'm forgetting. Yes, the type system is serious in Scala. They want to you get it right. Personally, I see the need for awesome static typing in a language like OCaml that has no dynamic type safety (no casting exceptions) but still wants to be type safe and avoid security risks.
But in a language with dynamic type safety (like Java or ducky languages like Python, JavaScript, or Ruby), how often do you really see casting exceptions? If I make a mistake, it will be found (rather than opening security holes), and I don't usually make mistakes.
So, to make life easy, Fan will do your casting (up or down a hierarchy) automatically. For example (in Fan):
In Java, you'd have to make that second cast explicit, being a down cast. Welcome to "I don't need generics to have my casting done for me" land.
And while I know that Scala folks will be all over me about this feature of Fan, think first about Scala's automatic type conversion. Fan only casts for you (yay! in my book). Scala, for all its type safety will magically convert integers into strings, if you set up the right magic. I'm personally really scared of automatic variable swapping going on behind my back. It's also something I dislike about C#.
One thing that I don't like about Fan is its lack of generics (except for Lists, Maps, and Funcs). Yep, I like generics (despite my list above on Scala). I just want autocasting and arbitrary support for co and contravariance. I'm a hippie that way. I think Scala's generics go too far. So really, I'd prefer some land in between Scala and Fan on the generics front. But between the two, I'll take Fan.
Side note, Fan also supports dynamic duck typing. If you say, "myVar->something", that does a dynamic lookup rather than the static form "myVar.something". Note that this is different from duck typing support in languages such as C#, Boo, and haXe, where method calls look the same, but the variable type is declared to be dynamic. The two styles have different effects on your code. Scala shuns dynamic typing in favor of static structural typing. I'm not sure either take is fully necessary, but between the two (duck typing vs. structural), I'd prefer structural. I just don't want the rest of Scala typing with it. Sorry for being too quick to find good links, but Google can probably help out.
I'll give at least one link, though, to the official description of Fan's system.
2. In Fan, you don't have to figure out existential types or other complex typing. Fan will even do your casting for you in many cases.
There's a huge debate about dynamic vs. static typing. I like static typing (because of easier toolability, performance, and hints for the programmer but yes I know there are pros and cons). I don't like typing to get in my way. That means I only want to say as much as I want to say. That is, infer where possible, and sometimes I just don't care what's co or contravariant. (Oh, the blasphemy!) I also don't want the type system to tie me in knots. Sometimes static enforcement blocks me from doing something correct the way I want to do it, even if other times it catches my mistakes.
Both Fan and Scala (and C# and others) do limited type inference. Usually, you have to specify types for public methods and such. Sure, they could be inferred in some cases. Some languages do that, but I like it to be explicit. The exact limits of type inference differ among these languages, but most of the focus is on local vars. For example (in Fan):
greeting := "hello"
size := greeting.size
In Fan, ':=' is used for var initialization as opposed to the 'var' keyword in Scala or C#. You even use it when specifying an explicit type for the var, just for consistency. I like either style better than the "guess where the var is defined" behavior you get in Python or Ruby. (Actually, Python has fairly simple rules, but they can get annoying sometimes. I've heard Ruby is cleaning up their ambiguity in this arena, too.)
But, anyway, my discussion had more to do with this list of features from Scala.
1. Abstract Types
2. Existential Types (officially not recommended except for interoperability with Java, is my understanding)
3. Generics
4. Type Bounds
5. Variances
6. Views
And probably things I'm forgetting. Yes, the type system is serious in Scala. They want to you get it right. Personally, I see the need for awesome static typing in a language like OCaml that has no dynamic type safety (no casting exceptions) but still wants to be type safe and avoid security risks.
But in a language with dynamic type safety (like Java or ducky languages like Python, JavaScript, or Ruby), how often do you really see casting exceptions? If I make a mistake, it will be found (rather than opening security holes), and I don't usually make mistakes.
So, to make life easy, Fan will do your casting (up or down a hierarchy) automatically. For example (in Fan):
Obj[] items := ["something", "and", "more"]
Str message := items[0]
In Java, you'd have to make that second cast explicit, being a down cast. Welcome to "I don't need generics to have my casting done for me" land.
And while I know that Scala folks will be all over me about this feature of Fan, think first about Scala's automatic type conversion. Fan only casts for you (yay! in my book). Scala, for all its type safety will magically convert integers into strings, if you set up the right magic. I'm personally really scared of automatic variable swapping going on behind my back. It's also something I dislike about C#.
One thing that I don't like about Fan is its lack of generics (except for Lists, Maps, and Funcs). Yep, I like generics (despite my list above on Scala). I just want autocasting and arbitrary support for co and contravariance. I'm a hippie that way. I think Scala's generics go too far. So really, I'd prefer some land in between Scala and Fan on the generics front. But between the two, I'll take Fan.
Side note, Fan also supports dynamic duck typing. If you say, "myVar->something", that does a dynamic lookup rather than the static form "myVar.something". Note that this is different from duck typing support in languages such as C#, Boo, and haXe, where method calls look the same, but the variable type is declared to be dynamic. The two styles have different effects on your code. Scala shuns dynamic typing in favor of static structural typing. I'm not sure either take is fully necessary, but between the two (duck typing vs. structural), I'd prefer structural. I just don't want the rest of Scala typing with it. Sorry for being too quick to find good links, but Google can probably help out.
I'll give at least one link, though, to the official description of Fan's system.
Monday, June 15, 2009
Fan vs. Scala: Target Platforms
This is a post in a series on some reasons why I prefer Fan to Scala. I don't hate Scala, and I don't mind if you use it. Still, I'm being biased here. And I don't speak authoritatively. I'm just some guy. The creators of Fan (Brian Frank and Andy Frank) are much smarter and nicer than I am. That's why they're wise enough not to do a series of blog posts like this.
So, back to my foolishness, in my original post, I claimed this as an advantage for Fan:
Scala has great support for Java, and it claims support for .NET, too. I've never used Scala nor Fan on .NET nor Mono, so I can't say which handles the platform better. So I'll just pretend they are equal on this subject (lacking time to gather evidence either way).
Still, I think JavaScript is just important a platform as either Java or .NET. I don't see any reference to JavaScript on the recent poll at scala-lang.org. I have seen references to past efforts, and it seems David Pollak of Lift fame is working on some kind of Scala to JS compiler. (Another reference here.)
On the other hand, here's an example of upcoming Fan JavaScript support. And they list JavaScript as a core focus on their home page. I find that important.
Side note, obviously GWT is more mature than either of these efforts, and for serious cross-platform support (though without Java or .NET so far), see haXe.
So, back to my foolishness, in my original post, I claimed this as an advantage for Fan:
1. Fan has a core goal to support Java, .NET, and JavaScript platforms.
Scala has great support for Java, and it claims support for .NET, too. I've never used Scala nor Fan on .NET nor Mono, so I can't say which handles the platform better. So I'll just pretend they are equal on this subject (lacking time to gather evidence either way).
Still, I think JavaScript is just important a platform as either Java or .NET. I don't see any reference to JavaScript on the recent poll at scala-lang.org. I have seen references to past efforts, and it seems David Pollak of Lift fame is working on some kind of Scala to JS compiler. (Another reference here.)
On the other hand, here's an example of upcoming Fan JavaScript support. And they list JavaScript as a core focus on their home page. I find that important.
Side note, obviously GWT is more mature than either of these efforts, and for serious cross-platform support (though without Java or .NET so far), see haXe.
Friday, June 12, 2009
Fan vs. Scala: My background
Well, my previous post on why I prefer Fan to Scala got some attention. It also got a few votes up and down at DZone. Also, I'm afraid I wasn't sufficiently clear in my post. I too rarely am. In any case, it seemed like it might be worth extending my discussion of the points I listed.
I ought to give some personal history first, though. I love Eclipse and what other such modern IDEs do for Java. I can navigate and fairly well tame code bases made of 1000s of files. I also love that Java performance is sometimes near C, except that I can just download and run jars. Getting stinking complex open-source C or C++ code to build correctly can really make me mad. (The download and run mentality of Windows or Mac really beats Linux in this respect, too, though maybe if Ubuntu becomes more ubiquitous, people can just target that and make life easier. Official packages are always so far behind for the few apps and libs that I really want fresh.) But back to Java, I really don't like it as a language. Checked exceptions, needing to repeat oneself, lack of closures, and so on really don't make my day. And I like to learn other languages, new and old.
I occasionally noticed Scala over the past few years. It seemed very promising. When I saw it starting to get attention a couple of years ago, I figured I'd learn it more and help be part of the momentum to see if it could overturn Java. Among other things, I submitted a game to the Java 4K game competition (jar size, not source size!) written in Scala. Scala doesn't shrink as nicely as Java, but I got it mostly working and in the right size. And I kept learning the language. I gave a brown bag presentation at my job on Scala about a year ago.
And just about the same day as my brown bag presentation, I saw posts from Cedric Beust and Stephen Colebourne about this other new language, Fan. I got to the site, looked around it, and I immediately switched my interests. I thought, hey, this is even closer to my own preferences, and it doesn't smell like you need a PhD to understand it (despite the fact that I'm now working on getting a PhD). I don't prefer every decision that had or has been made, but it's just so much closer to what I want than anything else out there with any momentum. It's statically typed with important limitations to structure programs, but it still has the feel of a scripting language. Scala might be convenient (usually), but it doesn't have that same relaxed air. And it doesn't even make some of the same guarantees you get from Fan.
So history aside, I'll try to delve deeper into my list of good things about Fan in the near future. And I'll keep the "vs. Scala" perspective, as well as "vs. Java" and maybe a few others. Nothing personal against Scala. If it's good for you, then good for you. I'm just afraid that for many folks looking at Scala, Fan is a better choice, but it's not high enough up the radar yet. Or the differences might not be clear enough. That's why I'm giving this focus.
I ought to give some personal history first, though. I love Eclipse and what other such modern IDEs do for Java. I can navigate and fairly well tame code bases made of 1000s of files. I also love that Java performance is sometimes near C, except that I can just download and run jars. Getting stinking complex open-source C or C++ code to build correctly can really make me mad. (The download and run mentality of Windows or Mac really beats Linux in this respect, too, though maybe if Ubuntu becomes more ubiquitous, people can just target that and make life easier. Official packages are always so far behind for the few apps and libs that I really want fresh.) But back to Java, I really don't like it as a language. Checked exceptions, needing to repeat oneself, lack of closures, and so on really don't make my day. And I like to learn other languages, new and old.
I occasionally noticed Scala over the past few years. It seemed very promising. When I saw it starting to get attention a couple of years ago, I figured I'd learn it more and help be part of the momentum to see if it could overturn Java. Among other things, I submitted a game to the Java 4K game competition (jar size, not source size!) written in Scala. Scala doesn't shrink as nicely as Java, but I got it mostly working and in the right size. And I kept learning the language. I gave a brown bag presentation at my job on Scala about a year ago.
And just about the same day as my brown bag presentation, I saw posts from Cedric Beust and Stephen Colebourne about this other new language, Fan. I got to the site, looked around it, and I immediately switched my interests. I thought, hey, this is even closer to my own preferences, and it doesn't smell like you need a PhD to understand it (despite the fact that I'm now working on getting a PhD). I don't prefer every decision that had or has been made, but it's just so much closer to what I want than anything else out there with any momentum. It's statically typed with important limitations to structure programs, but it still has the feel of a scripting language. Scala might be convenient (usually), but it doesn't have that same relaxed air. And it doesn't even make some of the same guarantees you get from Fan.
So history aside, I'll try to delve deeper into my list of good things about Fan in the near future. And I'll keep the "vs. Scala" perspective, as well as "vs. Java" and maybe a few others. Nothing personal against Scala. If it's good for you, then good for you. I'm just afraid that for many folks looking at Scala, Fan is a better choice, but it's not high enough up the radar yet. Or the differences might not be clear enough. That's why I'm giving this focus.
Wednesday, June 10, 2009
Why choose Fan over Scala?
So, if Scala is the top contender for the "new Java", and it's a convenient yet statically-typed language, why bother to consider Fan? Both target the JVM, both have static typing, type inference, closures, and so on. Well, I personally think Fan is a better choice for me.
Here are some of my own top reasons to choose Fan:
1. Fan has a core goal to support Java, .NET, and JavaScript platforms.
2. In Fan, you don't have to figure out existential types or other complex typing. Fan will even do your casting for you in many cases.
3. Fan doesn't encourage or even support global variables. It has an almost Erlang level of attention to concurrency. (Hopefully, people don't abuse 'object' in Scala for global vars, but I fear it's an easy trap, at least for newbies.)
4. In Fan, you can't invent your own <**==!!! operator. (I haven't double-checked this particular one in Scala, but I've seen some doozies.)
5. Fan types are not-nullable by default, with the concept built into the core of the language, instead of being "Option"al.
6. The Fan core library is simple and straightforward. It has functional features but doesn't try to shove complexity down your throat.
7. In Fan, building and modifying nested objects is straightforward.
8. Fan package (or rather pod) namespacing is simple.
9. For Fan, I only have to follow one group on a single lovely site to keep up with the core language happenings.
10. In Fan, all the Ints and Floats are 64-bit. So you don't have to worry about choosing something smaller. And chars are just Ints (using 32-bit code points which fit easily and without worrying about sign bits in that 64-bit space). Breath easy. Oh, and you do still have easy (Big)Decimal support, too, so don't worry about that.
I'm going to be biased and omit my reasons for not choosing Fan, except one. They haven't yet hit 1.0. (Don't let the version numbering scheme fool you.) There are still some backwards-incompatible changes to be made. But the goal is to stabilize things soon.
Here are some of my own top reasons to choose Fan:
1. Fan has a core goal to support Java, .NET, and JavaScript platforms.
2. In Fan, you don't have to figure out existential types or other complex typing. Fan will even do your casting for you in many cases.
3. Fan doesn't encourage or even support global variables. It has an almost Erlang level of attention to concurrency. (Hopefully, people don't abuse 'object' in Scala for global vars, but I fear it's an easy trap, at least for newbies.)
4. In Fan, you can't invent your own <**==!!! operator. (I haven't double-checked this particular one in Scala, but I've seen some doozies.)
5. Fan types are not-nullable by default, with the concept built into the core of the language, instead of being "Option"al.
6. The Fan core library is simple and straightforward. It has functional features but doesn't try to shove complexity down your throat.
7. In Fan, building and modifying nested objects is straightforward.
8. Fan package (or rather pod) namespacing is simple.
9. For Fan, I only have to follow one group on a single lovely site to keep up with the core language happenings.
10. In Fan, all the Ints and Floats are 64-bit. So you don't have to worry about choosing something smaller. And chars are just Ints (using 32-bit code points which fit easily and without worrying about sign bits in that 64-bit space). Breath easy. Oh, and you do still have easy (Big)Decimal support, too, so don't worry about that.
I'm going to be biased and omit my reasons for not choosing Fan, except one. They haven't yet hit 1.0. (Don't let the version numbering scheme fool you.) There are still some backwards-incompatible changes to be made. But the goal is to stabilize things soon.
Tuesday, June 9, 2009
Java, .NET, and ECMAScript Regex Compatibility - Expert advice wanted!
I'm trying to figure out the compatibility of regexes for Java, .NET, and ECMAScript. I did a quick skim, but I don't really have the experience to know what practical implications exist. So I'm going fishing here.
At first glance, it seems that ECMAScript 3 regexes are a subset of those for Java or .NET. Does anyone happen to know if this is correct? Any specific practical gotchas encountered?
(Side note, it seems that Perl 5 sure left its mark on the world. It made a semi-standard for half-decent regexes in the world. And I call that a good thing. Even if Perl 6 changed their own regexes again. Side note 2, even if you don't know the answers to my questions, please forward to your friends who might be experts on this matter. Many thanks!)
At first glance, it seems that ECMAScript 3 regexes are a subset of those for Java or .NET. Does anyone happen to know if this is correct? Any specific practical gotchas encountered?
(Side note, it seems that Perl 5 sure left its mark on the world. It made a semi-standard for half-decent regexes in the world. And I call that a good thing. Even if Perl 6 changed their own regexes again. Side note 2, even if you don't know the answers to my questions, please forward to your friends who might be experts on this matter. Many thanks!)
Wednesday, June 3, 2009
Review of Mere Christianity
Mere Christianity by C.S. LewisMy review
Rating: 4 of 5 stars
A really good book overall. Teaches lots of practical issues related to Christianity (as a religion and as a relationship with Christ) and Christian behavior. One sample of good advice is how giving ought to hurt. For instance, if we our charitable donations don't hamper our personal desires some, then we probably aren't giving enough. On that word "charitable", there's a nice discussion of charity (Christian love) itself.
From a philosophical/logical perspective, I think sometimes Lewis claims more than he's proven. For example, I believe in right and wrong, and I believe him that it shows the existence of God. Also, that everyone, if they really think about it, can figure it out. But I don't think Lewis logically proved that there aren't alternative explanations. Still, the arguments are convincing if not watertight.
Going on a tangent, I feel there's some value in comparing Lewis's theology with that of Mormonism (my being a Mormon and all). There are several differences, but I think the most fundamental is the nature of humanity. In Mormonism, we believe that all people are begotten spirit children of God. Christ has a special status. He was/is perfect. He also had a special role to play, and we refer to him as God in that role. But we believe that the rest of mankind are also spirit children of God, not merely creatures.
However, in our fallen world, and given our fallen natures, much of the same principles apply as Lewis describes. That is, Christ's redemption brings us _back_ into the state of being God's children. The process of that redemption overlaps much with the nature of choice and grace that Lewis describes. Lewis was obviously very inspired in his doctrine, and I agree with a majority of his teachings here.
With the differences being subtle at that level, I've had to think some about what the practical effects of the difference might be. I'm not sure I have a full answer at this point, but it does create a different psychological effect. The world isn't "progressing" in the way Lewis describes. The fall itself was necessary, and the fallen world is part of the experience God wants for us. Also, Christians go back to the beginning of the world. The atonement works retroactively.
Anyway, in all it was a great book, and I'm glad I read it.
View all my reviews.
Monday, June 1, 2009
Exuberant Ctags
I've been spending more time in Vim than Eclipse recently, so I was missing the source navigation features of Eclipse. Well, I finally dug into making ctags work, so I have my basic navigation features back again (the "go to definition" kind).
Then I found out that GNU ctags doesn't seem to support local variables. Then I found Exuberant Ctags, which is working great for me (in C and C++, at least). For now, I use an alias defined like so:
alias tags='$HOME/.local/bin/ctags --c++-kinds=+l --c-kinds=+l'
I wonder if there's some way to tell Vim to update the tags for a project each time I save ...
Then I found out that GNU ctags doesn't seem to support local variables. Then I found Exuberant Ctags, which is working great for me (in C and C++, at least). For now, I use an alias defined like so:
alias tags='$HOME/.local/bin/ctags --c++-kinds=+l --c-kinds=+l'
I wonder if there's some way to tell Vim to update the tags for a project each time I save ...
Subscribe to:
Posts (Atom)