|
in reply to There's Only One Way To Do It
Ok, I'm on the fence as a developer. I do both perl and java. Depends on who I’m doing it for or what it is, but I do know when to use the tools I have, even when in the language.
The problem with any language that has a tool-set, is that people will want to use the tools, sometimes too much. I'm not talking about things like DBI or what have you. I give you an example. I was once writing a throwaway script to fix up a data file in perl, and someone started telling me why I should use chomp vs chop (which I used), and the differences and what not. This was for a 20 line text file that was handed to me and needed to be fed into another process. All I wanted to do was take the 2 comma separated values and switch them around, per line. I know the file was uniform and it worked.
Now this is a minor example, all about chop vs chomp. Was this a more production level thing or code that was to stay out in the wild, I would have made it do actual format checking and other things. Maybe even use a CSV module instead. But it's a tiny argument over that shows a case of over-engineering a solution. It's what a lot of people suffer from, independent of the tools around.
The amount they over engineer is a function of what is sitting in front of them. A default install of perl has a good few handfuls of modules. If it's a one off thing with comma delimited files, I certainly would not go through the effort of installing a CSV parser unless I would use it over and over or it's production level. It's an easier module to install, I admit, but it takes time -- and I will less likely "install something" on a case-by-case basis. Sue me. :)
Java on the other hand, comes with well over a few hundred different classes. On top of that, there are also a lot of tools (not functions per se) in the language, so you have OOP, private members, static methods, and what not, easily, readily available as well. Sometimes, you don't need OOP. Sometimes you don't need the security. Sometimes, you don't need to over engineer. We don't always need the abstraction.
Java can be done to mimic other languages, but most people see the tools in front of them, and use them as such. They over-engineer. In the perl community, we have the opposite problem. Things like CSV parsers, or WWW::Mechanize aren't so obvious and available with all distributions on a default install, that people don't use them enough. You get beginners, neophytes and even those starting to become wise, under engineering. Things like File::Find can be done, to someone's needs, in a few lines of perl. But if it's not there in a tidy little document explaining the world to them, how would they have known when they aren't used to it? My theory is, people who become wise in programming, learn what tools are available and when to use them. So they learn to less over-engineer in java, and engineer more in perl, doing the right things vs "less desirable way."
Back to your point of the "only way". Yes. Sometimes it's retarded to re-invent the wheel. WHY would I write my own DBI is beyond words for me, as it's a solid architecture that few have even mimicked. Why should I implement hashes and an OOP architecture vs letting perl do it for me in it's native form? I can't think of an easy reason at all beyond experimenting with code. There are one true ways, but it won’t stop people from not knowing any better. There's no one-stop-shop for looking up, how do I pull down a web page, or do massive calculations. There is the cpan search engine, but it's not as convenient as having the entire shebang packaged up with perl with a neat little index.html explaining everything. One way? Totally agreed. Will anyone truly understand it within their first few days or even years of using perl? Unfortunately no. It’s not an excuse or a call to arms. It’s just a fact. :\
--
"So far my experience has been that most people who go for certification have broad but not deep knowledge in the field and the flavor of the knowledge is academic. But every once in a while one finds a gem of a person who learns all the time and uses certification to prove it." -- on Orkut
|
Re: Re: There's Only One Way To Do It
by hardburn (Abbot) on Apr 06, 2004 at 16:20 UTC
|
Java on the other hand, comes with well over a few hundred different classes.
A lot of which are redundant and tend to deprecate one method in favor of a method in another class instead of fixing what was wrong in the orginal (java.io.DataInputStream.readLine comes to mind). All of java.io.* could be reduced to a lot fewer classes if things weren't so overengineered.
----
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l]
[select] |
|
|
In defense of deprecation, running java using a deprecated function will warn you. As for the java io stuff, it is rather unweildy. Unwieldy? It's a view of how things should be. Some people agree with it, some people don't. It's a problem with complex systems. People are more likely to agree on the simple end of life, not the more complex ones :\
--
"So far my experience has been that most people who go for certification have broad but not deep knowledge in the field and the flavor of the knowledge is academic. But every once in a while one finds a gem of a person who learns all the time and uses certification to prove it." -- on Orkut
| [reply] |
|
|
running java using a deprecated function will warn you.
I don't want it to warn me, I want the orginal fixed. One of the major selling points of OO is that you can encapsulate behavior, so DataInputStream.readLine should be fixed instead of moving that functionality somewhere else. You can deprecate methods if you decide the old design was broken, but if it's just the underlieing code that's broken, then you're ignoring one of the big benifits of OO by deprecating it.
----
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l]
[select] |
|
|
Re: Re: There's Only One Way To Do It
by herveus (Prior) on Apr 06, 2004 at 16:38 UTC
|
Howdy!
I think jdporter's thesis is that, for a select set of
language features, there is only one useful way to do it.
Perl is a strongly typed language. You have three data
types -- scalar, array, hash. You can't coerce a scalar
into an array or a hash -- they are fundamental data types.
integer, float, decimal -- who needs the multiple names.
They are all scalar values.
Note that I don't equate "strongly typed" with "bondage and
discipline". Java does the B&D thing with data types,
leading to the ever-popular downcast. They may claim to be
Strongly Typed, but you can't do anything useful without
having to subvert the type system to get data moved around.
| [reply] |
|
|
You have three data types -- scalar, array, hash.
There are a few other types, such as subroutines and filehandles, plus the umbrella glob type. Also, I would argue that array and hash should be considered subtypes of the type 'list', since you can coerce a hash into an array (which may or may not give a useful result). You could also consider blessed references to have their own type (that type being the package they were blessed into), but if you do, you have to remember that it's totally seperate from the rest of Perl's type system. It's also easy to subvert via re-blessing.
Java does the B&D thing with data types, leading to the ever-popular downcast. They may claim to be Strongly Typed, but you can't do anything useful without having to subvert the type system to get data moved around.
Java actually has a rather weak type system, preciely because of the subversion you mention (C and C++ exibit the same problem). A big mistake a lot of people have made is equating static typing = strong, and dynamic typing = weak. Perl is dynamically typed, but also very strong. C/C++/Java are statically typed, but are relatively weak.
Languages with a type system like C are usually only good for giving the compiler some optimization hints. Some would argue that it's more self-documenting, but given how easy it is to subvert, I think this could easily lead to more confusion than its worth.
----
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
Perl is dynamically typed, but also very strong.
Can you explain this a bit more? First, are these definitions correct? Static typing means the type of the variable is known at compile time. Dynamic typing means the type of the variable is not known at compile time.
If those definitions are correct then I assume that the aspect of Perl that makes it dynamic is that the value in a variable can be a number or string of any length (limited by memory) and therefore makes the language dynamically typed. And the aspect that makes it static is that the structure of the variable is known at compile time (scalar, array, hash) and therefore makes the language statically typed as well. However just as in C and C++ references can be used to avert this static typing.
Is that right?
| [reply] |
|
|
|
|
| |
|
Howdy!
...OK, I concede that I simplified a bit...but for most
purposes, scalar/hash/array cover the field. I'd not
consider blessed references as a distinct type, as they
are a species of scalar with some "magic" (using "magic"
to not necessarily mean Perl-magic).
Type-as-associated-with-blessed-references is certainly
a different dimension, not quite orthogonal to scalar/hash/array, and I was disregarding it in my screed.
You appear to have read between my lines as I intended
(instead of falling for what I will admit could be construed
as lame flame bait)...
| [reply] |
Re: Re: There's Only One Way To Do It
by tachyon (Chancellor) on Apr 07, 2004 at 13:12 UTC
|
All I wanted to do was take the 2 comma separated values and switch them around, per line
And you needed chop() or chomp() or more than one line of code to do it? Get with the program dude - you need discover inplace editing :-) The supplementary backup file is nice when your brilliant solution turns out to have just destroyed 10,000 zone records, not that I would know :o)
perl -pi.bak -e "s/([^,]+),([^,\n]+)/$2,$1/" data
| [reply]
[d/l] |
|
|
