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.
- Everything you write will be open source. No FASLs, DLLs or EXEs. Developer may want to have control over the level of access to prevent exposure of internal implementation, as it may contain proprietary code or because strict interface/implementation decomposition is required. Python third-party library licensing is overly complex. Licenses like MIT allow you to create derived works as long as you maintain attrubution; GNU GPL, or other 'viral' licenses don't allow derived works without inheriting the same license. To inherit the benefits of an open source culture you also inherit the complexities of the licensing hell.
- 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 and can be hard to deploy as a desktop app due to cross platform issues, language version, etc. Open Source projects generally don't care about Windows, most open source developers use Linux because "Windows sucks".
- Probably the biggest practical problem with Python is that there's no well-defined API that doesn't change. This make life easier for Guido and tough on everybody else. That's the real cause of Python's "version hell".
- Global Interpreter Lock (GIL) is a significant barrier to concurrency. Due to signaling with a CPU-bound thread, it can cause a slowdown even on single processor. Reason for employing GIL in Python is to easy the integration of C/C++ libraries. Additionally, CPython interpreter code is not thread-safe, so the only way other threads can do useful work is if they are in some C/C++ routine, which must be thread-safe.
- Python (like most other scripting languages) does not require variables to be declared, as (let (x 123) ...) in Lisp or int x = 123 in C/C++. 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. Local and global scopes are unintuitive. Having variables leak after a for-loop can definitely be confusing. Worse, binding of loop indices can be very confusing; e.g. "for a in list: result.append(lambda: fcn(a))" probably won't do what you think it would. Why nonlocal/global/auto-local scope nonsense?
- Python has a faulty package system. Type time.sleep=4 instead of time.sleep(4) and you just destroyed the system-wide sleep function with a trivial typo. Now consider accidentally assigning some method to time.sleep, and you won't even get a runtime error - just very hard to trace behavior. And sleep is only one example, it's just as easy to override ANYTHING.
- Crippled support for functional programming. Python's lambda is limited to a single expression and doesn't allow conditionals. Python makes a distinction between expressions and statements, and does not automatically return the last expressions, thus crippling lambdas even more. Assignments are not expressions. Most useful high-order functions were deprecated in Python 3.0 and have to be imported from functools. No continuations or even tail call optimization: "I don't like reading code that was written by someone trying to use tail recursion." --Guido
- Python's syntax, based on SETL language and mathematical Set Theory, is non-uniform, hard to understand and parse, compared to simpler languages, like Lisp, Smalltalk, Nial and Factor. Instead of usual "fold" and "map" functions, Python uses "set comprehension" syntax, which has overhelmingly large collection of underlying linguistic and notational conventions, each with it's own variable binding semantics. This, in effect, makes Python look like an overengineered toy for math geeks. Good luck discerning [f(z) for y in x for z in gen(y) if pred(z)] from [f(z) if pred(z) for z in gen(y) for y in x]. In addition, you will enjoy cryptic expressions like z(*z(*m.i())[::-1]).
- Forced Indentation of Code (aka "off-side" rule) impedes using CLI, automatically generating Python code and moving around large code blocks. Editing Python code requires special editors (forget about Word/Notepad), that expand tabs into spaces, while sharing code through a web post or email will most likely break indentation. Absence of block-terminator is so utterly confusing, that you'll find yourself ending blocks with #endif anyway. It's painful to deal with other things that need indenting, such as large SQL queries, or HTML when you're using things like mod_python.
- Python hides logical connectives in a pile of other symbols: try seeing "and" in "if y > 0 or new_width > width and new_height > height or x < 0".
- Python indulges messy horizontal code (> 80 chars per line), where in Lisp one would use "let" to break computaion into manageable pieces. Get used to stuff like self.convertId([(name, uidutil.getId(obj)) for name, obj in container.items() if IContainer.isInstance(obj)])
- Quite quirky: triple-quoted strings seem like a syntax-decision from a David Lynch movie, and double-underscores, like __init__, seem appropriate in C, but not in a language that provides list comprehensions. There are better ways to mark certain features as internal or special than just calling it __feature__. self everywhere can make you feel like OO was bolted on, even though it wasn't.
- Python has too many confusing non-orthogonal features: references can't be used as hash keys; expressions in default arguments are calculated when the function is defined, not when it’s called. Why have both dictionaries and objects? Why have both types and duck-typing? Why is there ":" in the syntax if it almost always has a newline after it? The Python language reference devotes a whole sub-chapter to "Emulating container types", "Emulating callable Objects", "Emulating numeric types", "Emulating sequences" etc. -- only because arrays, sequences etc. are "special" in Python. Subtle data types (list and tuple, bytes and bytearray) will make you wonder "Do I need the mutable type here?", while Clojure and Haskell manage to do with only immutable data.
- Python's GC uses naive reference counting, which is slow and doesn't handle circular references, meaning you have to expect subtle memory leaks and can't easily use arbitrary graphs as your data. In effect Python complicates even simple tasks, like keeping directory tree with symlinks.
- Patterns and anti-patterns are signs of deficiencies inherent in the language. In Python, concatenating strings in a loop is considered an anti-pattern merely because the popular implementation is incapable of producing good code in such a case. The intractability or impossibility of static analysis in Python makes such optimizations difficult or impossible.
- Problems with arithmetic: no Numerical Tower (nor even rational/complex numbers), meaning 1/2 would produce 0, instead of 0.5, leading to subtle and dangerous errors.
- Poor UTF support and unicode string handling is somewhat awkward.
- No outstanding feature, that makes the language, like the brevity of APL or macros of Lisp. Python doesn’t really give us anything that wasn’t there long ago in Lisp and Smalltalk.
Advantages: Lisp
Good CLs and Schemes come with structured symbolic manipulation and pattern matching macros and functions like match for doing matching over nested list patterns to a good extent, though only up to a degree that Prolog would be better at this. Some Lisps further have a mini-prolog sub-language for those parts.
Good CLs and Schemes are JITted or compiled to machine code while preserving things like eval.
Macros.
Even Racket is about 10x faster than the scripting languages in the shootout.
lisp is good for making extremely powerful abstractions. these abstractions are good in big programs. The world is moving away from big programs, to small services that talk to each other over the network. lisp has no real differential for these types of programs, and has no good interface to the operating system.
ideally we would be using some form of scheme in the browser, which can be optimized much further than javascript, and transformed into any sort of mini-language that you want. Something OO for games or spreadsheet apps, something functional for a reactive interface, some logic programming for the model layer. Alas this is not the case, so the last place you see programmers using lisp is scripting their editor, or with the jvm. when hadoop and emacs get replaced, you will probably never see it at all.
Name:
Anonymous2012-10-06 2:23
>>13
Haskell | Lisp
---------------------------------|----------------------------------------------
zip l1 l2 | map list l1 l2
zip3 l1 l2 l3 | map list l1 l2 l3
zip4 l1 l2 l3 l4 | map list l1 l2 l3 l4
zip5 l1 l2 l3 l4 l5 | map list l1 l2 l3 l4 l5
zip6 l1 l2 l3 l4 l5 l6 | map list l1 l2 l3 l4 l5 l6
zip7 l1 l2 l3 l4 l5 l6 l7 | map list l1 l2 l3 l4 l5 l6 l7
N/A | map list . ls
map f l | map f l
zipWith f l1 l2 | map f l1 l2
zipWith3 f l1 l2 l3 | map f l1 l2 l3
zipWith4 f l1 l2 l3 l4 | map f l1 l2 l3 l4
zipWith5 f l1 l2 l3 l4 l5 | map f l1 l2 l3 l4 l5
zipWith6 f l1 l2 l3 l4 l5 l6 | map f l1 l2 l3 l4 l5 l6
zipWith7 f l1 l2 l3 l4 l5 l6 l7 | map f l1 l2 l3 l4 l5 l7
N/A | map f . ls
Everything you write will be open source. No FASLs, DLLs or EXEs. Developer may want to have control over the level of access to prevent exposure of internal implementation, as it may contain proprietary code or because strict interface/implementation decomposition is required.
Ever heard of .pyc?
Probably the biggest practical problem with Python is that there's no well-defined API that doesn't change. This make life easier for Guido and tough on everybody else. That's the real cause of Python's "version hell".
Also not an issue, e. g. in Debian you can install multiple Pythons (starting with the oldest supported version; on my day job it is 2.5, my personal shit is 2.6) and test your software on all of them plus PyPy. Sure, you won't be using any good new features, but it doesn't even annoy me, let alone prevent me from doing my work.
is believed to get in and around 60m/h in merely Several.6 http://www.cheaphollistersaless.com/womens-c-7.html seconds. 325i repairs Motors Symbol Of Benefit. BAYERISCHE MOTOREN WERKE (English tongue: BAVARIAN Vehicle Will continue to work), identified during http://www.cheaphollistersaless.com/abercrombie-footwears-c-10_15.html 1916, is commonly German born assembly company that provides for Car, Off road bike & Generator. It is really the father or just sister service provider about Rolls-Royce. All the motor bikes, according to the well-known name from 325i repair Motorrad & Husqvarna organizations, are made by simply 325i repair. In the past Mercedes was indeed into company of manufacturing aircraft vehicle, but nonetheless , rapidly shortly afterwards the globe struggle-I, another http://www.cheaphollistersaless.com/abercrombie-hollister-mens-tees-c-17_28.html treaty was indeed authorized & with the result that 325i repair was not allowed to supply the main.
it. If you're able to, try to discover over the car report. Receive sime good of your respective truck help criminal records to actually discover slightly http://www.mensonitsukatiger.com/buy-asics-gelvirage-4-c15.html towards the car the historical past. Selling Second-hand New or used cars Hoping to sell an individual's elderly car or truck can http://www.mensonitsukatiger.com/buy-asics-gelvirage-4-c15.html show extremely tough plus time-consuming. A lot of people who exactly tries to put up for sale a person's car generally obtains sick all of which certainly trade the application of or simply market it inside of a low price. Look into recommendations on http://www.mensonitsukatiger.com/buy-asics-gelstratus-21-c14.html providing a used car to receive the hottest.
portions for your completely new suv and receive extra features whilst marked down florida sales tax. Our GMC Downtown indiana translates into exceptional swap worth just for pre had automobiles, effectiveness & serenity closer to cherished consumer. http://www.newuniformsus.com/nike-st-louis-rams-c-66_98.html All of the GMC auto dealer Indiana offers a very close private make contact with head to vendors convey .. The most important good GMC dealer on Indiana is definitely the facility program weight reduction program experts. The main service plan consultants with regard to http://www.newuniformsus.com/atlanta-falcons-c-20_49.html GMC dealer are undoubtedly manufacturing http://www.newuniformsus.com/new-england-patriots-c-20_46.html facility tutored and.
I skimmed documentation of Python after people told me it was fundamentally similar to Lisp. My conclusion is that that is not so. When you start Lisp, it does `read', `eval', and `print', all of which are missing in Python.
>>13
>> lisp is good for making extremely powerful abstractions. these
>> abstractions are good in big programs. The world is moving
>> away from big programs, to small services that talk to each
>> other over the network.
That is an interesting observation and I think it is true. There are a lot of libraries focused on swarms of programs communicating with each other. Python is not very well suited for this purpose. Concurrency seems to be broken on various platforms. At least in 3<.
What I actually would like, is a programming language with native message passing support, serialize-able data structures and high level socket support ala ZeroMQ.
A programmer should be able to simply replace function application with message passing. He should actually not even be concerned with the difference. The runtime system should handle this. It should know, which players are on the network and what their capabilities are.
I don't see python do this kind of thing, it doesn't even get concurrency right. Lisp is more mature. It's community is more mature and more academic.
Name:
Anonymous2012-12-15 12:27
>>36
Probably Erlang. Too bad it sucks at strings and hashes/records though.
In before people saying it has to be slow because it looks like Ruby
Name:
Anonymous2012-12-15 14:19
>>36 It should know, which players are on the network
umena global consensus on cluster state mechanism built into language. not realistic. Lisp
i didn't see this buzzword is going to pop out >>37 it sucks at strings and hashes/records
nope it's not.
it does suck at whole bunch of more important things
unityping. in absence of oop support (module extension, parametric module style calls are banned (for good reasons)) this sometimes present big problems. dialyzer is (still, after ~10 years of development (kostis is a hell of a slacker)) broken beyond practical value. not mentioning that it requires (just) 20 minutes of processors time for a small project.
no metaprogramming support - parse transformations are unusable.
being advertised as functional language its capabilities stop right at ``apply'' function.
puke-inducing syntax makes price of abstraction penalty too high. execution model also plays important role here.
speaking of which, just as yale implementation of haskell failed due to gc discrepancy of lisp and haskell, akka and several haskell endeavours failed to provide actors model in other languages. erlang remains unique in this aspect, sadly. >>39 Elixir
120% hipster shit
irrespective of your taste in languages you'll be more comfy with ruby.
.
gotta check golang, but is seems to be way too low-level.