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

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

syntonica wrote: Fri Nov 08, 2019 5:50 am
mystran wrote: Fri Nov 08, 2019 4:09 am 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... :dog: :lol:
The funny thing about parens is that many traditional special forms (eg. let, cond..) use more parens than strictly necessary (and some modern dialects have tried to reduce them), but it turns out that keeping these seemingly superfluous parens allows a fairly stupid auto-indenter to always do the right thing. In fact, for the most part the indenter just needs a list of special-forms (or macros) that have a body (or in case of Common Lisp, you could just ask the runtime) and you're set to indent about 99% of most Lisp dialects correctly every time.

In comparison, with languages like C++ people can't even agree on what the correct indentation should look like. ;)

edit: I suppose for basic indent you could get away without the extra parens, but if you want more general code formatting or pretty-printing, then they are very helpful.

Post

mystran wrote: Fri Nov 08, 2019 7:34 am In comparison, with languages like C++ people can't even agree on what the correct indentation should look like. ;)
They should look like the exact way that I do them! :P

(I put the braces on their own lines, matching braces aligned vertically. I like lots of air in my code so I can read it. I hate the "modern" proscribed style that tries to pretend they're not there. That just looks ugly and inelegant to me.)

As an aside, my favorite coding style is Forth when you can make your colon definition look like a haiku.
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

syntonica wrote: Fri Nov 08, 2019 1:26 am 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. :lol:
I do not know what is you coding style and what kind of code you write to give the right use cases, but I'm pretty sure everyone can benefit from using lambdas. If you find them "just confusing syntactic sugar" you probably don't really familiar with them. Yes, labmdas in java are just instances of synthetic classes and you can always use anonymous or non-anonymous classes instead. But labmdas drastically reduce the amount of boilerplate code.

This code

Code: Select all

filterCollection(collection, item -> item.isVisible());
or even this

Code: Select all

filterCollection(collection, X::isVisible);
is much more readable than

Code: Select all

filterCollection(collection, new Predicate<X>() {
    @Override
    public boolean test(X item) {
        return item.isVisible();
    }
});
Not to mention callback or event handler example from C++ given above.

Post

mystran wrote: Fri Nov 08, 2019 5:02 am 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).
In java this is not a problem. It is even ok to have cyclic references.

Post

syntonica wrote: Fri Nov 08, 2019 8:04 am
mystran wrote: Fri Nov 08, 2019 7:34 am In comparison, with languages like C++ people can't even agree on what the correct indentation should look like. ;)
They should look like the exact way that I do them! :P

(I put the braces on their own lines, matching braces aligned vertically. I like lots of air in my code so I can read it. I hate the "modern" proscribed style that tries to pretend they're not there. That just looks ugly and inelegant to me.)
While I also prefer braces on their own line, I mostly don't care as long as you don't use hard tabs (don't even care how many spaces you want to indent with, just don't use tabs) or lines significantly longer than 80 characters (since this is really inconvenient when using an editor layout with two documents side-by-side, which is what I always do).

Post

mystran wrote: Fri Nov 08, 2019 4:41 pm While I also prefer braces on their own line, I mostly don't care as long as you don't use hard tabs (don't even care how many spaces you want to indent with, just don't use tabs) or lines significantly longer than 80 characters (since this is really inconvenient when using an editor layout with two documents side-by-side, which is what I always do).
One thing y'all should know about me is that I hate slavish programmers who feel the need to do absolutely everything they were told in programming class, otherwise they are bad programmers. I do the minimum that makes sense for the use case. E.g. I don't feel the immediate need to import XML/JSON libraries just to store a few values in a file. (Actually, I never feel the need to import either.)

Sometimes, I can run over 80 chars, but when I do, I have to think about 1) just how deep does this nesting really need to go? and 2) how ugly does that expression really need to be? I've come up with some great simplifications and optimizations because of that.

Oh, and I use tabs... :evil: It's a very old habit, but a good IDE should make the difference seamless.
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

syntonica wrote: Fri Nov 08, 2019 5:40 pm Oh, and I use tabs... :evil: It's a very old habit, but a good IDE should make the difference seamless.
The problem with tabs is that different tools (eg. diff tools, source code browsers, debuggers...) and people can never quite agree on how they should be treated. Even if you set your tabsize to the standard 8 characters, there's going to be someone with an editor that wants to treat it as 7 characters instead and mix it with spaces randomly in a way that eventually screws up the whole layout. Unless you periodically reformat your files, you eventually just end up with a mess where different parts of the same file require different interpretation to display correctly.

It's just way easier outright ban all tabs (in files). Most decent editors can convert spaces (either leading a line or everywhere, using whatever tabsize you like) into tabs for editing anyway, then expand back to spaces when saving into a file. This way you can use whatever settings you like and everyone (for the most part) can agree on how the result should be displayed.

Post

mystran wrote: Fri Nov 08, 2019 7:31 pm Most decent editors can convert spaces (either leading a line or everywhere, using whatever tabsize you like) into tabs for editing anyway, then expand back to spaces when saving into a file. This way you can use whatever settings you like and everyone (for the most part) can agree on how the result should be displayed.
That's what I was saying. I'm just happier navigating tabs at 4 spaces. It's far faster for cursor movements when I don't want to take my hands off the keyboard. An IDE should make that tab<->space translation on save/load seamlessly when requested.

8 is just weird for tab size. When I was pounding away on the keys of an Underwood upright, a tab was 5 spaces for indenting a paragraph.
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

I like tabsize of 2 with brackets on separate lines. Prefer spaces rather than tab char indents..

Tabsize of 2 seems big enough & I need the space for rather long "self documenting" names. Long names combined with logic a few conditionals deep leads to excessively long lines even using small 2 space indents.

Also prefer local vars declared at the top of a function rather than declared willy-nilly in the code wherever the var is first used.

Post

JCJR wrote: Sat Nov 09, 2019 1:29 am Also prefer local vars declared at the top of a function rather than declared willy-nilly in the code wherever the var is first used.
Can we please just agree that C89 is obsolete at this point.

edit: and actually even with C89 it's good practice to declare variable at the top of the block where they are used, rather than polluting the namespace of the whole function.

edit2: what you suggest is literally one of those things that will make it HARDER for a compiler to catch bugs :)

Post

Personal prefs do not mean it is better, just whatever is preferred. If code is laid out a certain way it is easier for me to read and work with. Folks with better perception don't need the crutch.

Worked with a talented productive fella whose format looked obfuscated. I had to autoformat before I could read it. My perceptual weakness not his. He could read any obfuscated mess, never noticing.

Post

mystran wrote: Sat Nov 09, 2019 2:29 am
JCJR wrote: Sat Nov 09, 2019 1:29 am Also prefer local vars declared at the top of a function rather than declared willy-nilly in the code wherever the var is first used.
Can we please just agree that C89 is obsolete at this point.

edit: and actually even with C89 it's good practice to declare variable at the top of the block where they are used, rather than polluting the namespace of the whole function.

edit2: what you suggest is literally one of those things that will make it HARDER for a compiler to catch bugs :)
If it's a variable that has meaning throughout the code, I prefer it at the top of scope with any needed usage notes. Nonce variables that are used once or twice can be declared when first used. Again, I do what makes sense (to me) rather than any proscribed style.
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

mystran wrote: Fri Nov 08, 2019 4:41 pm While I also prefer braces on their own line, I mostly don't care as long as you don't use hard tabs (don't even care how many spaces you want to indent with, just don't use tabs) or lines significantly longer than 80 characters (since this is really inconvenient when using an editor layout with two documents side-by-side, which is what I always do).
This is getting into some pretty subjective territory. Like you, I not only prefer braces on their own line, I would characterize myself as a devote begin-end-alignist. But I don't understand your dislike of tabs. I have yet to encounter a good editor (standalone or within an IDE) that does not allow the user to specify the spaces-to-tab factor. For me, three spaces of indentation is the sweet spot. Four is more common, but doesn't provide any more clarity, IMO. Any more than four is just wasted space. But that's why I like the ability for the user to format the code display as it best suites them.

Oh yeah ... about 80 characters max per line, I am in passionate agreement. In fact, I even prefer 72, since that always allows for two pieces of source code to be visible side by side on typical displays (and it has *nothing* to do with the fact that my programming career involved using punched cards for more years than I'd care to admit to :D ). But this is why keeping the indentation to three spaces works out for the best - there's more room on the line before you need to overflow to the next.
Last edited by dmbaer on Sat Nov 09, 2019 8:08 pm, edited 1 time in total.

Post

I prefer the white-space agnosticness of C languages. It's more enjoyable to just write something without worrying about indentation. As far as reading the stuff, a source-formatting program can handle that.

It's possible to write almost anything in C without any whitespaces. It's not helpful, it's rather pointless, but it is interesting nonetheless. It's syntax is well defined enough to allow the characters to define the program, not the indentation.

Post

camsr wrote: Sun Nov 10, 2019 6:41 pm It's possible to write almost anything in C without any whitespaces.
You need whitespace for the preprocessor and qualifiers and non-pointer definitions/declarations (can't think of a workaround for those; excessive parens might work)... but I think that's pretty much all of it in plain C. In C++ you also need some in nested templates, but not sure if there's anything else.

Post Reply

Return to “DSP and Plugin Development”