<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Having written a bit of Python..really just a bit..you are all privy to ALL of the Python I have ever written...I'll bite.<BR>
<BR>
It's fairly obvious once you write a bit of Python what goes on here.<BR>
<BR>
First, we all know that we all strive to indent things "correctly".<BR>
Now, "correctly" can vary somewhat, but the intent is universal.<BR>
Deeper lexical nesting goes with increased indentation.<BR>
You can pick the indent size, spaces vs. tabs, where the braces/begin/end go, but it's still the same intent.<BR>
<BR>
Now, when paired with begin/end or braces, you end up with a large duplication of information.<BR>
The one the compiler uses only and the ones human use more.<BR>
You get to keep them in sync. Your editor might help a lot.<BR>
<BR>
What Python does is merely throw out half the data, and require some consistency on your part for what in other languages the compiler ignores.<BR>
I don't know the exact rules, but they are probably easy to think of.<BR>
That is, it could easily allow either spaces or tabs.<BR>
<BR>
This approach is not bad. But I have two problems:<BR>
1) again, my editor<BR>
2) it's a little wierd and hard to see when you have a whole lot of closes in a row<BR>
<BR>
if <BR>
print <BR>
if <BR>
print <BR>
if <BR>
print <BR>
nothing here <BR>
<BR>
vs. either C or Modula-3.<BR>
Perhaps a better approach is to require "end" and require consistent indentation.<BR>
Python also can't cope with an empty statement because of this plus its lack of semicolons.<BR>
You have to say "pass". That's a bit of an indictment.<BR>
<BR>
As to tabs, the answer is very easy. Never ever use them.<BR>
Lots of folks use 4 space tabs, lots of folks use 8 space tabs.<BR>
I used to be a 4 space tab guy, but I gave up tabs a few years ago.<BR>
The Cygwin code uses 8 space tabs and is therefore unreadable to me.<BR>
(I could change my editor setting, and since the 4 space tabs are pretty rare now, ok.)<BR>
<BR>
To those who suggested emacs for convenient Modula-3 editing, sorry, it's not likely going to happen.<BR>
I have tried vi and emacs multiple times through the years and I can't use either.<BR>
I use vi just for editing commit comments, which are often pasted in to the console from notepad anyway.<BR>
<BR>
My "problem" is that I make heavy use of the arrows, home, end, page up, page down, control, and shift.<BR>
(control can "accelerate" arrows, shift is used for selecting).<BR>
And some other ingrained keyboard short cuts like control-f, F3, etc.<BR>
I use Visual C++ 5.0 and its support for these keys, plus a little bit of support for indentation, is excellent.<BR>
It could be that the newer versions are better, and I would like find-and-REPLACE in files, and support for unicode files, but these aren't worth it so far. Oh, and the find-in-files, minus a replace option, is excellent, just super duper, I use it constantly. Nothing else compares.<BR>
<BR>
The only people I try to get to change editors is people that use notepad.<BR>
<BR>
On PPC_DARWIN I make do with TextWrangler. It is ok. (From the BBEdit folks).<BR>
On PPC_LINUX I make do with kate (came with KDE/YellowDog). It is ok.<BR>
<BR>
If anyone out there is struggling with too-basic editors such as TextEdit or whatever it's called these days, I'd recommend trying these. But if you are already using a "programmer's editor", I'll leave you alone. :)<BR>
If anyone knows of something more comparable to Visual C++ 5.0 on other platforms, I'm eager to hear.<BR>
(Maybe under Wine? But that requires x86 I think..)<BR>
<BR>
Oh, CodeWarrior is ok too, and cross platform (well, Mac/Windows), but it starts up slowly on Windows, crashes a bit on Windows, and isn't being updated..<BR>
<BR>
(Trying for "gentle advise" not "advocacy" here.)<BR>
<BR>
> > incremental cost of adding any given feature. One of M3's great <BR><BR>
I think the problem is more of multiplication than increment.<BR>
How do the features interact with each other?<BR>
Two features interact very very well -- destructors and exceptions.<BR>
And constructors in that mix.<BR>
Otherwise not certain.<BR>
<BR>
> C is a bit obsessive about source size, <BR>
<BR>
There used to be an assembler that used tabs and a competitor that used spaces.<BR>
The tab guy advertised his much smaller files. :) And I think therefore faster assembling.<BR>
Well, definitely much faster assembling either way, probably not because of or only because<BR>
of the tabs.<BR>
<BR>Yes I have that problem with procedures. And modules, and interfaces.<BR>
This is where my editor and braces excel. You need to sprinkle in the matching text.<BR>
You type control-brace on a brace and it shows you the matching one.<BR>
Some editors do this just by moving the cursor across a brace (or paren).<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Fri, 15 Feb 2008 09:18:19 -0500<BR>> From: hendrik@topoi.pooq.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] "target specific pragmas"?<BR>> <BR>> On Fri, Feb 15, 2008 at 10:47:01AM +1100, Darko wrote:<BR>> > I don't really question the usefulness of any given feature, just the <BR>> > incremental cost of adding any given feature. One of M3's great <BR>> > strengths is that it is low on features, but the ones it has are <BR>> > powerful and well chosen.<BR>> > <BR>> > The comparison I meant in the typing discussion was between C and M3, <BR>> > not the length of symbols. C is a bit obsessive about source size, <BR>> > which was meaningful back in the day, but today is totally irrelevant. <BR>> > Even if you don't use macros on your editor, the amount of time spent <BR>> > staring and your code is much greater than the time you spend typing <BR>> > it. You could argue that BEGIN/END is easier to read than {/}<BR>> <BR>> If I had to argue, I'd argue the reverse. In fact, if it weren't for <BR>> disputes about the number of spaces that are equivalent to a tab and <BR>> such, I'd argue for using indentation and dispensing with BEGIN/END/{/} <BR>> altogether.<BR>> <BR>> Somewhere I have a C++ program with all the braces left out. If you <BR>> manage to supply the right braces and get it compiled, you end up <BR>> with a program that will do the job of supplying the right braces.<BR>> I could post it here if anyone in interested in such a curiosity.<BR>> <BR>> There's one language I've seen that goes in the opposite direction. <BR>> Every END is followed by an arbitrary amount of text from the start of <BR>> the construct it closes and a semicolon. This a WHILE loop starting<BR>> WHILE toronto == montreal <BR>> could end with<BR>> END WHILE toronto ==;<BR>> making visual matchin unambiguous.<BR>> <BR>> I've got friends that complain about haveing to type the name if a <BR>> procerure twice in its declaration -- once at the start and once at the <BR>> end. They say they keep fprgetting to modify both. But I welcome this <BR>> as a useful check on long-range bracket matching. Forcing it for <BR>> short-range marching, though, is clutter.<BR>> <BR>> -- hendrik<BR><BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>