vito

Wow, that's a whole lot of pretty major changes just for this beta. It's great that the Add-Ons manager is in a tab now rather than a window. Hopefully the Downloads window gets the same treatment.

Also: The "tabs on top" on OS X could use some touching-up - right now the tab bar is just swapped with the toolbar, and still below the window's title area. Something more like Chrome (or that Safari beta, for that matter) would be nice.

    Just 1 >> Nothing >> Just 3
      => Nothing

    Just 1 >> Just 2 >> Just 3
      => Just 3

To answer your last question, yes. It basically adds short-circuiting.

I'm very impressed with Racket.

* The documentation is fantastic. Insanely easy to browse around, very well formatted, and interconnected nicely.

* It comprises of multiple languages, and they can all interoperate - r5rs, r6rs, racket, etc. This has always been a major pain point for me when it comes to Scheme dialects - lots of implementations clinging to r5rs and using incompatible module systems.

* PLaneT has a ton of libraries covering many fields, and it's great that it's integrated into the language (requiring something from PLaneT will automatically download it).

* The community seems nice enough.

I also love that the new site immediately shows off the language: http://racket-lang.org/

Agreed. Don't remind the user that your app is going to use an OS feature that's meant to be pretty transparent. Especially if yours is the only app that nags them about it; it'll just confuse non-geeks and make them think you're doing something weird.

Might as well throw the normal GMail app into the mix: http://smarterware.org/wp-content/uploads/2010/01/android21-... (via http://smarterware.org/4308/android-2-1s-best-features-in-sc...).

Who says you have to use Eclipse? Just use your favorite editor, and run "adb install" to install it to the device or emulator for testing.

Android's "attempt" at resolution independence? It's been designed for it from the start, and as a result it's very very simple to work with as a developer. Stop spreading FUD.

Any Android app by a competent developer will look great from one resolution to the next. Now the iPhone can do that too, just with some growing pains as developers update their apps to provide higher-definiton resources.

It's great that the iPhone is progressing, but there's no need to adopt this "finally Apple gets it right!" stance and trash their opponents who have been for years doing pretty much the same things you tout as revolutionary and unprecedented.

The example code is a bit unreadable for me: http://i.imgur.com/uMcgo.png

Note that his definition for `eq` using phantom types does not compile. It has two different notions of `a`: Int and Bool, but the type constructor for Eq only has one: Expr a -> Expr a -> Expr a.

Other than that, a great overview!

They are standard. There's also `first` and `second`, but they do something different:

    Prelude> :m + Control.Arrow 
    Prelude Control.Arrow> :t first
    first :: (Arrow a) => a b c -> a (b, d) (c, d)
    Prelude Control.Arrow> first (2 +) (1, 4)
    (3,4)

In this case the Arrow instance is just (->), the function type constructor, so you could read that strange type signature as `first :: (b -> c) -> ((b, d) -> (c, d))`. But I've said too much.

Ha! I have the exact same, also imported from Japan. It's a lovely keyboard. :)

Can we keep this sensationalist tripe out? (That's rhetorical.)

Having read Alexis' letter I'd hardly call it "slamming," and undeserving of this melodramatic bullshit.

Engadget confirmed it here: http://www.engadget.com/2010/05/27/palms-matias-duarte-has-j...

Honestly works a lot better than I thought it would. Has a lot of tricks up its sleeve - for example, swiping right and left to reveal tab thumbnails and more controls was a pleasant surprise. Wish it had pinch-to-zoom though.

Overall very nice for a pre-alpha.

I could not agree more. Sent from my Nexus One that literally just arrived. My semi-new iPhone is on Craigslist, and I'm already working on an Android app.

That's quite some free advertising.

I quite like Toast. :)

I never said IB was iPhone-specific or made for it. I'd used it myself before that. Why are iPhone apps upscaled or letterboxed on the iPad, though?

Duby has been absolutely great on Dalvik so far. Like I said, Duby is not a dynamic language, it just provides one of its main benefits through type inference and a drastically less verbose syntax. I translated the same code from Java to Duby (reducing its size and making it a whole lot more fun to work with) and noticed absolutely no drawbacks. That's not to say there weren't any speed decreases, but if there were they were too small for me or anyone to care about.

Do you have any benchmarks or references for Scala and Clojure's speed on Dalvik? I haven't been able to find much. (That's curiosity, not snootiness.)

I would try it out, but right now my iPhone is on Craigslist and a Nexus One is in the mail. :) I run Linux so that wouldn't be very easy to do anyway.

Re: Interface Builder, I agree, but I don't think anything like that would work well for Android. It targets all kinds of devices and screen sizes; it really has to be flexible and that'd be harder to do with a WYSIWYG UI tool. That being said, someone made one for Android, but I still prefer coding it by hand: http://droiddraw.com/ (it ain't the prettiest thing but it seems to work; you can even load up your own layouts).

I don't question the rest, and I simply don't know enough about the iPhone APIs to compare it to Android, but I will say this: everything certainly works together in the Android APIs. I'm not 100% sure what the purpose of CoreData is - preferences? generic data storage? - but they are both part of Android as well.

Funny that you mentioned everything working together (albeit in a different context); that's the biggest difference I noticed between how iPhone apps work and how Android apps work. See Activities (Android) vs. Apps (iPhone), Content Providers, Intents -- just about everything about Android apps is designed around working together. For example, in every iPhone app I've used that has a browser in it, it's always essentially a WebKit view with some primitive controls, or it says "Halt app and switch to Safari?". In Android most apps open up the native Browser app's main activity, and hitting Back will close it and go right back to where you were. It's not really based on multitasking or switching apps, it just reuses the Browser's Activity to accomplish the same task. Applications are all on the same level, even built-in ones, and can all work together beautifully by simply calling Activities of other apps for performing specific tasks, or controlling them through Intents, etc. iPhone apps tend to be much more isolated.

The nice thing about Android is you don't have to use Java. Many other languages target the JVM, which is often trivial to convert to Dalvik (it depends on the language). Right now I'm working on an entire app in Duby (a Ruby-like language with static typing and type inference, with no baggage; reaches native Java speed easily), and loving it. All I had to do was change my compile command to dubyc and I was ready to go. JRuby is in the works, and apparently Scala is possible, and I'm sure many others are working on it too.

I've never written an iPhone app, and this is my first Android app, but I find the API and the SDK to be perfectly easy to work with; it was very easy to get started and quickly start prototyping. I'd like to know what parts of the Cocoa APIs you consider delightful though, just out of curiosity.

Nice timing; I was actually just playing with Duby + Android last night, it's just about perfect. Just be sure to get the latest git of Duby, and not the one in rubygems.

Here's a token Hello, world! app: http://pastie.org/915727

To get it going all you need to do is edit your build.xml to add a new compile target before the </project> (thanks to technomancy for this):

    <target name="compile" depends="-resource-src, -aidl"
            description="Compiles project's .duby files into .class files">
      <exec executable="dubyc" dir="src">
        <env key="CLASSPATH" file="${sdk.dir}/platforms/android-7/android.jar" />
        <arg value="-d" />
        <arg value="../bin/classes/" />
        <arg value="." />
      </exec>
    </target>

You may want to change android-7 to whatever platform you're on (and make sure sdk.dir is correct, it should be in your local.properties).

I would not consider Firefox to be a "top-notch" Mac app. Every time I used it it felt slow, awkward, and clunky. I'd even find myself using non-native keyboard shortcuts (despite the native ones being available; e.g. F5 vs. Cmd+R) simply because it took me out of the "Mac native" world. No matter how close its emulation came there was always something to throw me off, mostly little GUI idiosyncrasies.

I like how they changed "one of us is going to leave the company" to "one of us has to leave" and still treat it like it's a direct quote.

Interesting; it could be used like online petitions, but with actions instead of words. Hopefully most/all large tasks can be divided with such granularity that everyone can take part without major roadblocks.

Did it in Io (was already doing Euler stuff), pretty similar:

    problem25 := method(digits,
        term := 0
        n0 := BigNum with(0)
        n1 := BigNum with(1)
        loop(
            n0 = n0 + n1
            n1 = n0 - n1
            if(n1 asString size >= digits, break)

            term = term + 1
        )

        term
    )

    problem25(1000) println

Works great with the iPhone. In fact if you use multitouch you get some nice Windows line screensaver effects.

Firefox 3.6 on Ubuntu x64, Flash v10.0.32.18ubuntu1, seems to survive. Chrome survives too, unsurprisingly. Come to think of it, doesn't Firefox have plugin crash safety in place now?

Midori does insta-crash though.

Agreed. All of the characters are perfectly balanced and fine-tuned. For example, #, /, and <> all look wonderful in code. Monaco messes that up, especially with /.

Takes a little bit to get used to using a serif monospace font though.

It's largely subjective; the feedback of mechanical vs. membrane keyboards can certainly be measured objectively (i.e. pressure for key presses and snapback time), but it's just a matter of personal preference between the two (and I wouldn't consider the better feedback to be just a neat aesthetic benefit; it's the reason I bought it, not a bonus). My dad has always used an old clacky mechanical IBM keyboard but has no problem using membrane keyboards. I can use a membrane keyboard if I have to, but now it feels "mushy" after being spoiled by my Topre.

Membrane keyboards are cheaper to make (because most people don't care) but have less tactile feedback and are less reliable. Mechanical keyboards are more expensive to make, but are much more durable (keys will not wear out) and have quicker key snapback. Lack of n-key rollover could also be considered a defect of inexpensive keyboards, although it's not a common hindrance to casual typers.

More information: http://www.ergocanada.com/ergo/keyboards/mechanical_vs_membr...

At least with my Topre Realforce 87U there are definitely some perks to justify it:

* The feel of the mechanical keys is fantastic. There's much more feedback; keystrokes make a nice subdued "schlock" noise. The backspace key sounds like the sound from Mario games where he does that spinning landing thing on a baddie.

* Easily swappable keys; my WASD are swapped for the purple arrow keys they come with, and my Esc key is a nice dangerous-looking red.

* LEDs are built into the keys they're for. Not a killer feature, but pretty slick.

* Flexibility; there are dip switches in the back for various tweaks such as swapping Ctrl and Caps Lock on a hardware level - they even provide keys to switch out so that the new Caps Lock key gets its LED.

For something I'll be typing on for many hours a day it's a worthy investment.