Serious Versus Scripting Languages
Serious Versus Scripting LanguagesWhy do people accept CobolLanguage, FortranLanguage, CeeLanguage, CeePlusPlus and now JavaLanguage as serious commercial programming languages? What makes people call PerlLanguage, ToolCommandLanguage, RubyLanguage and PythonLanguage scripting languages? Where do VisualBasic, SmalltalkLanguage, DOS command language or MatLab fit into this? Or HTML and XML?
I suggested what I considered a thought-provoking and helpful definition of the difference in FutureOfJava. It is also obviously wrong. Any better ideas? -- RichardDrake
Sure. For a start, try AlternateHardAndSoftLayers. There's no good reason to build systems in the "serious" languages any more. Build your system in a soft language, profile it, then replace the bottlenecks with "serious" snippets. The result is something that is vastly more flexible and maintainable, but which performs exactly the same.
"serious" just means "more work". A program can be written in less time, that does the same stuff, in a scripting language. Machine Code is the ultimate "serious" language.
Serious languages take more work to get something simple done. Compare the code to get a message out of a "scripting" language vs the code to get a message out of a "serious" language. Just off the top of my head, it seems like all the "scripting" languages I can think of just need one line of code to get a message out, but the "serious" languages seem to require 4 more lines of incantations. I know getting a message out is a trivial example, but I think it's true for many larger tasks as well (classes in Perl being the glaring note against this in my mind).
Maybe people consider things "serious" when it takes more work to do something.
There's truth in that, and isn't it even this particular something that's the main point? Scripting languages (as distinguished from non-scripting languages, rather than "serious" ones) are languages where the file system, I/O streams, and command-line arguments are directly available to the programmer, using features in the base language. The price paid for this historically has included difficulty in describing and using new data structures or control flow mechanisms. That price need no longer be paid.
We know that "hello world" is more difficult in language X. Therefore, language X is the best one to use when we're doing something difficult. Is this one of the FallaciousArguments?
scripting languages are glue
Surely the point of a scripting language is that it is intended to provide either an easy mechanism for gluing together other pieces, or a mechanism for extending something more substantial? They're not supposed to make up the body of the system. Of course, things get out of hand (or people see sense, depending on your view) and folks build entire systems out of Perl or Python.
I've built large (hundreds of KLOC) "serious language" systems for over a decade, so I think I know where you're coming from, but I believe you're missing the point. AlternateHardAndSoftLayers is just good engineering practice. I don't think anyone much cares what is "supposed" to make up the body of a system, except for those technical managers who believe what they read in the trade journals. -- PeterMerel
interpreted vs compiled ... ultimately an irrelevant tangent
What is a ScriptingLanguage? I'd have said a script language is usually a language whereby the source is directly interpreted, rather than compiled. Thus Java and VB aren't, but Perl and an [VB|J]script are. I don't know enough abut Python. Does it go through a compiler, or do you just run the source? -- AlanFrancis
Actually, Python and Perl compile to bytecodes the first time you run them. Python's bytecodes persist and are re-used after they're compiled, so that puts it in pretty much the same camp as Java and VBA. Actually there is a very nice beast at http://www.jpython.org that will compile python into java bytecodes. I think it's fair to say Perl is a bit more interpretive - it compiles once every time you run.
sh, csh, and friends are fully interpreted.
bash and its friends (let's not talk about csh, that makes trouble) are also in the windows world. Check out CygWin. For the use prescribed in AlternateHardAndSoftLayers it's fair to say perl and python scale better. For simple tasks I still turn to sed/grep/find/*sh instead. The language in the bash world that is dead for me now is awk; perl exists.
But this is moving off our subject. Java, and before it C++, and before it C, fill the same serious-language niche. The real question is, are there any advantages to building large systems in these languages that the scripting languages can't match?
Some people would argue that you need InterfaceEnforcement to build large systems, and that scripting languages don't support that by definition. I feel pretty skeptical about that argument these days. -- MartinPool
Note that Tcl has had byte compilation since 8.0 (first released in 1997, current release is 8.3). Prior to 8.0 it was fully interpreted, but now scripts are compiled on the fly (a procedure is compiled into persistent bytecode upon the first call). -- Jeffrey Hobbs
people can be more productive in a soft language
Perhaps the best thing to do is to have your cake and eat it too, by using a serious language which gives you all the flexibility of the scripting languages. I refer, of course, to CommonLisp.
Or Python! Like Lisp, it has intellectual depth and an endearingly unique syntax.
More seriously, scripting languages are not just for non-programmers: people who are quite capable of learning a hard language might be more productive in a soft language.
end users vs Serious Programmers
It's these great answers to a simplistic question that make Wiki wonderful. But I'm still not clear: CanEndUsersScript?
speed, that's it
'Why do people accept Cobol, Fortran, C, C++ and now Java as serious commercial programming languages?'
Are these considered serious commercial programming languages because they have serious commercial and expensive developer tools available for them?'
No. People don't accept ScriptingLanguages? as serious because they are late-bound, typeless languages, and some people cannot afford the serious speed problems.
PrematureGeneralization. Most also allow you to write optimized code in languages like C.
no source is a feature
In my work, one of the features of a serious language was that the customer did not get the source, and therefore could not alter the source to create a nonstandard, unauthorized version. From a support stance, this is a GoodThing, because the customer never tells you that the code has been modified until after you've spent 3 days looking for the bug that was introduced. -- PeteHardie
If your customer changes the code, causes a bug, and requests support without telling you that the code has been changed, your choice of language is not really the problem you need to address.
You cannot predict in advance that a client may change your code, cause a bug and try to get support pretending they "didn't do anything". And even if you could, you would be throwing away 90% of your business refusing customers who might do that. What exactly problem do you think needs to be addressed if not choice of language?
[What about customers who hex-edit or third-party patch your application? (Stupid) People use no-cd cracks on pirated games and still expect support. The barrier is slightly higher if it's a compiled application than if it's a bunch of text files, that's all. But there's even workarounds for this in many scripting languages, like py2exe for python and similar packagers. That gets you at least as much security as Java has. I think the problem is that if you're paranoid about this sort of thing you need either need to take active steps to solve it (which apply equally to any type of language), such as digital signatures and/or encryption, or you need to take a step back and consider why you're so paranoid, if it's justified, and what you can do about your customer relationship to solve it. If you write your support contracts properly, and are up front with your customers, the very worst case is that you'll lose a some time and charge them a bunch of money.]
Somewhere on this wiki is a discussion of techniques for encrypting scripting languages, but for the life of me I cannot find it. If you come across it, please place a link here. Thanks. LostTopic?.
The points here are valid. Nevertheless I'd like to share the converse (BadThing): vendors who obfuscate their code in an effort to hinder analysis and drive up delivery and maintenance costs for customers. I work for a subsidiary of a large corporation. In my shop we have Engineers, Computer Scientists and others with the skills that allow us to do our own development - in fact we are set up like a 'mini' IT department to support the operational side of our business. Because we are small, we also engage vendors for some projects. We have found many of our vendors incompetent in various areas including - obfuscating open source versions of various languages and LDAP - ostensibly to create 'proprietary' applications, which turn out to be nothing more than wrappers over renamed libraries (when we determined this little subterfuge, we diff'd their libraries against the originals and found minimal changes - mostly attribution changes - they couldn't simply inherit and extend existing libraries - probably fearful that we would see how simple the 'difficult/complex' application solution they were hawking really was, and not justifiable of the outrageous price tag). Vendors also used extraneous and overbloated libraries and frameworks they did not fully understand, to build applications that did not scale as advertised - and required refactoring and rewriting by us (e.g. instantiating java objects in endless loop - breaking garbage collection and causing virtual memory leak when memory usage hit high water mark; not noticeable with small traffic volumes, very noticeable with heavy traffic volumes. Implemented in a Perl script that now gets the job done, and is capable of being maintained and extended easily). Without access to source code, we would not have been able to identify these issues. Another tactic that is more difficult to deal with is binary frameworks written in ancient languages (from 'strings' we can determine that we are dealing with a framework implemented in pascal, and another in a defunct Sun tool that is no longer in production).
In an effort to fend off these threats (to call BS when it is due) we now require vendors to provide source code - for which we take ownership - for all purpose built applications in our system. In my experience some of the biggest names in the enterprise software consulting business hire a mixed bag of developers that more often than not, are a detriment - particularly if you have in house capabilities - given the patience (to wait for existing schedules to clear), or will (to change the work priorities) to make it happen without flushing large amounts of cash down the drain. -- AnonymousCoward - I hope this provides another viewpoint that shows this issue does not have a simple black or white answer. My gut reaction is companies that do not have knowledgeable technical staff are at the mercy of unscrupulous consulting companies at worse, and suffer with incomplete or malfunctioning applications at best. I have yet to see consulting firms specialize in iterative development without a hefty price tag. I think I've come to the conclusion that I am in the wrong line of work...
make easy things harder and hard things easier
IMHO, serious languages, relative to scripting languages, make easy things harder and hard things easier. Perl is famous for its one-liners; there are no one-liners in java (typically, you've got at least three lines - package, class signature, method signature - before you even get going). On the other hand, I can't imagine writing anything big in Perl - but I don't know Perl very well.
I can't see why the features that make serious languages serious (namespaces, encapsulation, etc) couldn't be added to Perl without taking away the ability to write one-liners.
Perhaps it's not what the language lets you do that matters, but what it doesn't let you do. Serious languages are more restrictive. See BondageAndDisciplineLanguage.
-- TomAnderson
WADR, that's kind of missing the point. If we are talking Perl, OK. Perl has namespaces; I can't imagine CPAN working without them. Perl supports both functional and object-oriented abstraction, even if one could quite justifiably argue that its OO system is a kludge. Python and Ruby support features of orthogonality, maintainability, etc. even better, in many respects. In Ruby, it is true that you can finagle with a class at any time, such that private members become public, and in C++ you can just pull a cast. But in Java, private means private. So I think this distinction of 'scripting' vs 'serious', at least in this case, is meaningless.
Perhaps the difference between dynamic and static typing is a bigger and more meaningful issue. I don't really think that static typing buys much in terms of reliability, but there are obvious speed advantages - important for something as 'serious' as a kernel. LushLanguage mixes both approaches, and, if I'm not mistaken, so can CommonLisp. Given that Lush can compile to optimized machine code and incorporate C code, there is no reason one could not write a kernel in the language!
Does any flavor of SQL (PL/SQL for example) count as a "serious" language by the definitions discussed here?
Regular SQL isn't a programming language, so the serious/scripting distinction doesn't apply to it (any more than it does, to, say, XML). PL/SQL is basically SQL with Ada, so it's serious.
Is PL/SQL TuringComplete?
Any dialect of PL/SQL that supports unbounded looping is trivially TuringComplete. Create a two-column table where each row corresponds to a cell of the TuringMachine's tape, using one column for a sequential ID and the other for the cell's contents. Encode the internal state machine as a big CASE...WHEN expression. Loop until the state machine says to halt, doing SELECTs and UPDATEs on the tape as necessary.
Plain old StructuredQueryLanguage, on the other hand, is definitely not Turing-complete. The reason is that the same sequence of statements will always execute in the same order; that means that at any point in the sequence, quantities like the total number of rows in all of the tables are finitely bounded. Even a statement of the form "INSERT INTO table SELECT ..." has an upper limit on how many rows it can insert, and therefore how many computations it can carry out.
I should have noticed the 'PL' before 'SQL'. In that case, I would have guessed that it was Turing complete. GG me; duh...
Although I have no source to back this up, I was always under the impression that a "scripting language" is any language originally designed to help people avoid repetitive tasks, especially when doing system administration. Nothing in such a definition would prevent a language from being well-designed enough to be used for "serious" programs as well.
Computers are designed to help people avoid repetitive tasks, as are all programming languages, serious or not.
I have named Python and Ruby 'ScriptingLanguages' before, and people have frowned me upon for it. But lately I've thought of a reason why Python and Ruby, (or other non-typed 'scripting' languages for that matter) can make life harder in the long run. Imagine building a class Matrix. Seeing you don't have to specify parameter types in method definitions you can't overload functions. But take, for example, the operation '*'. This is a completely different algorithm for multiplying with a float or integer, or for multiplying with another Matrix. This means that we'll have to revert to such ugly practices like:
if param.is_a?(Matrix)and
if param.is_a?(Integer)(with Ruby syntax). Doesn't this go against OOP and OOD. How can PythonLanguage and RubyLanguage then proclaim they're ObjectOriented? Perhaps one of you can enlighten me a bit. -- ChristophePoucet?
Why use these ugly hacks when you have DoubleDispatch?
As in:
class Matrix
def *(b)
b.mult_by_matrix(self)
end
def mult_by_matrix(a)
# do matrix multiplication
end
def scalar_mult(n)
# do scalar multiplication
end
end
class Numeric
def mult_by_matrix(a)
a.scalar_mult(self)
end
end
Ruby has open classes, so extending Numeric isn't a problem. Doing DoubleDispatch in languages where you can't extend classes without changing their source code is a problem, though.
I think the above DoubleDispatch code is confused. First of all, the issue of commutativity vs. noncommutativity is not addressed. The multiplication of two Matrices should not be commutative: m1 * m2 != m2 * m1 (usually). Yet multiplying a Matrix and a scalar should be commutative: m * 5 == 5 * m. Second, I don't see how 5 * m knows to invoke 5.mult_by_matrix(m). G-d forbid I should open up Fixnum and redefine its * method to invoke mult_by_matrix. Oy. Perhaps the Matrix class is missing a coerce method. Ugh.
And PythonLanguage uses a set of special methods for OperatorOverloading. Thus __mul__ is the method called for the '*' operation. So if you implement a __mul__ method for your new class you get full * operator overloading on that class. Also for mixed types you can use dynamic type checking of the parameters within the __mul__ method. -- Alan Gauld
Matrix.__mul__ is invoked by m1 * m2 and m * 5. Matrix.__rmul__ is invoked by 5 * m. "Emulating numeric types" (http://www.python.org/doc/ref/numeric-types.html) is your friend. -- ElizabethWiethoff
processing text vs number crunching
Isn't one of the clues about what makes a language a scripting language in the name. 'Script' means a bit of text. Serious language have their roots in languages designed for engineers to manipulate numbers with and they tend to be good at that, but lousy at handling text. Scripting languages are good at handling text and that's what most of non-engineering computing is all about which is why scripting languages are so easy to use. They're fit for purpose. Of course, numbers are the serious hard facts, text is just the soft stuff round the outside. -- StephenHutchinson
Text is not the soft stuff around the outside if you're compiling the Oxford English Dictionary. http://www.oreillynet.com/pub/a/oreilly/perl/news/oxford_0900.html
Builtin numerical support is arguably better in Ruby and others than it is in, say, C, at least feature-wise. Ruby features standard support for matrices and bignums, for instance. The only difference is speed. If one were to introduce mathematicians who knew nothing significant about programming to a programming environment, odds are they would quickly lean towards something robust and interactive. (I know a few who did end up going that way.) Python, Lisp, and Ruby all come to mind immediately.
This is a holy war. It is irrelevant what language you use, provided it is the most efficient means of accomplishing your project. By that I mean you know it well enough and presumably have automated all of the drudge parts of it out with well crafted tools (ideally created by you and your team - and reused from project to project). I measure efficiency based on several criteria: a) can I create a prototype quickly? b) can I refactor the application quickly as the project evolves? c) can I embed and extract the documentation from the code itself? d) is the language hardened (not brittle)? e) is the language easy to recall as I compose, or am I constantly referring to reference material? f) does the language avoid BondageAndDisciplineLanguage problems? g) can I easily maintain and extend the application after my customers begin using it?
Given the evolution of hardware, there is little detectable performance difference between different languages anymore. However, I do accept that there will be instances where the small differences would be significant - as in the execution of a super-computer cluster who's primary function is crunching numbers as quickly as possible and each cycle of cpu time is in high demand. On the other hand, many applications (and I would hazard a SWAG at 'most') do not have such bottle necks; most of the bottlenecks seen are network latency, and disk access delays, neither of which will be significantly impacted by the choice of language.
The speed of user interaction is another major bottleneck.
Most, if not all 4GLs are intelligently designed, as mentioned above to provide byte code compilation - and subsequent runs are very competitive with java and C++; translators are also available, and hybrids, such as Jython merge multiple languages for the best of both worlds.
Results are everything. Dogma is counterproductive. While I crank out web based applications my customers want quickly, with minimal downtime, bugs, and administrative issues using Zope/Python, my counterparts struggle to get multiple projects that are late, over budget, and fail to meet the needs of their customers out the door. To paraphrase Bruce Lee, "Take what works, and discard the rest"; evolve or perish. -- MalcolmCampbell
And if you don't like what works, make something else that works; look at YukihiroMatsumoto.
which actually works best in the field?
When I worked for <mature, large, hospitality-related corp> we had apps of three classes: those we used internally to do cool, ad hoc stuff, those we shipped as binaries to clients, and those we made available as server-side scripts.
The local in-house stuff was about evenly divided between "serious" (compiled) languages and "scripting" (shell, perl, awk, etc) languages. The coolest stuff was often a short script or set of scripts that did magic things. The customers never got to see these.
The stuff that shipped as binaries was often written from a scripted model of something from our ad hoc apps stable. It got all kinds of rigor and formality, went through the ReleaseEngineer? and QA to customer testing and acceptance.
The server-side scripts that we made available on internet and intranets were less rigorously tested.
The stuff that gave us the least trouble was the in-house ad hoc scripted stuff. The most trouble came from the formally released stuff.
I'm sure a certain amount of that discrepancy was a consequence of who was using the stuff, but it was nonetheless a fascinating phenomenon for those involved. -- GarryHamilton
Deployment
If you work in C, you ultimately get an executable file that you can just give to users. If you work in Python, you don't - you have to get your customers to install a python runtime, and you have to figure out some way of running the thing.
Java has exactly the same problem, as does VisualBasic, but they're accepted as serious languages.
VB doesn't really require installation, as Windows comes with the necessary stuff installed, and the system knows how to run it. Java's an interesting example - in fact, java didn't get deployed widely until there were easy-to-use (and redistributable) JREs, executable JARs and so on.
There are equivalent tools for Python.
Really? Like what?
Ah, um. Not sure. But they probably do exist.
Well, thanks a bunch.
distutils can be used to create an installer for C and C++ extensions to Python. py2exe can be used to make "executable JAR" equivalents. The Python interpreter itself qualifies IMHO as an "easy-to-use (and redistributable) JRE" equivalent; the Windows version is available as a straightforward installer, and thereafter, Python scripts are double-click-to-execute. You can't drag to them, which I find somewhat annoying - however, I've worked around that with an additional Python script and a batch file. (The batch file reads its own name and tells the interface script what script to call and what that script should do; the interface script then dynamically imports the needed script and feeds to it the files that were originally dragged onto the batch file.) -- KarlKnechtel
The claim is made above that C developers get to have, at the end of the development process, a stand-alone executable that they can just give to end users.
This is inarguably true in some cases, particularly for small utility programs. But the fact is that a C application of any volume will have scads of dependencies to external resources, including DLLs (see DllHell), configuration files, databases, images, etc., etc., etc. For this reason, C developers more often than not need to give their end users a self-extracting executable with an installation program. Installation programs can and do handle the task of transparently installing interpreters for scripting languages along with the application program. (There's something to be said about GreenspunsTenthRuleOfProgramming here, but I'm not sure what it is).
You can have both scripting languages and a stand-alone executable by using an EmbeddedLanguage. Many of today's prevalent stand-alone scripting languages (i.e. Python) can also be embedded into applications. You treat your scripting source as you would any other resource used by the application.
I'm not sure there is a distinction between "scripting" and "serious" anymore. I've worked with C interpreters and lisp compilers and all sorts of weirdness. I maintain a simple categorization in my head:
Why did he do that? Doesn't he know there are a number of Lisp/Scheme dialects that translate into C code, hence machine code? I really don't see what's so special about C, because even C is meaningless to a computer. There is exactly one programming language: machine language. Everything else is fluff.
Kind of reminds me of the BrihadaranyakaUpanishad?: Kati devaha, Yajnakalya, iti? (How many Gods, Yajnakalya, are there?) asked Sakalya. Yajnakalya at first refers to the Nivid, and replies: Trayas ca tri ca sahasreti (Three-thousand and three.) Sakalya persists in delving deeper into this matter, and after several iterations of the same question, Yajnakalya finally replies: Eka iti. (There is but one.) -- TheerasakPhotha
There is exactly one programming language: machine language.
Except that there isn't. There are as many machine languages as there are processor models. CeeLanguage at least provides a layer of abstraction on top of that tower of Babel.
It may depend on the task at hand. Scripting languages are effective if a business has to be quick and nimble. Compiled languages tend to be a better choice for expensive critical function systems such as life support and bank calculations. The latter projects are prepared to absorb the extra cost of development in order to have a more robust product. I like scripting languages, but would not want to use them for medical equipment.
Compiled languages can catch more problems up front, but at the expense of more coding and slower testing cycles. It could be argued that the quicker turn-around of scripting languages gives one more time to develop unit tests. That may be true, but thorough unit testing has not been accepted into many organizations. Plus, in scripting languages there may be more to test. In a compiled language typically you don't have to check to make sure a parameter is a number instead of a string or mal-formed number, for example. The compiler enforces that up front. (The upside is that the scripting language is not verbosified by type declarations, reading more like pseudo-code.)
The rule of thumb is that if getting sued is a bigger fear than keeping on budget and/or keeping up with change, then go with compiled. This may be what they mean by "serious". However, the implication that scripting is for "amateurs" is misleading.
-- top
"Getting sued" and "compiled" are orthogonal. "Getting sued" instead correlates with strict development processes and "compiled" correlates with performance requirements, regardless of implementation language chosen. Thus, even though you might implement higher levels in a scripting language, you will also have created and reviewed in detail the requirements, design documents, and unit tests for that code, and the code itself would be under the same strict change management as everything else in the project. Scripting languages would be a great choice for the non-performance critical layers because whole classes of bugs go away (memory management, for example) and the code density is higher, resulting in less code to review and fewer places for bugs to hide. -- IanOsgood
Oh my, but "memory management errors" and "compiled" are also orthogonal. Also, would you consider Lisp a scripting language? I don't think so. But it isn't (necessarily) compiled and it's still not used for throwaway scripts. It also has a higher code density than most scripting languages. Hell, Ian, the world doesn't consist of C and Perl only!
I was only disputing that Compiled languages tend to be a better choice for expensive critical function systems such as life support and bank calculations. Language is not the issue, process is. On the other hand, some critical systems have RealTime requirements, in which case I would choose a compiled language over an interpreted language, and probably choose static memory usage over dynamic usage. -- io
...and still you did it with FallaciousArguments. Anyway, a compiler is quite close to a proof checker (the more powerful the type system is, the closer it comes). I'd rather trust an automatically checked proof than any 'process' that relies on hacking and testing.
I'd rather trust an automatically checked proof than any 'process' that relies on hacking and testing.
Then I think you will love TestFirstDesign.
Shouldn't this be an easy distinction? ScriptingLanguages? emphasize quickly writing one-off programs; serious languages emphasize writing long-lived, maintainable, fast-running programs. That makes C the classic serious language and Sh the classic scripting language. Java is obviously serious, VBA is obviously scripting (and VB is its bastard child with delusions of being taken seriously).
Ah, but what about JavaScript?
Well, what about it? Long-lived? No, lives until you click a link. Maintainable? Never seen, certainly not emphasized. Fast-running? A browser is slow even without JS. On the other hand, all Java-Scripts are crappy one-offs, witness the astonishing number of abandoned web pages. So really, what about it?
[What about NodeJs?]
It's my opinion that dynamic/scriptish languages make for poor SystemsSoftware. One needs "anal typing" for the core infrastructure "guts". Scripting languages are better suited for custom small to medium applications and light-duty "gluing" of components and languages.
[What does any of that have to do with writing long-lived, maintainable, fast-running programs?]
NodeJs is sometimes used to replace features found in Apache or IIS; basically a kind of roll-your-own web server, or at least an application that has web-server-like qualities to it. Thus, one may be reinventing SystemsSoftware. I'm not saying that such is always bad, but it's dancing at the smelly border of unnecessary reinvention of infrastructure.
[So… it indeed has nothing to do with writing long-lived, maintainable, fast-running programs. Great. Back on topic, Node's obviously geared toward long-lived programs, being intended for writing Web-app serversides. Whether it's maintainable is open for debate, but the proliferation of large, useful, and regularly-maintained applications written on Node (the CoffeeScript compiler being a prime example) is pretty good evidence. And as for performance, there's non-blocking I/O, plus Node uses the heavily-optimised V8 JavaScript runtime.]
I'm not sure what you mean by "long lived". I interpreted it as meaning software used for many years, but it now seems you meant not using the event-driven style typically used for web apps. And I don't want to get into a LanguagePissingMatch today. Maybe later.
[I didn't introduce the term "long-lived"; based on previous contributors' discussion, especially the "Long-lived? No, lives until you click a link." part, I assumed it meant that a particular application instance stays running for a long time, contrary to older client-side scripts that unload as soon as the user navigates anywhere. (I say "older" because these days, a lot of client-side scripts are used to pull together single-page applications, and those scripts stay running for as long as any other client app would.) If "long-lived" instead was meant to refer to the application itself being used for years, that property doesn't really relate to anything else in a language or platform design apart from the question of maintainability (which was also mentioned as a separate point). As for a LanguagePissingMatch, if you don't want one don't start one.]
If you come in asking "What about X?" you are generally inviting criticism about X. True, it takes two+ to Tango, and so the LanguagePissingMatch may be half my fault. But perhaps a dedicated topic would be more fitting. However, I will not participate any time soon.
[I asked "what about X?" in the context of "Y isn't a serious language because it isn't used to write long-lived, maintainable, fast-running programs", since X (in this case NodeJs) happens to be an instance of Y (JavaScript) used mostly for writing long-lived, maintainable, fast-running programs. It's a specific counterexample, not a general invitation for any and all discussion of X; I'd like a response from the original presenter of that claim (the claim that JS is never long-lived/maintainable/fast-running), rather than generic NodeJs criticism.]
An oft-quoted reference:
See:
EditText of this page
(last edited August 25, 2014)
or FindPage with title or text search