Catalina: Apple turns macOS into a closed platform; many audio-devs warned from the upgrade

[SampleScience]

I'm curious: what type of Mac issues did you have to deal with?

When I worked in support, I'd estimate that 5% of the issues I saw were actual bugs, 10-20% 'how to' questions (not really issues, but legitimate usage questions), 10% user error issues, and all the rest real issues that could, in most cases, be resolved by systematic troubleshooting.

In my case, it's around 5% actual bugs, around 20% "how-to" and the rest is people who don't read the manual and the product description (including the minimum system requirements). One solution I have in mind is doing instructional videos. Maybe people will be more inclined to watch a video than reading a manual or a text file.

[SampleScience]

Are most of the Mac support requests also related to compatibility?

No, not really. My plugins are tested on both macOS and Windows on all the major DAWs before release.

Currently, the only compatibility issue I know is for the VST3 version on Windows of my plugins, for some reason they don't work in FL Studio 20. They work in the other DAWs though.

[stratology]

In my case, it's around 5% actual bugs, around 20% "how-to" and the rest is people who don't read the manual and the product description (including the minimum system requirements). One solution I have in mind is doing instructional videos. Maybe people will be more inclined to watch a video than reading a manual or a text file.

So you don't see any issues that are not bugs and not usage issues? Issues that need systematic problem solving?
A DAW crashing at launch would be an example of a non-bug, non user error issue.

[dmbaer]

I'm not sure anybody has gotten OO "right", but I haven't truly delved into Simula or Smalltalk properly yet. There are some features I can't live without (or, prefer not to since they simplify some techniques greatly, like polymorphism), but most of it is utter junk and needs to be shot into the sun.

As far as Smalltalk goes, to me it's sort of the FORTRAN of OO. I haven't heard mention of it in years.

As to who's gotten it right, IMO Java came closer to that than any other language I ever encountered, at least before it opened Pandora's box with aspect oriented programming. I think was James Gosling who said AOP was like giving razor blades to children to play with. But I always found the Java object model was quite elegant, especially with respect to the interface capability. I checked out C# at one point, and liked that pretty well (very Delphi like, which was not surprising given who designed it), but I never had to use it professionally, so my opinion might have changed once I actually tried to program with it.

[SampleScience]

In my case, it's around 5% actual bugs, around 20% "how-to" and the rest is people who don't read the manual and the product description (including the minimum system requirements). One solution I have in mind is doing instructional videos. Maybe people will be more inclined to watch a video than reading a manual or a text file.

So you don't see any issues that are not bugs and not usage issues? Issues that need systematic problem solving?
A DAW crashing at launch would be an example of a non-bug, non user error issue.

No, not from the support requests I receive. I think the only time it may have happened is once with Reason on mac. It was when Reason started supporting VST plugins, it's not a problem anymore.

Edit: There are issues that arise with macOS updates, but they are fixed over time. I indeed receive support requests for those, like now with Catalina. But it's just during macOS update periods. It's still annoying and adds to the workload.

[mystran]

I'm not sure anybody has gotten OO "right", but I haven't truly delved into Simula or Smalltalk properly yet. There are some features I can't live without (or, prefer not to since they simplify some techniques greatly, like polymorphism), but most of it is utter junk and needs to be shot into the sun.

As far as Smalltalk goes, to me it's sort of the FORTRAN of OO. I haven't heard mention of it in years.

As to who's gotten it right, IMO Java came closer to that than any other language I ever encountered, at least before it opened Pandora's box with aspect oriented programming.

Objective-C is probably the closest to Smalltalk, but really all these languages get the whole OOP completely wrong. They violate separation of concerns when they associate methods with objects, which leads to this mess of inter-tangled objects that need to know about every other object they might ever have to interact with.

The only major language that gets it right is CLOS, where methods are not part of any objects. Rather you just choose the best method depending on the types of the set of objects you want to act on (ie. the method parameters). Unfortunately, this makes efficient implementation a lot more complicated, because in the worst-case true multiple-dispatch might need to do a run-time search (ie. find a set of parent-classes that satisfies one of the available method prototypes). This is why almost no other language does it, because it's much easier to just promote one of the objects as the "method owner" and then do a simple lookup into a vtable.

[syntonica]

As to who's gotten it right, IMO Java came closer to that than any other language I ever encountered, at least before it opened Pandora's box with aspect oriented programming. I think was James Gosling who said AOP was like giving razor blades to children to play with. But I always found the Java object model was quite elegant, especially with respect to the interface capability. I checked out C# at one point, and liked that pretty well (very Delphi like, which was not surprising given who designed it), but I never had to use it professionally, so my opinion might have changed once I actually tried to program with it.

I can handle Java up to v1.6, but find the "everything is a class" thing has been taken to ad absurdem levels by that point. Every field doesn't need to be its own class, or need immutable default classes, or factories, etc. (also see ObjC + Cocoa.) I find the more functional C# approach to be far superior. Unfortunately, Mono is pretty much a pig. Well, the JVM is too, anymore. The big problem is that despite being "managed" code, they are not safe from attack. I will be watching the advances in macOS starting with Catalina with great interest to see how they handle the same issues.

Despite how they've embedded themselves into various niches, I think the current star languages will start finding themselves replaced with the new hotness, like Rust, Go, Nim or Swift. (And if anyone wants to kill JavaScript, please do so with my blessing.)

BEGIN
IF it wasn't so verbose THEN I'd totally go Delphi/ObjPascal.
END

[syntonica]

The only major language that gets it right is CLOS,

(if (= CLOS (cons Lotsa (cons Irritating (cons Superfluous Parentheses)))) ...)


I'd just like C with class-like structs and polymorphism. That way, I get namespaces and no using nasty void pointers. I can write my own bespoke string routines and fat pointers. Everything else in say, C++, is just way too much.

[Vokbuz]

AU is relatively clean at the underlying API level, but the amount of base classes and boilerplate code you need to support it is concerning.

"The amount of base classes and boilerplate code you need to support it" is caused by the underlying API. If it would be clean, it would not require so much boilerplate code.

[Vokbuz]

Objective-C is probably the closest to Smalltalk, but really all these languages get the whole OOP completely wrong.

It is funny because Smalltalk and Objective-C are actually closer to the original OOP concept: there are objects and they exchange messages.

"I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind" (c) Alan Kay

[Vokbuz]

I can handle Java up to v1.6

Try 1.8. Lambdas and functional-style programming are really handy.

[syntonica]

Try 1.8. Lambdas and functional-style programming are really handy.

Lambdas really add nothing for me. As far I can see, they are just confusing syntactic sugar. Until I find a use case for something, I generally shun it, so maybe someday, I'll get into lambdas.

[mystran]

The only major language that gets it right is CLOS,

(if (= CLOS (cons Lotsa (cons Irritating (cons Superfluous Parentheses)))) ...)

Everyone likes to pick on the parenthesis, but if you write Lisp for a week you barely even see them anymore (rather you rely on indentation and let your editor tell you when the parens are balanced.. just like most people do with C-like syntax as well)... plus there's the "list" (or "list*" if you want a dotted tail) function to save you from having to cons like that.

[mystran]

Try 1.8. Lambdas and functional-style programming are really handy.

Lambdas really add nothing for me. As far I can see, they are just confusing syntactic sugar. Until I find a use case for something, I generally shun it, so maybe someday, I'll get into lambdas.

One of the things where I've found lambdas really helpful in C++11 is GUI programming: you let widgets define "notification signals" (eg. onClick, onValueChange, etc) as std::function<void()> with default initialisation to a dummy "doNothing" function, and it becomes really simple to wire-up application logic with lambdas:

Code: Select all

        /* this is copy-pasted snippet from the source of my current primary code-editor */
        findPanel.findBox.onEnter = [this](){ this->doSearch(false); };
        findPanel.findBox.onEscape = [this]()
        {
            if(this->activeTab) this->activeTab->content.editor.focus();
        };
        findPanel.findBox.onTab = [this]()
        { findPanel.replaceBox.focusSelectAll(); };
        findPanel.findButton.onClick = findPanel.findBox.onEnter;

        findPanel.replaceBox.onEnter = [this](){ this->doSearch(true); };
        findPanel.replaceBox.onEscape = findPanel.findBox.onEscape;
        findPanel.replaceButton.onClick = findPanel.replaceBox.onEnter;
        findPanel.replaceBox.onTab = [this]()
        { findPanel.findBox.focusSelectAll(); };

The only thing to watch out for is object lifetimes, but capturing "this" pointers like above is perfectly safe when the code lives higher up the GUI hierarchy in an object that owns all the widgets anyway (eg. the application window in the above example).

[syntonica]

Everyone likes to pick on the parenthesis, but if you write Lisp for a week you barely even see them anymore (rather you rely on indentation and let your editor tell you when the parens are balanced.. just like most people do with C-like syntax as well)... plus there's the "list" (or "list*" if you want a dotted tail) function to save you from having to cons like that.

Oh, I know. I was just teasing. And I haven't Lisped in ages. I couldn't remember the list syntax...