Visit Jeremy's Blog.
Go Back > Forums > Non-*NIX Forums > Programming
User Name
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.


  Search this Thread
Old 12-03-2008, 08:44 AM   #61
LQ Newbie
Registered: Aug 2004
Posts: 12

Rep: Reputation: 0

By the way,

If the original poster is still with us after this massive thread-jacking, I would highly recommend LISP. On the one hand, very good learning language, on the other very powerful. I especially like the ability of some of the LISP interpreters to compile small sections of code on the fly at a time even as you edit them in an editor. Check out the SLIME module for EMACS. Or check out one of the Scheme implementations and work through the following book:

What initially seems like unusual syntax won't bother you very long, and pretty soon you start to appreciate the consistency of it.
Old 12-03-2008, 11:10 AM   #62
Senior Member
Registered: Dec 2005
Location: London, ON, Canada
Distribution: Arch, Ubuntu, Slackware, OpenBSD, FreeBSD
Posts: 1,853

Rep: Reputation: 65
I second the LISP notion!
A second book to suggest (and it's the one that got me on my way with the language): Practical Common Lisp by Peter Seibel.

My "toolbox" is as follows...
Languages: Common Lisp, Java, Python, C, Perl
Editor: Emacs (the only editor with proper Lisp indentation)
Version Control: Bazaar & Subversion
Debugger: N/A (my C programs are usually small enough to bypass the need for a debugger)
Documentation: I handwrite all of my user and developer manuals using LaTeX2e
Old 12-07-2008, 03:33 PM   #63
LQ Newbie
Registered: Dec 2008
Distribution: Debian, Gentoo, FreeBSD, OpenBSD, Slackware, CentOS
Posts: 27

Rep: Reputation: 16
Originally Posted by acerimusdux View Post
It also had nothing to do with my code. Real world, though, best practice would be to use descriptive names, like length, width, and height; the machine isn't going to care what you call them or if you name them at all, it's your human readers you need to worry about understanding it.

If you want to really have some benefit from functional techniques, you also need to think about modularity, maintainability, and re-use. If you have to make any changes to that procedure as you've modeled it, you are going to have to modify both the procedure itself (adding or changing sub routines), and the calling routine. If you wanted to reuse some of that, elsewhere, for a similar operation, with minor changes, you would probably have to copy it and duplicate it, as it was not written in a generic fashion. Anonymous functions mean you can't call them from elsewhere. Unneeded nesting means if you decide you want the addition, but not the multiplication, you can't get to subroutine Z without going through X and Y first.

But, in any case, that is all about coding style, and nothing to do with the language used. My main complaint with this thread is all of the misinformation in here about the Python language.

No, if you understand the scoping rules you are using, you should understand that all you are doing is reusing the name. When you call "my $result" in three different scopes, that is creating three separate $result variables (one local to each subroutine). Same thing when you call my $sub three times. This is purely a matter of programmer choice, nothing to do with any advantages of the languages (in Python, lexical scoping is the default, no "my" needed). At any rate, there are many times where using unique variable names is going to make for greater clarity than re-using the same names from the enclosing scope.
Maintainability is often underrated. An hour of debugging ugly code versus a quick glance and fix can mean a lot of time, effort, money, and grey hairs saved.

Originally Posted by acerimusdux View Post
I think you missed my point. The only reason for using the library, was to accomplish what you appeared to attempting to do in Perl, somewhat unsuccessfully. After all, you named the file "partial"--which implies that you were trying to demonstrate partial functions.

Of course I could have done it your way without any library usage. I just didn't see the point. It would have looked something like this:

def sub(x):
    result = x
    def sub(y,result=result):
        result = result * y
        def sub(z,result=result):
            return result + z
        return sub
    return sub

for x in [1,2]:
    for y in [3,4]:
        for z in [5,6]:
            print x, y, z, zsub
Really the only differences there are minor idioms related to the individual language. In Python, classes, functions, object instances, and modules all have their own namespace. Conditional blocks like for and while loops don't. When you want different behavior from the default, you just have to be explicit about it.

All default behaviors will have to be over-ridden in some case. Perl likewise has defaults that you would have to override when you want different. The use of the my keyword in your code is in places where you want lexical scoping rather than the default (which in Perl is global--not good if you are concerned about side-effects). Your sample code also takes advantage of Perl's subroutines accepting arguments by default (what if you didn't want it to?) and returning the last calculated value by default (what if you didn't want that value returned?).
This is one of the reasons why I prefer C and Python - explicitness is a Good Thing.

Originally Posted by acerimusdux View Post
But as for what that code actually does, it is semantically no different than this (aside from the printing):

sub=lambda x: lambda y: lambda z: (x,y,z,x*y+z)
D=[[sub(x)(y)(z)] for x in [1,2] for y in [3,4] for z in [5,6]] 

>>>for line in D: print(line)

[(1, 3, 5, 8)]
[(1, 3, 6, 9)]
[(1, 4, 5, 9)]
[(1, 4, 6, 10)]
[(2, 3, 5, 11)]
[(2, 3, 6, 12)]
[(2, 4, 5, 13)]
[(2, 4, 6, 14)]
Note that I am not calling that function with three arguments, I am calling it each time with one argument (with the returned function being used to call the next).
If I ran across that code in production without a comment that explained why it was absolutely necessary, and what they were trying to accomplish I'd assume they were simply trying to be either "clever" or just plain mean.

Originally Posted by acerimusdux View Post
As for the truly functional way to do this, assuming that these multiplication and addition operations are meant to represent far more complex user defined operations (obviously there's no need for separate code blocks at all if all we are doing is using built-ins), my approach would still be similar, but with more generic reusable functions defined for those operations. For example, use function composition:

def add(x,y):
    return x+y
def multiply(x,y):
    return x*y
D=[[[x],[y],[z],[add(multiply(x,y),(z))]] for x in [1,2] for y in [3,4] for z in [5,6]]
Or, if you prefer:

>>> def add(a):
...     def result(b):
...        return a + b
...     return result
>>> def multiply(a):
...     def result(b):
...         return a * b
...     return result

>>> D=[[[x],[y],[z],[(add(multiply(x)(y))(z))]] for x in [1,2] for y in [3,4] for z in [5,6]]

>>> for line in D: print(line)... 
[[1], [3], [5], [8]]
[[1], [3], [6], [9]]
[[1], [4], [5], [9]]
[[1], [4], [6], [10]]
[[2], [3], [5], [11]]
[[2], [3], [6], [12]]
[[2], [4], [5], [13]]
[[2], [4], [6], [14]]
As you can see, there is certainly no barrier here to functional programming. Functions in Python are first class objects, you can pass them as parameters, or as return values. You can nest them as you like, you have full support for recursive functions, you have full support for closures, you have lazy evaluation of (boolean) conditionals, you have strong support built in for iterators, generators, sequences, and list comprehensions, a nice collection of built-in higher order functions, and now "decorators" which behave similarly to macros.

Finally, wrt the discussion on arrays, one could call the list of lists demonstrated above an array. I wouldn't. But, they can be accessed witht he D[6][3] type notation, and if all you are interested in is retrieving and storing data, then dictionaries, lists, and tuples will do fine. Tuples are immutable lists; if values will be stored and not changed much, the tuple will be quick. Lists are mutable, but good if you will be writing as much as reading. Dictionaries are hash tables, which basically require an immutable type for keys (integers, strings, or tuples) but can hold any types as values. That's probably the most efficient way to store and retrieve data (especially mutable objects).

But, if you really need an array of 3 or more dimensions, or are planning on doing any numeric array calculations, such as multiplying or dividing matrixes, etc, you should use the array type from the numeric python library:

from numpy import array, arange

Those will do most anything you can think of with arrays (and not just for numbers, good for all data types).

All that said, I wouldn't be one to say Python is the "more powerful" language; on the contrary I think hw-tph pretty much nailed it back on page one:
I wouldn't even say that Perl is more versatile - both can (and do) use C extensions to get the job done.

It's been a number of years since I wrote Perl in production, so I can't offer an example CPAN module that does such, but in Python, one need not look farther than cElementTree.

And frankly, when one considers that ability - to bypass a particular interpreter's failings (and they all have them) with pure, native C code - it really comes down to which tool a developer is most comfortable with, and which is more maintainable.

To each their own, but I'll stick with the snake. The camel often encourages bad (code) smells.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Best Programming Language for an Old Programmer falcon56215 Linux - General 5 12-22-2007 01:40 PM
LXer: Software tools detect bugs by inferring programmerís intentions LXer Syndicated Linux News 0 07-07-2006 09:54 PM
Programmer/System's Analyst tools Citizen Bleys Programming 0 01-16-2002 05:19 PM > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 05:39 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration