I feel like Swift reduces the runtime availability of dynamic dispatch by default... so for things like live programming or runtime hacking Swift is worse than Obj-C.
I envision a future similar to the "Smalltalk dream" where one can build apps live, with minimal recompilation and where dynamic dispatch should be the default. I think this scenario is less ideal for "systems programming" but for areas when one is snapping together UI components and data sources I think it's ideal. Perhaps someone here can come up with good counter examples why this isn't the case?
Finally, I think static dispatch, as is favored by Swift, tends to paint one into a corner down the road... but it's possible Swift has enough leeway so that this isn't the case?
Snapping together UI components and data sources has existed for a long time, but it always seems to fail to be popular outside of niche uses. That's often due to the overhead of runtimes and the unsuitability of generic UI components when you get into the nitty gritty of the application being designed. Of course, that doesn't mean it can't be done, just an observation that the attempts I've seen over the past 20 years or so haven't been very good, ultimately.
I've often been curious why programming by manipulating metaphors on screen is seen as an ultimate goal in the evolution of programming languages. It seems a bit like creating a book by sticking pre-generated paragraphs together.
On your final point - static dispatch doesn't prevent you from making your own dynamic dispatch mechanism in the language.
> It seems a bit like creating a book by sticking pre-generated paragraphs together.
But books are not tools or machines, whereas software applications are (not counting art & entertainment, generally.)
Nobody creates every screw and electrical component from scratch when designing and assembling other tools and machines.
"Programming by manipulating metaphors on screen" would be more akin to using predefined mathematical symbols and formulas, and just putting in the numbers and variables related to the problem you want to solve or the task you want to perform.
Even most popular genres of games could be made entirely from wiring up predesigned components together in a visual environment, without writing any code at all. You would just supply your own graphics and sound and other content.
I think your vision of these tools is far more sophisticated and capable than the current reality. It's certainly been an industry dream to produce tools that work at the high level you've described, but they have very limited domains and thus far, less than impressive results.
> It seems a bit like creating a book by sticking pre-generated paragraphs together.
A poor metaphor. Maybe more like "creating a book by joining high-level expressive words together instead of having to define every concept from scratch for every book"
The funny thing is, this type of programming for just about any type of program can be done right now if you are willing to let go of total live programming at the granular expression level and use it for the more course structure of a program. A lot of ideas have seem to fail due to people trying to force them into being a silver bullet that should be applied %100 consistently down to the base constructs.
I envision a future similar to the "Smalltalk dream" where one can build apps live, with minimal recompilation and where dynamic dispatch should be the default. I think this scenario is less ideal for "systems programming" but for areas when one is snapping together UI components and data sources I think it's ideal. Perhaps someone here can come up with good counter examples why this isn't the case?
Finally, I think static dispatch, as is favored by Swift, tends to paint one into a corner down the road... but it's possible Swift has enough leeway so that this isn't the case?