Now we're at the '_/How many Angels can dance on the head of a pin/_'
question (like anything with wings would waste time dancing. Ever seen
eagles mate (not the football players)? Dance it's not, but it looks
like /sex on a roller coaster only better/! Get me a pair of wings!).
Religious war over please! They get me long winded (as you'll note if
you keep reading). So, back to the original questions, now long forgotten.
The questions (there were three) were:
(1) Why does Java require each class be in a separate file?
(2) Why Python has no such rule?
And
(3) Is there a reason I should do one or the other (I assume that means
either, (3)(a) one class per file, regardless of language and/or (3)(b)
Java or Python).
-------------------------------------------------- <evangelist flag off>
--------------------------------------------------
Answers:
Question (1):
There appear to be four answers to this question.
(a) Don't know (most answers, but with some religious dogma
attached. JAVA bad; PYTHON good and I worship PHP. Move the adj.
around to suit your tastes).
(b) KISS principle. /Keep It Simple, Stupid/. This is probably the
right answer. Back then SUN, or as some of us remember '/Stanford
University Network/' employed some sharp people (I must admit, my
main reason for disliking SUN and CISCO was where they started. I
was from UC Berkeley. It should have been UCBUN, or Uncle Buns; but
that's just wouldn't sell. See how well BSD or 'bastard' sells).
(c) Early Java development technology not up to n+1 classes in a
single file. Reasonable from an old programmer's point of view.
Those old IPC workstation didn't have that much memory. Small
compiling jobs and executable loads would have been preferred if not
required. I remember my first IPC had 4 Megabytes of RAM (boy did I
have to beg for that box!) My Compaq 386/20 MHz computer, running
MSDOS 3.1 only had 1 Meg and a Hercules graphics card (16 colors. I
must have been good that year). I must have been a star, as most
other's new hires were using '*/Bleeding Edge/*' computers (and if
you don't know the reference, your just too young; think Gateway or
Dell's cheap, hobbled products). File and more importantly, virus
transfers where by /SneakerNet/. You young people have it too good;
just one message via Exchange and you can infect a million computers
in a thousand countries in moments. We had to work at it before we
could take a day off as IT reloaded our computers. Thank God or Bill
Gates, that companies keep buying a broken product.
(d) Last. It was developed for vending machines (as someone pointed
out, it started life as 'OAK'). Small memory foot print and a
limited feature set were no brainers. '/We Taka the coins in, We
dropa the Twinky out'. /The net's early domination by Unix variants
and the Macintosh made Java's '/jack of all trades'/ a good
solution. It was the main reason Microsoft tried (and failed) to
'/Embrace and Extend'/ Java (Novell watch your ass; Microsoft wants
to embrace and extend up your backside. SUN, just like a good
Catholic girl said NO! (Or not in public! as the IBM/SCO trial seems
to show)).
So, pick an answers. It's God's fault/feature (sorry, I forget SUN
!= Microsoft), a programming dogma, hardware related or just old
fashion growing pains. Probably some of each is the truth.
Question (2):
Python is a later generation language then Java. Without a SUN,
Digital or Microsoft to push it, it had to serve it's users better.
Design limitations, due to hardware (see HP and Korn shell) weren't
a consideration. The main issue I could see, when I was first
introduced to the Python language, was the reduction of overhead and
limited ways of doing the same task (1/ Perl ^ n in my experience).
The need to prettify code so other could read it, or more
importantly, so other's couldn't read it (for job security), wasn't
there. Python really is easy to learn, like Pascal was suppose to be.
Python, like Java was OO from the word go (ok gcc for you purists),
but was not syntactically a descendant of C++, so non-C++
programmers didn't need to pay homage to AT&T (and God's only son,
Bell Labs, from whence the Holy Ghost, Unix was created, destroyed
and reborn as BSD. Is there a movie with Mell Gibson there?
Remember, I said it first!).
Freedom of vendors often means best of breed wins (i.e. most useful
feature are includes). Freedom of vendors also means it hard to get
into your shop (no one ever got fired for buying IBM after all).
That takes care of why, I hope. _No doubt_ there's a few opinions left
to be expressed. Who knows, they might stay on topic as well or better
them I.
Question (3):
(3)(a) Is there a reason I should practice the 'One Class per File'
rule?
Answer is *yes,* when it makes your programming task easier and
*no,* when it makes your programming task harder (And yes, I could
be a damn good congressman too!).
For development, I think the n+1 class is the right choice. It lets
you start easy with a prototype class, one with little more then
placeholders and then using inheritances, build up the functionality
(you can see my Object Oriented Life started with C++, not a silver
or ruby spoon. I still have the first edition of "**The C++
Programming Language"** by Bjarne Stroustrup; an almost unreadable
book (six or eight beers make it easier, if not clearer; after
twelve you don't care). Don't ask to buy it. It's going into my
casket when I'm creamated, along with the first edition of '*The C
Programming Language*' by Kernighan and Ritchie and my second best
porn collection; might be tight in that casket, but what a FIRE!).
Using this method, program growth history is preserved. Some would
say that's the job of version control. But you can see where sandbox
development records got IBM and version controls blind usage in
Mircosoft's attempt at (5+ years) Vista. Somethings should be
forgotten, sooner rather than later.
For a developed, deployable product and JIT compilers, n+1 classes
with dead overridden inheritances, are wasted cycles, wasted space
and wasted download bandwidth. It just doesn't make sense. /Clean em
up, move'em out/. That's what version control is for.
(3)(b) Python or Java. Emmm, Dumb question (some question are,
despite the feel good gurus your boss will bring in when he wants to
cut your salary, double your workload or both while cutting you
coffee rations). The answer depends on your boss's preference. Learn
both and hope you can convience him the one you're best at, is the
right choice (good luck; boss's are generally a generation or two
behind and you. After all, you where hired because of your fresh
knowledge and viewpoint. We don't want that going to another
company. When you feel this is situation is all wrong, read the
novel Catch-22 and join th club). And please don't remind him that
you'll be there to support the language he doesn't know. That's a
ticket backwards and a new resume (yours).
-------------------------------------------------- <evangelist flag on>
--------------------------------------------------
Now for some fun. I have a wicked (so I'm told) and rude sense of humor.
Humor me, or you, if you please ...
You'll notice I didn't evangelize or denigrate Python, Jython, Java, PHP
or C++ (/OK, C++ just a little; after all, I am a fallen CatholiC++/.
/And a few jabs at Microsoft. The devil should always be mentioned,
especially when he's hard to avoid/).
So now here's the the motto or jingle of the dying and upstart languages
languages:
Perl: "Badges? We don't need any stinky badges!"
FORTRAN: "GOTO 40"
and
FORTRAN-90: "GOTO 40-ish, please!"
Basic: "Directory? What's a directory?"
<shudder>Pascal</shudder> (need I say more?)
and
COBOL on or off Ng: "Your in the wrong column, again!"
And the upstarts language mottos:
Ruby: I don't care if the slippers are suppose to be sliver; I'm
paying for Technicolor dammit; those slippers will be RUBY!
C-Sharp: Bitter on the tongue and leaves a bad after taste. Could I
have a Java light instead?
or C-Sharp's first cousin by bastardy with open source virgins (in
time they'll realize that pains in their behinds should have been
expected) ...
Mono: much like the disease, ready to infect anything it touches.
You should avoid it as fast as you can run.
And ... Not to forget the forgetable ...
PHP or for neophytes Perl Hypertext Protocol, also referred to as
'2nd Wind' or 'Last Gasp' can't be bad for you!
Did I miss anything? No? Then I have no /Smalltalk/ left, so you should
go /Forth/ and program. But remember JAVA & SCRIPT can grow infinitely,
especially when taken to the exp( GOOGLE ) plexed.
sph
--------------------------------------
P.S. Python RULES!
---------------------------------------
P.S.S. Still waiting for GWT via Python Google; I hate stepping
backwards; can't tell what I'm stepping in, but
GWT feels like dog poop; warm amd squishy but it stinks. Mom tells
you to stay outside and clean your
shoes. Flies think your sweet.
---------------------------------------
Carl Banks wrote:
On Apr 4, 5:23 pm, "Chris Lasher" <[EMAIL PROTECTED]> wrote:
A friend of mine with a programming background in Java and Perl places
each class in its own separate file in . I informed him that keeping
all related classes together in a single file is more in the Python
idiom than one file per class. He asked why, and frankly, his valid
question has me flummoxed.
A: Because you don't have to.
Less smart aleck: Python allows programmers to put more than one class
per file. Given that freedom, most people didn't obey one-to-one
correspondence between classes and files. Therefore, it's the more
common idiom in Python.
I tried to rationalize this Python idiom by claiming a file--a single
module--makes for a great container of code which is logically tied
together, such as a class and its subclasses. He posited that
directories (packages) can tie the files together just as well,
Which is not incorrect.
and by
having the classes as separate files, he can "diff" them to see how
they differ, something he wouldn't be able to do with the code all in
one file.
I agree with Bruno: feeling the need to do this is a big red flag that
the code is way too cut-and-paste.
(diff'ing different versions is useful, of course, but you can
usefully diff modules with many classes in them.)
I also offered that having related classes under one file gives more
direct access to those classes, e.g.:
[snip examples]
He doesn't find my arguments convincing, so I thought I'd ask here to
see why the Python idiom is the way it is: why should we NOT be
placing classes in their own separate files?
There's no overwhelming reason not to, IMO. As long you have some
organization, be it with packages or modules, everything's ok. Most
things you have to gain or lose by doing one way or the other are of
minor importance.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
