I decided to give Lisp another go, after having dipped my toe into it
some time ago, and deciding I didn't like it. I'm using Emacs 21.3.1 to
experiment with. I tried to write a little program which prepends line
numbers to a file. Here's what I came up with:
(defun go ()
(find-file "~/test.txt")
(setq num-lines (count-lines (window-start) (window-end)))
(goto-char (point-min))
(dotimes (line-number num-lines)
(setq real-line-num (+ 1 line-number))
(goto-line real-line-num)
(insert (format "%4d " real-line-num)))
(write-file "~/result.txt"))
(go)
(save-buffers-kill-emacs)
I found that, this time around, Lisp wasn't the nightmare that I was
expecting it to be. I actually wrote the above program quite quickly,
despite having almost zero knowledge about Lisp and the emacs-specific
functions. I think that writing it in an imperative style, rather than
an FP style, helped. Does that make me less of a man?
I program in VBA for a living but use Python for scripting whenever I
get the chance. It's a pity that emacs doesn't come with NNTP routines
out-of-the-box, because I'd then probably try to translate my Usenet
Group Summariser from Python to Lisp.
I'm having serious doubts about the merits of python's whitespace block
delimiting style. The problem is when you share code with others, or
even change the editor you use; those tabs and spaces can really mess
you up.
Just my two cents.
Mark Carter <···········@yahoo.co.uk> writes:
> I decided to give Lisp another go, after having dipped my toe into it
> some time ago, and deciding I didn't like it. I'm using Emacs 21.3.1
> to experiment with. I tried to write a little program which prepends
> line numbers to a file. Here's what I came up with:
>
> (defun go ()
> (find-file "~/test.txt")
> (setq num-lines (count-lines (window-start) (window-end)))
> (goto-char (point-min))
> (dotimes (line-number num-lines)
> (setq real-line-num (+ 1 line-number))
> (goto-line real-line-num)
> (insert (format "%4d " real-line-num)))
> (write-file "~/result.txt"))
>
> (go)
> (save-buffers-kill-emacs)
>
> I found that, this time around, Lisp wasn't the nightmare that I was
> expecting it to be. I actually wrote the above program quite quickly,
> despite having almost zero knowledge about Lisp and the emacs-specific
> functions.
Awright!
> I think that writing it in an imperative style, rather than an FP
> style, helped. Does that make me less of a man?
Heh. No, what would make you less of a man is being a slave to dogma.
As my experience with Lisp grew, I found I used a functional style
with increasing frequency because some code seemed more elegant that
way. But, there are plenty of cases where let's and setq's, iteration
and whatever else one wants to call non-FP are a good thing. So do
what seems natural to you. If there is something better, you'll
eventually find it. Sometimes Lisp is classified as a functional
language. Nevertheless, in general, Lisp is agnostic with respect to
FP/non-FP.
> I program in VBA for a living but use Python for scripting whenever I
> get the chance. It's a pity that emacs doesn't come with NNTP routines
> out-of-the-box, because I'd then probably try to translate my Usenet
> Group Summariser from Python to Lisp.
I think you probably do have an nntp.el in your installation.
> I'm having serious doubts about the merits of python's whitespace
> block delimiting style. The problem is when you share code with
> others, or even change the editor you use; those tabs and spaces can
> really mess you up.
I've always considered Python's indentation thing an obviously bad
idea. But every language has something stupid about it. All things
considered, it's a swell language. Have you tried py-shell with
emacs?
--
John M. Adams
In article <···············@RAKTABIJA.stsci.edu>,
·······@stsci.edu (John M. Adams) wrote:
> > I'm having serious doubts about the merits of python's whitespace
> > block delimiting style. The problem is when you share code with
> > others, or even change the editor you use; those tabs and spaces can
> > really mess you up.
>
> I've always considered Python's indentation thing an obviously bad
> idea. But every language has something stupid about it. All things
> considered, it's a swell language. Have you tried py-shell with
> emacs?
I've never done enough Python to figure out whether or not indentation
screwups bite you in practise, but it sure seems like a really dumb idea
to me. I mean ... I use C-M-\ *all* the time while moving things around
in every other language I use. That's not going to work in Python.
I've been using Ruby more and more lately for scripting-type stuff. As
far as I'm aware there's nothing in Python that Ruby doesn't do as well,
but with sane syntax.
Ruby's "something stupid" seems to be the scoping rules. But then
Python has its own version of that :(
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> I've been using Ruby more and more lately for scripting-type stuff. As
> far as I'm aware there's nothing in Python that Ruby doesn't do as well,
> but with sane syntax.
I found Python's syntax quite "okay". Nothing particularly painful or
glorious. But implicit local variables did really suck (say when you
forgot a Globals declaration).
Regards,
--
Julian Stecklina
Signed/encrypted mail welcome. Key-ID: 0xD65B2AB5
-> GIVE stylish confetti to HEAVILY ARMED CLOWN <-
-> Heavily Armed Clown: Wheeee!! <-
Julian Stecklina <··········@web.de> wrote in message news:<··············@goldenaxe.localnet>...
> Bruce Hoult <·····@hoult.org> writes:
>
> > I've been using Ruby more and more lately for scripting-type stuff. As
> > far as I'm aware there's nothing in Python that Ruby doesn't do as well,
> > but with sane syntax.
>
> I found Python's syntax quite "okay". Nothing particularly painful or
> glorious. But implicit local variables did really suck (say when you
> forgot a Globals declaration).
Or when you want to write a code walker that needs to know what
bindings exist in a given scope. Things are a lot easier when you just
have to look at the left child of the syntax tree to identify which
syntax you are looking at, and when the bound variables are all in a
nice list in a well-known place of that tree.
Kaz Kylheku wrote:
> Julian Stecklina <··········@web.de> wrote in message news:<··············@goldenaxe.localnet>...
>
>>Bruce Hoult <·····@hoult.org> writes:
>>
>>
>>>I've been using Ruby more and more lately for scripting-type stuff. As
>>>far as I'm aware there's nothing in Python that Ruby doesn't do as well,
>>>but with sane syntax.
>>
>>I found Python's syntax quite "okay". Nothing particularly painful or
>>glorious. But implicit local variables did really suck (say when you
>>forgot a Globals declaration).
>
>
> Or when you want to write a code walker that needs to know what
> bindings exist in a given scope. Things are a lot easier when you just
> have to look at the left child of the syntax tree to identify which
> syntax you are looking at, and when the bound variables are all in a
> nice list in a well-known place of that tree.
A Python user thinking about programming at the level of abstraction at
which the feasility of writing code-walkers becomes salient? That must
be Norvig still trying to get Python to be Lisp.
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Bruce Hoult <·····@hoult.org> writes:
> I've never done enough Python to figure out whether or not indentation
> screwups bite you in practise, but it sure seems like a really dumb idea
> to me. I mean ... I use C-M-\ *all* the time while moving things around
> in every other language I use. That's not going to work in Python.
Maybe you just need to start using `C-x r k' and `C-x TAB'. :-)
-Luke
Bruce Hoult <·····@hoult.org> writes:
> I've never done enough Python to figure out whether or not indentation
> screwups bite you in practise,
Given the C++ code I was confronted with an hour ago (indentation
completely random), Python's significant indentation just went up
significantly in my estimation. We need protection from such authors :-)
> Ruby's "something stupid" seems to be the scoping rules.
Care to give a 2 minute summary? (I've not looked into Ruby, but I
mean to.)
Mark Carter <···········@yahoo.co.uk> wrote:
> I'm having serious doubts about the merits of python's whitespace block
> delimiting style. The problem is when you share code with others, or
> even change the editor you use; those tabs and spaces can really mess
> you up.
That's no problem for me. I've added this to my init.el:
(load "cl-indent")
(setq lisp-indent-function (function common-lisp-indent-function))
(global-set-key [(control i)] 'indent-region)
(global-set-key [(control a)] 'mark-whole-buffer)
So if I want to read some code which is badly formatted (or to format my
own code :-) , I past it to Emacs, hit Ctrl-a and Ctrl-i and it will be
formatted perfectly (only line-breaks must be inserted or deleted, when
appropriate, see http://www.lisp.org/table/style.htm ).
If you want to use with Common Lisp, perhaps Slime would be useful, if
you like Emacs:
http://common-lisp.net/project/slime/
http://common-lisp.net/project/slime/doc/slime.pdf
http://www.cliki.net/SLIME-HOWTO
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Mon, 12 Jul 2004, Frank Buss wrote:
> Mark Carter <···········@yahoo.co.uk> wrote:
>
> > I'm having serious doubts about the merits of python's whitespace block
> > delimiting style. The problem is when you share code with others, or
> > even change the editor you use; those tabs and spaces can really mess
> > you up.
>
> That's no problem for me. I've added this to my init.el:
>
> (load "cl-indent")
> (setq lisp-indent-function (function common-lisp-indent-function))
> (global-set-key [(control i)] 'indent-region)
> (global-set-key [(control a)] 'mark-whole-buffer)
First, he was talking about having problems with cutting and pasting
Python code, not Lisp code. Second, your choice of keybindings plays
havoc with normal Emacs keybindings. C-i (also known as TAB) is normally
bound to lisp-indent-line, and C-a to beginning-of-line.
Also, there are already keybindings for those two functions:
C-x h --> mark-whole-buffer
M-C-\ --> indent-region
But you should also be considering using commands like M-C-q
(slime-reindent-defun, in SLIME), instead. And learning about C-h a
(apropos-command), C-h c (describe-key-briefly), C-h b
(describe-bindings), and the other C-h help commands which you could have
used to determine all this information.
Matthew Danish <·······@andrew.cmu.edu> wrote:
> First, he was talking about having problems with cutting and pasting
> Python code, not Lisp code.
you are right, I misunderstood it, but perhaps it may help anyway :-)
> Second, your choice of keybindings plays
> havoc with normal Emacs keybindings. C-i (also known as TAB) is
> normally bound to lisp-indent-line, and C-a to beginning-of-line.
I'm working a lot with Eclipse and other Windows style editors, so I
prefer to customize Emacs instead of switching all the time mentally
between different key-bindings. "TAB" is bound to my "TAB"-key and
beginning-of-line to my "POS1"-key, so this is no problem. Maybe it would
be a problem with pair-programming
(http://c2.com/cgi/wiki?PairProgramming) but at this time I do Lisp
programming only as a hobby at home.
> Also, there are already keybindings for those two functions:
> C-x h --> mark-whole-buffer
> M-C-\ --> indent-region
Have you tried M-C-\ on a german keyboard layout? Backslash requires a
modifier key (Alt Gr), like the shift key for writing upper case, it's a
nightmare.
> But you should also be considering using commands like M-C-q
> (slime-reindent-defun, in SLIME), instead. And learning about C-h a
> (apropos-command), C-h c (describe-key-briefly), C-h b
> (describe-bindings), and the other C-h help commands which you could
> have used to determine all this information.
yes, I'll take a look at it.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Mark Carter <···········@yahoo.co.uk> writes:
> I decided to give Lisp another go, after having dipped my toe into it
> some time ago, and deciding I didn't like it. I'm using Emacs 21.3.1
> to experiment with. I tried to write a little program which prepends
> line numbers to a file. Here's what I came up with:
>
> (defun go ()
> (find-file "~/test.txt")
> (setq num-lines (count-lines (window-start) (window-end)))
> (goto-char (point-min))
> (dotimes (line-number num-lines)
> (setq real-line-num (+ 1 line-number))
> (goto-line real-line-num)
> (insert (format "%4d " real-line-num)))
> (write-file "~/result.txt"))
>
> (go)
> (save-buffers-kill-emacs)
>
> I found that, this time around, Lisp wasn't the nightmare that I was
> expecting it to be. I actually wrote the above program quite quickly,
> despite having almost zero knowledge about Lisp and the emacs-specific
> functions. I think that writing it in an imperative style, rather than
> an FP style, helped. Does that make me less of a man?
Forget it.
You can use Lisp perfectly for "imperative" stuff.
>
> I program in VBA for a living but use Python for scripting whenever I
> get the chance. It's a pity that emacs doesn't come with NNTP routines
> out-of-the-box, because I'd then probably try to translate my Usenet
> Group Summariser from Python to Lisp.
You are sligthly wrong in this Group about Emacs Lisp. This group
mainly is about Common Lisp. I suggest you visit comp.emacs or
comp.emacs.xemacs
Well and you are slighly wrong about NNTP either. You wan to check out
Gnuss and especially the nntp.el file for NNTP access. Gnus is "the"
news-reader under (X)Emacs so everything you need (and very much
beyond that I assume) is there.
> I'm having serious doubts about the merits of python's whitespace
> block delimiting style. The problem is when you share code with
> others, or even change the editor you use; those tabs and spaces can
> really mess you up.
Be invited to check out Common Lisp. You may like it, maybe even more
than Emacs Lisp. Or because of you Python background you might want to
check Ruby.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich Dominicus wrote:
> Mark Carter <···········@yahoo.co.uk> writes:
> Well and you are slighly wrong about NNTP either. You wan to check out
> Gnuss and especially the nntp.el file for NNTP access.
D'oh, I see it now. Just having a quick shufty through it, I see that it
looks like it's got what I've been looking for.
> you might want to
> check Ruby.
I installed Ruby once, but it somehow messed up the TCL that Python
wanted to use. So I quickly uninstalled it. Ruby appears to be into
objects in a big way, and as I am personally am not overfussed about
object-orientation, I wasn't particularly itching to try it. All-in-all,
I decided to give Lisp another bash instead of Ruby, because it seemed
to be the one that everyone should have a go at at some point.
Ruby certainly seems to be gaining momentum, and it will be interesting
to see how well adopted it is in a few years time. Perhaps it will have
to overcome the inertia of the Perl, PHP and Python advocates who will
want to know the answer to the question of Why Another Language. Has
anyone noticed any particular takeup or slowdown in Lisp's popularity
over the past couple of years?
Interestingly, Perl, PHP, Python and Ruby are all driven by a central
character determined to make their respective language a success. Maybe
that is what's lacking in Lisp.
Thanks go to other respondants to my email for their kind responses.
Mark Carter <···········@yahoo.co.uk> writes:
> I think that writing it in an imperative style, rather than an FP
> style, helped. Does that make me less of a man?
No, it just means that you have managed to work out for yourself
something which many others fail to grasp[*], even when it is pointed
out to them: Lisp is a multi-paradigm language.
BTW, Emacs Lisp (while very good as a scripting language for an
Editor^H^H^H^H^H^H operating system) is not a good representative of
modern Lisp. Have a look at Common Lisp.
[*] Of course, often the reason for not grasping it is that it would
take some of the fun out of the popular pastime of spreading
ignorant lies about Lisp :-)
Mark Carter <···········@yahoo.co.uk> writes:
> I decided to give Lisp another go, after having dipped my toe into it
> some time ago, and deciding I didn't like it. I'm using Emacs 21.3.1
> to experiment with. I tried to write a little program which prepends
> line numbers to a file. Here's what I came up with:
>
> (defun go ()
> (find-file "~/test.txt")
> (setq num-lines (count-lines (window-start) (window-end)))
> (goto-char (point-min))
> (dotimes (line-number num-lines)
> (setq real-line-num (+ 1 line-number))
> (goto-line real-line-num)
> (insert (format "%4d " real-line-num)))
> (write-file "~/result.txt"))
Not bad! I was going to try and help out by showing you the version I
have in my ~/.emacs, but it turns out yours is better already :-)
Here're a few tips all the same:
(setq num-lines ..) assigns to a global variable called
num-lines. You could use a local variable instead with `let'.
(window-start) and (window-end) give the boundaries of the visible
part of the text. You can use (point-min) and (point-max) to get the
boundaries of the text itself (the "buffer").
For convenience you might like to make this a command that operates
on the currently selected text (the "region").
Here's one way to write it like that:
(defun number-lines (start end)
"Number lines in the region."
(interactive "r")
(goto-char start)
(beginning-of-line)
(dotimes (line (count-lines start end))
(insert (format "%4d " line))
(forward-line)))
The (interactive ...) line makes it possible to invoke this command
with `M-x number-lines'.
A somewhat fancier version would use only as many columns as
needed. Here's the (somewhat cryptic) version I put in my .emacs now:
(defun number-lines (start end)
"Number lines in the region."
(interactive "r")
(goto-char start)
(beginning-of-line)
(let* ((lines (count-lines start end))
(digits (1+ (truncate (log lines 10)))))
(dotimes (i lines)
(insert (format (format "%%%ds " digits) (1+ i)))
(forward-line))))
BTW, I set Follow-Up: to comp.emacs, since they mostly talk about
Common Lisp rather than Emacs Lisp in comp.lang.lisp.
-Luke
Mark Carter <···········@yahoo.co.uk> writes:
> I decided to give Lisp another go, after having dipped my toe into it
> some time ago, and deciding I didn't like it. I'm using Emacs 21.3.1
How long ago? Which Lisp did you try back then?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> Mark Carter <···········@yahoo.co.uk> writes:
>
>>I decided to give Lisp another go, after having dipped my toe into it
>>some time ago, and deciding I didn't like it. I'm using Emacs 21.3.1
>
> How long ago?
About a year ago.
> Which Lisp did you try back then?
I tried CLisp from Sourceforge.
Mark Carter wrote:
>>> I decided to give Lisp another go, after having dipped my toe into it
>>> some time ago, and deciding I didn't like it. I'm using Emacs 21.3.1
>>
>> How long ago?
>
> About a year ago.
>
>> Which Lisp did you try back then?
>
> I tried CLisp from Sourceforge.
I downloaded the (nearly) latest version of clisp. I tried out an old
version of ilisp from late 2002 that I found on one of my CDs, but I
didn't like it much. So I downloaded slime, to see how it would compare.
What a difference! Configuration was straightforward, and I got a nice
SLIME menu that allowed me to evaluate the last definition in my buffer
(plus other bits, of course). I think that this is much more like what
people would expect to see for a development environment. Ilisp seemed
fiddlier and underpowered by comparison. I couldn't even connect to its
website.
Hope noone takes offense at my critisism.