Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Trying to learn LISP but having problems with EMACS?
New Posts  All Forums:Forum Nav:

Trying to learn LISP but having problems with EMACS? - Page 2

post #11 of 15
Quote:
Originally Posted by Point Blank Rob View Post

original-number is not defined so you cant use that;
I am also confident that my method is different to newtons method, which would be more obvious discussing them in plain english or algebra should make this more obvious;
Newtons method: if we call the initial guess g and the number we are square rooting y;
y/g=x (x+g)/2= new g REPEAT

My method;
g^2=z z-y=k g-k/y=new g REPEAT

If we imagine we are trying to find the square root of 9 and use a guess of 4;
newtons method gives; 9/4=2.25 (2.25+4) / 2= 3.125

my method gives; 4^2=16 16-9=7 7 / 9= 0.778 4 - 0.778 = 3.222

Obviously my method is less efficient, but this doesnt both me since it is an alternative method and i didnt want to end up simply typing out the solution given in the MIT example since I wouldnt learn anything from doing that.
It is worth noting if you use my method that it only returns results quickly for numbers lower than 50, above this value it takes increasingly long, also the values returned are negative.
Thanks


When you call the sqrt function, you define a value for x. This value is then passed to the guess function.

post #12 of 15
Quote:
Originally Posted by hajile View Post

1. Try coding what you saw in python. It doesn't look better. Python has it's own hidden problem; if you indent more than a couple of times, it is very hard to keep track of which block you are in. I've had this bite me in the past when I've copied in code and thought I had indented it properly. I now use visual indentation indicators in VIM to alleviate that problem, but I also use parenthesis counters (which are supported on every text editor you can think of except MS notepad). It is worth noting that the code samples you linked to are not for the language the OP is learning and are instead for common lisp. I would once again challenge you to write this code in python and compare.

Look up M-expressions. When John McCarthy first discovered lisp, he intended to use M-expressions to make the code look more like FORTRAN. If you mess around with M-exp, you will find that you can make your code look a lot like python code (take a look at the Scheme sweet expressions if that's your thing). It turns out that most people who program in lisp PREFER the parenthesis over M-exp. Finally,

2. Once again, if your editor matches parenthesis, they aren't a problem. Even if you had to count them by hand, they would still be easier syntax than Python or even C as there are fewer rules to remember which necessarily means that more time is left. The power of a language is always important. If you know scheme, it's easier to learn the powerful features of scheme than to learn another language and then learn those features. Since the overhead of learning the language is minimal, it doesn't waste much time if you never touch the language again and it won't hinder the memorization of the rules another language has.

3. If he/she did not actually learn anything, then scheme is still a great first language (that's what it was designed for and many prestigious colleges and universities still require it either as an intro class or a "learn on your own because you'll still need it"). If important parts of programming were grasped, then they will come back quickly. I find it interesting that people seldom forget how to program in scheme -- even if they never use it. The simplicity of the syntax means that (unlike C) going for long periods without use doesn't hurt nearly as bad.

I don't know if lisp is the greatest programming language, but it's power and simplicity are very hard to beat (perhaps prolog or forth come close?). Python is a good language, but it doesn't compare to what scheme offers if for no other reason than a lack of usable functional methods nor in major areas such as block vs functional scoping. Ruby would be a much better comparison. Although it uses block scoping (causing interesting effects), it is much more lisp-like. As to the worst languages to learn first, I first learned IBM BASIC when I was 10 or so and my next language was perl (at about 12) with Javascript quickly following (I only thought I'd learned it -- there was so much about JS I didn't know that I would have if I had known scheme). I don't remember the exact order of the languages I learned after that, but if I could do it over, I'd start with lisp (and then C).

Okay, we could continuously go back and forth refuting each other's point until the cow's come home, so I'll just drop the debate. It would also serve no purpose to keep this going because the OP is obviously just going to go ahead with LISP (or Scheme, to be specific). However, I strongly disagree with you on some points you mentioned, so I will refute those and only those points.
1. "Python has it's own hidden problem; if you indent more than a couple of times, it is very hard to keep track of which block you are in." Most cases of deeply nested code can either be refactored or optimized. If none of that works, the problem should be solved using another approach. So, this 'hidden problem' in Python is the fault of the programmer if anything. Also, don't you think that this 'hidden problem' can be found in LISP code too?
2. "Even if you had to count them by hand, they would still be easier syntax than Python or even C as there are fewer rules to remember which necessarily means that more time is left." Many people agree that Python is basically just executable pseudocode. LISP uses Polish notation. I understand that most people can easily learn the notation, but I don't think that somebody beginning programming should have to do this and it might get them to back down from learning how to program. However, if that person learned Python first, this wouldn't be a problem, and that person would still get many great features found in LISP and a much more friendly & forgiving language.
3. "I don't know if lisp is the greatest programming language." Nope, it's definitely the greatest programming language ever.
4. "Ruby would be a much better comparison. Although it uses block scoping (causing interesting effects), it is much more lisp-like." You do know that you can basically convert Python code into LISP code line by line, right? Also, I haven't learned Ruby yet, but whenever I see someone coding in Ruby, I almost always confuse it with Python code because it looks SO similar and end up embarrassing myself somehow.
Edited by BuizelON - 6/28/13 at 6:52pm
post #13 of 15
Quote:
Originally Posted by BuizelON View Post


Okay, we could continuously go back and forth refuting each other's point until the cow's come home, so I'll just drop the debate. It would also serve no purpose to keep this going because the OP is obviously just going to go ahead with LISP (or Scheme, to be specific). However, I strongly disagree with you on some points you mentioned, so I will refute those and only those points.
1. "Python has it's own hidden problem; if you indent more than a couple of times, it is very hard to keep track of which block you are in." Most cases of deeply nested code can either be refactored or optimized. If none of that works, the problem should be solved using another approach. So, this 'hidden problem' in Python is the fault of the programmer if anything. Also, don't you think that this 'hidden problem' can be found in LISP code too?
2. "Even if you had to count them by hand, they would still be easier syntax than Python or even C as there are fewer rules to remember which necessarily means that more time is left." Many people agree that Python is basically just executable pseudocode. LISP uses Polish notation. I understand that most people can easily learn the notation, but I don't think that somebody beginning programming should have to do this and it might get them to back down from learning how to program. However, if that person learned Python first, this wouldn't be a problem, and that person would still get many great features found in LISP and a much more friendly & forgiving language.
3. "I don't know if lisp is the greatest programming language." Nope, it's definitely the greatest programming language ever.
4. "Ruby would be a much better comparison. Although it uses block scoping (causing interesting effects), it is much more lisp-like." You do know that you can basically convert Python code into LISP code line by line, right? Also, I haven't learned Ruby yet, but whenever I see someone coding in Ruby, I almost always confuse it with Python code because it looks SO similar and end up embarrassing myself somehow.

The refactoring statement also holds true of lisp -- it's not too hard to reduce the number of nested pairs. Indentation isn't a problem in lisp because it ignores whitespace (have you ever programmed in lisp?)

 

Python also uses polish notation extensively. When you create a class like the basic one below, you are creating a prefix (polish) notation that python internally converts to infix and overloads (a decidedly bad idea IMHO, but that's another topic). In fact, any function is a prefix notation. Python is far more complex in that it uses a random mix of prefix, infix, and postfix notation while lisp does not.

class MyClass:
    __init__(self, something):
        self.something = "whatever"

    __add__(self, other):
        return MyClass(self.something + other)


-- comparison of python and scheme functions

def MyFunction(x):
    #do something
    #nested functions --- a not so uncommon practice
    return outer(inner(x), another_inner( with_an_inner(), y))

(define (my-function x)
  ;;do something
  ;;nested functions
  (outer (inner x) (another-inner (with_an_inner) y))) )

-- notice that the difference is only whether the parenthesis surround the function name.
-- also note that return is implicit in lisp reducing the amount of extraneous stuff
-- while the lack of commas clears up the syntax. Let's show them again next to each other



  return outer(inner(x), another_inner( with_an_inner(), y))
  (outer (inner x) (another-inner (with_an_inner) y)))

-- which looks simpler? Which is more legible?

 

Ruby looks superficially like Python to the extent that C++ looks superficially like Java. Once you program in both, you'll recognize many differences in both the languages and how you do things. For example, Ruby encourages the passing of code blocks as parameters (a bit different from lambdas in Ruby) while Python mostly prefers a more traditional function call way of coding (though decorators have become more popular with time). Another interesting bit of historical difference is that Ruby was based on the idea that everything is an object (borrowed from smalltalk) while python used to keep types (such as strings or numbers) separate from objects -- a now remedied problem.

 

As to converting python code to lisp code, sure you can -- the logic doesn't change, but the idea that it's line for line identical is foolish. The datatypes are too different. Python strings are lisp symbols (while lisp strings are real, mutable strings). Python "arrays" are sometimes arrays (called vectors in scheme), but most of the time are more similar to linked lists which are two separate lisp data types with different performance and use cases. Many function calls have vastly different names and if you start using more advanced features in either language, there isn't ANY correlation (try converting a macro line by line or try converting closures that are used as objects).

post #14 of 15
1. "Indentation isn't a problem in lisp because it ignores whitespace (have you ever programmed in lisp?)" I'm pretty sure if somebody calls a language the greatest one ever, that person would logically have to have programmed in it. Anyways, I was talking about how the code looked like, sorry about that redface.gif.
2. "Python is far more complex in that it uses a random mix of prefix, infix, and postfix notation while lisp does not." Okay, you got me there.
3.
Code:
-- comparison of python and scheme functions

def MyFunction(x):
    #do something
    #nested functions --- a not so uncommon practice
    return outer(inner(x), another_inner( with_an_inner(), y))

(define (my-function x)
  ;;do something
  ;;nested functions
  (outer (inner x) (another-inner (with_an_inner) y))) )

-- notice that the difference is only whether the parenthesis surround the function name.
-- also note that return is implicit in lisp reducing the amount of extraneous stuff
-- while the lack of commas clears up the syntax. Let's show them again next to each other

  return outer(inner(x), another_inner( with_an_inner(), y))
  (outer (inner x) (another-inner (with_an_inner) y)))

-- which looks simpler? Which is more legible?
You know what, you're right, it does look more legible in LISP.

Wow, I never realized all of these problems Python had. I guess LISP is a better language for beginners. You win. thumb.gif
post #15 of 15
If the guy already has some experience in C++ then learning Python would be like going from a sports car to a tricycle. And there really isn't much point in learning the basics because he should already have that nailed. So I see no reason why learning LISP is a bad idea.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Coding and Programming
Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Trying to learn LISP but having problems with EMACS?