Swift Protocols Question

A lot of the debate over Swift is really over a loose typed dynamic language vs stonger typing more compiler optimized. The advantage to types is catching many errors at compiler time rather than runtime. But there’s no doubt it has a lot of tradeoffs including much poorer reflection.

It’s interesting with the move to thinking in terms of protocols as pseudo base types rather than basic classes that there is a lot of power. More than ObjC offers. Yet the common complaint among Haskell types is that there aren’t (yet) enough basic abstract types. Hopefully people will point out what protocols are missing and what their value is.

@Clark: I don't think lack of reflection is due to stronger typing; just that the language designers don't think it's as important/necessary.

The main disadvantage is in speed of early development and one-off solutions, where it's more valuable to get something up and running so you can try it out, rather than ensuring every last 'i' is dotted and 't' is crossed just so you can execute some quick-n-dirty code that you're going to be throwing away again five minutes later anyway.

The quicker you can throw away your code, the quicker you can do it right. There's not a person alive - programmer or otherwise - smart enough to come up with the correct solution to every problem, first time every time in time. The only way to get there is to try something quickly, work out where and why it sucks, then throw it out and try again - and keep repeating that process, progressively building on the lessons learned, until you understand the problem well enough to produce the correct solution. "Write one (or - even better - may) to throw away"; to paraphrase the great Fred Brooks.

It's something the belt-n-braces brigade frequently loses sight of, just as scripting types tend to ignore the costs that accrue by failing to automate their correctness checks. And really it's a false dichotomy, as there's no good reason why a language can't be designed to support both modes of development, and still provide benefits to all (e.g. soft typing).

Incidentally, my own scripting language, kiwi, is as weakly, dynamically typed as it gets, yet gets great value out of type and constraint annotations without ever being burdensome about it, providing documentation, runtime correctness checks, automatic bridging to the underlying implementation language in primitive plugins, and (in future) autocompletion/autocorrection support in code editors too. And I'm just a dumb dilletante scratching the surface at one end of the scale, so the exceedingly smart brains at the other really should have no problem exploring equivalent ideas at theirs.

And who knows, eventually some day we'll all meet and discover we've all been chewing on the same problem after all, and there never was any reason for having such spats in the first place. (Yeah, and programmers might fly...;p)

I disagree with Brent's assertion that "Objective-C, because it’s less strict with types, is closer to a scripting language than Swift is". While the "Objective" part may derive from Smalltalk, which is as dynamically script-y as can be, the C part will roger you sideways in ways no scripting language ever would or should the moment you take your eyes off it, in good part because C doesn't even have a type system to speak of, just a mismash of pedantically nitpicky and completely unavoidable compiler annotations for allocating memory on the stack.

Whereas Swift feels quite like a scripting language, at least up until the point the type system kicks in and starts complaining about what you've written, which actually wouldn't be un-scripting-like if it weren't for the fact that it blocks you executing the code too.

But again, that's nothing that couldn't be solved with a couple of compiler flags for flipping it into soft, fully-latent typing mode, with any ambiguous or unknown types automatically treated as AnyObject? with dynamic dispatch so that code can always be run now and tightened up later as/if needed.

IIRC, Dylan was quite relaxed about this sort of thing (+1 for the Lisp school, as usual;), so I don't think there's any technical reason it couldn't be achieved in a nice shiny new platform like Swift; just the normal everyday micromanaging OCD martinet tendency of programming languages and designers overstepping its bounds of usefulness as it's wont to do. But then that would be an ecumenical matter, which I suspect is much harder to solve.;)

Last thought: one interesting consequence of me catching a bit of the old Lisp bug is that I now tend to view static type systems not as C housekeeping or Java bureaucracy, but as an *embedded declarative DSL for doing set algebra*.

Which then makes me wonder if it wasn't past time language designers made an effort to extract that stuff out into a reusable, customizable, programmable language in its own right. Such a move would open up exploration of this particular problem space to anyone who wishes to do so, instead of being the sole domain of the parent language designer. I think type systems and theory are more than mature enough to be broken out as their own thing now, rather than remaining baked and caked in the rest of that whole ball-o-mud that is the modern mainstream programming language implementation.

For instance, if I want to type two variables as Int<min:0,max:10> and Int<min:-5,max:5> and then declare a third variable that supplies data to both, I expect my type system to be smart enough to infer this new variable's type to be Int<min:0,max:5>, or else I think I want my money back. And if it can't do this calculation out of the box - which is not unreasonable - then it damn well should allow me to inject this capability into it (just as I can already inject novel new behaviors into any other language through functions, libraries, FFIs, and other extension mechanisms), else it's not *nearly* as helpful or clever as it thinks it is.

[…] as a better Objective-C. I’m not enamored with generics, and protocols seem like a good idea that in practice are currently too much of a pain to use. Likewise, the standard library is still in […]

[…] Swift Protocols, Arrays, and Casting, Swift Protocols Question, Swift Protocols and […]