Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Paul Graham On 'Great Hackers' 620

dcgrigsby writes "Always interesting, if not unbiased, Paul Graham has published a new article on 'Great Hackers', discussing why Perl and Python are apparently better than Java, on why Microsoft developers get offices, and a host of other sure-to-be-controversial stuff."
This discussion has been archived. No new comments can be posted.

Paul Graham On 'Great Hackers'

Comments Filter:
  • by Junks Jerzey ( 54586 ) on Wednesday July 28, 2004 @09:27PM (#9827364)
    Second, and I'll probably be modded as troll for this, but all the programmers I know who like perl are sysadmin types who don't know better. Popularity isn't a much better measure of "goodness" in the open-source world than it is anywhere else.

    Nah, that's just the people you know. Perl, in my experience, tends to be used by people who write little programs to get things done quickly. And really, this covers a lot of sysadmins. But that's always been the secret of Perl: it's geared toward solving problems quickly. For example, in most languages you compile regular expressions and get back a handle, then you use the handle for searches. But in Perl the compiler takes care of this for you. You don't worry about it. You don't have to import an "re" library either. A good philosophy overall, even if the language isn't as pure and pristine in other ways.

    Still, I read the article, and I can't help thinking that Graham has already written this same article a couple of times in different forms.
  • Re:Its slashdotted.. (Score:3, Informative)

    by yppiz ( 574466 ) on Wednesday July 28, 2004 @09:40PM (#9827437) Homepage
    Much of the Internet Archive crawl and processing code, at one point, was perl scripts, GNU text utils, and custom C to deal with sockets and IO. This may still be true, but I haven't seen the Archive crawler in a few years.

    --Pat / zippy@cs.brandeis.edu

  • by kfg ( 145172 ) on Wednesday July 28, 2004 @09:52PM (#9827496)
    The Wright Bros. sued nearly everyone in sight for patent infringement, which is the main reason the center of aero-technology moved from America to Europe in less than a decade.

    By the time of WWI America was put in the position of having to license aeroplane and engine technologies from England and France.

    I think you should find a better example.

    KFG
  • Short version (Score:4, Informative)

    by Salamander ( 33735 ) <jeff@ p l . a t y p.us> on Wednesday July 28, 2004 @10:35PM (#9827727) Homepage Journal
    "What great hackers have in common is they're a lot like me (or at least like I imagine myself to be)"

    What an amazing ego.
  • Re:Java (Score:3, Informative)

    by OmniVector ( 569062 ) <see my homepage> on Thursday July 29, 2004 @12:08AM (#9828253) Homepage
    how about something more important, like integrated OOP. nothing's worse than claiming to be heavily object oriented, that has a bolted on OOP model.

    for example.. python:
    class foo:
    def __init__(self):
    // do stuff


    ruby:
    class foo
    def initialize
    // do stuff
    end
    end


    python reminds me so much of windows. everyone uses it, because it's all they know exists. if you want to see a language with modern OOP, and clean syntax, give ruby [ruby-lang.org] a try some time.
  • Re:Eric Raymond (Score:1, Informative)

    by Anonymous Coward on Thursday July 29, 2004 @12:44AM (#9828425)
    ESR has written less software than I had by the time I was an early teen.
  • by wotevah ( 620758 ) on Thursday July 29, 2004 @12:55AM (#9828471) Journal
    Sorry for the PRE/ecode, I don't like HTML much:
    # No more separate header files!
    - check - Python only has modules loaded at "runtime" (does not even have separae interface/implementation)

    # Garbage collection
    - check

    # Implicit bounds checking
    - check

    # Core libraries not afraid to use Exceptions
    - exceptions are the rule :)

    # Standard core libraries provide an enormously useful standard toolset.
    - yes, not nearly complete but growing

    # Strings are used everywhere freely making the code easier to debug
    - not sure what you mean by that.

    # Stack traces!
    - yes. Default stack traces suck though (but so do Java's). This is because without knowing the actual parameters passed to each function, their usefullness is limited. I posted a better stack trace module on comp.lang.python a while ago and got a few replies from people doing even more involved stuff in the same direction.

    # Javadoc
    - it's called pydoc - the module documentation on the website is done that way

    # Many choices for great IDEs
    - xemacs has a Python mode (that's what I use) but I heard Eclipse has a Python plugin as well, I am planning to try that soon.

    # Much much much more cross-platform
    - yes although, unlike Java, it offers platform-specific modules as well. Not trying to open a can of worms but as I despise having to reinvent the wheel I was mildly irritated by Java's insistence on not implementing certain OS-specific things (like IPC or fork) which lead to artificial obstacles such as the necessity of installing an SMTP server listening on 25 just to be able to send mail from the local machine.

    Python is still evolving though. One thing that I don't like about it is the absence of an option to enforce declaring variables before use, a la "use strict" in Perl. Python does complain if you try to read a non-existent variable (instead of just returning nothing as Perl does), but will create it with an assignment.

    Another thing (probably related) is that since applications don't declare what they throw you can never know what exceptions can come from where, which encourages people to use catch-alls (not a good idea).

    Finally, a (major ? minor ?) difference is that Python has no class protection per se, it relies on programmer's cooperation in that respect. It also has no class methods/variables although there are workarounds when those are needed.

    The indentation is annoying at first but you get used to it, especially when using an IDE that does it correctly for you.

  • by Anonymous Coward on Thursday July 29, 2004 @02:25AM (#9828809)
    1. At the time that SourceForge was started, C was a much more well-known language than Python.
    2. As other respondents have mentioned, most projects on SourceForge never get past the starting block.
    You should instead compare stats of level 5 (Production, stable) projects.
    3. Many people knew C before Python came along, and are reluctant to learn a new language.
    (These people are not necessarily hackers.)
    4. Many of the projects on SourceForge are "low-level", e.g., part of the kernel, and/or must run very quickly, and so are written in C for performance (speed) reasons.
  • Re:Eric Raymond (Score:1, Informative)

    by Anonymous Coward on Thursday July 29, 2004 @07:24AM (#9829957)

    Eric Raymond is a mediocre programmer at best, a drunkard, and likes guns. Can't you come up with a better example?

    Mike Bouma

  • by ultrabot ( 200914 ) on Thursday July 29, 2004 @09:58AM (#9831011)
    if i have to pass self to every single member function, that's bolted on

    It's a conscious design decision that makes the system more elegant. "Explicit is better than implicit". Of course it would be trivial to circumvent this by writing a preprocessor, but it's not considered a good idea.

    if i have to prepend and append __ to special object functions everywhere, that's bolted on.

    No, it's just a decision to call the methods that. It's just a naming convention. It has no relationship with whether OOP is implemented through functional constructs or not.

    in this case i'm defining foo, passing foo as a parameter to bar, and calling foo then returning it's return value. i'm not sure how first-class you can get, but that's pretty first-class to me.

    Well, you could do:

    def f(x):
    def g(y):
    return x+y
    return g

    myfunc = f(1)
    print myfunc(3) # prints 4

    to this day, python still lacks many of the oop and functional (lisp like) features of ruby.

    What are those features, apart from "blocks"? And functional != lisp-like, BTW.

    guess what, i have used python. it's the language that is lacking, not ruby.

    When did you use it? Modern Python is quite different from, say, 1.5.2 or even 2.1. Ruby had the upper hand in language features before 2.2, but that's gone.

    modern "windows" renders linux irrelevant too i'm sure, yet we persevere because linux is a better operating system.

    I would rather compare Ruby vs. Python with FreeBSD vs. Linux. In fact, that's a surprisingly good analogue.

    where have i lied?

    It's the wording, and speaking of "bolted on OOP". It is simply not true, and a standard part of Ruby rhetoric.

    if you'd broaden your horizons and actually dive into ruby maybe you'd understand why the few of us loyal to it hold it so dear.

    I understand very well why rubyistas hold ruby so dear - it's exactly the same reasons as with Python. The languages are more similar than they are different, which kinda undermines the less mature/popular choice. It's FreeBSD vs. Linux again.

    I believe ruby is like that. along with scheme, OCaml, Haskell, and other hacker languages that require discipline and free thinking to adopt and appreciate.

    Ok, Ruby is perhaps different in that way. Appreciation of Python didn't require discipline at all for me, it hit me pretty much instantly. As would have Ruby, if I hadn't "been there, done that" with Python before.
  • Re:Tool for the job. (Score:3, Informative)

    by DarkMan ( 32280 ) on Thursday July 29, 2004 @10:47AM (#9831518) Journal
    Heh, it's not as bad as it might sound.

    The Fortran code solved a particular eigenvalue problem in a few manners, to get different bits of information. Main workhog, used parrallel algorithms.

    The C code generated the set of input matrices for a spefic problem geometry. These were output into a text stream, passed to the Fortran routine. This means that the C code took input of number of atoms, orientation, interaction coefficents, and output some giant matrices.

    The Fortran output was several sets of output from the various methods. Perl chunk, for the most part, selected the output chunk desired, and pretified it. For one particular type, it output Postscript.

    So, the gist is that each indivdual part was seperate conceptually, and performed distinct roles. It would be feasable to run a specific job by piping the output of one stage to the input of the next. In practice, the runtimes of the Fortran stage was such that it was saved to disk, so the same output could be parsed in multiple ways.

    I wrote the code, ran some stuff, forgot about it, and had to go back to it 2 years later. Despite a serious lack of comments, it took around 5 minutes to get familar with it enough to extend it for a totally different crystal system.

Happiness is twin floppies.

Working...