Apple project lead Ted Kremenek discusses Swift 5 & how it is used internally

2

Comments

  • Reply 21 of 42
    IreneWIreneW Posts: 173member
    IreneW said:
    ivanh said:
    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.
    beowulfschmidt
  • Reply 22 of 42
    asdasdasdasd Posts: 5,323member
    IreneW said:
    ivanh said:
    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.
    Firstly - that’s not a defense of someone who said that DBase was 30 years ahead of swift. 

    Secondly ABI instability isn’t a feature of swift, it’s a bug in swift (or a task not yet handled). The article was about how swift 5 is fixing that. And yes, it’s a pain. 
  • Reply 23 of 42
    asdasdasdasd Posts: 5,323member
    mcdave said:
    welshdog said:
    BTW: Everyone can't code.
    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. 




  • Reply 24 of 42
    ivanhivanh Posts: 381member
    IreneW said:
    ivanh said:
    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.
    IreneW, you don’t know dBase, do you? Sorry to tell you that, I have decades of “real” application development, coding, code auditing exp. From Assembler, FORTRAN, COBOL, RPG, C, C#, C++... Java, Python to Swift 4.x. Coding should be obsolete and let the AI do the coding job. Frankly, I have too much coding hands-on and am sick of doing it (AR & VR stuff) in 2019. I’m totally disappointed by Xcode. Programming languages are just reinventing the wheel for every hardware platforms.

    beowulfschmidt, your focus on compatibility valid, but that’s only a tiny part. “Let there be an app, and there’s an app”, no human coding, voice-to-app is a milestone of a mature AI codingbot. 2019, we are still at stone age in terms of application development.
  • Reply 25 of 42
    mcdavemcdave Posts: 1,178member
    mcdave said:
    welshdog said:
    BTW: Everyone can't code.
    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. 
    “Simple” is easier said than done.

    https://m.youtube.com/watch?v=R4C_JciDsuo
    It depends on your perspective, a real world business problem maybe complex to the developer because they lack the subject matter expertise to construct a familiar & accurate context from which they can formulate a solution.  The same is true for non-developers initially grasping comparatively simple development concepts or a child learning how to author a story.   Put simply, if you see something as complex, you’re the wrong person to be looking, step back and let someone with that capability pick up decision-making.  Ideally competent management would have spotted this or set up the team/engagement capability correctly in the first place.
  • Reply 26 of 42
    mcdavemcdave Posts: 1,178member
    asdasd said:
    mcdave said:
    welshdog said:
    BTW: Everyone can't code.
    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.
  • Reply 27 of 42
    rcfarcfa Posts: 780member
    I wish they’d finally offer an optional traditional syntax. I miss ObjC for its syntax.

    The other thing missing, is a proper runtime system. It’s nice to have eval in Playgrounds, but it should (optionally) available in any app.
  • Reply 28 of 42
    ivanh said:
    IreneW said:
    ivanh said:
    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.
    IreneW, you don’t know dBase, do you? Sorry to tell you that, I have decades of “real” application development, coding, code auditing exp. From Assembler, FORTRAN, COBOL, RPG, C, C#, C++... Java, Python to Swift 4.x. Coding should be obsolete and let the AI do the coding job. Frankly, I have too much coding hands-on and am sick of doing it (AR & VR stuff) in 2019. I’m totally disappointed by Xcode. Programming languages are just reinventing the wheel for every hardware platforms.
    .
    Sure, I do. I used dBase in the 80's, when it was still a thing. Not sure why you bring up Code (which I agree is not a great IDE). Contrary to you, I still enjoy creating stuff and use the best tools available for the task - which in most cases means explicit instructions in one language or another, i.e. coding.
    I don't understand your last comment about the relationship between programming languages and hardware platforms, can you explain?
  • Reply 29 of 42
    asdasdasdasd Posts: 5,323member
    mcdave said:
    asdasd said:
    mcdave said:
    welshdog said:
    BTW: Everyone can't code.
    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.
  • Reply 30 of 42
    IreneW said:
    My comment were about the "application generator", a concept that is usable for a very small subset of the SW running in CPUs today. 
    Fair enough.  And I agree with that point, BTW.
  • Reply 32 of 42
    wizard69wizard69 Posts: 12,865member
    welshdog said:
    BTW: Everyone can't code.
    This is so true!   I want to hurl evertime some idiot claims he can teach anybody to code.
    welshdog
  • Reply 33 of 42
    wizard69wizard69 Posts: 12,865member
    welshdog said:
    BTW: Everyone can't code.
    Not quite correct.  Everyone can code.  Not everyone can do it well.

    :)
    Not even remotely true.   
  • Reply 34 of 42
    wizard69wizard69 Posts: 12,865member
    mcdave said:
    So a more robust ABI will increase the amount of third-party components moving apps away from first-party frameworks thus ensuring no hardware acceleration and everything looks like Android.  This isn’t a win in my book.
    Huh?

    This makes no sense at all.  
  • Reply 35 of 42
    mcdavemcdave Posts: 1,178member
    asdasd said:
    mcdave said:
    asdasd said:
    mcdave said:
    welshdog said:
    BTW: Everyone can't code.
    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.
  • Reply 36 of 42
    mcdavemcdave Posts: 1,178member
    wizard69 said:
    mcdave said:
    So a more robust ABI will increase the amount of third-party components moving apps away from first-party frameworks thus ensuring no hardware acceleration and everything looks like Android.  This isn’t a win in my book.
    Huh?

    This makes no sense at all.  

    tzm41 said:
    mcdave said:
    So a more robust ABI will increase the amount of third-party components moving apps away from first-party frameworks thus ensuring no hardware acceleration and everything looks like Android.  This isn’t a win in my book.
    I don't think that's what ABI stability means.


    Upon reflection my comment isn’t relevant.  My concern was making Swift more tolerant of libraries built with prior versions would make it easier to drop 3rd-party libraries into iOS projects and dilute the already dwindling use of 1st-party frameworks in favour of cross-platform generics.  Though open sourced I’m unsure many developers are using common Swift libraries on other platforms so my point is moot.

  • Reply 37 of 42
    asdasdasdasd Posts: 5,323member
    mcdave said:
    asdasd said:
    mcdave said:
    asdasd said:
    mcdave said:
    welshdog said:
    BTW: Everyone can't code.
    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. 
  • Reply 38 of 42
    foljsfoljs Posts: 345member
    darkpaw said:
    In this next version of Swift, will I suddenly get 4,000 errors due to fundamental syntax being changed? And if so, will that change be documented or will I have to hunt on Stack Overflow for the correct replacement code?
    If you have actually used Swift, you would have found that this was not the case to 3 to 4 either, so...
  • Reply 39 of 42
    foljsfoljs Posts: 345member
    ivanh said:
    SWIFT is 30 years behind dBase IV in application development. We need application generator, not coding.
    Swift is not meant to make cookie cutter business apps.

    It's a general purpose application programming language.


  • Reply 40 of 42
    welshdogwelshdog Posts: 1,694member
    wizard69 said:
    welshdog said:
    BTW: Everyone can't code.
    This is so true!   I want to hurl evertime some idiot claims he can teach anybody to code.
    This was my point. I do appreciate the discussion that erupted around my comment however - good stuff.

    For me I learned fairly quickly that coding was not for me. I took a FORTRAN course as a freshman, around 1975. I barely managed to make a C grade. That was not a typical grade for me. It showed me that I was not ever going program well. The reason was that I am not fluent in math. I took a lot of math courses - algebra, calculus, statistics, and while I made the grades, I never intuitively understood how to use it. Since programming becomes math at many levels, there is no way I would ever be a programmer. Math is a language and you can't effectively make use of it if you are not fluent. Math is slow agony to me and so is programming. I know my limitations.
Sign In or Register to comment.