Ruby is reasonably fast now, but when it became popular it still was very slow. So while speed definitely matters, maybe its lack is not an insurmountable obstacle.
So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?
This is an example of how programming as a discipline and activity is consistently dismissed by the software community as an unnecessary contrivance. "What about absolute performance?" But the reality is you're making tons of those tradeoffs. You're using a compiler, on an instruction set designed for humans, leaning on network stacks that do work for you in generic but sub-optimal ways, using container systems that introduce huge performance penalties.
Those are socially acceptable to you. They're special in that you think they aren't special.
> So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?
This assumes they are in fact equally capable. Please don't retort with Turing completeness. That's a copout and we all know you aren't about to go shipping things in BF.
Anyway, I'd argue competition is tougher not because there are more competitors (there might be, I don't know) but because they have advanced.
Compared to 15 years ago, Python has gained a lot of stuff, JavaScript has become an ok language with very fast implementations, there's a dozen funcional scripting languages targeting browsers, optional typing has made a comeback, Ruby has native threads and a decent vm and a large ecosystem, Go is a valid solution for things were you might have used a scripting language, lua owns the embedded space and luajit is the state of the art etc.
In 1998 it was enough to have closures and objects to be a potential perl replacement.
Python as it is now, is a very different language than it was in those days. Even ignoring the whole ecosystem with libraries and package management etc, and standard library changes, it's just a much bigger language.
I was using closures to great effect in Perl before I even knew what a closure was. (Are closures supposed to be a difficult or extraordinary feature?)
I really find it funny when other languages do things that Perl has already been doing for years.
Go2 is basically copying the way Perl5 has been advancing without breaking backward compatibility. (They don't seem to realize this.) JavaScript copied use strict. PowerShell copied $_. Everybody copied Perl extensions to regular expressions. (I can't wait for them to copy the cleaned-up, easier and more powerful Perl6 regular expression syntax.)
Every feature that I've heard that Python3 changes directly correlates with a similar change that has happened in Perl5. (Only Perl5 has done them in a way to reduce breaking your old code.)
Those are just a few of the the ones I know of.
Perl has been a far more influential language than anyone gives it credit for. Though that is probably because they just use the feature without knowing the history of it. Eventually Perl6 will be just as influential.
---
I agree that optional typing is good, I use it everyday in Perl6. (And have been for nearly ten years.)
The example was meant to show the "minimum" needed to be an interesting scripting language.
Edit: I love perl. I love perl6. I hope languages get inspired from it.
I have been thinking that there might be room nowadays for a new language that is unabashedly a "scripting language"... something you can easily write scripts with, but which doesn't necessarily aspire to scale real far beyond that, so people will not immediately reach for it to write, say, 250K-line web applications. :3 (Then again, if a language is good/useful/flexible enough, people will use it for everything.)
Anyway, I would like to see such a language. The old stalwarts will probably still work just fine for this purpose, but I am curious to see if there's any innovation left/possible in this particular space.
Dhall is amazing. But it's domain is very limited.
Good answer!
According to them, Perl6 was faster.
(The Perl6 code was also a lot shorter, and I could argue it was easier to understand.)
---
My guess is that the reason was that the C/C++ code had to scan for null terminators often, and copy strings around. (Or perhaps more precisely the stdlib had to do that.)
MoarVM doesn't use null terminated strings, and it treats strings as immutable objects. If you do something like create a substring, it creates a substring object that points into the original string. So rather than copying a bunch of data it basically just creates a pointer.
(Strings are technically immutable in Perl6, it is easy to assume otherwise though.)