Slashdot Mirror

← Back to Stories (view on slashdot.org)

Python 2.5 Released

Posted by ryuzaki0 on from the snakes-on-a-frame dept.

dominator writes "It's been nearly 20 months since the last major release of the Python programming language, and version 2.5 is probably the most significant new release of Python since 2.2. The latest release includes a variety of additions to the standard library, language extensions, and performance optimizations. This is a final release, and should be suitable for production use. Read the release announcement, the highlights, what's new, and download it."

45 of 228 comments (clear)

  1. Re:How appropriate... by Tackhead · · Score: 5, Funny
    > for Talk Like A Python Day....

    AVAST! Ah've had it with these landlubbin' memes on this landlubbin' website!

  2. Re:Languages continue to evolve into ... Lisp by Scarblac · · Score: 2, Insightful

    Because 90% of programmers only know the simplest languages.

    --
    I believe posters are recognized by their sig. So I made one.
  3. Python Challenge by Franio · · Score: 5, Informative

    I know this is offtopic but does anyone know what happened to the python challenge?

    There have been no new levels for a long time.

    For those who haven't seen it, the python challenge is a great way to learn python.

  4. Sqlite included! by imag0 · · Score: 3, Informative

    From TFA:

    In keeping with the theme of adding tried and true packages to the standard library, in 2.5 we've added ctypes, ElementTree, hashlib, sqlite3 and wsgiref to the standard library that ships with Python.

    That made me sit up and take notice. A pretty nice programming language with built-in functionality to read and write Sqlite databases natively?

    Looks like they release a Mac installer, too. Think I'll have to check it out when I get home

    Cheers

    1. Re:Sqlite included! by ubernostrum · · Score: 2, Insightful

      I didn't mean that they only used some functions, but simply that they didn't write those functions or anything, they're just linking a library and exposing the API to Python. This is really no different from having a perl module with a loadable module, except how it's distributed.

      Nope. It's a module. The entire module is right there for you to use. Not some headers, not a few functions, the whole thing.

      I'm sure you can compile it out, but putting the sqlite library into the base distribution is, IMO, stupid. It only makes base larger and more complex.

      Except it doesn't. Python the language has not gained native support for SQLite. Nothing having anything to do with SQLite has been "compiled in" to the core language. A module which provides a Python wrapper around the SQLite API is now included among the libraries in the standard Python distribution. If you don't need it, don't ever import it in a program. Simple as that. If you do need it, importing from the pysqlite2 module is always guaranteed to work on Python 2.5, because you no longer have to go download that module from somewhere.

    2. Re:Sqlite included! by masklinn · · Score: 4, Insightful

      Damn, missed that one.

      Now I know that's just me (well, not just me) but doesn't it make sense to keep the distribution light?

      No. It makes sense to keep the core language light, but it definitely does not make sense to keep the standard library "light". And it would go against Python's philosophy of being offered "batteries included".

      It makes sense to keep standard libraries high-quality, and fast, but stdlibs are great assets of computing languages. Many think that more than a language failed because there was no quality, extensive standard library (Common Lisp comes to mind).

      Now extensive third-party repositories such as CPAN or easy-to-install third-party libs such as Ruby's gems do make sense, and are also great assets to a language not to be underestimated, but stdlib functions just give much more (potentially misguided though) confidence about quality, and they create common idioms across the language.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  5. Re:Languages continue to evolve into ... Lisp by ltbarcly · · Score: 2, Informative

    C isn't simple, and in fact lisp is pretty simple.

    Lisp isn't used because it wasn't standardized until the late 80's, it uses much more memory than C (though it is almost as fast as C++) and most programmers until recently have learned to program Unix and not Lisp machines. Also, MS doesn't have a lisp implementation so that means that if you don't go to a research university you won't see anything but MS (little podunk colleges are notorious for teaching 'how to program Microsoft'. Any college with a class in Visual Basic should have it's accreditation revoked.)

    Finally C gives easy hooks into the OS, which isn't the same at all with Lisp, although you can do anything you can do with C it isn't Lispy to do so.

    Finally, C is good enough. If you really want to wonder about languages, ask why Perl is used for anything. Perl sucks.

  6. In line conditionals, FINALLY by gd2shoe · · Score: 4, Informative
    Although not as elegant as:
    cout << ( a==b ? "first option" : "second option" )
    It is good to finally see inline conditions such as:
    print ( "first option" if a==b else "second option" )
    This just makes me happy! ;-)
    --
    I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
    1. Re:In line conditionals, FINALLY by Anonymous Coward · · Score: 2, Informative

      Unless "first option" evaluated to False. So the general-purpose version of this is the hideous:

      print (a==b and ["first option"] or ["second option"])[0]

      if they're constant strings, you of course don't need this, but if they're expressions that might evaluate to False, you do need to do this.

      For example, if you have a function:
      def foo(a, b, x, y):
            print a==b and x or y

      and you don't know that x will never be False (or 0), then you have to write it as:
      def foo(a, b, x, y):
            print (a==b and [x] or [y])[0]

      The list [x] can never be False, so this always works. Given this subtle error, I much prefer the new syntax.

    2. Re:In line conditionals, FINALLY by the_wesman · · Score: 2, Insightful

      "When developing computer language syntax, natural language imitation should not be the priority"

      I could care less about inline if statements - I assume that those are only for people who either are the dangerous kind of lazy, like to write hard-to-read code or don't use emacs

      in response to your 'natural language' comment, I'm hoping that isn't the reason that this was done because the if/else syntax we already have imitates natural language.

      If she is hot, hit on her. else, if she is not hot and I'm drunk hit on her. else go home.

      looks like natural language to me.

      --
      calling all destroyers
    3. Re:In line conditionals, FINALLY by xTantrum · · Score: 3, Insightful

      I have to agree, i don't see why GVR couldn't have just fashioned it the same as the ternery operator in C. I love python not only for its RAD ability but the syntax: clear, terse and indented. Since they added decorators i've been getting more and more irritated with it. keep it clean, keep it concise. WHY BE DIFFERENT FOR THE SAKE OF BEING DIFFERENT!

      --
      $action = empty(PHP) ? backToC() : unset(PHP) ; "when the concrete cases are understood, the abstractions are readily
    4. Re:In line conditionals, FINALLY by Haeleth · · Score: 2, Insightful

      If she is hot, hit on her. else, if she is not hot and I'm drunk hit on her. else go home.

      looks like natural language to me.

      Looks rather unnatural to me. The usual way to say it would be more like "Hit on her if she's hot or you're drunk, else go home."

      Which, I realised as I typed it, is exactly how Python's new inline conditional syntax works. Neat.

  7. Re:Languages continue to evolve into ... Lisp by Scarblac · · Score: 4, Informative

    I think C is too hard for most programmers too. I may be in a bad mood, but I think most programmers do PHP and Visual Basic, badly. They wouldn't grasp Lisp's macros. Of actually good programmers, a very small percentage know Lisp; I wouldn't start a professional project in it for that reason.

    I personally love Python (used it for all the code I wrote for my thesis), but these days I program Perl at work. It's not that bad, really. It makes sense, in its own way and it's got a good solid set of libraries available out there. Java isn't half bad for bigger projects either, actually.

    About half a year ago, I tried to get into Lisp. It sounds like the holy grail - execution speed and error checking of a compiled language with all the speed of development of more dynamic languages. Perhaps s-expressions should be perfectly suited for HTML too (I'm still stuck in this web app world, at the moment). So I picked up Practical Common Lisp, installed SBCL, joined some mailing lists, found some libraries, got experimenting...

    Two things meant I got disinterested in a month or so: it has far too many slightly-differently-named functions in the standard language, many with non-obvious names too (that's what PHP gets its harshest criticism for); and also the huge library of things you need nowadays (internet stuff, databases, OS stuff, etc) is either missing or rather undeveloped.

    But it's still promising. I'll probably have another look in a few more months :-)

    --
    I believe posters are recognized by their sig. So I made one.
  8. Re:Too many pirates riding the snake... by Anonymous Coward · · Score: 3, Informative

    Dive Into Python really helped me to get started. You can buy it as a book, but it's also available for free on the web. Guido's own tutorial is also a good way to get started, as python's creator wrote it himself, and is a pretty good teacher too. Both of these are no big secret, but both are well written and clear, so i'd check them out first before looking for more detailed tutorials. Python's official documentation/website are really so good that looking elsewhere is for the most part unnecessary.

  9. Re:Languages continue to evolve into ... Lisp by drinkypoo · · Score: 4, Insightful

    All programmers should study assembler. With an understanding of what kind of action is going on behind the scenes, programming makes a lot more sense. Then they should probably move straight on to OO :)

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  10. Hey! by gd2shoe · · Score: 2, Insightful

    Hey!

    This is a time and place for us python nut-cases. Ruby wackos can go release thier own new versions...

    (Just messing with you, but your comment was a cheep shot)

    --
    I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
  11. try/except/else/finally by ttfkam · · Score: 3, Interesting
    Would someone be so kind as to explain this construct for me?
    try:
        block-1 ...
    except Exception1:
        handler-1 ...
    except Exception2:
        handler-2 ...
    else:
        else-block
    finally:
        final-block
    Coming from Java and C++ land, I'm familiar with the idea of

    try {} catch (...) {} finally {}

    What is the point of else? What does it get you that you didn't have just as easily without it? If no exception is thrown, run it? Isn't that what the content in the try section is for? Will someone provide a use case for this for me please?
    --

    - I don't need to go outside, my CRT tan'll do me just fine.
    1. Re:try/except/else/finally by artlogic · · Score: 5, Informative

      You would include logic in the else to be executed in the case that no exceptions occur, that is:

      else:
          print "no exceptions occured!"

      Everything else is the same as Java/C++.

      --
      "A Mathematician is a machine for turning coffee into theorems." ~ Paul Erdos
    2. Re:try/except/else/finally by masklinn · · Score: 3, Informative

      The code that you run after the part you may want to protect could thrown an exception that you wouldn't want to catch in your except handlers.

      The else clause gives you a way to run it without the risk of shadowing/accidentaly catching these exceptions.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    3. Re:try/except/else/finally by artlogic · · Score: 2, Informative

      The difference... which I keep not mentioning, doh... is in the case that "print 'no exception'" throws an exception. In that particular case, your code would proceed into the exception block, where my code would bubble up to the next error handler.

      --
      "A Mathematician is a machine for turning coffee into theorems." ~ Paul Erdos
  12. Re:Woot -- conditional expressions! by masklinn · · Score: 4, Informative

    I suppose that would have been too easy, though.

    It's not about "too easy", it was rejected after lenghy discussions on python-dev. You can read explanations, modivations, and get links to quite a lot of discussions on the PEP 308 - Conditional Expressions page.

    Whatever your thought on the result is, don't think for a second that the decision of this was easy, or a side-note on a receipt.

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  13. WxPython by nih · · Score: 5, Informative

    anyone using wxpython will need to upgrade to wxpython for python 2.5

    http://www.wxpython.org/download.php

    as soon as i'd installed python 2.5 all my app died, took me a few mins
    to realise that py2.5 breaks wxpython for py2.4, and some tk demo's ran:)

    --
    I'm a rabbit startled by the headlights of life :(
  14. Re:What? by cortana · · Score: 3, Funny

    Ouch ;)

  15. Re:Languages continue to evolve into ... Lisp by a.d.trick · · Score: 4, Insightful

    I don't like the idea that some people make intrisicly "good" programers, and the rest are all somehow "bad"; as if some of us had bigger brains or something. Two years ago, my programming experience was limited to QBasic and a short foray into Visual Basic. I was a bad programmer. Fortunatly for the sake of humanity I stayed away from the computer for the most part at that point, otherwise I'm pretty sure something of mine would have ended up on thedailywtf.com.

    Then I started to play around with other languages (PHP, JavaScript, Lisp, and Python) and over the course of a year, two the way I saw programming, changed. No dove came down from heaven with a booming voice. It was just my mind getting practice at building beautiful algorithms. The samething happened to me when I took up piano, singing, woodworking, and many other things.

    So the question is not so much are you good enough to learn C, but are you willing to take the time. In C, algorithms tend to be quite a bit more complex than they are in Python, and further removed from our common speach. But it's not impossible.

  16. Re:Easy transition from Python to Ruby? by masklinn · · Score: 3, Informative

    Migrating from Python to Ruby is trivial, they're 95% identical. Some idioms are different such as Ruby's use of anonymous functions (called blocks) and different ways of metaprogramming (plus the fact that Ruby uses metaprogrammatic abilities much more often than Python), but the difference between them is far smaller than some people make it to be.

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  17. Re:Easy transition from Python to Ruby? by masklinn · · Score: 2, Informative

    Oh yeah, the biggest hurdle when transitioning from Python to Ruby is the awfully shitty documentation by the way, and the fact that Ruby's stdlib is fairly anemic compared to Python's (third party packages and the ease of installing them via gem somewhat eases the pain though)

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  18. Learning Python... add pyrepl to the interpreter. by zapadoo · · Score: 2, Informative

    Tip #1: I highly recommend adding pyrepl to your Python environment. It enhances functionality of the interactive interpreter such that you can easily edit multi-line code snippets. Forward and back (control-n, control-p) through history. Control-r (then start typing) to find something back in history. Very useful. http://codespeak.net/pyrepl/

    Tip #2: Avail yourself of the help() function in the interpreter. help(SomeObjectOrFunction) i.e. help(open) will return the docstrings associated; help(SomeModule) i.e. import sha; help(sha) will return the module docs.

  19. Re:Too many pirates riding the snake... by All_Star25 · · Score: 2, Informative

    I have been tutoring a 7th or 8th-grader in Python for several months now using the book How to Think Like a Computer Scientist: Learning with Python. It's released for free under the GFDL, and I printed up two copies of it via PrintFu, and it seems to be a pretty good text. However, it's primarily geared towards those with no prior programming experience. Regardless, I learned the language along with him as I tutored, and learned some general programming things from the book. I have no idea to what extent you are familiar with programming, but I was able to look at various things and think things like, "Oh, those are the equivalent of Perl hashes". I found that Python and Perl have a good deal in common when compared to a language like C (caveat: I am most familiar with C and Perl). But, it is indeed free, so it could serve as a simple introduction to Python before you spend money on something like the O'Reilly text.

  20. Re:Woot -- conditional expressions! by Gospodin · · Score: 2, Informative

    I don't feel particularly strongly about it, but it seems to me that the Python syntax gets unwieldy more rapidly when you have nested conditionals, like so:

    "first option" if a==b else ("second option" if a==c else "third option")

    ...versus...

    a==b ? "first option" : (a==c ? "second option" : "third option")

    My other concern is that it's immediately obvious that a C conditional is just that, but the Python syntax makes it a little obscure:

    s = "first option" if a==b else "second option";

    ...versus...

    s = (a==b) ? "first option" : "second option";

    Isn't it a little tempting to read the Python version as s = "first option"? Might be just me, though. My knowledge of Python is somewhere between jack and s**t, so maybe it just makes sense there.

    --
    ...following the principles of Heisenburger's Uncertain Cat...
  21. Re:Python is not anything like Lisp by masklinn · · Score: 2, Informative

    Now Ruby has the anonymous function thing ("blocks") which lets you do some of the same things you can do in Lisp with Macros

    Duh, looks like you never used macros, blocks don't let you do anything macros let you do, they let you do what lambdas (anonymous functions) let you do in lisp.

    These is no relation at all between blocks and macros, macros are tools to generate (transform) code. The only think that could be linked to macros in Ruby are class_eval and instance_eval-type methods.

    Now please shut up, you don't even being to grasp what macros are or what they're used for, so don't talk about them.

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  22. Re:Use the appropriate language by Intron · · Score: 2, Informative

    I don't know. Back in the day, I wrote a simplified Lisp interpreter to run on a 6802 microprocessor in 64K. It seemed like the easiest way to run a realtime dispatching algorithm - kind of a rule-based expert system. You can get Lisp going with about a dozen hard-coded ops and write everything else in Lisp. I haven't seen a better way to do it since then, although I like stack-based languages for embedded systems also. Postscript is my favorite. One of the few embedded projects I've worked on that completely failed was written in C.

    --
    Intron: the portion of DNA which expresses nothing useful.
  23. Re:Use the appropriate language by masklinn · · Score: 2, Insightful

    It has features from many languages. That's why it's so easy to learn. Whatever your programming style, you can probably do it in Python.

    Well python is a multiparadigm language and fairly flexible, but it doesn't go far beyond OO, imperative and lightweight functional styles.

    It's not fit at all for logic programming, DBC and AOP are not that cool (even though decorators make them at least possible without being too damn ugly), and hardline functional programmin is impossible due to lack of support for recursions (Python doesn't optimize tail-recursion), absence of pattern-matching and mutable states.

    Oh, and it has no support whatsoever for distributed or heavy concurrent programming.

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  24. Re:Languages continue to evolve into ... Lisp by smallpaul · · Score: 4, Insightful
    I thought I dispelled this myth years ago.
    Here is the story as presented by Paul Graham (a famous Lisp expert). Of the three languages he chooses to discuss, Java, Perl and Python, Python is considered cooler (if not more popular) than Perl and Perl cooler (if not more popular) than Java because Python is most like Lisp of the three. Unfortunately, Python is a sort of immature Lisp which may over time grow into its full Lisp-yness but why wait around when you could just be using Common Lisp today? I'm sure if you are a Lisp programmer, it is a compelling story. Unfortunately it does not ring true.
    http://www.prescod.net/python/IsPythonLisp.html
  25. Re:Languages continue to evolve into ... Lisp by CaptainPinko · · Score: 2, Insightful

    We all know whats going on under the hood... the point of a programming language is to abstract out the "under the hood" and present it in a more semantically appropriate format. Our code doesn't remind us that memory is read into registers and then processed... but we all understand that. It's good to understand offsets, but there is no reason for our languages to reinforce that and make us say stupid things like "the zeroth element".

    --
    Your CPU is not doing anything else, at least do something.
  26. Re:Languages continue to evolve into ... Lisp by fuzz6y · · Score: 5, Insightful
    I don't like the idea that some people make intrisicly "good" programers, and the rest are all somehow "bad"; as if some of us had bigger brains or something
    Every skill is a function of talent and training. The cornerstone of elitism is to grossly overestimate the role of talent, but to dismiss it altogether is no less foolish.
    --
    If you're going to be elitist, it would help to be elite.
  27. Re:Easy transition from Python to Ruby? by ubernostrum · · Score: 4, Interesting

    Migrating from Python to Ruby is trivial, they're 95% identical. Some idioms are different such as Ruby's use of anonymous functions (called blocks) and different ways of metaprogramming (plus the fact that Ruby uses metaprogrammatic abilities much more often than Python), but the difference between them is far smaller than some people make it to be.

    If I moderated, I'd mod this up :)

    Seriously, the idioms and conventions of programming in Python and Ruby are the largest differences, not the actual languages themselves:

    • Ruby programmers, on average, seem more likely to crack a class open and add new things to it, where Python programmers generally prefer to subclass and do what they need in there.
    • Ruby programmers, on average, seem more likely to build domain-specific languages to solve problems, where Python programmers generally prefer other routes (though which route they take will vary depending on the problem).

    Et cetera, et cetera. Ruby folks are also big on the arbitrary anonymous blocks, which Python doesn't have, but I've yet to run into a problem I can't solve with a named function, and a lot of the time I end up with cleaner and more understandable code because of it. Which, really, I think is the biggest cultural difference: given a situation where all other things are equal, Ruby focuses on expressiveness (an inherited "there's more than one way to do it" from the Perl in its genes), and Python focuses on clarity and readability.

  28. Re:Dive Into Python by Millennium · · Score: 3, Informative

    Dive Into Python is great, but it has the problem of being old. So old, in fact, that so far I haven't found anything from it that doesn't work perfectly in Jython. That might not seem like much, until you realize that Jython is still not quite at the Python 2.2 stage yet: more than three years behind.

    Not that I dislike Jython. Quite the contrary: I use it more than I use cPython, for a variety of reasons. But its development is going slowly enough that it's making me want to brush up on my Java so I could help out.

  29. Re:Languages continue to evolve into ... Lisp by ciggieposeur · · Score: 4, Insightful

    About half a year ago, I tried to get into Lisp. It sounds like the holy grail - execution speed and error checking of a compiled language with all the speed of development of more dynamic languages. Perhaps s-expressions should be perfectly suited for HTML too (I'm still stuck in this web app world, at the moment). So I picked up Practical Common Lisp, installed SBCL, joined some mailing lists, found some libraries, got experimenting...

    Two things meant I got disinterested in a month or so: it has far too many slightly-differently-named functions in the standard language, many with non-obvious names too (that's what PHP gets its harshest criticism for); and also the huge library of things you need nowadays (internet stuff, databases, OS stuff, etc) is either missing or rather undeveloped.

    All very true criticisms. I too have switched my new code to Lisp for the purpose of being a better programmer (and because I've got two years in a MS program to get my basic math toolset switched over). It IS getting better, and faster at that. I think we're approaching critical mass of people adopting it and pushing it into the Python/Java/Perl/etc. space with sockets, threads, SQL, UFFI (now CFFI), etc.

    I think the biggest problems I've got with Lisp are packaging, pathnames, and the REPL.

    Packaging means ASDF, which I don't like at all compared to Java or Perl's filesystem packages. To get a package with dependencies to work OK, you've got to create a .asd file and add a defpackage to either a separate .lisp file or your main one, and the .asd specification is not documented well (the wiki page for setting up sub-modules is flat-out wrong).

    Pathnames ... UGH. I've already had to write my own version of a java.io.File just to have a string that is guaranteed to refer to an actual file.

    REPL. Well, it's very nice to be able to talk to a running Lisp, especially when the Lisp is an application server and you want to alter some values or force a reload of an app, or just to poke around and see what kind of stats have been collected. However, the distinction made in the spec between compile-time, interpret-time, and run-time for code makes some things difficult, e.g. defconstant is completely useless with SBCL. I like REPL, every book should mention it, but they should very quickly move OFF REPL and show people how to just load a .lisp file and run it. The implementations should also make it easier to tune the output of the Lisp (try to get compile-warning's squished in SBCL, it's not pretty).

    I would LOVE (and gladly buy two) copies of a book that had this information in it:

    1. What is Lisp, and where to find the community web sites
    2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows
    3. Basic language grammar, including CLOS
    4. How to use ASDF (including complex examples)
    5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
    6. How to package a standalone Lisp application to deliver to customers
    7. How to use UFFI
    8. How to set up a Lisp web application server (modlisp or Araneida or ...)
    9. How to use the most common libraries: CLSQL, OpenGL, SDL

    I know Lisp'ers love (and I do too) the fact we've got a spec and multiple implementations, but dangit if it isn't really difficult to get it all together and be able to actually DO something with it within a couple weeks.

  30. learning by mackyrae · · Score: 2, Informative

    I'm using a book called Python Programming for the Absolute Beginner. It explains all the data types and stuff which does get a little annoying if you already know another programming language, but it cost $15 less than Dive Into Python. I think one of the guys in my dorm is going to borrow it because he needs those explanations (first language).

    --
    look! it's a bird, it's a plane, it's....a girl? yes, a girl browsing Slashdot on Linux
  31. Re:Languages continue to evolve into ... Lisp by epee1221 · · Score: 2, Interesting

    I've seen more than a few people wonder why they have to declare arrays with their sizes in C and can't just keep writing past the end when they run out of space (like with a java.util.ArrayList).

    --
    "The use-mention distinction" is not "enforced here."
  32. Re:Languages continue to evolve into ... Lisp by smallpaul · · Score: 4, Insightful

    All programmers should study assembler. With an understanding of what kind of action is going on behind the scenes, programming makes a lot more sense.

    Perhaps they should also learn microcode because without that, you won't know what's going on behind the scenes in Assembler. And then to understand the microcode, maybe you need to understand electronics. And to understand the electronics, you should understand physics. So all programmers should understand Maxwell's equation lest they not know what's going on "behind the scenes."

  33. Re:Languages continue to evolve into ... Lisp by Garrett+Fox · · Score: 2, Insightful

    You jest, but it is good to learn as many aspects of a problem as possible. The extreme opposite case would be a programmer who thinks he's a whiz at giving magic incantations to the glowing mystery box, and ends up sacrificing AOL CDs to it when it breaks.

    In education in general, I'd like to see everyone know how to make things like one of those shaking-powered flashlights. A hands-on program like that would give people more of a sense of ownership over science and technology.

    --
    Revive the Constitution.
  34. unwind-protect by Nicolay77 · · Score: 2, Insightful

    So this is like Common Lisp unwind-protect special form.
    Nice feature :)

    Ohh sorry, I just forgot that Python is trying not to be more Lisp-like!! :P

    --
    We are Turing O-Machines. The Oracle is out there.
  35. Re:Languages continue to evolve into ... Lisp by SonOfLilit · · Score: 2, Interesting

    Good programmers aren't "good" because of their knowledge -

    They are "good" because of their will to learn.
    Because of their appreciation of code beauty.
    Because they like to code.

    Bad programmers don't care about coding, they see it as some sort of accounting-like job where you have to crunch symbols and get paid for it.

    I didn't meet many bad programmers. I am only 18 and am only in my first programming job and programmers here are selected very carefully.

    I only met bad programmers at school. They were the people who tried to copy what the teacher said just to get their grade, and didn't think about coding again until the next lesson.

    While the good coders were busy trying to understand why what the teacher said works, what else can be done with that knowledge...

    While bad programmers looked at the teacher, the book, or the neighbor good programmer (if they were lucky to have one) for answers, good programmers hacked and hacked until they found the solution /themselves/, enjoying the process.

        --------

    I bought yesterday a poetry book by Charles Bukowski. It cost me a lot of money, more than I could afford, and I could have bought two great SF books by Orson Scott Card for the same price. Why did I buy that book? I read the first poem.

    It started:

    *so you want to be a writer?*

    if it doesn't come bursting out of you

    in spite of everything,

    don't do it.

    unless it comes unasked out of your

    heart and your mind and your mouth

    and your gut,

    don't do it.

    if you have to sit for hours

    staring at your computer screen

    or hunched over your

    typewriter

    searching for words,

    don't do it.

    rest here: http://www.poets.org/viewmedia.php/prmMID/16549

  36. Re:Languages continue to evolve into ... Lisp by pelletron · · Score: 2, Informative

    A know the answers for some of your questions:

    1. What is Lisp, and where to find the community web sites

    Cliki is a good start:

    http://www.cliki.net/index

    2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows

    On Debian: apt-get install sbcl

    For windows try Lispbox:

    http://www.gigamonkeys.com/lispbox/

    3. Basic language grammar, including CLOS

    The best text is "Practical Common Lisp":

    http://www.gigamonkeys.com/book/

    4. How to use ASDF (including complex examples)
    5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
    6. How to package a standalone Lisp application to deliver to customers
    7. How to use UFFI

    CFFI seens to be a better option:

    http://common-lisp.net/project/cffi/

    With a good manual:

    http://common-lisp.net/project/cffi/manual/index.h tml

    8. How to set up a Lisp web application server (modlisp or Araneida or ...)
    9. How to use the most common libraries: CLSQL, OpenGL, SDL

    Common lisp community is growing, and the OS integration, libraries and documention is improving.