- Why does Swift have both a "var" keyword and a "let" keyword? One should be sufficient with the other being a default behavior. If a symbol is not declared "var" then just assume it is constant or visa versa. Furthermore, it may not be necessary to have either of the key words because (I think) in every case, the need for variability and mutation should be determinable by the compiler. Type is already being inferred by the compiler, and mutability could reasonably be considered an aspect of type.
Having to use a keyword to introduce a new symbol is a pretty critical reliability feature. If there's no keyword to say "I want to define a variable", then every typo creates a new variable, rather than a compiler error. Lots of scripting languages work this way, and it's hell on reliability.
- Why are Swift collection types like Data always mutable? What happened to the concept of immutable containers from Cocoa. [Yes, I know the "bridged" CF types are always mutable, but that was another bad decision IMHO.]
They're not. That's why you have "var" and "let" keywords. You use "let" for constants, and "var" for mutable objects.
- Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
"Systems programming" != "device driver development". Nothing above the driver level should be accessing hardware directly, so that's a feature that could likely wait until every other Swift use-case has been addressed.
- Having experienced frustration trying to port high performance graphics code from C/C++/Objective C to Swift, what's up with that? IMHO, Apple's sample code for using OpenGL/GLKit/Metal from Swift leaves the impression that Swift is unsuited to the style of "low level" programming needed/used by OpenGL/GLKit/Metal.
Not sure what the actual complaint is here. Can you give an example of something that's particularly difficult?
- Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"
Part of the goal of Swift is to use compiler "smarts" to generate performant code. You can't really do much in the way of optimizations for dynamic dispatch, so it's not the preferred method. The bindings are there to talk to Objective-C, but Swift-native code is expected to solve those problems another way.
- Finally, a trivial aesthetic critique: Why "var foo : typename" like Ada and Pascal (IIRC) instead of "var typename foo" like every language that inherited C style syntax? Is there an advantage to the Swift approach that I haven't seen, or was it just an aesthetic choice? Did the choice not produce some IMHO "silly" syntax for method declarations with named parameters?
As far as I know, it's purely aesthetic. It's worth noting that type declarations are optional fairly often in Swift, so perhaps it was a decision to try to make the appearance of types less "jarring" where they *do* need to show up.
Why does the boot process require random numbers, anyway?
They mention this in the article - one way to make a kernel harder to write an exploit for is to randomize the layout of memory somewhat, so system libraries, kernel tables, and the like are located in different places. Obviously if the "random" numbers are predictable, this makes those mitigation techniques less-useful.
But it's far more questionable whether he would welcome the iPhone 5C—almost certainly a low-margin device, despite its current-generation components and plastic body—taking a bite out of the more expensive, and presumably higher-margin iPhone 5S
Seriously? This guys thinks the margins on the iPhone 5c are *lower* than the 5s? In that case, why is everybody else complaining about how expensive the 5c is, and saying it should have been released at a $300 price point? If you believe that the 5c could be made & sold at $300 (and I do), then since it sells at $550, Apple *must* be making something like 40% margins on them. The 5s is $100 more, but I bet it's considerably more-expensive to make.
It's likely that the percentage of outsourced projects tracks the prevalence of security problems. Certainly, the government has a very high level of outsourced vs in-house development. I think that financial institutions also tend to largely outsource (especially customer-facing) development.
I'd be willing to put a reasonable amount of money at risk predicting that Apple will eventually ship something that's not an iPhone or iPad, which runs the full version of Mac OS X on the ARM architecture. Given how smooth (relatively speaking) the PPC-to-Intel transition went, it'd be a minor speed bump for most developers, not a major disaster. If you're already supporting PPC and Intel, then ARM is just a testing burden - you already need to code for big- and little-endian architectures, for example.
Given the Mac App Store, there's a lot less in the way of friction to just recompile something and put it out there, as opposed to trying to get boxes on retail shelves. Yes, third-party developers will complain, and so will users if they can't get whatever apps they depend on right away. Given that Macs already come with all the basics (email, web, music/video playback), probably 75% of typical users wouldn't even need to buy anything for an ARM Macbook Air to get plenty of use out of it.
If you're willing to include software that was developed, but not released, there are:
m68k (original NeXT hardware)
i386 (NEXTSTEP for Intel processors)
SPARC (NEXTSTEP for SPARC)
HPPA (NEXTSTEP for PA-RISC)
Motorola m88k (NeXT RISC Workstation - never released, but a working copy was at Apple when I worked there)
PowerPC (Mac OS X Server 1.0, later developed into Mac OS X)
Significant bits of NeXT software were also ported to Intel i860 and DEC Alpha, but not enough of the OS to actually qualify as a "NEXTSTEP port"
I'm not sure I'm understanding the question, here. Do you mean could it be included with Android? Absolutely - the license allows that, though I'm not sure what advantage shipping a version of Enyo with an Android distribution would be. It'd likely be out of date fairly rapidly.
If your question was more along the lines of "will Enyo apps run on Android", then the answer is it depends a bit on what version of Android - there are some significant bugs with some Android browsers That said, the intent is for Enyo 2.0 to be compatible with as many web browsers as possible.
Yeah, the "adult is the murderer of the child' metaphor is fairly common in literature, but it's not something people use in everyday conversation, which is what the dialog in a movie supposedly represents. Like I said, even if Obi-wan is just trying to skirt around the truth, it really doesn't reflect well on him, or on the Jedi in general. Yes "your father is a mass-murderer who turned to the dark side of the force and now calls himself Darth Vader" wouldn't be a nice thing to hear, but keeping Luke's parentage a secret from him is leaving him open to be pretty badly blindsided in the future.
The twin sister bit is also easily explained, Leia shows no signs of being a Jedi, Luke does. It isn't until the expanded universe that sorce sensitivity in Leia is ever mentioned let alone developed as her being nearly as powerful.
Not that it's particularly relevant, but that's simply not correct. Here's what the ghost of Obi-wan has to say about Leia in Episode VI, after Luke figures out that she's his sister:
BEN She hasn't been trained in the ways of the Jedi the way you have, Luke... but the Force is strong with her, as it is with all of your family.
Anyway, like I said, these are relatively minor nots compared to the problems trying to tie the prequels and the originals together (for example, nearly everything Obi-wan says to Luke in episode IV makes no sense taken in the context of the prequels), but it's pretty clear that the original movie was written as a stand-alone, and the plot twists in later movies were not planned for in the original.
The most obvious problem is that in Episode IV, Darth Vader killed Luke's Father. In Episode V, it's "revealed" that Darth is Luke's father. It's not "impossible" to reconcile, but Obi-wan saying "what I told you was true, from a certain point of view", is an obvious attempt to wallpaper over this inconsistency. Best case, it just makes Obi-wan look like a liar and untrustworthy.
Another issue comes up when Obi-wan's ghost and Yoda are discussing Luke's running off to save his friends at Cloud City: Yoda: Told you I did. Reckless is he. Now, matters are worse. Obi-Wan: That boy is our last hope. Yoda: No. There is another.
Seriously? Obi-wan doesn't remember that Luke has a twin sister?
Anyway, those are just off the top of my head. Nothing like the horrible plot holes ewhen you try to connect the prequels with the original movies, but not great for movies that were made one after the other, a couple of years apart.
Swapping out Li-Ion batteries isn't like swapping out propane tanks. The value of a propane tank is basically $0, plus the cost of the propane. The cost structure on the batteries is exactly the opposite - the charge is essentially free, but the batteries cost thousands of dollars.
In order for battery-swapping to make sense, the same entity has to own all of the batteries, or there needs to be careful tracking and accounting for wear and tear on each battery. Otherwise, there's an economic incentive to cheat.
I'm not talking about releasing a few apps and libraries here and there while keeping the system core proprietary. I'm talking about getting complete system build without reimplementing a proprietary decade of development history from scratch.
Way to move the goalposts, there. Your original statement was that Apple was "not contributing anything back to the community", and that's clearly not the case.
Apropos of this discussion, look at one of the lists and see what sorts of licenses those projects are licensed under. The majority are APSL, which means that they're Apple-developed code which was released to the wider community without any requirement to do so. Of the remaining, about one third are BSD licensed, a third are GPL, and the rest are a variety of other licenses.
Note that the BSD-licensed code doesn't carry any requirement for Apple to release their source code, either. You might wish that Apple would release more of their code under an Open Source license, but that doesn't mean they're benefitting from Open Source without contributing back.
You can make this work if you do what the game console makers have historically done - get commitments from parts suppliers on price reductions over the expected lifetime of the product (due to Moore's law, etc) and aggressively plan as much cost-reduction as possible. You then sell the product for what it *should* cost when the product is mature. You lose a fortune on the first units, but the bleeding stops and eventually you can sell them at a profit.
Of course, if you mis-estimate the lifecycle, or fail to get the expected volumes, this is *really* risky. It's also not really clear what the expected lifetime of a tablet is, yet. The market's just not as mature as the video game console market.
If your operating system comes with an encryption solution that provides safety for you in the case that someone steals your laptop, then everyone with sense will use it. The number of people that would bother to look for something other than what's already provided will be vanishingly small. The major reason anybody goes looking for the third-party solutions that are currently available is because their OS didn't come with a built-in solution.
> (I have an iPad and like it, but the fact that I can't do shortcuts on the keyboard and can't run an interpreter on it or fork subprocesses means that it is much less useful to me than it could be)
For what it's worth, webOS is lacking in the keyboard shortcuts department, but otherwise meets those requirements. and you can install any software you want on it, without getting anybody else's permission first.
I'm really enjoying my Touchpad. I'm biased, of course, having helped write the software, but I think the usability of webOS is superior to iOS 4, and at least the current version of Android. The app catalog is a bit thin, but the apps we have are pretty great, and some of the features built into the platform make it so we don't need "an app" for every little thing (Synergy sync, in particular).
Whether the usability, lack of tight-fisted control over the platform, and our unique features will be enough to push it into the "success" column will be determined by whether we hit a "sweet spot" for developers and users.
I'm really enjoying my Touchpad. I'm biased, of course, having helped write the software, but I think the usability of webOS is superior to iOS 4, at least. Whether the usability, lack of tight-fisted control over the platform, and our unique features will be enough to push into the "success" column will be determined by whether we hit a "sweet spot" for developers and users.
I wonder what happens to your ability to sync/listen to those songs if you stop paying? My guess is that all those legal copies will just disappear from all of your Apple devices at that point.
The other risk is pooling. You're absolutely correct that there are anti-pooling countermeasures which not only can be taken, but essentially must be taken when dealing with hydrogen (aka, this isn't stuff you want sitting around in just an ordinary garage). Even still, even in structures designed to prevent pooling and detonation, it still happens. Fukushima being a glaring recent example, but there are countless others. Hydrogen detonates just so damned easy.
I'm having trouble figuring out how the least-dense substance known can "pool" anywhere. Under any normal situation, it's just going to escape into the air. Yes, it's flammable, yes, it can ignite easily in air. But the real danger with substances like gasoline is that the vapors are heavier than air, and can travel horizontally to an ignition source.
> Let's say you do pay full price for a phone... why is your monthly rate the same as someone who buys a subsidized phone?
Because they can, and because consumers don't understand how the subsidy works. I have known people to hold onto their old, broken, held together with duct tape phones for years after they were eligible for a free replacement.
It's just a CYA move for them. I believe they have the authority to just go ahead and do it, but they reasonably fear lawsuits. If someone gives permission, with the appropriate disclaimer, they're safe from the consequences.
It's not just that they will inevitably disable some number of the infected PCs by accident due to unexpected interactions with other software on the systems, either. Just the fact that they "accessed my computer without permission" would motivate some number of lawsuits, as well as the fact that out of a few million targets, some non-trivial number of them will happen to have hardware failure right after being "disinfected", which the users will then blame them for.
Slashdot Mirror
- Why does Swift have both a "var" keyword and a "let" keyword? One should be sufficient with the other being a default behavior. If a symbol is not declared "var" then just assume it is constant or visa versa. Furthermore, it may not be necessary to have either of the key words because (I think) in every case, the need for variability and mutation should be determinable by the compiler. Type is already being inferred by the compiler, and mutability could reasonably be considered an aspect of type.
Having to use a keyword to introduce a new symbol is a pretty critical reliability feature. If there's no keyword to say "I want to define a variable", then every typo creates a new variable, rather than a compiler error. Lots of scripting languages work this way, and it's hell on reliability.
- Why are Swift collection types like Data always mutable? What happened to the concept of immutable containers from Cocoa. [Yes, I know the "bridged" CF types are always mutable, but that was another bad decision IMHO.]
They're not. That's why you have "var" and "let" keywords. You use "let" for constants, and "var" for mutable objects.
- Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
"Systems programming" != "device driver development". Nothing above the driver level should be accessing hardware directly, so that's a feature that could likely wait until every other Swift use-case has been addressed.
- Having experienced frustration trying to port high performance graphics code from C/C++/Objective C to Swift, what's up with that? IMHO, Apple's sample code for using OpenGL/GLKit/Metal from Swift leaves the impression that Swift is unsuited to the style of "low level" programming needed/used by OpenGL/GLKit/Metal.
Not sure what the actual complaint is here. Can you give an example of something that's particularly difficult?
- Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"
Part of the goal of Swift is to use compiler "smarts" to generate performant code. You can't really do much in the way of optimizations for dynamic dispatch, so it's not the preferred method. The bindings are there to talk to Objective-C, but Swift-native code is expected to solve those problems another way.
- Finally, a trivial aesthetic critique: Why "var foo : typename" like Ada and Pascal (IIRC) instead of "var typename foo" like every language that inherited C style syntax? Is there an advantage to the Swift approach that I haven't seen, or was it just an aesthetic choice? Did the choice not produce some IMHO "silly" syntax for method declarations with named parameters?
As far as I know, it's purely aesthetic. It's worth noting that type declarations are optional fairly often in Swift, so perhaps it was a decision to try to make the appearance of types less "jarring" where they *do* need to show up.
Why does the boot process require random numbers, anyway?
They mention this in the article - one way to make a kernel harder to write an exploit for is to randomize the layout of memory somewhat, so system libraries, kernel tables, and the like are located in different places. Obviously if the "random" numbers are predictable, this makes those mitigation techniques less-useful.
Seriously? This guys thinks the margins on the iPhone 5c are *lower* than the 5s? In that case, why is everybody else complaining about how expensive the 5c is, and saying it should have been released at a $300 price point? If you believe that the 5c could be made & sold at $300 (and I do), then since it sells at $550, Apple *must* be making something like 40% margins on them. The 5s is $100 more, but I bet it's considerably more-expensive to make.
Buy them here
http://www.sakuraofamerica.com/Pen-Archival
These are my favorite sketching / writing pens.
Read all about them here.
It's likely that the percentage of outsourced projects tracks the prevalence of security problems. Certainly, the government has a very high level of outsourced vs in-house development. I think that financial institutions also tend to largely outsource (especially customer-facing) development.
I'd be willing to put a reasonable amount of money at risk predicting that Apple will eventually ship something that's not an iPhone or iPad, which runs the full version of Mac OS X on the ARM architecture. Given how smooth (relatively speaking) the PPC-to-Intel transition went, it'd be a minor speed bump for most developers, not a major disaster. If you're already supporting PPC and Intel, then ARM is just a testing burden - you already need to code for big- and little-endian architectures, for example.
Given the Mac App Store, there's a lot less in the way of friction to just recompile something and put it out there, as opposed to trying to get boxes on retail shelves. Yes, third-party developers will complain, and so will users if they can't get whatever apps they depend on right away. Given that Macs already come with all the basics (email, web, music/video playback), probably 75% of typical users wouldn't even need to buy anything for an ARM Macbook Air to get plenty of use out of it.
If you're willing to include software that was developed, but not released, there are:
m68k (original NeXT hardware)
i386 (NEXTSTEP for Intel processors)
SPARC (NEXTSTEP for SPARC)
HPPA (NEXTSTEP for PA-RISC)
Motorola m88k (NeXT RISC Workstation - never released, but a working copy was at Apple when I worked there)
PowerPC (Mac OS X Server 1.0, later developed into Mac OS X)
Significant bits of NeXT software were also ported to Intel i860 and DEC Alpha, but not enough of the OS to actually qualify as a "NEXTSTEP port"
I'm not sure I'm understanding the question, here. Do you mean could it be included with Android? Absolutely - the license allows that, though I'm not sure what advantage shipping a version of Enyo with an Android distribution would be. It'd likely be out of date fairly rapidly.
If your question was more along the lines of "will Enyo apps run on Android", then the answer is it depends a bit on what version of Android - there are some significant bugs with some Android browsers That said, the intent is for Enyo 2.0 to be compatible with as many web browsers as possible.
Yeah, the "adult is the murderer of the child' metaphor is fairly common in literature, but it's not something people use in everyday conversation, which is what the dialog in a movie supposedly represents. Like I said, even if Obi-wan is just trying to skirt around the truth, it really doesn't reflect well on him, or on the Jedi in general. Yes "your father is a mass-murderer who turned to the dark side of the force and now calls himself Darth Vader" wouldn't be a nice thing to hear, but keeping Luke's parentage a secret from him is leaving him open to be pretty badly blindsided in the future.
The twin sister bit is also easily explained, Leia shows no signs of being a Jedi, Luke does. It isn't until the expanded universe that sorce sensitivity in Leia is ever mentioned let alone developed as her being nearly as powerful.
Not that it's particularly relevant, but that's simply not correct. Here's what the ghost of Obi-wan has to say about Leia in Episode VI, after Luke figures out that she's his sister:
BEN ... but the Force
She hasn't been trained in the ways of the
Jedi the way you have, Luke
is strong with her, as it is with all of your
family.
Anyway, like I said, these are relatively minor nots compared to the problems trying to tie the prequels and the originals together (for example, nearly everything Obi-wan says to Luke in episode IV makes no sense taken in the context of the prequels), but it's pretty clear that the original movie was written as a stand-alone, and the plot twists in later movies were not planned for in the original.
There's a new enyojs.com website, where you can read about Enyo and try out some example apps, as well as downloading the current version.
The most obvious problem is that in Episode IV, Darth Vader killed Luke's Father. In Episode V, it's "revealed" that Darth is Luke's father. It's not "impossible" to reconcile, but Obi-wan saying "what I told you was true, from a certain point of view", is an obvious attempt to wallpaper over this inconsistency. Best case, it just makes Obi-wan look like a liar and untrustworthy.
Another issue comes up when Obi-wan's ghost and Yoda are discussing Luke's running off to save his friends at Cloud City:
Yoda: Told you I did. Reckless is he. Now, matters are worse.
Obi-Wan: That boy is our last hope.
Yoda: No. There is another.
Seriously? Obi-wan doesn't remember that Luke has a twin sister?
Anyway, those are just off the top of my head. Nothing like the horrible plot holes ewhen you try to connect the prequels with the original movies, but not great for movies that were made one after the other, a couple of years apart.
Swapping out Li-Ion batteries isn't like swapping out propane tanks. The value of a propane tank is basically $0, plus the cost of the propane. The cost structure on the batteries is exactly the opposite - the charge is essentially free, but the batteries cost thousands of dollars.
In order for battery-swapping to make sense, the same entity has to own all of the batteries, or there needs to be careful tracking and accounting for wear and tear on each battery. Otherwise, there's an economic incentive to cheat.
I'm not talking about releasing a few apps and libraries here and there while keeping the system core proprietary. I'm talking about getting complete system build without reimplementing a proprietary decade of development history from scratch.
Way to move the goalposts, there. Your original statement was that Apple was "not contributing anything back to the community", and that's clearly not the case.
Apropos of this discussion, look at one of the lists and see what sorts of licenses those projects are licensed under. The majority are APSL, which means that they're Apple-developed code which was released to the wider community without any requirement to do so. Of the remaining, about one third are BSD licensed, a third are GPL, and the rest are a variety of other licenses.
Note that the BSD-licensed code doesn't carry any requirement for Apple to release their source code, either. You might wish that Apple would release more of their code under an Open Source license, but that doesn't mean they're benefitting from Open Source without contributing back.
You can make this work if you do what the game console makers have historically done - get commitments from parts suppliers on price reductions over the expected lifetime of the product (due to Moore's law, etc) and aggressively plan as much cost-reduction as possible. You then sell the product for what it *should* cost when the product is mature. You lose a fortune on the first units, but the bleeding stops and eventually you can sell them at a profit.
Of course, if you mis-estimate the lifecycle, or fail to get the expected volumes, this is *really* risky. It's also not really clear what the expected lifetime of a tablet is, yet. The market's just not as mature as the video game console market.
If your operating system comes with an encryption solution that provides safety for you in the case that someone steals your laptop, then everyone with sense will use it. The number of people that would bother to look for something other than what's already provided will be vanishingly small. The major reason anybody goes looking for the third-party solutions that are currently available is because their OS didn't come with a built-in solution.
> (I have an iPad and like it, but the fact that I can't do shortcuts on the keyboard and can't run an interpreter on it or fork subprocesses means that it is much less useful to me than it could be)
For what it's worth, webOS is lacking in the keyboard shortcuts department, but otherwise meets those requirements. and you can install any software you want on it, without getting anybody else's permission first.
I'm really enjoying my Touchpad. I'm biased, of course, having helped write the software, but I think the usability of webOS is superior to iOS 4, and at least the current version of Android. The app catalog is a bit thin, but the apps we have are pretty great, and some of the features built into the platform make it so we don't need "an app" for every little thing (Synergy sync, in particular).
Whether the usability, lack of tight-fisted control over the platform, and our unique features will be enough to push it into the "success" column will be determined by whether we hit a "sweet spot" for developers and users.
I'm really enjoying my Touchpad. I'm biased, of course, having helped write the software, but I think the usability of webOS is superior to iOS 4, at least. Whether the usability, lack of tight-fisted control over the platform, and our unique features will be enough to push into the "success" column will be determined by whether we hit a "sweet spot" for developers and users.
Works the same as other App Store purchases. Buy once, install on all your machines.
I wonder what happens to your ability to sync/listen to those songs if you stop paying? My guess is that all those legal copies will just disappear from all of your Apple devices at that point.
The other risk is pooling. You're absolutely correct that there are anti-pooling countermeasures which not only can be taken, but essentially must be taken when dealing with hydrogen (aka, this isn't stuff you want sitting around in just an ordinary garage). Even still, even in structures designed to prevent pooling and detonation, it still happens. Fukushima being a glaring recent example, but there are countless others. Hydrogen detonates just so damned easy.
I'm having trouble figuring out how the least-dense substance known can "pool" anywhere. Under any normal situation, it's just going to escape into the air. Yes, it's flammable, yes, it can ignite easily in air. But the real danger with substances like gasoline is that the vapors are heavier than air, and can travel horizontally to an ignition source.
> Let's say you do pay full price for a phone... why is your monthly rate the same as someone who buys a subsidized phone?
Because they can, and because consumers don't understand how the subsidy works. I have known people to hold onto their old, broken, held together with duct tape phones for years after they were eligible for a free replacement.
It's just a CYA move for them. I believe they have the authority to just go ahead and do it, but they reasonably fear lawsuits. If someone gives permission, with the appropriate disclaimer, they're safe from the consequences.
It's not just that they will inevitably disable some number of the infected PCs by accident due to unexpected interactions with other software on the systems, either. Just the fact that they "accessed my computer without permission" would motivate some number of lawsuits, as well as the fact that out of a few million targets, some non-trivial number of them will happen to have hardware failure right after being "disinfected", which the users will then blame them for.