Who is using Swift?

[Christian Schüler]

http://wiki.c2.com/?RefactorMercilessly
http://www.extremeprogramming.org/rules/refactor.html


Seriously, you have heard countless stories of companies that always dutifully serve their existing customer base ... and which do not exist anymore because they faded away together with their customers. Apple is not headed towards that fate for sure

EDIT:
Oh, and also
https://www.joelonsoftware.com/2002/01/ ... nd-motion/

since Microsoft was as guilty of it back in the days...

What's odd about Apple in general can be seen even in a 3 years old language:

https://swift.org/migration-guide/

Backward compatibility? No forget about it. You are supposed to be migrating code. I wonder how that would be happening if the code to be migrated wasn't a 5-10K lines long iPhone app.

LooooooooooooooooooooooooL
This is LoooooooooooooooooooooooL
Man, seriously NOPE
This apple thingy is ridiculous

[stratum]

http://wiki.c2.com/?RefactorMercilessly
http://www.extremeprogramming.org/rules/refactor.html

That's software engineering "religion" and I had enough of it, and decided to ignore it forever.
If anybody is "selling" practice that is not my own, I turn the TV off.
Refactor? that's not my practice. I scrap the poor design altogether and rewrite
If something is good enough to be refactored, then it's probably already good as it is, and it can be made better, but that has nothing to do with "this or that oriented, extreme, agile or whatever the current fashion is" programming trends. If not, it's a waste of time trying to fix it.

Microsoft was as guilty of it back in the days...

BTW, search for "MSDN Magazine" using ctrl + F in
https://www.joelonsoftware.com/2004/06/ ... e-api-war/

[Christian Schüler]

BTW, search for "MSDN Magazine" using ctrl + F in
https://www.joelonsoftware.com/2004/06/ ... e-api-war/

Yeah, that's the one!
Funny to read it since we have now the power of hindsight: Longhorn died, so did Avalon and WinFS. But we have WinRT now and the UWP and the Windows Store. And as the article says: The Raymond-Chen camp lost, the "MSDN Magazine camp" took over, and it shows.

Microsoft headed the Apple Way:
https://twitter.com/TimSweeneyEpic/stat ... 8383147008

[stratum]

Microsoft headed the Apple Way

An unfortunate fact.

[Guillaume Piolat]

Seriously, iOS development is profitable, and has a huge audience, that's what makes it attractive. Xcode still supports Objective C, C++, etc, so there's no lock in.

For Mac and iOS development, you get free, fully featured, professional developer tools. Comparable tools on other platform cost thousands.

Apple takes 30% - for that, developers get immediate worldwide distribution on a busy, highly visible market place, without having to do any of that themselves.

Another thing that I haven't seen others do is something like Swift Playgrounds, which is a fantastic, free learning tool for kids.
Tim Cook gave props to some kid developers during the keynote.

I could craft a detailed, witty bullet-point answer but doubt it would change anyone's mind.
I'll grant you that: Tim Cook did talk about some kid developers.

[BertKoor]

... they get 30% of your added value.

Release open source, as homebrew cask or something. Then 30% of nothing is: Nothing!

[Kraku]

I wonder if this article is right about Swift:
http://atastypixel.com/blog/four-common ... velopment/

"Don’t use Objective-C/Swift on the audio thread."

[arne]

I wonder if this article is right about Swift:
http://atastypixel.com/blog/four-common ... velopment/

"Don’t use Objective-C/Swift on the audio thread."

Yes, this is true. See "What's new in Audio" https://developer.apple.com/videos/play/wwdc2017/501/.
It's mentioned there again.

[BertKoor]

Backward compatibility? No forget about it. You are supposed to be migrating code.

That's not what I read:

[...] the Migrator [...] can understand both Swift 3.2 and Swift 4 code equally and compile them together, just like the Swift 4 compiler can. That means you decide when and if you’d like to migrate on a per-target basis when it makes sense for your project. While migrating to Swift 4 is definitely encouraged, it’s not an all-or-nothing process, as Swift 3.2 and Swift 4 targets can coexist and link together.

I wonder how that would be happening if the code to be migrated wasn't a 5-10K lines long iPhone app.

You're talking about monoliths then, and a lesson we all should have learnt by now is that building small components with a dedicated clear task is nearly always benefitial. Small components with as less dependencies as nescessary are easier to keep up to date than big monolithic applications.

[stratum]

About "compatibility": Yes I have seen that later, and the "ramblings of the thread" had changed from the "lack of backward compatibility" to its nonexistence in apple's dictionary, and then to microsoft's similar bloatware that keeps increasing in every release. Just ramblings you might say.

You're talking about monoliths then, and a lesson we all should have learnt by now is that building small components with a dedicated clear task is nearly always benefitial. Small components with as less dependencies as nescessary are easier to keep up to date than big monolithic applications.

I don't think we are alone with 500K lines and several GBs of open source dependencies for the sake of being cross platform but you can do that if you are not making end user software, but I won't claim that it makes sense in general or that I'm happy with it. Thinking about how to break it into smaller components, yes, I guess it can work to a degree, but in the end it's still the fact that all those components would be maintained and the total would still sum up to 500K+ a few GBs of external dependencies. You can see similar problems in every software that has a significant amount of functionality. Just have a look at QT or OpenCV.

[JCJR]

Maybe there are people who would prefer having dozens or hundreds of small maintainable apps rather than an obese daw that can do everything?

I will run the small track list app. Then run the small recording app and import or pipe the results into the small track list app. Then maybe I will open one of those tracks in the small maintainable piano roll app or audio edit app.

Maybe it could be OK but I think I'd prefer to use an obese daw.

Dunno if it would help maintainability-- If I sell an obese daw with source code longer than the bible, then I split it into 100 small apps-- When OS changes demand code fixes then it might be more labor intensive to update the 100 small apps than to update the single obese app.

Though both tasks can seem like pharoah demanding that new environmentally-friendly bricks be made without straw. The next week pharoah changes specs on the clay. Then the month after that pharoah changes specs on the water. And the new bricks are incompatible with the old bricks so all the old bricks have to be torn out and replaced. Arrrgh wailing and gnashing of teeth!

[resynthesis]

Maybe there are people who would prefer having dozens or hundreds of small maintainable apps rather than an obese daw that can do everything?

Aren't these called VSTs?

[stratum]

Maybe there are people who would prefer having dozens or hundreds of small maintainable apps rather than an obese daw that can do everything?

Good idea if you can actually make some money with them

[JCJR]

Well maybe it could be smart to "plug-ize" piano roll, audio edit, yadda yadda, but if it all plugs into a convenient master control shell I would guess the central shell might remain rather obese, but dunno. The VSTs get called then mixed and played and rendered yadda yadda. Do we keep that functionality in the mainshell, or do we make additional plugin specs for playback, vst calling, automation and mixing modules, etc?

The main point was that 100 small programs might not be any easier to maintain than one obese program. Numerous small apps could easily be more labor intensive for long-term maintenance.

Long ago I had a fairly big set of DX plugins and had to change them all at least once to accomodate OS changes. I don't recall it any easier to update a dozen small codes rather than one bigger program. But maybe there is some kind of advantage to numerous small jobs rather than one big job. Dunno.

It is a seemingly unavoidable task if one wants to keep a program running over the years. To me a not fun part of the job. In my locality, generally a 1939 house only has to conform to 1939 building codes. The house doesn't fall down or vanish into the air every time they update the building codes. People would riot in the streets and throw the bums out of town hall if the gov made them rebuild their houses to conform to every new building code change.

I guess its as inevitable as death and taxes but spent at least a year of my life monkey work updating old code according to OS changes. Maybe several years total. If it could somehow have been avoided, I could have figured out more fun and productive use of the time.

[stratum]

The way one packages things does not matter much, I think. If there is a difference then the product is either different or was implemented in a different way. If a company is living by selling a number of VSTs whose total functionality does not add up to a DAW, then that's a solution to the problem. If not, those small VSTs might be even more difficult to maintain, as you say. The worst case would be a complex DAW which was built to be sold 5 or 10 "copies" only and customized in each case to user needs. That's a reality in some excessively small "markets". Some countries look relatively large on the map, but it's actually 2-3 cities plus a larger, somewhat rural area and in that place companies from overseas are still competitors and that's why it is necessary to "use artillery to kill a small fly".. if that would be an appropriate description.