7

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?

Improve this question
4
  • 7
    Higher order functions, verbosity and concurrency have nothing to do with prototypes. Maybe the prototype-based languages you know happen to have those features, but that's just a coincidence.
    – user7043
    Oct 30, 2011 at 21:33
  • 2
    And what's this about concurrency? That's not a given either - many of them are sorely lacking in even the most basic concurrency control. And simulating "any" OO structure is one hell of a stretch. Hello, virtual dispatch?
    – Aaronaught
    Oct 30, 2011 at 21:46
  • Yes now that I took the time to read a bit more I realize I was not understanding well what it meanned. So you actually answered my question but as it was a comment I can't choose it.
    – WindScar
    Oct 30, 2011 at 23:12
  • 1
    I found it's a lack of understanding of the prototype chain that leads to it being disregarded by the community at large.
    – Josh K
    Nov 1, 2011 at 14:15

5 Answers 5

Reset to default
14

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:

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.

Improve this answer
3
  • That was just the answer I was expecting, someone to say I can go on and make my projects on JavaScript and HTML5. After learning several languages I felt in love with how things are done in JavaScript and Lua and was feeling like "too good to be true". Thank you very much.
    – WindScar
    Nov 4, 2011 at 3:37
  • @WindScar Glad you liked the answer and found it helpful. By the way, you have a bunch of questions you haven't accepted, can you please go back and accept some?
    – Incognito
    Nov 7, 2011 at 14:46
  • Enjoy your subjective "bests" ever. I'm sure that three.js is really popular and competitive... just for example.
    – DeadMG
    Nov 12, 2011 at 3:34
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).

Improve this answer
4
  • JavaScript is also the same order-of-magnitude as C and assembly. "Order-of-magnitude" is a bad comparison.
    – Raynos
    Oct 31, 2011 at 13:36
  • @Raynos: You said 2x in the comments to my answer, but you never said where you got that figure. Source or it never happened.
    – DeadMG
    Oct 31, 2011 at 22:37
  • @DeadMG 2x is an off-hand boast the mozilla team made at jsconf eu 2011. There are benchmarks floating around showing a 3x change. This benchmark claims an average difference of 4x between c & v8. I'll see whether I can find reputable sources. This benchmark claims v8 is a factor of 3 from c++ (in the comments)
    – Raynos
    Oct 31, 2011 at 22:45
  • @DeadMG Here's a more reputable source
    – Raynos
    Oct 31, 2011 at 23:02
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.

Improve this answer
6
  • 2
    Performance is a bad excuse. JavaScript in V8 executes about ten times faster than python 3 ( shootout.alioth.debian.org/u32/… ). A smart JIT compiler can translate dynamic typing into static behavior.
    – Joeri Sebrechts
    Oct 31, 2011 at 9:19
  • 2
    The question clearly specifies OO and functional languages. Comparing it to other dynamic languages is therefore irrelevant. I think that performance is an excellent reason.
    – DeadMG
    Oct 31, 2011 at 12:29
  • 2
    @DeadMG C is twice as fast as JavaScript. That's it. Sure a factor of 2 matters, but it doesn't qualify for "slow as hell". Also WHAT? "unsafe" C++ is "the king of you want to shoot yourself in the foot, do it". You can't use the "unsafe" argument.
    – Raynos
    Oct 31, 2011 at 13:37
  • -1. I've always felt that good programmers understand the pros and cons of languages and try to look at features in an objective manner. Based on that definition, you have most certainly failed. I'm not saying that prototype based languages are good or bad--I'm saying that you have did not answer in an objective manner.
    – riwalk
    Oct 31, 2011 at 17:28
  • 1
    If you're "Re-inventing the class wheel every time", then you're doing prototypal wrong.
    – Ryan Kinal
    Nov 1, 2011 at 14:32
2

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.

Improve this answer
1

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).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.