Discussion:
I want to learn a new language...
Bryan Sant
2007-02-14 21:30:41 UTC
Permalink
Contrary to popular belief, I'm not a complete and total Java bigot...
Okay, I lied, I am. Java is the shiz-nigget. However, I'm honestly
wanting to invest in a new language for fun and profit.

I have a decent background in bash/shell, Perl, and I've played with
Ruby and Python. One of the reasons that I'm so passionate about Java
is because it gets ganged up on by all of the scripting language
enthusiasts collectively. Java is pitted against the best features of
Ruby, Perl, Python, Lisp, Smalltalk, PHP, and even Haskell, OCaml, D,
and C/C++. Is Java going to beat the collective power of all of these
languages? Of course not (but it would be close :-).

Collectively the development language landscape is lush. But if I
(the operative word is *I*, I'm speaking for myself) peel off any one
of those languages and evaluate it by itself, it loses it's appeal
compared to Java. I sincerely want to learn a new language well, but
as I start to dig in to each language, I find warts that are even
uglier than the step-child that is Java.

I'd like to learn one of the following well: Python, Ruby, or Perl.

Here are my problems with each language respectively:

Ruby. You'd think this one would be a slam dunk for me. It's OO,
it's hip, it gets all the press. But Ruby is the
SLOOOOOOOOOOOOoooooooooooowest freaking language ever invented. It's
not just kind of slow it is so slow that it's embarrassing. For MOST
tasks, I'm sure that doesn't matter. When dealing with the web, the
bottleneck is the network. Utilities or shell-ish scripts don't need
to be fast. I could be convinced that speed is less important than
some other uber cool features in the language.

Perl. I like the fact that Perl is everywhere. You can't swing a
dead cat by the tail without hitting into a Perl interpreter. I like
that Perl is mature. One word, CPAN. All of this is great, but I
DON'T like the whole, "there's more than one way to do it" deal. More
than one way? That's a I nice way of saying that every Perl program
is as unique as a snow flake. I'd like to use a language that others
(and even ME after 6 months) can read. My own experience backs up the
claims that Perl is a "write only" language. This may be overly
dramatic, and Perl may be more readable than I think if I spent some
more time with it. Help me learn to love Perl.

Python. Python is the front runner for me. I like speed and Python
is comparatively fast. I like that Python is on most Linux systems
(but no UNIX systems in the entire world). I like that Python is very
readable and confines developers to use a similar layout and style. I
like that Python is named after a Monty Python. I think snakes are
cool. On the down side, I heard that Python didn't originally have OO
capabilities and that this was later bolted on (the same is true for
Perl). I get my OO, so what am I complaining about? Well, when you
don't have to use OO, you often find code snippets and other
developers who haven't bothered to learn and write OO code, so you're
stuck with crap semi-OO code or none at all. Ruby being OO from the
start seems like it would have a better object oriented standard lib
and a more OO competent user community. I also don't like that Python
has Zope, TurboGears, and Django. Ruby seems to have just one popular
web framework instead of three to learn (yes, I don't have to learn
all three, but I will come across them sooner or later).

Please advice.

PS > Don't say, "You should use each one for what it's best at."
Screw that. I'm not interested in learning to create "Hello World" in
20 languages. I want to pick a language and acquire a deep
comprehensive knowledge of it. I'd rather be awesome at two or three
languages than so-so with 15. I want to pick ONE -- please make sure
it's the best.

Thanks in advance,
-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-14 21:37:49 UTC
Permalink
Python, obviously.

<snip everything else>

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 21:39:58 UTC
Permalink
Post by Daniel C.
Python, obviously.
Great. Your vigor is overwhelming. I require a little more
convincing that a one liner.

Why Python? Why not Ruby or Perl instead? What does Python have that
they don't?

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-14 21:43:28 UTC
Permalink
Post by Bryan Sant
Great. Your vigor is overwhelming. I require a little more
convincing that a one liner.
If only I cared as much about convincing you as you do about being convinced.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 21:49:35 UTC
Permalink
Post by Daniel C.
Post by Bryan Sant
Great. Your vigor is overwhelming. I require a little more
convincing that a one liner.
If only I cared as much about convincing you as you do about being convinced.
Weak. You can't even tell my why you like the language you use. I'm
not going to bash you, or turn this into a, "Ya, that sounds cool, but
really Python sucks because..." I'd just like to know why a person
likes their language.

I need the equivalent of Levi for each language to really get into the
coolness offered by each :-). I'd like to know what I'm missing by
not using Python and just sticking with what I know. I'd like to hear
personal accounts of using Python to create a large or interesting
system and how great it turned out, etc.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-14 21:55:28 UTC
Permalink
Post by Bryan Sant
Weak. You can't even tell my why you like the language you use.
Won't, not can't.
Post by Bryan Sant
I'm not going to bash you
"weak" isn't bashing?
Post by Bryan Sant
I need ... I'd like to know ... I'd like to hear ...
Sorry. Maybe someone else can meet your needs.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bart Whiteley
2007-02-14 21:51:46 UTC
Permalink
Post by Bryan Sant
Post by Daniel C.
Python, obviously.
Great. Your vigor is overwhelming. I require a little more
convincing that a one liner.
Why Python? Why not Ruby or Perl instead? What does Python have that
they don't?
Merits of the language and run time environment aside, which community do
you want to hang with? My experience is that python-heads are an agreeable
bunch of hard-core coders. Ruby-heads remind me of Java-heads -- not good.
Perl-heads are, well, perl-heads; you've probably met some.

Flame on. ;)

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 21:57:48 UTC
Permalink
Post by Bart Whiteley
Merits of the language and run time environment aside, which community do
you want to hang with? My experience is that python-heads are an agreeable
I'd like the enumerations of the merits of the language/runtime
please. Community is important, but I'm not doing this for social
reasons. I could care less if every Perl coder in the world was a
hose head, as long as it's a better language/runtime that Python.
Post by Bart Whiteley
bunch of hard-core coders. Ruby-heads remind me of Java-heads -- not good.
Hard-core coders seems like a term open to interpretation. I want facts.
I am a Java-head. If the Ruby community thinks more like Java, that
would be a benefit in my mind.
Post by Bart Whiteley
Perl-heads are, well, perl-heads; you've probably met some.
Aside from Jayce, I like most Perl developers. They're practical and gritty.

But note taken. Thanks.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jason Hall
2007-02-14 22:03:39 UTC
Permalink
Aside from Jayce, I like most Perl developers.  They're practical and
gritty.
Grit, wow, I didnt' think anybody else read that!


--
Jayce^

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Andrew Jorgensen
2007-02-14 23:04:32 UTC
Permalink
Post by Bryan Sant
Post by Bart Whiteley
Merits of the language and run time environment aside, which community do
you want to hang with? My experience is that python-heads are an agreeable
I'd like the enumerations of the merits of the language/runtime
please. Community is important, but I'm not doing this for social
reasons. I could care less if every Perl coder in the world was a
hose head, as long as it's a better language/runtime that Python.
That's a little short-sighted of you. Languages attract a certain
kind of people because they are a certain kind of language. If every
perl coder in the world was a hose head you would surely either only
choose perl if you are a hose head or would become quite the hose head
after using it for long enough. I'm not kidding.

Given that you're interested in scripting languages like perl, python,
or ruby you might really want to factor in which crowd you think
you'll identify best with. Of course that won't be the most important
reason but it's not to be ignored either. Reading their -users
mailing lists should give you a notion of what kind of people they
are.

Anyway, I'd like to say what little I have to say about Perl. I
haven't used python or ruby to code anything so I really can't speak
to either.

I don't like perl.

I like code that's been written carefully, with the future in mind but
many of the modules you'll find on CPAN were written to scratch an
itch. There are, of course, many modules that were very carefully
written by perl hackers who know what they're doing but there's a lot
of useless or half-baked crap out there and it puts a bad taste in my
mouth every time I end up writing my own module because the module
that's in CPAN just doesn't cut it. One good example of this is
VCS::CMSynergy. We needed a perl module to help us do stuff with
CMSynergy but that module doesn't do any of the things we wanted to
do.

I use perl a lot for sys-admin tasks because it's really well suited
to tasks that would stretch shell a little. That's not to say that
shell couldn't do it but sometimes what you thought was going to be a
quick script grows into a larger project and you find yourself wishing
you'd used perl.

Honestly almost any small project I want to hack up I usually turn to
perl. Not because it's a great language but because it's easy for me
to get something working in a small amount of time in perl.

One of these days I'll do something in python. My brother Jens does
amazing things with python. I'm sure they could be done in other
languages but it was pretty cool to watch him whip up a python program
that basically did what rsync does when it's passing binary deltas.
It only took him a few minutes and worked over ssh by passing python
code to an interpreter on the other side. It was wild.

I also admire what the folks at Fluendo are doing with python in the
flumotion project. The list of standard libraries is impressive and
cool projects like avahi, dbus, and hal have python bindings.

Andrew McNabb's comment about liking python the more he uses it is an
excellent indicator too. The more I use perl the less I like it. I
should probably read the suggested perl books though.

I've got a hunch that ruby is trendy and will go away due to lack of
interest soon. I could be completely wrong about that. It just
hasn't got a firm enough hold to really thrive. Maybe ruby is like
IPv6, it's the next big thing but we're spending too much keeping the
older stuff working (and making it work better) to give it a decent
chance.

A few people have noted that perl is a great tool to have regardless
of what you love to code in and I'd have to agree.

My vote is for python all things considered. That's what I intend to
learn next.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jeff Schroeder
2007-02-14 23:22:21 UTC
Permalink
Post by Andrew Jorgensen
Honestly almost any small project I want to hack up I usually turn to
perl.  Not because it's a great language but because it's easy for me
to get something working in a small amount of time in perl.
(snip)
A few people have noted that perl is a great tool to have regardless
of what you love to code in and I'd have to agree.
These comments are great, and I agree wholeheartedly. I'm not a Perl
expert, but I use it a lot for "quick and dirty" programs where a shell
script just won't handle it, or where I need something that does a lot
of text processing.

I wouldn't want to spend all my time writing Perl, nor would I want to
build a huge enterprise system in it, but it's incredibly useful for
those one-off jobs you're always doing as part of your "regular work".

My recommendation would be to get good enough at Perl that you can whip
up a script when you need it, but continue using Java for those big
projects (since it sounds like you're well-versed in it already).

$0.02,
Jeff
Jesse Stay
2007-02-14 23:25:45 UTC
Permalink
Post by Jeff Schroeder
My recommendation would be to get good enough at Perl that you can whip
up a script when you need it, but continue using Java for those big
projects (since it sounds like you're well-versed in it already).
I think it should be a requirement for any Linux admin (or programmer)
to know "perl -i -pe". Even if you don't know Perl, the command-line
options can be very useful in any type of sysadmin task.

Jesse
--
#!/usr/bin/perl
$^=q;@!>~|{>krw>yn{u<$$<Sn||n<|}j=<$$<Yn{u<Qjltn{ > 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hans Fugal
2007-02-14 23:23:21 UTC
Permalink
Post by Andrew Jorgensen
I've got a hunch that ruby is trendy and will go away due to lack of
interest soon. I could be completely wrong about that. It just
hasn't got a firm enough hold to really thrive.
I think you're probably wrong. If you substitute rails for ruby you're
probably right (although I do think rails is a decent web framework).

Ruby has been growing steadily for a number of years. It's been big in
Japan for a long time. The hype surrounding rails was somewhat
unexpected, although it didn't come as much of a surprise to us that
something hit the hype threshhold. It has given the community an influx
and moved us a long a bit faster than we were going, but if the hype
died down tomorrow and no new rails programmers joined the ranks, Ruby
would continue to grow steadily. That's my take anyway.
Post by Andrew Jorgensen
Maybe ruby is like
IPv6, it's the next big thing but we're spending too much keeping the
older stuff working (and making it work better) to give it a decent
chance.
No, that's LISP!
--
Hans Fugal ; http://hans.fugal.net

There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
Daniel C.
2007-02-14 23:28:36 UTC
Permalink
Post by Hans Fugal
Post by Andrew Jorgensen
Maybe ruby is like
IPv6, it's the next big thing but we're spending too much keeping the
older stuff working (and making it work better) to give it a decent
chance.
No, that's LISP!
Wait, is Lisp the old one that we're wasting resources on, or the next big one?

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hans Fugal
2007-02-14 23:42:40 UTC
Permalink
Post by Daniel C.
Post by Hans Fugal
Post by Andrew Jorgensen
Maybe ruby is like
IPv6, it's the next big thing but we're spending too much keeping the
older stuff working (and making it work better) to give it a decent
chance.
No, that's LISP!
Wait, is Lisp the old one that we're wasting resources on, or the next big one?
The next big one that is "obviously superior", has been around for ages,
and yet is still not yet adopted.
--
Hans Fugal ; http://hans.fugal.net

There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
Andrew McNabb
2007-02-14 22:48:14 UTC
Permalink
Post by Bryan Sant
Post by Daniel C.
Python, obviously.
Why Python? Why not Ruby or Perl instead? What does Python have that
they don't?
Why Python? It's the only language I've ever used that I like more the
more I use it. Preferences are subjective, and so are the reasons for
them. Let me ramble a bit to give you some of what I like. If I had
more time, I'd be more organized and succinct in my response.

1. When I started using Python, I hated the idea of using whitespace
for syntax. I endured this weakness (as I saw it). After a few weeks,
my perspective changed completely. We all use whitespace anyway. When
the compiler cares, you get consistency and cleanness for free. On at
least two occasions, I've spent hours trying to track down a bug of the
following form in Perl or C:

if (condition)
x = 1
y = 2

The code worked when it was:

if (condition)
x = 1

and my eye just didn't see what was wrong when I added "y = 2". I
haven't made this mistake in several years because I can't forget the
pain. Python code looks really clean to me because of the way it uses
whitespace.


2. Python is very dynamic. Docstrings are amazing: any object can give
you its documentation on the fly. Functions and classes are first class
objects. You can ask a function how many parameters it takes. You can
make things with very dynamic behavior. For example, I have a plot
library which writes Gnuplot files.

Here are two different examples of code that uses the library to plot
some basic functions:

def f(x):
return x**2
def g(x, y):
return x**2 + y**2

# This opens up a Gnuplot window with a 2-D plot:
p = Plot(title='Test Function')
p.append(Function(f))
p.show()

# This opens up a Gnuplot window with a 3-D plot:
p = Plot(title='Test Function')
p.append(Function(g))
p.show()


3. Python has a few high level structures that it makes very useable:
lists, dictionaries, and tuples. In my experience, these constructs are
very practical. For example, if I want to open a file and read in a
list of floating point numbers, with one number per line, it looks like
this:

lst = [float(line.strip()) for line in open('/path/to/file')]

In my opinion, this is incredibly readable, and it looks the same on the
screen as it was in my head before I wrote it down.

I can even take the squares of the list:

lst2 = [x**2 for x in lst]

These might look like dumb, simple examples, but the code I write every
day is full of similarly dumb and simple lines of code. It's easy to
write, and it's easy to understand when I look at it later.


4. I find Python to be clean and consistent all the way through, or at
least as much as any programming language can be. Certain themes show
up in many different places, such as dictionaries. A namespace is just
a dictionary, and defining a class is really just creating a dictionary
mapping names to attributes and methods.

One note: I originally was bothered that you write len(lst) instead of
lst.len(). However, in Python, len() is conceptually an operator. I
write len(lst) instead of lst.len() just as I write "-x" instead of
"x.minus()". This is an example of something that I like once I get
used to it. The warts in other languages tend to bother me more and
more over time.

Sure, Python isn't perfect. But it's so simple that I always feel like
I know where the imperfections are, and I write code without worrying
about them.


Anyway, those are just a few of those thoughts. Don't tear them apart
because I didn't try to write some proof of why Python is the greatest
thing in the world or something. This is just an attempt to identify a
few of the reasons why I seem to have more fun in Python than in most
other languages. And honestly, there are a lot of other great languages
out there, and preferences really are subjective.
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
Bryan Sant
2007-02-14 22:59:10 UTC
Permalink
Post by Andrew McNabb
Anyway, those are just a few of those thoughts. Don't tear them apart
because I didn't try to write some proof of why Python is the greatest
thing in the world or something. This is just an attempt to identify a
few of the reasons why I seem to have more fun in Python than in most
other languages. And honestly, there are a lot of other great languages
out there, and preferences really are subjective.
Thank you. This is just what I am looking for.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-14 23:29:50 UTC
Permalink
Post by Andrew McNabb
Sure, Python isn't perfect. But it's so simple that I always feel like
I know where the imperfections are, and I write code without worrying
about them.
Thought I'd interject with a few of my favorite things to hate about
python.

Most of my issues with python surround the "duck" typing system. This
works very well for lots of things. Basically the type of an object
doesn't matter so long as it supports the protocol you want. Thus you
can use the "for x in " operation on any object that is iter-able. The
problem is that there's no easy way to discern ahead of time what is
expected when you pass an object to a function. You can use
introspection to get the built-in docs, ask the function how many
parameters it's expecting, true. But if the docs don't say, you have no
idea what methods the function is expecting to call on the object until
you try it and get an exception. This often makes working with
third-party libraries very painful. I had to run several python twisted
networking apps in a debugger until I figured out just what the
different methods and functions in twisted are expecting, the good docs
notwithstanding. The source code is essential in finding out some of
these things. So while I find dynamic typing extremely powerful, it
does have warts.

The other major architectural limitation in python is the GIL, a giant
lock that synchronizes calls to the interpreters core. Thus
multithreaded programs can not utilize multiple processing units. In
practice this usually isn't a huge deal. I'd say much of the time a
multithreaded app is best done with an asynchronous library anyway, like
twisted. But threads have their place. Just be aware of this
limitation when doing heavy computations with python.

Michael
Post by Andrew McNabb
Anyway, those are just a few of those thoughts. Don't tear them apart
because I didn't try to write some proof of why Python is the greatest
thing in the world or something. This is just an attempt to identify a
few of the reasons why I seem to have more fun in Python than in most
other languages. And honestly, there are a lot of other great languages
out there, and preferences really are subjective.
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Nicholas Leippe
2007-02-14 23:37:34 UTC
Permalink
Just curious. I've been curious to learn python, (but haven't had the
time/opportunity yet), but then I ran across boo, which looked extremely
interesting to me.

Has anyone tried boo?

(It has python-like syntax, compiles to the .NET/mono CLI, and has some other
significant changes.)



/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Ellis
2007-02-14 23:47:08 UTC
Permalink
Post by Nicholas Leippe
Just curious. I've been curious to learn python, (but haven't had the
time/opportunity yet), but then I ran across boo, which looked extremely
interesting to me.
Has anyone tried boo?
One of the python UG guys likes it. (I don't think he's on this
list...) He's really into desktop GUI stuff and Boo + winforms does
seem good at that. And the SharpDevelop Boo plugin seemed pretty good.

OTOH some of the design decisions lead me to believe the author doesn't
really understand why python hits a sweet spot, and suffers as a result.
Then it has some gratuitous weirdassness thrown in for good measure.
(Auto-call super? That is just wrong.)

Now that IronPython is out (Boo predates its inception IIANM) I don't
really have a reason to use Boo.

-Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-14 23:55:05 UTC
Permalink
Post by Nicholas Leippe
Just curious. I've been curious to learn python, (but haven't had the
time/opportunity yet), but then I ran across boo, which looked extremely
interesting to me.
Has anyone tried boo?
(It has python-like syntax, compiles to the .NET/mono CLI, and has some other
significant changes.)
I tried it briefly while looking for a .NET language to use for a
project. It may look like Python, but it's not Python. You may like
using it, though, if what you like most about Python is the syntax.
On the other hand, as long as you're going to use a language with
inferred static types, you might as well use F#, which is a fairly
nice subset of OCaml with some changes to help it fit the .NET
environment better. It seems to be catching on fairly well in some
circles, and there are even a couple of books on it in the works.

--Levi

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Ellis
2007-02-14 23:41:00 UTC
Permalink
On Wed, 14 Feb 2007 16:29:50 -0700, "Michael L Torrie"
Post by Michael L Torrie
Thought I'd interject with a few of my favorite things to hate about
python.
This often makes working with
third-party libraries very painful. I had to run several python twisted
networking apps in a debugger until I figured out just what the
different methods and functions in twisted are expecting, the good docs
notwithstanding.
Twisted is well-known for having a very steep learning curve. I haven't
had this problem with any Python libraries I can think of.
Post by Michael L Torrie
The other major architectural limitation in python is the GIL, a giant
lock that synchronizes calls to the interpreters core. Thus
multithreaded programs can not utilize multiple processing units. In
practice this usually isn't a huge deal. I'd say much of the time a
multithreaded app is best done with an asynchronous library anyway, like
twisted. But threads have their place. Just be aware of this
limitation when doing heavy computations with python.
Well, if you're doing heavy computation, it should be in a C library
that releases the GIL properly. So in practice this isn't as big a
limitation as it sounds -- all the python stdlib that deals with
blocking or disk-touching system calls does this, for instance.

-Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-15 17:36:15 UTC
Permalink
Post by Jonathan Ellis
Post by Michael L Torrie
The other major architectural limitation in python is the GIL, a giant
lock that synchronizes calls to the interpreters core. Thus
multithreaded programs can not utilize multiple processing units. In
practice this usually isn't a huge deal. I'd say much of the time a
multithreaded app is best done with an asynchronous library anyway, like
twisted. But threads have their place. Just be aware of this
limitation when doing heavy computations with python.
Well, if you're doing heavy computation, it should be in a C library
that releases the GIL properly. So in practice this isn't as big a
limitation as it sounds -- all the python stdlib that deals with
blocking or disk-touching system calls does this, for instance.
-Jonathan
Good to know. Thanks Jonathan.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hans Fugal
2007-02-14 23:46:45 UTC
Permalink
Post by Michael L Torrie
Post by Andrew McNabb
Sure, Python isn't perfect. But it's so simple that I always feel like
I know where the imperfections are, and I write code without worrying
about them.
Thought I'd interject with a few of my favorite things to hate about
python.
Most of my issues with python surround the "duck" typing system. This
works very well for lots of things. Basically the type of an object
doesn't matter so long as it supports the protocol you want. Thus you
can use the "for x in " operation on any object that is iter-able. The
problem is that there's no easy way to discern ahead of time what is
expected when you pass an object to a function. You can use
introspection to get the built-in docs, ask the function how many
parameters it's expecting, true. But if the docs don't say, you have no
idea what methods the function is expecting to call on the object until
you try it and get an exception. This often makes working with
third-party libraries very painful. I had to run several python twisted
networking apps in a debugger until I figured out just what the
different methods and functions in twisted are expecting, the good docs
notwithstanding. The source code is essential in finding out some of
these things. So while I find dynamic typing extremely powerful, it
does have warts.
I disagree that duck typing (which is a feature of ruby also) is a
problem. I find it much more useful than not. I do agree however that it
is important to document what is accepted and expected for your methods.
Post by Michael L Torrie
The other major architectural limitation in python is the GIL, a giant
lock that synchronizes calls to the interpreters core. Thus
multithreaded programs can not utilize multiple processing units. In
practice this usually isn't a huge deal. I'd say much of the time a
multithreaded app is best done with an asynchronous library anyway, like
twisted. But threads have their place. Just be aware of this
limitation when doing heavy computations with python.
Incidentally, Ruby has similar (perhaps worse) limitations in threading.
These are on the table for repair with the virtual machine work being
done. The story is long, but basically you can do threads but they're
not real threads, and I say that in the pragmatic sense not the academic
sense.
--
Hans Fugal ; http://hans.fugal.net

There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
Bryan Sant
2007-02-15 17:48:55 UTC
Permalink
Post by Hans Fugal
I disagree that duck typing (which is a feature of ruby also) is a
problem. I find it much more useful than not. I do agree however that it
is important to document what is accepted and expected for your methods.
Doesn't this defacto need to document your parameters bring back much
of the verbosity of a statically typed language? I'm not trying to be
inflammatory, it's a sincere question I've had for a long time. I've
avoided using dynamic languages partly for this reason.

Granted that the interpreter doesn't *require* you to specify the type
or order of parameters, it makes sense that this is a good idea
(especially when working on a larger project, or building a lib that
will be used by others). But if this information is valuable,
wouldn't it be better if the language forced you to specify the type
and order of parameters? Wouldn't it be better to remove the guess
work about how a method, class, and library are used because the
contract for how you call them is embedded in the language?
Post by Hans Fugal
Incidentally, Ruby has similar (perhaps worse) limitations in threading.
These are on the table for repair with the virtual machine work being
done. The story is long, but basically you can do threads but they're
not real threads, and I say that in the pragmatic sense not the academic
sense.
Is this a limitation for Rails? Does Rails run as a single process
with green threads or messaging, or pooled out in separate processes
like mod_perl or CGI?

Thanks,
-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Ellis
2007-02-15 18:02:13 UTC
Permalink
Post by Bryan Sant
Post by Hans Fugal
I disagree that duck typing (which is a feature of ruby also) is a
problem. I find it much more useful than not. I do agree however that it
is important to document what is accepted and expected for your methods.
Doesn't this defacto need to document your parameters bring back much
of the verbosity of a statically typed language? I'm not trying to be
inflammatory, it's a sincere question I've had for a long time. I've
avoided using dynamic languages partly for this reason.
Not really. First, because such "type information" is often encoded in
the parameter name itself -- "count" is (or should) always be an int,
and I don't need a type declaration to tell me that. And then you have
doctest (http://www.python.org/doc/lib/module-doctest.html) which is the
best thing since sliced bread. (Really!)

But more importantly, leaving out type declarations is only a small part
of what makes dynamic languages so productive:
http://spyced.blogspot.com/2005/06/anders-heljsberg-doesnt-grok-python.html

Also: http://dirtsimple.org/2004/12/python-is-not-java.html

-Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jacob Fugal
2007-02-15 18:50:30 UTC
Permalink
Post by Bryan Sant
Post by Hans Fugal
Incidentally, Ruby has similar (perhaps worse) limitations in threading.
These are on the table for repair with the virtual machine work being
done. The story is long, but basically you can do threads but they're
not real threads, and I say that in the pragmatic sense not the academic
sense.
Is this a limitation for Rails? Does Rails run as a single process
with green threads or messaging, or pooled out in separate processes
like mod_perl or CGI?
Rails is normally run under a pool of fastcgi or mongrel[1] processes.

Jacob Fugal

[1] http://mongrel.rubyforge.org/

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hans Fugal
2007-02-15 20:51:55 UTC
Permalink
Post by Bryan Sant
Post by Hans Fugal
I disagree that duck typing (which is a feature of ruby also) is a
problem. I find it much more useful than not. I do agree however that it
is important to document what is accepted and expected for your methods.
Doesn't this defacto need to document your parameters bring back much
of the verbosity of a statically typed language? I'm not trying to be
inflammatory, it's a sincere question I've had for a long time. I've
avoided using dynamic languages partly for this reason.
Granted that the interpreter doesn't *require* you to specify the type
or order of parameters, it makes sense that this is a good idea
(especially when working on a larger project, or building a lib that
will be used by others). But if this information is valuable,
wouldn't it be better if the language forced you to specify the type
and order of parameters? Wouldn't it be better to remove the guess
work about how a method, class, and library are used because the
contract for how you call them is embedded in the language?
It's always important for the API to be understood. The advantage to a
dynamic (duck-typing) language is not that you don't have to understand
or make understood the API. The advantage to a dynamic language is that
you can pass a guy dressed in a duck suit to the library that was only
designed for ducks. The difference becomes you documenting "something
that behaves like a duck in this sense" vs. static type checking which
requires things that descend from Duck or _are_ Duck. It's not a matter
of power, it's a matter of expressiveness. People argue that static
languages are safer. I say we have enough of that with our government
treating us like babies. I don't need my compiler/interpreter to do it
too.
Post by Bryan Sant
Post by Hans Fugal
Incidentally, Ruby has similar (perhaps worse) limitations in threading.
These are on the table for repair with the virtual machine work being
done. The story is long, but basically you can do threads but they're
not real threads, and I say that in the pragmatic sense not the academic
sense.
Is this a limitation for Rails? Does Rails run as a single process
with green threads or messaging, or pooled out in separate processes
like mod_perl or CGI?
I'm not a Rails expert, but I do believe ruby threads are not a problem
(though it may have been something they had to work around). How rails
runs is as much a matter of deployment as anything. A common deployment
is the fastcgi-like setup, whether it's really fastcgi or some other
http daemon with something similar. So in short, I believe it's usually
a pool of processes handling requests.
--
Hans Fugal ; http://hans.fugal.net

There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
Bryan Sant
2007-02-15 21:38:07 UTC
Permalink
Post by Hans Fugal
It's always important for the API to be understood. The advantage to a
dynamic (duck-typing) language is not that you don't have to understand
or make understood the API. The advantage to a dynamic language is that
you can pass a guy dressed in a duck suit to the library that was only
designed for ducks. The difference becomes you documenting "something
that behaves like a duck in this sense" vs. static type checking which
requires things that descend from Duck or _are_ Duck. It's not a matter
I see the value of what you're talking about, and I've had to deal
with the inconvenience of making an object conform to an interface so
that it would work with an API designed for said type. This is why
you should design your API using interfaces rather than concrete
classes (in the case of Java). However, not everyone does this so you
ofter have to deal with the short sightedness of another developer.
At least with duck typing I don't need to worry about this. That's a
big win. But, I'd also argue that subclassing or implementing an
interface isn't that much harder, and I know what I'm expected to
implement. Using either straight inheritance or a combination of
inheritance and composition I can work around any API issue.

How do you know what duck-ish methods will be called off of an object
without access to the source code of the library or trial-and-error
with "method not found" exceptions? Telling me that your routine
expects a duck doesn't tell me much about it. Because a "duck" is a
vary fluid concept in a dynamic language. I may think, "Oh, you
naturally want to call a 'quack' method." When really the routine
wants a "waddle" method. How am I to know?

I guess I'm just saying that with a statically typed language I can
look at the API and know how it is supposed to be used. With a
dynamic language, there may be a fair amount of writing and running
code just to see what breaks as you discover the correct way to use
the API. Seems like a time waster.

I'm sure as I use these languages, I'll find that my fears are
unwarranted. I'm just describing the "flaw" in my opinion,
notwithstanding your explanation.
Post by Hans Fugal
of power, it's a matter of expressiveness. People argue that static
languages are safer. I say we have enough of that with our government
treating us like babies. I don't need my compiler/interpreter to do it
too.
I'm completely on board with you when it comes to government ;-).
Thinking of that parallel will help me be more accepting of the
liberty a dynamic language gives me, rather than curse the lack of
static type safety. Too much law and restriction is worse than not
enough, but I don't endorse anarchy either.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-15 21:46:31 UTC
Permalink
Post by Hans Fugal
It's always important for the API to be understood. The advantage to a
dynamic (duck-typing) language is not that you don't have to understand
or make understood the API. The advantage to a dynamic language is that
you can pass a guy dressed in a duck suit to the library that was only
designed for ducks. The difference becomes you documenting "something
that behaves like a duck in this sense" vs. static type checking which
requires things that descend from Duck or _are_ Duck. It's not a matter
of power, it's a matter of expressiveness. People argue that static
languages are safer. I say we have enough of that with our government
treating us like babies. I don't need my compiler/interpreter to do it
too.
Although I mostly agree with you, my experience with languages that
have very expressive type systems has made my opinion of static typing
much more favorable than it was before. I think there's a balance to
be struck between dynamism and static analysis, and though it may vary
from project to project depending on requirements, I think that Java
and other languages with similar type systems are usually more rigid
than would be ideal.

--Levi

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
b***@public.gmane.org
2007-02-15 17:07:32 UTC
Permalink
Post by Michael L Torrie
Thought I'd interject with a few of my favorite things to hate about
python.
The other major architectural limitation in python is the GIL, a giant
lock that synchronizes calls to the interpreters core. Thus
multithreaded programs can not utilize multiple processing units. In
practice this usually isn't a huge deal.
I wasn't going to respond to the original message because my only thought
was "It depends" (on what you are going to write, mostly). But since I
looked at these 3 languages for a specific project recently, I'll go ahead
and add my $.02.

The project I was doing required either heavy threading or asynch IO. It
was basically replaying production application server traffic in real time
so we could run our new database cluster in parallel with our old one for
a couple of weeks before replacing the old one.

Since it was doing a lot of HTTP requests, I didn't have time to write my
own HTTP library, and I wanted to use an existing lib, I ended up choosing
threads and Python.

If threads are important to you, Python, even with its limitations, is
still way ahead of Ruby or Perl. At least according to the docs.

Although I did already have a log munging code in Perl that I didn't want
to re-write, so I had a bunch of Perl processes piping data to a
multi-threaded Python process. So maybe JUST learning python is a bit
limiting. Perl really is excellent at transforming text.

FWIW,
Barry Roberts


/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Andrew Jorgensen
2007-02-15 17:25:30 UTC
Permalink
Post by b***@public.gmane.org
If threads are important to you, Python, even with its limitations, is
still way ahead of Ruby or Perl. At least according to the docs.
I'd just like to add there that I'm disappointed with the way threads
work in perl (interpreter threads). We've been fighting the fact that
perl uses ridiculous amounts of memory and a big part of that has to
do with how it does threads.
"Perl is a profligate wastrel when it comes to memory use. There is a
saying that to estimate memory usage of Perl, assume a reasonable
algorithm for memory allocation, multiply that estimate by 10, and
while you still may miss the mark, at least you won't be quite so
astonished."

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-15 17:55:46 UTC
Permalink
Post by Andrew Jorgensen
"Perl is a profligate wastrel when it comes to memory use. There is a
saying that to estimate memory usage of Perl, assume a reasonable
algorithm for memory allocation, multiply that estimate by 10, and
while you still may miss the mark, at least you won't be quite so
astonished."
Coming from the Java world, I doubt I'll be astonished at Perl's
memory usage :-).

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jason Hall
2007-02-15 18:08:18 UTC
Permalink
Post by Bryan Sant
Post by Andrew Jorgensen
"Perl is a profligate wastrel when it comes to memory use. There is a
saying that to estimate memory usage of Perl, assume a reasonable
algorithm for memory allocation, multiply that estimate by 10, and
while you still may miss the mark, at least you won't be quite so
astonished."
Coming from the Java world, I doubt I'll be astonished at Perl's
memory usage :-).
Very true, it will look light in that relationship. Perl isn't too bad
overall with memory, but from the internal perspective, it's just very
permissive. It keeps the used memory around for as long as it can, and when
building a veyr large app, it's something you look at, but much less that
with C or its kind.

As for threads, I do agree, as with pretty much the whole perl community that
iThreads are not our friend. That's why there is such a better rewrite in
place for perl6. As for the thread memory usage, there are a few things you
can do to take care of a majority of the problems you will encounter (prevent
them from being issues). But they are not what we want, and are being
changed.

--
Jayce^

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-15 18:20:28 UTC
Permalink
Post by b***@public.gmane.org
The project I was doing required either heavy threading or asynch IO. It
was basically replaying production application server traffic in real time
so we could run our new database cluster in parallel with our old one for
a couple of weeks before replacing the old one.
Since it was doing a lot of HTTP requests, I didn't have time to write my
own HTTP library, and I wanted to use an existing lib, I ended up choosing
threads and Python.
I wonder how an asynchronous http library, such as one that comes with
Twisted would have performed in this case.

Seems to me that for anything that is I/O bound, the only way to really
make it scale is with asynchronous programming, not threads. CPU bound
is an entirely different story.

Michael
Post by b***@public.gmane.org
If threads are important to you, Python, even with its limitations, is
still way ahead of Ruby or Perl. At least according to the docs.
Although I did already have a log munging code in Perl that I didn't want
to re-write, so I had a bunch of Perl processes piping data to a
multi-threaded Python process. So maybe JUST learning python is a bit
limiting. Perl really is excellent at transforming text.
FWIW,
Barry Roberts
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-15 17:34:13 UTC
Permalink
Post by Michael L Torrie
Thought I'd interject with a few of my favorite things to hate about
python.
Most of my issues with python surround the "duck" typing system. This
works very well for lots of things. Basically the type of an object
doesn't matter so long as it supports the protocol you want. Thus you
can use the "for x in " operation on any object that is iter-able. The
problem is that there's no easy way to discern ahead of time what is
expected when you pass an object to a function. You can use
introspection to get the built-in docs, ask the function how many
parameters it's expecting, true. But if the docs don't say, you have no
idea what methods the function is expecting to call on the object until
you try it and get an exception. This often makes working with
third-party libraries very painful. I had to run several python twisted
networking apps in a debugger until I figured out just what the
different methods and functions in twisted are expecting, the good docs
notwithstanding. The source code is essential in finding out some of
these things. So while I find dynamic typing extremely powerful, it
does have warts.
Isn't this limitation true of all dynamic languages? This isn't a
python specific problem, but the side-effect of not requiring the
declaration of parameters, their "type", and the order in which they
are expected? Wouldn't you have the same issue you're describing with
Perl or Ruby?
Post by Michael L Torrie
The other major architectural limitation in python is the GIL, a giant
lock that synchronizes calls to the interpreters core. Thus
multithreaded programs can not utilize multiple processing units. In
practice this usually isn't a huge deal. I'd say much of the time a
multithreaded app is best done with an asynchronous library anyway, like
twisted. But threads have their place. Just be aware of this
limitation when doing heavy computations with python.
If I were doing heavy computations, I'd likely use Java. I know
that's a cop out. I'm not saying your concern is invalid. But, for
*me*, if I had to do threading or heavy processing I wouldn't use a
scripting language at all.

Thanks, for the heads up though, Michael.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Scott Paul Robertson
2007-02-15 01:47:04 UTC
Permalink
<snip>
4. I find Python to be clean and consistent all the way through, or at
least as much as any programming language can be. Certain themes show
up in many different places, such as dictionaries. A namespace is just
a dictionary, and defining a class is really just creating a dictionary
mapping names to attributes and methods.
<snip>
In a bit of follow-up to this point, I love the "pythonic" style. To me
it follows more of how I tend to think of problems, and lets me solve
things in an interesting and clean way.

I've done a decent variety of different things in Python since I started
using it, and find it meets my needs in many different spheres. My web
page is driven by Python. I've implemented AES in Python (it was "fast
enough"). I wrote a quick rainbow table for a truncated SHA1 hash in it
(C would've run faster). And I've done a web-based ticket system. In all
these cases Python has been up to the task, and generally fast enough
for me.

The real reason I keep using it is because I can code quickly,
efficiently, and correctly with Python.

You mentioned the 3 web-frameworks that Python has (Zope, Turbogears,
and Django). I'm a huge Django fan, and I'll just throw in some ofmy
reasons:
1. Loosely Coupled - You can use a single part of Django without the
rest. I do this on my website.
2. Pythonic API - It fits will with the rest of your code, and you don't
feel like it's out of place.
3. Quick - I can get a basic blog up in half-an-hour. I got the UUG
website overhauled to it's current state in 4 hours.
4. Friendly Community - This really does matter you know.
--
Scott Paul Robertson
http://spr.mahonri5.net
GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601
Bart Whiteley
2007-02-14 21:44:03 UTC
Permalink
Post by Daniel C.
Python, obviously.
+1 Python.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Steve
2007-02-14 21:47:59 UTC
Permalink
Take it from me, python sucks, just not as hard as ruby.
Actually all of your choices pretty much suck, I recommend writing a
language from scratch if you want to have a deep understanding of it's
internals. Maybe even use Lua as a base for that.
Post by Bart Whiteley
Post by Daniel C.
Python, obviously.
+1 Python.
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 21:52:18 UTC
Permalink
Post by Steve
Take it from me, python sucks, just not as hard as ruby.
Good. This started out well. I'd like to know why python sucks and
ruby even more so.
Post by Steve
Actually all of your choices pretty much suck, I recommend writing a
language from scratch if you want to have a deep understanding of it's
internals. Maybe even use Lua as a base for that.
And then it goes limp.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-14 21:56:43 UTC
Permalink
Post by Bryan Sant
And then it goes limp.
I love how you ask for advice and then spit on the advice people give.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 22:03:44 UTC
Permalink
Post by Daniel C.
Post by Bryan Sant
And then it goes limp.
I love how you ask for advice and then spit on the advice people give.
Your comments hardly qualify as advice. I'm not asking you to write a
full on paper. I just figured an avid Python user would be so excited
about it, that the virtues of it would just flow into an email. I'd
like *some* substance.

I could say, "C++ rulez". But that doesn't mean anything.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Ellis
2007-02-14 22:10:27 UTC
Permalink
Post by Bryan Sant
Post by Daniel C.
Post by Bryan Sant
And then it goes limp.
I love how you ask for advice and then spit on the advice people give.
Your comments hardly qualify as advice. I'm not asking you to write a
full on paper. I just figured an avid Python user would be so excited
about it, that the virtues of it would just flow into an email. I'd
like *some* substance.
Personally, I had the impression that Daniel was more of a Lisp guy, and
just liked Python best of your 3 finalists.

-Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-14 22:17:33 UTC
Permalink
Post by Jonathan Ellis
Personally, I had the impression that Daniel was more of a Lisp guy, and
just liked Python best of your 3 finalists.
You are correct. When I first read that someone was looking for a new
language to learn, my first thought was "Lisp!". I was all prepared
to enumerate the reasons for learning it. Then I discovered that
(tongue going into cheek, for those who may miss it...) the person
asking was a Java enthusiast, and realized that he probably isn't
intelligent enough to grasp Lisp.

So I recommended Python as a suitably dumbed-down substitute.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 22:44:43 UTC
Permalink
Post by Daniel C.
So I recommended Python as a suitably dumbed-down substitute.
Boohoo, I'm not smart enough for Lisp. At least I wont were out my (
and ) keys.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
garth h
2007-02-14 23:00:06 UTC
Permalink
Disclaimer: avowed Perl bigot speaking.

Here's why I would learn Perl before the other two:

I have minimal experience with Ruby and Python, and so can't comment on
their abilities. But as for Perl, regardless of whatever language I may use
in the future, having the Perl tool in the my belt will always serve me
well. I don't know of any other language that gives you the ability to
write throw-away programs with such ease. Larger programs are also
possible, but I don't think anyone shines brighter when it comes to getting
something hard done quick and easy. Want to do significant regex work in
multiple files? You can do it commandline. Want to do something a little
more complicated? A short script will do. I don't know of any other
language that steps out of your way better when it comes to IO and text
manipulation. I think Larry Wall stated the philosophy of Perl as something
like "make easy things easy and hard things possible." In the end, if you
don't use it for the final form of something, it's the best scratch paper
language that exists.

Also, I would say one of the most important keys in learning any language is
simply how much you *like* it, regardless of its speed or elegance or
whatever. I couldn't care less how Java isn't as sucky as it used to be, I
simply don't like it. I don't like the syntax, I don't like the verbosity,
I don't like the control it exerts over me. Sure, it's a great language and
has its place. I think arguing "speed" or something like that is just too
subjective. I bet my mod_perl app runs just as fast as whatever web app you
come up with. And I bet my C for loop beats your Java for loop. But, who
cares? The most important time factor is *your* time--how much time you're
going to spend learning and churning the language.

And yes, I do have experience programming in C/C++, Java, Visual Basic,
Pascal, Basic, etc. Perl opened my eyes to some new ideas that changed how
I think about programming in any language. And it kept me from wasting my
time on things that didn't matter to the task at hand. The same has been
said about Lisp, but it's not on your list.
--
Garth

A designer knows he has achieved perfection, not when there is nothing left
to add, but when there is nothing left to take away.
~Antoine de Saint-Exupery

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-14 22:14:03 UTC
Permalink
Post by Bryan Sant
Your comments hardly qualify as advice.
It wasn't my comment(s) that you were calling limp.

Also, I'm not an avid Python user.

I'm not on call to provide you with data on which to base your
decisions. You presented three options, I told you which I'd do if I
were you. There's plenty of information about Python available
online. In the time it's taken for us to have this exchange, you
could have gone and found much of it.

Others may be inclined to provide more verbose justifications for
their advice. I'm not.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 22:38:41 UTC
Permalink
Post by Daniel C.
I'm not on call to provide you with data on which to base your
Great. Bow out, and please let someone with some knowledge help inform me.
Post by Daniel C.
decisions. You presented three options, I told you which I'd do if I
were you. There's plenty of information about Python available
online. In the time it's taken for us to have this exchange, you
could have gone and found much of it.
I've already read much on all languages. I'd like some details from
people with first hand experience. I know we have a list full of
people who are very dedicated to their language of choice (you and
Lisp for example). I'd appreciate a few reviews from anyone who loves
their language of choice.
Post by Daniel C.
Others may be inclined to provide more verbose justifications for
their advice. I'm not.
Obviously.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jason Hall
2007-02-14 21:53:40 UTC
Permalink
Post by Bryan Sant
I'd like to learn one of the following well: Python, Ruby, or Perl.
Main Considerations:
1) Who will you work with in learning? Obviously if more of your friends know
Perl, it's helpful to learn that, so they can guide you.
2) How much do you want to change? Are you looking for a language that is
closer to Java? or a bigger change? ( Python shares the same love of S&M as
Java, so that would be easier, Perl is completely opposite, and Ruby tries to
have some of both)
3) Buzzwordy. We all know you love your buzzwords and hype :) So Ruby has a
lot in that direction for you. It is popular because it's newer, and has
many key features that Perl and Python are fixing.
4)Work use, will your daily job benefit more from a specific language (eg.
enhanced Perl knowledge will automate your life, Free your Mind, etc. Or
would jython have direct usability?)

--
Jayce^

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Andrew Jorgensen
2007-02-14 21:53:31 UTC
Permalink
Post by Bryan Sant
PS > Don't say, "You should use each one for what it's best at."
Screw that. I'm not interested in learning to create "Hello World" in
20 languages. I want to pick a language and acquire a deep
comprehensive knowledge of it. I'd rather be awesome at two or three
languages than so-so with 15. I want to pick ONE -- please make sure
it's the best.
I think this is the wrong approach. You can't have a deep
comprehensive knowledge of a language without programming something
significant in it. Pick a project that you think you can stick with
long enough and then, I'm sorry to say it but it's true, try to find
the language best suited to that project.

It would rock if you could actually pick one language that was truly
better than the rest but it's just not so. The reason there are so
many languages out there thriving (rather than many out there and one
winning) is that some things are best done with one rather than
another. You can't write a kernel in Java and you really shouldn't
write a startup script in C.

Let me say this one more time:
Pick a project first, then pick a language.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 22:26:40 UTC
Permalink
Post by Andrew Jorgensen
I think this is the wrong approach. You can't have a deep
comprehensive knowledge of a language without programming something
significant in it. Pick a project that you think you can stick with
long enough and then, I'm sorry to say it but it's true, try to find
the language best suited to that project.
Sound advice, sound advice. I intend to do just this. I'm just
hoping for a little guidance from the list. I was hoping that folks
could express why they think language X is so cool. I'll end up
picking one and I'll use that language to do something meaningful and
get some hands-on experience.
Post by Andrew Jorgensen
Pick a project first, then pick a language.
It seems to me that Ruby/Perl/Python all fill the same niche. In my
opinion, learning one of them gives you most of the benefit of any of
them. I'd just like to know which one would best jive with me. Any
project I pick would be equally applicable to every language I listed.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hans Fugal
2007-02-14 22:57:10 UTC
Permalink
Post by Bryan Sant
It seems to me that Ruby/Perl/Python all fill the same niche.
Then you truly do not understand the world. The world is not Java vs. C
vs. the script kiddies.
Post by Bryan Sant
In my
opinion, learning one of them gives you most of the benefit of any of
them. I'd just like to know which one would best jive with me. Any
project I pick would be equally applicable to every language I listed.
Perl is completely and utterly different from python and ruby at its
core (or vice versa as perl was here first). Python and ruby are perhaps
more alike, but still fundamentally different in their spheres.

In one sense, moving from Java to any scripting language will give you
considerable benefit/insight/whatever, in another sense that is just the
tip of the iceberg. I suppose you have to take that first step though.

Note, I am not saying scripting languages are better than
compiled/virtual machined languages. Indeed I would say the line is
harder to draw all the time. Ruby is getting a virtual machine in the
near future. Ruby and Java have a fascinating and fast-moving merger in
JRuby. Python already has bytecode. Who knows what perl6 has in store
(Jayce^, probably). I frequently consider projects that I would only do
in C (perhaps C++ or Java), and others that I would never do in anything
but Ruby.

That said, I haven't seen anything yet that drives me to learn python,
as I already know Ruby. I bet a lot of snakes feel the same way about
the red gem. I once could code my way out of a cardboard box in perl,
but these days I just use ruby. I think perl would be more applicable in
some applications, but I either don't play in those arenas or the effort
involved in remembering perl isn't worth it to me.

My own recommendation based on my personal preference is Ruby. I do have
substantiatable reasons but I frankly am tired of evangelising things to
people who will mostly turn around and do what they like based almost
entirely on emotion or convenience. (This goes for *NIX, vim, mutt,
top-posting, etc. It's not that I think evanglising is bad or
unimportant, or that I won't turn around and evanglise stuff in a
day/week/month/year. It's just that I'm tired of doing it)

I think Ruby would be a good fit for you because of JRuby. It's a
fast-moving project with some amazing potential (including addressing
the speed issue and interop with existing and future Java code), and
now with paid full-time developers thanks to Sun.

Ruby has, imho, the most supportive fun fantastic community (aside from
the more traditional buzz of the rails community), and the most
mind-bending paradigm shifting power (that's a good thing) of any of the
alternatives except perhaps smalltalk. There's my plug.

1. http://jruby.codehaus.org/
--
Hans Fugal ; http://hans.fugal.net

There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 23:05:12 UTC
Permalink
Post by Hans Fugal
Then you truly do not understand the world. The world is not Java vs. C
vs. the script kiddies.
Sure it is. Just read slashdot.
Post by Hans Fugal
Perl is completely and utterly different from python and ruby at its
core (or vice versa as perl was here first). Python and ruby are perhaps
more alike, but still fundamentally different in their spheres.
Fair enough.
Post by Hans Fugal
In one sense, moving from Java to any scripting language will give you
considerable benefit/insight/whatever, in another sense that is just the
tip of the iceberg. I suppose you have to take that first step though.
I've used dynamic languages before, I don't think I'm *that*
uninitiated. Maybe you're right. I'll find out shortly.
Post by Hans Fugal
I think Ruby would be a good fit for you because of JRuby. It's a
fast-moving project with some amazing potential (including addressing
the speed issue and interop with existing and future Java code), and
now with paid full-time developers thanks to Sun.
Ruby has, imho, the most supportive fun fantastic community (aside from
the more traditional buzz of the rails community), and the most
mind-bending paradigm shifting power (that's a good thing) of any of the
alternatives except perhaps smalltalk. There's my plug.
1. http://jruby.codehaus.org/
Thank you.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jesse Stay
2007-02-14 21:57:54 UTC
Permalink
Post by Bryan Sant
Perl. I like the fact that Perl is everywhere. You can't swing a
dead cat by the tail without hitting into a Perl interpreter. I like
that Perl is mature. One word, CPAN. All of this is great, but I
DON'T like the whole, "there's more than one way to do it" deal. More
than one way? That's a I nice way of saying that every Perl program
is as unique as a snow flake. I'd like to use a language that others
(and even ME after 6 months) can read. My own experience backs up the
claims that Perl is a "write only" language. This may be overly
dramatic, and Perl may be more readable than I think if I spent some
more time with it. Help me learn to love Perl.
One good book that will help you love perl:

Perl Best Practices by Damian Conway

Also:

Higher Order Perl, by Mark Jason Dominus

The first is one every Perl programmer should read. There are Perl
programmers, and then there are Perl programmers that have read Perl
Best Practices - you will see a firm standard in writing code by those
that have read it. Their code will be much easier to read.

The second has some excellent examples of why OO is not always the
best way to do things. It goes over recursion, writing programs that
can be "programmed", and other great methods of using Perl to write
great programs.

Jesse
--
#!/usr/bin/perl
$^=q;@!>~|{>krw>yn{u<$$<Sn||n<|}j=<$$<Yn{u<Qjltn{ > 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-14 22:13:57 UTC
Permalink
Post by Jesse Stay
Perl Best Practices by Damian Conway
Higher Order Perl, by Mark Jason Dominus
Thank you. I'll take a look.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jason Hall
2007-02-14 22:15:12 UTC
Permalink
The first is one every Perl programmer should read.  There are Perl
programmers, and then there are Perl programmers that have read Perl
Best Practices - you will see a firm standard in writing code by those
that have read it.  Their code will be much easier to read.
Speaking of that, when are you getting around to reading it? :)

--
Jayce^

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jesse Stay
2007-02-14 22:17:36 UTC
Permalink
Alright. Now that wasn't fair. Here was my response to Jayce^:

:-)

---------- Forwarded message ----------
From: Jesse Stay <jesse-57c3ABav1/***@public.gmane.org>
Date: Feb 14, 2007 3:14 PM
Subject: Re: *****SPAM***** Re: I want to learn a new language...
The first is one every Perl programmer should read. There are Perl
programmers, and then there are Perl programmers that have read Perl
Best Practices - you will see a firm standard in writing code by those
that have read it. Their code will be much easier to read.
Speaking of that, when are you getting around to reading it? :)
I've read it already. Are you jealous? ;-)

--

#!/usr/bin/perl
$^=q;@!>~|{>krw>yn{u<$$<Sn||n<|}j=<$$<Yn{u<Qjltn{ > 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael Brailsford
2007-02-14 22:54:30 UTC
Permalink
Alright, I used to be a major ruby fan boy. I would never consider programming perl, ever. Then I graduated and had to get a job. Guess what? The only job at the time was a job writing a web app with perl. So guess what, I now know perl a lot better than ruby. I still love ruby and use it wherever I can. But I have a problem with it, I don't want to install an interpreter just to use a script. You see, I wouldn't have a problem with that if I worked on a small set of Linux machines, but I work with AIX, HPUX, and OpenVMS. Thankfully the VMS is deprecated, but I still have to use it. Guess which languages are available to use on all those platforms by default? NONE. Perl and Korn shell are on all the Unix boxen. DCL is the only thing available by default on VMS. Thankfully, the admins here put perl on VMS. Oh yeah, did I mention I have to run these scripts on 10s-100s of these machines, most of which I don't have root access to? So you see, your choices should be limited to that which you have available. If you know for sure you will always have a python or ruby interpreter on the machines you have to use, then use them by all means. In the real world, they frown on developers installing language interpreters for a few scripts. Bosses have mostly heard of perl and so you generally get management on your side to include lots of perl scripts. But try selling the merits of Ruby and Python to a few PHBs that don't grok tech the way you do, you will soon start using what you have and focus your efforts on pushing for really important things like unit testing frameworks, refactoring projects, etc...

In the end, when I want/need to do something at work, I use perl. Not because I prefer the language, but because its the most practical choice. I have used Ruby for about 5 years, but I use perl everyday instead of pushing ruby. Its easier and better supported and it looks good on a resume. With perl I have written an automated cross platform C++ build system, a cscope web front-end, dependency graphing tool and other stuff. All in my spare time, which is rare around here.

I most heartily second the "Perl Best Practices" book! It is a very well written book. It also contains A LOT of non-perl specific best practices. I recommend it to everyone, whether you use perl or not. My programming-fu skills greatly benefitted from reading it.

So I guess I recommend perl purely for the practicality. If your criteria is less practical, I very highly recommend ruby. It is a very clean language, and very easy to work with.

-Michael

----- Original Message ----
From: Jesse Stay <jesse-57c3ABav1/***@public.gmane.org>
To: Provo Linux Users Group Mailing List <plug-***@public.gmane.org>
Sent: Wednesday, February 14, 2007 3:57:54 PM
Subject: Re: I want to learn a new language...
Post by Bryan Sant
Perl. I like the fact that Perl is everywhere. You can't swing a
dead cat by the tail without hitting into a Perl interpreter. I like
that Perl is mature. One word, CPAN. All of this is great, but I
DON'T like the whole, "there's more than one way to do it" deal. More
than one way? That's a I nice way of saying that every Perl program
is as unique as a snow flake. I'd like to use a language that others
(and even ME after 6 months) can read. My own experience backs up the
claims that Perl is a "write only" language. This may be overly
dramatic, and Perl may be more readable than I think if I spent some
more time with it. Help me learn to love Perl.
One good book that will help you love perl:

Perl Best Practices by Damian Conway

Also:

Higher Order Perl, by Mark Jason Dominus

The first is one every Perl programmer should read. There are Perl
programmers, and then there are Perl programmers that have read Perl
Best Practices - you will see a firm standard in writing code by those
that have read it. Their code will be much easier to read.

The second has some excellent examples of why OO is not always the
best way to do things. It goes over recursion, writing programs that
can be "programmed", and other great methods of using Perl to write
great programs.

Jesse
--
#!/usr/bin/perl
$^=q;@!>~|{>krw>yn{u<$$<Sn||n<|}j=<$$<Yn{u<Qjltn{ > 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/




/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-14 23:04:58 UTC
Permalink
Post by Bryan Sant
Python. Python is the front runner for me. I like speed and Python
is comparatively fast. I like that Python is on most Linux systems
(but no UNIX systems in the entire world).
Jython may be good for you. It's python implemented in Java and can
access the full java class library from python, as well as the standard
python library.

Michael
Post by Bryan Sant
I like that Python is very
readable and confines developers to use a similar layout and style. I
like that Python is named after a Monty Python. I think snakes are
cool. On the down side, I heard that Python didn't originally have OO
capabilities and that this was later bolted on (the same is true for
Perl). I get my OO, so what am I complaining about? Well, when you
don't have to use OO, you often find code snippets and other
developers who haven't bothered to learn and write OO code, so you're
stuck with crap semi-OO code or none at all. Ruby being OO from the
start seems like it would have a better object oriented standard lib
and a more OO competent user community. I also don't like that Python
has Zope, TurboGears, and Django. Ruby seems to have just one popular
web framework instead of three to learn (yes, I don't have to learn
all three, but I will come across them sooner or later).
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Mark Higbee
2007-02-14 23:03:04 UTC
Permalink
If you want to learn a fun language that doesn't require an IDE and
minimal typing Perl is the language for you.

I would caution that if you do too much Perl programming you may become
less excited about Java at least that is what happened to me.
I found my self saying all the time Wow I wish you could to that in
Java. Not that I was ever into Java as much as you are but Java was my
first programming language.

I do agree that many Perl programmers write code that can be hard to
figure out and maintain, however it is possible to write code that is
easy to maintain and follows good coding styles and standards just like
any other language.
Post by Bryan Sant
Contrary to popular belief, I'm not a complete and total Java bigot...
Okay, I lied, I am. Java is the shiz-nigget. However, I'm honestly
wanting to invest in a new language for fun and profit.
I have a decent background in bash/shell, Perl, and I've played with
Ruby and Python. One of the reasons that I'm so passionate about Java
is because it gets ganged up on by all of the scripting language
enthusiasts collectively. Java is pitted against the best features of
Ruby, Perl, Python, Lisp, Smalltalk, PHP, and even Haskell, OCaml, D,
and C/C++. Is Java going to beat the collective power of all of these
languages? Of course not (but it would be close :-).
Collectively the development language landscape is lush. But if I
(the operative word is *I*, I'm speaking for myself) peel off any one
of those languages and evaluate it by itself, it loses it's appeal
compared to Java. I sincerely want to learn a new language well, but
as I start to dig in to each language, I find warts that are even
uglier than the step-child that is Java.
I'd like to learn one of the following well: Python, Ruby, or Perl.
Ruby. You'd think this one would be a slam dunk for me. It's OO,
it's hip, it gets all the press. But Ruby is the
SLOOOOOOOOOOOOoooooooooooowest freaking language ever invented. It's
not just kind of slow it is so slow that it's embarrassing. For MOST
tasks, I'm sure that doesn't matter. When dealing with the web, the
bottleneck is the network. Utilities or shell-ish scripts don't need
to be fast. I could be convinced that speed is less important than
some other uber cool features in the language.
Perl. I like the fact that Perl is everywhere. You can't swing a
dead cat by the tail without hitting into a Perl interpreter. I like
that Perl is mature. One word, CPAN. All of this is great, but I
DON'T like the whole, "there's more than one way to do it" deal. More
than one way? That's a I nice way of saying that every Perl program
is as unique as a snow flake. I'd like to use a language that others
(and even ME after 6 months) can read. My own experience backs up the
claims that Perl is a "write only" language. This may be overly
dramatic, and Perl may be more readable than I think if I spent some
more time with it. Help me learn to love Perl.
Python. Python is the front runner for me. I like speed and Python
is comparatively fast. I like that Python is on most Linux systems
(but no UNIX systems in the entire world). I like that Python is very
readable and confines developers to use a similar layout and style. I
like that Python is named after a Monty Python. I think snakes are
cool. On the down side, I heard that Python didn't originally have OO
capabilities and that this was later bolted on (the same is true for
Perl). I get my OO, so what am I complaining about? Well, when you
don't have to use OO, you often find code snippets and other
developers who haven't bothered to learn and write OO code, so you're
stuck with crap semi-OO code or none at all. Ruby being OO from the
start seems like it would have a better object oriented standard lib
and a more OO competent user community. I also don't like that Python
has Zope, TurboGears, and Django. Ruby seems to have just one popular
web framework instead of three to learn (yes, I don't have to learn
all three, but I will come across them sooner or later).
Please advice.
PS > Don't say, "You should use each one for what it's best at."
Screw that. I'm not interested in learning to create "Hello World" in
20 languages. I want to pick a language and acquire a deep
comprehensive knowledge of it. I'd rather be awesome at two or three
languages than so-so with 15. I want to pick ONE -- please make sure
it's the best.
Thanks in advance,
-Bryan
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jesse Stay
2007-02-14 23:20:26 UTC
Permalink
Post by Bryan Sant
Contrary to popular belief, I'm not a complete and total Java bigot...
Okay, I lied, I am. Java is the shiz-nigget. However, I'm honestly
wanting to invest in a new language for fun and profit.
Honestly, even though my license plate says "USE PERL", I think you're
taking the right path. The more languages you learn, the more you can
apply and contribute to the language you prefer. C gives fundamental
memory and process management skills. Lisp gives great functional
skills. Ruby and Java give great OOP skills. They also contribute
great MVC knowledge and ideas. PHP is a great web language that keeps
writing for the web simple. Perl, whether you like it or not, has
TIMTOWTDI and has contributed quite a bit of knowledge to the regex
libraries in various languages. I think there are things that are
encouraged in each, that can be applied in many ways to your preferred
language. Do they each have their flaws? Yes, but the strengths from
other languages I believe can be brought into any language out there.
It doesn't matter the language you program in - what matters is what
you do with the language you prefer.

Jesse
--
#!/usr/bin/perl
$^=q;@!>~|{>krw>yn{u<$$<Sn||n<|}j=<$$<Yn{u<Qjltn{ > 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Ellis
2007-02-14 23:22:18 UTC
Permalink
On Wed, 14 Feb 2007 14:30:41 -0700, "Bryan Sant" <bryan.sant-***@public.gmane.org>
said:

I've written production code in all three languages you mention (the
Perl was a long time ago, but I have no desire to go back for a
refresher), and I prefer Python; I find it elegant but practical. My
second pick would be Ruby.
Post by Bryan Sant
On the down side, I heard that Python didn't originally have OO
capabilities and that this was later bolted on (the same is true for
Perl).
Python's OO is more smalltalkish than javaish, and it doesn't force you
into "thou shalt write everything as classes," but it's OO to the core.
See http://www.prescod.net/python/OOMyth.html

This also seems apropos:
http://spyced.blogspot.com/2005/10/why-do-java-programmers-like-ruby.html

Also, since you're probably used to Eclipse already, you should check
out PyDev. It's one of the best free IDEs for a dynamic language.

Finally, a bunch of helpful people hang out in
irc://irc.freenode.net/#utahpython

-Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-14 23:42:03 UTC
Permalink
So, here's my take on these three languages:

Perl is an accretion of very useful features glued together on top of
a fairly elegant, nearly Lisp-like core. However, the accretive
nature shows itself quite plainly; it's got 'awk'ward pieces and
'sed'iment littered throughout its syntax and semantics. It's full of
quirks, corner cases, and ad-hoc design decisions that were created to
make particular patterns of use very convenient. This all makes it a
complex language that you can pick up the basics of very easily, but
requires a lot of reading and conversing with arcane masters to
explore all the nooks and crannies of. If you're not planning on
using it frequently, it's probably not worth it, because you'll forget
a lot of these details between uses. People who use it all the time
tell me that they remember just fine; maybe it's just me. Anyway, the
true raison d'etre of Perl is Unix system administration. Despite its
flaws, and whether you love it or hate it, it nearly always wins at
this one task. Sometimes it's because of the text manipulation tools,
sometimes it's due to bindings or CPAN modules. If you don't care
about Unix system administration, I would give it lower consideration.

Python was, at one point, my favorite language. I didn't have
exposure to many languages at that time, but it was very easy for me
to pick up and I was immediately able to create useful programs. It's
a very clean language, and the way to do things is generally fairly
obvious. I have a few nits to pick with it, but they're not serious
flaws as far as I'm concerned. Also, anyone who tells you Python
isn't really object oriented is probably using a different definition
of 'object oriented' than you are. It's a very object-oriented
language indeed, though some of the machinery is exposed (though not
to the absurd extent of OO perl). It's very dynamic, flexible, and
powerful. It's reasonably fast. It's got a fairly good set of
libraries. I don't see any big reason not to choose Python.

I don't have as much to say about Ruby, because I've never actually
used it. I like it a lot conceptually, since it marries the Smalltalk
object model with some Lispy sensibilities. However, you've already
seen some of my concerns about the language and its current
implementation. I also don't like the fact that blocks are relegated
to the final argument position, and have some odd quirks compared to
their Smalltalk counterparts. I think Ruby has the potential to be
very fun, though; perhaps more so than Python, and far more so than
Perl, which I can only hate because of the mess that it is. I will
probably learn a bit of it myself, sometime, someday, if its current
popularity trend holds.

Those are my opinions; you'll have to decide for yourself which one
you want to learn, since the languages I would suggest are not options
you listed.

--Levi

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-15 17:40:58 UTC
Permalink
Post by Levi Pearson
I don't have as much to say about Ruby, because I've never actually
used it. I like it a lot conceptually, since it marries the Smalltalk
object model with some Lispy sensibilities. However, you've already
seen some of my concerns about the language and its current
implementation. I also don't like the fact that blocks are relegated
to the final argument position, and have some odd quirks compared to
their Smalltalk counterparts. I think Ruby has the potential to be
very fun, though; perhaps more so than Python, and far more so than
Perl, which I can only hate because of the mess that it is. I will
probably learn a bit of it myself, sometime, someday, if its current
popularity trend holds.
What's wrong with blocks being the last arg? How would you prefer it
(don't know how smalltalk does it)?

Thanks Levi,
-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-15 18:45:10 UTC
Permalink
Post by Bryan Sant
What's wrong with blocks being the last arg? How would you prefer it
(don't know how smalltalk does it)?
Well, Smalltalk allows a block in any argument place, giving them
first-class status. This is due to the fact that Smalltalk has a very
simple syntactic and semantic model based on message-passing between
objects. There are no syntactic control structures like loops,
conditionals, etc. All of those things are constructed via classses,
messages, and blocks. For example, let me describe how an if/then
statement is implemented:

(a > b) ifTrue: [ a ] ifFalse: [ b ]

The evaluation process first passes the > message to a with b as an
argument. The object referred to by a then evaluates the primitive >
operation and returns either the canonical true or false object. That
object then receives the ifTrue:ifFalse message with two blocks as
arguments. Block contents are not evaluated when they are
constructed. If the object receiving this message is the true object,
it will evaluate the ifTrue block. If the object receiving this
message is the false object, it will evaluate the false object. Thus,
we have been able to build conditional execution without having it
primitive in the language.

This would, of course, be horribly inefficient with a naive compiler,
but people have been working on making this fast since the late 70s,
and they have done a very good job of it. A good Smalltalk
implementation should be in the same ballpark as Java depending on the
sort of application you're writing with it. Strongtalk had just about
achieved that when the developers were aquired by Sun and put to work
on Java. It also has an optional static typing system that you can
use to alleviate bugs that crop up due to type errors, though
interestingly enough that type system wasn't even used by the
mechanisms that made it so fast.

As a side note, Smalltalk syntax has some distinct advantages for
self-documenting code. Messages have named arguments, so it is always
clear when you see a message send what the parameters mean. Ruby
chose to do away with this in order to appeal to programmers coming
from languages syntactically similar to C, and I can understand that
motivation, but it makes me sad. As far as I'm concerned, Smalltalk
is far superior to Ruby for systems and application work, while Ruby
has distinct advantages in the scripting and glue departments.

--Levi




/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-15 18:58:17 UTC
Permalink
Post by Levi Pearson
As a side note, Smalltalk syntax has some distinct advantages for
self-documenting code. Messages have named arguments, so it is always
clear when you see a message send what the parameters mean. Ruby
chose to do away with this in order to appeal to programmers coming
from languages syntactically similar to C, and I can understand that
motivation, but it makes me sad. As far as I'm concerned, Smalltalk
is far superior to Ruby for systems and application work, while Ruby
has distinct advantages in the scripting and glue departments.
I think one of the things that prevented Smalltalk from gaining a lot
of traction in app development was the fact that Smalltalk was like its
own operating system. Smalltalk objects where created by the IDE that
was part of smalltalk, and the only way to save your work was to dump
the environment out to disk. Were later implementations more like a
traditional environment where source could could be loaded/compiled and
executed?

Years ago my uncle worked at Wordperfect on a language that was intended
to be embedded in WordPerfect, DataPerfect, and the like. It was called
Tool and was based on Smalltalk (bootstrapped from smalltalk actually).
It was very cool at the time. Like smalltalk it had an integrated IDE
and debugger. It was also a similar syntax to Smalltalk. Can't
remember all the advantages it had over smalltalk. I'll have to dig up
the documentation I still have on it.
Post by Levi Pearson
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-15 19:25:58 UTC
Permalink
Post by Michael L Torrie
I think one of the things that prevented Smalltalk from gaining a lot
of traction in app development was the fact that Smalltalk was like its
own operating system. Smalltalk objects where created by the IDE that
was part of smalltalk, and the only way to save your work was to dump
the environment out to disk. Were later implementations more like a
traditional environment where source could could be loaded/compiled and
executed?
I don't think that itself was a big problem. The commercial
Smalltalks (and Lisps, which follow the same image-based strategy) had
version control systems and tree-shakers, which remove the IDE-related
stuff from the app executable when an image is created for
distribution. Java is essentially the same, though the image is
rebuilt every time you run an application instead of being a frozen
set. Smalltalk actually did get a lot of traction in a few
industries, especially the financial industry in Wall Street. I still
see Smalltalk job openings there occasionally. I think the main
reason it lost to Java was price and marketing strategy.

Anyway, if you really must work with files and build your image from
scratch every time, GNU Smalltalk works on that model. There's also
some work being done with Squeak to modularize it and make it more
suited for traditional app development, though it's going very slowly
since there are already other Smalltalks well-suited to that. Dolphin
Smalltalk is an excellent, fast implementation for Windows that
creates native-GUI apps with standalone executables. You work with
the image, but you can version control everything, so it doesn't feel
terribly different than working in an IDE with regular files.
Post by Michael L Torrie
Years ago my uncle worked at Wordperfect on a language that was intended
to be embedded in WordPerfect, DataPerfect, and the like. It was called
Tool and was based on Smalltalk (bootstrapped from smalltalk actually).
It was very cool at the time. Like smalltalk it had an integrated IDE
and debugger. It was also a similar syntax to Smalltalk. Can't
remember all the advantages it had over smalltalk. I'll have to dig up
the documentation I still have on it.
Domain-specific languages often have advantages over their host
languages for the domain they were created for. Why else would they
exist? It doesn't sound like it would be very useful outside of the
WordPerfect suite, though.

--Levi

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jacob Fugal
2007-02-15 19:13:05 UTC
Permalink
Post by Levi Pearson
Post by Bryan Sant
What's wrong with blocks being the last arg? How would you prefer it
(don't know how smalltalk does it)?
Well, Smalltalk allows a block in any argument place, giving them
first-class status.
For a clarification, Ruby does have first-class code blocks. They can
be created various ways. These "procs", as they're known in Ruby, can
be assigned to variables, passed as arguments (any position), etc.

"Blocks", which are (mostly[1]) as subset of procs, *are* relegated to
the last argument however. Blocks are a special code block that
immediately follows a method invocation. They do not need the "proc"
or "lambda" keywords, which makes their appearance a bit cleaner. They
are also the target of the "yield" keyword invoked in the method body.
These traits raise them up to a special status beyond that of normal
procs. A proc can be converted to a block and vice versa. For example,
the following are equivalent:

# the curly braces delimit the block
collection.each{ |element| ... }

and

# the unary-& converts the proc to a block
block = proc{ |element| ... }
collection.each(&block)

These blocks are relegated, as Levi said, to the final position for
practical considerations: 1) without named parameters (I agree with
Levi that they would be nice to have), any syntax for multiple blocks
becomes confusing and/or ambiguous; 2) the "yield" keyword is intended
to be as simple as possible and requiring a block-distinguishing
parameter would clutter it.

So, to come back to Levi's example about Smalltalk's ifTrue:ifFalse, a
similar construct is *technically* possible in Ruby:

class TrueClass
def branch(true_proc, false_proc)
true_proc.call
end
end

class FalseClass
def branch(true_proc, false_proc)
false_proc.call
end
end

(x < 1).branch(
proc{ puts "x is less than 1" },
proc{ puts "x is greather than 1" }
)

The beauty that Smalltalk affords just isn't there however, due to the
extra noise of the proc keyword and the lack of named parameters.

Jacob Fugal

[1] I say "mostly" because the current implementation of Ruby actually
treats blocks and procs (and even amongst procs, depending on which
creation method was used) differently in some subtle ways. One is in
how mismatches in definition vs. call arities is handled. This is an
acknowledged wart and the multiple variations of "proc" are being
unified in the development going on for Ruby 1.9/2.0.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-15 19:44:16 UTC
Permalink
Post by Jacob Fugal
For a clarification, Ruby does have first-class code blocks. They can
be created various ways. These "procs", as they're known in Ruby, can
be assigned to variables, passed as arguments (any position), etc.
Thanks for clarifying that. I'd seen most of that before, but I
didn't recall the details. However, your clarification did illustrate
one of the problems I have with Ruby, in that it's got those kinds of
quirks that currently make it difficult to fully understand it, and
difficult to make another Ruby implementation. I imagine a lot of the
quirks will go away with time as Ruby matures, though.

--Levi

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jacob Fugal
2007-02-15 20:09:59 UTC
Permalink
one of the problems I have with Ruby [is] that it's got those kinds of
quirks that currently make it difficult to fully understand it, and
difficult to make another Ruby implementation. I imagine a lot of the
quirks will go away with time as Ruby matures, though.
I agree those quirks are present. While I still love Ruby despite
them, I want them to go away too. There's been a recent surge in
alternative implementations of Ruby and from the conversations I've
followed, they've run into those quirks as well.

Fortunately, the multiple implementors (including the canonical
implementations of pre-1.9 C-ruby and post-1.9 YARV) have begun to
coordinate amongst themselves. At the last RubyConf there was an
Implementor's Summit, and at the upcoming MountainWest RubyConf (held
in our own Salt Lake) there will be another summit. Charles Nutter and
Thomas Enebo (JRuby), Evan Phoenix (rubinius -- ruby written in ruby
with a smalltalkish VM), John Lam (RubyCLR), and our own BYU alumnus
Kevin Tew (Cardinal -- Ruby on Parrot) will all be present.

Ruby has some maturing to do and has had growing pains, especially
recently. I believe the future continues to be bright, however.

Jacob Fugal

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hans Fugal
2007-02-15 21:36:33 UTC
Permalink
Post by Levi Pearson
implementation. I also don't like the fact that blocks are relegated
to the final argument position, and have some odd quirks compared to
their Smalltalk counterparts. I think Ruby has the potential to be
This is because blocks are almost never passed as parameters but as a
block following the method call. Incidentally, you can wrap up a block
with lambda/proc or even pass a method, as any parameter you want, and
then yield it (or call it) explicitly. They're not really relegated to
only the last position.

If you vote for Ruby, all your wildest dreams will come true.
--
Hans Fugal ; http://hans.fugal.net

There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
Bryan Sant
2007-02-15 21:42:20 UTC
Permalink
Post by Hans Fugal
If you vote for Ruby, all your wildest dreams will come true.
Wo. Say no more. All of my wildest dreams eh... Have you ever come
across anything like time travel on the Internet?

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Steve
2007-02-15 21:47:08 UTC
Permalink
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.

Just my 2c

Regards,
Post by Bryan Sant
Post by Hans Fugal
If you vote for Ruby, all your wildest dreams will come true.
Wo. Say no more. All of my wildest dreams eh... Have you ever come
across anything like time travel on the Internet?
-Bryan
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Andrew Jorgensen
2007-02-15 21:49:25 UTC
Permalink
Post by Steve
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.
'cause it's a web language. Anyone who wants to make it more than
that is silly.

Java is too but more that's more debatable.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-15 21:56:31 UTC
Permalink
Post by Andrew Jorgensen
Post by Steve
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.
'cause it's a web language. Anyone who wants to make it more than
that is silly.
Nay, not so. PHP is a good general-domain language. In fact, if you
wanted to, you could write full-blown GUI apps with it. I don't know of
anyone doing it, but a full GTK app would be no more difficult or less
powerful in PHP than it would be in python or perl.

Before I got heavily into Python, I used php for more things than web
programming. In fact, php makes a great general-purpose scripting
language. The plethora of built-in libraries make doing things like
hacking a quick script to add a field to every ldap record on my server
very easy. It seemed to me to be a good mix of perl and C, but was able
to do many things bash does also. Up until recently most of my main
system administration scripts were written in php, mainly because of the
ease of use of the ldap routines.

On the subject of full-blown apps, I think the age of the dynamic
language has truly come in this area. I think it is silly to do UI
stuff in the static, compiled languages like Java or C++. For me, I
plan to do almost all GTK gui work in python from now on.

The simplicity and power of embedding python into a C or C++ app means
it just doesn't make a lot of sense to do the more mind-numbing GUI
coding in C or C++. In fact, one of the great advantages of python is
that there is no difference between embedding python in a C program or
extending python with C. It's the same stuff. Therefore it makes sense
to code in python generally, calling out to C or C++ (or Java with
jython or what have you) for some things that have to be done there.
This makes python a better choice for general programming than php
(which has a not so wonderful C API).

Michael
Post by Andrew Jorgensen
Java is too but more that's more debatable.
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-15 22:02:30 UTC
Permalink
Post by Michael L Torrie
Nay, not so. PHP is a good general-domain language.
PHP *can* be used as a general-domain language. However it was
developed to be a web development language, and was hacked into other
domains later.

PHP is the language I know best. I use it all the time to develop web
pages, and I have used it in the past to do other things - shell
scripts, text file parsing, even billing scripts that were run by a
cron job.

But because a language is capable of doing these things does not make
it "good" at doing them, and certainly doesn't make it the best
choice.

Dan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-15 21:49:49 UTC
Permalink
Post by Steve
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.
PHP is only good for web development.

Some would argue, quite convincingly, that it's not even "good" for that.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Duncan
2007-02-15 21:51:23 UTC
Permalink
Post by Daniel C.
Post by Steve
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.
PHP is only good for web development.
Some would argue, quite convincingly, that it's not even "good" for that.
I use PHP for shell scripting. Quite handy.

Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-15 21:59:19 UTC
Permalink
Post by Jonathan Duncan
I use PHP for shell scripting. Quite handy.
I use a screw and a pair of pliers to open bottles of wine. It's
easy, you just screw the screw into the cork with a screwdriver, then
grab it with a pair of pliers and yank the sucker right out of there.
Sometimes you have to have someone else hold the bottle so you can get
both hands on the pliers. If you do that, you have to be careful not
to spill the wine when the cork pops out.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Duncan
2007-02-15 22:16:09 UTC
Permalink
Post by Daniel C.
Post by Jonathan Duncan
I use PHP for shell scripting. Quite handy.
I use a screw and a pair of pliers to open bottles of wine. It's
easy, you just screw the screw into the cork with a screwdriver, then
grab it with a pair of pliers and yank the sucker right out of there.
Sometimes you have to have someone else hold the bottle so you can get
both hands on the pliers. If you do that, you have to be careful not
to spill the wine when the cork pops out.
Wow, that is quite resourceful of you. I just use a hammer and pick out
the glass slivers. Same great taste, less filling. Pardon me, I have
some holes to plug...

Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Mike Heath
2007-02-15 21:53:36 UTC
Permalink
Post by Daniel C.
Post by Steve
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.
PHP is only good for web development.
Some would argue, quite convincingly, that it's not even "good" for that.
PHP is "good" for web development the same way that VB is "good" for
GUI development. They're the fast food of software development.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-15 22:03:16 UTC
Permalink
Post by Mike Heath
PHP is "good" for web development the same way that VB is "good" for
GUI development. They're the fast food of software development.
That's a bunch of BS, frankly. PHP may have quirks that lend itself
well to bad programming, but so do many other languages. I may not much
like php anymore myself, but that still doesn't make your assertion
true.

Furthermore there's nothing wrong with using VB for app development if
you chose to do so. Frankly it did for windows what the plethora of
good scripting languages has done for linux. It (for better or worse)
made programming accessible again. One could, in fact, write a good
clean app in VB6 if he chose. Of course VB.net is now as technically
good as C#, although many people dislike VB simply for the verbose
keyword set. Some like the curly braces!

Now the ratio of good php (or vb) apps to bad isn't so great, granted.
Whether to blame the language for the programmer's mistakes is an
ongoing (as we see here on this list) debate.

Michael

P.S. vim is the superior editor.
Post by Mike Heath
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-15 22:07:38 UTC
Permalink
Post by Michael L Torrie
Post by Mike Heath
PHP is "good" for web development the same way that VB is "good" for
GUI development. They're the fast food of software development.
That's a bunch of BS, frankly.
PHP has a very low barrier to entry. So does the fast food industry.
I find the comparison apt, especially when you consider that
McDonald's is a billion dollar, multinational corporation. It'd be
even better if there were fast food places that served gourmet food,
proving that just because it's fast food doesn't mean it can't be high
quality.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-15 22:22:14 UTC
Permalink
Post by Daniel C.
Post by Michael L Torrie
Post by Mike Heath
PHP is "good" for web development the same way that VB is "good" for
GUI development. They're the fast food of software development.
That's a bunch of BS, frankly.
PHP has a very low barrier to entry. So does the fast food industry.
I find the comparison apt, especially when you consider that
McDonald's is a billion dollar, multinational corporation. It'd be
even better if there were fast food places that served gourmet food,
proving that just because it's fast food doesn't mean it can't be high
quality.
I'd have to agree there. Except in the case of programming languages,
the quality of the program is almost solely dependent on the programmer
unless the libraries are bad, which has happened before with just about
any langauge.
Post by Daniel C.
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Ellis
2007-02-15 22:09:58 UTC
Permalink
On Thu, 15 Feb 2007 15:03:16 -0700, "Michael L Torrie"
Post by Michael L Torrie
Post by Mike Heath
PHP is "good" for web development the same way that VB is "good" for
GUI development. They're the fast food of software development.
That's a bunch of BS, frankly.
If anything it's unfair to VB. :P

It's okay to have a soft spot in your heart for PHP because it was your
first exposure to web dev or whatever. I have the same nostalgia for
Turbo Pascal. But don't confuse that with thinking that PHP is actually
a good language.

-Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Michael L Torrie
2007-02-15 22:20:34 UTC
Permalink
Post by Jonathan Ellis
It's okay to have a soft spot in your heart for PHP because it was your
first exposure to web dev or whatever. I have the same nostalgia for
Turbo Pascal. But don't confuse that with thinking that PHP is actually
a good language.
State the reasons why PHP is not a good language.

I'll start:

- no variable declarations
- non-secure legacy stuff is often enabled by default ($postvars for ex)

Of course #2 is not an issue anymore and #1 is moot because all the good
languages seem to have this feature too.

Reasons why VB6 sucks
- Overly verbose
- Not truly compiled
- Has object-oriented syntax, but is not object-oriented
- no pointers
- variable declaration is optional

Of course VB.net fixes almost all of these points, although some are
merely personal preference.

So if your reasons for saying php is a bad language come from your own
personal preferences, then we can't say php sucks. I dislike Java
strongly for various reasons, but they are almost all mostly personal
preferences. Therefore I cannot say Java sucks with any authority.
Post by Jonathan Ellis
-Jonathan
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Mike Heath
2007-02-15 22:20:51 UTC
Permalink
Post by Mike Heath
PHP is "good" for web development the same way that VB is "good" for
GUI development. They're the fast food of software development.
That's a bunch of BS.
How is this BS? I never said either was bad or shouldn't be used.
Both are great for quick applications just like fast food is great for
satisfying your appetite when you're in a hurry.

In my experience, neither one is well suited for large projects with
many developers. For building more than trivial applications, I think
there are other languages that have much better frameworks than what
is available with PHP.

If you want to move up the pay scale, PHP is not the way to do it. If
you want to move up the pay scale in the food industry, flipping
burgers is not the way to do it either. Both can get you through
college though.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-15 22:07:53 UTC
Permalink
Post by Steve
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.
Relatively respectable amongst people who aren't particularly
concerned with good language design, perhaps. It's a hack of
monumental proportions; an undead example of the 'design by accretion'
philosphy, but without the smart people that Perl had. It should have
remained 'Personal Home Page' and left programming to languages that
were designed for programming.

--Levi

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-15 22:08:48 UTC
Permalink
Post by Steve
Just curious but why was PHP not brought up in the debate?
It's widely used, relatively respectable language, and there seems to
be a hot market right now for PHP programmers, add that to the Java
skills and your talking a pretty good paying job.
Just my 2c
Regards,
Fair question. I have no problem with PHP itself and I should dabble
a little bit with it too (just to know some). But I'll retract my
comment about not caring about the community of the language. My
feeling is that the PHP community is primarily composed of
beginner/sloppy developers. There is no rails equivalent (or really a
strong demand for intelligent MVC frameworks from its users) to my
knowledge. And PHP is nearly as slow as Ruby without being nearly as
cool of a language (in my opinion).

So PHP is slower than Python and Perl, less useful for non-web tasks
than the alternatives, and marbled with crappy code examples/libraries
from hack-it-out-quickly I-promise-I'm-a-coder-not-a-designer novice
types.

I don't doubt there are great PHP developers, and great libraries --
just as VB had a few great developers and libs. But I think I'll find
more quality with the other languages.

If I didn't know Java, I would swallow my pride and learn what would
compensate me well (as you've accurately described). But, because I'm
at the top of the food chain in the market demand department, I have
the luxury of picking an interesting and technically sound 2nd
language.

This whole email is crazy harsh and probably the typical tripe you
deal with day-in-and-day-out with PHP. I'm willing to admit I may be
completely wrong about PHP. Help me see the light.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Matthew Walker
2007-02-15 22:13:45 UTC
Permalink
Post by Bryan Sant
Fair question. I have no problem with PHP itself and I should dabble
a little bit with it too (just to know some). But I'll retract my
comment about not caring about the community of the language. My
feeling is that the PHP community is primarily composed of
beginner/sloppy developers. There is no rails equivalent (or really a
strong demand for intelligent MVC frameworks from its users) to my
knowledge. And PHP is nearly as slow as Ruby without being nearly as
cool of a language (in my opinion).
There's a strong framework growing with CakePHP (http://www.cakephp.org/).

Still relatively young, but it's got lots of potential.
--
Matthew Walker
Kydance Hosting & Consulting
LAMP Specialist

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Louis Zirkel
2007-02-15 21:47:33 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Bryan Sant
Wo. Say no more. All of my wildest dreams eh... Have you ever come
across anything like time travel on the Internet?
John Titor. ;)

- --
Louis Zirkel / lzirkel-z3qUhMM1GPLQT0dZR+***@public.gmane.org
Systems Engineer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF1NT1aBHnnVFBPfYRAnnQAJ9K+FhS8F6C0NdAI4fErqik7dUeyQCfdz3x
XA1tkmsWPpyhgvFYD0+7IE0=
=yC4o
-----END PGP SIGNATURE-----

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Levi Pearson
2007-02-15 22:02:00 UTC
Permalink
Post by Hans Fugal
This is because blocks are almost never passed as parameters but as a
block following the method call. Incidentally, you can wrap up a block
with lambda/proc or even pass a method, as any parameter you want, and
then yield it (or call it) explicitly. They're not really relegated to
only the last position.
Are blocks almost never used that way because the language makes it
more awkward to do it that way, or because no one would want to do it?
I think Smalltalk is evidence for the former. And I did understand
that you could use blocks and procs and all that stuff in other
positions, but it comes at a syntactic price, and it doesn't seem to
be done very often.
Post by Hans Fugal
If you vote for Ruby, all your wildest dreams will come true.
I will undoubtedly be learning Ruby myself at some point, but for
someone like Bryan, I don't know if it's the best choice. Certainly
not a bad one, though.

--Levi

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hans Fugal
2007-02-15 22:21:22 UTC
Permalink
Post by Levi Pearson
Post by Hans Fugal
This is because blocks are almost never passed as parameters but as a
block following the method call. Incidentally, you can wrap up a block
with lambda/proc or even pass a method, as any parameter you want, and
then yield it (or call it) explicitly. They're not really relegated to
only the last position.
Are blocks almost never used that way because the language makes it
more awkward to do it that way, or because no one would want to do it?
I think Smalltalk is evidence for the former. And I did understand
that you could use blocks and procs and all that stuff in other
positions, but it comes at a syntactic price, and it doesn't seem to
be done very often.
I agree, they're not as cool as smalltalk blocks, but they're a lot
cooler than closureless languages. I have written code and seen code to
use procs, and perhaps the most natural application is something like an
observer registry. I'd say more than anything, the one block at the end
covers 90% of the use cases.
Post by Levi Pearson
Post by Hans Fugal
If you vote for Ruby, all your wildest dreams will come true.
I will undoubtedly be learning Ruby myself at some point, but for
someone like Bryan, I don't know if it's the best choice. Certainly
not a bad one, though.
Well, not everyone's dreams should come true.
--
Hans Fugal ; http://hans.fugal.net

There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
Stuart Jansen
2007-02-15 18:51:22 UTC
Permalink
Post by Bryan Sant
I sincerely want to learn a new language well, but
as I start to dig in to each language, I find warts that are even
uglier than the step-child that is Java.
I'd like to learn one of the following well: Python, Ruby,
or Perl.
Frankly, you should learn all three. As Hans has already pointed out,
not all scripting languages are created equal. Each has strengths that
makes it best for solving certain kinds of problems. Often because of
libraries, but sometimes just because of the design of the languages.
For example, PyNumeric, matplotlib & PyGTK are three great things about
Python no one else has mentioned yet. But regular expressions in Python?
Makes me wish I had an IDE. If I know I'm going to be doing a lot of
regex, I'll pick Ruby or Perl instead.

But of course, that's not very helpful is it? Here's a shorter version:
pick one to focus on for now, but keep dabbling with the others to
cross-pollinate ideas from each community.

The more I think about it, the more I think you should focus on Python.
I think it's the most likely to fit your development style. Python
places a lot of emphasis on well engineered solutions anyone can
approach. Unfortunately in Python that often means There Is Only One Way
To Do It Foo'. (TIOOWTDIF) That's good and bad. In my experience it
means that corner cases of the language get less attention. And
sometimes the Python solution isn't the solution that fits my brain
best.

But that's not really something you notice until you spend time with
other languages. With the resurrection of Jython, there's more chance
for you to combine Java and Jython in a single project taking advantages
of the strengths of each. Because the rebirth is so recent, though, I do
worry about Jython stagnating again. One thing that frustrates me about
Jython is it implements an older version of the Python standard and some
really nice stuff was added to Python 2.4.

The next bit of advice is a little harder to give. A similar argument
can be made for learning Ruby because of JRuby. Perhaps even stronger
because it's officially sponsored by Sun now. But JRuby isn't complete
and still has even bigger performance problems than Ruby. That said, a
stated goal of Ruby is to make programmers happy and for me at least, it
does just that. It's a clean language that fits my brain well. Some of
the freedom of Perl, without the excess. Some of the opinionated-ness of
Python, without the excess. A little secret sauce of its own.

Frankly, though, I have to admit I think you'd be best served by making
Perl your secondary focus. Every sysadmin should know Perl. Programmers
can also benefit. For example, you need to do some refactoring but your
specific scenario covered by your IDE. Carefully building a
one-time-only solution is stupid. Because Perl is so powerful and
flexible, this is one of the things its great for: quick, temporary
solutions. (If the phrase "one-time-only solution" makes you
uncomfortable, replace it with the word "prototype".)

Because Perl has people like Damian Conway abusing it in strange ways,
it's an extremely robust language. I've thrown sick and wrong programs
at it because I was in a hurry and not concerned about perfect design.
Python choked and fell over, Perl rolled with the punches and gave me my
solution. I personally don't have enough confidence in the current
version of Ruby to even try such a thing.

If that isn't enough for you, consider this: Perl has a very different
culture from Java. It's stupid to claim one is always right and the
other always wrong. If you're willing to invest the time to learn Perl's
approach to well engineered solutions, you will learn skills rarely
encountered in the Java world. Being able to draw on the knowledge of
each philosophy will make you a better programmer.

For example, a person experienced in meta-programming probably never
would have designed the tragedy that was J2EE 1.0. But meta-programming
is a skill easiest learned in a more flexible language. Although it's
possible in Java, it's harder and therefor less commonly encountered.
The meta-programming approaches you learn from Python/Perl/Ruby will
make you a more powerful Java programmer.

By the way, the nature of my advice is proof I'm trying to be objective.
My personal preference is Ruby, Perl, Python in that order. My advice to
you is Python, Perl, Ruby in that order.
--
Stuart Jansen e-mail/jabber: sjansen-***@public.gmane.org
google talk: stuart.jansen-***@public.gmane.org

"However beautiful the strategy, you should occasionally look at
the results." -- Winston Churchill
Mike Heath
2007-02-15 21:49:44 UTC
Permalink
I would recommend Groovy (http://groovy.codehaus.org/). Groovy was
built to run on the Java platform so it gives your the performance of
the JVM but also give you the flexibility of scripting languages. You
can also call all of your existing code from Groovy. You can also
call Groovy code from Java.

Groovy is not interpreted but gets compiled to byte codes at run-time.
The JVM can then convert the byte codes to native code. You can also
compile Groovy scripts to .class files.

Groovy allows you to use dynamic typing. You can also you static
typing if you explicitly specific the type you want.

Groovy also supports closures and uses them extensively.

In Groovy, if you want to read a file you can do:

new File("foo.txt").eachLine { line -> println(line) }

Groovy also has the very cool concept of builders which allow you to
greatly simplify building GUI's, creating XML or HTML. You could
apply the concept of builders to many tasks.

Groovy, of course, has some of the downsides of Java such as, slow
start time, large memory footprint, etc.

Another downside to Groovy is that you don't have much IDE support so
things like debuggers, code completion, refactoring, unit test
coverage metrics and compile as you go are either not available yet or
really immature.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Daniel C.
2007-02-15 21:57:09 UTC
Permalink
Groovy was built to run on the Java platform. You
can also call all of your existing code from Groovy. You can also
call Groovy code from Java.
Groovy is not interpreted but gets compiled
You can also compile Groovy scripts to .class files.
Groovy allows you to use dynamic typing.
Groovy also supports closures and uses them extensively.
Groovy also has the very cool concept of builders
Groovy contains a liquid core, which, if exposed due to rupture,
should not be touched, inhaled, or looked at.

Groovy may stick to certain skin types.

Do not taunt Groovy.

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Hill, Greg
2007-02-15 22:16:02 UTC
Permalink
Post by Bryan Sant
If I didn't know Java, I would swallow my pride and learn what would
compensate me well (as you've accurately described). But, because I'm
at the top of the food chain in the market demand department, I have
the luxury of picking an interesting and technically sound 2nd
language.
I have never seen a good paying PHP job. The companies that primarily
use PHP also tend to think $40k is a good developer salary. So,
learning PHP for career development is self-defeating. You'll get stuck
forever in low-paying jobs using a poorly-designed language. Sounds
like hell to me.

Greg

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Jonathan Duncan
2007-02-15 22:18:32 UTC
Permalink
Post by Hill, Greg
I have never seen a good paying PHP job. The companies that primarily
use PHP also tend to think $40k is a good developer salary. So,
learning PHP for career development is self-defeating. You'll get stuck
forever in low-paying jobs using a poorly-designed language. Sounds
like hell to me.
I would normally agree, but recently I saw a PHP job paying $55+. But
then again, i do not know what your scale is for "good paying".

Jonathan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Bryan Sant
2007-02-15 22:28:58 UTC
Permalink
Post by Jonathan Duncan
I would normally agree, but recently I saw a PHP job paying $55+. But
then again, i do not know what your scale is for "good paying".
Jonathan
Six figures is a good paying job. I heard once that 50k is the
*average* Utah wage. I have no source to back that up.

Regardless, I am not average. Are you?

Snobby elitism rules!!
-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
Dave Smith
2007-02-15 22:31:22 UTC
Permalink
Post by Bryan Sant
Six figures is a good paying job. I heard once that 50k is the
*average* Utah wage. I have no source to back that up.
The average household income is in the 50k range in Salt Lake County.
Individual income is in the 30's I believe.

http://www.ers.usda.gov/Data/Unemployment/RDList2.asp?ST=UT

--Dave

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/

Loading...