Related
I have to code in APL. Since the code is going to be maintained for a long time, I am wondering if there are some papers/books which contain heuristics/tips/samples to help in designing clean and readable APL programs.
It is a different experience than coding in other programming language. Making a function, for example. Small will not help: such a function can contain one line of code, which is completely incomprehensible.
First, welcome to the wonderful world of APL.
Writing readable and maintainable APL code is not much different than writing readable and maintainable code in any language. Any good book on writing clean code is as applicable to APL as any other language, perhaps even more so. I recommend Clean Code by Robert C. Martin.
Consider the guideline in this book that all code in a function should be at the same level of abstraction. This applies to APL 100 times over. For example, if you have a function named DoThisBigTask it should have very few APL primitive symbols in it, and certainly no long complex one-liners. It should just be series of calls to other, lower level functions. If these higher-level functions are all well-named and well-defined, the general drift should be easily determined by someone who does not even know APL. The lowest level functions will be nothing but primitives and will be inscrutable to the non-APLer. Depending on how they are written they may even initially appear inscrutable to a seasoned APLer. However, these low level functions should be short, have no side effects, and can easily be re-written rather than modified if the maintaining programmer is unable to understand the original coding technique.
In general, keep your functions short, well-named, well-defined, and to the point. And keep the lines of code even shorter. It is much more important to have well-defined and well-documented functions than it is to have well-written or well document lines of code.
Since you asked for books and other references, I can suggest:
APL2 in Depth by Norman D. Thomson and Raymond P. Polivka. I worked with Ray Polivka for years and he was one of the best APL teachers I
have ever known.
The classic A. P. L.: An Interactive Approach by
Leonard Gilman and Allen J. Rose is good for the core language, but
is rather outdated and doesn't contain much that is truly relevant on
readability.
APL 2 at a Glance by James A. Brown and Sandra Pakin serves in some ways as an update to Gilman and Rose. It covers nested operations and other updates to APL, but has not much specifically directed at readability. Still, if you follow the examples here you will be writing readable code.
APL is Easy by STSC and Jerry R. Turner is an intro directed specifically at the APL*Plus line. Again, not much specifically on readability, but the models are generally well-designed readable code.
Mastering Dyalog APL: A Complete Introduction to Dyalog APL by Bernard Legrand is quite good if you are specifically workign in Dyalog APL, not so much if you are working in one of the other versions such as APL*Plus (from APL2000)
It is my view that the reputation of APL as a "write-only language" is much overstated. One does need to get used to the primitives and the symbols used to represent them. But then one needs to get used to the syntax and the various library functions in many other language environments. I have seen convoluted code in C, C++, and Java as hard to follow as any APL. Of course, it isn't good C, C++, or Java, even if it is clever.
Some advice:
Writing 'one-liners' is a way to test one's mastery of the language,
but is very poor practice for production code.
Comment to make the algorithm and especially the data structure being used clear. As with any code, comments should add something
that cannot be easily read from the code itself, or call attention to
complex or obscure code.
If possible avoid obscure code so there is no need to explain it. It is usually possible.
Make each function do one and only one job, with a clear interface.
Avoid global variables for the most part, and document any that are needed.
Document the interface, purpose, and efect of any function at the
top. Make utilities black boxes without side-effects if possible. If
side-effects are essential, document those as part of the interface.
Develop a standard header comment structure.
Dynamic code built on-the-fly can add flexabiliy to a solution, but
is often much harder to debug if problems occur. Make such code
bullet-proof to the extent you can, and build in optional logging to
help when it turns out to have problems anyway.
You can use an OOP-like style if you wish. But there is no need to do so. If you do, it should IMO be used fairly pervasively through an application, except perhaps for low-level utilities. But OOP-style code can be at least as convoluted as non-OOP code, and APL doesn't have built-in inheritance or other OOP-supporting syntax.
(I'll use here "A" instead of comment, "'" instead of symbol sign.)
Well, I was developing APL for a year, I have only used Aplusdev.org.
You don't even need more. The trick is to try to think OOP-like. You should have -- if I remember well -- structured fields used as class data, sth like {'attribute1 'attribute2, {value,value2}}, so you can easily pick them out like obj.attribute1 in c++.
(here 'attribute Pick object, use only in class functions :) )
Moreover, use namespaced functions:
namespace_classname.method(this, arg1)
namespace_classname._private_method(this, arg1, arg2)
and lots of simple tool functions instead of nifty, long lines. The performance drop is not substantial, you can optimize later for say arrays once you see something could be faster.
And before anything: think matlab and mathematica without for loops! :) It helps a lot.
My suggestions for robust, maintainable code:
use extensive set of utility functions instead of trickery with those unreadable symbols to make your code always to the point.
try-catch blocks there is a built in exception handling, which can be utilized here,
try_begin();
A tried code, maybe in extra brackets not to forget try_end() at the end.
try_end();
catch(sth, function_here);
can be nicely implemented. (You'll see, catching errors is very important)
crude type checking : implement a standard and use for not-so-many times called functions... (you can put a function with flexible parameters right after a function definition)
Syntax:
function(point2i, ch):
{
typecheck({{'int, [1 2]}, 'char}); A do some assertions in typecheck...
// your function goes here
}
lambda functions can be very effective, you can do some reflections to achieve lambdas.
always declare returns with saying "return"!
Unit tests based on try-catch testing each and every function you write.
I also used a lot of 'apply' and 'map' from mathematica, implementing my own version, they are very-very effective here.
I wrote matlab thinking since you can here have a list of structured fields (=class data) in a variable. You will write lots of those if you wanna keep things for-loop-less (and you wanna, trust me). For that you need to have a standard naming convention say indicate with plurals:
namespace_class.method(objects, arg1, arg2)
To the end: also, I wrote inputBox and messageBox like the ones in Javascript or VisualBasic, they will make very easy hacking together simple tools or checking states. The only catch of messageBox, that it can't put the function-flow on hold,
so you need
AA documentation of f1
f1():
{
A do sth
msgbox.call("Hi there",{'Ok, {'f2}});
}
f2():
{
A continue doing stuff
}
You can write auto-docs in bash with a gawk/sed combination to put it into a webpage.
Also creating HTML formatted code helps in printing. ;)
I hope this was good outline for a proper build-up. Before writing own tools, try to dig up the available tools from the legacy codebase... functions are often even 4 times implemented with different names due to the mess that time.
I recently saw a programming language called supernova and they said in the web page :
The Supernova Programming language is
a modern scripting language and the
First one presents the concept of
programming with direct Fiction
Description using
Clear subset of pure Human Language.
and you can write code like:
i want window and the window title is Hello World.
i want button and button caption is Close.
and button name is btn1.
btn1 mouse click. instructions are
you close window
end of instructions
my question is not about the language itself but it is that are we need such languages and did they make writing code easier or not?
The code may look like natural language, but it's really just regular computer code with different keywords. In your example, I want is probably synonymous with new. It's not like you can use natural language directly and say make me a window instead (and if you could, things would get even uglier...).
Lets take a close look at your code and the language implications:
i want window and the window title is Hello World.
i want means new, and denotes beginning of the argument list. the <type_name> <member_name> is sets instance variable member_name on the object being created. Note that you have to write the type_name twice.
i want button and button caption is Close.
and button name is btn1.
. ends a statement. However, you can 'chain' method calls on an object by starting the next statement with and. Also, how do you refer to a variable named Close instead of the string "Close"? Heck, we even have this problem in regular English: what the difference between 'Say your name' and 'Say "your name"'?
btn1 mouse click. instructions are
you close window
end of instructions
mouse click is an identifier containing a space, should be mouseClick. instructions are defines a lambda (see the is vs. are keyword confusion causing trouble yet?). you close window calls window.close(). end of instructions is end of a lambda. All of these are longer than they need to be.
Remember all that? And those are only my guesses at the syntax, which could be completely wrong. Still seem simple? If so, try writing a larger program without breaking any of those rules, AND the additional rules you'll need to define things like conditional logic, loops, classes, generics, inheritance, or whatever else you'll need. All you're doing is changing the symbols in regular programming languages to 'natural language' equivalents that are harder to remember, unnecessarily verbose, and more ambiguous.
Try this translation:
var myWindow = new Window( title="Hello World" );
myWindow.addButton( new Button( caption="Close", name="btn1" ) );
btn1.onMouseClick = function() {
myWindow.close();
}
See how each line maps to its counterpart in the previous example, but states the intent more directly? Natural language may be good for execution by humans, but it is terribly difficult to use for precise specifications.
The more you try to make English communicate these ideas easily and clearly, the more it's going to look like programming languages we already have. In short, programming languages are as close to natural language as we can get without losing clarity and simplicity. :D
Since the fundamental difficulty of programming is getting your thoughts ordered enough to tell the computer what to do, making the language more “natural” is highly unlikely to make it more accessible to non-programmers; the language itself was never the real problem in the first place. What's more, all that extra clutter of natural language doesn't help any programmers (worth the name) with what they're doing either, so why add it?
Or can we have a real natural language programming language, complete with “Um”, “Er”, and “Oh, I don't really know”? :-)
Edsger W. Dijkstra, On the foolishness of "natural language programming". I have nothing to add.
The programming language you have showed us above is extremely verbose (as it seems even more than COBOL).
This comes with several problems:
It takes long code to do simple things.
Code grows unmaintainable fairly fast
It takes long to find out what code does
Whether they're better or not is opinion, but that looks like some mutated cross of COBOL and BASIC, which is most definitely epically bad.
So in my opinion, no. I think somewhat to-the-point languages that still use readable verbs/adjectives/names are better (C++, C#, PHP, etc are my preferred languages).
Some languages start to get too high-level and/or verbose, making the actual logic so abstracted it's hard to know what does what. Some are too low-level and brief, forcing you to explicitly state everything you want done. A balance between readability and brevity, with power and flexibility, is what is best for development.
I'll be brave and offer a slightly different opinion here.
I haven't seen anything of this language other than what has been presented in the question, but looking at that I'd have to say it probably is much more readable for a non-programmer. For a programmer on the other hand it won't hurt readability, but it won't help either because we're used to reading code.
On the actual development side of things, I think it would be horrible to have to type so many extra bits especially if you're used to succinct keywords and constructions like us programmers.
But let's imagine a far away future where speech recognition is actually accurate. I think a language like this would be far easier to code by talking to your computer, I'd hate to have to specify every parenthesis and such. Not having to do that would help keep your train of thought.
In conclusion:
non-programmer readability: great.
programmer readability: no improvement.
codability typing: no, just...no.
codability speech: probably much easier.
person.eBusiness[text.this.author].like(language.supernova.idea.reverse);
language.English[ambiguous[very]];
person.eBusiness.suggest(create(language.Codetalk));
language.Codetalk.grammar.inspiration=language.programming.grammar;
language.Codetalk[new,better,ambiguous[not]];
if(person.all.use(language.Codetalk)){
person.all.understand(person.all.communication);
};
question(language.Codetalk.idea[good]);
In my opinion there is no really useful advantage in using that kind of "human language", because you still need a syntax and special words. You have to learn both of them, and because that's necessary it would be not much more difficult to learn a "programming language", which gives lots of advantages because it is oriented at the machine's structure and not at the human's way of thinking.
You will need to think the way the machine works if you want to write good programs, and a programming language is definitely more powerful to express that way of thinking than human language.
One problem with these languages is: Say you write significant portions of your app in this language and then need different people to maintain,extend or otherwise change the code.
Who are you going to get to do this ? Nobody off the street is going to know it and others are going to have a steep learning curve.
Let's also assume you have a question on how to accomplish a task the language, where do you turn ?
Well the perfect programming language would be an exact copy of the English Language. You could just tell your computer to do some stuff in the same way you might order a coffee or give homework to your class. However, such a language would be extremely difficult to implement (an advanced A.I would be necessary).
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
It is interesting that some languages do not use semicolons and braces, even though their predecessors had them. Personally, it makes me nervous to write code in Python because of this. Semicolons are also missing from Google's GO language, although the lexer uses a rule to insert semicolons automatically as it scans.
Why do some languages not use semicolons and braces?
Every programming language must have some way of distinguishing the end of a statement, function call parameter lists or a block of code from the next one.
Some languages use ; and {} (C, Java)
Some languages rely on known sizes of parameter lists (x86 assembly code)
Some use parentheses to form s-expression (Lisp, Clojure)
Some use whitespace (Python)
Some use special keywords like begin .... end (Pascal, Delphi)
So basically this is mostly just a language design choice. There is always some equivalent of ; or {}, even if it doesn't look the same at first glance...
You can argue that when you use semicolons and braces, you still indent your code with whitespace and new lines - for readability reasons. Therefore those delimiters can be considered redundant in this sense.
The designers for those languages presumably believe that the braces and semi-colons are needless cruft, when line continuations can (usually) be detected due to a statement not being complete, and blocks can be detected by whitespace.
Personally it makes me nervous too, but then the lack of checked exceptions in C# had the same effect on me for a while... I suspect that when you get used to such a scheme, it can improve readability (which is the point). It does mean you need to be more careful with whitespace, of course.
We have been using indentation to indicate statement groupings as a readability aid for a long time. This occasionally causes problems when the indentation and the actual statement groupings (indicated by {};, begin/end, whatever) are in conflict; we read one meaning, but the code actually says something else.
Python took the simplifying approach. If we find indentation a help in clarity of expression, why not make it the way the language itself determines groupings. When we write code, we express intent to other readers, so looking at what writing gurus say is often useful:
A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. ~William Strunk, Jr., The Elements of Style, 1918
So, maybe a programming language should have no unnecessary syntax elements...??
Two reasons: There are so many different ways to put braces around code blocks (see indent styles) that reading/parsing code written by others can be quite hard. Python code, on the other hand, always looks similar, and the indentation level gives a very clear visual clue for the structure of the code. As a side effect, it forces you to keep your code structure simple since deep nesting makes your code vanish off the right side of the screen :)
As for the semicolons - I've been bitten often enough by for(i=0;i<=100;i++); errors that I'm glad I'm not falling into the same traps in Python...
"Syntactic sugar causes cancer of the
semicolon."
Alan Perlis
Is there any reason why some languages do not use semicolons and braces?
Some designers believe that "syntactic noise" such as semicolons and braces distract the reader from the code. There are various ways to eliminate them:
Python and Haskell use significant indentation.
Clu and Lua use very carefully engineered grammars.
Standard ML uses keywords to introduce each construct plus let-bindings, which eliminate the need for most semicolons while also providing a handy way to declare local variables.
The Bourne shells use significant newlines to eliminate semicolons
Scheme uses an extremely regular syntax which in which the only syntactic markers are parentheses. Longtime Schemers like Olin Shivers claim that after a few weeks, your brain adjusts and you no longer see the parentheses.
The fact that there are so many designs, with so much variation, suggest that many language designers view semicolons and braces as syntactic noise to be eliminated if possible. By eliminating syntactic noise, designers make programs easier to read and understand all at once. and many programmers feel more productive, as if the signal-to-noise ratio has improved and they are channeling their code more clearly. (I won't say they're right and I won't say they're wrong, but I will say that has language-design decisions go, this one is pretty easy to defend.)
So is there a reason why language designers do use semicolons and braces?
Many of the modern semi-colon-and-brace languages are designed explicitly, or in some cases not so explicitly, to appeal to C programmers. After all, if it has semicolons and braces, it must be easy to learn. Right?
Using delimiters like semicolons and braces, or not, is just a matter of taste. In practical terms, compilers can work without them, so, why use them in modern programming languages? As I said, is a matter of taste, and... a long-time established de-facto syntax that ressembles C. It is difficult to fight against that.
There is one field in which braces and semicolons are useful: code generation. When you generate code that is expected to be compiled/interpreted in a kind of reflective behaviour, it is normally more comfortable to write braces (in, say, just one, single line) than to write the structure needed by a programming language such as Python, for example. Think of a function with a couple of unnested loops. You would have to keep track of the number of tabs needed at each line.
Is there any reason they should use them?
Some people think that semicolons and curly braces are not exactly human-readable text. I personally favor the Pascal-style begin end blocks, it seems more natural and easier to understand in terms of sheer meaning, even for a non-initiate in programming languages: "See, is says begin, then some stuff, then end, so it must be something that begins here and ends over there, some sort of block, huh...". Nevertheless, semicolons and brackets are usually easier to parse, so that's why it's easier to use them instead of indentation or other constructs; designers that consider the language easier to understand without them, but easier to parse with them, apply tricks like the one you mentioned: the lexer uses a rule to insert semicolons automatically as it scans.
Semicolons and {} have semantic meanings (variable lifetime, mostly) as well as just syntax. In C++ I've written code that looked like
{
lua_table tab;
{
lua_string str;
}
}
They were of great use because using the Lua stack from C++ sucks terribly.
For some people, semicolons and braces look like noise that makes difficult reading the 'actual' code.
As you can have parsers to recognize blocks either based on punctuations or in indentation (no technical issue involved) the use of one or the other alternative is just a question of the programmer preference.
My impression is that this preference could be mainly due to the previous programmer background.
I really don't understand why you ask. You hate writing Python code? Well, don't! Nobody has canceled C/C++/etc.
I need to document the software I'm currently working on. The software consists of several programming languages and scripts which got me thinking. If a new developers comes along and needs to fix something, they might know Java but maybe not bash scripting. It would be nice if there was a program which would help to understand what
for f in "$#" ; do
means. I was thinking of something that creates a static HTML page with the code plus syntax highlighting and if you hover over something (like the "for"), it would display a pop-up with an explanation:
for starts a loop which iterates over all values that follow in. In the loop, you can access each value via the variable $f. The loop body is between do and done
Does something like that already exist?
[EDIT] This is just an example. You'll get another help for f, in, "$#", ; and do, i.e. each and every element of the line should be explained. Unknown elements (like command names) should link to Google. So you can understand what it does even if you're missing some detail.
[EDIT2] I'm aware that you can't write a program which understands what another program does. What I'm looking for is a simple tool which will do "extended syntax highlighting" in the sense that it will color an expression and give a short explanation what it means (plus maybe a link to some in-depth reference).
This is meant for someone who knows how to program but maybe hasn't seen some obscure construct before. Say
echo "Error" 1>&2
Every bash programmer knows what this means but a Java developer might be puzzled by the 1>&2 despite the fact that they can guess that echo == System.out.println. A simple "Redirects stdout to stderr" will clear things up and give that instant "AHA!" which allows them to stay in their current train of thought.
A tool like this could be built using ANTLR, i.e. parse the code into an abstract syntax tree using an ANTLR grammar for that language, and write an HTML generator which produced the annotated code.
It sounds like a useful tool to have for language learning, or exploring source code of projects you're not maintaining -- but is it appropriate for documentation?
Why is it important to help the programmers of other languages understand the code at this level of implementation detail? Anyone maintaining the implementation at this level will obviously have to know the language and will probably have an IDE to do most of this.
That said, I'd definitely consider a tool like this as a learning aid.
IMO it would be simpler and more effective to just collect links to good language-specific references and tutorials on a Wiki page.
For all mainstream languages, such sources exist and are maintained regularly. If you try to create your own reference, you need to maintain it too. Fair enough, bash syntax is not going to change very often, but other languages do develop faster, so it is going to be a burden.
If you think about it, it's not that useful to have a tool that explains the syntax. Developers could just google for keywords instead of browsing a website in a similar fashion to http://www.codeweblog.com/source/ .
I believe that good comments will be by far more useful, plus there are tools to extract the documentation by using the comments (for example, HappyDoc does that for Python).
It is a very tricky thing. First of all by definition it can be proven that program that will "understand" any program down't exist. However, you can still use existing documentation. Maybe using tools like Doxygen can help you. You would need to document your code through comments and the documentation will be generated from them.
A language cannot be explained only through its syntax. The runtime environment plays a great part, together with the underlying philosophy of the language and libraies.
Moreover, syntax is not that complex for most common languages (given that code has been written with maintainability in mind).
Going on with bash example, you cannot deeply understand bash if you know nothing about processes & job control, environment variables, a big list of unix commands (tr, sort, cut, paste, sed, awk, find, ...) and many other features that don't appear in syntax.
If the tool produced
for starts a loop which iterates over
all values that follow in. In the
loop, you can access each value via
the variable $f. The loop body is
between do and done
it would be pretty worthless. This is exactly the kind of comment that trainee (human) programmers are told nver to write.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
C++ is my first language, and as such I'm used to whitespace being ignored. However, I've been toying around with Python, and I don't find it too hard to get used to the whitespace rules. It seems, however, that a lot of programmers on the Internet can't get past the whitespace rules. From what I've seen, peoples' C++ programs tend to be formatted very consistently with respect to whitespace (or else it's pretty hard to read), so why do some people have such a problem with whitespace-based languages like Python?
It violates the Principle of Least Astonishment, because we have it ingrained in ourselves (whether for good or bad) that whitespace Does Not Matter in a programming language. Whitespace is one of those issues that has been left up to personal style.
I still have bad memories back from being a student of learning the hard way that 8 spaces is not equivalent to a tab in a Makefile... Ah, the sleep I lost...
The only valid reason I have come across is that refactoring using cut-and-paste (not copy) without refactoring tools (or syntax-aware cut-andpaste), can end up changing semantics if an easy mistake is made.
There are several different types of whitespace (spaces, tabs, weird unicode characters, carriage returns, line breaks, etc.), they aren't necessarily visually distinct, and languages and editors may treat them capriciously. This isn't an argument against well-designed whitespace semantics, but many people are against all forms of it simply because of the possibility of poor design.
People hate it because it violates common sense. Not a single one of the replies I have read here decided that it was ok to simply forgo periods and other punctuations. In fact the grammar has been very good. If the nonsense about indentation actually carrying the meaning were true we would all just forget about using punctuations entirely.
No one learned that newlines terminate a sentence in a horizontal language like English, instead we learned to infer when a sentence ended regardless of whether or not the punctuation was present or not.
The same is true for programming languages, especially for those of us who started out with a programming language that did use explicit block termination. You learn to infer where a block starts and stops over time, it does not mean that the spacing did that for you, the semantics of the language itself did.
Most literate people would have no problem understanding posts without punctuations. Having to rely on what is a representation of the absence of a character is not a good idea. Do any of you count from zero when you make your to-do list?
Alright, this is a very narrow perspective, but I haven't seen it mentioned elsewhere: keeping track of white space is a hassle if you are trying to autogenerate a script.
When I first encountered Python, I don't remember the details, but I had developed a Windows tool with a GUI that allowed novice users to configure several settings, and then press OK. The output of the tool was a script, which the user could copy to a Unix machine, and then execute it there to do something or other that was too complicated or tedious for them to do manually. Since nobody maintained the generated scripts, there was no reason they needed to look nice. So, keeping track of indentation seemed like an unnecessary burden from that perspective.
For most purposes, though, I find that Python is much easier than any other language.
Perhaps your C++ background (and thus who your peers are) is clouding your perception of this (ie selective sampling) but in my experience the reaction to Python's "white space is intent" meme is anywhere from ambivalent to they absolutely love it. The reason a lot of people love it is that it forces people to format their code.
I can't say I've ever met anyone who "hates" it because hating it is much like hating the idea of well-formatted code.
Edit: let me put this in some perspective.
In the Java world there are two main methods of packaging and deploying Web apps: Ant and Maven.
Ant is basically an XML-based Make facility that has tasks for the common things you do. It's a blank slate, which is powerful, but it also means you have to write a lot of common things yourself and every installation is free to do things slightly differently. All of this is well-intentioned but can make it hard to figure out someone's Ant scripts.
Maven is far more fully features. It has archetypes, which are basically project types. Depending on which archetype(s) you use, you won't have to write any tasks to start, stop, clean, build, etc but you will have a mandated directory structure, which is quite deep.
The advantage of that is if you've seen one Maven Web app you've seen them all. You know the commands. You know the structure. That's extremely useful.
But you have people who absolutely hate Maven and I think it comes down to this: they don't like giving up control, even when it's ultimately in their interest to do so. Also, you'll find a certain brand of person who thinks that their use case is a justifiable exception. You see this personality trait a lot. For example, I think an old Joel post mentioned a story where someone wanted to use "enter" to go from the username to password form fields even though the convention was that enter executed the default action (usually "OK") so they had to write a custom dialog class for Windows for this.
Basically some people just don't like being told what to do and others are completely obstinate in their belief that they're right even when all evidence points to the contrary.
This probably explains why some supposedly hate Python's white space: they don't like being told how to format their code. They like the freedom of C/C++.
Because change is scary. And maybe, among certain developers, there are some faint memories of languages with capricious rules about whitespacing that were hard to remember and arbitrary, meant more for compiler convenience than expressiveness.
Most likely, not giving whitespace-significance a fair shake before dismissing it is the real reason. Ask someone to fix a bug in a reasonably complex but well-written Python program, then ask them to go fix a bug in a 20 year old system in C, VB or Cobol and ask them which they prefer.
As for me, I have as much trouble with whitespace in Python or Boo as I have with parentheses in Lisp. Which is to say, none.
They will have to get used to it. Initially I had a problem my self trying to read some examples but after using language for some time I started liking it.
I believe it is a habit that people has to overcome.
Some have developed habits (for example: deeply nested loops, unnecessarily large functions) that they perceive would be hard to support in a whitespace sensitive language.
Some have developed an aesthetic dislike for hanging indents.
Because they are used to languages like C and JavaScript where they can align items as they please.
When it comes to Python, you have to indent code based on its context:
def Print():
ManyArgumentFunction(LongParam1,LongParam2,LongParam3,LongParam4...
In C, you could do:
void Print()
{
ManyArgumentFunction(LongParam1,
LongParam2,
LongParam3,...
}
The only complaints I (also of C++ background) have heard about Python are from people who don't like using the "Replace Tabs with Space" option in their IDE.