This question already has answers here:
When is a language considered a scripting language? [closed]
(40 answers)
Closed 8 years ago.
Where does Scripting ends and Programming begins? ActionScript 3 and JavaScript/JScript are so different...
The distinction was meaningful once, but the line is getting increasingly blurred to the point where I dont think it is useful today.
historically, scripting languages are interpreted, programming langauages are compiled. But with the advent of VM's and JIT, the line is increasingly blurred.
scripting is when an existing application or tool is manipulated programatically (e.g. office macros), rather than building an app from scratch. Again the line is getting blurred, because libraries and frameworks means that everybody is building on existing tools. Also, API's allow you to use traditional compiled languages to manipulate applications, eg. in Office you can now automate using .net, which I supppose means you can write Excel macros in managed C++.
languages tend to outgrow their niche. Perl was concieved as a scripting language for text manipulation, but has since grown into a full-fledged programming language.
scripting languages have traditionally been higher-level with features like garbage collection and implicit typing which allowed the developer to focus on the task rather than the metal. Real programming languages like C forced you to be more concerned about memory management and machine architecture. Again, the line is being blurred by newer languages. For example, C# has high-level features like garbage-collection and dynamic types, and low-level features like pointers.
For these reasons scripting has been seen as more accessible, where programming has been seen as more demanding and hard-core. Therefore the term scripting can be used disparagingly, like in "JavaScript is just a scripting languague, not a real programming language" or "he is just a scripter, not a real programmer".
Is there a difference? Youre just writing software in different languages for different run-time environments.
It reminds me of an old definition of the difference between prose and poetry which went something like:
There once was a lady from Glass
Who went into water up to her knees.
That's prose. If she had gone deeper, it would have been poetry.
It strikes me that the difference between scripting and programming is a matter of degree, not what language you are using. I've seen people write some pretty sophisticated programs using the bash shell, and others write trivial things using C. Which is the programmer and which is the scripter?
When you're able to write something that's more than a quick hack or something knocked together to get the immediate job done, when you've written something with an eye towards craftsmanship and maintainability, then you've written a program.
The German Wikipedia says:
Aus architektonischer Sicht werden
Skriptsprachen verwendet, um aus
bestehenden Komponenten ein
Anwendungsprogramm zu bauen. Die
Komponenten selbst werden in einer
Programmiersprache entwickelt.
Translation:
From an architectural point of view, script languages are used to
build an application program from
existing components. The components
themselves are developed using
programming languages.
Script languages use components that are already there to make programs. These components are written in programming languages. :)
Think about shell scripting... There you use little programs "mostly" written in C.
Programming is programming.
People often differentiate between scripting languages and compiled languages, but the distinction isn't that useful IMO.
I.e. can compile many scripting languages and interpret many compiled languages.
This question is similar to these past questions:
Programming vs scripting — what’s your definition?
What’s the difference between a “script” and an “application”?
A script, in common usage, is a sequence of actions ("enter stage left"), like a recipe.
For example, a testing script is a simple sequence of actions to perform. It has zero cyclometric complexity.
Programs are more general, and can do anything. They should be modular and designed for reuse.
As software expands, scripts become more complex, but at heart they are imperative recipes, designed for a single purpose.
In one of the wargaming simulations I've worked on, one of the big selling points was that it wasn't scripted, but each entity in the simulation was an autonomous actor which responded to events.
Whether or not the runtime is interpreted, compiled, jited or whatever doesn't matter. Awk scripts were compiled. Lisp programs were often interpreted. Often the unit test scripts for a program are written in the same language as the program.
If I had to point to a language difference, it would be the presence of a module system. Apart from C, all 'proper' programming languages have a module system. JavaScript is getting a module system as part of the ServerJS working group, and is obviously mature enough for applications programming, so is now neither anything to do with Java nor exclusively a scripting language.
The difference should really be made between scripted (interpreted) and compiled code. Programming, I think, is just the general term of giving instructions to a computer or machine.
Programming Languages: Languages that are compiled before they are deployed.
Scripting Languages: Languages that are code when they are deployed and are interpreted on the fly when they are requested.
In the end it's all the same sh*t, they are all programming languages
Two definitions that I find particularly useless are:
Programming depends on the code's being compiled before deployment
Scripting means that the code is "only" used to connect components
I was initially tempted to draw the line around the intention with which the code was written. I would have called one-off with limited lifetime and scope a script and everything else a program. But then, I have written quite a few such programs in C ... and I wouldn't call anything in C as scripted.
My current working definition is this: Scripted code tend to be limited in scope, small, and (hopefully) simple to understand and replace. Everything else is programmed. :-)
Remember that most modern scripting languages have frameworks or backends with some built-in compiling to pre-build and cache the scripts. (see PHP with some optimizers like Zend or eAccelerator, template engines...)
Modern scripting languages like Actionscript3, PHP, Javascript allowing most of modern design pattern (like MVC) and some OOP paradigms - and some advanced designs like "closures". So you have all for "programming".
Rich Internet Applications (RIA) needs a lot of programming skills, the same with RIA running as a desktop application (Flash/Flex with Adobe Air). This has nothing todo anymore with some easy scripting embedded in a website. This are complex applications needing a lot programming skills.
Because most of the scripting languages uses some "backend" to get/retrieve data from databases, this applications are often not easy to develop because of much side effects. People must have knowledge with server stuff to setup their development environment, other scripting languages like PHP for the backends and so so on. Implement some same thing with C++ and a good framework like Qt, wxWidgets are sometimes easier and needs not much more programming skills.
Scripting and programming are for me the same. Yes, you could say "writing a onclick handler for a button on a website is scripting... writing a videoplayer or game with Flex/Flash and Actionscript3 is programming"?
There a differences between a scripting language and a compiled language (host access, sandbox, performance...). But its all programming.
Related
This is a quote from the O'Reilly Javascript Patterns book:
JavaScript is also an unusual language. It doesn’t have classes, and
functions are first class objects used for many tasks. Initially the
language was considered deficient by many developers, but in more
recent years these sentiments have changed. Interestingly, languages
such as Java and PHP started adding features such as closures and
anonymous functions, which JavaScript developers have been enjoying
and taking for granted for a while.
and that's it. I really don't understand how Javascript was considered "deficient" before, and now is not, because other languages like Java or PHP has added closures and anonymous functions? Aren't they just generic computing concepts? Aren't they available in other languages like Ruby? So I don't really know how Javascript is now not "deficient" because Java and PHP added closures and anonymous functions as their features? Why is that?
I think what it's referring to is that in the past many developers considered JavaScript as a 'toy' language and only used it to do quick Web UI tasks like validation etc. without bothering to understand how the language really worked.
In recent years the 'hidden' features of JavaScript such as closures, prototypal inheritance etc. have come to the fore and people are now taking JavaScript much more seriously as a 'real' language.
So JavaScript was never really "deficient" but people may have thought that it was due to their misconceptions about the language.
I personally think it's a poor editing job.
The paragraph should have read (bold addition is mine and is just a suggestion on how
to read it):
JavaScript is also an unusual language. It doesn’t have classes, and
functions are first class objects used for many tasks. Initially the
language was considered deficient by many developers, but in more
recent years these sentiments have changed due to a better and more uniform browser support, extensive work done by various ECMA editions and evolution of various JavaScript frameworks. All, or much, of that change is a direct result of ever-expanding movement of software products to the Web and growing demand for a lightweight language for mobile applications (this one can be somewhat argued).
Interestingly, languages such as Java and PHP started adding features
such as closures and anonymous functions, which JavaScript developers
have been enjoying and taking for granted for a while.
For years, JavaScript has been known to only be a browser language, for (simple) features that required more dynamic and/or flexibility than offered by HTML and CSS.
For several years now, JavaScript evolved as a language and as platform, offering powerful libraries, which also removed certain cross-browser incompatibilities. With rise of these libraries, community actually only started to learn how to use some powerful concepts of JavaScript, such as closures and prototypal inheritance.
They have not been widely used nor known even to JavaScript developers before, since JavaScript is in its basics very simple language, and most developers didn't even have to learn it as you'd learn Python, C or Java - all they had to look at were tutorials and many of them didn't include these language features.
Duo to the increase in popularity, JavaScript (officially ECMAScript) has received several 'editions', where features have been added to the language itself. Latest edition (still under development) will introduce some radical novelties (considered are classes, module system, iterators, algebraic types among others), so JS will become even better, more structured and more easily maintainable language.
JavaScript is raising in popularity on server side also (node.js), and proves to be easy, fast and enough powerful language to do (almost) any kind of work. Node widely 'abuses' probably its best feature - asynchronous nature of JavaScript. That is not new, many languages have async libraries, but as Ryan Dahl said in one of his earliest speeches on node, JS is perfect for it. And mainly because of the closures and other concepts built into it.
So final answer would be the author of the book you're quoting has poorly expressed his thoughts or is simply wrong. It was a toy language and didn't mean to be used for such variety of use cases as it is today. But it evolved, just as Java or PHP did (don't forget PHP didn't have OOP support that seems so obvious now until v5). Other languages are just picking up goodies that JavaScript proved to be more efficient for certain use cases. Overall, my thoughts are that JavaScript hasn't been used properly from the start, and that's the case it had been called 'deficient'. Now developers got chance to explore its magnificence.
Are there any real-world prototype-based programming languages with a whole development cycle?
"A whole development cycle" like Ruby and Python: web frameworks, scripting/interacting with the system, tools for debugging, profiling, etc.
Thank you
A brief note on PBPLs: (let's call these languages PBPL : prototype-based programming language)
There are some PBPLs out there. Some are being widely used like JavaScript (which Node.js may bring it into the field - or may not!). One other language is ActionScript which is also a PBPL but tightly bound to Flash VM (is it correct to say so?).
From less known ones I can speak of Lua which has a strong reputation in game development (mostly spread by WOW) but never took off as a full language. Lua has a table concept which can provide you some sort of prototype based programming facility.
There is also JScript (Windows scripting tool) which is already pointless by the newcomer PowerShell (I have used JScript to manipulate IIS but I never understood what is JScript!).
Others can be named like io (indeed very very neat, you will fall in love with it; absolutely impossible to use) and REBOL (What is this all about? A proprietary scripting tool? You must be kidding!) and newLISP (Which is actually a full language, but no one ever heard about it).
For sure there are much more to list here but either I do not remember or I did not understood them as a real world thing, like Self).
I would argue that JavaScript is a real world language. The main difference is that it tends to be embedded into lots of different environments rather than being a stand alone development environment.
Aside from the obvious use in a browser, JavaScript can be used on the server side using CouchDB (which is becoming very popular as a database both for websites and the desktop) or Node.js - there are lots of others as well. It can also be used to create desktop applications via seed or gjs.
As for debugging tools, these are included in most web browsers and there are extensions such as firebug.
The approach is different in JavaScript - instead of having a core language and using libraries to access different programming environments, it is embedded directly into these environments.
It doesn't look like it. Checking out the Wikipedia list, I can't say any of them are particularly popular for systems-type or standalone programming. And I have a few theories why:
Inertia - people are more familiar with procedural/procedure-class based languages. In the same way procedural languages are more popular than functional, I think we find it easier to mentally keep track of the objects we've specified beforehand
Less error-prone - When I use a class, I can't use things not specified in that class. It's a bit less flexible, but when working on a large project I'm very, very grateful to be able to look at the spec for an object (even if I've written that object) and know how the object will behave. That is, I know the compiler will probably throw an error if I try to do something stupid like use the wrong variable name.
You mention "scripting/interacting with the system". As far as that goes, classes aren't even particularly popular. One-off scripts may use a few functions, or even just straight procedural code. I know if I write a simple little Python script, I'll have a few simple functions and I'll use builtin objects. It's OO, but I'm not writing anything.
No/not many suitable languages. This is I think the biggest one. Lua's great for embedded scripting, but I don't think it can replace Python/Perl scripts in my toolkit.
Prejudice - the sordid past of Javascript has not been good for prototype-based languages, I don't think. Javascript's actually a pretty nice language, once you see code written by somebody that understands it, but there's still a lot of derision - it's seen like a kiddie language. If you say "I'm a Javascript programmer", it's hard to be taken seriously.
EDIT It's either a sign or a symptom, but most PT languages are embedded or application-specific scripting languages (Lua in games or for UIs, Javascript in webpages or for the UI like in Firefox, etc). I'm not sure why this is, but they are either more suited to application customizing or otherwise-embeddedness, or that's what the common implementations are designed for. Python can be easily embedded into a program, and it sometimes is, but it's more common standalone.
This may be more philosophical than you're looking for, and I'm by no means a prototype-based expert, but I've done a fair bit of Javascript and fiddled with Lua. I stand by my answer, though, based on at least personal experience. YMMV.
I see no reason why a PT language as useful as Python couldn't be written, but it doesn't seem like anyone's done it.
I did not found one and the only candidate (JavaScript) is still spending very first steps (like Node.js).
Still one other valid candidate would be JavaScript! There is a .NET based implementation named IronJS which is implemented in F# and is going pretty well. This way one can have whole .NET development cycle at his toolbox. It is based on DLR and can be used in both .NET and Mono!
I'm now thinking to establish my server-side code in JavaScript, and begin to do all on it, but I want to know about its security and flexibility compared to PHP.
I want to know too, if it can be successfully used to develop things like forum boards, full web-sites and things like this, as PHP does.
Javascript is just now starting to get some presence on the server, with things like ServerJS and nodeJS, but right now, you would probably be best off using PHP for your server side code, and javascript for client-side beautification.
The question is very, very broad. Interpreting it as "can I use Javascript on the server":
Fundamentally, sure, Javascript is a very powerful language and so you can do development in it server-side just like you can client-side (and if you do client-side scripting as well, you get some definite reuse benefits using Javascript on the server).
For Apache systems, there's the v8cgi project (a FastCGI Javascript plug-in with connectors, using Google's freaky-fast V8 engine).
On Microsoft-based systems, IIS supports Javascript (JScript) on the server out of the box (I use that all the time), which has access to all of the ActiveX stuff (e.g., for talking to databases, dealing with the file system, etc.).
If your server framework is JVM-based, there's Rhino, which is Javascript for the Java platform and has access to all (or nearly all) of the libraries available for Java — e.g., a huge ecosystem of libraries and plug-ins.
Aside from v8cgi, there are a couple of other projects built on Google's V8 engine.
There's a place that does a full stack for you called chromeserver (I don't know what their backend is; I'm not going to infer from the name).
Paul mentioned ServerJS and NodeJS.
There's the whole CommonJS project.
Etc. etc. etc. There's quite a list on Wikipedia.
Arguing against, there's a very rich ecosystem built around PHP. Unless you're using something like Rhino for the Java platform or JScript on IIS (because of the ecosystems they leverage), you may find that you don't have nearly that ecosystem available to you when developing in Javascript for the server. I mean, if you're looking for pre-built forum or wiki software (for example), let's just say you can't swing a dead cat without finding one based on PHP, and the same cannot be said of Javascript on the server.
The way they are usually used, PHP and JavaScript run in entirely different worlds, and are not really comparable. (There is a server-side version of JavaScript but it's fair to say it's not especially widespread yet, and doesn't run on standard web hosting.)
The security issues you are going to encounter in JavaScript (on the browser) side are very different from what you have to look out for in PHP.
I want to know too, if it can be sucessfully used to develop things like forum boards, full web-sites and things like this, as PHP does.
No, not with client-side Javascript. For dynamic applications, you will always need some server-side language backing it, be it PHP or some other language like ASP, Python, Ruby, Perl....
To replace PHP with Javascript, you need server-side Javascript and there is a lot happening on that front. Mozilla’s Rhino runs Javascript atop the JVM and it seems Google is also working on its own server side Javascript framework. The most popular in-production implementations are:
Helma: Several active projects are using it, runs on Jetty & Rhino and lets developers leverage the power of JVM, has its own object-oriented MVC framework
Project Phobos: runs on Glassfish & Rhino and lets developers leverage the power of JVM, includes plug-ins for NetBeans and integrates with jMaki Web UI framework
JSSP: A very simple server side framework, a lot like classic ASP, JSP and PHP
Aptana’s Jaxer showed a lot of promise, especially by bringing the DOM to the server side, but the project seems dead now. From what I understand, node.js is not a server-side Javascript framework in the same sense as Helma and Phobos. Instead it can be used for writing event-driven servers in Javascript (for example: writing your own web server).
Yes, my site is written by node.js
Using websvr, it's Java style have filter and handlers, hosting on debian OS.
This is slightly off-topic, but it may actually get to the core of your question:
if you want to use only one language for web applications, you may wanna have a look at Haxe.
It is a cross-platform language, that (among other targets) compiles to JavaScript and PHP source as well as NekoVM bytecode. For server-side JavaScript, there are NodeJS bindings.
This way you are not bound to a specific platform. The neko and PHP APIs are largely compatible, so you can deploy on both platforms, having the option to choose neko's speed and persistency or PHP's ease of deployment. Please note however, the PHP output has a little overhead although common optimizers as eaccelerator will make this barely noticeable.
Haxe is significantly less forgiving than both JavaScript and PHP. This makes it harder to learn, but a much safer, robust and in the end more productive tool.
In a word: no. Javascript is a client-side language. In order to do the things that you are describing, you need a server-side language such as PHP.
EDIT: OK, technically it is possible to implement Javascript in other areas besides the browser, but this is not very common.
5 YEAR EDIT: Well, 5 years later, this answer obviously is not accurate, with the popularity of things like node.js. Let that be a testament to how quickly things can change!
PHP and JavaScript are two different languages that do two different things. One cannot replace the other. You are most likely going to use a combination of the two. JavaScript for client-side stuff. PHP for server-side stuff.
I am using GWT, which includes a Java-to-JavaScript compiler. Before this project, targeting the JavaScript runtime from a different language hadn't occurred to me, and I'm enjoying the GWT experience.
A quick search revealed Java2Script as another Java-to-JavaScript solution. Are there any other mature compilers that target the JavaScript runtime?
List of languages that compile to JS
You also have Haxe. It features static, structural, strong and inferred typing; algebraic data types; lambda expressions with closure support; a module system and can compile not only to JavaScript but also Flash, C++, Neko, PHP. Java support is under development too.
Pyjamas compiles Python to JavaScript.
HotRuby runs Ruby source code under JavaScript and Flash.
Orto is (was?) a JVM implemented in JavaScript. (Original site is down; link is to a blog entry.)
The ZK framework, which likes to compare themselves favorably against GWT, uses Java and XML to generate JavaScript. (They claim that it takes far less code than GWT to do the same stuff.)
And I have heard it well-argued that jQuery is a separate language that happens to be implemented in, and run under, JavaScript. :-)
OpenLaszlo is on open source XML -> Javascript (technically DHTML, also can compile to Flash) compiler. I've played with it a little bit and it seemed interesting, although have never used it seriously (bad IDE support when I tried it).
Objective-j is a similar project that resembles objective-c, although runs as javascript (not sure if it compiles it or has a js interpreter). I don't know much about it, but do see posts about it on the Ajaxian from time to time.
Parenscript is "a translator from a small Lispy language to JavaScript". It's not Common Lisp -- it's mostly just Lisp syntax for Javascript, though for simple things you can write the same code to target both, if you're careful. I'm not sure I'd call it "mature", either.
While there are other products which compile to javascript (noted in the other comments), I believe that GWT is, by far, the most mature one out there, in terms of real-world usage.
The simple fact that a number of Google's core applications use GWT (e.g.: the new adwords GUI, Google wave, etc) means you can have confidence the product is going to be maintained for at least the next few years, it isn't just going to fade away anytime soon.
Another thing to keep in mind is that GWT is far more than a java-to-javascript compiler, it also is an optimizing compiler, it has hosted mode, it is fully interoperable with native javascript, it does image bundling, it does code spliting in the new version, etc.
Script #
JSC
cappuccino (sort of)
The inventors of Clojure (a JVM based Lisp dialect) launched ClojureScript in mid-2011. ClojureScript compiles Clojure source code into JavaScript, making use of the Google Closure compiler and the Closure framework. ClojureScript code can run both in the browser client, or on node.js servers.
Here's a shameless plug for a project I started and am continuing to develop: scxml-js, a Statecharts-to-JavaScript compiler
I am looking for an ECMAScript alternative to work as a scripting language for custom application logic. There are things I like about ECMA, especially the syntax for the newer spec(like AS3).
Unfortunately, the AS3 engine is not open source to be able to integrate in a project. I would like a scripting language that was designed for object oriented use.
Specifically, is there a language that has:
Statically typed variables(optional)
Classes, including public/private members
Inheritance, including Interfaces
Packages(optional)
Clean syntax
Must be able to interface as an internal scripting language for an application(like Javascript for a browser), can not be an external system call.
Things I would rather do without
The messy ECMA prototype object
What languages that you know about fit this profile? I've had difficulty finding a quality scripting language that was designed for good object oriented design.
In Java the best ECMAScript (Javascript) option is to embed Rhino. I don't find the prototype-based inheritance a deal killer, as with a bit of discipline you can make it behave almost like class-based inheritance.
If you want something that interoperates very closely with Java, go with Groovy. If you need JVM compatibility, also look into Jython (python on the JVM), Jruby (Ruby on the JVM) and Scala (a functional language on the JVM). If you don't care about Java and JVM compatibility, look at Ruby, Python, and Erlang. Clojure is a dialect of Lisp on the JVM.
Going further afield, TCL (Tool Command Language) lets you embed an interpreter in C/C++ code, there are many embeddable Lisp and Scheme interpreters, etc.
If you want a scripting language that works like ECMAScript, why not use ECMAScript? There are many Open Source implementations, just take a look at the list on Wikipedia.
I'd recommend either Python or Ruby. Neither are like ECMA, but I learned them after JavaScript, and they were a snap to pick up. Plus, they are more powerful languages, making it a better alternative to using a JavaScript engine inside of your application (Rhino for Java).
Python
Forces clean syntax (almost like English while is not False:)
Multiple inheritance (no interfaces)
Interpreter can be extended using C/C++ (possibly used for your adapters, if needed)
Ruby
Syntax is supposed to be close to English (unless conditional, until loop)
Everything is an object
Only supports single inheritance, but uses Mixins to add functionality
Both
Classes
Can be embedded in another application
Private members
Packages
Lua - everything you want and more in ~100KB
See this page for comparison betwen Lua and other mentioned languages.
Haxe on Neko looks like the exact thing you want. I don't know how embeddable nekovm is, but it is opensource so you can fiddle with it. http://haxe.org
The Ruby interpreter can also be embedded within C programs, and may be considered by some to be more object-oriented than Python.
We use ECMAscript as an extension language for the software product I work on and it works quite well. Being a standard (and popular) language, it's nice to be able to point our users to the copious off the shelf documentation for the language. We built our own ECMAscript compiler that translates into bytecode for the platform we are running on, but if I had it to do over again, I'd seriously consider embedding Google's V8 ECMAscript engine (in fact, I'd even consider building our entire app on it).
I'd go with something fairly mainstream to simplify things. Having read your requirements, I'd recommend Python. It doesn't really have interfaces in the Java/C# way, but it doesn't really need them, either. Other than that, it should be a good fit.
QtScript is ECMAScript. You don't mention what the main part of your application is written in, but I suppose it's not Qt, or you'd already know about QtScript.