This may sound like a troll, but it is an honest question.
Seeing as all variants of Lisp support and even use not negligibly setf, setq, loop constructs and others, why is Lisp any more functional than Python, Ruby, or Smalltalk?
If I had to classify Common Lisp with Python or with Haskell, it obviously falls into the Python class far more closely, and that's not really functional...
Python uses a hybrid approach of refcounting + refloop-finding.
A language that leaks memory in real use cases is just not good enough. A language that slows down execution for periods of time may be good enough. The difference is that the first impairs correctness, while the second does so to performance. While bad performance can be tolerated, incorrectness can't.
Avoid any and all forms of code duplication (or the DRY principle in general). This may mean a lot of templates, code generation and even preprocessor use (unfortunatly, X-Macros are irreplacable in some cases, even with all of C++'s machinery). Sometimes there is no escaping a code generation script. This must be done, against all lazyness.
One of the worst source of bugs is parallelism and management of shared resources. Since knowing this, I have avoided them as much as I could and as such have little to say about debugging them properly. However, I would suggest reducing the amount and complexity of interactions between parallel threads and processes, even at the cost of performance when that seems reasonable. The amount of time spent debugging an ultra-optimized communication scheme is better spent optimizing other parts of the system.
Runtime debug traces. Spend time to create a mechanism for fast debug tracing. I was surprised to find out, that if you trace into memory and dump that memory to some device in big enough chunks, that tracing each and every function entry, exit, argument values and return codes is not expensive and has negligible effect on performance (Ofcourse you can filter out statically traces that cause trouble). If you use a system-call-per-trace, its not going to be fast enough. This relates to the former point of parallelism. You will not be able to kill the bugs without a very good and solid debug trace mechanism. It may be expensive to write as there are very few existing implementations out there, but if your project is large enough and employs parallelism, you need it, and you need it badly.
Consider all code production code, that must be reviewed (You do review your code..?), and make sure that any "hack" or lower-quality code is marked with at least a greppable//TODO and better yet with a #warning.
Error handling is just as important as the nominal case. Most developers write crappy error handling code at best, and ignore the error handling altogether at worst. Error handling should be written, reviewed and tested just like any other piece of code.
Write tests. A lot of tests. Get good coverage (>90%). To do all this, you will have to use a scripting language for your tests. Writing tests in a relatively low-level'ish language such as C++ is in my opinion a huge mistake. RAD-type development of tests which makes them more enjoyable to write and interactive to develop, in a language such as Python, will improve the quality and quantity of your tests by orders of magnitude. Python is a great choice for testing, and there are many tools for FFI that allow testing your C++ code from Python. The small effort to connect the two is worth it.
The size of the real world applications I write is large. The parallelism required by these applications, at least in terms of the parallel hardware is not large.
The point is that this is the situation for almost all developers. Almost everybody is using threads as a tool for parallelism, rather than a tool for exploiting performance of parallel hardware, which is the only thing they're really good for. And indeed very few have the kind of parallel hardware AND performance requirements to really need those threads.
That aside, if you happen to be in a situation where you really need to exploit the hardware to its last bit of performance, and the hardware happens to be parallel - use threads. I would, in that case though, suggest to avoid Java, and write the performance critical threaded code in C, C++, and use a high-level language only for the surrounding logic.
Where "really interesting stuff" is very subjective. I believe I do "really interesting stuff", most of it with Python, with a bit of C where that's a necessity.
Anyhow, I only "appealed to authority" because that seemed to be the language you'd understand, saying that all the "professionals" you know prefer to use something else.
I am not sure what definition of "professional" you use, but most "professionals" I know who come to work for me and prefer to avoid Python (as they were taught in university, or various other places) are not the greatest developers. Once they get acquianted with Python's amazing productivity, they don't look back (and incidentally become a bit better developers in other languages they know...)
Is it me, or is Firefox on non-Windows (at least on Ubuntu/breezy, and other Debian-ish versions) extremely unstable?
On Windows, Firefox is great!
But after an hour of 3 crashes every 5 minutes, when using it on Kubuntu, I can't help but switch to Konqueror, even with the lesser support for various sites (though Konqueror does have better performance, at least seemingly).
Your examples involved types explicitly and specifically useful for threaded programming.
I am questioning the usefulness of threads themselves.
People think of them as "transparent parallelism" in their programs, while in fact the parallelism in threads is about as transparent as a whole lot of mutexes and race conditions.
The simplicity of threads is an illusion, one that one usually snaps out of too late. Reactors and coroutines allow for scalable parallelism while:
Retaining deterministic execution allowing much more effective debugging, and eliminating practically all race conditions.
Don't require any locks, thus require almost no thought at all about critical sections simplifying the design, with the added benefit of no deadlocks.
On Uniprocessor machines, they actually run faster, because of quicker/less context switching and no locking overhead.
With modern languages, and even in less modern ones (via modern tricks), coroutines can be just as transparent as threads at first, and much more transparent later, when the locks are not required.
If English was explicitly statically typed and compiled instead of dynamic, you would have had to write:
"Noun English; verb compiled; adjective instead(adjective *of); typedef mutability_t dynamic; pronoun you; [5 more useless lines...] If English was compiled instead of dynamic, you would have recieved the following compiler errors:"
With all that work you have to do to satisfy the compiler, I write unit tests, and test the code types AND the required functionality. My code will in fact be better and more reliable, in the end.
I think the entire Python community is in debt for your comment, helping them realize the error of their dynamic typing ways.
Seriously, now, if you take a little less patronizing look of the situation, you'd realize that Python developers realize the merits, advantages and disadvantages of dynamic typing. Pythoneers dream of static typing via type inference (the PyPy and other projects), but they wouldn't dream of explicitly and redundantly repeating the declarations of all types. This would reduce Python's expressiveness by orders of magnitude, making it as low as Java's, while also making code very redundant and thus resistant to changes.
Python is not missing lessons from the past, and dynamically-typed code is just as scalable as static code, it just requires modularity and basic unit testing.
In fact, the more powerful approaches enabled by dynamic typing enable more powerful scalability. The lack of scalability is a myth, and Python projects scale up wonderfully (while retaining amazingly low line counts).
Just to clarify, you think that C, Javascript and Perl define behaviour in weird and even incorrect ways. Since none of them will return an error in that context.
In C, "Hello world" + 5 at least makes some sense, as "Hello world" is a pointer, and moving that pointer by 5 references " world". Its not perfect, but it is usable. "Hello world" + 5 resulting in 5 is just mind boggling.
How are you going to replace the quoting operators (q, qq, qw, Leaving that aside, suppose that stronger typing enabled you to demote some operators to class methods. For example, the 'x' operator could be a method, so you write $string2 = $string1->x(50); instead of $string2 = $string1 x 50;. What's the gain? Are you concerned about pollution of the top-level namespace?
No, I'd write (in Python, for instance): string2 *= 50 (The operator itself is polymorphic based on the type. operators are methods, there's no need for all the -> fancy syntax.)
Just like you can use: string2 += "world", and my_int += 5, using the same + operator to achieve different operations based on the operated type. This polymorphism allows for a _lot_ more operations to be represented by a much smaller set of operators. Much easier to remember, too.
Perl's behavior is neither undefined nor incorrect. It's defined in the man pages - type perldoc perldata. If you think it's "incorrect" for Perl to evaluate the above as 5, which it does, what's your basis for thinking that? And do you want the behavior of C, which returns the address of the ' ' before "world" in a temporary string, or the behavior of javascript, which returns "Hello world5"?
I want the behaviour of Python and many other strongly-typed languages: An error.
Pretty much every operator in Perl that is not present in C was added to meet the needs of seasoned C programmers like Larry Wall. If you don't have powerful quoting operators, you'll have to escape quotes when embedding SQL, Postscript and HTML. If you don't have the binding operator '=~', you have to use more verbose and clumsy function calls to use regexps.
Pretty much every operator in Perl was added because the language is weakly typed, and a multitude of operators cannot be achieved by proper polymorphism of scalar types, so it is achieved by creating a whole manual of them.
But usually, brainwashing does work and does persist. As in your case, it does not always succeed.
But just look at the simple statistics, of the amounts of people who persist their parents' beliefs vs. the amounts of people that don't. If brainwashing was not an issue, then persistence should be around 50%, and we both agree it is far above that, is it not?
How could I be accountable if I was never making a choice.
Why does accountability depend on "free will" (whatever that means)?
As long as your decision-making algorithm (you do agree that there is an algorithm there, don't you?) takes into account the consequences of accountability, it makes sense to make you accountable, whether or not you have this "free will" thing you speak of.
They set up some arbitrary criterion (like "irreducible complexity"), claim a particular example meets that criterion, then claim that supports their alternative theory.
The flaw is that "irreducible complexity" does not imply "could not have arised by natural selection", just "could not have arisen through some *straightforward* process of evolution."
The "irreducible complexity" is a valid way to disprove evolution created a certain construct. Sure, that specific construct may have arised by an unlikely large mutation, but you cannot call that evolution: Evolution is the accumulation of incremental positive changes.
In fact, without "irreducible complexity", there is really no argument to contradict evolution at all, as the definition of evolution itself is tautaulogic. The "irreducible complexity" argument is about whether or not species were created by evolution, and without it, without a way to disprove evolution - it is not a theory. Every theory must have a way of disproval, or it is worthless, as it predicts _all_ possible outcomes!
Nature is big enough and has been around long enough that there is a good likelihood that some things will exist that have not left enough evidence behind to determine their natural origins. The fact that we don't have, for instance, hard evidence of the genealogy of the Japanese emperors does not mean we accept that they arose from the Sun god. We might be able to figure out that they came from Korea because of similar customs, or whatever, but we also might never figure it out.
That is true, and we may never figure out how to reduce the complexity of some organisms, but if you can indeed prove that there is no way to reduce that complexity, then you have shown evolution did not in fact occur for that organism.
Ahem! There is a difference between syntactical messiness and semantic messiness. Perl is very ugly syntactically, but I've found it so very beautiful semantically, and its fluidity is exactly what makes Perl so perfect: it allows the fusion of functional (e.g., Lisp-like), imperative (e.g., C-like), and OO paradigms of programming. While many languages fuse the latter two (like C++), few are able to successfully fuse in the first (with things like functions being first-class expressions and something similar to an equivalence of statements and expressions) (and no, just because Python has "lambda" doesn't make it more Lisp-like in the broad picture--in fact, they are even thinking about retreating from that--grrr).
How is Perl beautiful semantically? It is:
Weakly typed (Please don't confuse this with dynamically typed).
Defines behaviour in weird and even incorrect ways, or in other words: blissfully ignores undefined behaviours ("Hello world" + 5).
Has hundreds of operators to remember (Part of the reason Perl developers need to walk around with the Perl manual in their pockets..)
Has no proper exceptions and exception handling (And even uses return codes and "exceptions" interchangably to handle errors)
Lacks formal argument naming (Making automatic documentation generators much more difficult, as well as reflection lacking).
Awful division of the world into scalars and other types, resulting in the use of references to place some types of objects in hashes. In some cases, these references are not even properly ref-counted, and Perl's garbage collector incorrectly frees the objects prematurely (Please tell me this was fixed, I may be out of date about this one).
Awful syntax (but you mentioned that already)...
Generally putting value on the flexibility of how the program can look, rather than on readability, making the computer or human parser go through grammar forests (now extensible, yay) in order to read them.
And dude, "lambda" in Python is just a short-cut syntax for a "def" nested function and represents no extra expressiveness, only "another way to write the same thing", which is frowned upon in the Python way.
Python fully supports functional programming by passing around function objects, though it is rarely the most Pythonic way to do things.
If someone feels that using the full scope of Perl results in messiness, they aren't forced by any means to use that full scope. There are many Perl coders who limit themselves to the "C subset" of Perl. But unlike certain other unnamed languages, Perl doesn't try to play the role of parent in telling you what you can and can't express so those who are more comfortable with a wider breadth of linguistic forms can take advantage of that and make code that is, in a word, elegant.
Its not enough not to force it. You need to discourage it. Or else it will be used, and it IS used. The vast majority of most Perl code out there is NOT written while avoiding all these unreadablity-enhancement features.
As for the syntactical ugliness (the $, @, %, etc.) that most people are referring to when they say that Perl is ugly... well, you learn to live with that pretty early on. But beneath that superficial ugliness lies a sparkling beautiful language.
Weak typing, non-uniform error handling, and lack of formal argument naming are a few things I would not call beautiful.
We're not interested in telling people what they can't do.
I like that.
It is actually very important what people cannot do, in order for programs to be readable.
The less a writer can write, the easier it is for a reader to read.
If you impede write-ability by just a bit (even assuming that offerring just one obvious way to do things, you reduce write-ability, ignoring increased code compatability) you increase readability by orders of magnitude, and I know where I want to be on that tradeoff scale.
Another way to say it, is that if the language offers and encourages developers to use one of 10 different incompatible unreadable ways, they will use them. Maybe YOU won't, but the code you will have to read and use will.
Slashdot Mirror
C++? No thanks :-) I'd almost rather use Perl.
I'd prefer to use Python, thank you.
This may sound like a troll, but it is an honest question.
Seeing as all variants of Lisp support and even use not negligibly setf, setq, loop constructs and others, why is Lisp any more functional than Python, Ruby, or Smalltalk?
If I had to classify Common Lisp with Python or with Haskell, it obviously falls into the Python class far more closely, and that's not really functional...
Python uses a hybrid approach of refcounting + refloop-finding.
A language that leaks memory in real use cases is just not good enough. A language that slows down execution for periods of time may be good enough. The difference is that the first impairs correctness, while the second does so to performance. While bad performance can be tolerated, incorrectness can't.
The good old "Perl doesn't suck because any language can be used well or badly" argument.
Why is that statement not applicable with assembly, or machine code?
You can write readable and maintainable code in almost any language. Some languages just try to make it terribly hard. Perl is one of them.
When gracefully handling fatal and/or process-management signals becomes as easy as catching exceptions, unix will freeze over.
The size of the real world applications I write is large. The parallelism required by these applications, at least in terms of the parallel hardware is not large.
The point is that this is the situation for almost all developers. Almost everybody is using threads as a tool for parallelism, rather than a tool for exploiting performance of parallel hardware, which is the only thing they're really good for. And indeed very few have the kind of parallel hardware AND performance requirements to really need those threads.
That aside, if you happen to be in a situation where you really need to exploit the hardware to its last bit of performance, and the hardware happens to be parallel - use threads. I would, in that case though, suggest to avoid Java, and write the performance critical threaded code in C, C++, and use a high-level language only for the surrounding logic.
Where "really interesting stuff" is very subjective.
I believe I do "really interesting stuff", most of it with Python, with a bit of C where that's a necessity.
Anyhow, I only "appealed to authority" because that seemed to be the language you'd understand, saying that all the "professionals" you know prefer to use something else.
I am not sure what definition of "professional" you use, but most "professionals" I know who come to work for me and prefer to avoid Python (as they were taught in university, or various other places) are not the greatest developers. Once they get acquianted with Python's amazing productivity, they don't look back (and incidentally become a bit better developers in other languages they know...)
Though I would like to ask:
All the time you spend on obscure trolling, could it not be better spent in a homeless shelter?
Is it me, or is Firefox on non-Windows (at least on Ubuntu/breezy, and other Debian-ish versions) extremely unstable?
On Windows, Firefox is great!
But after an hour of 3 crashes every 5 minutes, when using it on Kubuntu, I can't help but switch to Konqueror, even with the lesser support for various sites (though Konqueror does have better performance, at least seemingly).
Like the amateurs at Google, or Nasa?
I am questioning the usefulness of threads themselves.
People think of them as "transparent parallelism" in their programs, while in fact the parallelism in threads is about as transparent as a whole lot of mutexes and race conditions.
The simplicity of threads is an illusion, one that one usually snaps out of too late. Reactors and coroutines allow for scalable parallelism while:
Are you saying software maintainance is by definition done by less skilled programmers? God help the software being maintained.
Seriously, I (almost) never have these bugs in my Python code.
If English was explicitly statically typed and compiled instead of dynamic, you would have had to write:
"Noun English;
verb compiled;
adjective instead(adjective *of);
typedef mutability_t dynamic;
pronoun you;
[5 more useless lines...]
If English was compiled instead of dynamic, you would have recieved the following compiler errors:"
With all that work you have to do to satisfy the compiler, I write unit tests, and test the code types AND the required functionality.
My code will in fact be better and more reliable, in the end.
Threads are overrated.
Every solution using threads is simpler, better and more reliable with coroutines or a Reactor.
The only use of threads is to extract every last bit of computational power from SMP machines. This is not the target audience for Python and Ruby.
I think the entire Python community is in debt for your comment, helping them realize the error of their dynamic typing ways.
Seriously, now, if you take a little less patronizing look of the situation, you'd realize that Python developers realize the merits, advantages and disadvantages of dynamic typing. Pythoneers dream of static typing via type inference (the PyPy and other projects), but they wouldn't dream of explicitly and redundantly repeating the declarations of all types. This would reduce Python's expressiveness by orders of magnitude, making it as low as Java's, while also making code very redundant and thus resistant to changes.
Python is not missing lessons from the past, and dynamically-typed code is just as scalable as static code, it just requires modularity and basic unit testing.
In fact, the more powerful approaches enabled by dynamic typing enable more powerful scalability. The lack of scalability is a myth, and Python projects scale up wonderfully (while retaining amazingly low line counts).
No one I've met doing serious development is building on python, it's just too error prone.
Huh?
All the serious developers I know use almost exclusively Python, only resorting to other languages when they must.
What developers did YOU meet?
Just to clarify, you think that C, Javascript and Perl define behaviour in weird and even incorrect ways. Since none of them will return an error in that context.
In C, "Hello world" + 5 at least makes some sense, as "Hello world" is a pointer, and moving that pointer by 5 references " world". Its not perfect, but it is usable. "Hello world" + 5 resulting in 5 is just mind boggling.
How are you going to replace the quoting operators (q, qq, qw, Leaving that aside, suppose that stronger typing enabled you to demote some operators to class methods. For example, the 'x' operator could be a method, so you write $string2 = $string1->x(50); instead of $string2 = $string1 x 50;. What's the gain? Are you concerned about pollution of the top-level namespace?
No, I'd write (in Python, for instance): string2 *= 50 (The operator itself is polymorphic based on the type. operators are methods, there's no need for all the -> fancy syntax.)
Just like you can use: string2 += "world", and my_int += 5, using the same + operator to achieve different operations based on the operated type. This polymorphism allows for a _lot_ more operations to be represented by a much smaller set of operators. Much easier to remember, too.
Perl's behavior is neither undefined nor incorrect. It's defined in the man pages - type perldoc perldata. If you think it's "incorrect" for Perl to evaluate the above as 5, which it does, what's your basis for thinking that? And do you want the behavior of C, which returns the address of the ' ' before "world" in a temporary string, or the behavior of javascript, which returns "Hello world5"?
I want the behaviour of Python and many other strongly-typed languages: An error.
Pretty much every operator in Perl that is not present in C was added to meet the needs of seasoned C programmers like Larry Wall. If you don't have powerful quoting operators, you'll have to escape quotes when embedding SQL, Postscript and HTML. If you don't have the binding operator '=~', you have to use more verbose and clumsy function calls to use regexps.
Pretty much every operator in Perl was added because the language is weakly typed, and a multitude of operators cannot be achieved by proper polymorphism of scalar types, so it is achieved by creating a whole manual of them.
But usually, brainwashing does work and does persist.
As in your case, it does not always succeed.
But just look at the simple statistics, of the amounts of people who persist their parents' beliefs vs. the amounts of people that don't. If brainwashing was not an issue, then persistence should be around 50%, and we both agree it is far above that, is it not?
How could I be accountable if I was never making a choice.
Why does accountability depend on "free will" (whatever that means)?
As long as your decision-making algorithm (you do agree that there is an algorithm there, don't you?) takes into account the consequences of accountability, it makes sense to make you accountable, whether or not you have this "free will" thing you speak of.
They set up some arbitrary criterion (like "irreducible complexity"), claim a particular example meets that criterion, then claim that supports their alternative theory.
The flaw is that "irreducible complexity" does not imply "could not have arised by natural selection", just "could not have arisen through some *straightforward* process of evolution."
The "irreducible complexity" is a valid way to disprove evolution created a certain construct. Sure, that specific construct may have arised by an unlikely large mutation, but you cannot call that evolution: Evolution is the accumulation of incremental positive changes.
In fact, without "irreducible complexity", there is really no argument to contradict evolution at all, as the definition of evolution itself is tautaulogic. The "irreducible complexity" argument is about whether or not species were created by evolution, and without it, without a way to disprove evolution - it is not a theory. Every theory must have a way of disproval, or it is worthless, as it predicts _all_ possible outcomes!
Nature is big enough and has been around long enough that there is a good likelihood that some things will exist that have not left enough evidence behind to determine their natural origins. The fact that we don't have, for instance, hard evidence of the genealogy of the Japanese emperors does not mean we accept that they arose from the Sun god. We might be able to figure out that they came from Korea because of similar customs, or whatever, but we also might never figure it out.
That is true, and we may never figure out how to reduce the complexity of some organisms, but if you can indeed prove that there is no way to reduce that complexity, then you have shown evolution did not in fact occur for that organism.
How is Perl beautiful semantically? It is:
And dude, "lambda" in Python is just a short-cut syntax for a "def" nested function and represents no extra expressiveness, only "another way to write the same thing", which is frowned upon in the Python way.
Python fully supports functional programming by passing around function objects, though it is rarely the most Pythonic way to do things.
If someone feels that using the full scope of Perl results in messiness, they aren't forced by any means to use that full scope. There are many Perl coders who limit themselves to the "C subset" of Perl. But unlike certain other unnamed languages, Perl doesn't try to play the role of parent in telling you what you can and can't express so those who are more comfortable with a wider breadth of linguistic forms can take advantage of that and make code that is, in a word, elegant.
Its not enough not to force it. You need to discourage it. Or else it will be used, and it IS used. The vast majority of most Perl code out there is NOT written while avoiding all these unreadablity-enhancement features.
As for the syntactical ugliness (the $, @, %, etc.) that most people are referring to when they say that Perl is ugly... well, you learn to live with that pretty early on. But beneath that superficial ugliness lies a sparkling beautiful language.
Weak typing, non-uniform error handling, and lack of formal argument naming are a few things I would not call beautiful.
We're not interested in telling people what they can't do.
I like that.
It is actually very important what people cannot do, in order for programs to be readable.
The less a writer can write, the easier it is for a reader to read.
If you impede write-ability by just a bit (even assuming that offerring just one obvious way to do things, you reduce write-ability, ignoring increased code compatability) you increase readability by orders of magnitude, and I know where I want to be on that tradeoff scale.
Another way to say it, is that if the language offers and encourages developers to use one of 10 different incompatible unreadable ways, they will use them. Maybe YOU won't, but the code you will have to read and use will.