5 ms·

You kinda did this to yourself by using Swift when it was not stable yet. Meanwhile old Objective-C code continues to work just fine on iOS 15.

by xuki 5y ago

mst 5y ago
I agree wrt Obj-C but as a non-Mac developer it would not have been obvious to me a priori that something that was declared version 2 already wasn't stable. (I would absolutely assume that if it was officially still unstable that would have been documented somewhere ... I would absolutely not assume that I would have noticed)
- nevster 5y ago
  Agree - 99.9% of Java 1 apps will still compile and run just fine on Java 17
  - nitrogen 5y ago
    Unless you used XML.
    - mlyle 5y ago
      Are you talking about jaxp? Don't old jaxp jars still work?
      - cesarb 5y ago
        The parent comment is probably talking about the J2EE packages which used to come with the JRE before Java 11; a lot of code which used to run on Java 8 and earlier no longer runs on Java 11 and later unless you manually add a couple of extra JARs to the classpath (and good luck knowing which ones are needed when reflection is involved). However, the grandparent comment is talking about Java 1, which is before J2EE; the thing which would break code from that time is probably not going to be XML, but instead things like Applet support. There's a good chance that a Java 1 app is in fact an applet designed to run within a browser, and no longer runs fine on Java 17 since the Java plugin is no longer supported.
- chipotle_coyote 5y ago
  I know very little about Mac/iOS application development, but my impression from developer friends and acquaintances is that Swift uses an unusual variant of semantic versioning, in which all real numbers are assumed to be unstable releases. (it's a joke, I love you, Swift developers)
- christoph 5y ago
  I’m sure I’m going to be running the HN gauntlet here, but AS3+Flex was a beautiful time to be coding for me. I was paid to basically knock corporate front-end software out (what would now be certainly termed SPAs, oh, how we reinvented the wheel…) day in and day out when Flash wasn’t a very naughty, bad swear word. We knew how it would run in every browser, it was responsive and it seamlessly integrated with all our backend web services. Easily. I honestly feel that it’s only in the last year or two HTML/JS is now at parity with where we were with this stuff nearly 10 years ago. Yes, it is clearly much better now for all sorts of reasons, I won’t sugar coat it… Flash also sucked badly. Very badly. but… AS3 with Flex “bindings/proper ties” was a beautiful set up. It just worked. Always. Everywhere. The only other language I’ve felt a serious affinity with was Objective-C. It’s the only language where I knew when I hit compile/run any errors were on me. Maybe it’s just having spent years in those ecosystems/languages and developing what some might call “mastery”, I never got surprised. I never felt like a master. People above me always knew so much more. I do remember writing a couple of thousand lines of Obj-c over two heavily caffeine fuelled days, hitting run for the first time and it just worked. Years on I still find “gotchas” in JS and CSS that I just never found in those languages. Maybe I thought about code more back then? Constant integration and hot reloads all the time, just make it all feel a bit different. Maybe I’m just set in my ways from spending a day typing out Spectrum machine code from the back of a magazine? Anyway… my favourite language of all time is Objective-c, that’s all I actually wanted to say. Rant over.
  - simion314 5y ago
    I done AS3 and Flex4 Adobe AIR apps, AS3 was similar to TypeScript . And Flex4 had very good layout components and widgets , IMO web is still behind Flex4 for SPAs advanced applications.
- dehrmann 5y ago
  > it would not have been obvious to me a priori that something that was declared version 2 already wasn't stable Swift came out in Sept. 2014 and v2 in 2015. Just knowing that the language was 1.5 years old would bring long-term compatibility doubts to mind.
  - laumars 5y ago
    That’s not really fair. For example Go programs written in v1.0 are still mostly compilable (the few tweaks you do need to make aren’t substantial). Rightly or wrongly Apple very much decided Swift should take a different approach to backward compatibility.
    - dehrmann 5y ago
      You're always rolling the dice with new languages; Go just happened to be mostly compatible. If you want something that will compile in 20 years, pick something with a track record.
      - mst 5y ago
        My perl5 version 8 code still runs perfectly on version 34, and for all people's (often valid) dislike of perl still helps a lot of companies make a lot of money. That wasn't the point I was trying to make in that particular comment though.
      - laumars 5y ago
        Most languages offer some guarantee by the time they hit version 1, let alone 2. Take Python for example, v2 took a decade to deprecate. Swift is the edge case on this one. Not the norm.
nevster 5y ago
Is Swift 4 not yet stable? The point is, I couldn't even migrate from Swift 4 to the latest with my current M1 MacBook. (You need old XCode to migrate from 4.0 to 4.2) What's surprising is the very quick dropping of the migration tools from Xcode.
- bee_rider 5y ago
  Out of curiosity (I mostly use old languages so I'm definitely missing something), why does migrating require support from Xcode? It's just text, right? I mean fundamentally you could just copy the files over and then fix them to be compatible with the changes in the language, right? (Does Xcode have some automagic tool to convert between different version of the language?)
  - nevster 5y ago
    Technically, yes. In the easiest cases it's just changes in library function names so effectively the migration tool is just handling all that search and replace for you. Of course there's more complex stuff than that. There's also all the ancillary build files and project setting files that get updated. All pretty tedious to investigate and do by hand, especially for someone like me who just wants to get their old app running again on the latest iOS.
    - bee_rider 5y ago
      Pretty annoying that they'd pull the rug like that. Actually, kinda worse than the bad-old way of doing things. I'm sure if they hadn't set the expectation that such a tool would exist, you'd have set your code up to be more easily search/replaced (or sprinkle macros around, etc).
  - nicoburns 5y ago
    > Out of curiosity (I mostly use old languages so I'm definitely missing something), why does migrating require support from Xcode? That's just Apple being Apple unfortunately.
jrochkind1 5y ago
Wait, did people know at the time that Swift 2 was "not stable"? What version of Swift became "stable"?
- shilgapira 5y ago
  I guess for some definition of stable[1] you could say that we knew Swift 2 was not that, and by the time Swift 5 was released we knew it'd reached that milestone. [1] https://www.swift.org/blog/abi-stability-and-more/ https://www.swift.org/blog/abi-stability-and-more/
callmeal 5y ago
>You kinda did this to yourself by using Swift when it was not stable yet. Meanwhile old Objective-C code continues to work just fine on iOS 15. In pretty much any other programming language, upgrading to a new build enviroment / ide / compiler does not require a staged upgrade. I can take my android studio project from version 2.x and open them in the latest ide without having to step through intermediate versions. Of course I expect a sea of red, but the ability to migrate directly is present, and it's not in xcode. edit: And to make things worse, you cannot just download an older version of xcode because it might not run on our newest os/mac. SMH. Planned obsolescence FTW!

You kinda did this to yourself by using Swift when it was not stable yet. Meanwhile old Objective-C code continues to work just fine on iOS 15.

by xuki 5y ago

You kinda did this to yourself by using Swift when it was not stable yet. Meanwhile old Objective-C code continues to work just fine on iOS 15.

mst 5y ago

I agree wrt Obj-C but as a non-Mac developer it would not have been obvious to me a priori that something that was declared version 2 already wasn't stable. (I would absolutely assume that if it was officially still unstable that would have been documented somewhere ... I would absolutely not assume that I would have noticed)

nevster 5y ago
Agree - 99.9% of Java 1 apps will still compile and run just fine on Java 17
- nitrogen 5y ago
  Unless you used XML.
  - mlyle 5y ago
    Are you talking about jaxp? Don't old jaxp jars still work?
    - cesarb 5y ago
      The parent comment is probably talking about the J2EE packages which used to come with the JRE before Java 11; a lot of code which used to run on Java 8 and earlier no longer runs on Java 11 and later unless you manually add a couple of extra JARs to the classpath (and good luck knowing which ones are needed when reflection is involved). However, the grandparent comment is talking about Java 1, which is before J2EE; the thing which would break code from that time is probably not going to be XML, but instead things like Applet support. There's a good chance that a Java 1 app is in fact an applet designed to run within a browser, and no longer runs fine on Java 17 since the Java plugin is no longer supported.
chipotle_coyote 5y ago
I know very little about Mac/iOS application development, but my impression from developer friends and acquaintances is that Swift uses an unusual variant of semantic versioning, in which all real numbers are assumed to be unstable releases. (it's a joke, I love you, Swift developers)
christoph 5y ago
I’m sure I’m going to be running the HN gauntlet here, but AS3+Flex was a beautiful time to be coding for me. I was paid to basically knock corporate front-end software out (what would now be certainly termed SPAs, oh, how we reinvented the wheel…) day in and day out when Flash wasn’t a very naughty, bad swear word. We knew how it would run in every browser, it was responsive and it seamlessly integrated with all our backend web services. Easily. I honestly feel that it’s only in the last year or two HTML/JS is now at parity with where we were with this stuff nearly 10 years ago. Yes, it is clearly much better now for all sorts of reasons, I won’t sugar coat it… Flash also sucked badly. Very badly. but… AS3 with Flex “bindings/proper ties” was a beautiful set up. It just worked. Always. Everywhere. The only other language I’ve felt a serious affinity with was Objective-C. It’s the only language where I knew when I hit compile/run any errors were on me. Maybe it’s just having spent years in those ecosystems/languages and developing what some might call “mastery”, I never got surprised. I never felt like a master. People above me always knew so much more. I do remember writing a couple of thousand lines of Obj-c over two heavily caffeine fuelled days, hitting run for the first time and it just worked. Years on I still find “gotchas” in JS and CSS that I just never found in those languages. Maybe I thought about code more back then? Constant integration and hot reloads all the time, just make it all feel a bit different. Maybe I’m just set in my ways from spending a day typing out Spectrum machine code from the back of a magazine? Anyway… my favourite language of all time is Objective-c, that’s all I actually wanted to say. Rant over.
- simion314 5y ago
  I done AS3 and Flex4 Adobe AIR apps, AS3 was similar to TypeScript . And Flex4 had very good layout components and widgets , IMO web is still behind Flex4 for SPAs advanced applications.
dehrmann 5y ago
> it would not have been obvious to me a priori that something that was declared version 2 already wasn't stable Swift came out in Sept. 2014 and v2 in 2015. Just knowing that the language was 1.5 years old would bring long-term compatibility doubts to mind.
- laumars 5y ago
  That’s not really fair. For example Go programs written in v1.0 are still mostly compilable (the few tweaks you do need to make aren’t substantial). Rightly or wrongly Apple very much decided Swift should take a different approach to backward compatibility.
  - dehrmann 5y ago
    You're always rolling the dice with new languages; Go just happened to be mostly compatible. If you want something that will compile in 20 years, pick something with a track record.
    - mst 5y ago
      My perl5 version 8 code still runs perfectly on version 34, and for all people's (often valid) dislike of perl still helps a lot of companies make a lot of money. That wasn't the point I was trying to make in that particular comment though.
    - laumars 5y ago
      Most languages offer some guarantee by the time they hit version 1, let alone 2. Take Python for example, v2 took a decade to deprecate. Swift is the edge case on this one. Not the norm.

nevster 5y ago

Is Swift 4 not yet stable? The point is, I couldn't even migrate from Swift 4 to the latest with my current M1 MacBook. (You need old XCode to migrate from 4.0 to 4.2) What's surprising is the very quick dropping of the migration tools from Xcode.

bee_rider 5y ago
Out of curiosity (I mostly use old languages so I'm definitely missing something), why does migrating require support from Xcode? It's just text, right? I mean fundamentally you could just copy the files over and then fix them to be compatible with the changes in the language, right? (Does Xcode have some automagic tool to convert between different version of the language?)
- nevster 5y ago
  Technically, yes. In the easiest cases it's just changes in library function names so effectively the migration tool is just handling all that search and replace for you. Of course there's more complex stuff than that. There's also all the ancillary build files and project setting files that get updated. All pretty tedious to investigate and do by hand, especially for someone like me who just wants to get their old app running again on the latest iOS.
  - bee_rider 5y ago
    Pretty annoying that they'd pull the rug like that. Actually, kinda worse than the bad-old way of doing things. I'm sure if they hadn't set the expectation that such a tool would exist, you'd have set your code up to be more easily search/replaced (or sprinkle macros around, etc).
- nicoburns 5y ago
  > Out of curiosity (I mostly use old languages so I'm definitely missing something), why does migrating require support from Xcode? That's just Apple being Apple unfortunately.

jrochkind1 5y ago

Wait, did people know at the time that Swift 2 was "not stable"? What version of Swift became "stable"?

shilgapira 5y ago
I guess for some definition of stable[1] you could say that we knew Swift 2 was not that, and by the time Swift 5 was released we knew it'd reached that milestone. [1] https://www.swift.org/blog/abi-stability-and-more/ https://www.swift.org/blog/abi-stability-and-more/

callmeal 5y ago

>You kinda did this to yourself by using Swift when it was not stable yet. Meanwhile old Objective-C code continues to work just fine on iOS 15. In pretty much any other programming language, upgrading to a new build enviroment / ide / compiler does not require a staged upgrade. I can take my android studio project from version 2.x and open them in the latest ide without having to step through intermediate versions. Of course I expect a sea of red, but the ability to migrate directly is present, and it's not in xcode. edit: And to make things worse, you cannot just download an older version of xcode because it might not run on our newest os/mac. SMH. Planned obsolescence FTW!