4 ms·

Lattner takes "working" software to mean something that can be shipped to production and used in the real world, as opposed to the classic "works on my machine"

Lattner takes "working" software to mean something that can be shipped to production and used in the real world, as opposed to the classic "works on my machine" definition that second rate developers hide behind. It takes a certain maturity and experience shipping to recognize the long term benefit that approach. As the head of Apple developer tools (at the time), his job is not to cater to the hobbyist working on his fun software project, but improve quality of software on his company's platform.

spenrose 8y ago
If you remove the value judgments from your comment, you and I are saying the same thing. Many developers say they want to "get something working quickly", where "working" means "executing and performing some simple I/O, etc". Some developers don't value that stage, and prefer to develop until a piece of code is ready for wide-scale production. And that difference in values is just fine. 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/KaSKeg4vQtz https://plus.google.com/u/0/110981030061712822816/posts/KaSK...
- handle0174 8y ago
  This Latner quote was excerpted from his response to "What's the sales pitch for adopting Swift now?"
- blub 8y ago
  Is there any proof that the liberal perspective is able to produce software of sufficient quality? All the safety-critical development standards take a very conservative approach, especially in respect to development speed. 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.
wool_gather 8y ago
There's a tremendous amount of value, in any creative task, in being able to sketch out ideas quickly. The less time you spend seeing if the shape of the thing you're making is broadly okay, the more shapes you will be able to try, and the higher the chance that you'll converge on a good one. 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.
- nielsbot 8y ago
  I agree. Thank you for writing this. 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.
wool_gather 8y ago
> second rate developers hide behind. It takes a certain maturity and experience Also, you really could have phrased this to be a little less inflammatory.
- pertymcpert 8y ago
  Incompetent developers?

spenrose 8y ago

If you remove the value judgments from your comment, you and I are saying the same thing. Many developers say they want to "get something working quickly", where "working" means "executing and performing some simple I/O, etc". Some developers don't value that stage, and prefer to develop until a piece of code is ready for wide-scale production. And that difference in values is just fine. 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/KaSKeg4vQtz https://plus.google.com/u/0/110981030061712822816/posts/KaSK...

handle0174 8y ago
This Latner quote was excerpted from his response to "What's the sales pitch for adopting Swift now?"
blub 8y ago
Is there any proof that the liberal perspective is able to produce software of sufficient quality? All the safety-critical development standards take a very conservative approach, especially in respect to development speed. 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.

wool_gather 8y ago

There's a tremendous amount of value, in any creative task, in being able to sketch out ideas quickly. The less time you spend seeing if the shape of the thing you're making is broadly okay, the more shapes you will be able to try, and the higher the chance that you'll converge on a good one. 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.

nielsbot 8y ago
I agree. Thank you for writing this. 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.

wool_gather 8y ago

> second rate developers hide behind. It takes a certain maturity and experience Also, you really could have phrased this to be a little less inflammatory.

pertymcpert 8y ago
Incompetent developers?