SWIFT is 30 years behind dBase IV in application development. We need application generator, not coding.
Never did much real development, did you?
Perhaps he hasn't, but I have, and while his comment is more rhetoric than fact, the point remains valid.
That bit the article mentions about the ABI stands out. Having not used Swift, I won't comment on the specifics, but I will comment on the general case. Maintaining compatibility of interface between applications and modules built with different versions of a compiler is almost an absolute must. Effectively cutting a new application off from old modules is a really dumb idea. Lack of compatibility means that any modules I want to reference must also be recompiled, even if they're working fine. This rebuild brings with it risk, since the new compiler might have changes that change the way the code works, or removes a feature used by the old code (these aren't issues most of the time, but I've seen them both, especially with some C compilers), which means the old module has to be reworked to work around the compiler issue.
Not to mention the fact that the older build might still be required by still other modules, which means maintaining multiple versions, with potentially multiple versions of the source as well. Been there, done that, got the t-shirt. No thanks.
Now, that doesn't mean the interface shouldn't evolve and improve, by any means. Maintaining compatibility isn't that tough for a well designed compiler, and can be implemented in a number of ways. As interfaces evolve, perhaps include the backwards compatibility for old builds in every newly built application. Obviously this means including code might not ever be used. Or perhaps a compiler switch that says "include compatibility for version X.X modules." Better still if that detection were built into the compiler, so that when an older module is referenced, the needed compatibility is automatically included.
Lack of compatibility for modules built with older versions of the compiler (unless it's something like a security issue) just creates more, in most cases unnecessary, work for developers, including Apple's own developers.
No doubt about it, I absolutely agree that a stable ABI is fundamental and that Swift is still too immature for (my) professional use. My comment were about the "application generator", a concept that is usable for a very small subset of the SW running in CPUs today. I have tried different generations, including the really expensive model--based engineering tools and the latest AI/ML magic. Code is still king.
“Coding is still king” that I disappointedly agree. Regarding a “stable ABI” I prefer to see iOS Virtual Machines. Previous Qs: I don’t see Swift be able to run on Android phones in near future. Xcode should have AI-enhanced coding assistant to ease backward- and forward-compatibility while keeping the devices secure. If Swift 5 gets obese from a fat Swift 4, and the products run even slower, it’ll be ugly.
Yeah but only like everyone can’t write. With a little education its just not that hard. The problem is ‘coders’ have taken it upon themselves to design too and that’s the hard part but only due to their lack of subject matter expertise. Implementing a well considered design is less demanding than most think, good designs are simple and require minimal technical implementation. Of course, the same rule applies; not all subject matter expert’s can design.
Very few coders also design, certainly not in most companies where its a different role in the company, but when they do in fact they can be good. Many winners of Apple design awards are one or two person shops. In real life many programmers never even touch front end or mobile design, however. They write backend or embedded code, or libraries.
Design isn’t the hard part. The design of WhatsApp, Instagram, google search, and Twitter are simple, the code which ensures they can handle millions to billions of transactions without falling over is the hard part.
There it is! One word, multiple meanings. In fact design touches many aspects of development, graphic/UI design is just one. Design encompasses structuring a solution which could mean technical design (which is incorporated into implementation), functional design, conceptual design and even the ERM/Data design is heavily affected by the subject matter. Of course the industry has hijacked these different facets of design along with associated decision-making and terminology; an architect in the construction industry lives & breathes the subject matter of habitat - I’ve never met an IT Architect of any flavour who had any kind of grasp on the subject or purpose of the product beyond anecdotal.
Given that you said "coders have taken on themselves to design" as well, my assumption that you meant UI is understandable. In general technical design is called architecture and is in fact built by people who either will code it ( in smaller companies), or will code some of it or none of it in larger ones. There isnt a seperate degree or training for these disciplines, you graduate from one to the other.
I dont know what you mean with regards to an IT Architect not having any grasp on his purview - do you think the archtects of the Google backend just know their product "anecdotally"?. Whatever that means.
And that perspective is understandable given the status quo. However ‘design’ is a far broader topic than the presentation layer and is, and always has been, the real challenge for software development. It dictates how the technology is applied to a given purpose at all levels. It can only be reconciled by subject matter expertise or the product may be functional but not useful. IT Architects know their product literally in terms of its technical contraction but yes, in terms of its purpose and impact only anecdotally. Their assumption that everyone else is as ignorant as they are is a source of extreme frustration for SMEs, product owners and business customers alike. Product alignment with it’s purpose is usually in spite of, not because of, its technically-driven architecture.
Honestly that’s meaningless gibberish. You are using the term anecdotally incorrectly for one. It means knowing something by hearing about it from someone else, it doesn’t mean superficially.
And in the last paragraph it looks like you are back to UI/UX design again - because customers are not happy with that design. Hard to tell really. However in large companies developers have little or no input to UI/UX design - that’s a seperate competency.
My use of anecdotally is correct, their understanding of business impact can only be 2nd-hand/assumptive. Again, Design isn’t exclusive to UX though that’s an obvious area due to its visibility. It’s a broader term that’s mis-applied in IT. It covers most of the pre-implementation process, in layman’s terms; the thinking before the doing. Applying SME to the ERM for example, provides a far more efficient & relevant model.
Comments
Previous Qs: I don’t see Swift be able to run on Android phones in near future. Xcode should have AI-enhanced coding assistant to ease backward- and forward-compatibility while keeping the devices secure. If Swift 5 gets obese from a fat Swift 4, and the products run even slower, it’ll be ugly.
Again, Design isn’t exclusive to UX though that’s an obvious area due to its visibility. It’s a broader term that’s mis-applied in IT. It covers most of the pre-implementation process, in layman’s terms; the thinking before the doing. Applying SME to the ERM for example, provides a far more efficient & relevant model.