pifflesnort

> This is about "shortest path" or "worse is better ...

I think we're in agreement there.

> JS is "good enough" and manifestly capable of evolving cross-browser via the Ecma TC39 standards process and some coopetition to be even better.

Perhaps in disagreement there, especially when you're competing against Apple's user-first focus, and especially when I'm on the receiving end of being forced to use a JS-based stack as a developer. I do mean the full stack, too -- instruction level profiling, debugging, failure reporting, consistent performance profiles, the whole nine yards.

> Anyway, at the asm.js level, apart from syntax, why do you care how an int32 cast or type annotation is encoded? The semantics are sufficient, as proven by UE3 in Firefox. They only get richer as we do SIMD, task ||ism, etc.

Well, as an implementor of systems software, I can't help but be wary that asm.js brings along with it the entire JS language and (in practice) web stack, too. It means that the likelihood that 'web' applications will ever be free of the enormous web stack is lowered, though alternative implementations (eg, NaCL) reduce some of that risk.

I guess we'll see how it goes.

> The point is you seem to treat Google as more benign and non-commercial. That's not credible based on many pieces of evidence, including their public company performance scrutiny by Wall Street. I admire Google for some things they do, and believe they do not over-optimize their share price, but they cannot ignore it, either. Also, they are a house divided, with many conflicting agendas not directly related to business goals.

Absolutely not; I consider Google to be an organization whose commercial interests are ultimately far more aligned with my own than Apple's or Microsoft's. It has nothing to do with being benign or non-commercial -- my interests are in no small part commercial.

> No, for Emscripten/ASM.js, you still need a C or C++ runtime, not just libc/stdio/stdlib stuff but various graphics, audio, and other APIs.

Sure, but we (the systems/games development community) are well equipped to create common runtime libraries, especially on a platform that provides an anemic set of platform standards and components, in which case custom libraries won't suffer from QT or Swing's uncanny valley problem.

> Now you tell me why the shoe isn't on the other foot. Why did Google "ignore" what we've been doing to advance JS for the last two years, and move all its Aarhus talent onto Dart, at some cost to V8?

It seems to me that Google made a rational decision that JavaScript is not a technologically sound foundation upon which to build, and made the first moves to find alternatives.

> You really do have a pro-Google, anti-Mozilla animus -- good/bad or purple/shiny, I don't care.

It's actually an anti-JavaScript animus. The idea that JavaScript ought to be the foundation of the next generation of modern computing platforms runs counter to everything I know about language and runtime design.

It seems to be an entirely market-driven solution, not a technologically-driven one -- but those market circumstances are something you have far more influence over than I do.

> 1) How is this a problem?

I touched on this in a peer comment, but it ties your hands in terms of doing rather normal things that would make for a better model API.

> 2) I don't get this. Your model is tied to a context manager, even if they are mutable, you don't need to merge context throughout your base unless you want to.

Using an immutable model makes concurrency far, far easier (among other things).

> 3) They are not thread safe, the same way UIView isn't thread safe. Why would multiple managed context become out of sync unless you allow it? It's not difficult to deal with. Create a context in the queue you are in. Merge it when you're done.

Like I said in reply to your other comment -- The difference is that the 'model' is what binds all of your code together. The constraints of Core Data therefor introduce tightly bound constraints on all your code.

> 4) You can use Core Data without persistent store and make it fully in memory and everything will work fine. You can even separate your memory context with multiple context managers. Separating your creates and your deletes and etc.

I think you're confusing what I mean by in-memory model and on-disk model.

The way one defines and represents on-disk storage is very different than in-memory storage: the data is persistent, it must remain accessible over time, the model must be versioned, and changes to the actual model definition must be applied as migrations between versions.

In-memory models, however, live only for the lifetime of a particular run of that application, may be modified freely, require no versioning, and require no migrations other than code refactoring.

By tightly binding these things together, Core Data creates the worst of both worlds: all the complexity and downsides of on-disk models with almost none of the flexibility and simplicity of in-memory models.

> 5) Fud. Write a wrapper, use existing wrappers.

That involves quite a bit more work than defining a simple class. Tools such as mogenerator are big, complicated, and a hassle. The point of Core Data is to save effort, but it generates more work and complexity.

> 6) Agree.

Well, at least we agree about something :)

I've found the 'couple things' to introduce enough overhead, that when coupled with the other downsides, Core Data hasn't saved me time, reduced LoC, provided any performance advantages, or improved code quality.

> Why do you distrust Apple and Microsoft and ascribe bad motives to them based on their commercial interests, but fault Mozilla for not jumping on Google's Pepper treadmill like a good little-brother caricature?

I don't distrust them, or ascribe bad motives. I ascribe motives that align with their economic interests -- it doesn't matter if they're bad or good.

> Google has commercial interests too, and they have spent >$1B a year on Chrome -- including advertising and bundling that directly targets Firefox users. (It's amazing we are still alive, and possibly even growing desktop share.)

How much does Google spend on Firefox's search deal? What do you see as Google's commercial motive with Chrome?

My reading (in the context that I have some family that works on Chrome) is that their primary interest was ensuring that they could help push the web forward, and not be beholden to external interests in doing so. They have an interest in open platforms insofar as it gives them leverage over the much more strongly established platform players (eg, Microsoft, Apple).

> asm.js and evolved Web APIs (which developers need anyway) are winning.

The interesting thing is that if asm.js has sufficient adoption, the 'web' part of the equation may very well not matter at all.

If Google maintains their efforts on (P)NaCL and can provide better performance, end implementors may target both asm.js and NaCL, with shims for platform-specific functionality (not unlike most game development today). Once you're doing that, you can also target other native platforms with the same code and tooling.

So I don't think asm.js is all bad. Ironically, it could very well be the escape route from JS/HTML/CSS/DOM that we've all been praying for ever since the idea of the web app came into being. Not because it's the best technical solution, but since when has technical correctness outweighed market forces?

> Evil-me on my Throne of Skulls didn't ordain this outcome.

Of course not. But "evil you" certainly has a hand in it. There are only 4 real players in the browser market, and you're one of them.

In fact, you're the one that decided to ignore what Google has been doing and invest in asm.js to begin with, so divesting any claim in the role of asm.js's possible ascendency is a bit of a stretch.

> Litters the code with Core Data ism? The same your code is littered with UIVism, NSFoundationsm and etc?

The difference is that the 'model' is what binds all of your code together. The constraints of Core Data therefor introduce tightly bound constraints on all your code.

> Please stop using the word thread and use the word queue :)

Why? Queues are M:N mapped to threads, so they are still threads. Additionally, not all work is always done on queues, especially when working with legacy APIs.

> What do you mean by 1), though? The link shows a list of methods you can't override on NSManagedObject, but they're things like -class and -isEqual:, which seems pretty reasonable for a system that needs to inspect and compare its objects.

Well, keep scrolling :~)

Especially 'Custom Instance Variables' and 'Custom Accessor Methods' and 'Validation Methods'. I don't think it's controversial that defining derived instance variables, accessor methods, or other derived state on model classes is an unusual or unwarranted desire, yet doing so with Core Data requires considerably more effort and complexity than a simple model object.

This requires performing all mutation on dedicated code paths. If you require non-asynchronous completion, you have to use the 'wait' variant, but this introduces deadlock risk between threads.

This in turn litters your code with Core Data isms, and means that one can not simply make use of their model as a standard in-memory model.

Compare to SQLite, where one can simply open and commit a transaction synchronously on any thread.

> It's more like $10M and multiple elapsed years to get to Chrome parity, assuming Chrome doesn't keep evolving and put us on a treadmill.

So you don't believe Google's offers to work with external implementors?

> But then, I'm just the guy managing engineering and worrying about budget at Mozilla. Maybe you have greater skills. Where do you work?

I run a systems programming consulting shop. We focus on low-level OS/driver and VM projects, with application development making up the remainder of our work.

In theory, reliable estimates are my livelihood, and I have a very vested interest in the future of the platforms that we will have to develop for. I'm very concerned about the market requiring us to develop apps for a Mozilla platform.

> Microsoft and Apple are on the same page

What reason do they have to roll out something that helps Google undercut their vertical platform/app markets?

If NaCL is 'too good', then it threatens their business. Take that for what it means in terms of asm.js optimization adoption.

> Epic folks have confirmed again just this week that they won't do NaCl, there's no benefit to something CWS-only.

CWS-only and Chrome-only are again, oddly, something you have a hand in. Google pushed out beta PNaCL tools, and CWS-only has primarily been (rightfully) pending PNaCL.

> But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense.

Unless you consider the possibility that:

- Web apps versus web documents are two very different things

- You see this as a way by which we could escape the mess and massive size of the current web stack by standardizing on a much smaller base.

- Simplifying the core stack could open the door to new competition and innovation in the field.

Personally, I'd love to see WebKit and/or Gecko and all the browser chrome implemented on top of NaCL and/or asm.js, with only the most minimal runtime, such that you're not sitting in a privileged position of running native code while the rest of us are stuck in JS/HTML/CSS hell.

> We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations.

We also know that it's ridiculously expensive and difficult, in no small part due to the resistance to enforcing things like formal validation of HTML in the browser itself, creating a problem that's as much art as it is science.

> And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate.

Apple and Microsoft have no interest in undercutting their own vertically integrated platforms.

Only you and Google have an strong interest in furthering the web, and yet, you refuse to work with Google despite them expending considerable time and money on furthering the web, while sharing their work freely.

I think there's a good argument for it being broken:

1) Core Data objects are not NSObject objects. You can't treat them remotely like normal objects: https://developer.apple.com/library/mac/documentation/Cocoa/...

2) Core Data requires making your model mutable, and spreading dependencies on Core Data's abnormal objects throughout your entire code base.

3) Since the abnormal objects are spread throughout your code, and they're tied to non-thread-safe NSManagedObjectContexts, concurrency becomes rather difficult. You have to deal with multiple managed object contexts becoming out-of-sync across threads. Most people just give up and perform expensive operations like -save on the main thread.

4) Core Data merges the concepts of your on-disk model with your in-memory model, despite the fact that the two problem domains have very different requirements in terms of API design, data longevity, relational design, etc. This leads to code that is neither a clean in-memory model, nor a clean on-disk model.

5) Since Core Data objects are abnormal objects, one must produce a considerable amount of boilerplate just to define new model objects. What time you save upfront using a GUI to design your original model, you spend 10-fold in maintaining the code to support it, and in being handicapped by the contraints Core Data places on your code.

6) NSPredicate is awful. It's a brain-dead query language that often make it impossible to cleanly normalize your data store. Aggregate operations are expensive and often require O(n) cost, the query language is poorly documented and poorly specified.

Core Data is a very poorly fit abstraction, but it probably works well enough for simple use-cases. Once you move into concurrency, complex/large models, aggregate operations/projections across your data, or have to deal with it failing, it falls over.

After using it myself for a large project and struggling with all of these issues (and more), and watching another team do the same on their own project, I'd never make use of it again. SQL (via sqlite) is a far better abstraction for managing on-disk data, especially when doing so in a highly concurrent application where one can rely on SQLite's transaction support.

Core Data is barely functional locally, requiring an enormous amount of invasive runtime hooks to create the appearance of a "transparent" (it's anything but) object store on top of Objective-C objects.

The fact that anyone, anywhere (including Apple), actually expected Core Data to work as a distributed object store is totally beyond my comprehension.

> Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow.

You keep repeating this, but I don't see how you can be remotely serious about it.

Compared to JS, DOM, HTML, and CSS, Pepper is downright simple:

https://developers.google.com/native-client/peppercpp/inheri...

As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain.

Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues.

On the other hand, I can't even imagine trying to write a full browser stack, including HTML(5), CSS, JS, et al, in one year for <= $2M? Not a chance.

Yet you call Pepper "too big" and "too complex". Meanwhile, the enormous weight of the mess that is the web stack creates a huge barrier to entry for anyone that might want to meaningfully contribute new ideas to the space.

We're already seeing interesting development occur around (the much more approachable) NaCL/Pepper:

http://zerovm.org/

> That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS.

This is rich coming from the CTO that's refused to collaborate with Google and instead is going off and "misdirecting" energy on alternative approaches.

> It's 2013 now and Dart is not going cross browser.

You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog.

> Given that most code degrades into either wrapping checked exceptions into runtime exceptions ...

This is a self-referential argument; people who are disinclined to take the time to define how code fails are disinclined to define how code fails.

The code can still fail, the failure cases still must be defined, but now the compiler won't warn them that they've failed to do so, and the result is that the failure cases are undefined and unknown, and the code is less reliable.

Without defining failure modes, the system is always in an unknown state: any undefined failure will leave any any stateful code in an unknown state. Since failure modes must be defined, either in code, or in documentation, and writing documentation takes longer, and it must be maintained (and read) manually.

Since defining failure modes manually takes more effort than using the compiler's support for checked exceptions, the reality is that unchecked exception advocates are really arguing for not defining failure modes at all; this is simply laziness.

> There is a reason no other language created in computer history uses them.

Many languages simply don't use exceptions at all, since having what amounts to an 'atomic goto' isn't necessarily considered an advantageous feature. Not using exceptions is the only choice that doesn't introduce a significant likelihood of program failure due to littering code bases with what amount to unchecked stack unwinding gotos.

That said, your statement is not really correct. Languages like Haskell provide checked exceptions via library features. C++ has an optional checked exception mechanism, but they aren't enforced at compile-time (unfortunately).

Not due to technical constraints, unlike ActiveX. It's a self-fulfilling prophesy -- Mozilla's refusal to adopt NaCL will, indeed, stall the adoption of NaCL.

Things might get more interesting if NaCL provides a higher performance deployment target for Chrome users than asm.js does. Then you can just cross-compile for both.

ActiveX was portable the way that the SYSV/SVR4 binaries were portable -- almost entirely in theory.

"It was introduced in 1996 and is commonly used in its Windows operating system. In principle it is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator. Most also require the client to be running on Intel x86 hardware, because they contain compiled code."

What rational comparison do you have between NaCL's constrained syscall interface + Pepper, and ActiveX?

> Yep, so non-portable that they released a Mac SDK back when Macs were PowerPC. Super non-portable. The non-portablest.

Which produced binaries that couldn't run on any other PPC OS other than Mac OS, and provided a runtime that couldn't run the ActiveX controls being deployed for Windows clients, even if it was somehow magically possible to run x86 code.

It was explicitly advertised as being non-portable, as a feature: "Developers can create ActiveX Controls for the Mac that integrate with other components and leverage the full functionality of the Mac operating system, taking advantage of features such as Apple QuickTime."

http://www.microsoft.com/en-us/news/press/1996/oct96/macpr.a...

So, yes, "non-portablest".

What exactly is the equivalence to (P)NaCL?

ActiveX was, at its very core, not portable.

Are you making an objective technical argument, or a solipsistic one?

In that case, I think we just have some differing definitions.

Would you call Java's or Dalvik's bytecode assembly?

How exactly is that by my own words? You also seem to be confusing quite a few technical topics.

First, you're equating ARM and x86 with Microsoft Windows. Those are all "platforms", but they exist at very different levels of the technology stack, and the impact of relying on them is quite different.

Samsung and Apple can both ship compatible ARM devices. Only Microsoft could ship an ActiveX runtime.

Second, you're throwing out "security" as a red herring without actually explaining what is insecure. Exactly what are you talking about?

Lastly, if PNaCL is not viable, then NaCL is not viable. Thus, Google is holding off on NaCL until PNaCL is viable. In the meantime, I'm targeting mobile and desktop applications -- today -- which is entirely consistent with my earlier stated position.

This is a false comparison.

ActiveX was technologically flawed: it was specific to Microsoft Windows, and it was insecure.

NaCL is secure and portable, without sacrificing the user experience today.

Indirectly referring to me as a platform shill is unwarranted. The reason that I argue so strenuously for maximizing performance is simply that performance improves user experience.

> I'm deeply reminded of the leaked internal DART e-mail ( https://gist.github.com/paulmillr/1208618 ) where as much ink was expended on marketshare as it was on technical issues.

I've read the whole memo, and I don't understand what your complaint is at all. Google seems to be focused on actually improving the web as an application development target, and making it competitive with modern platforms.

> This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM.

I didn't intend for this to be misleading -- the option to deploy code specific to each architecture is a benefit.

It means you can take advantage of the architecture's specific features (such as NEON and SSE).

Anything in particular? I eyeballed the API docs recently and didn't see anything so frightening, but you may have more in-depth evaluation:

    https://developers.google.com/native-client/peppercpp/inherits

Google has also stated that they're open to re-evaluating and reworking the API.

I agree that it's wise to default to a portable implementation. I also think it's wise to also have the option of serving up binaries that are optimized for the devices your users actually have, today.

> Right, so by 2040 we can't distribute an application without rebuilding it for 5 or 6 different architectures

5 or 6? 2040? All we've seen over the past 20 years is the gradual reduction of in-use architectures down to a few winning players. We're even seeing it in the SoC/MCU space now, where custom architectures are being replaced with ARM.

I expect to continue to see evolution and simplification, not revolution. If there is a revolution, well, we'll want to take advantage of the power of that fancy new hardware, I suppose.

> one of which is a bitcode format that doesn't even run at native speeds, despite the name.

PNaCL generates native code from the bitcode.

[response to your edit]

> You're basically demonstrating the entire problem with the Native Client camp - you're so myopically focused on the immediate needs and the immediate environment (arm! x86! games! performance this year!) that you have absolutely no appreciation for the trail of destruction being left for future generations.

I would say that you're demonstrating why the web camp continues to fail so horribly to move past simple applications: you're so myopically focused on the ideology of tomorrow over providing a great user experience today.

In fact, I day say you're leaving a far worse trail of destruction, because web applications are the ultimate expression of always-on DRM. When the servers for your "apps" disappear in a few years time, the applications will disappear right along with them -- forever.

How is the Internet Archive going to archive your webapp?

> You have Pepper which is a huge bastardized, specialized clone of all WebGL/HTML 5 audio/media APIs

That's an overstatement of Pepper. It's quite simple -- far more so than the massive browser stack that WebGL+HTML5 brings with it.

In fact, Pepper is simple and constrained enough that someone other than an existing browser vendor or major corporation could actually implement and support a standalone implementation of it. By contrast, producing a compatible browser is such an enormous undertaking that even companies like Opera are giving up and tracking WebKit.

> It's not. Asm.js is pretty much just assembly.

No, it's not. Have you even read http://asmjs.org/spec/latest/ ?

It's a rather high-level bytecode, expressed by constraining JavaScript to a specific subset of the language, interpreted according to rules that are considerably more specific than those specified in the JavaScript spec.

We haven't moved past ARM and x86. Those two cover almost the entire mobile/tablet/desktop market.

If there's a real MIPS resurgence outside of WiFi routers (eg, extremely cheap/low-quality tablets), then they can use PNaCL just fine until a native NaCL target is implemented.

However, given the market weight behind ARM and x86, this seems extraordinarily unlikely to be used outside of some extreme edge players. IIRC, MIPS support isn't even mainlined into Android.

> NaCl is not portable. asm.js is. You should compare PNaCl and asm.js.

NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86. In doing so, it can support NEON, SSE, and other architecture-specific hardware features that make substantial differences in performance.

So why shouldn't you compare NaCL to asm.js?

PNaCL is there to cover the case where we move past ARM and x86, in which case it provides the ability to target new architectures from existing deployed code. In an ideal universe, sites would serve fat x86/arm/pnacl binaries, optimized for a given client.

Failure types are generally classifiable; part of clean module design is in classifying your exceptions in a way that allows you to declare that a more or less granular exception types are thrown based on the actual failure mode(s) possible from your code.

The 'throws Exception' behavior only emerges when people don't take the time to define how code can fail, which is something that is necessary to fully define an interface, regardless of whether or not you have language support for declaring failure modes.

Thank you for being a voice of reason. Adria Richards is clearly trying to redefine the narrative in her favor, and the broader impact on the dialog in our industry is unlikely to be a positive one.