Is there a site like http://yosefk.com/c++fqa/defective.html but for all other crappy languages? You know, they all have their weak points and can be ridiculed.
Python is not as good as it is made out to be, in other words it suffers from a degree of hype. I'll try to argue this point. Potential detractors of the language usually lack the experience to criticize it authoratively. This is more true for Python as it is not (yet) common that people are coerced (by work, school) into learning and working with the language. So the detractors are few and drowned out by the vocal supporters.
The proponents of Python cite 'indentation' as the worst problem, this is a strawman argument 'this is the worst problem and its not really a problem'. This argument has been voted up presumably by people who like the language, because it is certainly not a good reason not to use Python.
Python is open source, and community driven from the beginning, attributes which give it support amongst people such as vocal blogger-developers (not necessarily the people who get the most done) who are credible proponents. Compare to java or C# whose main proponents have a commercial interest and as such have such devalued words that they can't credibly make any positive assertions about their products, and being commercial there are any number of detractors.
People often say Google use it a lot, the 'language of google', so it must be good. Now I suspect Google use it mainly for scripting and web programming.
I am far from an expert at Python, but I have done a couple of semi-serious projects in the language and will try to recall specifically what I didn't like.
- installation mentality, python has inherited the idea that libraries should be installed, so it infact is designed to work inside unix package management, which basically contains a fair amount of baggage (library version issues) and reduced portability. Of course it must be possible to package libraries with your application, but its not conventional.
- quite quirky e.g. __init__
- doesn't perform all that well
- no switch (why not??)
- poor utf support
- no outstanding feature (that I know of). closures and duck typing (all objects are hashes) are just dynamic language bread and butter.
>>7
It does, but it bashes pretty much anything. It's fun to read.
Name:
Anonymous2011-07-21 13:30
Guido has eliminated lambda, map(), filter(), and reduce() from Python 3.0, sying in his blog, that "About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of a Lisp hacker who missed them and submitted working patches. I think these features should be cut from Python 3000..." (http://www.artima.com/weblogs/viewpost.jsp?thread=98196)
"I don't like reading code that was written by someone trying to use tail recursion. It's the ultimate code obfuscation." --GuidoVanRossum
>>5 no outstanding feature (that I know of).
Ah, another toy "programmer", attracted by outstanding features. Python is not a toy language and is not supposed to provide intellectual stimulation to the likes of you.
>>10 "I don't like reading code that was written by someone trying to use tail recursion. It's the ultimate code obfuscation." --GuidoVanRossum BURN THE HERETIC!!
Why drop lambda? Most Python users are unfamiliar with Lisp or Scheme, so the name is confusing; once map(), filter() and reduce() are gone, there aren't a whole lot of places where you really need to write very short local functions.
Name:
Anonymous2011-07-21 13:44
I find that more often than not the callbacks should be methods of some state-carrying object anyway (the exception being toy programs).
Name:
Anonymous2011-07-21 13:46
So now reduce(). This is actually the one I've always hated most, because almost every time I see a reduce() call, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do.
Name:
Anonymous2011-07-21 14:16
>>16
closures can carry state dude. Really easily.
Name:
Anonymous2011-07-21 14:17
Python (like most other scripting languages) does not require variables to be declared, like (let (x 123) ...) in Lisp. This means that Python can't even detect a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo - THEN go boom and you lost all unsaved data.
>>19 Python (like most other scripting languages) does not require variables to be declared
This and the fact that arrays are accessed via ordinals and not offsets are the two reasons why I don't even want to try Lua.
Every non-Lisp high-level interpreted language is actually a shitty Lisp with a syntax, no exceptions.
Name:
Anonymous2011-07-21 14:30
>>20
Lisp isn't interpreted by design. Common Lisp is especially designed for compiler optimization. Eairly Lisps (ones with FEXPRs) were interpreted (for a good reason of theoretical elegancy), but had little in common with Python or Ruby (which use interpreter for a bad reason).
Name:
Anonymous2011-07-21 14:37
>>19 Python (like most other scripting languages) does not require variables to be declared
I wouldn't say most.
>>20
for instance, Lua makes you declare variables with the "local" keyword.
>>24
I understand my error now.
But how would you classify languages such as FIOC and Haskell versus C and Assembly? I thought of using ``scripting languages'' but it is very imprecise.
Name:
Anonymous2011-07-21 15:00
>>27
>how would you classify languages such as FIOC and Haskell versus C and Assembly?
Haskell is compiled (although inefficiently), FIOC isn't.
>>46
Touhous definitely fuck other touhous and I have the doujins to prove it.
Name:
Anonymous2011-07-21 19:41
lithp ``faggots'' can't touch my nonlocal
Name:
Anonymous2011-07-21 20:14
>>40
I don't want to. Russians are total alcoholic retards. They write Pascal, eat pork and don't like Lisp. Hate russians, hope Allah will punish them.
>>49
Excuse me sir, does you being a Muslim imply that they cut part of your dick? Isn't that just like being a Jew but without actually being smart?
Name:
Anonymous2011-07-21 20:47
>>50
smart equals evil. you, jewish smartasses, should be killed to make world a better place and please Allah.
Name:
Anonymous2011-07-21 21:06
2.257. Allah is the Protector of those who have faith: from the depths of darkness He will lead them forth into light. Of those who reject faith the patrons are the evil ones: from light they will lead them forth into the depths of darkness. They will be companions of the fire, to dwell therein (For ever).
About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers who missed them from their past experience. To this collection, Scheme added a lexically-scoped, properly-functioning LAMBDA. But, despite of the PR value of anything with Guy Steele's name associated with it, we think these features should be cut from PLT Scheme v300.
We think dropping FILTER and MAP is pretty uncontroversial; (filter P S) is almost always written clearer as a DO loop (plus the LAMBDA is slower than the loop). Even more so for (map F S). In all cases, writing the equivalent imperative program is clearly beneficial.
Why drop LAMBDA? Most Scheme users are unfamiliar with Alonzo Church (indeed, they don't even know that he was related to Guy Steele), so the name is confusing; also, there is a widespread misunderstanding that LAMBDA can do things that a nested function can't -- we still recall Dan Friedman's Aha! after we showed him that there was no difference! (However, he appears to have since lapsed in his ways.) Even with a better name, we think having the two choices side-by-side just requires programmers to think about their program; not having the choice streamlines the thought process, and Scheme is designed from the ground up to, as much as possible, keep programmers from thinking at all.
So now FOLD. This is actually the one we've always hated most, because, apart from a few examples involving + or *, almost every time we see a FOLD call with a non-trivial function argument, we have to grab pen and paper and imagine the *result* of a function flowing back in as the *argument* to a function. Plus, there are *more* arguments coming in on the side! This is all absurdly complicated. Because almost all the examples of FOLD we found in practice could be written as a simple loop with an accumulator, this style should be preferred, perhaps with us providing a simple helper function to abstract away the boilerplate code. At any rate, FOLD must fold.
Because almost all the examples of FOLD we found in practice could be written as a simple loop with an accumulator, this style should be preferred, perhaps with us providing a simple helper function to abstract away the boilerplate code.
It's a thing of beauty.
Name:
Anonymous2011-07-22 0:41
>>10 Best practices in enterprise software development