(This may be inaccurate as I'm recalling it from what I read in Simon Singh's "The Code Book", but I hope it explains the point.)
The idea is that you can measure the photons with only partial accuracy, and according to the setting of the measuring instrument. For example, if sending a photon in state Y, the measurement does not yield: "The photon was in state Y", but instead "The photon was probably in state X but maybe in state Y or Z, and not in state W.". Another measurement configuration could yield: "The photon was probably in state Y but maybe in state X or W, and not in state Z." The "hacker" does not know the measurement configuration at the receiver and may try some arbitrary configuration of his own.
The problem is, when receiving the measurement result, for example that the photon was probably in state X, trying to retransmit it as X may be picked up as inconsistent at the real receiver's.
The measurement configuration itself for each bit can be agreed upon by a negotiation stage where a bitstream is sent accross random configurations of both the sender and receiver and then publically agreeing which bits of the sequence to use (knowing they have matching configurations, not letting a "hacker" enough information to know what configurations those are - leaving him with impossible guesswork).
Firstly, white lists shouldn't be similar amongst different people - disallowing spammers from forging their address into many white lists.
Secondly, the white list can be a set of public keys rather than a set of addresses - and the white list filtering would verify a cryptographic signature.
There seems to be a solution to the spam problem - but one that is not backwards compatible.
I have seen this solution posted as a comment to some story in the past - so the credit is not mine, but of some comment writer I do not recall.
The idea is to create a complicated and expensive hashing algorithm that costs quite a few cycles - and use it as a "signature" for each mail's content, including the from and to addresses.
This would mean that sending mail could require a few seconds and be cpu-bound instead of network bound, but this is almost nothing for the average mail user. The spammer, however, would be required to calculate the hashes of the hundreds of thousands of mails he is sending - which could be a costly calculation.
Perhaps, (and this is my idea:), the hash function could be controlled by the server which would require the sender to sign using a function of higher complexity when loads are higher.
Perhaps (another idea of mine), users could signify as part of their email addresses - the complexity of the hash function required to send them mail, or at least know what complexity of a hash function was used when sending them mail. This could allow users to reject mails that weren't at least a bit costly for the sender to send, thereby making spam too costly to practically send.
White lists can also be used by users to save their friends from the trouble of calculating a hash of their mails - but this is probably unnecessary as it should only take a few seconds at most.
Ofcourse verifying the mail's hash should be trivial, no matter the complexity of the hash function - and mails with unmatching hashes would simply be thrown away immediately.
You have ignored the unification of types and classes I mentioned - that does indeed use slots for all standard-named methods (the vast majority of method calls).
Therefore Python enjoys the order that appeals to the software engineer, and the speedup due to slot lookups.
Proto-based unification of classes and instances, by call constructors on classes and such seems to be an 'artificial' and non-natural unification of two similar but different concepts.
Python's basic OO style promotes class notions: the inheritance tree is set up so that nonleaf nodes are classes and leaf nodes are instances.
You're assuming that instances are 'inheriting' from the classes they're instantiated of.
But in fact, this is all fiction down deep: there is no necessary distinction between instances and classes. Nonetheless, one must ask WHY Python has a class declaration at all.
The differentiation between instances and classes is taken from Smalltalk, and done for several reasons:
Instances are instantiated, subclasses are defined. Instantiations run a class's constructor, while definitions are almost a simple assignment (metaclass functionality aside).
Class methods are unbound, while instance methods are bound. Differentiating classes from instances allows one to refer to a class's method in general, or to one bound (curried) to a specific instance in a syntax-friendly way. (MyClass.method)(my_instance, a, b, c) is similar to (my_instance.method)(a, b, c).
Subclasses are conceptually different from instances. The syntatic differentiation allows easy clarification of which concept the code is trying to express. Whether a type of instances is being declared, or a single instance.
Subclasses can be of multiple classes. Instances are always of one class.
This is how Python actually implements things (and like Python, it's slow).
For the implementation of class member descriptors, and due to the binding I mentioned above, Python classes are implemented a little differently. The instance has a __class__ attribute, pointing to the class, the class has a __bases__ attribute for a list of its base classes.
Also note that Python, since version 2.2 is moving to real class systems, that really use fast slot lookups in exchange for some of the flexibility allowed by the previous proto design. Little change in interface is noticed, except for more consistent unification of the type and class of instances (classes are now first-class types), the inability to change the class of instances, and the inability to multiply inherit under some conditions.
To my knowledge, Python cannot do nested closures like this.
Untrue. Python, ever since version 2.1, can easily do such things:
I'd like to ask whether the Java code you pasted is actually correct, because the return types of some of these functions are void, while they return ints or functions/classes. I'd like to see Java code that compiles, or a better explanation of what the 'void' means in those method declarations.
Or alternatively: f1 = lambda x: lambda y: lambda z: (x, y, z)
There is a similar problem to Java's:
def f(x):
a = [None]
def g(y):
x = y # This will create a local 'x' in g
a[0] = y # This will assign to a of the outer scope
Also things like: def f(x):
class A:
def __init__(self, y):
self.x, self.y = x,y Are allowed (including any number of nested functions or classes, ofcourse).
You must have tried Python before 2.1, or Python 2.1 without enabling lexical scoping ("from __future__ import nested_scopes").
which have real data types in the forms of rationals, fractions, complex numbers, with supertypes etc.,
rationals are soon to be added to Python, and can for now be implemented in the form of two arbitrarily long objects. fractions are doubles. complex numbers exist in Python even in the syntatic level (try evaluating "4+6j", or "1j**2").
What do you mean by supertypes here?
Python's closure handling is broken; it can't even handle simple nested lexical scoping. This can be quite a big deal for writing fast, on-the-fly code
What version of Python have you tried? Python has fixed this problem since Python 2.1. Lexical scoping works fine in Python, except for the fact local variables are local to the innermost function declaring them, so that assignments into outer scopes is not allowed. Assignment into attributes of objects from outer scopes is easily possible though, resolving the requirement to access the outer scope.
As far as I know, Java has no closures or lexical scoping at all.. Can you show an example Java code with lexical scoping?
As to the object system: my general feeling, and I think the feeling of most people who've used both class-based and proto-based models, is that proto-based models are much more flexible and intuitive. You need a good reason to use a class-based model. Typically the reasons are either (1) speed or (2) compile-time bug-checking via strong typing. Both are good reasons.
Python is not a class-based system. The 'slots' are merely an implementation-level detail that does not interest the Python programmers, and seen as a 'standard name' for common operations.
What extra syntax are you talking about?
Python syntax is the smallest of all the languages you mentioned, if you include standard macros and special forms in the Lisp variants' syntaxes.
Again, I'd like to understand where you think Python has a class-based type system. With an example, if you can.
Please explain how "self" is absurd? I'm assuming you refer to the explicit method argument. In actuality, I have witnessed at least one case where the explicit naming of the given instance let me define classes nested in methods, allowing the internal methods to access the namespace of the external class's methods (achieving the more important lexical access goals of closures, btw).
Supporting real closures that allow messing of the enclosing function's namespace with new references is a problem because it clashes with the concept of unstated local variables. There are many syntatic-level ways around it. For example, assuming full closure support:
def func():
def internal_func():
a = 5
internal_func()
return a
Note the closure above does not make it possible for nested functions to have local variables of their own.
As for the Object Model in Python - its very clear to me, and seems quite simple too. Python has slots for functionalities - because its a great way to express the idea of "standard methods" such as construction, addition, and other basic concepts. This is very easy to understand and follow in code.
class C:
def __init__(self):
print 'This initializes', self, 'and is quite clear about it!'
Subclasses work by pointing at their superclass to find the method implementations - but this is completely unrelated to the slots. I understand that technically, on the low implementational level, there is a link between the way a method is looked up (in a slot, or by name), and the way subclassing works (overriding functions in slots, or pointing to super class). Conceptually, however, I don't understand why anyone has to keep this information in mind.
When programming Python, one does not think of slots and pointers to superclasses. Instead, one thinks of __init__ as a standard name for constructors, of __add__ as a standard name for the '+' method, etc. All lookups are conceptually by name, and superclass method finding rules are well established and documented - as a completely different concept.
I'd be happy if you could reiterate why you thought the low-level method lookup mechanism mattered to the programmer or the language, and would appriciate examples in code.
Re:Syntactically Significant Whitespace - YUCK!!!
on
Python in a Nutshell
·
· Score: 1
The % feature depends on your editor. If your editor is decent, you can jump up/down Python blocks as well, or at least script the editor to be able to. As for tabstops - that's indeed a problem with Python, one a Python programmer should be aware of. However, once the Python programmer is aware of this problem, its not really serious, because rarely will indentation problems result in anything other than IndentationError raised, and you can simply search-replace all tabs to 4 or 8 spaces, or vice versa.
The other side of the coin is that all Python code everywhere and from anyone is properly indented making it more readable. The language syntax becomes less noisy, and less redundant (expressing blocking via symbols _and_ indentation), reducing the odds of having code that looks differently from what its really saying.
Just curious, Do you write your code unindented, in other programming languages?
Re:A (hopefully) unbiased opinion on Perl v. Pytho
on
Python in a Nutshell
·
· Score: 3, Insightful
But the problem is that Python suffers from a lot of Perl's problems Other than Performance?
and adds a few of its own: you can't implement it in itself Hmm? Its quite trivial to parse Python code in Python, and its qutie trivial to interpret it with Python code, so where's the problem?
it has no strong typing (even Perl's use strict is ridiculously better), You're confusing "strong typing" with "static typing". Python has no Static Typing, but indeed has Strong Typing (try '5 + "Hello"' in your Python interpreter). Perl, on the other hand, has no strong typing at all ("Hello" + 5 is perfectly valid in Perl, albeit senseless). Not having Static Typing is not a bad thing - its a concious decision by the language designers. The designers of Python wanted the language to be just-explicit. If you want the program code to express an idea, you express it once - Which is more than implicit, and less than redundant. Static typing is redundant - and avoided in Python as a design goal of minimizing programming time of any task. Another idea behind the lack of static typing is that all lines of code MUST run at least once anyway for any minimal level of reliability, so the compilation-level check adds no value.
an OO system with no support for data hiding, etc. etc. Python supports data-hiding, but simply does not enforce it. This is because Python is not a BDL (Bondage and discipline langauge). Instead, there are extremely well-established and documented Python conventions. The prefix underscore that denotes private/protected, The double underscore that denotes private (avoiding namespace clashing by name mangling), etc. And that brings me to the biggest problem: Python doesn't really have a niche to fill. The CGI space has been seemingly co-opted completely by Perl (at least until people start using PHP), and it's too dog-slow to be used for real CS applications. Python isn't a niche language. Its a general-purpose language - and no - its far from being too slow for real CS applications. That's why its successfully used in Search engines, 3d engines, system administration, compilers, games, etc. As a beginner's language it's ideal, but that's not going to help it be taken seriously when it comes to real computing tasks. Python is taken very seriously in many many places, with increasing seriousness.
If the python developers made some tweaks to the type system Like what? Static typing conflicts with the Python design goals. and added a real compiler Python already has the Jython compiler to Java, psyco compiler to native code, and others. then I would advocate that most software engineering be moved there. Many already advocate it for all software engineering except for the inner loops which are exported to Python from C code. This proves for many people to be the most effective way to write fast, reliable maintainable code. As it stands it's an original language which is a lot of fun to program in, and still has lots of unmapped potential to it. The unmapped potential is discovered by more people every day:)
Re:A (hopefully) unbiased opinion on Perl v. Pytho
on
Python in a Nutshell
·
· Score: 1
Your blocks are obviously too large, then. You need to divide into smaller, more trivial pieces of code.
Python is so expressive that functions/methods rarely need to exceed 5-8 lines.
Show me any example of a long Python function where you have experienced what you speak of, and I'll explain how and why its too long.
How is it "raping the exception mechanism"? Can you point to a case where it could cause a problem or harm readability?
"continue 2" on the other hand, almost makes me puke, requires a lot more careful tracking of changes in the code, and makes every piece of code tightly-coupled with every other.
Either they're elegant, or you're trapped in a misconception:)
Ofcourse you can view C and Unix as great tools that worked wonderfully over the years.. Or you can blame K and R for an insecure design (yielding problems such as The Confused Deputy) and the general insecurity problems that exist in Unix and C and not in many alternatives.
The concept of a process is also not very related to Unix specifically, but found everywhere where hardware-level separation between threads of execution is useful. I think in the future, such protection will be achieved at the language-level, rather than the hardware level, and that processes are actually ad-hoc and not in any way elegant.
As for files... I see those as the general concept of applications explcitly serializing and persisting their data into bit streams uniquely identified on the disk via string hierarchies. I don't find that elegant at all. In fact, I find Orthogonal persistence a lot more elegant.
I believe Unix encapsulates some nice creative ideas, even elegant. But I also think that the positive concensus about them is a simple reflection of the poor alternatives and of general ignorance of better and more elegant designs out there.
Many people here express worry that teleporting humans actually destroys them before recreating someone else in another position.
I want to counter that with two points:
According to Quantum theory, no particles or physical entities have an identity other than the collection of their properties. This means that two particles of the same type and with the same properties are completely indistinguishable. This means that a human being destroyed, but replicatedexactly somewhere else, will have the exact same properties aside for position, in other words - moved. If you're worried that changing your position is a problem, you're already dead:)
Many human cells are constantly dying and get replaced. Not many of the cells in the human body existed when the human was born. This means that your existing body/cells have been destroyed and recreated already - you simply didn't know.
I'll bite: These Americans may have every reason to believe that waging war is necessary here.. Sometimes war is the rational choice (See the loss of Chechoslovakia pre-WW II).
I've been pondering this idea for a while. I've spoken about it in many IRC channels.
Now reading this Slashdot article, it seems that my idea is finally impelmented, and even the description is put in almost the exact same words I used to describe the idea.
Modern Copyright is a draconian misinterpretation of the ethical copyright, originating in the American constitution. The modern copyright legislation is all based on laws passed as a result of high pressure from organization such as MPAA and RIAA. Thus, it is not unethical to not abide by these copyright laws.
Also, copyright infringement is by no means identical, similar or matching to the definition of "stolen" in the dictionary. Note that almost all definitions of theft insist that the stolen item must be removed completely, at least temporarily, from its rightful owner. Thus, as you see, copyright infringement cannot be classified as theft -- at least not in English.
The MPAA and RIAA have even managed to brainwash people like you into associating MP3's with copyright infringement, where in fact they are simply an audio compression format.
There is no real measurement of how free something is, as there is no 1 dimensional axis.
To the software user - the GPL is free-er because it requires the distributors of software to that user to release the source. It even allows him to make secret changes not as GPL, as long as he doesn't distribute them.
To the software creator - the GPL is less free, and also in regard to a specific GPL'd source, it is less free.
I prefer the freedom for software users, as the "freedom" of software creators/distributors is not at all valuable, and not to be confused with other things meant to give software distributors an incentive to create work.
GPL forces everyone else to release modifications as GPL. No, you can keep the modifications to yourself. If, however, you choose to distribute these modifications, you must distribute them as GPL, and not some other license.
Slashdot Mirror
(This may be inaccurate as I'm recalling it from what I read in Simon Singh's "The Code Book", but I hope it explains the point.)
The idea is that you can measure the photons with only partial accuracy, and according to the setting of the measuring instrument. For example, if sending a photon in state Y, the measurement does not yield: "The photon was in state Y", but instead "The photon was probably in state X but maybe in state Y or Z, and not in state W.". Another measurement configuration could yield: "The photon was probably in state Y but maybe in state X or W, and not in state Z."
The "hacker" does not know the measurement configuration at the receiver and may try some arbitrary configuration of his own.
The problem is, when receiving the measurement result, for example that the photon was probably in state X, trying to retransmit it as X may be picked up as inconsistent at the real receiver's.
The measurement configuration itself for each bit can be agreed upon by a negotiation stage where a bitstream is sent accross random configurations of both the sender and receiver and then publically agreeing which bits of the sequence to use (knowing they have matching configurations, not letting a "hacker" enough information to know what configurations those are - leaving him with impossible guesswork).
Firstly, white lists shouldn't be similar amongst different people - disallowing spammers from forging their address into many white lists.
Secondly, the white list can be a set of public keys rather than a set of addresses - and the white list filtering would verify a cryptographic signature.
The solution to that problem is ofcourse the white lists. White lists could allow solicited mail to not be hashed.
There seems to be a solution to the spam problem - but one that is not backwards compatible.
:), the hash function could be controlled by the server which would require the sender to sign using a function of higher complexity when loads are higher.
I have seen this solution posted as a comment to some story in the past - so the credit is not mine, but of some comment writer I do not recall.
The idea is to create a complicated and expensive hashing algorithm that costs quite a few cycles - and use it as a "signature" for each mail's content, including the from and to addresses.
This would mean that sending mail could require a few seconds and be cpu-bound instead of network bound, but this is almost nothing for the average mail user. The spammer, however, would be required to calculate the hashes of the hundreds of thousands of mails he is sending - which could be a costly calculation.
Perhaps, (and this is my idea
Perhaps (another idea of mine), users could signify as part of their email addresses - the complexity of the hash function required to send them mail, or at least know what complexity of a hash function was used when sending them mail.
This could allow users to reject mails that weren't at least a bit costly for the sender to send, thereby making spam too costly to practically send.
White lists can also be used by users to save their friends from the trouble of calculating a hash of their mails - but this is probably unnecessary as it should only take a few seconds at most.
Ofcourse verifying the mail's hash should be trivial, no matter the complexity of the hash function - and mails with unmatching hashes would simply be thrown away immediately.
You have ignored the unification of types and classes I mentioned - that does indeed use slots for all standard-named methods (the vast majority of method calls).
Therefore Python enjoys the order that appeals to the software engineer, and the speedup due to slot lookups.
Proto-based unification of classes and instances, by call constructors on classes and such seems to be an 'artificial' and non-natural unification of two similar but different concepts.
You're assuming that instances are 'inheriting' from the classes they're instantiated of.
But in fact, this is all fiction down deep: there is no necessary distinction between instances and classes. Nonetheless, one must ask WHY Python has a class declaration at all.
The differentiation between instances and classes is taken from Smalltalk, and done for several reasons:
Instances are instantiated, subclasses are defined. Instantiations run a class's constructor, while definitions are almost a simple assignment (metaclass functionality aside).
Class methods are unbound, while instance methods are bound. Differentiating classes from instances allows one to refer to a class's method in general, or to one bound (curried) to a specific instance in a syntax-friendly way. (MyClass.method)(my_instance, a, b, c) is similar to (my_instance.method)(a, b, c).
Subclasses are conceptually different from instances. The syntatic differentiation allows easy clarification of which concept the code is trying to express. Whether a type of instances is being declared, or a single instance.
Subclasses can be of multiple classes. Instances are always of one class.
This is how Python actually implements things (and like Python, it's slow).
For the implementation of class member descriptors, and due to the binding I mentioned above, Python classes are implemented a little differently. The instance has a __class__ attribute, pointing to the class, the class has a __bases__ attribute for a list of its base classes.
Also note that Python, since version 2.2 is moving to real class systems, that really use fast slot lookups in exchange for some of the flexibility allowed by the previous proto design. Little change in interface is noticed, except for more consistent unification of the type and class of instances (classes are now first-class types), the inability to change the class of instances, and the inability to multiply inherit under some conditions.
To my knowledge, Python cannot do nested closures like this.
Untrue. Python, ever since version 2.1, can easily do such things:
I'd like to ask whether the Java code you pasted is actually correct, because the return types of some of these functions are void, while they return ints or functions/classes.
I'd like to see Java code that compiles, or a better explanation of what the 'void' means in those method declarations.
def f1(x):
def f2(y):
def f3(z):
return x,y,z
return f3
return f2
Or alternatively:
f1 = lambda x: lambda y: lambda z: (x, y, z)
There is a similar problem to Java's:
def f(x):
a = [None]
def g(y):
x = y # This will create a local 'x' in g
a[0] = y # This will assign to a of the outer scope
Also things like:
def f(x):
class A:
def __init__(self, y):
self.x, self.y = x,y
Are allowed (including any number of nested functions or classes, ofcourse).
You must have tried Python before 2.1, or Python 2.1 without enabling lexical scoping ("from __future__ import nested_scopes").
which have real data types in the forms of rationals, fractions, complex numbers, with supertypes etc.,
rationals are soon to be added to Python, and can for now be implemented in the form of two arbitrarily long objects. fractions are doubles. complex numbers exist in Python even in the syntatic level (try evaluating "4+6j", or "1j**2").
What do you mean by supertypes here?
Python's closure handling is broken; it can't even handle simple nested lexical scoping. This can be quite a big deal for writing fast, on-the-fly code
What version of Python have you tried? Python has fixed this problem since Python 2.1. Lexical scoping works fine in Python, except for the fact local variables are local to the innermost function declaring them, so that assignments into outer scopes is not allowed. Assignment into attributes of objects from outer scopes is easily possible though, resolving the requirement to access the outer scope.
As far as I know, Java has no closures or lexical scoping at all.. Can you show an example Java code with lexical scoping?
As to the object system: my general feeling, and I think the feeling of most people who've used both class-based and proto-based models, is that proto-based models are much more flexible and intuitive. You need a good reason to use a class-based model. Typically the reasons are either (1) speed or (2) compile-time bug-checking via strong typing. Both are good reasons.
Python is not a class-based system. The 'slots' are merely an implementation-level detail that does not interest the Python programmers, and seen as a 'standard name' for common operations.
What extra syntax are you talking about?
Python syntax is the smallest of all the languages you mentioned, if you include standard macros and special forms in the Lisp variants' syntaxes.
Again, I'd like to understand where you think Python has a class-based type system. With an example, if you can.
Please explain how "self" is absurd? I'm assuming you refer to the explicit method argument. In actuality, I have witnessed at least one case where the explicit naming of the given instance let me define classes nested in methods, allowing the internal methods to access the namespace of the external class's methods (achieving the more important lexical access goals of closures, btw).
Supporting real closures that allow messing of the enclosing function's namespace with new references is a problem because it clashes with the concept of unstated local variables. There are many syntatic-level ways around it. For example, assuming full closure support:
def func():
def internal_func():
a = 5
internal_func()
return a
Can be implemented instead via:
def func():
a = [None]
def internal_func():
a[0] = 5
internal_func()
return a[0]
Note the closure above does not make it possible for nested functions to have local variables of their own.
As for the Object Model in Python - its very clear to me, and seems quite simple too. Python has slots for functionalities - because its a great way to express the idea of "standard methods" such as construction, addition, and other basic concepts. This is very easy to understand and follow in code.
class C:
def __init__(self):
print 'This initializes', self, 'and is quite clear about it!'
Subclasses work by pointing at their superclass to find the method implementations - but this is completely unrelated to the slots. I understand that technically, on the low implementational level, there is a link between the way a method is looked up (in a slot, or by name), and the way subclassing works (overriding functions in slots, or pointing to super class). Conceptually, however, I don't understand why anyone has to keep this information in mind.
When programming Python, one does not think of slots and pointers to superclasses. Instead, one thinks of __init__ as a standard name for constructors, of __add__ as a standard name for the '+' method, etc. All lookups are conceptually by name, and superclass method finding rules are well established and documented - as a completely different concept.
I'd be happy if you could reiterate why you thought the low-level method lookup mechanism mattered to the programmer or the language, and would appriciate examples in code.
The % feature depends on your editor. If your editor is decent, you can jump up/down Python blocks as well, or at least script the editor to be able to.
As for tabstops - that's indeed a problem with Python, one a Python programmer should be aware of.
However, once the Python programmer is aware of this problem, its not really serious, because rarely will indentation problems result in anything other than IndentationError raised, and you can simply search-replace all tabs to 4 or 8 spaces, or vice versa.
The other side of the coin is that all Python code everywhere and from anyone is properly indented making it more readable. The language syntax becomes less noisy, and less redundant (expressing blocking via symbols _and_ indentation), reducing the odds of having code that looks differently from what its really saying.
Just curious, Do you write your code unindented, in other programming languages?
But the problem is that Python suffers from a lot of Perl's problems
:)
Other than Performance?
and adds a few of its own: you can't implement it in itself
Hmm? Its quite trivial to parse Python code in Python, and its qutie trivial to interpret it with Python code, so where's the problem?
it has no strong typing (even Perl's use strict is ridiculously better),
You're confusing "strong typing" with "static typing". Python has no Static Typing, but indeed has Strong Typing (try '5 + "Hello"' in your Python interpreter). Perl, on the other hand, has no strong typing at all ("Hello" + 5 is perfectly valid in Perl, albeit senseless).
Not having Static Typing is not a bad thing - its a concious decision by the language designers. The designers of Python wanted the language to be just-explicit. If you want the program code to express an idea, you express it once - Which is more than implicit, and less than redundant. Static typing is redundant - and avoided in Python as a design goal of minimizing programming time of any task.
Another idea behind the lack of static typing is that all lines of code MUST run at least once anyway for any minimal level of reliability, so the compilation-level check adds no value.
an OO system with no support for data hiding, etc. etc.
Python supports data-hiding, but simply does not enforce it. This is because Python is not a BDL (Bondage and discipline langauge). Instead, there are extremely well-established and documented Python conventions. The prefix underscore that denotes private/protected, The double underscore that
denotes private (avoiding namespace clashing by name mangling), etc.
And that brings me to the biggest problem: Python doesn't really have a niche to fill. The CGI space has been seemingly co-opted completely by Perl (at least until people start using PHP), and it's too dog-slow to be used for real CS applications.
Python isn't a niche language. Its a general-purpose language - and no - its far from being too slow for real CS applications. That's why its successfully used in Search engines, 3d engines, system administration, compilers, games, etc.
As a beginner's language it's ideal, but that's not going to help it be taken seriously when it comes to real computing tasks.
Python is taken very seriously in many many places, with increasing seriousness.
If the python developers made some tweaks to the type system
Like what? Static typing conflicts with the Python design goals.
and added a real compiler
Python already has the Jython compiler to Java, psyco compiler to native code, and others.
then I would advocate that most software engineering be moved there.
Many already advocate it for all software engineering except for the inner loops which are exported to Python from C code. This proves for many people to be the most effective way to write fast, reliable maintainable code.
As it stands it's an original language which is a lot of fun to program in, and still has lots of unmapped potential to it.
The unmapped potential is discovered by more people every day
Your blocks are obviously too large, then.
You need to divide into smaller, more trivial pieces of code.
Python is so expressive that functions/methods rarely need to exceed 5-8 lines.
Show me any example of a long Python function where you have experienced what you speak of, and I'll explain how and why its too long.
How is it "raping the exception mechanism"? Can you point to a case where it could cause a problem or harm readability?
"continue 2" on the other hand, almost makes me puke, requires a lot more careful tracking of changes in the code, and makes every piece of code tightly-coupled with every other.
Puke. Now I know why I don't use PHP.
Either they're elegant, or you're trapped in a misconception :)
Ofcourse you can view C and Unix as great tools that worked wonderfully over the years.. Or you can blame K and R for an insecure design (yielding problems such as The Confused Deputy) and the general insecurity problems that exist in Unix and C and not in many alternatives.
The concept of a process is also not very related to Unix specifically, but found everywhere where hardware-level separation between threads of execution is useful. I think in the future, such protection will be achieved at the language-level, rather than the hardware level, and that processes are actually ad-hoc and not in any way elegant.
As for files... I see those as the general concept of applications explcitly serializing and persisting their data into bit streams uniquely identified on the disk via string hierarchies. I don't find that elegant at all. In fact, I find Orthogonal persistence a lot more elegant.
I believe Unix encapsulates some nice creative ideas, even elegant. But I also think that the positive concensus about them is a simple reflection of the poor alternatives and of general ignorance of better and more elegant designs out there.
SOMEVALUE | ~SOMEVALUE = 0xFFFF... (according to the size of the type)
0xFFFF... (where all of the integer's bits are set) is -1, in the 2's complement numbering representation used by all digital computers.
I want to counter that with two points:
According to Quantum theory, no particles or physical entities have an identity other than the collection of their properties. This means that two particles of the same type and with the same properties are completely indistinguishable. This means that a human being destroyed, but replicated exactly somewhere else, will have the exact same properties aside for position, in other words - moved. If you're worried that changing your position is a problem, you're already dead :)
Many human cells are constantly dying and get replaced. Not many of the cells in the human body existed when the human was born. This means that your existing body/cells have been destroyed and recreated already - you simply didn't know.
Superbowl -> Anti-war rant...
Nice trolling.
I'll bite: These Americans may have every reason to believe that waging war is necessary here.. Sometimes war is the rational choice (See the loss of Chechoslovakia pre-WW II).
Bah. Unethical people should be shot. That includes you.
I've been pondering this idea for a while.
:)
I've spoken about it in many IRC channels.
Now reading this Slashdot article, it seems that my idea is finally impelmented, and even the description is put in almost the exact same words I used to describe the idea.
I wonder if I inspired someone...
Is Paul Graham's statistical filtering of spam applied anywhere?
:)
To me, it seems as an obvious step forward in spam filtering and achieves amazing results.
Somehow though, most good ideas get ignored
Modern Copyright is a draconian misinterpretation of the ethical copyright, originating in the American constitution. The modern copyright legislation is all based on laws passed as a result of high pressure from organization such as MPAA and RIAA. Thus, it is not unethical to not abide by these copyright laws.
Also, copyright infringement is by no means identical, similar or matching to the definition of "stolen" in the dictionary. Note that almost all definitions of theft insist that the stolen item must be removed completely, at least temporarily, from its rightful owner. Thus, as you see, copyright infringement cannot be classified as theft -- at least not in English.
The MPAA and RIAA have even managed to brainwash people like you into associating MP3's with copyright infringement, where in fact they are simply an audio compression format.
Python for anything that doesn't require performance.
C for the rest.
My own Lisp variant for everything (when I get time to implement it, ofcourse :)
:)
Now, use any set you like and quit bitching
There is no real measurement of how free something is, as there is no 1 dimensional axis.
To the software user - the GPL is free-er because it requires the distributors of software to that user to release the source. It even allows him to make secret changes not as GPL, as long as he doesn't distribute them.
To the software creator - the GPL is less free, and also in regard to a specific GPL'd source, it is less free.
I prefer the freedom for software users, as the "freedom" of software creators/distributors is not at all valuable, and not to be confused with other things meant to give software distributors an incentive to create work.
GPL forces everyone else to release modifications as GPL.
No, you can keep the modifications to yourself.
If, however, you choose to distribute these modifications, you must distribute them as GPL, and not some other license.
is not a safe language.