On Dynamism
I’ve kept my hat out of the discussions of Swift vs. Objective-C for several reasons, but the main one is that frankly, I’ve been busy. I ship a product, one that I would consider successful, and recently shipped a major release. What does that mean? It means that debating these types of issues and playing with the latest thing is a luxury. Because I have a shipping product with a lot of users, I can’t just change things unless I find that it adds value to my users. My job is to solve my users’ problems. Now that I have a little bit of time to do so, this is one lens I’m hoping to add to this discussion
In addition, years ago, when Java was introduced, I jumped on that bandwagon, leaving behind Objective-C. It started out writing replacements for Foundation and AppKit in Java and ended with writing large scale servers. I was on that wagon for a good 10 years before returning, so I wasn’t a tourist there. This is yet another lens I also want to add to the discussion as history seems to be repeating itself and many younger people seem to be missing out on this part.
But let’s start with the current issue about dynamism since that’s the hot topic.
One thing many people seem to overlook about the dynamism of Objective-C is that it enabled NeXT (and Apple) to provide better GUI tools. Using dynamism, they were able to make GUI building declarative in nature. Connect this to that. Call this method. All stored in a file that was (and still is) data, not code. Competitors at the time (and today) resorted to code generation which is fragile and, ironically, unsafe. Yes, you could have a more declarative file format, but implementing that in using a static language required a lot of hard-coding and switch statements. Not the elegance that many people claim to be moving towards.
I’m not saying that a language has to be purely dynamic but it shouldn’t be purely static either. It think it’s spurious not to credit a level of dynamism for the quality of apps on Apple platforms over the years, and to be pedantic, the NeXT ones as well – many of which were considered the best on any platform at the time. To deny that, I feel, shows a lack of understanding of what has made the platform great all these years.
Moving from a dynamic language to a more static one seems refreshing at first. I went through the exact same thing when switching to Java. Yes, I can hear some of you grumbling “Java” out there but the irony is that there are more similarities in the evolution between Java and Swift than you may want to admit.
Everything seemed so much “tighter” in Java. Interfaces (Java’s version of protocols) everywhere! No more pointers! Checked exceptions! It’s all so new and exciting. You might just have to take my word on this, but any new language that you really like will always seem to make you “more productive”. A colleague and I (plus maybe one, or one and a half, devs who were on the periphery) implemented our own version of Foundation and AppKit in what I would consider a pretty short amount of time. Other people at Lighthouse can correct me on this but my recollection was that it was on the scale of months, not years. You can read up more on it here.
Was it the language? At the time we might say yes but in hindsight, I’d say it was just that we were just super excited and into the project. I was working with an exceptional team and being a new platform, we were excited about making our mark on it. Yeah, there were bits about Java that were better than Objective-C. But there were bits that were worse. The point here, though, is that until the honeymoon is over and you are maintaining a project over several years, it’s hard to make real proclamations about productivity. Truth be told, I’d say the biggest impact on software quality and productivity is the quality of engineers regardless of any other factors.
Looking back on my years with Java, I find the biggest problems with the platform was this idea that everything can be done by the compiler. It sounds great on paper but when implemented, it resulted in all sorts of contortions to work around not letting any dynamism in. It resulted in a lot of glue being written that I wouldn’t have to write in a more dynamic platform. It resulted in cascading changes across code to make trivial modifications just to appease the compiler. Maybe in a future post I’ll go into specific language features that I found problematic and show parallel trends/features in Swift but let’s just say that less is more. It’s an aesthetic that I always felt that put Apple above the rest and something which I feel like in some ways is being abandoned.
Now, I’m sure many of you will just paint me as an old, stubborn Obj-C luddite. And it’s true on some level but that doesn’t mean you should discount my experience. Many of us old fogeys are working on products that have shipped for years. That means that (1) we are solving user problems (2) have immense experience with doing app development (3) really understanding the frameworks (4) have been maintaining a code base.
Let’s go through these points:
1. We are solving user problems.
We have real problems to solve for people outside of ourselves. We need to be practical to survive. Users don’t care about the tech underneath. We have to ship them solutions. This oftentimes requires rapid response. This also oftentimes involves working around Apple bugs, bugs that never get fixed and will only grow in number as Apple maintains their yearly release schedule (something to think about for proponents of the “final” keyword). Agility and flexibility are paramount here. Reality is not pretty. The user could care less how beautiful your code is if you aren’t solving their problems.
2. We have immense experience with doing app development
I want to emphasize the “app” part of that. A common argument for very strict type safety are for cases which aren’t apps. The predominant software in the Apple ecosystem is end user applications. Let’s try and not lose focus here and argue the case for categories of software that aren’t Apple’s forte. If you are writing some life-critical software on an Apple platform, god help you. Even with Swift, you are stuck with Xcode and Apple’s insistence on yearly new OS releases.
3. We really understand the frameworks
I would take many of the arguments for Swift more seriously if there weren’t strawman examples set up on the Obj-C side. You’ll have to dig up Brent Simmons’ posts on this, but when I see the kooky examples of horrible old Obj-C way, what it tells me is more that you don’t understand the frameworks. It resembles informercials where people are fumbling opening a jar and then are presented with some useless gadget to solve a non-existent problem. I’m sure things can be done better than they are now but providing bad examples indicating ignorance of what it is you are trying to replace doesn’t help your argument. And I have seen plenty of examples of new people replacing what they don’t understand. Please don’t be one of those people.
4. We have been maintaining a code base for a while
I have been writing Hazel for ten years. Many of us old-time app developers are in similar positions. Speaking with many other devs, most of whom write iOS apps, I’d be lucky to find those that have maintained a code base for a third of that time. Sure, there are parts of the code that are ugly, but that happens on any platform. Same thing happened on Java. No matter what you do, time is always against you. When I was working with Java, I found the technical debt grew in a different fashion. It was hard to change anything. This was because changes in stricter languages tended to cascade. Because everything has to declare everything about itself, changing code turns into a Facebook feed, except where you and everyone else are obligated to respond to every stupid pic and forward of Snopes-bait. With a more dynamic code base, I can say I have less code to maintain and that I can be more agile. Not that it’s without it’s own problems. But let’s not act like type-safety is a panacea.
And to give more of my personal perspective on the language debate, I’d love to have something better than Objective-C. But I’d also like to have something better than Swift. My personal pet peeve is that we are in the 21st century and we still have to give a shit about the storage type of numbers. I’d be happy to get rid of scalar primitives entirely.
Ultimately, though, I need something that solves my problems. My problems aren’t performance. They aren’t type-safety (maybe it’s just me, but I rarely have issues with it and when I do, the time it takes to fix it is far less than the time specifying everything to a tee everywhere else). They aren’t being able to write clever VDLs. For me, it’s writing apps that solve my users’ problems and getting them out in a timely fashion. As it stands now, Swift (at least pure-Swift, or even current Swift as a non-ABI-stable moving target) does not do that for me.
Now maybe these same problems can be solved in a static way but what I’m not seeing from the static-camp are (decent) solutions. What I’m seeing are either hand-waving or the same crufty code-generation, write tons of repetitive boilerplate type of solutions that I had hoped we had left behind in the 90s.
What I do see makes me worry that it’s not the experienced app-writers that are being heard. Unfortunately, many of us are too busy to sit in the various mailing lists and forums. Yes, ok, we lose. But we all lose if those creating the platform don’t draw from the experience of those who have built upon it successfully. As someone who has done both (write frameworks and apps) and seen what happens when the former ignore the latter (the rise and fall of Java), I’m hoping history doesn’t repeat itself.
That’s my somewhat meandering brain dump for the moment as I do have to get back to working on my next patch. Sure, these are just my opinions but my hope is that we can at least look for more balance in our approaches to solving actual problems.
Category: Cocoa, OS X, Programming 36 comments »
May 24th, 2016 at 12:13 pm
This had me laughing out loud.
May 24th, 2016 at 1:19 pm
Thank you for writing this. Well said.
May 24th, 2016 at 1:54 pm
Thanks for sharing your thoughts.
> We really understand the frameworks
Indeed, when I was learning Cocoa – about 12 years ago – that really was the hardest and most intense part. But turns out it was worth.
May 24th, 2016 at 2:18 pm
Really well written, thanks Paul.
(Also, ancient “hi again!” from way back in Lighthouse history.)
May 24th, 2016 at 2:19 pm
Everything here is so spot on; so good!
May 24th, 2016 at 2:27 pm
Thanks for all the comments everyone. Was not expecting this type of response and surprised that I had more than two readers.
Greg: It totally slipped my mind when writing this, but thanks to you guys for writing the text system for the frameworks. And say hi to everyone there (except Jim).
For those that don’t know, Lighthouse and Omni had a close relationship back then with Lighthouse even selling OmniWeb in the beginning. In any case, when we were doing the Java frameworks, Omni did the NSText/NSTextView equivalent which, if you’ve spent any time with the Cocoa text system, is no small feat.
May 24th, 2016 at 2:52 pm
Thank you for expressing this so well.
May 24th, 2016 at 4:04 pm
I don’t mean to be rude, but you’ve presented us with 4 arguments from authority, and that’s not a proper way to argue.
It sounds like you’re trying to use Swift as if it were less verbose Objective-C, which it’s not.
Also it is not Java, and I see no point in drawing comparisons between them. Sure, they are both strongly typed and have packages instead of headers, but that’s where similarities end.
Yeah, Swift will require us to change the way we develop apps – more coding instead of connecting outlets, maybe even adoption of once esoteric technologies like FRP, or maybe we will even get rid of Interface Builder (probably not, but I would really love to).
But if it will result in safer and faster code, why not? I for one would not miss “[NSNumber length] unrecognized selector sent to instance of blablabla” or [setValue:forUndefinedKey:] exceptions.
May 24th, 2016 at 4:30 pm
Well, I’m not using Swift right now as mentioned, it doesn’t solve my problems.
The parallels with Java go beyond that. I’m not talking about the language features specifically (though there are more than you cite). It’s how it’s being developed, how people are jumping on the bandwagon, and how both projects are/were in danger of losing focus on what they are supposed to do. The notion of compile-time safety at any cost is what limited Java in many ways and its the same mindset that is prevalent in Swift. To not suffer the same fate, Swift has to not try and be everything to everyone and realize why it was created.
“more coding instead of connecting outlets” – that is not a good thing. IB is a good thing and I’m curious as to why you think otherwise (and I mean by design, not because of bugs you have with it). Tools which more directly let us see and manipulate things is a step forward. WYSIWYG word processors are the way documents should be edited. Editing UIs graphically was a huge innovation and I have a hard time seeing how reverting to editing that all in code is preferable.
As for those errors, I don’t miss them either because they don’t happen much. When I do, it’s usually because of a memory issue (i.e. another object go allocated in a freed object’s space). That points to more of a shortcoming of ARC as opposed to GC, which while you can argue about performance, results in safer memory management.
And safety for its own sake is precisely the point of the article. Is it worth it if you spend more time preventing it than the times you would have spent fixing it? And is it worth it if it prevents you from providing certain features to your users? How much are you willing to give up for some theoretic 100% safety that you seem to be shooting for? Do you do 100% coverage on your unit tests? If not, why not? Maybe because there are higher priorities than trying to spend an inordinate amount of time to assure low-risk sections of your code are absolutely “safe”.
May 24th, 2016 at 4:40 pm
Oh and on the topic of invalid arguments, let’s see, gross mischaracterization (can be classified as ad hominem or strawman). Oversimplification. No concrete examples – more hand-wavery.
May 24th, 2016 at 5:27 pm
Am I glad to see this article! Finally a focus on the problem! For so long I have thought I was the only one experiencing this. When I do the Dynamism on my Macintosh Performa 6220 I try to open the EWorld internet program but it stalls out even when I put the eWorld romulator into the compact disk reader drive tray. I put it in, the tray opens with the Dynamic Swift program, and I try to run it, but it does just stall out. Every time! Apple won’t offer any support on this and they tell me it is not compatable with the New Macintosh, but I tell them I already paid $3500 for this Macintosh Performa 6220 model and I sure as heeck ain’t going to replace it for nothing!!!
I am at the Gym right now using Delray’s pass but you can page me on the intercom if you want to talk about it 408-974-6803 I also have the email on my The iPhone and you can reach me there too 408-434-85** the last two digits are the same as the last two digits in my email address @me.com if you want, I am free to talk at the gym or after words when I will be back home. I live in Cupertino and use the Gym here at the campus sometimes for convenience.
Let me know what you think,,
Bill Evans
May 24th, 2016 at 5:28 pm
And I just wanted to say I am not the “Technical Type” to get into the weeds with this problem, but I am glad you are finding it for us!!
Thanks,
Bill Evans
May 24th, 2016 at 5:30 pm
The part about Swift that has me less than enthused is the idea that Swift will be a language that you can use for everything, as a C replacement, to writing Server side services, to creating apps.
If Swift were to truly stick to this goal, it would almost certainly require a lowest common denominator approach to features, where a feature that might greatly enhance app development may be excluded because it would cause a 0.005% increase in server response time.
It sounds too much in scope like “Write Once, Run Everywhere” for me to be entirely comfortable.
May 24th, 2016 at 5:57 pm
I went through a similar transition from Java to Scala a few years ago, and then from JavaScript to TypeScript. I haven’t used Swift, though my wife does, and she occasionally shows me source code. And I haven’t done much Objective-C since the NeXT days. I too spent a fair amount of time reinventing NeXT libraries (EOF, a.k.a. WebObjects) in Java.
The world of languages has changed a lot in the last 5-10 years. Much more than the decade before that. Swift is just one of a host of early-binding (i.e. less dynamic) languages that are replacing late-binding ones.
Perhaps the biggest advantage of early-binding (i.e. less dynamic) languages these days is IDE support. It’s no coincidence that two of the biggest IDE makers are designing their own languages. (TypeScript, a JavaScript replacement from Microsoft; and Kotlin, a Java replacement from JetBrains.) Microsoft explicitly advertises IDE support as the major advantage of TypeScript.
Since Apple’s IDE is pretty mediocre and doesn’t support Swift refactorings, you lose a lot of the potential advantages right there.
The biggest change in the last 5-10 years is that early-binding languages have gotten clever about inferring stuff that only late-binding languages used to be able to do. The most obvious is type inference. As a result these new languages are often just as compact and expressive as many dynamic languages.
In the last year or two, I’ve seen lots of examples of new early-binding languages replacing dynamic languages on late-binding’s home turf. Other that Swift replacing Objective-C we have:
1. Facebook introducing JSX, a compiled JavaScript/HTML replacement for building web components.
2. Angular 2.0, a web framework, is built around TypeScript, while 1.0 is built around JavaScript. (Either language can be used with either version.)
3. And in the last week, it was announced that Gradle 3.0, a Java build tool, will allow build scripts to be written in Kotlin instead of Groovy. Groovy Gradle scripts look like configuration files. Kotlin Gradle scripts are slightly more verbose but let the IDE provide a lot more help.
May 24th, 2016 at 6:24 pm
David: Thanks for the input.
IDE support is definitely something though JetBrains has shown you can do a lot more than what is currently available with Obj-C as well. Xcode may not be the best example for this aspect of the discussion.
I’m not familiar with those platforms so I have no frame of reference on whether those moves were good things or not. Even if it was a net gain, I think the part of the discussion which keeps getting glossed over is the cost. What did they lose by going that route? Is that something we can afford to lose on Apple platforms?
May 24th, 2016 at 8:54 pm
It was a very good read. I’ve also been reading such posts on Obj-C from “old timers” (Brent Simmons, Michael Tsai, Daniel Jalkut, Marco Arment and others… haven’t seen David Owens III except in comments above).
I agree with you (mr_noodle) that the dynamic hook up of IB Outlets and such in Xcode felt magical, and I think that would truly be a big loss from a client app standpoint. At one point, I considered re-writing my company’s GUI so it wasn’t what I consider a ‘dead language’ (written in FLEX, more info below). Indeed I wonder how they will handle GUI items in a graceful way.
However, I have spent my life after college working on server-side applications handling all the backend services and letting someone more gifted at UX handle the front-side. In many ways, I can understand the desire for more static typing in business-related apps, or server-side if you will. They don’t often have the most educated/experienced of developers in the field.
I personally think they’ll try to add some more dynamic functionality to the language to cover GUI use cases, but are there “absolutely critical” dynamic cases they must hit lest they fail on the GUI side? I don’t want to imply that Apple is pivoting to a more server-side/biz-oriented focus, but IFF they do, what are the critical pieces that could be brought over from Obj-C/Cocoa that were essential for GUI dev?
Kelly
** Note: As you can tell, I never shipped any app, I developed items on my Mac for internal applications because I thought it was an interesting learning exercise. As such, I may not know the great tricks & tips that were known to many in the app dev scene. My questions probably stem from genuine curiosity and perhaps lack of depth of knowledge in the Obj-C env.
May 24th, 2016 at 8:59 pm
There seems to be the mistaken impression that static typing prohibits the kind of flexibility that Cocoa’s declarative GUI building requires. The solution that gives the best of both worlds is a type system that supports algebraic data types (like Haskell or Standard ML). With ADTs, you can have static, type-safe code that is flexible and extensible. I’ve seen a bit written about ADTs in Swift (http://thepurecoder.com/algebraic-data-types-in-swift/) but it seems rather clumsy at this point. This might be a good solution in the future, though.
May 25th, 2016 at 4:56 am
Noah Daniels: Your comment is interesting. Can you please elaborate? I don’t see the parallels between Objective-C dynamism (e.g., easy UI building) and the extensibility of algebraic data types. (After all, ADTs are determined at compile time and if you add information to an ADT, you have to adapt your codebase accordingly.)
May 25th, 2016 at 5:40 am
Quote: “One thing many people seem to overlook about the dynamism of Objective-C is that it enabled NeXT (and Apple) to provide better GUI tools. Using dynamism, they were able to make GUI building declarative in nature. Connect this to that. Call this method. All stored in a file that was (and still is) data, not code. Competitors at the time (and today) resorted to code generation which is fragile and, ironically, unsafe.”
Unless you are using “dynamism” here in a way that I’m not familiar with, it feels to me like you’re mixing up language support for introspection and reflection–that is, the ability, given a class object, and some features of that class, like a method name or a field variable name, to manipulate those parameters of the class–with the features commonly associated with dynamic programming languages (dynamic typing of variables, dynamic addition of code, dynamic object extension).
The fact that no-one (at least that I’m aware of) has built a Interface Builder style system for Java without resorting to code generation doesn’t mean you couldn’t do it using Java’s introspection and reflection features. There is no reason why someone couldn’t ship a Java Swing interface builder project that uses the java.lang.reflect classes to unroll a serialized object from data (ObjectInputStream already does this), and, given an object, discover the variable fields and pre-populate them, or to send messages to methods by name. Sure, you’d have to include a small library to support both parsing the interface file and sending messages to methods by name–but that’s only because that is not part of the Java RTL.
Introspection and reflection do not require any of the features associated with a dynamic language (dynamic types, dynamic modification of the code at runtime), it only requires that the compiler generate type information sufficient to allow the discovery of fields and method calls by name for a given object.
And heck, even the guys maintaining the C++ specification are looking into adding reflection to the C++ language.
May 25th, 2016 at 10:55 am
I was trying to really put into words why I do not like Swift, other than just the syntax (“let”, “var”, “func”- really???). You did it for me.
I love the dynamism of Objective-C. As you’ve said, it really opens up so much that a static language like Swift prevents, or make extremely difficult.
I also find Swift to be a language that encourages cleverness leading to obtuseness. Objective-C is extremely readable, where as Swift is compact and much less readable.
I hopeful that Objective-C will remain a first class citizen for a long while, even if Swift continues to grow.
May 25th, 2016 at 11:03 am
One point I glossed over was the reflection API in Java. That does give you dynamism (and yes it is dynamism since it results in runtime checks and errors). It was added so that they could implement tools but it was pretty much prohibited from use in anything else. So the libraries could not make use of any of that dynamism.
Also, yes, server-side Java tended to be static (and to be fair, from my experience, the programs themselves had pretty static pipelines). But many still made use of dynamism indirectly. If you used any object-relational mapping tool, reflection was used there. Even now, people writing Swift apps now are taking advantage of dynamism through the Objc bridge. It’s easy to say you don’t need dynamism if someone else is doing the heavy lifting for you.
Noah: Interesting. I’ll have to take a closer look at it but my more general concern is the contortions and complexity people are willing to pile on a language for some idealistic goal which I feel is a bit out of touch with reality.
I feel like inordinate amount of time, effort and complexity is being applied to something that can be solved much more simply if people would just relax a little. The zealotry (not from you, just pointing out other responses people have had on this topic) can be strong on this topic.
May 25th, 2016 at 11:23 am
Kelly: It’s hard to predict how Apple is going handle this. To give us the capabilities we already have, the basic things that come to mind off the top of my head are being able to do the following dynamically: determining what method to call, finding and instantiating a class, determining if an object implements a method.
I’d be curious to see if what new paradigms people come up with but many responses I see seem to be short on details or rehashes of previously rejected proposals.
May 25th, 2016 at 9:05 pm
“One point I glossed over was the reflection API in Java. That does give you dynamism (and yes it is dynamism since it results in runtime checks and errors). It was added so that they could implement tools but it was pretty much prohibited from use in anything else. So the libraries could not make use of any of that dynamism.”
You must be thinking of Java 1.1, because nowadays (and since at least 1.4) everyone and their dog is using reflection in Java. You cannot do AOP without reflection, and that’s half of the Spring library. (Full disclosure: I hate Spring; the overuse of reflection creates its own problems.) Heck, you can’t do object serialization and deserialization, which is behind a number of server-side libraries that handle everything from back-end support for client-server to serializing database objects.
Also, as a footnote, if “runtime checks” qualifies a language as “dynamic”, then C is a dynamic language, as certain functions (such as opening a file) result in a runtime check. On the other hand, with reflection in Java (and in other languages) it is possible to do a check of your layout data file against the compiled code to verify during a check pass if all the objects and methods noted in the layout data file are present. Java actually makes that easy for a library provider to do: after the jar files are generated, load them in a custom class loader and introspect to verify the fields and methods in your data file are present.
(Why Apple doesn’t do this: that is, why there is no “lint”-like function–and yes, I’m dating myself–during copying of nib files, is beyond me. For me, the whole thing is about creating an integrated tool chain that catches as many problems as possible.)
May 25th, 2016 at 9:31 pm
Are we talking about official frameworks? I know third parties use reflection (and yes, I’ve used and am not a fan of Spring either) but I don’t know of any of the standard libraries using it, but then again it’s been a while.
I think we can all agree that there can be vast improvements made on the tool end of things.
May 26th, 2016 at 5:46 am
Thanks for saying this. My thoughts exactly. My main occupation the last 14 years was developing and maintaining a Cocoa app in objective-c. I wouldn’t be able to write such a big application without the benefits of the objective-c dynamism and leaving that behind is an odd thing for Apple to do. I really don’t get it.
When Apple intoduced Swift, they said “Objective-C without the C”, as time passes it seems more and more like “Objective-C++ without the Objective”.
May 26th, 2016 at 4:54 pm
John – the point is that rather than having complete dynamism through message-passing (where any message can be passed to any object, but you’d better hope it’s implemented) typeclasses and ADTs would allow for a more specific set of (for example) user interface functions to be called on the appropriate objects, while allowing for the correctness to be checked at compile time.
May 26th, 2016 at 6:50 pm
> Ultimately, though, I need something that solves my problems. My problems aren’t performance. They aren’t type-safety (maybe it’s just me, but I rarely have issues with it and when I do, the time it takes to fix it is far less than the time specifying everything to a tee everywhere else). They aren’t being able to write clever VDLs. For me, it’s writing apps that solve my users’ problems and getting them out in a timely fashion. As it stands now, Swift (at least pure-Swift, or even current Swift as a non-ABI-stable moving target) does not do that for me.
While I feel I understand what you mean by the above, as someone from outside both ObjC and Swift, but with a strong interest in languages, it’s still hard to understand what exactly you’d need.
In that sense I read the above more like: “As a long time ObjC developer with an existing ObjC code base, I don’t think Swift is improving my productivity.” Even to this I could probably come up with some arguments (e.g. better tooling => faster development, less and more explicit errors => shipping faster, faster code => happier customers, etc.)
There are too many facets to this problem to be able to generalize it though. And in the end, I could agree with something like: “for my code base and based on my experience and level of expertise, I don’t think Swift brings any major improvements”.
May 26th, 2016 at 7:28 pm
Alex: It’s all about trade-offs. I don’t consider the complexity and limitations of type-safety are a good trade off to prevent a small class of bugs that are uncommon, easily found and easily fixed. It’s all about a measured response and I feel like it’s unbalanced in this case.
My concern is, because I’ve seen it before, is pursuit of safety over all other things. For some, it becomes a mantra without any notion of whether it has a big enough effect in reality. Type-safety is only small kind of safety and in the bigger scheme of things, it really isn’t all that. If I were to prioritize the problems I need to solve, it would not be in there.
Yes, shipping faster is great but type safety goes against that. My experience is that it makes you less agile. That’s the price you pay for things being more tightly bound.
And I’m not saying Swift isn’t bringing any improvements. There are a lot of great things about it. But it has fundamental issues that need to be addressed and instead of good answers I’m seeing a lot of dismissal and denial from certain segments, which is really unfortunate. I suggest checking out Brent Simmon’s series of posts and seeing the types of responses he gets for legitimate and earnestly asked questions.
May 26th, 2016 at 8:12 pm
mr_noodle, firstly thanks for answering.
1. You’ll noticed that I haven’t mentioned type safety as the main enabler of shipping faster, but rather better tooling and less/more explicit errors which are deriving from it.
One can code with TextEdit, or Vim, or Emacs, or Xcode or Visual Studio or IntelliJ IDEA. And I assume you know what I’ll say next (I don’t want to shift the conversation in that direction though).
2. Truth being told, type information always exists. It’s either explicit and available to the tools you are using and also right in front of your eyes, or it can all exist in your head. My argument is that the latter is less optimal for larger projects or larger teams or libraries that are meant for others to use.
3. The above is also the reason I tried to better understand your perspective here by framing it to your experience, development process (I confess that I have no idea if you are working with a team or alone), and your application (once again I have no idea if you are working on a single code base, Hazel, or you have to maintain multiple products or change gears ever).
I did read most of the posts on this topic and, as far as I can tell, the feedback expressed in these posts is from the point of view of “if I’d be to rewrite my existing iOS or Mac app in Swift, what would I win?”. Please don’t get me wrong, I do believe it’s a very valid perspective. But I also hope we can agree that it’s just one side of the coin when looking at a new programming language (and a coin only has two sides while there are many more in this case :-).
May 26th, 2016 at 8:45 pm
I’d say it’s a pretty important perspective and it deserved better than what was given by certain camps.
My development history is quite varied. I do Hazel alone. During the Java years worked on various teams of various sizes and was a director of a department at one point. Lighthouse was a pretty small company yet produced quite a few very featureful apps. I’d say the ratio of engineers to apps was close to 1:1 but through very smart planning and rotation, great talent and use of well-written common libraries, we were able to support them all. Some of their apps formed the spiritual basis for apps you use now (Diagram->OmniGraffle, Concurrence->Keynote). Actually, those two programs were either written by or lead by ex-Lighthouse people.
BTW, one factor which is sorely missing on Apple platforms but was standard in Java was documentation. With javadoc, you had a standard documentation system and people used it. I’d say that, more than anything, was what kept things together. Apple has dallied with various doc systems in the past but never really went all in and had it fully integrated into Xcode, which is too bad.
The point here is that the focus should be on shipping apps. Not on appeasing some academic ideal or writing types of software that aren’t really Apple’s thing (like servers, for instance). I think chasing either at the detriment of the true goal is something that needs to be watched.
May 26th, 2016 at 8:54 pm
Oh, and one more thing, don’t just take my word for it. Look at the responses to this post and check twitter. There are a lot of people writing the apps you (figuratively, not you specifically) use every day. It’s far from an isolated perspective.
May 27th, 2016 at 1:11 am
I confess that I’m not really sure why are you implying that I suggest this is an isolated perspective. I don’t think I suggested or implied that in any of my comments. But if that’s the impression I’ve left you with, then I apologize.
As someone interested in programming languages and developer tools in general, I’m very curious to seeing how Apple is proceeding with Swift. It was introduced as a general language that can be used for scripting, but also server side coding, iOS, and OS X applications. As a non iOS or OS X developer, the experience of using Swift was very lacking. Learning about the perspective of OS X and iOS developers helps me see a larger picture.
May 27th, 2016 at 11:08 am
Alex: I highly recommend following Michael Tsai’s blog: http://mjtsai.com/blog/
He does an exceptional job keeping his finger on the pulse of developers in the Apple world and keeping a balanced view of things. If there’s any one feed you should subscribe to, that would be it.
May 29th, 2016 at 5:53 am
“It think it’s spurious not to credit a level of dynamism for the quality of apps on Apple platforms over the years, and to be pedantic, the NeXT ones as well – many of which were considered the best on any platform at the time. To deny that, I feel, shows a lack of understanding of what has made the platform great all these years.”
I wonder whether this is actually true (independent of the specific technical merits of dynamism, staticness and everything in-between). Apple had an ecosystem of high quality apps before the NeXT purchase on a platform so primitive it’s hard to meaningfully describe it in ‘dynamic vs static’ terms. It had a culture of quality in visual, interactive and, uh, ‘intestinal’ design that matched what was produced for the then much more sophisticated WhateverStep platform. Conversely, other technically sophisticated platforms (say, .Net, Firefox XUL if we’re to pick ‘declarative UI’ as a criterion) haven’t produced a great deal of elegant or aesthetically pleasing apps over the years.
I can’t claim a decade of experience of shipping an OS X app but I was also there for the Java honeymoon and spent some time reimplementing Foundation/AppKit/IB/EOModeller/EOF in Java. Your take on it sounds head-noddingly familiar but I don’t find it as obvious you do the relationship between dynamism and quality is causal.
May 29th, 2016 at 10:46 am
I’d say during the NeXT years, the apps on that platform were superior to the ones on Mac OS. One example: Virtuoso, by Altsys. It was a vector drawing program that was then morphed into what became Freehand 4 (the file formats were even the same). Another example: Improv by Lotus. It was later ported to Windows. In both cases, the non-NeXT version was clunky in comparison.
Also, it’s not declarative UI in and of itself. It’s just one of the results that dynamism, well-integrated into the language, brought. Correct me if I’m wrong but C# is still a strongly typed language (don’t know anything about Firefox XUL to comment).
June 2nd, 2016 at 10:56 pm
Can you explain why you consider code-generation unsafe?