or Connect
New Posts  All Forums:

Posts by Maury Markowitz

 That sounds fishy. Right now industrial-scale solar farms are going in for about $1.80 a watt, all-in. 17.5 x 1.80 = $31.5. Even with the trackers they like to use, this still sounds like its more than it should be.
Yeah, but that's the forum software doing it, not the iOS stuff. That's going to work on one system and not another. I want it *everywhere*. Especially the Wiki.
So Apple used to have something called WebScript, which, contrary to anything you might divine from the name, was an Obj-C interpreter. It was also almost useless, because it didn't have pointers, so your "real" Obj-C code didn't run properly (at least not in general). Why do I mention this? Because there are two missing pieces of the development puzzle on Cocoa, and Swift solves one of them. As noted in the demos, Swift can run immediately, right there. This leaves the...
Swift eliminates pointers, and appears to do so at a fundamental level - they're not just hiding the *'s. So while I fully expect you'll be able to USE C code in a Swift application, I doubt the mapping will be as invisible as it is in Obj-C. But so far, I can't find out how to do it *at all*.
Technically, there's no difference. Indeed, it appears that this system works on file exchange, and therefore would not work with web forms. But think about how much you type into web forms these days. Like this one.
Big deal. The question is whether they also send over the content of edit fields, like the one I'm typing into now. My major workflow issue is starting a response on a web page on my iPhone, and then deciding I'd like to move to the desktop because it's going to be long. If they solve that problem, I'll buy another iPhone.
I would much prefer a different next step, which they kinda sorta have with those interactive debuggers - I'd like to directly link the GUI builder to the code, similar to but better than .net/VB. Ideally I'd like the ease of HyperCard in terms of moving from the GUI to the code that runs it. I think that is a much greater barrier to easy development and THEN you'd be ready for the jump to iOS. I mean, can you imagine storyboards on a iPad? *shudder*.
It could also increase program size and complexity. Optionality also implies nullability, which means that you can use a simple scalar type to box to an object, but have to include flags as well. Personally I don't know if this is a real issue or not, but its the one that leaves bits of crud like this in a number of languages.
Agree completely. With a few exceptions - "let", "->" and why oh god are there "@'s" in this language - I found it totally easy to grasp. If there were users that were turned off iOS/MacOS because of Obj-C, maybe this will grab them too. For those who haven't used it, this strikes me as all good. BTW, did you come across a way to call C code from Swift? I have whole libraries of C that do math, am I up the creek?
Given that the AppStore launched in 2008, and I'd have to surmise that the vast majority of submissions are from people who never looked at Obj-C before that point, that implies Apple convinced thousands (millions?) of people to pick up Obj-C in the last five years. So why shouldn't they convince them to switch to something that's supposedly much better? MS did with C#.
New Posts  All Forums: