Hacker News Reader

Comment by amelius | Hacker News Reader

> There are fewer layers in it vs android.

Fewer layers usually also means less flexibility.

Actually you have it inverted. Fewer layers means fewer abstractions. Less abstraction means you're lower level, thereby having increased flexibility.

Edit: Anyone care to elaborate why the downvotes? From a technical standpoint, I'm absolutely right.

Then assembly is more flexible than your favorite high-level language? It's true that you can, by definition, do more with low-level access. And I suppose that's one definition of "flexibility". But I think most developers would use the word to mean that various pieces of functionality can be put together easily. So they might say, for example, that Unix pipes are "flexible". I think I'd usually agree with that meaning.

Yes, assembly is more flexible than my favorite higher level language.

Because if you have access to assembly, you can implement the whatever higher level language or semantics you want.

Whereas if you only have a higher level language, you have to work with/around the abstractions baked into it.

For realtime applications it's better to at least have access to a low-level, less overhead API.

That is true.

For example, in assembly we can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention.

We cannot do that in C. That's because there are areas of the program state that are "off limits", and the compiler generates "GC ignorant" code.

do you mind elaborating on this? What would be off limits, and what in assembly would allow a garbage collector free of false retention vs C?

What in assembly would allow freedom from false retention is that we know exactly what is in every register and memory location (because we put it there). We know where the GC has to look for root references and where it doesn't have to look.

In C, if we have a pointer p which is the last reference to some object, and is not used any more, and add the line "p = NULL", hoping to drop a reference so the object can be reclaimed, there is no guarantee that the compiler actually generates the code which does the assignment. Since the variable has no next use, and the compiler doesn't know anything about garbage collection, the assignment looks like wasteful, dead code that should be optimized away. Even if the scope finishes executing, the compiler can leave behind a memory location which still references the object.

Here is something else, not related to GC. In assembly language, we can make ourselves a calling convention for variadic functions which know how many arguments they have. As we build up the higher level language, it will have nicely featured variadic functions.

In C, we are stuck with <stdarg.h> which doesn't have a mechanism for the callee to know where the arguments end. The language has no flexibility to add this --- without resorting to approaches which will basically involve assembly language.

In C you can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention.

You can do it portably if you just don't store objects on the C stack, and you can do it non-portably if you do so.

> In C you can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention.

If so, you will be the first; I look forward to the "Show HN:" when it's done.

> You can do it portably if you just don't store objects on the C stack,

Sure, for example, you can do it portably in C if you write a complete emulator for an 80386, and then use that to run an assembly language program. That program isn't a utility for your C code; it's not extending the host C with a garbage collector or whatever else.

If you do not store object references on the stack, your use of C is severely crippled to the point that it's not really C any more. For one thing, C function arguments are on the stack (or, more abstractly, "automatic storage"), so say goodbye to conventional use of C argument passing: the backbone of most normal C programming.

That garbage collector isn't for C. C has automatic storage, and a proper garbage collector has to traverse it.

> and you can do it non-portably if you do so.

Sure, if non-portably means going as far as forking a specific C compiler with your custom hacks, and requiring that C compiler, or else living with the imprecision and taking a whack-a-mole approach to plugging the issues as they arise.

Chicken scheme uses C function calls, and merely requires a contiguous stack for automatic storage (which is technically non-portable, but doesn't require forking a compiler):

http://en.wikipedia.org/wiki/CHICKEN_%28Scheme_implementatio...

[edit] And here is a toy scheme interpreter that uses precise garbage collection to show off the Ravenbrook MPS

http://www.ravenbrook.com/project/mps/master/manual/html/gui...

You're ignoring the fact that speed is paramount (the whole point of the article). If you want flexibility and speed, you're going to look at using assembler (where you can do anything that can be done, running as fast as it can run) instead of a high-level language (where you have to work with packaged functionality and aggregates hiding complexity). No, it's not going to be easy.

The fact that Apple totally controls both sides of the symbiotic audio hardware & SDK running on a tiny set of products, while Android must have an SDK which accommodates an unknown range of hardware for hundreds of products, means iOS will have an inherent advantage.

    The fact that Apple totally controls both sides of the symbiotic audio hardware & SDK running on a tiny set of products

You can use CoreAudio with third party audio hardware

There are a TON of third party audio interfaces that CoreAudio supports.

One of the counter arguments would be that more layers of indirection lead to more flexibility.

Deleted comment

Heavily down voted for taking a one line comment about whether more or fewer layers of abstraction is more flexible, and using it to beat your "I hate apple" drum about terms and conditions and control and Muh Freedoms.

You're being that guy, so obsessed with a thing that you see it everywhere and think every conversation is about it.

Have you ever seen Rogue Amoeba's Audio Hijack for OS X?

It proves the system supports a ton of flexibility.

https://www.rogueamoeba.com/audiohijack/

I am not sure why this is downvoted. Abstraction layers are often added to give flexibility and ease of use, sometimes at the cost of performance. For example ALSA has features like muxing together audio from several apps, while a lower level API might only allow one app to use audio.

I think it's being downvoted because the point of abstraction layers is generally to make specific things easy at the cost of making most other things much harder. For example, Rails makes building web apps easier, but it would be much harder to make a command-line program in Rails. Ruby itself is fine for command-line programs, but there are a host of things that are impossible using it which are doable with raw C. That's why Ruby allows for C extensions: it breaks Ruby's abstractions, but restores some lost flexibility.

In that sense, flexibility and ease of use aren't synonyms; they're opposites. An open flame is flexible but not easy to use, so we have the toaster, which is easy to use but not flexible at all.

iOS can mix audio while preserving low latency. It works much better because CoreAudio is basically a full audio routing and mixing engine and forces more realtime-ish requirements on implementations. The system level engine just takes audio from apps as if they were submixers.

None of that stops you from having a high-level API on top, and in fact iOS has several at different levels of abstraction: AVAudioEngine gives you a lighter weight but object-oriented engine that's less complex to setup. AVAudioPlayer handles almost everything for you.

Just came here to say that. The fact that core audio is a great performing API means even less performance critical stuff still gets the benefits of it even if the easy to use abstractions like AVAudioPlayer give up some flexibility and performance vs the native API. While abstraction can make things more flexible, I would argue that the main purpose is ease of use and hiding implementation details.

In your ALSA example the lower level API doesn't prevent you from mixing audio, it simply isn't as easy because you must implement it yourself, this could be arguably more flexible as well.

Abstractions can hide features of the hardware but they cannot create new hardware. Whatever the abstraction is doing the client software could do instead with the lower level API.

So I would say abstraction layers are often added to give ease of use, sometimes at the cost of performance and flexibility.

I think this whole subthread is about different meanings of "flexibility".

An audio abstraction layer can allow different kinds of audio hardware without changing the apps, which is a kind of flexibility.

Reply on news.ycombinator.com