but can I upgrade software without hours of searching for missing libraries? Huh?
This is so much more powerful in GNU/Linux distributions now than it is in Windows.
Debian, for instance, has apt, which is far more powerful than any Windows installation software.
Upgrade is a snap, and unlike in Windows, a central piece of software upgrades the thousands of software packages you have. You don't have to click the custom-made (closed-source inefficiently recreating the same update-code in every piece of software, that is) "Update" in each piece of software.
The drivers run unmodified in the host OS. They receive their IRQ's through interrupt forwarding, and the Linux kernel itself is modified to not access I/O directly but via host-API's.
Ghandi fought illegitemate law, by not cooperating with it.
Doing the right thing, and suffering the consequences.
It could be interesting if the entire world violated software patents just like its violating copyrights - but also willingly suffer the consequences/punishment. According to Ghandi this is the most effective way to fight the illegitmacy. By willing to suffer the consequences, you are effectively making your opponent's sword worthless.
Compare it to Java and it is pretty much the same.
Compare it to Python and its way behind.
The only reason the people I know use it is for all the RAD development wizards, not because C# is a good language. This too, I presume, because they have not tried using the Qt designer and pyqt.
The notion that "putting restrictions in software is inappropriate" is in itself a restriction, and thus invalidates itself.
It is a restriction, but not a restriction in software and thus it does not invalidate itself. What are you talking about?
Restrictions on what people can code in software they distribute is fine (are not allowed to distribute viruses, for example). Putting user-restrictions in the software itself (different from restricting the authors of the software) is not legitimate.
I am a software author myself, and I am against user-restrictions, and for some sorts of restrictions on what authors should be able to do with their software. If it was up to me, distribution of software would only be legal with the source included, and the freedom to modify and redistribute it. In such a case, user-restrictions in the software become a non-issue.
You haven't mixed, say, Vi and Emacs, the two most common editors out there, have you? Depending on the editor settings, Emacs will use spaces, and Vi will always use Tabs. Hell, I haven't done *that* much Python development (relative to other languages I know), and even I have encountered the broken-tabs problem.
Valid point. When I mix editors, I usually explicitly do search-replace on tabs/spaces to unify them all to the same form. I have been burnt once or twice on tabs problems (well, if wasting 5-10 minutes finding a spacing problem once or twice is a burn:), so I'm concious to it.
However, there remains the problem that code can be incorrect, but not necessarily *appear* incorrect (to the developer), since there's no visual markers (other than whitespace) to indicate where the blocks *should* have been. Therefore, if something does get out of place for some reason (and yes, I've had this happen), it isn't always immediately obvious that something's amiss.
I think you got that backwards. In languages where indentation is ignored by the compiler, there is a problem. Indentation is for the human readers, while the braces are for the compiler. A human reader is more likely to ignore the braces for the indentation than vice versa. Thus, in C, a human reader might think that an indented code is within some block where in fact it is not:
if(x) {
for(i = 0; i < 10; ++i)
printf("Blah %d\n", i);
x += 10; }
The above is confusing, while: if x:
for i in xrange(10):
print "Blah", i
x += 10
does exactly what the reader would expect.
So, that's one example where the C code appears correct but is actually incorrect. Can you show any example of Python code that appears correct but isn't? The whole point of significant indentation is that the human reader and the compiler are reading the same information, and thus code appearance is exactly what will execute.
The problems with significant whitespace has nothing to do with the benefits of code formatting. Everyone knows that proper block indentation improves readability. However, whitespace significance is *incredibly* annoying if things like tabs break (if you've ever edited a Makefile with a naive editor, you'll know *exactly* what I'm talking about, here).
There's a fundumental difference between Python's whitespace significance and that of Makefiles. Makefiles dictate where to use tabs, and where to use spaces. Good Python style merely dictates that whatever you use, you use it consistently. Simply don't mix tabs and spaces for indentation. Even naive editors don't have a problem with this.
if (condition):
blah
if (condition2): # wrong lexical level!
blah
When indentation is the lexical level information, obviously you have to adjust it while you write the code. Your assertion that the editor does not indent the code automatically as in other languages is quite silly, because in other languages it knows to indent your code because of the extra information that you type (braces/etc).
Consequently, I'm forced to backspace in order to get things to come out correctly.
As opposed to being forced to press '}' in order to get things to come out correctly with most other languages?
Plus if I try to auto-indent this code, it's quite possible that it could get it wrong, because there's no way to unabiguously determine the intended scope of the statements in a block.
Again, you are trying to apply the concept of auto-indentation, which only makes sense where indentation is redundant information to the braces. Where the indentation is the information, there is no reason to auto-indent because indenting is done instead of, and at a lower cost than typing the curly braces.
Once you stop trying to auto-indent a language where indentation is the one and only specificier of the nesting level, you see that it is quite trivial to unambiguously determine the intended level under which statements go.
Replace 'Replace "software" with "networks" or "servers" or "actions" or "use of my personal info" and I think you'll see the fallacy of your statements.' with 'This is a fallacy' and I think you will see the fallacy of your statements.
Seriously though, networks/servers are different from software. A server/network is a physical entity that belongs to someone who can restrict it as he may. Software is information which can be copied virtually infinitely. Restricting the software is restricting a virtually infinite amount of copies that belong to multiple different entities.
C will typically convert between incompatible values (pointers and ints, for instance) without an explicit typecast, with certain warnings raised.
In some cases, incompatible type conversions (mostly between pointers to different types) don't even yield warnings:
char c; void *a; int *b;
a = &c; b = a;/* To emphasize that this is wrong: */
(*b) = 0;/* Undefined behaviour */
Hell, the mere fact one can incorrectly cast in C makes it weakly typed. In a strongly typed language, the wrong type may never be applied to wrongly interpret memory bits. This is not true of C, and true of Python. C is weakly typed, Python is strongly typed.
"Hello" + 3 will raise an exception in Python, but yield 3 (or "3") in Perl, along with the fact that:
"3" and 3 are indistinguishable in Perl (Might be wrong about this, but for common operations at least, they are indistinguishable), make Python superior (at least in this specific regard).
They perhaps know how to use a certain subset of Python, but it is quite untrue that there is not much to learn in Python.
Unless the language they know includes:
Lexical scoping
Dynamic typing
The same reference semantics
Notion of Immutability
Generators
List comprehensions
They really have a lot to learn still:)
Sure, most of these are well-designed and simple features that don't take more than a few minutes to learn. To learn the whole Python syntax and its basic semantics really shouldn't take more than a week or two.
However, to "know the language" is to know when to use those features and in my experience it takes almost a year to learn that. (You should still be able to create working programs before that though:)
But immediately the "object model" if you want to call it that got on my nerves. Why "len(list)" and not "list.len()"? Why "'\n'.join(array)" instead of "array.join('\n')"? What's with the simplistic scoping? Why all the underscores? Why "self" everywhere, and why is it so unpythonic to just call it "s" instead? Do I really have to type parantheses all the time? Where are the first-class regexps? Does it make sense that for many built-ins, "foo(obj)" calls "obj.__bar__", why not just use "obj._foo()" directly and eliminate "foo()" from the language.
Lets call this the foo indirection. The foo indirection is useful because it releases the tight coupling between the foo(obj) call, and the obj.__bar__() call. For example, the int(object) call is implemented by usually calling object.__int__(), but this is not necessarily so. int is a type whose constructor converts objects to an integer using __int__ or other protocols/methods. For example, int(some_string, 16) will convert the string to an integer treating it as an ascii representation of a hexadecimal number. The string does not necessarily have __int__ and/or does not necessarily support the same arguments as int.
The foo indirection also allows for later modifications of things like the len() function without modifying the __len__ method protocol. The foo indirection is exactly the same as the indirection you get when using object[subscript], where that subscript may be an index or a slice. It used to call __getitem__ or __getslice__, which is a messy protocol. Because of this indirection, the messy protocol was now cleaned to __getitem__ which may take an integer index or a slice object index, while still supporting __getslice__.
I guess I'm one of those weenies that believes all languages eventually become Lisp or Smalltalk, and any sharp corners that vary from those models will eventually be "filed off". I tried Ruby and discovered it was much more like Smalltalk. Very elegant and easy to write code.
Python does not try to be Smalltalk, however it is indeed very similar to Lisp in many ways. However, there is a fundumental difference in the philosophies of Lisp and Python. Lisp tries to be the "language of languages", where macros let you variate the language to your specific needs. Python tries to be the "uniform language", where macros would never get in the language because they harm uniformity.
Unfortunately Python stole the thunder and now python has the great docs and 3rd-party libraries, while Ruby lingers and grows slowly.
Fortunatly, if you ask me:)
And Python has the arrogant, Perl-like community now, that thinks jamming list comprehensions and generators into everything makes you "cool".
I simply find comprehensions more readable than.append() loops in most cases. I also love generators and find they are amazing ways to write extremely simple code that yields generic iterators. (Extremely useful for the implementation of __iter*__ methods).
Why do they think it's so cool to reduce the number of lines in a program? I own the "Python cookbook" and find it highly irritating. Rather than solving problems in a single elegant and general way, it presents each author's particular 'leet Python skills, and usually 4-5 different solutions (in a language that claims "one way to do it").
The number of lines is often a good (perhaps rough) indicator of the number of bugs in the code. Code that's not written does not have bugs. I find the "advanced" generator-using solutions very elegant and general. Python does not claim there is "one way to do it". Python claims "there should be one obvious way to do it, preferrably only one". There can be more than one obvious way, and there always is more than one way (just not obvious).
I found it very unhelpful, and again was confused when people said it was such a great book.
Slashdot Mirror
They are one, technically. Except for the GUI "mode" in which they are initiated.
Type a webaddress in an explorer window and see what happens.
but can I upgrade software without hours of searching for missing libraries?
Huh?
This is so much more powerful in GNU/Linux distributions now than it is in Windows.
Debian, for instance, has apt, which is far more powerful than any Windows installation software.
Upgrade is a snap, and unlike in Windows, a central piece of software upgrades the thousands of software packages you have. You don't have to click the custom-made (closed-source inefficiently recreating the same update-code in every piece of software, that is) "Update" in each piece of software.
The drivers run unmodified in the host OS.
They receive their IRQ's through interrupt forwarding, and the Linux kernel itself is modified to not access I/O directly but via host-API's.
My comment about it being nice that you have your morals above enriching yourself was not sarcrastic...
Ghandi fought illegitemate law, by not cooperating with it.
Doing the right thing, and suffering the consequences.
It could be interesting if the entire world violated software patents just like its violating copyrights - but also willingly suffer the consequences/punishment. According to Ghandi this is the most effective way to fight the illegitmacy. By willing to suffer the consequences, you are effectively making your opponent's sword worthless.
Maybe that's the reason its "small"? :)
I do think its great you refuse to use closed/patented formats. Nice to have morals above enriching yourself.
Huh?
In terms of development speed:
Compare it to Java and it is pretty much the same.
Compare it to Python and its way behind.
The only reason the people I know use it is for all the RAD development wizards, not because C# is a good language. This too, I presume, because they have not tried using the Qt designer and pyqt.
14 years + Optional 14 year extension
The notion that "putting restrictions in software is inappropriate" is in itself a restriction, and thus invalidates itself.
It is a restriction, but not a restriction in software and thus it does not invalidate itself. What are you talking about?
Restrictions on what people can code in software they distribute is fine (are not allowed to distribute viruses, for example). Putting user-restrictions in the software itself (different from restricting the authors of the software) is not legitimate.
I am a software author myself, and I am against user-restrictions, and for some sorts of restrictions on what authors should be able to do with their software. If it was up to me, distribution of software would only be legal with the source included, and the freedom to modify and redistribute it. In such a case, user-restrictions in the software become a non-issue.
You haven't mixed, say, Vi and Emacs, the two most common editors out there, have you? Depending on the editor settings, Emacs will use spaces, and Vi will always use Tabs. Hell, I haven't done *that* much Python development (relative to other languages I know), and even I have encountered the broken-tabs problem.
:), so I'm concious to it.
Valid point. When I mix editors, I usually explicitly do search-replace on tabs/spaces to unify them all to the same form. I have been burnt once or twice on tabs problems (well, if wasting 5-10 minutes finding a spacing problem once or twice is a burn
However, there remains the problem that code can be incorrect, but not necessarily *appear* incorrect (to the developer), since there's no visual markers (other than whitespace) to indicate where the blocks *should* have been. Therefore, if something does get out of place for some reason (and yes, I've had this happen), it isn't always immediately obvious that something's amiss.
I think you got that backwards.
In languages where indentation is ignored by the compiler, there is a problem. Indentation is for the human readers, while the braces are for the compiler. A human reader is more likely to ignore the braces for the indentation than vice versa. Thus, in C, a human reader might think that an indented code is within some block where in fact it is not:
if(x) {
for(i = 0; i < 10; ++i)
printf("Blah %d\n", i);
x += 10;
}
The above is confusing, while:
if x:
for i in xrange(10):
print "Blah", i
x += 10
does exactly what the reader would expect.
So, that's one example where the C code appears correct but is actually incorrect. Can you show any example of Python code that appears correct but isn't? The whole point of significant indentation is that the human reader and the compiler are reading the same information, and thus code appearance is exactly what will execute.
The problems with significant whitespace has nothing to do with the benefits of code formatting. Everyone knows that proper block indentation improves readability. However, whitespace significance is *incredibly* annoying if things like tabs break (if you've ever edited a Makefile with a naive editor, you'll know *exactly* what I'm talking about, here).
There's a fundumental difference between Python's whitespace significance and that of Makefiles. Makefiles dictate where to use tabs, and where to use spaces. Good Python style merely dictates that whatever you use, you use it consistently. Simply don't mix tabs and spaces for indentation. Even naive editors don't have a problem with this.
if (condition):
blah
if (condition2): # wrong lexical level!
blah
When indentation is the lexical level information, obviously you have to adjust it while you write the code. Your assertion that the editor does not indent the code automatically as in other languages is quite silly, because in other languages it knows to indent your code because of the extra information that you type (braces/etc).
Consequently, I'm forced to backspace in order to get things to come out correctly.
As opposed to being forced to press '}' in order to get things to come out correctly with most other languages?
Plus if I try to auto-indent this code, it's quite possible that it could get it wrong, because there's no way to unabiguously determine the intended scope of the statements in a block.
Again, you are trying to apply the concept of auto-indentation, which only makes sense where indentation is redundant information to the braces. Where the indentation is the information, there is no reason to auto-indent because indenting is done instead of, and at a lower cost than typing the curly braces.
Once you stop trying to auto-indent a language where indentation is the one and only specificier of the nesting level, you see that it is quite trivial to unambiguously determine the intended level under which statements go.
You get a warning/error (use python -t, ofcourse).
Or if you forget -t, you get an IndentationError or a SyntaxError which is quickly narrowed down to the indentation problem.
You misunderstood.
He was referring to the costs of the receiever, not the fax spammer.
What do you expect from "Hello world 3" + "3"?
I certainly wouldn't expect 0, 3, or 6. I would expect it to either fail, or return "Hello world 33".
Obviously, a language with simple predictable semantics is superior to one with ad-hoc weird semantics.
There are false positives
There are false negatives
Software restriction cannot really work on Free Software, which requires a lot heavier freedom-killing to operate.
Replace 'Replace "software" with "networks" or "servers" or "actions" or "use of my personal info" and I think you'll see the fallacy of your statements.' with 'This is a fallacy' and I think you will see the fallacy of your statements.
Seriously though, networks/servers are different from software. A server/network is a physical entity that belongs to someone who can restrict it as he may. Software is information which can be copied virtually infinitely. Restricting the software is restricting a virtually infinite amount of copies that belong to multiple different entities.
Do you mean to say that you don't indent your code? :)
I tend to believe you ran away screaming before you tried using significant whitespace.
C will typically convert between incompatible values (pointers and ints, for instance) without an explicit typecast, with certain warnings raised.
/* To emphasize that this is wrong: */
/* Undefined behaviour */
In some cases, incompatible type conversions (mostly between pointers to different types) don't even yield warnings:
char c;
void *a;
int *b;
a = &c;
b = a;
(*b) = 0;
Hell, the mere fact one can incorrectly cast in C makes it weakly typed.
In a strongly typed language, the wrong type may never be applied to wrongly interpret memory bits. This is not true of C, and true of Python. C is weakly typed, Python is strongly typed.
"Hello" + 3 will raise an exception in Python, but yield 3 (or "3") in Perl, along with the fact that:
"3" and 3 are indistinguishable in Perl (Might be wrong about this, but for common operations at least, they are indistinguishable),
make Python superior (at least in this specific regard).
Unless the language they know includes:
Lexical scoping
Dynamic typing
The same reference semantics
Notion of Immutability
Generators
List comprehensions
:)
:)
They really have a lot to learn still
Sure, most of these are well-designed and simple features that don't take more than a few minutes to learn. To learn the whole Python syntax and its basic semantics really shouldn't take more than a week or two.
However, to "know the language" is to know when to use those features and in my experience it takes almost a year to learn that. (You should still be able to create working programs before that though
Pyrex
Try: Pyrex
or as mentioned, try Boost's Python if you prefer C++.
What functionality are you lacking from the standard library and the The Vaults of Parnassus?
But immediately the "object model" if you want to call it that got on my nerves. Why "len(list)" and not "list.len()"? Why "'\n'.join(array)" instead of "array.join('\n')"? What's with the simplistic scoping? Why all the underscores? Why "self" everywhere, and why is it so unpythonic to just call it "s" instead? Do I really have to type parantheses all the time? Where are the first-class regexps? Does it make sense that for many built-ins, "foo(obj)" calls "obj.__bar__", why not just use "obj._foo()" directly and eliminate "foo()" from the language.
:)
.append() loops in most cases. I also love generators and find they are amazing ways to write extremely simple code that yields generic iterators. (Extremely useful for the implementation of __iter*__ methods).
Lets call this the foo indirection.
The foo indirection is useful because it releases the tight coupling between the foo(obj) call, and the obj.__bar__() call.
For example, the int(object) call is implemented by usually calling object.__int__(), but this is not necessarily so.
int is a type whose constructor converts objects to an integer using __int__ or other protocols/methods.
For example, int(some_string, 16) will convert the string to an integer treating it as an ascii representation of a hexadecimal number. The string does not necessarily have __int__ and/or does not necessarily support the same arguments as int.
The foo indirection also allows for later modifications of things like the len() function without modifying the __len__ method protocol.
The foo indirection is exactly the same as the indirection you get when using object[subscript], where that subscript may be an index or a slice. It used to call __getitem__ or __getslice__, which is a messy protocol. Because of this indirection, the messy protocol was now cleaned to __getitem__ which may take an integer index or a slice object index, while still supporting __getslice__.
I guess I'm one of those weenies that believes all languages eventually become Lisp or Smalltalk, and any sharp corners that vary from those models will eventually be "filed off". I tried Ruby and discovered it was much more like Smalltalk. Very elegant and easy to write code.
Python does not try to be Smalltalk, however it is indeed very similar to Lisp in many ways. However, there is a fundumental difference in the philosophies of Lisp and Python. Lisp tries to be the "language of languages", where macros let you variate the language to your specific needs. Python tries to be the "uniform language", where macros would never get in the language because they harm uniformity.
Unfortunately Python stole the thunder and now python has the great docs and 3rd-party libraries, while Ruby lingers and grows slowly.
Fortunatly, if you ask me
And Python has the arrogant, Perl-like community now, that thinks jamming list comprehensions and generators into everything makes you "cool".
I simply find comprehensions more readable than
Why do they think it's so cool to reduce the number of lines in a program? I own the "Python cookbook" and find it highly irritating. Rather than solving problems in a single elegant and general way, it presents each author's particular 'leet Python skills, and usually 4-5 different solutions (in a language that claims "one way to do it").
The number of lines is often a good (perhaps rough) indicator of the number of bugs in the code. Code that's not written does not have bugs. I find the "advanced" generator-using solutions very elegant and general.
Python does not claim there is "one way to do it". Python claims "there should be one obvious way to do it, preferrably only one". There can be more than one obvious way, and there always is more than one way (just not obvious).
I found it very unhelpful, and again was confused when people said it was such a great book.
adict = {'key':'val','key2':'val2','key3':3.14}
for k, v in adict.iteritems():
print k, '->', v
I think this is actually more readable than Ruby's "each" function which is a weaker alternative to iteration.