Swift really does not support quickly iterating on a design. It demands that you sit down with your plan fully-formed, ruler and protractor in hand. Due to its strictness, changes ripple very quickly across even a small codebase.
Realized you need another enum case? You can't compile again until you touch all your switches. Protocol would be more expressive with an associated type? Stop what you're doing and write some type eraser boilerplate. Function needs to signal an error condition? Try/do/catch anywhere you call it, right now, before you run again. Need to put another type into that array? Write a new protocol and add some conformances.
Changing a interface as you work in Swift immediately creates a sea of red marks, which hinders the ability to experiment.
You're right that this strictness helps write ~correct~ safe code, and I appreciate that. But it's a tradeoff; there's a real cost in developer productivity/creativity. And I believe that it does not help produce the best design. It takes too long to get to running, which makes it too costly to heavily revise based on what you learn as you build.
EDIT: Actually, I want to go even further, and strike out "correct" in the paragraph above. Swift helps at a certain level of correctness, which is really not much higher than the type system -- it would be better to call this "sound" code, rather than "correct".
The overall point that I'm trying to make is that at the level of application/business logic -- which is the whole point of the program, after all -- Swift does not help with correctness. In fact, it can be detrimental, because, unless/until you understand your use cases well enough to actually lift them into the type system, at that upper level it blocks exploration without adding rigor.
I realized recently that I actually do like static typing, as long as the cost is low. (I really like TypeScript)
Sorry, I don't want to reason about the "shape" of my application state vector before I've written it... but that's what Swift's static type checking forces me to do... Design my app and it's data model at the same time.
Call me a lazy software hippie I guess.
I find the opposite to be the case. You assume that compile errors are a net negative for speed of development and expressivity. Instead I find that the compiler reminds me upfront of all the places I would need to update anyway in due time. In a dynamic language those inconsistencies would be found hours/days later and usually after lengthy debugging. Instead I find myself making large sweeping changes in the design very frequently, because I trust the compiler to warn of any logical inconsistencies.
You have to admit at that this point it boils down to subjective preference. You sound averse to the swift style of doing the right thing up front, and using the compiler to help you stay consistent. I personally tired of the hidden and unacknowledged costs of unsafe language, and compilers that allow your design to degenerate into an unmaintainable ball of mud over time. I'm ok with swift being an acquired taste and a technical advantage of folks who get it.
With the exception of the associated types thing which is a language limitation that would be nice to see resolved eventually, the others can be resolved with a combination of automatic refactoring (add new enum cases, etc) and a compiler mode where type errors compile down to runtime traps without preventing you from running the program. (And faster compilation in general would help as well!) These are both non-trivial to design and implement well, but I think it’s a good future direction for statically typed languages that will give them many of the benefits of dynamic languages during the prototyping phase.
Absolutely, something like this would be perfect. I like being able to leverage the compiler in preventing runtime errors...just not necessarily all at once, right up front. Allowing some strictness to be dialed back in debug builds would be a very nice feature.
In C++ -Wswitch is a valuable tool to find the former, but there is no way to find the latter. This makes writing correct exception handling code much much harder, so having Swift's strict behaviour would be great from my perspective!
It sounds to me that you want to use a few days of exploratory coding to save a few hours of design work. If this type of exploration is needed, then it could be done in another language which supports it and then when the design is in decent shape it can be ported to Swift.
Swift is not detrimental to the correctness of the business logic. It offers you a bedrock at the type sustem level on which to build that.
Lattner used rhetorical slight of hand to assert, in effect, "you 'working quickly' developers need first to adopt my values; only then can you be admitted to the conversation." C.f. Yegge on liberal-vs-conservative developers. [1] Lattner (along with you) is adopting a position towards the conservative end of the spectrum, which is cool. What's not cool is gaslighting the existence of a liberal perspective.
[1] https://plus.google.com/u/0/110981030061712822816/posts/KaSK...
A program that executes and performs some I/O is a very very low bar to pass. The next step is not being ready for wide-scale production, in fact the IEEE Software Engineering Body of Knowledge aims to define the many steps required for that and it's a lot of them. Developing by the seat of ones pants is fine for personal projects, but not for publicly used software.
And why should what developers "want" be the main criteria that should be used to choose programming languages? It's certainly important that developers are able to extract some satisfaction from their work, but that doesn't mean we should sacrifice other important goals just for the personal comfort of developers.
Also, you really could have phrased this to be a little less inflammatory.