Apple built its own apps using one approach and left a side effect of implementing a web browser as an excuse to not offer an actual SDK - web apps were second class citizens. Palm, from what I can tell, actually build their own apps using this technology.
It's about the even footing; being able to use the primary SDK is fine, even if I don't see HTML and CSS as having the flexibility I'd like for the UI.
(For the record, the SDK iPhone apps are still far too constrained, but at least now we get to get at some of the hardware. Try coding Rolando for MobileSafari.)
Exactly. Where's the world come to? First he was right about Home Basic being a stupid nickel-and-dime move, now this. Good thing Dell stopped their new MP3 player, or he'd be launching pigs too.
The version that brought LINQ was.NET 3.5, with C# 3.0..NET 3.0 was just the Vista technologies ("WinFX": WF, CardSpace, WCF, WPF and arguably also WTF) and didn't affect any of the languages in any way - just a bunch of new namespaces..NET 4.0 will deemphasize LINQ to SQL in favor of LINQ to Entities, which hooks LINQ up to Entity Framework, a more solid (but as of yet woefully "1.0") mapping framework on its own. As with everything Microsoft, it'll probably live on for ages.
LINQ to SQL is more of a joy to use, but it's a joy to use because it has less syntax, and it has less syntax because it tries to abstract less. Entity Framework tries to abstract more (like abstract away most many-to-many junction tables where the connection itself doesn't have properties) to the point where it is intelligent enough to handle joins for you, and it demands you to be far more explicit about lazy-loading data across relationships (which is a good thing). But it's not entirely there yet unless every query *always* produces an instance of a known type from the database.
Just to clarify (because it's not clear from the parent, which means it's not even clear if the parent had them confused): The autorelease pool is not the same as a garbage collector.
The autorelease pool is an opt-in way of saying "add this to a pool of objects that can be released and fully deallocated at a later date *unless* it is retained later on". You can create several autorelease pools, and the "closest" pool in terms of scope is always used, so if necessary (which it is in some convoluted scenarios involving object dependencies) you can create a local pool, do your thing and then release the pool, which releases every "autoreleased" object within the time it existed.
Basically, autorelease just says "do release this, eventually, if nothing else happens". Beyond managing some corner-cases, it provides a GC-like way of writing convenience methods to return objects where neither you nor the callee have to worry about who owns the object.
The autorelease pool existed before GC, but wasn't around from the start. In Cocoa, it's a no-op when the GC is on, along with retain and release. Which makes sense, since it's not culling the heap for dead objects or anything, it just delays sending the right number of "release" messages.
Most likely they wanted to optimize for a very specific layout and some controls that were hard to implement efficiently in HTML and Javascript at the time. (Like the "swoosh" on the front page.) Reducing the surface area for attacks and not having to reimplement everything that could be in both the track list and the content area probably played a part, too.
It's not technically Safari, and it's not technically WebKit, and it's not technically WebCore. It's not HTML anything. It's just an unconnected rendering engine stringing up XML in some very un-HTML ways. It has links, came around a few months after Safari was revealed and perhaps evokes table layouts, but that's about it.
And that's just it. Safari is a great browser, and it is probably the best mobile browser in terms of usability, but it's not the best browser in terms of capability. If the iPhone platform was more open, Opera could port their browsers over, and people who wanted to use features that Safari for a number of reasons (some of which are good) don't support, like Java and Flash, could just use those browsers instead.
I don't blame Apple right now for not supporting Java and Flash in Safari, because with a scalable UI, a relatively slow CPU and battery considerations, supporting these things might not be a good trade-off for many people. I do blame Apple for blocking other applications like that from being implemented under the pretense of quality applications (many of them aren't) and a secure device.
but C# is a better, more coherent language than Java in my view
That isn't saying much;-) Java was designed mostly for tool builders, not front-line developers.
Admittedly it might not be saying much, but I reject the notion that Java was designed for "tool builders". I don't see any evidence for this at all, and my experience with Java has been that ordinary things are tedious and tricky things are a nightmare; and by nightmare I mean tricky, tedious and verbose to the effect that the language stands in your way and forces you to write more lines of code or constructs that are just weird. Although it depends on what you mean by tools, they are full of tricky things.
If indeed something has been said officially on what Java's been designed for, I'd be interested in reading that. It's possible I just didn't hear it over the Sun "write once run anywhere" party line.
It's not perfect, but right now I'm getting more stuff done in C# than I do in any other language, surpassing Ruby and Objective-C, my other two preferred languages.
It may be that the platform is chock full of wizards, bad decisions and a penchant for not backporting architectural improvements because of the backward compatibility bogeyman. But I'm getting lots of work done *despite* the wizardry, and I like to go "beyond the official way".
In the end, maybe stuff like LINQ makes it all worthwhile, but the baseline is higher than many people seem to assert. I seem to be relatively alone in this on sites like Slashdot, but C# is a better, more coherent language than Java in my view, because it's designed by a few people (including Anders Hejlsberg, Denmark's way of making up for Bjarne Stroustrup) instead of largely by committee.
Isn't the issue not that there's currently only a MEF version available - although they've said that'll change - that links with Windows, but that a license they're using limits any derivative works to be available outside of the Windows platform?
The Open Source Initiative is supposedly where Microsoft is interested in "certifying" their licenses, and I'll admit that the Open Source Definition put out by that group is a bit vague on this issue. The strongest support could be found in point 6 ("No Discrimination Against Fields of Endeavor") and point 8 ("License Must Not Be Specific to a Product").
Unless you wanted a competent GPU which is what this whole article and thread is about. The GMA in Mac mini and the "regular" MacBooks is about on par performance-wise with a cardboard replica.
Command+~ switches windows. Command+Tab switches applications. You're right that the Zoom button does fit-to-content in some apps and maximize in some apps and I'd rather see it do just one of them, preferably maximize.
Slashdot Mirror
Apple built its own apps using one approach and left a side effect of implementing a web browser as an excuse to not offer an actual SDK - web apps were second class citizens. Palm, from what I can tell, actually build their own apps using this technology.
It's about the even footing; being able to use the primary SDK is fine, even if I don't see HTML and CSS as having the flexibility I'd like for the UI.
(For the record, the SDK iPhone apps are still far too constrained, but at least now we get to get at some of the hardware. Try coding Rolando for MobileSafari.)
Hey, I've read about this.
Exactly. Where's the world come to? First he was right about Home Basic being a stupid nickel-and-dime move, now this. Good thing Dell stopped their new MP3 player, or he'd be launching pigs too.
The version that brought LINQ was .NET 3.5, with C# 3.0. .NET 3.0 was just the Vista technologies ("WinFX": WF, CardSpace, WCF, WPF and arguably also WTF) and didn't affect any of the languages in any way - just a bunch of new namespaces. .NET 4.0 will deemphasize LINQ to SQL in favor of LINQ to Entities, which hooks LINQ up to Entity Framework, a more solid (but as of yet woefully "1.0") mapping framework on its own. As with everything Microsoft, it'll probably live on for ages.
LINQ to SQL is more of a joy to use, but it's a joy to use because it has less syntax, and it has less syntax because it tries to abstract less. Entity Framework tries to abstract more (like abstract away most many-to-many junction tables where the connection itself doesn't have properties) to the point where it is intelligent enough to handle joins for you, and it demands you to be far more explicit about lazy-loading data across relationships (which is a good thing). But it's not entirely there yet unless every query *always* produces an instance of a known type from the database.
Just to clarify (because it's not clear from the parent, which means it's not even clear if the parent had them confused): The autorelease pool is not the same as a garbage collector.
The autorelease pool is an opt-in way of saying "add this to a pool of objects that can be released and fully deallocated at a later date *unless* it is retained later on". You can create several autorelease pools, and the "closest" pool in terms of scope is always used, so if necessary (which it is in some convoluted scenarios involving object dependencies) you can create a local pool, do your thing and then release the pool, which releases every "autoreleased" object within the time it existed.
Basically, autorelease just says "do release this, eventually, if nothing else happens". Beyond managing some corner-cases, it provides a GC-like way of writing convenience methods to return objects where neither you nor the callee have to worry about who owns the object.
The autorelease pool existed before GC, but wasn't around from the start. In Cocoa, it's a no-op when the GC is on, along with retain and release. Which makes sense, since it's not culling the heap for dead objects or anything, it just delays sending the right number of "release" messages.
Pipe Wrench Fight!
It's still dark matter, it's just not fuel anymore.
Citation granted in my other comment: http://tech.slashdot.org/comments.pl?sid=1021097&cid=25669385
Most likely they wanted to optimize for a very specific layout and some controls that were hard to implement efficiently in HTML and Javascript at the time. (Like the "swoosh" on the front page.) Reducing the surface area for attacks and not having to reimplement everything that could be in both the track list and the content area probably played a part, too.
No, it's not WebKit. Dave Hyatt, the development lead on WebKit and Safari has said as much himself. http://weblogs.mozillazine.org/hyatt/archives/2004_06.html#005666
$ strings /Applications/iTunes.app/Contents/MacOS/iTunes | grep WebKit
[nothing]
$
It's not technically Safari, and it's not technically WebKit, and it's not technically WebCore. It's not HTML anything. It's just an unconnected rendering engine stringing up XML in some very un-HTML ways. It has links, came around a few months after Safari was revealed and perhaps evokes table layouts, but that's about it.
iTunes doesn't use Safari, it just looks web-like. It's custom rendering.
And that's just it. Safari is a great browser, and it is probably the best mobile browser in terms of usability, but it's not the best browser in terms of capability. If the iPhone platform was more open, Opera could port their browsers over, and people who wanted to use features that Safari for a number of reasons (some of which are good) don't support, like Java and Flash, could just use those browsers instead.
I don't blame Apple right now for not supporting Java and Flash in Safari, because with a scalable UI, a relatively slow CPU and battery considerations, supporting these things might not be a good trade-off for many people. I do blame Apple for blocking other applications like that from being implemented under the pretense of quality applications (many of them aren't) and a secure device.
Although I'd deduct points for the initial "a night of heavy drinking". It's "a week of binge drinking".
Or 5 minutes on a cell phone.
That isn't saying much ;-) Java was designed mostly for tool builders, not front-line developers.
Admittedly it might not be saying much, but I reject the notion that Java was designed for "tool builders". I don't see any evidence for this at all, and my experience with Java has been that ordinary things are tedious and tricky things are a nightmare; and by nightmare I mean tricky, tedious and verbose to the effect that the language stands in your way and forces you to write more lines of code or constructs that are just weird. Although it depends on what you mean by tools, they are full of tricky things.
If indeed something has been said officially on what Java's been designed for, I'd be interested in reading that. It's possible I just didn't hear it over the Sun "write once run anywhere" party line.
It's not perfect, but right now I'm getting more stuff done in C# than I do in any other language, surpassing Ruby and Objective-C, my other two preferred languages.
It may be that the platform is chock full of wizards, bad decisions and a penchant for not backporting architectural improvements because of the backward compatibility bogeyman. But I'm getting lots of work done *despite* the wizardry, and I like to go "beyond the official way".
In the end, maybe stuff like LINQ makes it all worthwhile, but the baseline is higher than many people seem to assert. I seem to be relatively alone in this on sites like Slashdot, but C# is a better, more coherent language than Java in my view, because it's designed by a few people (including Anders Hejlsberg, Denmark's way of making up for Bjarne Stroustrup) instead of largely by committee.
Isn't the issue not that there's currently only a MEF version available - although they've said that'll change - that links with Windows, but that a license they're using limits any derivative works to be available outside of the Windows platform?
The Open Source Initiative is supposedly where Microsoft is interested in "certifying" their licenses, and I'll admit that the Open Source Definition put out by that group is a bit vague on this issue. The strongest support could be found in point 6 ("No Discrimination Against Fields of Endeavor") and point 8 ("License Must Not Be Specific to a Product").
Unless you wanted a competent GPU which is what this whole article and thread is about. The GMA in Mac mini and the "regular" MacBooks is about on par performance-wise with a cardboard replica.
The email client just isn't there, and the web browser is just barely better than IE7.
Especially their enormous fleet.
However, everyone who's a Perl programmer...
Does that mean we can finally throw sausage pizza away?
Command+~ switches windows. Command+Tab switches applications. You're right that the Zoom button does fit-to-content in some apps and maximize in some apps and I'd rather see it do just one of them, preferably maximize.
The nipple's intuitive. Everything else is more or less hard to learn.