Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Re: Re: Teach him a lesson with facts

by Anonymous Monk
on Feb 23, 2003 at 01:48 UTC ( #237831=note: print w/replies, xml ) Need Help??


in reply to Re^2: Teach him a lesson with facts
in thread Teach him a lesson with facts

Agreed. There are lots of facts we need to consider. My original post was not focused on the speed thing, if you read it again, it is just one example, which was exggerated during the discussion/dispution.

I definitely agree that all what you mentioned are very important to a project: efficiency (I believe you mean the efficiency of development), robustness, maintainability and portability etc.

Let's narrow down the scope of our comparason, only talk about Java and perl. For all those what you mentioned, which I agreed, Java delivers them in a more graceful way.

Let's again narrow down to maintainability. I don't quite agree with you, that Perl code is (easy) maintainable, on the contrary, There are couple of big things really hurt Perl's maintainability:
  1. Perl's scope is getting better, but still very prime, and hacked (this is one thing I really hate about Perl, Perl has too much hacked pacthes and concepts, it almost become a daily routine in Perl, why don't they think in a systematic way??? largely because Perl is building on a poorly defined foundation!)
  2. Perl's OO is hacked, which hurts modulization that is a main contributor to maintainability in all modern languages.
  3. perl is not a stable language, it is still RADICALLY (don't read this sentence without this word) evolving, and many times, that is done by hacking. There is a delimer for Perl, because the original design of this language is flawed, you have to either radically modify it, or to keep it familiar but with lots of hacking.
  4. The so called perlish style does not agree with maintainability at all, hope we at least agree with each other on this.
I can go on and on, but back to the point, I don't agree that perl code is easily maintainable. That's not determined by Perl programmer's capability, it is really a built-in defect of Perl.

This made lots of people feel difficult to consider Perl seriously in a project.
  • Comment on Re: Re: Re: Teach him a lesson with facts

Replies are listed 'Best First'.
Re^4: Teach him a lesson with facts
by adrianh (Chancellor) on Feb 23, 2003 at 03:30 UTC
    Perl's scope is getting better, but still very prime, and hacked (this is one thing I really hate about Perl, Perl has too much hacked pacthes and concepts, it almost become a daily routine in Perl, why don't they think in a systematic way??? largely because Perl is building on a poorly defined foundation!)

    Some examples please. Perl is pretty consistant in it's structure in my opinion, certainly not radicallly inconsistant compared to other languages. The lack of a defined foundation can be considered an advantage. Perl shamelessly steals interesting things from other languages. Perl6 is carrying on this tradition. I far prefer useful functionality to theoretical purity.

    Perl's OO is hacked, which hurts modulization that is a main contributor to maintainability in all modern languages.

    This is arguable. It lacks useful things like direct support for private methods/attributes. However, these can be implemented using other language features. It's rarely an issue in real world code in my experience.

    Perl's OO also gives you a lot of flexibility in your OO models - witness things like Class::Delegation and Class::Contract.

    You can make arguments about Java's OO too (lack of generic classes, lack of multiple implementation inheritance, non-OO base types, etc.).

    Again, these are arguable points (well, except for generic classes - not having those was insane and will be fixed in the next version :-) There are good reasons for non-OO base types and interfaces - but there are also disadvantages.

    perl is not a stable language, it is still RADICALLY (don't read this sentence without this word) evolving, and many times, that is done by hacking. There is a delimer for Perl, because the original design of this language is flawed, you have to either radically modify it, or to keep it familiar but with lots of

    Completely disagree. Perl has been remarkably stable. I've still got perl4 scripts running unchanged in perl 5.8. It has certainly evolved, but it's kept compatability to a remarkable degree.

    Java has gone through a lot of changes too since it was first released and is still having major features added (witness the proposed addition of generic classes to the next version.) I've had people working on projects where they have had to completely gut elements due to changes in the "standard" libraries :-)

    4. The so called perlish style does not agree with maintainability at all, hope we at least agree with each other on this.

    I can go on and on, but back to the point, I don't agree that perl code is easily maintainable. That's not determined by Perl programmer's capability, it is really a built-in defect of Perl.

    Again, I beg to differ ;-)

    Its language independent. I've seen a lot of terrible perl code. I have also seen a lot of terrible C, C++, Java, insert-language-of-choice code. I've seen great perl code. I've also seen great C++, C, even assembler. Bad programmers write bad code. Period.

    Now, you can make an argument that it is easier to write bad code in perl than it is in some other languages. Personally I'm undecided on that issue. However, in my opinion, even if this is true it is part of the price you pay in having a flexible language that enables a good programmer to produce good code in a timely manner.

    This is why many people can and do use perl for serious commercial projects.

    I've not chosen to use perl for fun (well, not just for fun :-). Fun doesn't pay my rent.

    I've used it because it's a useful language. I've used it because people pay me to use it. Whether that be because they have existing perl code that is doing its job very well, or because it is easier (aka cheaper) to develop a solution in perl than any other language. I've used it because some CPAN modules cut development time to almost nothing compared to Java/C++/whatever (try an API with multiple-database support as good as DBI in another language).

    I don't think perl is a silver bullet. I don't use it for everything. I don't recommend it for everything. I've even regretted using it on occasion. The same applies to every other language. There is no silver bullet.

    You use the right tool for the right job. Perl can be that tool a great deal of the time.

      Fair enough. This is what I like to hear (you don't need to feel favorable towards some one's comment because you agree with him. You can feel really like it, as long as it is logical, even if you disagree with it), and this is kind of perl monk I would respect.

      What I hate the most is to see those fundamentalist's thought, which I have seen again and again here.

      It is harmful for people to blindly recommend Perl to others, especially here. I am not saying this is a useless site. I am saying, from time to time, I saw, because of the XP point system, troll-like ideas (I don't call people troll) prevails any way.
Re: Re: Re: Re: Teach him a lesson with facts
by hardburn (Abbot) on Feb 23, 2003 at 05:16 UTC

    why don't they think in a systematic way???

    Perl is a very practical language. There are plenty of times where, reading the docs, I've thought "why did they do it that way?" Then when I got to actually using the thing, it suddenly saw that doing it that specific way made coding a lot easier, and said "Ahh, that's why it works that way!"

    So if it doesn't appear systematic, it's only because we don't live in a systematic world.

    Perl's OO is hacked

    Yes, it is. But did you also know that adding OO to Perl required defining precisely zero new syntax to the language? Which brings me to this:

    There is a delimer for Perl, because the original design of this language is flawed, you have to either radically modify it, or to keep it familiar but with lots of hacking.

    Not needing any new syntax for OO is a direct counterexample to this. By the time people started looking for OO to be added to Perl, closures, lexically scoped variables, packages, and referances were already in the language. These things comprise the building blocks of Perl OO (and probably a few other things I can't think of ATM). I think bless() had to be added, but that's a builtin subroutine, not new syntax.

    The so called perlish style does not agree with maintainability at all, hope we at least agree with each other on this.

    Are you talking about obfu/golf? If so, you're looking at the wrong place. Nobody is (should) be writing Perl that way for real programs. Look around this site, for instance. The community here hates it when people post code that isn't using strict and warnings--two ideas that generally get in the way of obfu/golf.

    It is perfectly reasonable to write Perl code that looks just as pretty as a well-formatted Java code. All that is needed is a few rules about identation and spacing (I prefer K&R, myself). Regexen can be ugly, but they're equally ugly everywhere, as Java programmers are sure to (re)discover, since 1.4 now includes them. The /x modifier can help, if used properly.

    ----
    Reinvent a rounder wheel.

    Note: All code is untested, unless otherwise stated

      But did you also know that adding OO to Perl required defining precisely zero new syntax to the language?

      I'm in a niggly mood :-)

      I don't know where this meme started - but it's not true. OO in perl needed little new syntax, but it did need -> method invocation, indirect object syntax and SUPER::.

      Adding OO to perl was done very neatly, so neatly many people didn't notice the difference - but there is specific syntax too support OO in perl.

        I don't know where this meme started . . .

        Possibly on page 321 of the blue Camel, just under the "Class Inheritance" subheading:

        As with the rest of Perl's object system, inheritance of one class by another requires no special syntax to be added to the language.

        The -> operator denotes a referance, which has plenty of use outside OO. In this case, were referancing a subroutine from a bless'd variable. I'm not sure about SUPER::.

        ----
        Reinvent a rounder wheel.

        Note: All code is untested, unless otherwise stated

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://237831]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2018-08-16 02:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Asked to put a square peg in a round hole, I would:









    Results (166 votes). Check out past polls.

    Notices?