The book What Color is Your Parachute? might help. (You don't have to get the latest version; anything recent is fine.)
Re:Perl is not too loose and messy
on
Beyond Java
·
· Score: 1
The language doesn't encourage clean code.
Somehow you managed to write clear and understandable English, a language that 14 year olds all over the world use to write text messages and argue on message boards.
The question is: is Perl becoming a LISP implementation?
No; Perl has syntax.
(Seriously, Perl 5 supports 7.5 or 8 of the 9 distinguishing features of Lisp, lacking mostly sane macros.)
Re:My short experience with perl...
on
What is Perl 6?
·
· Score: 1
I don't know if this is helpful to you, but the particular docs that would have helped are perldsc, the data structures cookbook, and perlref, the references and nested data structures documentation. The table of contents, perltoc lists all of the core documentation.
Re:My short experience with perl...
on
What is Perl 6?
·
· Score: 1
I said "exactly", not "differently". Why'd you replace the square brackets with parentheses?
Re:10 Years Overdue
on
What is Perl 6?
·
· Score: 5, Informative
Over 10 years later, perl 6 is still in beta mode.
Did you read the same article I wrote or is your post from the mysterious future? Larry announced Perl 6 in the summer of 2000.
Re:My short experience with perl...
on
What is Perl 6?
·
· Score: 1
How do you write nested lists such as [[1,2],[3,4],5,[6,7,8]]?
In Perl? Exactly that way. Really, how much did you try?
However, I'm afraid I still have problems with your claim that open source developers and users have nothing in common except open source. I'm not sure whether it's true; more importantly I don't understand why it's relevant.
I don't believe there's a single "open source community". There was a discussion on use Perl; two years ago about Open Source and Egos.
The problem is, among all of the groups of people that might possibly be members of a single open source community, what interesting commonalities are there? You can point to the self-identified Free Software community and make some assumptions about community values and ideals. You can't point to the open source community and say "they are all pragmatists" or "they are all libertarians" or "they all want to beat Windows".
John Mark's argument is that businesses interested in open source should focus more on the economic advantages of open source than the advantages put forth by anyone who points to a mythical community and says "There, that's what these people all care about!" -- because the economic reasons for the successes of open source software are real, yes, but also because they're likely more important to such businesses than the supposed values of the community.
If there is no single open source community with an ideological fence to keep insiders in and outsiders out, then the reason for adopting or not adopting open source depends on the goals and ideals of the potential adopter.
It's not that free software fans don't exist. It's not that software developers don't exist. It's not that Slashdotters don't exist. Hey, I'm a member of all three groups.
I'm not sure how far to take the argument from historical inevitability, but there are some strong social, economic, and historical reasons why free and open source software really started to spread when they did. I don't have a problem with people using open source software because those factors matter to them. I hope they contribute back and I hope the arguments for quality and freedom affect them positively, but I think assuming that they share (or should share) values with an ill-defined community is a mistake.
John Mark's argument is completely different from your facile characterization.
Do you think that, of all the people in the myriad groups that use and develop open source software, there's one single identifying common attribute between them, beyond the fact that they use open source software? Why, some of them don't even know what that means!
Yet more people and businesses use open source software every day. Is it because the adopters come to share the values of the mythical open source community? I don't think so. John Mark doesn't think so.
If that's not true (and it's debatable and that's why I published the article), what other reasons do they have for using open source software?
Explicit variable declarations don't have to include type annotations.
Perl 5's declarations denote the scope of lexical variables, so if the compiler hasn't seen a declaration for a variable in that scope, it can give a warning. (For global variables, the compiler uses the heuristic of counting the number of occurrences of variable names. If there's only one, it's probably a typo.)
I'm using Python 2.4.2. Which version forces people to write small, self-contained functions and methods, to use meaningful and appropriate variable names, to document and comment their code appropriately, to write sufficient and maintainable tests, to eliminate repetition, to factor discrete subsystems into the appropriate modules and classes, and to use source control effectively? Should I wait for 2.4.3 to fix all of my readability and maintainability problems?
Evidently even personal software deployed on single-user virtual hosts has to be enterprise-ready, scalable, mature, and ready for prime time, or something. I guess.
Actually, writing technical books is a terrible way to make a living, when you consider the money earned versus time spent ratio.
Re:Isn't Duke Nukem Forever coded in Perl 6?
on
Larry Wall on Perl 6
·
· Score: 1
If you don't mind working with an alpha version (in terms of features supported), you can try Pugs right now. It's pretty impressive and should be even better with the next release.
There's no official release date nor an official estimate, but when Pugs and Parrot meet in the middle (hopefully within the next couple of releases), things will start moving much more quickly. A feature-complete beta is probably not any closer than a year away, give or take the million things that can go wrong with any big open source project.
If you're a good programmer already and you learn the language, you can maintain the code. Then it doesn't matter if you could read the program before you knew the language. You know the language.
If you don't know how to program, you have no business maintaining the program before you learn to code. It doesn't matter if you think you can read the program.
If you're a good programmer and you suddenly have to maintain a program written in a language you don't know, the learnability of the language is important... but you're still in trouble.
In one job, I had to fix a website for a client developed in ASP with VBScript. I don't know VBScript, but it was close enough to other languages I knew so that I could stumble through a book and figure out just enough to fix things. It wasn't a brilliant solution and it probably wasn't even the optimal solution, but it worked. Still, it was a bad situation.
I think it was only VBScript's similarity to other languages I'd used (and my familiarity with web programming at that point) that made it possible to fix the bugs. If it had been another language designed for human readability (COBOL, for a totally unfair example, or AppleScript), I'm not sure the readability of the language would have helped at all.
Fortunately, the client only needed that little bugfix and I didn't have to learn VBScript and ASP to keep supporting them. Sure, my rule about not maintaining code in a language you don't know is an ideal rule and you can't always avoid it, but if people stuck with it we might be in a lot less trouble code-wise.
Slashdot Mirror
Stig Brautaset recently wrote about Testing C with Libtap.
The book What Color is Your Parachute? might help. (You don't have to get the latest version; anything recent is fine.)
Somehow you managed to write clear and understandable English, a language that 14 year olds all over the world use to write text messages and argue on message boards.
If I disagree, does that prove your point or rebut it? Is this a free-market version of the Hegelian paradox?
How does investing it take it out of circulation?
Fortunately, the article answers that question.
That's what Parrot's NCI layer does. It's a foreign function interface to shared libraries. It's much nicer than Perl 5's XS.
Mono has lingering patent questions. Parrot doesn't. That's a strong point in favor of Parrot.
No; Perl has syntax.
(Seriously, Perl 5 supports 7.5 or 8 of the 9 distinguishing features of Lisp, lacking mostly sane macros.)
I don't know if this is helpful to you, but the particular docs that would have helped are perldsc, the data structures cookbook, and perlref, the references and nested data structures documentation. The table of contents, perltoc lists all of the core documentation.
I said "exactly", not "differently". Why'd you replace the square brackets with parentheses?
Did you read the same article I wrote or is your post from the mysterious future? Larry announced Perl 6 in the summer of 2000.
In Perl? Exactly that way. Really, how much did you try?
I don't believe there's a single "open source community". There was a discussion on use Perl; two years ago about Open Source and Egos.
The problem is, among all of the groups of people that might possibly be members of a single open source community, what interesting commonalities are there? You can point to the self-identified Free Software community and make some assumptions about community values and ideals. You can't point to the open source community and say "they are all pragmatists" or "they are all libertarians" or "they all want to beat Windows".
John Mark's argument is that businesses interested in open source should focus more on the economic advantages of open source than the advantages put forth by anyone who points to a mythical community and says "There, that's what these people all care about!" -- because the economic reasons for the successes of open source software are real, yes, but also because they're likely more important to such businesses than the supposed values of the community.
If there is no single open source community with an ideological fence to keep insiders in and outsiders out, then the reason for adopting or not adopting open source depends on the goals and ideals of the potential adopter.
It's not that free software fans don't exist. It's not that software developers don't exist. It's not that Slashdotters don't exist. Hey, I'm a member of all three groups.
I'm not sure how far to take the argument from historical inevitability, but there are some strong social, economic, and historical reasons why free and open source software really started to spread when they did. I don't have a problem with people using open source software because those factors matter to them. I hope they contribute back and I hope the arguments for quality and freedom affect them positively, but I think assuming that they share (or should share) values with an ill-defined community is a mistake.
John Mark's argument is completely different from your facile characterization.
Do you think that, of all the people in the myriad groups that use and develop open source software, there's one single identifying common attribute between them, beyond the fact that they use open source software? Why, some of them don't even know what that means!
Yet more people and businesses use open source software every day. Is it because the adopters come to share the values of the mythical open source community? I don't think so. John Mark doesn't think so.
If that's not true (and it's debatable and that's why I published the article), what other reasons do they have for using open source software?
Did you read the same article I published?
Explicit variable declarations don't have to include type annotations.
Perl 5's declarations denote the scope of lexical variables, so if the compiler hasn't seen a declaration for a variable in that scope, it can give a warning. (For global variables, the compiler uses the heuristic of counting the number of occurrences of variable names. If there's only one, it's probably a typo.)
I miss that behavior in both Python and Ruby.
That has nothing to do with the type system. Perl has a dynamic type system yet can catch those errors.
I'm using Python 2.4.2. Which version forces people to write small, self-contained functions and methods, to use meaningful and appropriate variable names, to document and comment their code appropriately, to write sufficient and maintainable tests, to eliminate repetition, to factor discrete subsystems into the appropriate modules and classes, and to use source control effectively? Should I wait for 2.4.3 to fix all of my readability and maintainability problems?
Don't forget make!
Because the language designer probably doesn't know as much about your team and the problems you're trying to solve as you do.
Evidently even personal software deployed on single-user virtual hosts has to be enterprise-ready, scalable, mature, and ready for prime time, or something. I guess.
Actually, writing technical books is a terrible way to make a living, when you consider the money earned versus time spent ratio.
If you don't mind working with an alpha version (in terms of features supported), you can try Pugs right now. It's pretty impressive and should be even better with the next release.
There's no official release date nor an official estimate, but when Pugs and Parrot meet in the middle (hopefully within the next couple of releases), things will start moving much more quickly. A feature-complete beta is probably not any closer than a year away, give or take the million things that can go wrong with any big open source project.
Hm, I didn't type my full thought.
If you're a good programmer already and you learn the language, you can maintain the code. Then it doesn't matter if you could read the program before you knew the language. You know the language.
If you don't know how to program, you have no business maintaining the program before you learn to code. It doesn't matter if you think you can read the program.
If you're a good programmer and you suddenly have to maintain a program written in a language you don't know, the learnability of the language is important... but you're still in trouble.
In one job, I had to fix a website for a client developed in ASP with VBScript. I don't know VBScript, but it was close enough to other languages I knew so that I could stumble through a book and figure out just enough to fix things. It wasn't a brilliant solution and it probably wasn't even the optimal solution, but it worked. Still, it was a bad situation.
I think it was only VBScript's similarity to other languages I'd used (and my familiarity with web programming at that point) that made it possible to fix the bugs. If it had been another language designed for human readability (COBOL, for a totally unfair example, or AppleScript), I'm not sure the readability of the language would have helped at all.
Fortunately, the client only needed that little bugfix and I didn't have to learn VBScript and ASP to keep supporting them. Sure, my rule about not maintaining code in a language you don't know is an ideal rule and you can't always avoid it, but if people stuck with it we might be in a lot less trouble code-wise.