Re: OT - trivial programming language
"s. keeling" <[EMAIL PROTECTED]> writes: > Incoming from Faheem Mitha: >> >> well. The bottom line is that in Python whitespace is syntatically >> meaningful, in C etc. it is not. >> >> This has the consequence that in C, emacs is able to correctly indent >> the code, using the built-in syntax rules it knows about. This is very >> useful since it shows up trivial syntax bugs right away. > > ... which is one of the reasons I truly enjoy coding in emacs. > >> On the other hand, much of the time emacs does not know what to do >> with Python code (when in python mode, that is), since part of the > > This is surely a deficiency in emacs' python mode? Well, Emacs can't read your mind. Consider the following code: if a> synax info is encoded in the whitespace. Blindly hitting tab, which >> works fine with C/C++ and probably most of the other languages out >> there, can really mess up Python code. > > The same is true for shell-mode and perl-mode. But for those modes, it's just a matter of parsing them correctly. (CPerl-mode does a very good job for Perl, FWIW.) For Python, it's an essential property of the language that syntax-driven indentation can't work. The reason is that syntax-driven indentation means that the indentation is driven by the syntax, but for Python, it's the other way round: the syntax is driven by the indentation. Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
"s. keeling" <[EMAIL PROTECTED]> writes: >> On the other hand, much of the time emacs does not know what to do >> with Python code (when in python mode, that is), since part of the > > This is surely a deficiency in emacs' python mode? The mind-reading interface is not yet completed. A sufficiently intelligent python mode could presumably constrain indentation to whichever indentation levels could be valid, but there could be any number of levels. Since python blocks are based on indentation, you could have the option of closing five or more blocks. > You would think that with access to the code in the shell, perl, or > python interpreter, emacs shell, perl, and python modes would do as > well as the shell, perl or python interpreters. You'd have to port the parser to Emacs lisp, then modify it to do syntax annotation instead of code generation. Some work is being done on that with semantic for various things like Java... could be extended to those modes. On the other hand, I don't think there's anyone in the world who really wants to dig into the perl interpreter and try to duplicate it. -- Alan Shutko <[EMAIL PROTECTED]> - I am the rocks. Sign at nursery: Come to me my melon-cauliflower baby. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Incoming from Faheem Mitha: > > well. The bottom line is that in Python whitespace is syntatically > meaningful, in C etc. it is not. > > This has the consequence that in C, emacs is able to correctly indent > the code, using the built-in syntax rules it knows about. This is very > useful since it shows up trivial syntax bugs right away. ... which is one of the reasons I truly enjoy coding in emacs. > On the other hand, much of the time emacs does not know what to do > with Python code (when in python mode, that is), since part of the This is surely a deficiency in emacs' python mode? > synax info is encoded in the whitespace. Blindly hitting tab, which > works fine with C/C++ and probably most of the other languages out > there, can really mess up Python code. The same is true for shell-mode and perl-mode. emacs generally doesn't know what to do, indentation-wise, when it runs into what it considers ambiguous situations. You would think that with access to the code in the shell, perl, or python interpreter, emacs shell, perl, and python modes would do as well as the shell, perl or python interpreters. This is often not the case. I've often found it necessary to comment/escape special chars in perl code to expect (shell|perl)-mode to get it right. I've had to embed comments that warned that the following expression is the way it is because emacs' perl-mode got it wrong, and the code is the way it is because the emacs mode is broken, and the code should be edited before use. Really, for me, it's not a big deal. I can do that. It just seems odd that the mode can't (for whatever reason) do as well as the interpreter/compiler. Whoever's writing the _mode_ parser should be working from the same page as the _code_ parser, no? -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Sat, 29 May 2004 15:54:48 +0200, Kai Grossjohann <[EMAIL PROTECTED]> wrote:
> Steve Lamb <[EMAIL PROTECTED]> writes:
>
>> Faheem Mitha wrote:
>>> Bob Proulx makes good points elsewhere in this thread. Whether you
>>> like the indentation as syntax feature is really a matter of
>>> taste. Personally, I am ambivalent about it. On the one hand it makes
>>> code more compact. On the other hand, indentation is easily lost
>>> information, for example when cutting and pasting. Also, I have the
>>> habit in emacs of hitting tab to get code to line up. I've done this
>>> for years, and it is a hard habit to break. Unfortunately it has
>>> disastrous consequences in python code.
>>
>> So have EMACS treat the tab key as the equivolent number of spaces and
>> write the file out using spaces instead of tabs.
>
> This won't help: in Emacs, TAB computes the right indentation from
> the buffer contents. In C-like languages, this is fairly easy: after
> a "{", indent more, after a "}", indent less. There are a lot of
> other rules, but that's the basic.
>
> But in Python, it is not possible to compute the indentation from the
> buffer contents. This means that just hitting TAB on each line is
> either a no-op (then why are we doing this), or it would get the end
> of a loop wrong and suchlike.
Yes. There have been a lot of people in this thread you have
misunderstood what I was saying. I think Kai summarised it pretty
well. The bottom line is that in Python whitespace is syntatically
meaningful, in C etc. it is not.
This has the consequence that in C, emacs is able to correctly indent
the code, using the built-in syntax rules it knows about. This is very
useful since it shows up trivial syntax bugs right away.
On the other hand, much of the time emacs does not know what to do
with Python code (when in python mode, that is), since part of the
synax info is encoded in the whitespace. Blindly hitting tab, which
works fine with C/C++ and probably most of the other languages out
there, can really mess up Python code. It does know enough to avoid
indenting if you forget the colon at the end of if statement, for
example, so it *is* of some use.
Hope this clarifies things.
Faheem.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes: > Uck, nasty. Give me nothing but spaces, please, because there will be > problems in that setup. The only problem I can see is that the right tab/space mix might get lost. Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Kai Grossjohann wrote:
> Steve Lamb <[EMAIL PROTECTED]> writes:
>>Well, of course it would, You used nothing but tabs to achieve the
>>alignment you wanted. There's no mixing of spaces and tabs.
> There IS mixing of tabs and spaces. It seems there is a
> misunderstanding.
> In the following, I will use "--->" to show a tab and "_" to show a
> (leading) space.
> for(;;) {
> --->if (a == b) {
> --->--->some_long_function_name(a,
> --->--->b);
> --->}
> }
Uck, nasty. Give me nothing but spaces, please, because there will be
problems in that setup.
> I apologize for inadvertently using a multiple of 8 chars in the name
> "some_long_function_name".
> Oh, wait! The name is 23 chars long. Hm.
some_long)function_name( is 24. You forgot the opening paren.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
signature.asc
Description: OpenPGP digital signature
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes:
> Well, of course it would, You used nothing but tabs to achieve the
> alignment you wanted. There's no mixing of spaces and tabs.
There IS mixing of tabs and spaces. It seems there is a
misunderstanding.
In the following, I will use "--->" to show a tab and "_" to show a
(leading) space.
for(;;) {
--->if (a == b) {
--->--->some_long_function_name(a,
--->--->b);
--->}
}
For a function name that's longer by 1 character, you'd get this:
for(;;) {
--->if (a == b) {
--->--->some_long_function_name1(a,
--->--->_b);
--->}
}
With this arrangement of tabs (for indentation) and spaces (for
alignment), you can change the display tab width and get the right
effect.
I apologize for inadvertently using a multiple of 8 chars in the name
"some_long_function_name".
Oh, wait! The name is 23 chars long. Hm.
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Kai Grossjohann wrote:
> To wit, consider this piece of code, based on tab width = 4:
Ok, let's use alternating t and T to represent the tab characters.
> for(;;) {
> if (a == b) {
> some_long_function_name(a,
> b);
> }
> }
> I used spaces only in this message, please pretend that my style of
> mixing tabs and spaces was used. Changing tab display width to 8
> will then produce this:
Well, of course it would, You used nothing but tabs to achieve the
alignment you wanted. There's no mixing of spaces and tabs. A better example
actually mixes tabs and spaces. T and t for alternating tabs. S for spaces.
TW = 4
for(;;) {
if (a == b) {
some_long_function(a,
SSSb);
}
}
TW = 8
for(;;) {
if (a == b) {
some_long_function(a,
SSSb);
}
}
Whoops, a and b no longer line up!
TW=2
for(;;) {
TTif (a == b) {
TTttsome_long_function(a,
TTttTTttTTttSSSb);
TT}
}
Whoops, a and b no longer line up!
Maybe I'm misunderstanding something in your proposal. How, exactly, did
your magiv work? :P
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
signature.asc
Description: OpenPGP digital signature
Re: OT - trivial programming language
Kai Grossjohann wrote: > and also what's the display width of a tab character. Here you would be wrong. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Derrick 'dman' Hudson <[EMAIL PROTECTED]> writes:
> If tabs and spaces are combined for indentation purposes, then when
> you change your tab display width you will see a horrid mess of
> incorrectly indented code.
This is often, but not always the case. I explained how tabs and
spaces are combined so that changing the tab display width will avoid
a horrid mess of incorrectly indented code.
To wit, consider this piece of code, based on tab width = 4:
for(;;) {
if (a == b) {
some_long_function_name(a,
b);
}
}
I used spaces only in this message, please pretend that my style of
mixing tabs and spaces was used. Changing tab display width to 8
will then produce this:
for(;;) {
if (a == b) {
some_long_function_name(a,
b);
}
}
Changing it to 2 will produce this:
for(;;) {
if (a == b) {
some_long_function_name(a,
b);
}
}
Now, you may like some of them better than others, but clearly none of
them is a mess. Each of them looks as you would expect from the
tab width setting.
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes: > Kai Grossjohann wrote: > >> My proposal was meant to allow people to edit the same file, but to >> see different things depending on their preferences. I believe in >> giving people the choice to view things as they like. > > Which doesn't work in a collaberative environment; even then coding > standards are mandated. I'm sure that coding standards prescribe what is in the file, and not what the user sees. Things that the user sees include: which font is used, which colors are used for syntax highlighting, and also what's the display width of a tab character. Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Sat, May 29, 2004 at 09:40:49PM -0600, Monique Y. Mudama wrote: | On 2004-05-29, Steve Lamb penned: | > | >> Syntax highlighting (at least full syntax highlighting), you | >> certainly don't have. | > | > Which would be the one. | | At the risk of undermining my own argument, if you use vim as your | pager, you can get syntax hilighting. That's what I do. I often use vim, just for the colors (even as my pager in 'mutt'). See the script /usr/share/doc/vim/macros/less.vim to make vim more comfortable in a pager type role (as in combination with mutt). | And it turns | out that if you do that, you can also set any variable, including | tab-related ones, during the pager session. (Just found that out.) | But I still don't see why I should have to guess what settings I need to | see the code as the author saw it. This means don't mix tabs and spaces. | I like the ability to change tab representations on the fly, If tabs and spaces are combined for indentation purposes, then when you change your tab display width you will see a horrid mess of incorrectly indented code. | but for code that ever expects to be shared, I think it makes more | sense to use the universal common denominator. Code sharing is the source for all style arguments. Any given group of developers who share code must use the same style (not just indentation) or else comparing changes, etc., becomes quite a nightmare. -D -- In his heart a man plans his course, but the Lord determines his steps. Proverbs 16:9 www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: OT - trivial programming language
On Sun, May 30, 2004 at 07:45:41PM -0700, Steve Lamb wrote:
| Kai Grossjohann wrote:
| > If you have more than one level, then you need to hit >> more often.
| > (At least if my understanding of >> does is right.)
Correct.
| As I said, meaningful problem.
| I certainly don't see this a problem
Same here.
| as I could just prefix it with a count
Almost. With << and >>, the numerical prefix is the number of lines
to operate on, not the number of times to repeat. (I don't know why
it is different from all other commands) Nonetheless, type >> once
and then, for example, 3. to repeat the command three more times.
| and I have found, from personal experience,
| that the problems it avoids far outweights an added keystroke here and there.
Let's not mention the time I spent far too many hours trying to debug
this piece of C++ code :
while (item = list->next()) ;
{
cout << *item ;
}
The list is empty the first time this piece of code is reached. The
program crashes (SEGV) every time, on the line with the 'cout'
statement. Can you see the problem? The same typo in python would
result in a quickly-found syntax error.
In practice the "lack" of braces solves more problems than it creates.
If you want proof, then try it! :-)
-D
PS. I don't remember the exact spelling for getting the next item
from an STL list, but it is similar enough to what I wrote above.
PPS. The list returns NULL when trying to access elements beyond the
end of the list.
--
If your life is a hard drive,
Christ can be your backup.
www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: OT - trivial programming language
On Monday 31 May 2004 09:57, Colin Watson wrote: > Civilized societies should outlaw absurdly-drawn-out coding style > arguments on public mailing lists, especially when I have to > attempt to read them over a tediously slow ssh connection from a > conference in a different hemisphere. Yes, but at least you are at a conference in a different hemisphere. I hope you are having fun. -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Civilized societies should outlaw absurdly-drawn-out coding style arguments on public mailing lists, especially when I have to attempt to read them over a tediously slow ssh connection from a conference in a different hemisphere. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Kai Grossjohann wrote: > If you have more than one level, then you need to hit >> more often. > (At least if my understanding of >> does is right.) As I said, meaningful problem. I certainly don't see this a problem as I could just prefix it with a count and I have found, from personal experience, that the problems it avoids far outweights an added keystroke here and there. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Kai Grossjohann wrote: > My proposal was meant to allow people to edit the same file, but to > see different things depending on their preferences. I believe in > giving people the choice to view things as they like. Which doesn't work in a collaberative environment; even then coding standards are mandated. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes: > Kai Grossjohann wrote: >> This will work for one level of nesting. But this means you need to >> keep track of the nesting levels when moving things around in the >> code. > > Huh? Works for multiple levels. I've often refactored code from simple > functions into a large class oriented framework. That involved moving things > of multiple intention levels to line up. Works fine. If you have more than one level, then you need to hit >> more often. (At least if my understanding of >> does is right.) Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes:
> I set tab width to 4, align at 6. Tab + 2 spaces. Person sets his tabs
> to 8 the line is 10 spaces out, 4 spaces too far. That's why people insist on
> a tab width of 8. If tabs were immutable like that mixing tabs and spaces
> wouldn't be a problem. It's not so it is.
My proposal was to use tabs and spaces in a way so that this does not
happen. Consider the following piece of pidgin C:
if (some_condition) {
if (another_condition) {
foo(a,
b);
/* >| */
In the comment line I have tried to indicate how tabs and spaces are
used for the "b" line: the line starts with two tabs, one for each
level of nesting. After this come spaces.
This means that, regardless of the tab width you choose, you will
always see the b below the a.
If the function name was foobar instead of foo, the "b" line would
still start with two tabs, but then you'd have 7 instead of 4 spaces.
I tried to coin the term "indentation" for the whitespace due to the
nesting level, and the term "alignment" for the spaces that make sure
that "b" and "a" line up. And my proposal was to use tabs for
indentation and spaces for alignment. If this was confusing, then
please accept my apologies.
It goes without saying that the nice property of giving code that
looks good in any tab width setting is lost as soon as you violate
that rule of using tabs and spaces.
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes: > Kai Grossjohann wrote: >> You have mentioned a number of problems, but your proposal has even >> more problems. > > Such as what exactly? > > Indention works. Alignment works. Everyone sees the same thing. This is the problem: everyone sees the same thing. My proposal was meant to allow people to edit the same file, but to see different things depending on their preferences. I believe in giving people the choice to view things as they like. Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Kai Grossjohann wrote: > You have mentioned a number of problems, but your proposal has even > more problems. Such as what exactly? Indention works. Alignment works. Everyone sees the same thing. If they are working on the same code they use the same style. In the case of Python there are also no holy wars about where to put the braces. It is also redily apparent what the code is doing instead of what people might read it doing. I fail to see any meaningful problem at all. I've listed the problems I've referred to. I can only presume since you haven't that you're just imagining them, no? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes: > Kai Grossjohann wrote: >> Well, nothing that couldn't be solved with a somewhat wider window. >> Many people like to have windows wider than 80 columns. (I prefer 80 >> columns, myself.) > > And wider paper? The commonly accepted practice is that code should not > be wider than 80 columns; 78 being about max. That's why most languages > support splitting of lines with \ or other such constructs. Maybe I get ugly printout, but at least I get pretty code on screen! Your proposal means I get ugly printout, and also ugly code on screen. Argh. >>>Thank god it doesn't. That is the worst possible style since tab is >>>meaningless. > >> Hm? > > How wide is a tab? The only acceptable answer is "as wide as the user > configures it." This means mixing tabs and spaces for any reason will > eventually cause problems. You have mentioned a number of problems, but your proposal has even more problems. >>>It is also because of indention and alignment that I think that >>>people should never, ever, us tabs because there are going to be >>>some schmucks that break the first rule of never changing the tab >>>width in the first place. > >> Huh? > > I set tab width to 4, align at 6. Tab + 2 spaces. Person sets his tabs > to 8 the line is 10 spaces out, 4 spaces too far. That's why people insist on > a tab width of 8. If tabs were immutable like that mixing tabs and spaces > wouldn't be a problem. It's not so it is. There is a misunderstanding of what alignment means. Please try to read my proposal again to see that the problem you are proposing does not occur. (Of course, my proposal works only if tabs and spaces are used in the right way. If they are used in the wrong way, then bad things will happen. But that's like the "rm -rf" command: if used in the right way, good things will happen, if used in the wrong way, bad things will happen. So this fact does not make my proposal a bad proposal.) Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
dircha <[EMAIL PROTECTED]> writes: > Kai Grossjohann wrote: > >> The style I'm proposing is designed to make it possible to change >> tab width! > > It does not work. Yeah... > Consider the problems created with a code file created by a user who > prefers 8-character-width tabs _and_ 80 columns. > > Now, when someone who prefers 4-character-width tabs and 80 columns > wishes to collaborate on this document, he or she will find lines > wrapped at ~65-75 characters as they were originally wrapped for > 8-character-width tabs and 80 columns. You can't have the cake and eat it, too. The user has two choices: (a) Live with ugly tab-width=8 but enjoy pretty 80 cols. (b) Enjoy pretty tab-width=4 and live with ugly 65 cols. Your proposal prohibits (b). I don't see how it could be bad to give a user more choices. Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On 2004-05-29, dircha penned: [snippage] > > First, this requires that the user perform a tab width calculation for > each wrapping to determine where it would wrap were it displayed with > code. Well, if you're using vim, at least, you can set the textwidth once for every edit session and be done with it. Not that that isn't a pain. -- monique "The people who run record companies now wouldn't know a song if it flew up their nose and died." -- David Crosby, on PBS Frontline -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On 2004-05-29, Steve Lamb penned: > >> Syntax highlighting (at least full syntax highlighting), you >> certainly don't have. > > Which would be the one. At the risk of undermining my own argument, if you use vim as your pager, you can get syntax hilighting. That's what I do. And it turns out that if you do that, you can also set any variable, including tab-related ones, during the pager session. (Just found that out.) But I still don't see why I should have to guess what settings I need to see the code as the author saw it. I like the ability to change tab representations on the fly, but for code that ever expects to be shared, I think it makes more sense to use the universal common denominator. -- monique "The people who run record companies now wouldn't know a song if it flew up their nose and died." -- David Crosby, on PBS Frontline -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Micha Feigin wrote: On Sat, May 29, 2004 at 04:50:09PM -0500, dircha wrote: Actually the best method when collaborating on someone else's work is to adopt their coding style. If its a joint work then you should a agree on a coding style in the first place. On my last job, every new programmer had as part of the training to read the coding style specifications for the company, and in properly collaborated projects its supposed to be very hard to notice which parts were written by which programmers. I concur! Hence, I conclude: The best proposal is to mandate a fixed tab width or spaces per indent level, and mandate wrapping for a fixed column width. I'm ready to argue that this should generally be 4-character spaces and 80 column wrapping. But then probably no one else would have read through to the end of my post either - better your succinct summary. %) dircha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Sat, May 29, 2004 at 04:50:09PM -0500, dircha wrote:
> Kai Grossjohann wrote:
> >Steve Lamb <[EMAIL PROTECTED]> writes:
> >>if (foo){
> >> if (bar){
> >> foreach $foo (@bar){
> >> while $foo < $baz{
> >> some really long and convoluted computation here
> >> }
> >> }
> >> }
> >>}
> >>
> >>Now expand that out to someone's preferred 8 per line (ew) and
> >>you'll see that the "some really long and convoluted computation
> >>here" is wrapping. On my screen it looks reasonable, on someone
> >>else's it looks like crap.
> >
> >Well, nothing that couldn't be solved with a somewhat wider window.
> >Many people like to have windows wider than 80 columns. (I prefer 80
> >columns, myself.)
>
> This is not an adequate response to scenario's similar to what Steve
> illustrates here. I will elaborate below.
>
> >>It is because of this mixing of tabs and spaces that people rigidly
> >>say that tabs should never be changed from 8 character widths.
> >
> >The style I'm proposing is designed to make it possible to change tab
> >width!
>
> It does not work.
>
> Consider the problems created with a code file created by a user who
> prefers 8-character-width tabs _and_ 80 columns.
>
> Now, when someone who prefers 4-character-width tabs and 80 columns
> wishes to collaborate on this document, he or she will find lines
> wrapped at ~65-75 characters as they were originally wrapped for
> 8-character-width tabs and 80 columns.
>
Actually the best method when collaborating on someone else's work is
to adopt their coding style. If its a joint work then you should a
agree on a coding style in the first place.
Any indentation style will usually be ok as long as it is
consistent. Trouble starts when different people use different
indentation style in the same project.
On my last job, every new programmer had as part of the training to
read the coding style specifications for the company, and in properly
collaborated projects its supposed to be very hard to notice which parts
were written by which programmers.
> In this case the 4-character-width tabs user has only one option to
> retain a style acceptable for use by the 8-character-width tabs user. He
> or she must wrap lines such that for a given line, were it displayed
> with 8-character-width tabs, it would still fit within 80 columns.
>
> First, this requires that the user perform a tab width calculation for
> each wrapping to determine where it would wrap were it displayed with
> 8-character-width tabs. Second, this defeats the original intention of
> the 4-character-width tabs user in using 4-character-width tabs: to use
> a indent width he or she can more easily follow visually and while at
> the same time making more effective use of 80 columns for complex code.
>
> As illustrated by Steve's example above, in either direction of
> conversion, your proposal may as well be to mandate that the tab width
> and column width of the original environment for all collaborating
> users, because for your proposal to work, you must deny the user the
> ability to reap the advantages of his or her preferred environment.
>
> The best proposal is to mandate a fixed tab width or spaces per indent
> level, and mandate wrapping for a fixed column width.
>
> I'm ready to argue that this should generally be 4-character spaces and
> 80 column wrapping.
>
> dircha
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>
>
> +++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Micha Feigin wrote:
> Scrolling depends on several things and off course you can scroll back
> using the console with more and cat if you configure it to save enough
> lines and scroll both ways with less and most but its not as powerful
> as a full editor.
First off we were talking about pagers. Cat is not a pager. That leaves
more and less as pagers in your list. Secondly even if we took only those two
that would mean one is quite good and one isn't. Considering less is pretty
much the de facto standard pager on most unices these days we can reasonibly
compare less to editors. There are others but I do not know them off the top
of my head.
> Searching does work but usually not as good and more cumbersome.
Why do you say that. Let's compare my favorite editor to less. Regex and
Regex. Both use / to start searching forward and both are capable of
searching backwards (not that I know that as I rarely reverse search).
> Syntax highlighting (at least full syntax highlighting), you certainly
> don't have.
Which would be the one.
> And last if its no trouble with customizable indentation then you no
> longer have any claim against tabs.
Quite the contrary it is because they're configurable that there is a
problem. Same as in an editor. What you have configured and what I have
configured may be different.
> BTW if you have problems with my indentation you can always do (in a
> proper programming editor) select all and re-indent (not with python
> according to what people said here which is exactly what I have against
> using syntax for figuring context, beside the fact that it sounds very
> error prone in that respect, I prefer the {} method.
Really. Tell me, what happens when I do that, make some changes and do
any of these:
a: submit a patch.
b: check into cvs.
Oh, yeah, that pesky working with other people problem.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
signature.asc
Description: OpenPGP digital signature
Re: OT - trivial programming language
On Sat, May 29, 2004 at 12:41:53PM -0700, Steve Lamb wrote:
> Micha Feigin wrote:
> > You don't have same power of scrolling, searching, syntax highlighting,
> > customizable indentation etc. as with a proper editor.
>
> Only one of those claims is true. I'll leave it as an exercise to you to
> figure out which one. It'll be good for you as a learning process.
>
Scrolling depends on several things and off course you can scroll back
using the console with more and cat if you configure it to save enough
lines and scroll both ways with less and most but its not as powerful
as a full editor.
Searching does work but usually not as good and more cumbersome.
Syntax highlighting (at least full syntax highlighting), you certainly
don't have.
And last if its no trouble with customizable indentation then you no
longer have any claim against tabs.
BTW if you have problems with my indentation you can always do (in a
proper programming editor) select all and re-indent (not with python
according to what people said here which is exactly what I have against
using syntax for figuring context, beside the fact that it sounds very
error prone in that respect, I prefer the {} method.
> --
> Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
>PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
> ---+-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Kai Grossjohann wrote: > This will work for one level of nesting. But this means you need to > keep track of the nesting levels when moving things around in the > code. Huh? Works for multiple levels. I've often refactored code from simple functions into a large class oriented framework. That involved moving things of multiple intention levels to line up. Works fine. > With syntax-driven indentation, the editor figures it out for you. With syntax-driven indention, the editor has to figure it out for you. > OTOH, perhaps people can quickly *see* whether the indentation is > right. If it isn't, they repeat the >> command. Exactly. Not to mention there's none of the holy wars over where to place the braces. ;) -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Kai Grossjohann wrote:
Steve Lamb <[EMAIL PROTECTED]> writes:
if (foo){
if (bar){
foreach $foo (@bar){
while $foo < $baz{
some really long and convoluted computation here
}
}
}
}
Now expand that out to someone's preferred 8 per line (ew) and
you'll see that the "some really long and convoluted computation
here" is wrapping. On my screen it looks reasonable, on someone
else's it looks like crap.
Well, nothing that couldn't be solved with a somewhat wider window.
Many people like to have windows wider than 80 columns. (I prefer 80
columns, myself.)
This is not an adequate response to scenario's similar to what Steve
illustrates here. I will elaborate below.
It is because of this mixing of tabs and spaces that people rigidly
say that tabs should never be changed from 8 character widths.
The style I'm proposing is designed to make it possible to change tab
width!
It does not work.
Consider the problems created with a code file created by a user who
prefers 8-character-width tabs _and_ 80 columns.
Now, when someone who prefers 4-character-width tabs and 80 columns
wishes to collaborate on this document, he or she will find lines
wrapped at ~65-75 characters as they were originally wrapped for
8-character-width tabs and 80 columns.
In this case the 4-character-width tabs user has only one option to
retain a style acceptable for use by the 8-character-width tabs user. He
or she must wrap lines such that for a given line, were it displayed
with 8-character-width tabs, it would still fit within 80 columns.
First, this requires that the user perform a tab width calculation for
each wrapping to determine where it would wrap were it displayed with
8-character-width tabs. Second, this defeats the original intention of
the 4-character-width tabs user in using 4-character-width tabs: to use
a indent width he or she can more easily follow visually and while at
the same time making more effective use of 80 columns for complex code.
As illustrated by Steve's example above, in either direction of
conversion, your proposal may as well be to mandate that the tab width
and column width of the original environment for all collaborating
users, because for your proposal to work, you must deny the user the
ability to reap the advantages of his or her preferred environment.
The best proposal is to mandate a fixed tab width or spaces per indent
level, and mandate wrapping for a fixed column width.
I'm ready to argue that this should generally be 4-character spaces and
80 column wrapping.
dircha
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Kai Grossjohann wrote: > Well, nothing that couldn't be solved with a somewhat wider window. > Many people like to have windows wider than 80 columns. (I prefer 80 > columns, myself.) And wider paper? The commonly accepted practice is that code should not be wider than 80 columns; 78 being about max. That's why most languages support splitting of lines with \ or other such constructs. >>Thank god it doesn't. That is the worst possible style since tab is >>meaningless. > Hm? How wide is a tab? The only acceptable answer is "as wide as the user configures it." This means mixing tabs and spaces for any reason will eventually cause problems. >>It is also because of indention and alignment that I think that >>people should never, ever, us tabs because there are going to be >>some schmucks that break the first rule of never changing the tab >>width in the first place. > Huh? I set tab width to 4, align at 6. Tab + 2 spaces. Person sets his tabs to 8 the line is 10 spaces out, 4 spaces too far. That's why people insist on a tab width of 8. If tabs were immutable like that mixing tabs and spaces wouldn't be a problem. It's not so it is. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes: > First off it looks damned wrong so you know something's wrong. Where in > the above example it looks wrong but works. It may, in fact, *be* weong. > Secondly I dunno about EMACS but in VIM, highligh the 2 middle lines, hit >>. > Tada, indented just fine. This will work for one level of nesting. But this means you need to keep track of the nesting levels when moving things around in the code. With syntax-driven indentation, the editor figures it out for you. OTOH, perhaps people can quickly *see* whether the indentation is right. If it isn't, they repeat the >> command. Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes:
> Kai Grossjohann wrote:
>> If the middle two lines were indented with a tab, then people could
>> view this code with different indentation settings by just frobbing
>> the tab width, without changing the file contents.
>
> Good in theory, bad in practice. For example, in my Perl code I prefer an
> indention of 2 spaces. Don't ask why, I just do.
:-X
> if (foo){
> if (bar){
> foreach $foo (@bar){
> while $foo < $baz{
> some really long and convoluted computation here
> }
> }
> }
> }
>
> Now expand that out to someone's preferred 8 per line (ew) and you'll
> see that the "some really long and convoluted computation here" is wrapping.
> On my screen it looks reasonable, on someone else's it looks like crap.
Well, nothing that couldn't be solved with a somewhat wider window.
Many people like to have windows wider than 80 columns. (I prefer 80
columns, myself.)
>> The "b" line should start with one tab (for the indentation) and then
>> four spaces (for the alignment with the "a" above it).
>
>> I wish that Emacs would allow this style of editing.
>
> Thank god it doesn't. That is the worst possible style since tab is
> meaningless.
Hm?
> It is because of this mixing of tabs and spaces that people
> rigidly say that tabs should never be changed from 8 character widths.
The style I'm proposing is designed to make it possible to change tab
width!
> It is also because of indention and alignment that I think that
> people should never, ever, us tabs because there are going to be
> some schmucks that break the first rule of never changing the tab
> width in the first place.
Huh?
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Kai Grossjohann wrote:
> What happens when, after moving a block, it is surrounded by more or
> less levels of conditionals or loops? I don't program Python, so I
> don't know.
[ snip ]
> I can paste some lines in the middle of this easily:
> if (...) {
> a;
> d;
> e;
> b;
> }
> Then I tell my editor to reindent the whole thing and Bob's my uncle.
> But if I do the analogous thing in Python, the d line ends the
> conditional...
Actually it would look like this:
if foo:
a
d
e
b
First off it looks damned wrong so you know something's wrong. Where in
the above example it looks wrong but works. It may, in fact, *be* weong.
Secondly I dunno about EMACS but in VIM, highligh the 2 middle lines, hit >>.
Tada, indented just fine.
> But I'm sure that Python programmers don't have this kind of problem,
> so there must be something I'm not seeing.
Of course, we're not expecting our editors to be smarter than we are.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
signature.asc
Description: OpenPGP digital signature
Re: OT - trivial programming language
Micha Feigin wrote:
> Because for good and for bad that will lock you into editor dependency
> (you need the proper indenting capabilities) and coding style.
> The later is not necessarily bad.
How does it lock me into an editor? So far the most significant feature
needed is: autoindent. That's it. I can name seven editor off the top of my
head that are installable by Debian which have autoindent (vi, nvi, elvis,
vim, joe, emacs, jed). Not all of those editors, however, have advanced
automation to make coding for the machine (IE, {}) and for the human (IE,
indention) automagically happen. So once you get used to those that do it is
hard to move to an environment or even try other editors which might not act
exactly the same way. To me that is locking you into the editor moreso than a
simple autoindent.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
signature.asc
Description: OpenPGP digital signature
Re: OT - trivial programming language
Micha Feigin wrote: > You don't have same power of scrolling, searching, syntax highlighting, > customizable indentation etc. as with a proper editor. Only one of those claims is true. I'll leave it as an exercise to you to figure out which one. It'll be good for you as a learning process. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Kai Grossjohann wrote:
> If the middle two lines were indented with a tab, then people could
> view this code with different indentation settings by just frobbing
> the tab width, without changing the file contents.
Good in theory, bad in practice. For example, in my Perl code I prefer an
indention of 2 spaces. Don't ask why, I just do.
if (foo){
if (bar){
foreach $foo (@bar){
while $foo < $baz{
some really long and convoluted computation here
}
}
}
}
Now expand that out to someone's preferred 8 per line (ew) and you'll
see that the "some really long and convoluted computation here" is wrapping.
On my screen it looks reasonable, on someone else's it looks like crap.
> The "b" line should start with one tab (for the indentation) and then
> four spaces (for the alignment with the "a" above it).
> I wish that Emacs would allow this style of editing.
Thank god it doesn't. That is the worst possible style since tab is
meaningless. It is because of this mixing of tabs and spaces that people
rigidly say that tabs should never be changed from 8 character widths. It is
also because of indention and alignment that I think that people should never,
ever, us tabs because there are going to be some schmucks that break the first
rule of never changing the tab width in the first place.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
signature.asc
Description: OpenPGP digital signature
Re: OT - trivial programming language
On Sat, May 29, 2004 at 01:13:38PM +1000, Cameron Hutchison wrote: > Once upon a time Micha Feigin said... > > On Fri, May 28, 2004 at 12:00:03PM -0600, Monique Y. Mudama wrote: > > > On 2004-05-28, [EMAIL PROTECTED] penned: > > > > s. keeling wrote: > > > >> > > > >> However, this is likely only a problem for those of us who hate tabs. > > > >> Those who like tabs are blissfully ignorant of the problems they > > > >> cause. Thankfully, we've found ways to deal with this ridiculous > > > >> preference of yours (man expand, man unexpand, perldoc Text::Tabs, > > > >> ...). > > > > > > > > What kind of problems do using tabs cause? > > > > > > Your or my editor may not let you set the tab display size. > > > > > Pretty lame editor. Get a real one. > > It's not just editors though. To view a file, most of the time I'll use > less(1). Other times I'll cat(1) it to an xterm and use the scrollback > buffer. When printing, mostly I'll use a2ps(1), but sometimes use > mpage(1) or just send the text to lpr(1). > > These are just the programs I use. Others will undoubtedly use other > programs. All these programs are going to need a consistent way to deal > with tab expansion. > > I dont mind people using tabs as long as the tab stop is set to 8 - > because that's what all programs expect as a default. > And thats what I do. Tabs at 8 indentation at 4. > I still prefer to avoid tabs, though. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > +++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Fri, May 28, 2004 at 08:46:22PM -0600, Monique Y. Mudama wrote: > On 2004-05-29, Micha Feigin penned: > > On Fri, May 28, 2004 at 01:32:24PM -0600, s. keeling wrote: > >> > >> And if it's python, we're hosed. > >> > > Since I am not a python user, why so? > > Because in python, scope is determined entirely by indentation. > > >> Here's another: displaying a file in less/more/pg/most may or may not > >> show the same thing we see in our choice of text editor. > >> > > > > That can be setup properly, and it won't be that unreadable and > > considering less/more/etc. weren't meant for reading more the a couple > > lines of code. > > Justify that claim, please. Why shouldn't I use a pager to scan through > pages of code? > You don't have same power of scrolling, searching, syntax highlighting, customizable indentation etc. as with a proper editor. > -- > monique > > "The people who run record companies now wouldn't know a song if it flew up > their nose and died." -- David Crosby, on PBS Frontline > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > +++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Fri, May 28, 2004 at 07:55:49PM -0700, Steve Lamb wrote:
> s. keeling wrote:
> > Indentation is syntactical in python. No, I don't know why.
>
> Better to ask why in most other languages there are two syntaxes. One for
> the computer, one for the human.
>
> This is legal:
> if (foo){bar;}lese{baz;}
>
> So is this:
> if (foo)
> {
> bar;
> }
> else
> {
> baz;
> }
>
> But we're taught to do this (or something like it):
> if (foo)
> {
> bar;
> }
> else
> {
> baz;
> ]
>
> So make the machine read that like the human does and take out the
> portions the machine needs and what are you left with?
>
> if (foo)
> bar
> else
> baz
>
> If we're taught to code that way *anyway* then we should make it
> significant because it is.
Because for good and for bad that will lock you into editor dependency
(you need the proper indenting capabilities) and coding style.
The later is not necessarily bad.
>
> --
> Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
>PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
> ---+-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Incoming from Kai Grossjohann: > > Also, I find it interesting that RMS is not opposed to duplication of > code. Given the results, his position can't be all that stupid. Of > course, this contradicts with the teaching we all got in school, where > they told us that duplicating code leads us to programmer's hell. I'm > still trying to figure out where this contradiction comes from and how > to resolve it. Maybe someone should ask him. I know that if I want something to perform some action, I'd like to call a black box that knows how to do that. Anytime something in that black box is found to be insufficient, I know to go to that black box to fix it. Everything that uses that box is updated when it is. With cut/copy + paste, I don't know where to go to add the fix(es), and I never would know whether I'd found them all. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
"Derrick 'dman' Hudson" <[EMAIL PROTECTED]> writes:
> On Wed, May 26, 2004 at 07:21:38PM +, Faheem Mitha wrote:
>
> | On the other hand, indentation is easily lost
> | information, for example when cutting and pasting.
>
> In practice this isn't a problem. Cut and paste the entire block of
> code and the indentation is preserved.
What happens when, after moving a block, it is surrounded by more or
less levels of conditionals or loops? I don't program Python, so I
don't know.
Given the following pseudo code:
if (...) {
a;
b;
}
I can paste some lines in the middle of this easily:
if (...) {
a;
d;
e;
b;
}
Then I tell my editor to reindent the whole thing and Bob's my uncle.
But if I do the analogous thing in Python, the d line ends the
conditional...
But I'm sure that Python programmers don't have this kind of problem,
so there must be something I'm not seeing.
> Besides, you shouldn't try using the "copy-n-paste" method of code
> reuse because it doesn't work in the long run.
I guess cut and paste (as opposed to copy and paste) is not a problem.
Surely moving code around is something that happens often during
refactoring, and refactoring has become something of a fad recently.
Also, I find it interesting that RMS is not opposed to duplication of
code. Given the results, his position can't be all that stupid. Of
course, this contradicts with the teaching we all got in school, where
they told us that duplicating code leads us to programmer's hell. I'm
still trying to figure out where this contradiction comes from and how
to resolve it.
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
"Monique Y. Mudama" <[EMAIL PROTECTED]> writes:
> I may or may not feel like changing my tabwidth settings just to read
> your g*dd*mn code!
Actually, using real tabs allows us to view the same file with
different indentation levels. However, this requires some thought
and no editor I know of applies the tabs appropriately.
What I mean is that it is possible to write C code in such a way that
it looks "good" with any tabwidth setting. So if you prefer an
indentation step of 2, then set tabwidth to 2 and the code will be
displayed like that. I prefer 4, so I just choose that value and get
nicer indentation that matches my taste.
The key is to distinguish between indentation and alignment.
Indentation happens after a "{" character in C-like languages and
similar constructs. Consider the following code, which has
indentation for the middle two lines:
if (foo) {
some_statement;
another_statement;
}
If the middle two lines were indented with a tab, then people could
view this code with different indentation settings by just frobbing
the tab width, without changing the file contents.
Here is an example of alignment:
foo(a,
b);
The intent is that the a and the b are beneath each other. If the
second line is indented by a tab, then changing the tabwidth can make
the code look bad. Therefore, the second line should start with the
right number of spaces.
It is possible and meaningful to combine indentation and alignment:
if (foo) {
some_statement;
foo(a,
b);
}
The "b" line should start with one tab (for the indentation) and then
four spaces (for the alignment with the "a" above it).
I wish that Emacs would allow this style of editing.
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Steve Lamb <[EMAIL PROTECTED]> writes:
> Faheem Mitha wrote:
>> Bob Proulx makes good points elsewhere in this thread. Whether you
>> like the indentation as syntax feature is really a matter of
>> taste. Personally, I am ambivalent about it. On the one hand it makes
>> code more compact. On the other hand, indentation is easily lost
>> information, for example when cutting and pasting. Also, I have the
>> habit in emacs of hitting tab to get code to line up. I've done this
>> for years, and it is a hard habit to break. Unfortunately it has
>> disastrous consequences in python code.
>
> So have EMACS treat the tab key as the equivolent number of spaces and
> write the file out using spaces instead of tabs.
This won't help: in Emacs, TAB computes the right indentation from
the buffer contents. In C-like languages, this is fairly easy: after
a "{", indent more, after a "}", indent less. There are a lot of
other rules, but that's the basic.
But in Python, it is not possible to compute the indentation from the
buffer contents. This means that just hitting TAB on each line is
either a no-op (then why are we doing this), or it would get the end
of a loop wrong and suchlike.
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On 2004-05-29, Micha Feigin penned: > On Fri, May 28, 2004 at 01:32:24PM -0600, s. keeling wrote: >> >> And if it's python, we're hosed. >> > Since I am not a python user, why so? Because in python, scope is determined entirely by indentation. >> Here's another: displaying a file in less/more/pg/most may or may not >> show the same thing we see in our choice of text editor. >> > > That can be setup properly, and it won't be that unreadable and > considering less/more/etc. weren't meant for reading more the a couple > lines of code. Justify that claim, please. Why shouldn't I use a pager to scan through pages of code? -- monique "The people who run record companies now wouldn't know a song if it flew up their nose and died." -- David Crosby, on PBS Frontline -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On 2004-05-29, [EMAIL PROTECTED] penned: > What if the editor you're using actually puts five spaces when you hit > tab? In that case, just about any editor should display it correctly. > Then you're not using tabs and no one cares. I don't care if you type alt-ctrl-apple-B to insert your 5 spaces, so long as they end up as spaces. (But 5? Eww!) -- monique "The people who run record companies now wouldn't know a song if it flew up their nose and died." -- David Crosby, on PBS Frontline -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Once upon a time Micha Feigin said... > On Fri, May 28, 2004 at 12:00:03PM -0600, Monique Y. Mudama wrote: > > On 2004-05-28, [EMAIL PROTECTED] penned: > > > s. keeling wrote: > > >> > > >> However, this is likely only a problem for those of us who hate tabs. > > >> Those who like tabs are blissfully ignorant of the problems they > > >> cause. Thankfully, we've found ways to deal with this ridiculous > > >> preference of yours (man expand, man unexpand, perldoc Text::Tabs, > > >> ...). > > > > > > What kind of problems do using tabs cause? > > > > Your or my editor may not let you set the tab display size. > > > Pretty lame editor. Get a real one. It's not just editors though. To view a file, most of the time I'll use less(1). Other times I'll cat(1) it to an xterm and use the scrollback buffer. When printing, mostly I'll use a2ps(1), but sometimes use mpage(1) or just send the text to lpr(1). These are just the programs I use. Others will undoubtedly use other programs. All these programs are going to need a consistent way to deal with tab expansion. I dont mind people using tabs as long as the tab stop is set to 8 - because that's what all programs expect as a default. I still prefer to avoid tabs, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Is it perhaps time to take this argument off-list? Just a thought.
Patrick
On Fri, 28 May 2004, Steve Lamb wrote:
:s. keeling wrote:
:> Indentation is syntactical in python. No, I don't know why.
:
:Better to ask why in most other languages there are two syntaxes. One for
:the computer, one for the human.
:
:This is legal:
:if (foo){bar;}lese{baz;}
:
:So is this:
:if (foo)
:{
:bar;
:}
:else
:{
:baz;
:}
:
:But we're taught to do this (or something like it):
:if (foo)
:{
:bar;
:}
:else
:{
:baz;
:]
:
:So make the machine read that like the human does and take out the
:portions the machine needs and what are you left with?
:
:if (foo)
:bar
:else
:baz
:
:If we're taught to code that way *anyway* then we should make it
:significant because it is.
:
:--
: Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
: PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
:---+-
:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
s. keeling wrote:
> Indentation is syntactical in python. No, I don't know why.
Better to ask why in most other languages there are two syntaxes. One for
the computer, one for the human.
This is legal:
if (foo){bar;}lese{baz;}
So is this:
if (foo)
{
bar;
}
else
{
baz;
}
But we're taught to do this (or something like it):
if (foo)
{
bar;
}
else
{
baz;
]
So make the machine read that like the human does and take out the
portions the machine needs and what are you left with?
if (foo)
bar
else
baz
If we're taught to code that way *anyway* then we should make it
significant because it is.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
signature.asc
Description: OpenPGP digital signature
Re: OT - trivial programming language
Incoming from [EMAIL PROTECTED]: > What if the editor you're using actually puts five spaces when you hit > tab? In that case, just about any editor should display it correctly. My editors (emacs & vim) do. Display is not the only problem. What happens in vi(m) when you're sitting on a tab character? First, the cursor is at the far right of the tab character _just so you know you're on a tab character_! Why? Probably because someone once told vi "7x" to remove white space, and ended up mangling his file instead. I repeat; do whatever you damn well want to. We've got expand to make up for your perversion. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Incoming from Micha Feigin: > On Fri, May 28, 2004 at 01:32:24PM -0600, s. keeling wrote: > > > > And if it's python, we're hosed. > > Since I am not a python user, why so? Indentation is syntactical in python. No, I don't know why. > > Here's another: displaying a file in less/more/pg/most may or may not > > show the same thing we see in our choice of text editor. > > considering less/more/etc. weren't meant for reading more the a couple > lines of code. ... In your opinion. Maybe you should fight that one out with the vi zealots. It's the same functionality they rely on (:n). > > Tabs are *evil*. > > Don't agree here. I'm happy for you. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Incoming from Micha Feigin: > On Fri, May 28, 2004 at 12:00:03PM -0600, Monique Y. Mudama wrote: > > On 2004-05-28, [EMAIL PROTECTED] penned: > > > s. keeling wrote: > > >> > > >> However, this is likely only a problem for those of us who hate tabs. > > >> Those who like tabs are blissfully ignorant of the problems they > > >> cause. Thankfully, we've found ways to deal with this ridiculous > > >> preference of yours (man expand, man unexpand, perldoc Text::Tabs, > > > > > > What kind of problems do using tabs cause? > > > > Your editor may not display tabs as the same number of characters as my > > editor does. > > Then set it to that if you wish to read the file. Both vim and emacs as Sigh. Now I have to run to a manpage just to be able to read your file? > > Your or my editor may not let you set the tab display size. > > Pretty lame editor. Get a real one. Now you get to decide what software I use?!? > > I may or may not feel like changing my tabwidth settings just to read > > Then don't read the g*dd*mn code if you don't want to. Count on it! -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Fri, May 28, 2004 at 01:32:24PM -0600, s. keeling wrote: > Incoming from Monique Y. Mudama: > > On 2004-05-28, [EMAIL PROTECTED] penned: > > > > > > s. keeling wrote: > > >> > > >> However, this is likely only a problem for those of us who hate tabs. > > >> Those who like tabs are blissfully ignorant of the problems they > > >> cause. Thankfully, we've found ways to deal with this ridiculous > > > > > > What kind of problems do using tabs cause? > > > > I may or may not feel like changing my tabwidth settings just to read > > your g*dd*mn code! > > And if it's python, we're hosed. > Since I am not a python user, why so? > Here's another: displaying a file in less/more/pg/most may or may not > show the same thing we see in our choice of text editor. > That can be setup properly, and it won't be that unreadable and considering less/more/etc. weren't meant for reading more the a couple lines of code. > Tabs are *evil*. > Don't agree here. > > -- > Any technology distinguishable from magic is insufficiently advanced. > (*) http://www.spots.ab.ca/~keeling > - - > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > +++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Fri, May 28, 2004 at 12:00:03PM -0600, Monique Y. Mudama wrote: > On 2004-05-28, [EMAIL PROTECTED] penned: > > > > > > s. keeling wrote: > >> > >> However, this is likely only a problem for those of us who hate tabs. > >> Those who like tabs are blissfully ignorant of the problems they > >> cause. Thankfully, we've found ways to deal with this ridiculous > >> preference of yours (man expand, man unexpand, perldoc Text::Tabs, > >> ...). > > > > What kind of problems do using tabs cause? > > Let's start with this: > > Your editor may not display tabs as the same number of characters as my > editor does. > Then set it to that if you wish to read the file. Both vim and emacs as examples also let you set tab size for only the current file and also set it in a comment so it will always use that tab size when you open that file. > Your or my editor may not let you set the tab display size. > Pretty lame editor. Get a real one. > Your or my editor may not let you display tabs as "special characters". > It also won't display space as a special character and a proper editor can be configured to display tabs as special characters if you wish so (read my previous remark). > I may or may not feel like changing my tabwidth settings just to read > your g*dd*mn code! > Then don't read the g*dd*mn code if you don't want to. > -- > monique > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > +++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
What if the editor you're using actually puts five spaces when you hit tab? In that case, just about any editor should display it correctly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Incoming from Monique Y. Mudama: > On 2004-05-28, [EMAIL PROTECTED] penned: > > > > s. keeling wrote: > >> > >> However, this is likely only a problem for those of us who hate tabs. > >> Those who like tabs are blissfully ignorant of the problems they > >> cause. Thankfully, we've found ways to deal with this ridiculous > > > > What kind of problems do using tabs cause? > > I may or may not feel like changing my tabwidth settings just to read > your g*dd*mn code! And if it's python, we're hosed. Here's another: displaying a file in less/more/pg/most may or may not show the same thing we see in our choice of text editor. Tabs are *evil*. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On 2004-05-28, [EMAIL PROTECTED] penned: > > > s. keeling wrote: >> >> However, this is likely only a problem for those of us who hate tabs. >> Those who like tabs are blissfully ignorant of the problems they >> cause. Thankfully, we've found ways to deal with this ridiculous >> preference of yours (man expand, man unexpand, perldoc Text::Tabs, >> ...). > > What kind of problems do using tabs cause? Let's start with this: Your editor may not display tabs as the same number of characters as my editor does. Your or my editor may not let you set the tab display size. Your or my editor may not let you display tabs as "special characters". I may or may not feel like changing my tabwidth settings just to read your g*dd*mn code! -- monique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
s. keeling wrote: However, this is likely only a problem for those of us who hate tabs. Those who like tabs are blissfully ignorant of the problems they cause. Thankfully, we've found ways to deal with this ridiculous preference of yours (man expand, man unexpand, perldoc Text::Tabs, ...). What kind of problems do using tabs cause? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Incoming from Micha Feigin: > On Thu, May 27, 2004 at 05:56:00PM -0700, Steve Lamb wrote: > > > > No self respecting programmer should ever use tabs. Ever. And yeah, I > > know certain people (*cough*Linus*cough*) does, doesn't mean the rest of us > > It doesn't really matter what method you use as long as you are > consistent. It doesn't matter how consistent you are. As soon as you accept a file from someone else, you're back at square one. However, this is likely only a problem for those of us who hate tabs. Those who like tabs are blissfully ignorant of the problems they cause. Thankfully, we've found ways to deal with this ridiculous preference of yours (man expand, man unexpand, perldoc Text::Tabs, ...). -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Thu, May 27, 2004 at 05:56:00PM -0700, Steve Lamb wrote: > Micha Feigin wrote: > > And I don't remember the syntax, but you can get vim to use tabs > > instead of spaces also. > > No self respecting programmer should ever use tabs. Ever. And yeah, I > know certain people (*cough*Linus*cough*) does, doesn't mean the rest of us > mere mortals should lest we get get so full of ourselves and go the way of > Bernstien. >.< > I use tabs and I like them (don't know why, but...). All I need to do for that is make sure the different programs I use are consistent on the width of tab (8 spaces in my case). It doesn't really matter what method you use as long as you are consistent. > -- > Steve C. Lamb | I'm your priest, I'm your shrink, I'm your >PGP Key: 8B6E99C5 | main connection to the switchboard of souls. > ---+- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Micha Feigin wrote: > And I don't remember the syntax, but you can get vim to use tabs > instead of spaces also. No self respecting programmer should ever use tabs. Ever. And yeah, I know certain people (*cough*Linus*cough*) does, doesn't mean the rest of us mere mortals should lest we get get so full of ourselves and go the way of Bernstien. >.< -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
On Wed, May 26, 2004 at 04:41:55PM -0600, s. keeling wrote: > Incoming from Steve Lamb: > > Faheem Mitha wrote: > > > Bob Proulx makes good points elsewhere in this thread. Whether you > > > like the indentation as syntax feature is really a matter of > > > taste. Personally, I am ambivalent about it. On the one hand it makes > > > > So have EMACS treat the tab key as the equivolent number of spaces and > > write the file out using spaces instead of tabs. I'd tell you how but I'm a > > vim user and that is how vim handles it. > And I don't remember the syntax, but you can get vim to use tabs instead of spaces also. > fwiw: > > -x h# mark entire buffer > > -x untabify # convert tabs to equivalent no. of spaces > > And you can stuff (setq-default indent-tabs-mode nil) into your > startup file so the TAB key inserts the equivalent number of spaces > instead of TAB characters. > > > -- > Any technology distinguishable from magic is insufficiently advanced. > (*) http://www.spots.ab.ca/~keeling > - - > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > +++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Incoming from Steve Lamb: > Faheem Mitha wrote: > > Bob Proulx makes good points elsewhere in this thread. Whether you > > like the indentation as syntax feature is really a matter of > > taste. Personally, I am ambivalent about it. On the one hand it makes > > So have EMACS treat the tab key as the equivolent number of spaces and > write the file out using spaces instead of tabs. I'd tell you how but I'm a > vim user and that is how vim handles it. fwiw: -x h# mark entire buffer -x untabify # convert tabs to equivalent no. of spaces And you can stuff (setq-default indent-tabs-mode nil) into your startup file so the TAB key inserts the equivalent number of spaces instead of TAB characters. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Faheem Mitha wrote: > Bob Proulx makes good points elsewhere in this thread. Whether you > like the indentation as syntax feature is really a matter of > taste. Personally, I am ambivalent about it. On the one hand it makes > code more compact. On the other hand, indentation is easily lost > information, for example when cutting and pasting. Also, I have the > habit in emacs of hitting tab to get code to line up. I've done this > for years, and it is a hard habit to break. Unfortunately it has > disastrous consequences in python code. So have EMACS treat the tab key as the equivolent number of spaces and write the file out using spaces instead of tabs. I'd tell you how but I'm a vim user and that is how vim handles it. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
On Wed, May 26, 2004 at 07:21:38PM +, Faheem Mitha wrote: | On Fri, 21 May 2004 20:33:14 -0400, richard lyons <[EMAIL PROTECTED]> wrote: | | > That makes two votes for Python (the other was off-list). I've had it | > in mind to find time to investigate Python -- so I'll have a go at | > that. | | Make that 3 votes. :-) I recently started learning Python. I like | it. It has a very clean syntax. Python is easy to learn, flexible, powerful, clean, and fun. (IMO) It scales down to "scripting" quite well and also scales up to enterprise applications. It is my preferred language. If you are familiar with programming, then an hour or two spent reading the tutorial (http://www.python.org/doc/tut/tut.html) will be enough to learn most of the language. If you aren't already familiar with programming (in another language) then I recommend reading Alan Gauld's tutorial instead (http://www.freenetpages.co.uk/hp/alan.gauld/). | Bob Proulx makes good points elsewhere in this thread. Whether you | like the indentation as syntax feature is really a matter of | taste. Personally, I am ambivalent about it. On the one hand it makes | code more compact. If you think indentation doesn't matter, join any C, C++ or Java project and start suggesting new indentation conventions. This is one of the biggest never-ending sources of a flamewar you can find. No matter how you look at it, after you have written code (or even prose!) for a while, you interpret the indentation level mentally as you read the text. Python takes it one step further and uses the same interpretation you use to interpret the code. You can easily write wrong C or Java code that looks correct until you notice the indentation and the punctuation (braces) don't match and the compiler reads the code in a way you didn't intend. My point is only that C and Java programmers care about indentation just as much as Python, even though some claim otherwise. | On the other hand, indentation is easily lost | information, for example when cutting and pasting. In practice this isn't a problem. Cut and paste the entire block of code and the indentation is preserved. Besides, you shouldn't try using the "copy-n-paste" method of code reuse because it doesn't work in the long run. | Also, I have the | habit in emacs of hitting tab to get code to line up. I've done this | for years, and it is a hard habit to break. Configure your editor correctly and this is not a problem. I don't use emacs, but you can find plenty of instructions on the web, I am sure, to tell emacs how you want it to behave when the button on your keyboard engraved with the label 'Tab' is pressed. http://www.python.org/emacs/python-mode/ If you use vim, set the following options. set et sts=4 sw=4 ts=8 With these settings, vim will use spaces only to indent, with an indentation level of 4. I can press the keyboard button labeled 'Tab' 3 times and vim inserts 12 spaces. I can then press backspace once and vim deletes 4 spaces (one indentation level) and I can begin typing the line of code with 8 spaces of indentation. Configure the tool to serve you. | Unfortunately it has | disastrous consequences in python code. Mixing tabs and spaces is bad, particularly if your configure your editor to treat a tab (either in display or otherwise) as something other than 8 spaces in width. However, if you want to use tabs exclusively that is not a problem. | Bob says ruby is pretty good, and I believe him. However, libraries | are a make-or-break feature. The nicest language in the world is | useless without comprehensive libraries, and python is up there when | it comes to libraries. True. -D -- "...the word HACK is used as a verb to indicate a massive amount of nerd-like effort." -Harley Hahn, A Student's Guide to Unix www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: OT - trivial programming language
On Fri, 21 May 2004 20:33:14 -0400, richard lyons <[EMAIL PROTECTED]> wrote: > That makes two votes for Python (the other was off-list). I've had it > in mind to find time to investigate Python -- so I'll have a go at > that. Make that 3 votes. :-) I recently started learning Python. I like it. It has a very clean syntax. Bob Proulx makes good points elsewhere in this thread. Whether you like the indentation as syntax feature is really a matter of taste. Personally, I am ambivalent about it. On the one hand it makes code more compact. On the other hand, indentation is easily lost information, for example when cutting and pasting. Also, I have the habit in emacs of hitting tab to get code to line up. I've done this for years, and it is a hard habit to break. Unfortunately it has disastrous consequences in python code. Bob says ruby is pretty good, and I believe him. However, libraries are a make-or-break feature. The nicest language in the world is useless without comprehensive libraries, and python is up there when it comes to libraries. I am not sure how ruby compares. Also, there are a lot of interesting projects forming around python, eg. boost-python and pyx. Debian supports python pretty well. All significant free software projects involving python (that I am aware of) are in Debian. Also, Debian has a nice Python policy which makes things work well. Faheem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Monday 24 May 2004 06:00, Nick Croft wrote: > * richard lyons ([EMAIL PROTECTED]) wrote: > > H 0.00 > > > > On Sunday 23 May 2004 12:35, Joachim Fahnenmueller wrote: > > > Hi Richard > > > > > > On Fri, May 21, 2004 at 02:55:35PM -0400, richard lyons wrote: > > > > I'm asking for a bit of advice here. > > > > > > > > I wish to convert a kaddressbook database to abook format > > > > saving as many fields as possible. > > Have you considered Vim. Open the original file. Write a macro, > test it on the first line. Apply it to the whole file. I admit I hadn't. I have continued for twenty years using the same 5% of vi/vim. I have decided to put the learning effort into either python or ruby. If I am investing time it might as well be on a new language and on one with many potential uses. But it won't be this week... to much else on my plate. Thanks -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
richard lyons <[EMAIL PROTECTED]> writes:
> But it seems to me most rational to use the opportunity to begin
> learning one of the lighter languages that I keep seeing mention of.
> So the question is, which do you people recommend?
IMHO, none of Perl, Python, Ruby is "lighter" than the others. So I
suggest to just let your taste decide. "Clean syntax" is an advantage
that you could use for some (all?) of them.
awk and sed are nice, but they are limited in some ways, so as soon
as you want to do something that they are not so well-suited to do,
you will start to invent workarounds. That's why I usually use awk
for single one-liners such as "foo | awk '{print $2}'", but otherwise
I use one of the others.
Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
* richard lyons ([EMAIL PROTECTED]) wrote: > H 0.00 > > On Sunday 23 May 2004 12:35, Joachim Fahnenmueller wrote: > > Hi Richard > > > > On Fri, May 21, 2004 at 02:55:35PM -0400, richard lyons wrote: > > > I'm asking for a bit of advice here. > > > > > > I wish to convert a kaddressbook database to abook format saving > > > as many fields as possible. Have you considered Vim. Open the original file. Write a macro, test it on the first line. Apply it to the whole file. Regexes work in a way that this is familiar to users of sed and perl. And a wonderful mailing list with people eager to take up your task as a challenge. Just a thought. Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Sunday 23 May 2004 12:35, Joachim Fahnenmueller wrote: > Hi Richard > > On Fri, May 21, 2004 at 02:55:35PM -0400, richard lyons wrote: > > I'm asking for a bit of advice here. > > > > I wish to convert a kaddressbook database to abook format saving > > as many fields as possible. [...] > I did a similar thing using awk. Actually, it tries to convert a > xml addressbook format to csv, but it can be rewritten to do the > other way. > > See http://www.fahnenmueller.privat.t-online.de/abx2csv/ [...] Thanks, Joachim. I have downloaded it and had a quick look. I find awk very taxing to read, but I get the drift, and shall be able to learn a few things from it - if I can only fond the time to sit with the man page and the script ... -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
Hi Richard On Fri, May 21, 2004 at 02:55:35PM -0400, richard lyons wrote: > I'm asking for a bit of advice here. > > I wish to convert a kaddressbook database to abook format saving as > many fields as possible. > > (...) > > But it seems to me most rational to use the opportunity to begin > learning one of the lighter languages that I keep seeing mention of. > So the question is, which do you people recommend? > > The input data will be the cvs dump from kmail, and the output will be > abook native format, which is a series of numbered paragraphs , > reminiscent of an doze .ini file. That is to say, it begins: >[2] >name=name >[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] >address=address_1 >address2=address_2 >city=hereville >... > so I assume sed is less than optimal. It seems like a function I > might need again, so it is worth having it in a script. > > (...) > TIA > > -- > richard > I did a similar thing using awk. Actually, it tries to convert a xml addressbook format to csv, but it can be rewritten to do the other way. See http://www.fahnenmueller.privat.t-online.de/abx2csv/ HTH -- Joachim Fahnenmüller # Hi! I'm a .signature virus. Copy me into # your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
richard lyons wrote: > I keep seeing mention of Ruby, but have no idea what its strengths > are. I was biting my fingers to keep from posting a pro-ruby message. But now I can't resist. Perl is a very "evolved" language. It grew like a mold. It was not designed into the language that it is today. Don't get me wrong. I have used Perl very much and it has been very useful to me. But I am tired of the warts. People like Ruby for similar reasons to why people like Python. These are languages which were _designed_ to be a language. People compare them because they are both similar and different from Perl in many of the same ways. Really Ruby and Python are in many ways more alike than they are dissimilar. But as with any two things that fill similar purposes there will be competition between them even if the authors did not start out with competition in mind. Ruby is an extremely well thought out language. The author did an excellent job of crafting an elegant and powerful language. But Ruby was created in Japan and until a few years ago the documentation was all in Japanese. That limited its adoption in western countries and is why it has only recently become well known outside of Japan. But now that the western programmers have rallied around ruby most of the documentation is available in english[1]. And Ruby has been very well tested by years of production use. You will find it a solid performer. I highly recommend Ruby. For a summary of the language itself I can't do anywhere near as good of a job at describing it as the Pragmatic Programmer's do so please read the preface of the provided reference for that. But it all boils down to this. Python uses indention for control flow. Python advocates claim this is a feature. Others claim this is a terrible misfeature. Regardless I think most will agree that this one particular aspect of the language has probably prevented it from becoming the dominant language of the three. Bob [1] The most popular Ruby reference is available both as a paper book and as an online reference here. Very well written. http://www.rubycentral.com/book/index.html pgphS3QM20PX3.pgp Description: PGP signature
Re: OT - trivial programming language
On Fri, 21 May 2004, richard lyons wrote: > On Friday 21 May 2004 18:56, Benedict Verheyen wrote: > > richard lyons wrote: > > > I'm asking for a bit of advice here. > [...] > > > learning one of the lighter languages that I keep seeing mention > > > of. So the question is, which do you people recommend? > [...] > > > > A lot of languages are suited for this. A really easy language to > > learn is > > Python. There is also php, java and so on. > > php is really for talking to a webserver, which is unnecessary for the > kind of things I have in mind. Java... hmmm... I keep seeing mention > of Ruby, but have no idea what its strengths are. Perl seems > overqualified - even though I have played with it a bit. Not sure what "overqualified" means in this context - on a reasonably modern machine, the speed and memory overhead for loading perl is likely to be indistinguishable for most tasks from that for loading python, sed, awk, ruby, or even (gasp) Java. > > > But if i where you i would first > > have a look at Python. > > That makes two votes for Python (the other was off-list). I've had it > in mind to find time to investigate Python -- so I'll have a go at > that. > Python isn't meaningfully smaller or faster. The difference between perl and python seems to be mostly one of preference and personal history -- the syntaxes are very different, so it can be hard to move between perl and python. I happened to learn perl and have used it a lot, so would use perl for this; it's easier than deciding whether, say, awk is optimal for a given task and then using awk. I suspect others deal similarly with python. But what the heck - here's a vote for perl. ap -- Andrew J Perrin - http://www.unc.edu/~aperrin Assistant Professor of Sociology, U of North Carolina, Chapel Hill [EMAIL PROTECTED] * andrew_perrin (at) unc.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Fri, May 21, 2004 at 02:55:35PM -0400, richard lyons wrote: > I'm asking for a bit of advice here. > > I wish to convert a kaddressbook database to abook format saving as > many fields as possible. > > I could do this by exporting to cvs, importing to gnumeric (or any > spreadsheet), shuffling the columns around, re-exporting to cvs and > importing back to abook. I'll lose a lot more than I want to, as the > abook cvs is only a partial dump. > > I could do it in BASIC - I still vaguely remember my first language! > > I could probably do it in perl - but I've never really learned perl, > and would have to work from the manual. > > But it seems to me most rational to use the opportunity to begin > learning one of the lighter languages that I keep seeing mention of. > So the question is, which do you people recommend? > It sounds like sed or awk is the optimal solution for what you want to do. > The input data will be the cvs dump from kmail, and the output will be > abook native format, which is a series of numbered paragraphs , > reminiscent of an doze .ini file. That is to say, it begins: >[2] >name=name >[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] >address=address_1 >address2=address_2 >city=hereville >... > so I assume sed is less than optimal. It seems like a function I > might need again, so it is worth having it in a script. > > I really do need to equip myself with a convenient scripting language > for all these day-to-day admin tasks, and I'd like it if it can do a > little maths for me at time too. Please advise me which manual to > open. > > TIA > > -- > richard > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > +++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
richard lyons wrote: [...] A lot of languages are suited for this. A really easy language to learn is Python. There is also php, java and so on. php is really for talking to a webserver, which is unnecessary for the kind of things I have in mind. Java... hmmm... I keep seeing mention of Ruby, but have no idea what its strengths are. Perl seems overqualified - even though I have played with it a bit. PHP may most commonly be used to talk to a webserver, but it works just fine as a normal scripting languague, if the package is compiled with the necessary options. -Roberto Sanchez signature.asc Description: OpenPGP digital signature
Re: OT - trivial programming language
Benedict Verheyen wrote: richard lyons wrote: I'm asking for a bit of advice here. I wish to convert a kaddressbook database to abook format saving as many fields as possible. The input data will be the cvs dump from kmail, and the output will be abook native format, which is a series of numbered paragraphs , reminiscent of an doze .ini file. That is to say, it begins: [2] name=name > A lot of languages are suited for this. A really easy language to learn is Python. There is also php, java and so on. But if i where you i would first have a look at Python. Another vote for Python. I believe the Pyton library even contains a module for dealing with Windows-style ini files. -- "Codito ergo sum" Roel Schroeven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Friday 21 May 2004 18:56, Benedict Verheyen wrote: > richard lyons wrote: > > I'm asking for a bit of advice here. [...] > > learning one of the lighter languages that I keep seeing mention > > of. So the question is, which do you people recommend? [...] > > A lot of languages are suited for this. A really easy language to > learn is > Python. There is also php, java and so on. php is really for talking to a webserver, which is unnecessary for the kind of things I have in mind. Java... hmmm... I keep seeing mention of Ruby, but have no idea what its strengths are. Perl seems overqualified - even though I have played with it a bit. > But if i where you i would first > have a look at Python. That makes two votes for Python (the other was off-list). I've had it in mind to find time to investigate Python -- so I'll have a go at that. Thanks for the input. -- richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
richard lyons wrote: > I'm asking for a bit of advice here. > > I wish to convert a kaddressbook database to abook format saving as > many fields as possible. > > I could do this by exporting to cvs, importing to gnumeric (or any > spreadsheet), shuffling the columns around, re-exporting to cvs and > importing back to abook. I'll lose a lot more than I want to, as the > abook cvs is only a partial dump. > > I could do it in BASIC - I still vaguely remember my first language! > > I could probably do it in perl - but I've never really learned perl, > and would have to work from the manual. > > But it seems to me most rational to use the opportunity to begin > learning one of the lighter languages that I keep seeing mention of. > So the question is, which do you people recommend? > > The input data will be the cvs dump from kmail, and the output will be > abook native format, which is a series of numbered paragraphs , > reminiscent of an doze .ini file. That is to say, it begins: >[2] >name=name > > [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] > address=address_1 address2=address_2 city=hereville ... > so I assume sed is less than optimal. It seems like a function I > might need again, so it is worth having it in a script. > > I really do need to equip myself with a convenient scripting language > for all these day-to-day admin tasks, and I'd like it if it can do a > little maths for me at time too. Please advise me which manual to > open. > > TIA > > -- > richard A lot of languages are suited for this. A really easy language to learn is Python. There is also php, java and so on. But if i where you i would first have a look at Python. Regards, Benedict -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT - trivial programming language
On Fri, 21 May 2004 14:55:35 -0400
richard lyons <[EMAIL PROTECTED]> wrote:
> I'm asking for a bit of advice here.
>
> I wish to convert a kaddressbook database to abook format saving as
> many fields as possible.
>
[ ... ]
>
> I could probably do it in perl - but I've never really learned perl,
> and would have to work from the manual.
>
Perl is a great language. I think it can solve many issues quickly, but it does
appear large and overwhelming at first.
>
> I really do need to equip myself with a convenient scripting language
> for all these day-to-day admin tasks, and I'd like it if it can do a
> little maths for me at time too. Please advise me which manual to
> open.
>
Until this past year, I used three primary tools in conjunction with the Bourne Shell
for my "day-to-day admin tasks": sed, grep and awk. With these three tools you can
manipulate text to your heart's content. In this case, if I didn't want to use perl,
awk is a good choice. For example,
echo "hanson,carlos,[EMAIL PROTECTED],123 street,somewhere,555-1234" |
awk '
BEGIN { FS="," }
{
printf ("[%s]\n", NR)
printf ("name=%s %s\n", $2, $1)
printf ("email=%s\n", $3)
printf ("address=%s\n", $4)
printf ("city=%s\n", $5)
printf ("phone=%s\n", $6)
printf ("\n")
}'
but the equivalent in perl script is
#!/usr/bin/perl
my $count = 1;
while (<>) {
chomp;
my @record = split(/,/);
printf ("[%s]\n", $count++);
printf ("name=%s %s\n", $record[1], $record[0]);
printf ("email=%s\n", $record[2]);
printf ("address=%s\n", $record[3]);
printf ("city=%s\n", $record[4]);
printf ("phone=%s\n", $record[5]);
printf ("\n");
}
If I was to do something quick on the command line, I would use sed, grep and awk.
Otherwise, I try to use perl. Perl is a combination of those tools and more.
Enjoy.
--
Carlos Hanson
Webmaster and Postmaster
Tigard-Tualatin School District
ph: 503.431.4053
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
