And how do you figure they are wasting space? Ever examined the content of their apps?
It's all about distribution issues. One-size-fits-all ends up requiring App developers to ship with 1x, 2x and now 3x bitmaps for the artwork. This does inflate apps, just as having multiple interface files specialization for multiple device sizes (~iphone & ~ipad xib files, or the bloating AutoLayout + Size Classes super storyboards). It's inevitable.
But Apple is also taking steps towards reduced bitmap footprints.
As of iOS 7, there has been FAR fewer bitmaps in the core OS in favour of lighter (visually and storage-wise) user interfaces.
With the introduction of PDF-based image assets that auto-compiles all the required resolutions, developers are now in a position to gradually rid themselves of the burden of maintaining multiple bitmaps (those where getting quite a hassle in large projects where every image was a trio of increasing sized bitmaps).
In OS X, PDF images are rendered natively and bypass the asset compiler. In iOS 8, the path is paved for abandoning bitmaps altogether.
So, no, Apple is not making their OS fatter on purpose. It's the cost of added features and backward compatibility that does that.
Your certificate is authenticated by checking against it's parent certificate authority. That parent also has a parent. Rinse and repeat until you reach one of the top certificate authorities. There are seven of those (or just about?).
For as long as the parents are valid and your certificate is valid, then it's considered signed.
VeriSign, a top certificate authority back in 2001, had made the news because it's DB got compromised. All certificates underneath where disabled and the whole tree had to be re-created. Symantec bought VeriSign since.
Touché. But an alias is still a distinct identification, unlike anonymous posting, for an alias is linked to an email address and that can be traced. Besides, my linked home page clearly identifies me.
I started with a blank project to write a Swift framework in order to learn the language and reach a usability goal of signing into a production server, make a couple of REST calls and yield out Switch class instances in a hierarchy, through unit tests. No UI.
Then I proceeded to replicate the same thing in Obj-c using the same class hierarchy, same object model. There was a near 1:1 correspondance in the whole thing. Where things differed were where Switft could not directly handle things like NSClassFromName where an Obj-C factory was embedded in the Swift code.
The exact numbers (now that you got me out of bed) was 84,341 bytes (file system rounded to 184k) for 29 items for the Obj-C version and 249,282 bytes (324k) for 23 items for Swift.
Size comparaison is no longer possible because the Swift was frozen on ice since jully-ish while the Obj-C version given considerable more smarts, expanded object model, additional services (REST calls handlers) and additional auth method (Basic, SSO, Form with redirection support while Swift only had Basic auth).
And yes, I know Swift is a moving target (we all cringed when they promised not to promise source compatibility between releases...). I can only hope it keeps on getting better. I just dont think its mature enough for a corporate environment such as ours.
Wish I could show side-to-side comparaison of where the major differences where and why swift ended up taking more code but sharing code is not the kind of thing my employer is very keen about (they own java and we all know how that went).
I can tell you where is a lot of "as String" or "as NSString" going on, and things like foo!.dynamicType(). One line I'll replicate is this one:
var version : NSString = bundle?.infoDictionary["CFBundleShortVersionString"] as NSString
Isn't it completely useless and mind boggling that I have to use "as NSString" at the end of this line if I took the express care of typing the "version" variable as NSString? Damnit, the compiler should be smart enough to do it for me. Things like that really need refinements. This ain't Hypertalk (remember that?).
Noteworthy is that I used the same coding style in both language in terms of line spacing, variables/types alignments using tabs and K&R style braces. As long as style did not contravene the convention of the language.
And I thought I was pretty nice (in Swift's favour) to not have mentioned "SourceKit crashes". But that's an XCode issue, not a language one.
The code was written for production consideration. In the end, the Obj-C version was retained. Yup. NSJsonSerializer. The was a level of abstraction around it to allow using a different (and faster) engine but not during those tests.
The wrapper includes facilities to map the resulting NSDicts to corresponding classes if they existed, or use custom class maps for customizing recipient objects based on calls. This conversion of dictionaries to class instance is recursive. Meaningful keys are also trapped on a per class basis so a -toJson round trip can be achieve, including optional retaining of unknown values (should the server object model not match the compiled classes. That was the part that Swift had shortcomings.
About them enums, I'm saying that havng to use a specific toRaw() to access the value is effin idiotic. For an inferred type language, you sure have to write an effin lot of garbage.
Wether your code is small and modular doesn't change the fact that you are still sending out entire source code out rather than simple headers that outline intended usage. When dev group x sends code your way, if the interface is full of symbols you should not directly access, wether they are marked privates still doesn't make the published code easier to deal with.
The Obj-C mangled names was in the documentation and WWDC presentation at Time of This comparative exercise.
And yes, code size was bigger in swift. Despite having 2/3 the number of files that the Obj-C version had (due to the header+mplementation duets). The exact numbers on my laptop but off the top of my head it was 234kb for Swift and 182 for Obj-c. If I could upload pics in/. Comments, I have a screenshot of both folders inspectors opened.
You can work out the syntax in under a week. It's an academic exercise at worst.
The real problem lies in the language itself.
The playground is a cool nifty feature but it's not something that could not be done with clang/obj-c. There was a time we could fix-and-continue code at runtime. They removed the feature instead of fixing it (at a time it was based on GCC).
Even today, using framework for custom views in Obj-C, you can code changes in your view code and see live changes in your layout files (xibs/storyboards) as you work in the code (I love this new features).
Speaking of IB_DESIGNABLEs, while they are awesome for special view coding for drawing custom content, they still lack the ability of interacting with their subviews in IB (the code is being called to render the view, without it's content), making its use for layout views not possible (such as a content-sorting or layout view).
Definitely Objective-C, unless your intent are for small home projects no one else will ever have to deal with.
Here is a bunch of random notes I took when evaluating Swift...
- No header files confuscate passed-on intended usage by exposing ALL class details rather than the intended consumable APIs.
Q: Is there any private/public scoping in the language? A: None! It's wide open. Apple promised at the WWDC to fix that. But it will probably take the form of private/protected keywords much like C++ in the class definition. They seem hard-bent on not having public header files.
- Access Control
In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework. The three access levels included in this release are: private entities are available only from within the source file where they are defined.
Internal entities are available to the entire module that includes the definition (e.g. an app or framework target). public entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.
Ie: public class ListItem {// Public properties. public var text: String public var isComplete: Bool }
Problem with that is regardless of access control, you are still exposing your entire class code and layout to users of it, preventing any restriction on class access for "consumable non-internal" implementations.
- optional means object can be nil. But they're just a wrapper.
Real-world test code being written showed you end up peppering your code with ? and ! symbols. Using ! unwraps a var to it's value. CHECK FOR NIL or use if let
Ig target.foo?() unwraps to if [target respondsToSelector(foo)] target.foo()
-weak reference need to be optional
-Swift "module" import uses the project group name; change a file from group and suddenly is out of the module
-AnyObject = id or Class type
Can't upcast AnyObject to a static type
wrong: var view: NSView = anyObject
need to upcast using as
var view: NSView = anyObject as NSView
or tested
var view: NSView = anyObject as? NSView
- Arrays upcast arrays: for item in myItems as NSButton[]
Your code end up having full of "as othertype" in it. So much for inferred type.
Random bridging nastiness:
-NSError** gets magically translated as NSErrorPointer
and you still need to pass by reference: &error
and then receiver must unroll pointer using !
- useless notations like optionals:
foo?.prop?.prop?.prop.ToInt() vs foo.prop.prop.prop.intValue;
Saved nothing. Obj-C can already handling nil object dereferencing
- Integration with existing code: Obj-C require Swift mangled name
SWIFT_CLASS("_TC5MyApp10MyDocument")
-STL-style templates
@objc func myGeneric(x:T)-> (String,String) {} ensures
func can be expressed in Obj-C at compile type
Need I say more?
- Specify obj-c accessor:
var enabled : bool
{
@objc(isEnabled) get {...}
}
further obfuscate the.swift file (remember: NO HEADERS!)
- Swift does not fix the CF bridging issue
Unmanaged for manual memory management. ie
let color = CGColorGetRandomColor().takeUnretainedValue()
Force the memory convention by annotating the header
Slashdot Mirror
Have you had regret nightmares since unleashing STL?
And how do you figure they are wasting space? Ever examined the content of their apps?
It's all about distribution issues. One-size-fits-all ends up requiring App developers to ship with 1x, 2x and now 3x bitmaps for the artwork. This does inflate apps, just as having multiple interface files specialization for multiple device sizes (~iphone & ~ipad xib files, or the bloating AutoLayout + Size Classes super storyboards). It's inevitable.
But Apple is also taking steps towards reduced bitmap footprints.
As of iOS 7, there has been FAR fewer bitmaps in the core OS in favour of lighter (visually and storage-wise) user interfaces.
With the introduction of PDF-based image assets that auto-compiles all the required resolutions, developers are now in a position to gradually rid themselves of the burden of maintaining multiple bitmaps (those where getting quite a hassle in large projects where every image was a trio of increasing sized bitmaps).
In OS X, PDF images are rendered natively and bypass the asset compiler. In iOS 8, the path is paved for abandoning bitmaps altogether.
So, no, Apple is not making their OS fatter on purpose. It's the cost of added features and backward compatibility that does that.
Breaking into VPN isn't that easy.
A bajillion dollars wont work.
You need rubber.
Enough said.
I'll wait for the Netflix release.
Your certificate is authenticated by checking against it's parent certificate authority. That parent also has a parent. Rinse and repeat until you reach one of the top certificate authorities. There are seven of those (or just about?).
For as long as the parents are valid and your certificate is valid, then it's considered signed.
VeriSign, a top certificate authority back in 2001, had made the news because it's DB got compromised. All certificates underneath where disabled and the whole tree had to be re-created. Symantec bought VeriSign since.
by fricking trains with lasers beams attached to their heads.
Touché. But an alias is still a distinct identification, unlike anonymous posting, for an alias is linked to an email address and that can be traced. Besides, my linked home page clearly identifies me.
And supports anonymous posting.
Being open-sourced it'll get forked and in no time Hawking will be able to communicate with the reptilians.
Most non-coders have the same attention spam as a Linux distro.
Soon enough, their free time forks off into another party. And we're not invited.
They are called Jobs Crisis and are meant as guidance. Solutions are the realm of the secret, hidden Second Jobs.
Cities are going to be built around this.
Because already they had too much.
Actually, it was the other way around.
I started with a blank project to write a Swift framework in order to learn the language and reach a usability goal of signing into a production server, make a couple of REST calls and yield out Switch class instances in a hierarchy, through unit tests. No UI.
Then I proceeded to replicate the same thing in Obj-c using the same class hierarchy, same object model. There was a near 1:1 correspondance in the whole thing. Where things differed were where Switft could not directly handle things like NSClassFromName where an Obj-C factory was embedded in the Swift code.
The exact numbers (now that you got me out of bed) was 84,341 bytes (file system rounded to 184k) for 29 items for the Obj-C version and 249,282 bytes (324k) for 23 items for Swift.
Size comparaison is no longer possible because the Swift was frozen on ice since jully-ish while the Obj-C version given considerable more smarts, expanded object model, additional services (REST calls handlers) and additional auth method (Basic, SSO, Form with redirection support while Swift only had Basic auth).
And yes, I know Swift is a moving target (we all cringed when they promised not to promise source compatibility between releases...). I can only hope it keeps on getting better. I just dont think its mature enough for a corporate environment such as ours.
Wish I could show side-to-side comparaison of where the major differences where and why swift ended up taking more code but sharing code is not the kind of thing my employer is very keen about (they own java and we all know how that went).
I can tell you where is a lot of "as String" or "as NSString" going on, and things like foo!.dynamicType(). One line I'll replicate is this one:
var version : NSString = bundle?.infoDictionary["CFBundleShortVersionString"] as NSString
Isn't it completely useless and mind boggling that I have to use "as NSString" at the end of this line if I took the express care of typing the "version" variable as NSString? Damnit, the compiler should be smart enough to do it for me. Things like that really need refinements. This ain't Hypertalk (remember that?).
Noteworthy is that I used the same coding style in both language in terms of line spacing, variables/types alignments using tabs and K&R style braces. As long as style did not contravene the convention of the language.
And I thought I was pretty nice (in Swift's favour) to not have mentioned "SourceKit crashes". But that's an XCode issue, not a language one.
The code was written for production consideration. In the end, the Obj-C version was retained. Yup. NSJsonSerializer. The was a level of abstraction around it to allow using a different (and faster) engine but not during those tests.
The wrapper includes facilities to map the resulting NSDicts to corresponding classes if they existed, or use custom class maps for customizing recipient objects based on calls. This conversion of dictionaries to class instance is recursive. Meaningful keys are also trapped on a per class basis so a -toJson round trip can be achieve, including optional retaining of unknown values (should the server object model not match the compiled classes. That was the part that Swift had shortcomings.
About them enums, I'm saying that havng to use a specific toRaw() to access the value is effin idiotic. For an inferred type language, you sure have to write an effin lot of garbage.
Wether your code is small and modular doesn't change the fact that you are still sending out entire source code out rather than simple headers that outline intended usage. When dev group x sends code your way, if the interface is full of symbols you should not directly access, wether they are marked privates still doesn't make the published code easier to deal with.
The Obj-C mangled names was in the documentation and WWDC presentation at Time of This comparative exercise.
And yes, code size was bigger in swift. Despite having 2/3 the number of files that the Obj-C version had (due to the header+mplementation duets). The exact numbers on my laptop but off the top of my head it was 234kb for Swift and 182 for Obj-c. If I could upload pics in /. Comments, I have a screenshot of both folders inspectors opened.
You can work out the syntax in under a week. It's an academic exercise at worst.
The real problem lies in the language itself.
The playground is a cool nifty feature but it's not something that could not be done with clang/obj-c. There was a time we could fix-and-continue code at runtime. They removed the feature instead of fixing it (at a time it was based on GCC).
Even today, using framework for custom views in Obj-C, you can code changes in your view code and see live changes in your layout files (xibs/storyboards) as you work in the code (I love this new features).
Speaking of IB_DESIGNABLEs, while they are awesome for special view coding for drawing custom content, they still lack the ability of interacting with their subviews in IB (the code is being called to render the view, without it's content), making its use for layout views not possible (such as a content-sorting or layout view).
Definitely Objective-C, unless your intent are for small home projects no one else will ever have to deal with.
Here is a bunch of random notes I took when evaluating Swift...
- No header files confuscate passed-on intended usage by exposing ALL class details rather than the intended consumable APIs.
Q: Is there any private/public scoping in the language?
A: None! It's wide open. Apple promised at the WWDC to fix that. But it will probably take the form of private/protected keywords much like C++ in the class definition. They seem hard-bent on not having public header files.
- Access Control
In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework. The three access levels included in this release are:
private entities are available only from within the source file where they are defined.
Internal entities are available to the entire module that includes the definition (e.g. an app or framework target).
public entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.
Ie: public class ListItem { // Public properties. public var text: String public var isComplete: Bool
}
Problem with that is regardless of access control, you are still exposing your entire class code and layout to users of it, preventing any restriction on class access for "consumable non-internal" implementations.
- optional means object can be nil. But they're just a wrapper.
Real-world test code being written showed you end up peppering your code with ? and ! symbols.
Using ! unwraps a var to it's value. CHECK FOR NIL or use if let
Ig target.foo?() unwraps to if [target respondsToSelector(foo)] target.foo()
-weak reference need to be optional
-Swift "module" import uses the project group name; change a file from group and suddenly is out of the module
-AnyObject = id or Class type
Can't upcast AnyObject to a static type
wrong: var view: NSView = anyObject
need to upcast using as
var view: NSView = anyObject as NSView
or tested
var view: NSView = anyObject as? NSView
- Arrays upcast arrays: for item in myItems as NSButton[]
Your code end up having full of "as othertype" in it. So much for inferred type.
Random bridging nastiness:
-NSError** gets magically translated as NSErrorPointer
and you still need to pass by reference: &error
and then receiver must unroll pointer using !
- useless notations like optionals:
foo?.prop?.prop?.prop.ToInt()
vs foo.prop.prop.prop.intValue;
Saved nothing. Obj-C can already handling nil object dereferencing
- Integration with existing code: Obj-C require Swift mangled name
SWIFT_CLASS("_TC5MyApp10MyDocument")
-STL-style templates
@objc func myGeneric(x:T)-> (String,String) {} ensures
func can be expressed in Obj-C at compile type
Need I say more?
- Specify obj-c accessor:
var enabled : bool
{
@objc(isEnabled) get {...}
}
further obfuscate the .swift file (remember: NO HEADERS!)
- Swift does not fix the CF bridging issue
Unmanaged for manual memory management. ie
let color = CGColorGetRandomColor().takeUnretainedValue()
Force the memory convention by annotating the header
CF_IMPLICIT_BRIDGING_ENABLED() //header content
CF_IMPLICIT_BRIDGING_DISABLED()
- String-types enums are a major fubar
Given
enum Method : String
{
case GET = "GET"
case POST = "POST"
case DELETE = "DELETE"
case PUT = "PUT"
case PATCH
They actually cached in lots of their stock one month before the release of the iPhone.
They knew very well what was going on.
Ferguson.
I'm still in the 2nd edition of TSR though.
It'll kill people by the millions. Spontaneously conjuring plagues and first-born viruses.
Whoosh.
Either way, the pun is over the biblical unilateral pro-god nature of the OS.
No de[a]mons there.
Or any kind of demons.
They got it down.
And up.
And down.
And up.
And down.
Pretty much means they crashed it.