It would be possible to extrapolate that Python's gaining popularity relative to Perl over time as companies migrate Perl code to Python code, but the job statistics don't show a decline in Perl and corresponding gains in Python.
Per my reading of the job trends, they prove that such a replacement is indeed not happening in significant volume.
Perhaps that subset of Linux known as x86 has fine support, but the last time I looked, PPC Linux (for example) had no support from NVidia. Synecdoche does not make for accurate engineering.
But Vista will end the year in the w3Schools stats with a 6% to 7% market share. Linux at 3% - little changed since the dawn of time.... How then do you make the argument that Linux is in track and Microsoft is not?
With all of Microsoft's preloading deals and the almost unavoidable Windows tax and a growing market for new computers, Vista only has a 6 to 7% share?
You cannot substantially increase everyone's pay without going above X. Therefore you either have to reduce someone else's compensation in order to give someone (the writers) a raise or pass the cost onto consumers.
... or find new markets or sources of income, such as DVD sales and Internet distribution.
This raises three questions. First, if (as the argument goes) a DVD boxed set with commentary from the writers and producers and showrunner is worth more than a DVD boxed set without that commentary, why does the studio ask the writers and producers and showrunner to contribute their work in making that commentary for free?
Second, if Internet distribution really isn't making any money, why are the studios doing it?
Third, if Internet distribution is an investment which the studios hope will make money, what's the harm in giving writers residuals as a percentage of revenue? If it doesn't work, the studios aren't out anything. If it does work, it's the same recompense system as any other form of distribution: small screen, rentals, DVD sales, big screen, syndication, etc.
The problem is that there's now a system in which creators can bypass all of the middlemen (studios, distributors) and reach their audiences directly. The studios don't like that and want to bypass everyone else (creators, distributors).
If you had read my posts with any degree of caution whatsoever, you would have noticed that I was very careful to suggest that only a small portion of the entire Ruby community exhibits this behavior.
As far as I can tell, no one in the Ruby community is claiming that Ruby or the Ruby community invented most of the things it is known for doing well...
Cosine didn't use the word invented specifically, but my claim is that there is a very vocal coterie in the Ruby community that seems to pride itself on slapping new names on old, old practices and parading them around as if they were new.
Anytime you define a new function you are changing the semantics.
I can't see how. Just about every language I've used that supports functions allows you to define your own functions of variadic arity. The semantics are "functions take arguments", and you don't get much choice of whether you pass by reference or value, for example, or whether arity is fixed or checked at compile time or types are checked or what.
The entire reason Ruby is hailed as being good for writing DSLs is that you can do things within Ruby with little more than well-chosen method names, classes, and a few minor hacks (often involve method_missing) that would take writing a parser and doing more complex work in other languages...
... except for languages such as Perl, Smalltalk, PHP, Lisp, Scheme, and I believe Python and Tcl. This list is not exhaustive.
It's amusing and a little disturbing to see all of the fervor in some parts of the Ruby community as if they'd invented something that the rest of us haven't been doing in several other languages for, in some cases, decades. Me, I'm waiting for them to invent LLDD (linked-list driven development) when they get tired of BDD. (I suppose you can link a list of test cases to the desired external non-programmer behavior of a project.)
... embedded DSLs are a kind of API, and there is no obvious dividing line between "just an API" and an embedded DSL.
Sure there is. If you have to write a parser, you've written a new language -- you're no longer using a subset of the syntax and semantics of the host language. Merely choosing expressive nouns and verbs where the language already allows you to choose nouns and verbs is not creating a DSL. It may be using language specific to the domain, but it's not creating a new language.
Hygenic macros or manipulating the AST directly is closer to the line, but when you can change the actual semantics of the host language, you have something different.
I haven't ever seen a so-called Ruby DSL that actually did anything other than slap meaningful names on method calls and classes.
The binding of given block, particularly the binding of x?
By that definition, all subroutines that take arguments are closures. I could certainly write a language that implemented them as closures, but that doesn't make them closures per the language's semantics.
Your createErrorReporter does indeed return a closure though.
Re:I'd like something else.
on
Ruby 1.9.0 Released
·
· Score: 2, Informative
There's a Ruby implementation on Parrot called Cardinal. It stalled for a while until the Parrot 0.5.0 release in November, but that should have cleared the next few roadblocks.
The block syntax isn't as good as having first-class lambdas, either, so you're running a risk of overrating Ruby blocks there.
Ruby does have first-class lambdas, but the block/proc distinction can be kind of a problem sometimes.
Domain-specific languages are a widespread technique.
I'm familiar with domain specific languages: m4, regular expressions, procmail. Passing a hash of parameters to a method does not make a DSL. It's an API, no matter how many parentheses you remove from the argument list or how many colons you slap on bare-words.
To understand a lot of Ruby code out there, you need to wrap your head around concepts like functional programming, metaprogramming, and domain-specific languages.
I would have said "blocks, string eval monkeypatching, and vigorous self-handshaking by people far too awesome to write mere APIs". Of those, blocks are the only interesting concept.
Slashdot Mirror
It would be possible to extrapolate that Python's gaining popularity relative to Perl over time as companies migrate Perl code to Python code, but the job statistics don't show a decline in Perl and corresponding gains in Python.
Per my reading of the job trends, they prove that such a replacement is indeed not happening in significant volume.
Have you ever seen this work? Me neither.
Oh. Hm. Have you ever seen this work on anything more (let's say) pragmatic than a binary heap?
That's one component of popularity, however.
There's an interesting book you should read. I forget the name, but it's about how to improve the design of existing code.
Funny, most novelists don't.
Perhaps that subset of Linux known as x86 has fine support, but the last time I looked, PPC Linux (for example) had no support from NVidia. Synecdoche does not make for accurate engineering.
Eclipse should seem plenty familiar to anyone who used VisualAge, however.
With all of Microsoft's preloading deals and the almost unavoidable Windows tax and a growing market for new computers, Vista only has a 6 to 7% share?
That is how you make the argument.
... or find new markets or sources of income, such as DVD sales and Internet distribution.
This raises three questions. First, if (as the argument goes) a DVD boxed set with commentary from the writers and producers and showrunner is worth more than a DVD boxed set without that commentary, why does the studio ask the writers and producers and showrunner to contribute their work in making that commentary for free?
Second, if Internet distribution really isn't making any money, why are the studios doing it?
Third, if Internet distribution is an investment which the studios hope will make money, what's the harm in giving writers residuals as a percentage of revenue? If it doesn't work, the studios aren't out anything. If it does work, it's the same recompense system as any other form of distribution: small screen, rentals, DVD sales, big screen, syndication, etc.
The problem is that there's now a system in which creators can bypass all of the middlemen (studios, distributors) and reach their audiences directly. The studios don't like that and want to bypass everyone else (creators, distributors).
First Life?
If you had read my posts with any degree of caution whatsoever, you would have noticed that I was very careful to suggest that only a small portion of the entire Ruby community exhibits this behavior.
I apologize for the second reply, but I just found the post which amused me the most. To wit:
— Cosine Jeremiah, Back to Perl.
For fun, try to find out what he means by "DSL".
Why Use a Language-Powered Domain Specific Language?, by Cosine Jeremiah, or Knowing Ruby and Perl for an even better example.
Cosine didn't use the word invented specifically, but my claim is that there is a very vocal coterie in the Ruby community that seems to pride itself on slapping new names on old, old practices and parading them around as if they were new.
I can't see how. Just about every language I've used that supports functions allows you to define your own functions of variadic arity. The semantics are "functions take arguments", and you don't get much choice of whether you pass by reference or value, for example, or whether arity is fixed or checked at compile time or types are checked or what.
... except for languages such as Perl, Smalltalk, PHP, Lisp, Scheme, and I believe Python and Tcl. This list is not exhaustive.
It's amusing and a little disturbing to see all of the fervor in some parts of the Ruby community as if they'd invented something that the rest of us haven't been doing in several other languages for, in some cases, decades. Me, I'm waiting for them to invent LLDD (linked-list driven development) when they get tired of BDD. (I suppose you can link a list of test cases to the desired external non-programmer behavior of a project.)
If it does, it's a closure. If it doesn't, it's not.
Sure there is. If you have to write a parser, you've written a new language -- you're no longer using a subset of the syntax and semantics of the host language. Merely choosing expressive nouns and verbs where the language already allows you to choose nouns and verbs is not creating a DSL. It may be using language specific to the domain, but it's not creating a new language.
Hygenic macros or manipulating the AST directly is closer to the line, but when you can change the actual semantics of the host language, you have something different.
I haven't ever seen a so-called Ruby DSL that actually did anything other than slap meaningful names on method calls and classes.
By that definition, all subroutines that take arguments are closures. I could certainly write a language that implemented them as closures, but that doesn't make them closures per the language's semantics.
Your createErrorReporter does indeed return a closure though.
There's a Ruby implementation on Parrot called Cardinal. It stalled for a while until the Parrot 0.5.0 release in November, but that should have cleared the next few roadblocks.
I've written a few IO-bound applications. C doesn't select(2) measurably faster or slower than Ruby or Perl or Python.
Having read a few discussions of Perl, I have to say "Evidently not."
Programming in Haskell by Graham Hutton is a good introduction to the language. I'm waiting for Real World Haskell too.
Ruby does have first-class lambdas, but the block/proc distinction can be kind of a problem sometimes.
I'm familiar with domain specific languages: m4, regular expressions, procmail. Passing a hash of parameters to a method does not make a DSL. It's an API, no matter how many parentheses you remove from the argument list or how many colons you slap on bare-words.
It is? What does it close over?
I would have said "blocks, string eval monkeypatching, and vigorous self-handshaking by people far too awesome to write mere APIs". Of those, blocks are the only interesting concept.
Im pretty sure it doesn't say anything about the nation of Israel building any pyramids.