4 ms·

I have thought of doing projects with server side swift but only because I know Swift so well. It does seem like the worst thing to do is to try and learn Swift

I have thought of doing projects with server side swift but only because I know Swift so well. It does seem like the worst thing to do is to try and learn Swift in the non-golden case of being within MacOS. But ultimately this does seem to be standard issues you might see working with swift and lacking inference but the dev didn't know much about Swift to work his way out of it. I do agree that the way Package.swift works and how it relates to your imports is really confusing. Not to mention how the name in the Package.swift relates to the package names your importing (they don't, they relate to the repo or directory instead of the Package names in the repo's Package.swift). It seems like the dev just kind of randomly plugged away and they weren't really willing to learn anything and is holding everything at arm's length.

ShadowBanThis01 3y ago
I've been developing in Swift for years and have never looked in Package.swift. I also would not have known what to do about pretty much any of the problems he encountered.
- MBCook 3y ago
  For most people Xcode just handles it for you. I’ve never touched it by hand. It can be, it’s designed for that (as opposed to something like an Xcode project file), but it doesn’t come up for most of us. Obviously it’s different if you’re not developing on a Mac. But given the usual audience of Swift users, I bet it’s hard to find good tutorials for this kind of stuff.
  - chairhairair 3y ago
    I absolutely hate the reliance on XCode for Apple stuff. I don’t want to blindly search for some checkbox widget, please just give me a config file.
    - cmrdporcupine 3y ago
      This. And this was a problem with MS/Windows development for years, too, over-reliance on Visual Studio... In fact, XCode reminds me a lot of older versions of Visual Studio, complete with terrible giant configuration dialogs, generated code galore, and subpar refactoring and external tooling support. I really don't get Mac/iOS developer's weird stockholm syndrome with XCode -- when I worked doing iOS for a period of time, I used JetBrain's AppCode and it helped take the edge off things. Granted, I haven't ventured into XCode & iOS dev since Swift came on the scene. That does look to have improved things.
      - ShadowBanThis01 3y ago
        I've worked with Xcode since it was Project Builder. And I worked with Visual C++ from the days when it was two disparate versions, one 16-bit and one 32-bit. I used to love Visual Studio. Not MFC and its crap-heap of hokey macros, but the IDE. Project Builder was primitive as hell by comparison. Fast-forward 20 years, and Visual Studio is still plagued by the same ridiculous UI defects it suffered from in the '90s, and Xcode is vastly improved from Project Builder. I've heard (and evidence bears it out) that there's no one left at Apple who understands how Xcode works at this point. The giant piles of settings, many of which are specified in multiple places in multiple ways, and the corruptibility of the project files... once your project goes wrong there's often no coming back. Granted, this is far less frequent than it used to be, but still... this thing needs a ground-up rewrite behind the scenes. I work in Xcode daily, and I would be open to trying something else if I thought it would fully integrate all of the non-coding BS that encrusts development. Specifically things like code-signing, certificates, SDK locations, simulator integration... Do third-party IDEs offer seamless support for all that stuff?
        cmrdporcupine 3y ago
        > Do third-party IDEs offer seamless support for all that stuff? when I used it, AppCode did a lot of song-and-dance to delegate out to XCode to do a bunch of the stuff like that. and it was by no means seamless
geodel 3y ago
> It seems like the dev just kind of randomly plugged away and they weren't really willing to learn anything and is holding everything at arm's length. I do it all the time. It is useful test to see practical use of a language on actual project at hand. If a language is not productive quickly and need lot of background there maybe nothing wrong with language. But at same time nothing wrong with devs trying to see where it takes.

ShadowBanThis01 3y ago

I've been developing in Swift for years and have never looked in Package.swift. I also would not have known what to do about pretty much any of the problems he encountered.

MBCook 3y ago
For most people Xcode just handles it for you. I’ve never touched it by hand. It can be, it’s designed for that (as opposed to something like an Xcode project file), but it doesn’t come up for most of us. Obviously it’s different if you’re not developing on a Mac. But given the usual audience of Swift users, I bet it’s hard to find good tutorials for this kind of stuff.
- chairhairair 3y ago
  I absolutely hate the reliance on XCode for Apple stuff. I don’t want to blindly search for some checkbox widget, please just give me a config file.
  - cmrdporcupine 3y ago
    This. And this was a problem with MS/Windows development for years, too, over-reliance on Visual Studio... In fact, XCode reminds me a lot of older versions of Visual Studio, complete with terrible giant configuration dialogs, generated code galore, and subpar refactoring and external tooling support. I really don't get Mac/iOS developer's weird stockholm syndrome with XCode -- when I worked doing iOS for a period of time, I used JetBrain's AppCode and it helped take the edge off things. Granted, I haven't ventured into XCode & iOS dev since Swift came on the scene. That does look to have improved things.
    - ShadowBanThis01 3y ago
      I've worked with Xcode since it was Project Builder. And I worked with Visual C++ from the days when it was two disparate versions, one 16-bit and one 32-bit. I used to love Visual Studio. Not MFC and its crap-heap of hokey macros, but the IDE. Project Builder was primitive as hell by comparison. Fast-forward 20 years, and Visual Studio is still plagued by the same ridiculous UI defects it suffered from in the '90s, and Xcode is vastly improved from Project Builder. I've heard (and evidence bears it out) that there's no one left at Apple who understands how Xcode works at this point. The giant piles of settings, many of which are specified in multiple places in multiple ways, and the corruptibility of the project files... once your project goes wrong there's often no coming back. Granted, this is far less frequent than it used to be, but still... this thing needs a ground-up rewrite behind the scenes. I work in Xcode daily, and I would be open to trying something else if I thought it would fully integrate all of the non-coding BS that encrusts development. Specifically things like code-signing, certificates, SDK locations, simulator integration... Do third-party IDEs offer seamless support for all that stuff?
      - cmrdporcupine 3y ago
        > Do third-party IDEs offer seamless support for all that stuff? when I used it, AppCode did a lot of song-and-dance to delegate out to XCode to do a bunch of the stuff like that. and it was by no means seamless

geodel 3y ago

> It seems like the dev just kind of randomly plugged away and they weren't really willing to learn anything and is holding everything at arm's length. I do it all the time. It is useful test to see practical use of a language on actual project at hand. If a language is not productive quickly and need lot of background there maybe nothing wrong with language. But at same time nothing wrong with devs trying to see where it takes.