What is the actual problem with a prototype based design?

Question

I feel like anything that can be developed using OO/functional languages can be generally made 'better' using a prototype based language, because they appaer to have the best of them all: high order functions, flexibility to simulate any OO structure, productivity (low verbosity) and scalability because of concurrency. But it seems like they are avoided for the creation of executable applications and of bigger projects in general. Why that?

Answer 1

But it seems like they are avoided for the creation of executable applications and of bigger projects in general. Why that?

I don't know, but the assumption is false.

Larger projects use prototypical languages:

• JavaScript is the most popular language on github.
• Cloud9 is a full-blown cloud based IDE written in JavaScript that connects to GitHub. 98% of this project is JavaScript, 2% is CoffeScript, go look at the source and tell me it's a trivial application.
• Node, not like you haven't heard of it, just happens to be that event-loop webserver framework for building a web app in JavaScript.
• three.js is a 3dEngine in JavaScript. Because, you know, that's not really a big project...
• pdf.js
• Broadway doesn't do much, just decodes h.264 natively in your browser without codex.
• The JVM has been implemented in JavaScript, allowing JVM bytecode from Scala, Java, or Clojure to run inside JavaScript.
• Bcrypt is implemented in JavaScript.
• One of the best video games of all time was written in Lua.
• Lua is used in a lot of places.

How much "bigger" do you want? Are you expecting someone write code that emulates a computer and can just take a linux ISO and run a whole operating system out of your browser and you can start writing code from a linux command-line in C++... or something ridiculous like that? Okay, we have that too.

Seriously, what's "bigger?"

Again, you have the most proliferated language on github that has lead to an IDE, a webserver, a 3d graphics engine, a pdf document rendering tool, video decoder, encryption library and x86 emulator.

I'm not even going to bother linking to the endless slew of webapps and stuff in the chrome store, frameworks of all shapes and sizes, static code analysis tools, or other 'trivial' projects that nobody uses because the language is just so painfully slow and we can't be sure of how to write code in it.

Oh wait, we can be sure how to write quality code in JavaScript. It's called reading the funny manual, writing unit tests, static code analysis, and other fun things you do in every other language if you're competent in that language also.

It's not "risky" because it's got a prototype, it just means you need to know what you're doing, the same way you need to know how to program in whatever paradigm you enjoy. It's not "slow" because it's a prototype, languages out there that I haven't mentioned run at near-C speeds. You can find more information on your local search engine.

Good day.

Answer 2

They're slow as hell. How long do you think it takes a JavaScript VM to make an OO call, compared to C++? And you basically waste time inventing structures that other languages provide for you. And I hope you don't enjoy type safety, either.

I've done a lot of coding in Lua. Re-inventing the class wheel every time was not my idea of a good time. Now I work in C++ out of choice.

Flexibility is slow and unsafe.

Answer 3

OK, let's put aside the debate of native vs JIT, and static vs dynamic. Suppose we take as a given that someone wants to use a dynamic JIT-ed language, like java, python or javascript. Why do they choose a language with classical inheritance instead of one with prototypal inheritance?

The dominant reason is because javascript is not very suited to large systems programming and javascript is the only prototypal language popular enough to get "C-level" approval for a new project. Javascript is bad for large systems programming because it lacks a strict typing mechanism. In large systems you rely on API's to abstract implementation details. Strict typing moves the responsibility of correctly addressing API's from the developer to the compiler. You want the compiler to do that job.

A second reason is because classical inheritance is what most programmers know and have been trained on, and prototypal inheritance is too weird for them. Never underestimate how much "popularity" factors into technical decisions.

Performance does not factor into the decision. Large systems are programmed in java every day, and javascript V8 is roughly in the same performance order-of-magnitude as java (3 times slower in synthetic benchmarks).

Answer 4

To those that complain about speed and scalability ask these questions:

1. How fast does it need to be. I'm talking requirements here, not generalities (full page must respond in 1s kind of detail)
2. How many users are going to use this sytstem now, how many in 5 years.
3. Will it interface with other systems and if so how.

The answers to the above questions will greatly influence your decision. You don't need C++ speeds for probably 95% of applications out there, maybe more. As for scalability. Less than 1/10000 of 1% of applications will ever scale to google/ebay/amazon levels. Most, probably less than 1% will scale to the point that you have more than 100 requests per second, even in enterprise.

Now if you work for say AOL or Google, then by all means speed and scalability likely matter, for the rest of us, not so much so, it's a lot more important to get it done and get it done fast at the lowest possible cost.

Answer 5

I don't think there's anything fundamental, but in javascript specifically there are a few issues that can cause trouble in large scale software:

1. Encapsulation is weak: it very easy for any other code to inspect and modify any other code. This allows some powerful things, but it can also lead to problems in large projects. Hard to find bugs can happen if you accidentally step on some code that isn't yours.

2. convenience over security: js has features like arguments.callee which allows any function to call all the way up the stack and access the root (window in a browser) object. This means that you really need to trust any third party code you call. This isn't an issue for every application, but it does constrain what you can do (strict mode fixes this, but can't be relied upon in a browser context)

3. anything numeric is extremely awkward: every number is a float, which is probably the right choice if you're only going to have one number type, but makes dealing with binary data and integer arithmetic awkward.

4. boilerplate required for typical oo style: it's awesome that you can make a library that implements classes in javascript, but on the downside you're going to need one, and everyone new is going to need to learn the particular library you use.

None of these kill javascript for large projects, and all languages have their own drawbacks -- these are just thigns to be aware of while using js. Using new js features and only targeting modern js engines (v8 for example), which you can do for a standalone app, allows you to avoid some of these issues. External tools can also provide some help (for example the closure compiler from google does various forms of static checking).