Ok, I actually do use perl professionally, but even I realize there are some serious problems with it. The reality is a middle ground between you and the grandparent.
But we also expected we'd have that around 2005.
You were expecting it the same year the very first implementation (Pugs) was started? That was silly of you.
Pugs was started in 2005 as an attempt to inject life into what looked like a dying project. The language spec started in 2000. In five years they hadn't nailed it down. In ten years there still isn't a working implementation.
It's nearly 2010, and we still don't see much real progress on that front. Rakudo just isn't a production-grade product yet.
Unless lives are at risk, Rakudo is stable enough for production (although you may want to wait for the April "Rakudo Star" release).
That is EXTREMELY wishful thinking. It may have changed in the last couple months, but I tried this perl 6 code out earlier in the summer: my $blah = "blah"; $blah = $blah.reverse; print $blah;
and that SIMPLE code resulted in an infinite recursion error.
I'm sad to admit it, but instead of waiting for incremental Perl 5 releases for the next decade until Perl 6 is finally mature enough
Perl 6 != Perl 5. They are two VERY different languages. Perl 5 and 6 will continue to be maintained in parallel.
Perl 5 has problems inherent with the language that inhibit large scale use, and this is coming from someone who works on a multi-million line perl 5 project. Recent frameworks have tried to address the problems by grafting perl6 like features onto perl5, but they always impact performance, and are never perfect. And goddammit, I've still found no way around the broken behavior of the SUPER keyword.
until Perl 6 is finally mature enough, the company I'm with has started to migrate from Perl to Python.
You're complaining about maturity and yet you're using Python?
Unlike the Perl community, the Python community has shown with Python 3 that they're capable of working together to create a major release with many new features in a relatively short amount of time (especially compared to the Perl 6 effort).
Perl 6 has many, many more changes than Python 3. It is an entire rewrite of the language from the ground up, they didn't just change the print statement to a function and call it a day.
Rewriting our approximately 3 million lines of Perl code into Python has actually gone reasonably well.
That would have been what, 6 million lines in Python? Now I know you're trolling.
You're being a bit unfair to Python. I'm not a huge fan of the language (if I had to move anywhere it'd be ruby), but python 3 while it didn't change much in the language itself, was a huge boost in performance to the interpreter. There are incremental changes happening to the perl5 interpreter, but nothing major structural can, because the codebase just isn't very maintainable. In fact that was one of the main reasons they decided to scrap it and develop parrot from scratch instead of working from the perl5 base. Try embedding the python interpreter and the perl5 interpreter in a C program, see which one has internals that make more sense.
Not to mention that python is immensely more parsable. There are identical python interpreters in C, on the JVM, and on the CLR. Its been said that the only thing that can parse perl5 is perl5, and that is evidenced by the fact that the parrot project gave up on implementing a perl5 parser.
That's not to say there aren't things python does wrong. Every time there's a point release it seems everyone's code completely breaks, while perl5 is backward compatible to perl1. And frankly, I hate significant whitespace, but that's a personal preference.
Regardess things are not completely happy in the perl world.
Its not an indication of anything. 5.11 is a development branch. In theory it should be released the moment they implement one feature that doesn't belong in 5.10.
If you're referring to the subway, not Metro North, then no, there isn't a schedule. Trains run every 8 minutes. If they were to try and make a schedule with 8 minute intervals, any delays (which are inevitable, its a huge system) would quickly throw that out of what completely. Instead of late trains waiting for the next 8 minute interval, they just leave as soon as they can. New Yorkers know that if you miss a train, the next one isn't that far off.
If you are talking about Metro North like they were in the article, then you weren't looking hard enough. Grand Central has big lit up boards with all the schedules, and pampheletes all over the place. Those trains run once an hour. There a schedule is necessary. With the subway, not so much.
The REST model is probably a good thing, but HTTP doesn't type your parameters, doesn't allow datastructures more complex than key value pairs, and doesn't do input validation. In most cases where I've seen people using HTTP as a REST mechanism, they end up needing complex data, and end up sending... *drumroll*... blocks of XML! Unspec'd, incompatible, app specific XML layouts. SOAP isn't the answer, but it solved some problems very well that HTTP doesn't even approach.
This is the problem with modern business methodology. Engineers do cost-benefit analysis also, but not with monetary cost. Every design decision in a piece of software is a balance of how much cpu time does this save me vs. how much memory does this eat up vs. how much complexity does it add to my system, etc.
But before cost-benefit analysis even begins, problems to be solved are classified by their risk. There is a class of problems that absolutely must be solved regardless of the cost. If you're writing a filesystem, anything that has the remotest chance of data loss is unacceptable, regardless of how slow it is. If one of these crucial elements costs too much for the system to handle, take out something else.
A large number of businesses don't seem to see anything as unacceptable risk. Medical companies, car manufacturers, baby toy manufacturers, etc. consider anything that could possibly cause loss of human life an unacceptable risk. Banks and retailers should treat anything with the remotest possibility of leakage of customer data a must fix problem, and this means IT security should get done, regardless of cost.
A perl6 *interpreter* was written in haskell, and it's considered a non-performance oriented reference implementation, purely for exploring the perl6 syntax. No one has ever doubted that interpreters and compilers are easier to do in functional languages. One of the things you learn first when you take a class in lisp is a recursive descent parser. But the version of perl6 that's expected to acutally perform? Parrot is written in C. The fact that its no where near done is a completely different matter...
I don't know how often the oppressive rules "internal security" fanatics actually cause, but they do drive away employees. The job I had before this one treated every employee like a suspect. It was a small company, so the owner could get away with a level of paranoia that would be impractical in a larger organization.
Each of the dev rooms had web cams trained on all the engineers, which the owner would actually watch (no joke, he'd pull you in at the end of the day and tell you "I see around 3:20 you were staring off into space for a few minutes, why weren't you working?"). The dev network was on a completely disconnected network, with no removable media on any machines. If you wanted to bring any file into the network, you had to personally ask the owner for permission, and he usually said no. If you wanted to bring a file out of the network, well, you couldn't.
Everyone there had developed a sense of fear that anything tiny little thing they did could cause all hell to break loose. After a month of looking over my shoulder every five minutes, I quit. I wasn't the first. And the owner couldn't understand why he had such a turnaround, but was convinced if he wasn't careful, a single disgruntled employee could steal all his IP.
Take a look at any tech employment site. Look at the number of openings for jsp, ejb, struts, jboss, weblogic, whatever java technology of the week developer jobs there are. Java's been the dominant non-ms way of doing web dev for a while now.
And no, I don't have hard numbers to back that claim. I just know that I don't personally like working with java (I know it, I've done it professionally, I just don't like it), and its becoming harder and harder to find server side unix work without it.
I worked at amazon for two years. I never saw any use of Haskel, SML or any other functional language. 90% of all work at amazon is some combination of C++ and Perl, with a few groups trying to transition to Java.
Re:My short experience with perl...
on
What is Perl 6?
·
· Score: 1
Ok, I love perl, but I understand where this confusion comes from. In perl, a list and an array are not the same thing. You can consider a list somewhat like a constant array. An array is always a variable (or a reference to a variable). A list is always a value (that's usually assigned to an array).
Thing is, a list (or the value of an array) is always a list of scalars, so you're right, perl does flatten lists. But elements of a list can be references to arrays. (a,b,c) denotes a list, while [a,b,c] denotes a reference to an anonymous array.
This seems stupid until you realize that perl is smart enough to treat a reference to an array, and an array itself as near to the same thing. Its logic taken from C (for better or worse).
So: $arrayref = [[1,2],[3,4],[5],[6,7,8]];
gives you exactly what you want. $arrayref is a reference to the array that contains references to the sub arrays. Just like when you malloc a pointer to a block of memory in C, treat it as an array, and fill the elements of that array with pointers to other arrays.
If you're treating this as a "pure" high level language, yes, it's fucked. But it's the only high level language that gave me the power I missed from C.
No, what this means is that of the people who want to hack on the X source code, 99% were unable to get into it because of the interdependant mess that the code was, and the inabillity for most people to commit back.
Now 99% of the people who want to hack on X will be able to find a small isolated module to start on. And now those modules may be able to evolve without breaking the whole. I've wanted to hack at X for a long time, now I very well might.
Not sure about the others, but the perl binding in eclipse is auful. Absolutely minimal syntax hylighting, the project manager doesn't quite work right with perl, auful debugger integration, and none of the introspection features you get with java (admittedly because it's damn hard to do them with perl). It effectively becomes an incredibly bloated notepad.
Is it because these are all low energy, stable compounds that commonly form from random processes. Most "organic" compounds are high energy compounds that are usually (though not always) produced by life processes. Organic compounds all break down into the ones you listed.
On the other hand I'm not a chemist so this is just a guess.
I've been burned repeatedly in multiple production environments with recent (as of the beginning of this year) and every reiser installation has failed. This isn't annecdotal "yeah I used it once on questionable hardware and it didn't work right" evidence. This is "I had 18 storage servers storing 125 million files apiece on decent SCSI raid cards with enterprise quality disks, and every one of them was corrupted within eight months, while the 6 using ext3 (because they weren't as many small files) were completely fine". Reiser3's performance for lots of small files beats everything else out there, even some dedicated storage systems like NetApps, but it trades any semblance of data integrity to achieve this. I'm afraid to even try Reiser4 if this is the kind of software Hans Reiser puts out as stable.
At the place I work for which shall remain nameles, we set up several Reiser3 file servers to store a few terabytes of data. We chose reiser3 because the data is in lots of small files and Reiser4 wasn't stable yet. Within a year all six of the storage servers (all mirrors of each other) had shown severe corruption, 3 of them catastrophic (filesystem wasn't useable at all). One of the guys on the team looked at the corrupted data and found kernel stacks dumped into filesystem structure blocks. The only thing we could do was to reformat the downed machines and copy data from an intact one. This kept us alive until we got funding for a real storage system (NetApp Filers).
Um, no. SOAP was proposed to the W3C by a consortium that included HP, IBM and Microsoft, and most reporting on the matter has MS as the driving force in that. You may be thinking of XML-RPC, which SOAP is based on.
And yes I know web services did exist. They weren't big business. Most of the push of.NET was to make web services big business (in fact they were pushing them as the core of future development). They failed because the web services MS provided at first were really bad (think Passport). Soon, every other platform out there adopted the protocols MS drafted, and made web services useful.
The thing I find the funniest about all of these articles talking about web services being microsoft's downfall, is how much microsoft pushed web services in the beginning. Anyone remember that whole.NET thing? One of the core aspects of that was web services. In fact ms was the company that laid out the SOAP standard. They must really have lost control of that ball, because now anyone you hear about doing web services is probably doing it with Java.
So the question becomes, which was the stupider mistake for ms, starting the whole web services thing rolling, or losing control of it shortly thereafter?
Slashdot Mirror
Ok, I actually do use perl professionally, but even I realize there are some serious problems with it. The reality is a middle ground between you and the grandparent.
But we also expected we'd have that around 2005.
You were expecting it the same year the very first implementation (Pugs) was started? That was silly of you.
Pugs was started in 2005 as an attempt to inject life into what looked like a dying project. The language spec started in 2000. In five years they hadn't nailed it down. In ten years there still isn't a working implementation.
It's nearly 2010, and we still don't see much real progress on that front. Rakudo just isn't a production-grade product yet.
Unless lives are at risk, Rakudo is stable enough for production (although you may want to wait for the April "Rakudo Star" release).
That is EXTREMELY wishful thinking. It may have changed in the last couple months, but I tried this perl 6 code out earlier in the summer:
my $blah = "blah";
$blah = $blah.reverse;
print $blah;
and that SIMPLE code resulted in an infinite recursion error.
I'm sad to admit it, but instead of waiting for incremental Perl 5 releases for the next decade until Perl 6 is finally mature enough
Perl 6 != Perl 5. They are two VERY different languages. Perl 5 and 6 will continue to be maintained in parallel.
Perl 5 has problems inherent with the language that inhibit large scale use, and this is coming from someone who works on a multi-million line perl 5 project. Recent frameworks have tried to address the problems by grafting perl6 like features onto perl5, but they always impact performance, and are never perfect. And goddammit, I've still found no way around the broken behavior of the SUPER keyword.
until Perl 6 is finally mature enough, the company I'm with has started to migrate from Perl to Python.
You're complaining about maturity and yet you're using Python?
Unlike the Perl community, the Python community has shown with Python 3 that they're capable of working together to create a major release with many new features in a relatively short amount of time (especially compared to the Perl 6 effort).
Perl 6 has many, many more changes than Python 3. It is an entire rewrite of the language from the ground up, they didn't just change the print statement to a function and call it a day.
Rewriting our approximately 3 million lines of Perl code into Python has actually gone reasonably well.
That would have been what, 6 million lines in Python? Now I know you're trolling.
You're being a bit unfair to Python. I'm not a huge fan of the language (if I had to move anywhere it'd be ruby), but python 3 while it didn't change much in the language itself, was a huge boost in performance to the interpreter. There are incremental changes happening to the perl5 interpreter, but nothing major structural can, because the codebase just isn't very maintainable. In fact that was one of the main reasons they decided to scrap it and develop parrot from scratch instead of working from the perl5 base. Try embedding the python interpreter and the perl5 interpreter in a C program, see which one has internals that make more sense.
Not to mention that python is immensely more parsable. There are identical python interpreters in C, on the JVM, and on the CLR. Its been said that the only thing that can parse perl5 is perl5, and that is evidenced by the fact that the parrot project gave up on implementing a perl5 parser.
That's not to say there aren't things python does wrong. Every time there's a point release it seems everyone's code completely breaks, while perl5 is backward compatible to perl1. And frankly, I hate significant whitespace, but that's a personal preference.
Regardess things are not completely happy in the perl world.
Its not an indication of anything. 5.11 is a development branch. In theory it should be released the moment they implement one feature that doesn't belong in 5.10.
Huh, so there is. Looking at it, it has absolutely no bearing on reality, at least with regard to my line (the A).
If you're referring to the subway, not Metro North, then no, there isn't a schedule. Trains run every 8 minutes. If they were to try and make a schedule with 8 minute intervals, any delays (which are inevitable, its a huge system) would quickly throw that out of what completely. Instead of late trains waiting for the next 8 minute interval, they just leave as soon as they can. New Yorkers know that if you miss a train, the next one isn't that far off.
If you are talking about Metro North like they were in the article, then you weren't looking hard enough. Grand Central has big lit up boards with all the schedules, and pampheletes all over the place. Those trains run once an hour. There a schedule is necessary. With the subway, not so much.
You mean like Mason? Possibly you're looking for something more like Catalyst?
These things have been available for Perl for a long time.
But, your window manager doesn't run as root. And themes have to be installed by the end user. This is no less secure that just using a browser.
The overhead could be ridiculous, sure, but this just isn't a security problem.
The REST model is probably a good thing, but HTTP doesn't type your parameters, doesn't allow datastructures more complex than key value pairs, and doesn't do input validation. In most cases where I've seen people using HTTP as a REST mechanism, they end up needing complex data, and end up sending ... *drumroll* ... blocks of XML! Unspec'd, incompatible, app specific XML layouts. SOAP isn't the answer, but it solved some problems very well that HTTP doesn't even approach.
This is the problem with modern business methodology. Engineers do cost-benefit analysis also, but not with monetary cost. Every design decision in a piece of software is a balance of how much cpu time does this save me vs. how much memory does this eat up vs. how much complexity does it add to my system, etc.
But before cost-benefit analysis even begins, problems to be solved are classified by their risk. There is a class of problems that absolutely must be solved regardless of the cost. If you're writing a filesystem, anything that has the remotest chance of data loss is unacceptable, regardless of how slow it is. If one of these crucial elements costs too much for the system to handle, take out something else.
A large number of businesses don't seem to see anything as unacceptable risk. Medical companies, car manufacturers, baby toy manufacturers, etc. consider anything that could possibly cause loss of human life an unacceptable risk. Banks and retailers should treat anything with the remotest possibility of leakage of customer data a must fix problem, and this means IT security should get done, regardless of cost.
A perl6 *interpreter* was written in haskell, and it's considered a non-performance oriented reference implementation, purely for exploring the perl6 syntax. No one has ever doubted that interpreters and compilers are easier to do in functional languages. One of the things you learn first when you take a class in lisp is a recursive descent parser. But the version of perl6 that's expected to acutally perform? Parrot is written in C. The fact that its no where near done is a completely different matter...
I don't know how often the oppressive rules "internal security" fanatics actually cause, but they do drive away employees. The job I had before this one treated every employee like a suspect. It was a small company, so the owner could get away with a level of paranoia that would be impractical in a larger organization.
Each of the dev rooms had web cams trained on all the engineers, which the owner would actually watch (no joke, he'd pull you in at the end of the day and tell you "I see around 3:20 you were staring off into space for a few minutes, why weren't you working?"). The dev network was on a completely disconnected network, with no removable media on any machines. If you wanted to bring any file into the network, you had to personally ask the owner for permission, and he usually said no. If you wanted to bring a file out of the network, well, you couldn't.
Everyone there had developed a sense of fear that anything tiny little thing they did could cause all hell to break loose. After a month of looking over my shoulder every five minutes, I quit. I wasn't the first. And the owner couldn't understand why he had such a turnaround, but was convinced if he wasn't careful, a single disgruntled employee could steal all his IP.
Take a look at any tech employment site. Look at the number of openings for jsp, ejb, struts, jboss, weblogic, whatever java technology of the week developer jobs there are. Java's been the dominant non-ms way of doing web dev for a while now.
And no, I don't have hard numbers to back that claim. I just know that I don't personally like working with java (I know it, I've done it professionally, I just don't like it), and its becoming harder and harder to find server side unix work without it.
Some market niche meaning...the vast majority of server side web development right now?
I worked at amazon for two years. I never saw any use of Haskel, SML or any other functional language. 90% of all work at amazon is some combination of C++ and Perl, with a few groups trying to transition to Java.
Ok, I love perl, but I understand where this confusion comes from. In perl, a list and an array are not the same thing. You can consider a list somewhat like a constant array. An array is always a variable (or a reference to a variable). A list is always a value (that's usually assigned to an array).
Thing is, a list (or the value of an array) is always a list of scalars, so you're right, perl does flatten lists. But elements of a list can be references to arrays. (a,b,c) denotes a list, while [a,b,c] denotes a reference to an anonymous array.
This seems stupid until you realize that perl is smart enough to treat a reference to an array, and an array itself as near to the same thing. Its logic taken from C (for better or worse).
So:
$arrayref = [[1,2],[3,4],[5],[6,7,8]];
gives you exactly what you want. $arrayref is a reference to the array that contains references to the sub arrays. Just like when you malloc a pointer to a block of memory in C, treat it as an array, and fill the elements of that array with pointers to other arrays.
If you're treating this as a "pure" high level language, yes, it's fucked. But it's the only high level language that gave me the power I missed from C.
No, what this means is that of the people who want to hack on the X source code, 99% were unable to get into it because of the interdependant mess that the code was, and the inabillity for most people to commit back.
Now 99% of the people who want to hack on X will be able to find a small isolated module to start on. And now those modules may be able to evolve without breaking the whole. I've wanted to hack at X for a long time, now I very well might.
Not sure about the others, but the perl binding in eclipse is auful. Absolutely minimal syntax hylighting, the project manager doesn't quite work right with perl, auful debugger integration, and none of the introspection features you get with java (admittedly because it's damn hard to do them with perl). It effectively becomes an incredibly bloated notepad.
Is it because these are all low energy, stable compounds that commonly form from random processes. Most "organic" compounds are high energy compounds that are usually (though not always) produced by life processes. Organic compounds all break down into the ones you listed.
On the other hand I'm not a chemist so this is just a guess.
I've been burned repeatedly in multiple production environments with recent (as of the beginning of this year) and every reiser installation has failed. This isn't annecdotal "yeah I used it once on questionable hardware and it didn't work right" evidence. This is "I had 18 storage servers storing 125 million files apiece on decent SCSI raid cards with enterprise quality disks, and every one of them was corrupted within eight months, while the 6 using ext3 (because they weren't as many small files) were completely fine". Reiser3's performance for lots of small files beats everything else out there, even some dedicated storage systems like NetApps, but it trades any semblance of data integrity to achieve this. I'm afraid to even try Reiser4 if this is the kind of software Hans Reiser puts out as stable.
Slight nitpick, order of magnitude check. Estimates of the earth's age are around 4 billion years. Dinosaur bones are around 60 million years old.
Beginning of this year?
At the place I work for which shall remain nameles, we set up several Reiser3 file servers to store a few terabytes of data. We chose reiser3 because the data is in lots of small files and Reiser4 wasn't stable yet. Within a year all six of the storage servers (all mirrors of each other) had shown severe corruption, 3 of them catastrophic (filesystem wasn't useable at all). One of the guys on the team looked at the corrupted data and found kernel stacks dumped into filesystem structure blocks. The only thing we could do was to reformat the downed machines and copy data from an intact one. This kept us alive until we got funding for a real storage system (NetApp Filers).
I won't trust ReiserFS again.
It also has a tendency to corrupt your data under heavy use (talking personal experience here).
To prove my point:c net
http://news.com.com/2100-1001-231478.html?legacy=
Um, no. SOAP was proposed to the W3C by a consortium that included HP, IBM and Microsoft, and most reporting on the matter has MS as the driving force in that. You may be thinking of XML-RPC, which SOAP is based on.
.NET was to make web services big business (in fact they were pushing them as the core of future development). They failed because the web services MS provided at first were really bad (think Passport). Soon, every other platform out there adopted the protocols MS drafted, and made web services useful.
And yes I know web services did exist. They weren't big business. Most of the push of
The thing I find the funniest about all of these articles talking about web services being microsoft's downfall, is how much microsoft pushed web services in the beginning. Anyone remember that whole .NET thing? One of the core aspects of that was web services. In fact ms was the company that laid out the SOAP standard. They must really have lost control of that ball, because now anyone you hear about doing web services is probably doing it with Java.
So the question becomes, which was the stupider mistake for ms, starting the whole web services thing rolling, or losing control of it shortly thereafter?