> The point of Obj-C was kind of to avoid writing the kinds of apps where a great type system would really shine, swift lets you build those kind of apps, but in my opinion most of the time we shouldn't be building them.
Can you clarify this? What is the kind of apps where a "type system would really shine"? How can you avoid writing them?
Type systems really shine in apps that you maintain. You avoid writing them by writing shovelware that intends to extract the maximum amount of money in a short term and be replaced by something else in the long term.
I don't think that's really what Obj-C was designed for.
eg. For some reason your app has the ability to use Postgres instead of SQLite, even though you always use SQLite.
eg. For some reason your app supports Postgres/MYSQL/SQL Server because every enterprise you sell to wants to run their preferred database instead of the one that works best with your product.
I'm not trying to be contrarian, but I fail to see what great type systems (or lack of them) have to do with YAGNI or writing poorly architected enterprise apps.
Are you saying the main application of type systems is writing overengineered enterprise apps? Do you think type systems have no place in well-architected and/or minimalist apps?
im saying those with a propensity to build such systems invariably choose strongly typed languages and in those languages that is the culture and the language encourages it.
Eg.rewriting base classes to use IWritableStream instead of looking up the write method and calling it.
I'm confusing types and 'Java-like interfaces and design patterns' to the same degree that you're confusing swift's type system with 'what great type systems can do for you.'
The type system of swift is much closer to java than to that of haskell. (Or whatever language you think has a 'great' type system)
For example in F# if you just use one method the type system will infer that you need an object that has that method. (especially if that method is an operator)
eg.
let add a b = a + b will work on any pair of objects that have the + operator defined. That is a good and useful type system, what swift has just makes you type more for little benefit.
eg. making types is easy, reflecting methods is hard. (it should be noted that swift effectively doesn't support reflection)
You mistake me: I wasn't talking about Swift, a language I'm barely familiar with. I was puzzled by your more general assertion about "the kind of apps where a great type system would really shine". So far you haven't explained what you meant by this; you seemed to be complaining about enterprise software, but a lot of enterprise software isn't built with programming languages featuring great or even particularly modern type systems.
I'm not sure what reflection has to do with this. I'm sure you're aware there are "great type systems" which do not use reflection.
No, it's that there's a limited amount of space to communicate my ideas and I chose brevity over clarity. I also use the common definition of terms over academic preciseness because I'm trying broad thoughts on a forum rather than a formal dissertation on type systems.
Can you clarify this? What is the kind of apps where a "type system would really shine"? How can you avoid writing them?