I've only started this particular episode, but the Talk Python to Me podcast is pretty stellar and has contributed a lot to my addiction to technical podcasts.
After years with Python, it's still a mystery to me how the same constructs are so intuitive and readable in Python (think it acceptable that they are less in C++, Java or javascript etc, even Ruby)
It might depend on your previous history. My development arc was C, Perl, Java, Ruby, Python with Javascript in parallel. Python is not particularly intuitive after 10 years of Ruby. Actually it's a mistery to me how people can like such a complicated language. However I got only customers using Python last year so I must make me like it at least a little. I keep thinking I could have been very unlucky and found some Java projects instead.
Yup. I'm with you. For my money, Ruby could fill exactly the space Python does and do it better...but Python has too much steam in its niche and Ruby got pigeon-holed as a web language; such is life.
The python one valued doc, robustness, readability and stability.
The ruby one loved cleverness, beautiful design and conventions.
Eventually they ended up meeting at the middle, but in the mean time, people got tired of :
- having the last monkey patch breaking their code
- having to try to understand the last crazy dsl somebody came up with
- having an incomplete out of data doc and no tests
- having gem install breaks on you randomly
- having to mess with rvm (still an issue though) which never seems to do quite what you want
Ruby is a good language, but it took too much type to come out of it's teen years, playing bold and teasing. Now it's too late.
JS is getting away with it, despite being way inferior to ruby, because it's the only language on the web platform and we are forced to use it. Ruby didn't have this chance.
It's just what you know, coming from the other direction I found Ruby ugly and plenty of warts of its own. But I'm aware this is just a subjective impression and they're broadly very similar.
But didn't Guido say that everything what could be backported was already backported?
> There are a small handful of backwards incompatibilities introduced by Tauthon.
How to understand this?
Anyway, something like this was expected to happen. I wonder if it wouldn't be better if Guido would not halt python 2 development and just let it evolve.
Yes, I know. The question is if this decision is correct, given that apparently a lot of people and companies just doesn't plan to switch no matter what.
Proper unicode handling, list comprehensions, generators, await & async, TSL 1.1 & 1.2 support, better namespace handling, better string interpolation, and better argument parsing are just a few of the things that you get.
Is there a feature that could entice these people? Or have they made up their minds?
List (and set,dict and generator) comprehensions and generators are available in python2. Await & async and unicode handling are nice improvements, but you could do both in python2 well enough if it was important to you. TSL support I don't use in python so I cannot comment on it. And I've honestly never found namespace handling or string interpolation a problem.
Is there a feature that could entice these people? Or have they made up their minds?
It's not practical to safely work with non-ASCII strings in Python 2. There are too many "arbitrarily mangle my string" functions available (both in the language proper and in libraries), and the only way to avoid them is constant vigilance, which doesn't scale.
No reason per se. Just that lots of people have lots of Python2 code and feel that Python3 doesn't offer anything interesting enough to make it worthwhile to go through the effort of porting their code.
Probably momentum? The only reason is if they are supporting an app that they don't want to move to 3. As a professional Python dev, I can see no other reason. All my new projects are in 3, and as far as I'm concerned, the debate was settled years ago (and there wasn't much of a debate anyway.
On most OSes, open a terminal and type 'python', and you get a python2 REPL. That's reason enough to write a lot of scripty admin / automation stuff in python2. And then if you need to extend that, it's easy to just continue on in python2. It's there, it works, it's stable, you don't have to maintain versions in case of security issues, the OS package does it for you.
To give another example, Ubuntu is moving towards Python 3 by default, the plan is to have it as the only pre-installed Python version by 18.04 LTS, which is only a year away.
https://www.python.org/dev/peps/pep-0394/#id16 It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2 .
You can also open a terminal and type 'python3', and get a Python 3 REPL.
I only learned recently that it's a compatibility decision that means that plain 'python' will always be Python 2. However, you're starting to see Python 3 distributed right alongside it in most recent distros.
I've recently had to start writing python professionally and I'm not super impressed. My previous python experience was writing small services and fixing others code. Now that I'm working on larger "apps" it feels like a 90's language with all the rough edges and warts. I'd rather being working in a language with better language services and tooling, but python has numpy and all these data viz libraries so whatcha gonna do? At least I get a little reprieve with TypeScript; never thought I'd be so happy to work with the node platform, but there you have it.
3.5 looks attractive but there are just fundamental issues with the lang and language services. It's a bit like lipstick o... Well, I'm not going to say it.
I'm wondering if the OP is referring at least partially to the state of Python packaging. There was an HN article just a couple weeks ago, I think, along these lines that may be contributing to the complaint.
It seems odd to me given that pip has improved rather dramatically over the last 1-2 years (at least on *nix), so perhaps you're right regarding typing.
Pycharm tries really hard to paper over the lack of static typing in Python. Variable/function refactoring works mostly, code completion is acceptable (especially if you're inside a specially supported-framework like Django) and sometimes it'll show up a type error before your tests fail, saving you the time it takes up setup the test db, run the tests etc...
I love Pycharm, and I think people who go without IDE support are masochists (I did it for a few years with Python, and I'm not going back) but it's not like the kind of tooling support you get from a proper statically typed language, where the IDE can do so much to help you.
And I say this as someone who's been full time in Python for years. It's a fun language to write, with a wonderful ecosystem, but it's not good enough when your codebase gets big or you need to do major refactoring.
>Pycharm tries really hard to paper over the lack of static typing in Python.
It does and IMO this is the wrong approach. I usually fire off a test and use that the push the code to the line I'm interested in, at which point I fire up IPython.embed().
That gives you perfect code completion, instant variable inspection (including instant docstring and code lookup) and the ability to execute and inspect on the fly.
You can then fairly easily copy and paste the lines you want back to the text editor.
IMO that's a step ahead of just having autocomplete in an IDE.
My main issue with Python is distribution. Oh, you're using it on Windows? No worries, just install matplotlib using pip. Oh wait, you need to install cygwin and a C compiler and for some weird reason it won't compile but no worries there is a website with Unofficial Windows Binaries for Python Extension Packages but it's still not working....
Numerical computations and plotting are also my prime use cases for Python. IMO it's the only real competition to Matlab in this area.
The problem you describe has been fixed with precompiled wheels. As long as projects make the effort to package them, there is no need for compilers now.
Don't know why this was downvoted. NB you need to upgrade your pip to the latest to use this if you are on Ubuntu LTS though. (But you are working in virtualenvs so this isn't a problem right?)
I think that Continuum Analytics does incredible work in this direction, so it is really possible to just do `conda install matplotlib` and install matplotlib on any distribution.
UNIX also not, since Sun decided it was a good idea to sell the SDK separately, thus leading some companies to sponsor the until then largely ignored GCC.
The *BSDs and GNU/Linux variants are the exception to this.
In any case, Visual C++ and the plain command line SDK are a download away.
Not with the default install, but it's a free download from microsoft if you want one (either as part of an IDE or as a standalone command line tool). An official native port of OpenSSH is in beta and should be ready to ship officially soon.
Might be an off-topic, but recently I learned that Windows does come with a C# compiler. It's included in the .NET runtime, which is installed by default nowadays. This might be useful if you're extremely lazy to install any language implementation. It is quite amazing since even Ubuntu doesn't ship a C/C++ compiler by default.
You type in 'sudo apt-get install build-essentials' and you have it. I don't what the process on Windows these days but you used to have to find visual studio install media, install it, and reboot two or three times.
I learned this when my boss was wringing his hands over an Excel job that was too complicated to do comfortably in VBA. I'm not allowed to install anything on the computers because I'm a flunky technician.
I started poking around the C:\Windows directory to see if there was something that I could use, and I found C:\Windows\Windows.NET\
"Wait a second - C# is .NET, right?"
A hundred lines of C# later, I had a solution for my boss where you drag the CSV onto the program and it spits out another CSV. I would've liked to have the ability to grab an Excel file, but that requires installing another library... can't do it.
It doesn't really matter when it comes to Python, for the most part. Most big packages now distribute wheels which include pre-compiled binaries. I.e. no need for a compilation toolchain on Python. It's been like this for a year or so, I think, and continuously getting better.
There has been tension between the Python and R community, but not at all with the developers, i.e. feather development by both R's Hadley Wickham and Wes McKinley. Python and R are great tools, but the Python community tends to call R garbage and believes that Python has over taken R which is actually not true. R has really grown and is still the number one Open Source language in the domain and I think R has more resources behind it than Python.
R has actually already surpassed Matlab. Now R has some funky sides to it (Which you don't need to use) and R also has many people who were not good at programming making horrible examples. It surprised me how functional R is and there is a lot of Scheme in the under belly. The tools and libraries are just getting better and better.
R in the past 4 years has really become amazing. I left Python for R and it has been an amazing ride for me with the Hadleyverse of libraries. Millions has been invested into R with Microsoft even making it a part of SQL Server and Azure after buying R Revolutions. The tools that have been coming out are amazing.
Julia has been a promise on the horizon which I haven't had need of. For my workflow R has been dead on pleasure to use and my data sets are not so large that I need it. I also could use R with Spark if that ever becomes an issue.
There isn't anything good about matplotlib that I can see. Maybe I'm just not smart enough to see what's nice about it -- but as someone who has to learn it rather than already indoctrinated into matlab style plotting -- it seems like a disaster ... I switched to bokeh and am so far much happier
Matplotlib's main API is pretty terrible. But it's just fine for the simple plots that scientists and engineers are often needing (e.g., just plot y vs. x). It's also pretty straightforward to get publication-quality plots. Bokeh can handle simple plotting and more complex visualizations, but it is aimed mostly at interactive visualizations rather than plotting for publication. For now, matplolib is the only real option for that in the Python world.
Matplotlib inherits most of its baggage from originally being meant to mimic Matlab plotting that many were then familiar with. As an aside, I find the pandas interface to plotting with matplotlib to generally be much easier to work with.
This. Where I work, a lot of the scientists use matlab. Transferring from that to matplotlib is relatively simple. Also, making publication quality graphics is what I use it for. If I want to make something interactive these days, I tend to just put it on the web...
I should clarify that my experience is pretty narrow in the python space. The comment was based on my (recent) experiences in the land of jupyter notebooks -- first using matplotlib and then switching to bokeh and finding the api to be more straightforward.
Conda people really understand how to distribute code. It is great except that it doesn't always come with the latest package versions. Some packages are a few years old, which sometimes troubles.
Interested to hear more specifics of the issues you have – "language services" isn't a term I've heard before.
My feeling is that the python language is still one of the nicest around. It takes quite a bit of practice before you get good at writing it though. Distribution etc is a bit rubbish, but you normally go through that pain once and then just leave it alone.
I've maintained technical debt ridden code for most of my career - initially in C#, Javascript, also doing PHP and Java. Python is the only language for which it was remotely bearable.
It has some warts (it is weakly typed in some respects) but the only languages that fix those warts have a pale shadow of Python's ecosystem and you typically cannot prototype as fast in them.
As for tooling, it's probably got the best REPL (IPython) of any language.
I had to work with Python a few times in the past year and I really have to agree. The lack of proper lambdas, closures, its reliance on mutable data structures and imperative idioms, and the useless distinction between statements and expressions makes it feel like somebody was trying to write a modern language but for some reason stopped halfway.
For example: you can't assign the result of an "if" statement. Why? Because it's a SyntaxError, no real reason. There is even an "ifExp" in the language grammar, but that's only for inline ifs.
You can't have statements in lambdas, and map and filter are "unpythonic". Yet everybody feels like list comprehensions are the best thing after sliced bread, despite being the same thing.
Closures are also clunky: you can define another named function inside a function and call it afterwards, and you can use functools.partials from the stdlib, but I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method.
Ultimately, to me it feels like this all hurts the composability of the idioms of the language. List comprehensions can be nested, but they feel clunky and they're in a syntactical wall garden. You can compose expressions, but not statements.
I extensively use closures in Python, particularly jit compiled closures with numba. I don't really have any problems with that, why do you say it's unpythonic?
I'm not saying they are, I don't think I've used the language enough to be able to tell what's pythonic and what's not. It's just that I think the language support could be better: why defining a function and calling it right after? That's what lambdas are for.
We prefer to have only one obvious way to do it. The more good techniques in existence, the less there's a clear sense of "Pythonic".
It's just a preference. Many tasks have more than one obvious way. But if you're asking to add a new feature, you should explain why it's worth the downside of adding yet another way to do it.
>For example: you can't assign the result of an "if" statement. Why? Because it's a SyntaxError, no real reason. There is even an "ifExp" in the language grammar, but that's only for inline ifs.
Do you mean something like a ternary operator? You can certainly do:
x='foo' if condition else 'bar'.
In fact you can even do multiple assigments:
(x,y) = ('foo1','foo2') if condition else ('foo3', 'foo4')
where 'Foo' may also be a function call.
>I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method.
There's a few pycon talks on "a single method class should not be a class" but I'd say that's the single responsibility principle at its purest along with the community needing to move to more lightweight structures like namedtuples.
Why do you need everything to be an expression? Sure, a variable lookup takes a nanosecond, but that's a small price to pay for readability.
The fact that Python has an if expression and a lambda expression, but they were intentionally, not accidentally limited to one line should indicate there are some benefits to the trade-off.
Yeah, I don't think you know python very well at all given your criticisms. The very first thing you criticize is "its reliance on mutable data structures"--uhh no, most data structures and types in python are immutable.
I'll at least agree I've met a lot of python snobs who say don't use the built in map/filter functions and things like that in favour of comprehensions, but that's hardly representative of the language.
And please. List comprehensions can be nested, just like every other language can be abused if you really want to try.
Most semi-primitive types in python is immutable, yes (int, float, char, str, and DateTime), but all of the collections are mutable (List, Dict, Set).
I'm sure there are immutable versions of those same data structures hidden somewhere in the standard library, but I haven't looked.
I did stumble upon pyrsistent (https://github.com/tobgu/pyrsistent) a while ago which does provide proper immutable (and persistent) data structures for python.
I usually treat them as immutable by using copy(x) or deepcopy(x) unless I'm writing a chunk of code that is explicitly building it from scratch and pushing it somewhere.
The other week I've learned a bit of Python history I didn't know about. After listening to Steve Pemberton's talk ([1]), guys in the audience with ties to CWI (Amsterdam uni) pointed out to me that the language he and his team were developing at CWI was the precursor of what came to be Python. Specifically, they did usability studies with non-developers (but still engineers) to come up with ABC/Python's syntax (see the linked talk). So I guess that's something to keep in mind when comparing Python to functional programming languages/idioms. Another language coming out of this line of thinking and generation of programming languages, for me, is AppleTalk (or was it AppleScript?), so it could've become much worse I guess.
Minor detail, but CWI (Centrum Wiskunde & Informatica - Centre for Mathematics and Computer Science) isn't a Dutch university. It is a national research institute, and part of the Dutch organization for scientific research NWO. Many members of the research staff teach at a Dutch university though.
I know Python since the 1.6 version, could never convince myself to use it for anything else other than plain scripts, specially when I can get better performance and overall workflows out of Lisp and ML derived languages, without having to rely on C.
Haskell and OCaml are also 90's languages. The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry. I do not even believe it is the best choice for teaching programming to children. It heavily mixes and conflates higher-level ideas like lambdas and list comprehensions with imperative programming and mutation (the assignment syntax "x=x+1" must be especially confusing to high-school kids). It also throws in "object-oriented programming" constructs into the mix too.
I first came across that as a school kid (in BASIC) and didn't find it confusing at all. I still find functional computing confusing - I mean to do something for the numbers 1 to 100 instead of for x = 1 to 100 you have to do some weird tail call recursion which if you are lucky the compiler then converts back to for x = 1 to 100 because that's how processors work efficiently.
I learnt BBC Basic before my high-school algebra and was certainly confused by the different meanings. Don't concern yourself with tail recursion if you are still learning FP, it's just an optimisation, nothing to do with semantics. Python doesn't have it and few people care. What do you want to do with the numbers 1..100? A for loop doesn't give me any hints, which is part of its problem.
Don't bother thinking about what the processor is doing. Just trust it to figure it out. Tell it what to do (which shouldn't involve "weird tail recursion" - rather you probably want to use "map" or similar), and let the runtime/processor do it for you. If and when it turns out to actually be too slowly, and you profile it and can't immediately see why, then you're allowed to worry about that kind of thing. Not before.
The syntax is trying to look friendly and familiar, but ultimately it's an abuse of a standard mathematical notation that has meant something else for hundreds of years. The original meaning, an equality relation, is still being taught to high-school children today, typically before python is forced upon them.
The human brain is very good at interpreting things in context and it's really trivial for even middle school kids to understand that `=` in math is different from `=` in programming.
Do you want an example of something that beginner programmers struggle with? Pointers.
But you still need a symbol for the equality operator, so not choosing "=" for that seems rather absurd. It's comparable to making the choice to use + for string concatenation and ++ for (numeric) addition.
Good god. If anything is "forced" upon high-school kids, it's algebra. (Maybe ask the average high schooler and see what they have to say about it.) I haven't heard of any schools that make Python mandatory though; where are these located?
They suffered from the VM rise of Java and CLR, finally we are circling back to AOT tooling and FP concepts are becoming mainstream so advocating them is easier nowadays.
Also these things take time, even C++, I saw recent presentations from BMW[1] and Sony[1] that only now in 2017 they are transitioning from C to C++11 (not C++14) for some specific embedded development.
> "x=x+1" must be especially confusing to high-school kids
I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet the high-school kid who thinks this says that 1=0.
Now, like the rest of us, high-school kids can get tripped up by assignment and its consequences. Functional programming offers us great tools to deal with that. But the 1=0 argument is not credible to your average procedural programmer who's been doing assignment since the age of fourteen, and is in full command of basic algebra. A much better argument would be that Haskell lets you take advantage of algebra as an analogy, and Python doesn't unless you're unusually disciplined.
I never said mutating a variable is confusing. I said repurposing the equality operator is potentially confusing, especially for children. Pascal used ":=" to mean assignment, long before Python existed.
BASIC used "=" for both assignment and equality tests long before Pascal existed and was more popular for teaching the youngest students even when Pascal was available, so I find the idea that the use of "=" for assignment is some kind of barrier that high school kids (or younger, even) are going to have a lot of problems with just as implausible as the idea that imperative mutation is such a problem.
It was before my time, but ALGOL used ":=" long before BASIC existed. The point is that academics have repeatedly not used "=" for assignment for successive new languages over many decades. Clearly they care, even if you do not.
Well yes, it's clear that repurposing '=' for assignment confuses or at least annoys many academics, no disputing that. But your earlier claim was that it confuses children, which it certainly does not. (Source: it didn't bother me in the slightest when I was learning Basic at age 11, or any of the other children I talked to about it.)
> the assignment syntax "x=x+1" must be especially confusing to high-school kids
It wasn't at all confusing to me as an elementary school kid in BASIC, so I doubt it. The variables = named boxes metaphor was a fairly standard part of the pedagogy.
Immutability is great, sure, but let's not pretend that imperative sequences of instructions aren't basic and common things humans have to deal with and quite natural.
I wasn't arguing against imperative semantics. I was trying to point out that Python abuses notation and conflates paradigms; and so perhaps may not be the best teaching language.
Both Haskell and OCaml make very good imperative languages, but are much more explicit about what's going on. Assignments are clear to see (using "<-") and one must explicitly declare a mutable reference, rather than the Python default of everything is mutable.
> The rise of Python at the expense of safer, typed, faster, more principled languages makes me very sad for the state of our industry
There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages.
I noticed that a lot of people who enjoy Go come from Ruby or Python. Go's type system is clearly antiquated and weak, but it's a straight upgrade from a dynamically typed language, which is why it's finding an audience with the Python/Ruby crowd.
"""There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages."""
This sounds like wishful thinking. (Your wish, apparently... certainly not mine. :-) I have seen no evidence that Python is on the way out. If I look at the languages asked for in HN's "Who's Hiring" thread, Python is #1. Even so, there are dynamically typed functional languages, like Clojure and Elixir, that are definitely on the way up.
Your post history seems to suggest you are heavily involved in Python. I'm not. I don't write Python, I don't write Go, I have no dog in this race. I'm just observing trends, like I've been doing for the 30+ years I've been in this industry.
And these past few years, I've observed enough hints that people are moving from Python and Ruby in droves. And also that no large projects would be started in either of these languages today. Python/Ruby are going to stay around forever, no doubt, but much more as a glue/infrastructure language to write scripts here and there (and TensorFlow might help Python stay relevant for a bit longer too).
"the assignment syntax "x=x+1" must be especially confusing to high-school kids"
Many other comments already discussing this, but I have to add this. I don't think that has ever confused more than a handful of high school students because you are almost certainly bringing an understanding of "=" that you acquired at a much higher level of math.
For a lot of students, "=" isn't even what you would consider the "equality" operator... it's the simplify operator. That is:
2 + 2 = ____
has, for them, One and Precisely One answer. (You know this to be true, because your brain has already supplied that answer, and you already know that "3 + 1" is not an acceptable thing to put in that blank, even if a later understanding swoops in to say "Well, yes it is..." You still first knew the One and Precisely One answer.) So it's not the "equality" operator for them.
(I will give this kudo to Common Core, it tries much harder to avoid grinding the "simplify" definition into children's heads than older curricula.)
I don't think they get much collision with the "simplify" operator while programming because the contexts are too different.
I'd also submit that the conception of mathematical statements existing timelessly in some abstract math space would be foreign to them, and it is not hard for them to develop the "intuition" that "x = x + 1" is simply a statement that "after" this statement x will be one greater.
The only people who have trouble with "x = x + 1" are mathematicians trained to a very particular formal level, where they understand the idea of equality more deeply than a high school student but still haven't noticed that operators and formalisms change between branches of math all the time and insisting on your precise definition of an operator hasn't yet inhibited you from understanding the branches of math that redefine it themselves. Granted, no branch of math uses a definition that looks like the imperative programming version (even mathematical formalizations of imperative programming tend not to use = for assignment from what I can recall), but it's still just one more definition in a constellation of definitions, not the uniquely odd one out. You're going to have a hard time with homotopy type theory if you insist on your conventional = definition, for instance.
In the UK, algebra is first introduced using the equality operator, often with pictures of weight scales and weights, which students are asked to balance. Then they are introduced to a concise notation for this, e.g.:
1 + x = 3
Simplification comes later; and it often involves moving terms from one side of the relation to the other, which isn't possible with an assignment operator.
I have no doubt that beginners soon learn any different meaning of "=" over time, but why reuse the operator in the first place? Is it really making it "easier" for the beginner? At least with BASIC the context switch was easier as it was strictly imperative. Python tries to mix in more declarative concepts.
The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?
"but why reuse the operator in the first place? Is it really making it "easier" for the beginner"
That's a different question than "Has it confused a whole lot of high school students?"
"The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?"
Assuming by "more important ones" you mean more important mathematical ones, that's extremely easy to answer: They can't and they haven't. Very few programming languages look anything like conventional mathematics. Most of the popular programming languages are wildly adhoc from a mathematical perspective. But while some mathematically-inclined folks consider that some sort of damning criticism, they must also address the fact that there are no known practically useful languages that are not at least partially adhoc. Haskell is the closest and the community is well-aware of the places where even it cuts substantial mathematical corners. However, the developing languages that don't cut mathematical corners are only useful on toy problems right now, with the occasional triumphant breakthrough on a very particular problem. It's hard to program in languages where successfully creating a "sort" algorithm is a modestly impressive feat.
Compared to the other wild liberties taken relative to conventional mathematics, rewriting two parallel horizontal lines to mean "assignment" is hardly even interesting... after all, assignment itself, as an operation embedded in time, isn't very "mathematical", requiring rather a lot of formal machinery to represent, and goodness help you if you try to formalize what a multi-core system is really doing. It's merely one of the more obvious deviations from math, but arguably the more numerous and profound subtle ones are much more important.
I see you are one of those people who can't stick to a topic for more than one message and constantly change the specific topic of conversation rather than engage in debate. Especially when my own message already carried the idea that Haskell and Python vary substantially in their mathematical content. Carry on then.
You brought Haskell into the debate (along with many other topics) and I didn't get the impression it was in a positive light, hence my reply.
There isn't really anything more to debate. Your position appears to be that such details are "uninteresting", even for an aspiring high-level language like Python, because there are harder problems to solve. I suspect many academics would disagree, which I infer from their language designs.
I respectively disagree. I use types for rapid prototyping. Often I write out the type signatures first, type-check the high-level compositions and then fill in the implementations later.
You say that like it's a bad thing. Python is a multi-paradigm language, allowing you to pick (or create) the idiom that is best suited for solving the problem at hand. It is not a straitjacket language that tells you how to think.
The use of "=" for assignment is only confusing if you are already used to using for equations, and even then it's only confusing for a very short time, since it's obvious that the two (assignment vs equations) are completely different things. Python is hardly the first language to use it, by the way; I got started with BASIC on a Commodore 16 which used X=X+1, before I even knew about equations.
In practice I do not see it being any more "multi-paradigm" than e.g. Haskell is. It just conflates the imperative and declarative subsets, meaning that a lambda is not really a lambda etc
I'd absolutely love to hear what language you're using that's superior and not a "90s language" then. Pretty sure most of the popular languages date back to then if not a decade or two earlier.
I find it especially amusing you cite typescript and the node ecosystem as superior. I've never seen such an unreliable and constantly changing ecosystem with dozens of frameworks and libraries ever in recent history.
Having used Scala I can't stand to go back to Python. Almost as lightweight (more lightweight in some places - case classes and "_ lambdas" are things I really missed in Python, though attrs maybe solves the first), but a whole lot safer, which makes it much easier to refactor, which makes it possible to maintain a much higher quality standard in a long-lived codebase.
And the whole library/build ecosystem works a lot better - partly the problem is harder for Python because many "python" libraries rely on native code (whereas JNI is relatively rare), but it seems there are still four or five different ways to build and package Python projects and to work at an organization with a large Python codebase you end up having to understand all of them. (Every few years I see a blog post on how the packaging problem is totally solved now, for real this time, but at this point I've stopped believing them).
Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited: every project uses the same source directory layout, every project uses the same release tag format, every project uses the same unit test layout, and so you can immediately jump into any project and be productive. When you want to run random code in your build process it has to be encapsulated as a plugin, which means a) any random logic in the build process is at least ordinary first-class code that goes through your normal code review process, has a versioning and release cycle, can be unit tested etc. b) the slight extra overhead means there's more likely to be one standard plugin for doing a thing, which again means there'll be a standardised source directory etc., rather than everyone integrating thrift or swagger or what-have-you into their build in an ad-hoc and slightly different way. c) often people decide that actually they can live without having function names be capitalised if the build was made on a Wednesday or whatever nonsense they wanted to do to the build, and put their business logic in code where it belongs instead.
Beyond that there's a working central repository where all the important libraries are (and it's one of the few ecosystems that actually enforces code signing of all published libraries), and also a free repository server that you can run on-premises (and that's a normal JVM app that runs like anything else in the ecosystem) and use for private publishing and/or to proxy remote repositories to make sure you will always be able to rebuild any previously successful build even if a remote repository goes down. The release plugin enforces good practices by default, e.g. you tag a release and rebuild from that release, ensuring you can always recreate any given release; you may build a -SNAPSHOT which depends on another -SNAPSHOT, which makes it lightweight to make a change to an upstream library and check that it has the right effect on your downstream application (and the first-class IDE integration dovetails very nicely with this), but releases are only allowed to depend on releases, which ensures they're reproducible and immutable. None of this should be hard, and I think other ecosystems are gradually getting it right, but Maven just seems to have managed to make all the right choices and avoid all the pitfalls. You don't hear as much about it as you do about, say, NPM, but I think that's at least partly because it rarely goes wrong, so a lot of the time it's invisible to developers.
>Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited
That, along with its horrible XML markup abortion, was exactly what I hated about it. Any behavior that was even moderately unusual was a monumental pain to implement.
Build scripts by their very nature need to be turing complete because the need for customization isn't rare enough.
>Beyond that there's a working central repository where all the important libraries are
Python got this 17 years ago, a good 4 years before maven even existed.
> Build scripts by their very nature need to be turing complete.
They really don't. The build process should be simple and the same for every project; any actual logic can go in first-class code, that's what it's for (whereas finding out that a file somehow wasn't built, or got substituted before being built, makes for an extremely unpleasant surprise when investigating an issue). I find Turing-complete build systems end up with an analogue of https://martinfowler.com/bliki/SnowflakeServer.html - the "snowflake build", where every module builds slightly differently.
I used Scala for a few years. I actually prefer python to it though. My reasons are:
1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size)
2) Django. Play is ok, but for web stuff I think Django does a little better job.
3) Ease to find help. Finding someone to write scala is hard. Usually means hire a Java or a Haskell guy and train them. Way more people know Python.
4) Easier to metaprogram. Sometimes, metaprogramming is awesome. Don't do it nonstop, but sometimes it is amazing. Reflection and macros and all of that exists, but it gets seriously awful to deal with.
5) Code readability. I read scala fine, but it can still take a while to parse a file to know what is going on. Trying to think through crazy scalaz or something can hurt your head, even if you get it.
6) No SBT
Now this is not to say all is perfect, things I do miss from Scala:
1) When you really do need high performance, you can get there without dropping to C.
2) Compile time checks catch many many errors. Really sucks if you write something in prod and get a ValueException at runtime. Obviously this means you missed a test, but a scala codebase with say 25% test coverage will be generally less likely to have runtime erors than a Python codebase with even 75% coverage.
3) IDE support. Mypy is a work in progress, but click though stuff still works a little bit better in Scala. Scala is not Java good at this though due to implicit magic, so this is becoming more of a wash.
> 1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size)
True, but 95%+ of the issues you'd catch with unit testing in Python you catch during compilation in Scala, and that can be an incremental compile rather than a full compile. So once you have a properly set up dev environment the feedback loop takes less than 2 seconds in practice, though the one-off setup to reach that point is a lot fiddlier than for Python.
> 2) Django. Play is ok, but for web stuff I think Django does a little better job.
Heh, I don't like either, I'm a huge fan of Wicket (the one time I had to use Django I wrapped it in a Wicket-like layer I called smoff, which I think might even still be out there). Django is too page/request-oriented for my liking, I think a component-oriented library leads to much better design when you're making actual UIs. For REST endpoints spray is the best thing I've ever used, in any language: having your route definition look more-or-less like a route definition but being regular code that you can refactor in all the regular ways is amazing, especially when you get to the point of wanting to use e.g. custom directives and you can just click through to the standard directives and they're just ordinary code that you can adapt the same way as any other code.
> 4) Easier to metaprogram. Sometimes, metaprogramming is awesome. Don't do it nonstop, but sometimes it is amazing. Reflection and macros and all of that exists, but it gets seriously awful to deal with.
I think if you can't do it with Shapeless it's probably not worth doing. The typeclass-derivation stuff is more boilerplate than it should be, but it does work well apart from that, and always leaves you with something more-or-less understandable. Whereas some of the Python metaclass tricks I've seen have just been completely crazy.
> 5) Code readability. I read scala fine, but it can still take a while to parse a file to know what is going on. Trying to think through crazy scalaz or something can hurt your head, even if you get it.
I think you have to remember to compare code that does the same amount, not code that's the same length. Like, sometimes there will be a 1-liner in Scala that I'll have to mentally expand out to 6 lines to understand - but in Python the same code would have been 6 lines in the first place. And I think there's a huge benefit to being able to see a whole class definition on a single page, so I'd rather have the "compressed" single-line version even if it takes slightly longer to read in isolation than the "expanded" six-line version.
> 6) No SBT
Agreed. Can't stand it, have no idea why it's popular. I just use maven.
> True, but 95%+ of the issues you'd catch with unit testing in Python you catch during compilation in Scala, and that can be an incremental compile rather than a full compile. So once you have a properly set up dev environment the feedback loop takes less than 2 seconds in practice, though the one-off setup to reach that point is a lot fiddlier than for Python.
Not sure I agree with either of those. Compiler catches different types of error compared to Unit tests. Lots of ways especially when dealing with external libs or APIs where compile can't catch anything.
> Django wicket etc
To each their own. I despise SPAs, and neither code them nor use them if I can help it. DRF is really good for rest endpoints though.
> Meta programming
meh, different levels of it. Look at using Django ORM for some queries, vs say Slick. Slick is a bit gross.
> 1 liner vs 6 liner
Meh. In practice, Python is very terse also. Java vs Scala is a big line of code difference. I have not found Scala vs Python is that different.
> especially when dealing with external libs or APIs where compile can't catch anything.
It can if those libraries/APIs are written to use types effectively. In the early days of Scala there weren't many native libraries that did so, but there's a pretty established native-to-Scala ecosystem these days.
> To each their own. I despise SPAs, and neither code them nor use them if I can help it.
Um, agreed, which is exactly why I love Wicket ? I think we must've misunderstood each other at some level.
> Meh. In practice, Python is very terse also. Java vs Scala is a big line of code difference. I have not found Scala vs Python is that different.
In a lot of code I agree, but I think the cases where you will see "crazy scalaz or something" are precisely those cases where those things save a fair few lines. If you can write it in a readable line of Python, that will usually translate directly into an equally readable line of Scala.
I've been programming python 15 or so years, and packaging seems very much a solved problem to me. I'm sorry its difficult for others, I just can't see the problem myself. I guess I understand them all at this point, and it all seems easy... pytest and tox is a dream. It's so quick, I can modify some code and switch to my test window, and I already have the results... It is not unrealistic to author several thousands of lines in a single day, its just so freeing to make a thought into code so quickly.
Only programming Scala for one year, and it has been so depressing that it is beginning to affect my mental health. Mostly around sbt -- inconsistent incremental compiler issues, having more than one sbt causes a lock file I can't avoid, and even if they succeed, I get corrupt class files, so down to the one... and then getting inconsistent coverage report results, running all of the tests all over again because the report is no longer accurate, sbt and scala compiler are so dog shit slow that I'm back to "making tea" and "making sandwich" time during the edit & test cycle. Waiting just two extra seconds can interrupt a flow, waiting 12 minutes and you've lost it entirely.
Having worked with 20 or so languages professionally, this is probably the least productive I've ever been in my career.
Scala seems mega-boss hard.. please tell me it gets better
Scala gets great, SBT stays awful. Avoid it if you can.
Once you get used to working with the type system you'll need tests a lot less - the cycle becomes edit/save/look at IDE "problems" tab, and that catches the overwhelming majority of issues, so you only resort to running the tests every couple of hours. It takes a while to make the transition though.
Love Python, but very happy to be writing Go instead now, to give one example of a post-90s language.
(Their intersection of uses isn't total, of course; Python's still got Go handily beat for numpy-ish stuff and interactive use. See Julia for a possibly-superior post-90s competitor in those areas, though I've only played with it.)
I would argue that Go is very much a 90s language. It has none of the benefits of a 21st century language, none of the (as yet mostly unknown) drawbacks of a 21st century language, and fixes the drawbacks of 90s languages that we've learned over the last 25 years.
This definitely should not be interpreted as a slight on Go, many people would very happily trade that lack of benefits to get that lack of drawbacks.
Yeah, Go is more of a "synthesis" language, trying to conservatively use proven-out techniques in a very refined, cohesive whole. To me it is still "post-90s"; see my response to zephyrfalcon for details. :)
But that's not to say it doesn't include good stuff.
I'd say support for lightweight threading, CSP (channels), structural typing, fully embracing first-class functions (crippled python lambda, anyone?), and a build-system integrated into the language rather than left to 3rd-party-tools are all distinctly post-90s features, for a mainstream language.
Also, gofmt is a huge boon. The Go community focuses on ecosystem and ergonomic human factors of development feels distinctly post-90s-lanauge to me.
Also, the 90s saw an intense, misguided focus on "object-oriented-programming", which Go completely, mercifully ditches. In that sense, it's post-90s. :)
(Well, OK, maybe OO-style programming is good for UIs -- thinking of stuff like iOS/Cocoa apis and Unity.)
I've made a living of Python since 2.4 and hitting the 3.6, here is my take on it:
The Python team does an incredible job at making the language evolve. This is a 20+ years old language, with billions of lines written in the world, and allowing a huge number of paradigms. It still matures, steals ideas, makes hard compromise on growth vs compat, etc. I know very few other techs that can even compare to this level of legacy/flexibility.
(Python-idea is a fantastic mailling list BTW. You learn a lot about programming, community management, Python and humans. It's very approachable, yet you read some very talented people. Sign up ! https://mail.python.org/mailman/listinfo/python-ideas)
Coding in 2.x is now a pain. You can't see that if you are stuck in 2.7. 3.X doesn't seems appealing because what it brings on the table is not shinny. But the hundreds of small fixes hugely add up, and the experience is not the same at all on any project that takes more than a few days.
The good things is, Python 3 won. Nobody starts a new project in 2.x, most important 3rd party libs are have been converted and legacy code is ported every day. Porting a big code base is not really hard (2to3, python-future and python-six do most of the work) and can take only a few hours if you know what you are doing. Which is nothing given Guido have us 15 years to do it.
Honestly I had more time porting from Django 1.5 to 1.9 and DRF 1 to 2.
Python 3.6 is a wonderful release and a bliss to use. pathlib, f-string, better error handling, absolute imports, diminished verbosity, transparent unicode support, stable asyncio, unpacking everywhere, improved windows support, wheels for so many things, subprocess pools, pip+venv included (although debians admin excluded them, grrrr)... Everytime you go back to an earlier version it feels clunky.
The problem is, there are very few tutorials showing you the current best practices. I still read plenty of .format(), os.path.join(), manual subprocess/threads handling, etc.
People are still complaining you can't provide a standalone Python program while nuikta have been compiling very well Python for years now. It's even yum/apt installable.
Whether you are in Python 2 or 3 though, the ecosystem makes it all.
I'm amazed at where I find Python these days. It's the official language for colleges in France, it's installed on Linux and Mac by default, on the raspi (en consequently a recommended language for all students in the UK). It's at Google, Facebook, Instagram, Apple, Disney/Pixar, Sony, the CNES, the NASA, Mozilla, Docker...
But also in very heterogeneous places. Blender uses it to script, but most GIS as well. I got clients from everywhere using it: mathematicians, physicists, geographers, sysadmin, bankers, big data analysts, deep learning researchers... In big and small ways.
Plus there are so many great 3rd party tools: requests, django, sqlalchemy, numpy, pendulum, begins, jupyter, httpie, faker, marshmallow, autobahn, crossbar, pew are fantastic.
On strengh of Python is that it's good a little script upt to big projects. but there is an enormous list of things to learn if you want to get out of the scripter mind set and start coding a big project.
I like to brag and say the best blog I know about Python is mine. But it's in french so you will have to take my word for it. Yet it has more than 300 articles about Python and covering at length stuff from decorators to metaclass and even a fat 8 parts manual on OOP. Maybe google translate can help.
I liked the bit where he said he underestimated the number of people and code using python 2.7. I often hear python 3.X has 99% penetration based on probably the same bogus metrics, like downloads from python.com. Then they go on to talk about how many exciting changes are being made to python 3. Some of us actually have work to do.
150 comments
[ 3.1 ms ] story [ 320 ms ] threadThe python one valued doc, robustness, readability and stability.
The ruby one loved cleverness, beautiful design and conventions.
Eventually they ended up meeting at the middle, but in the mean time, people got tired of :
- having the last monkey patch breaking their code
- having to try to understand the last crazy dsl somebody came up with
- having an incomplete out of data doc and no tests
- having gem install breaks on you randomly
- having to mess with rvm (still an issue though) which never seems to do quite what you want
Ruby is a good language, but it took too much type to come out of it's teen years, playing bold and teasing. Now it's too late.
JS is getting away with it, despite being way inferior to ruby, because it's the only language on the web platform and we are forced to use it. Ruby didn't have this chance.
https://github.com/naftaliharris/tauthon
> There are a small handful of backwards incompatibilities introduced by Tauthon.
How to understand this?
Anyway, something like this was expected to happen. I wonder if it wouldn't be better if Guido would not halt python 2 development and just let it evolve.
Is there a feature that could entice these people? Or have they made up their minds?
Is there a feature that could entice these people? Or have they made up their minds?
A working, stable, version of http://pyparallel.org/ would entice the hell out of me.
Speaking of speed, I hear 3.7 should finally be able to beat 2.7 for most benchmarks, which is pretty sweet.
https://wiki.ubuntu.com/Python
I only learned recently that it's a compatibility decision that means that plain 'python' will always be Python 2. However, you're starting to see Python 3 distributed right alongside it in most recent distros.
3.5 looks attractive but there are just fundamental issues with the lang and language services. It's a bit like lipstick o... Well, I'm not going to say it.
It seems odd to me given that pip has improved rather dramatically over the last 1-2 years (at least on *nix), so perhaps you're right regarding typing.
I love Pycharm, and I think people who go without IDE support are masochists (I did it for a few years with Python, and I'm not going back) but it's not like the kind of tooling support you get from a proper statically typed language, where the IDE can do so much to help you.
And I say this as someone who's been full time in Python for years. It's a fun language to write, with a wonderful ecosystem, but it's not good enough when your codebase gets big or you need to do major refactoring.
It does and IMO this is the wrong approach. I usually fire off a test and use that the push the code to the line I'm interested in, at which point I fire up IPython.embed().
That gives you perfect code completion, instant variable inspection (including instant docstring and code lookup) and the ability to execute and inspect on the fly.
You can then fairly easily copy and paste the lines you want back to the text editor.
IMO that's a step ahead of just having autocomplete in an IDE.
My main issue with Python is distribution. Oh, you're using it on Windows? No worries, just install matplotlib using pip. Oh wait, you need to install cygwin and a C compiler and for some weird reason it won't compile but no worries there is a website with Unofficial Windows Binaries for Python Extension Packages but it's still not working....
Numerical computations and plotting are also my prime use cases for Python. IMO it's the only real competition to Matlab in this area.
The *BSDs and GNU/Linux variants are the exception to this.
In any case, Visual C++ and the plain command line SDK are a download away.
Not with the default install, but it's a free download from microsoft if you want one (either as part of an IDE or as a standalone command line tool). An official native port of OpenSSH is in beta and should be ready to ship officially soon.
1) Go to visualstudio.com
2) click Downloads
if you want the full IDE:
3) choose between downloading free version of a trial of the professional version
if you just want the command line tools
3) scroll down until you find C++ Build Tools and download that
4) double click the file you just downloaded.
5) Done
Uninstall or upgrade is still a nightmare, but installing it on a PC which has never had it isn't bad.
I started poking around the C:\Windows directory to see if there was something that I could use, and I found C:\Windows\Windows.NET\
"Wait a second - C# is .NET, right?"
A hundred lines of C# later, I had a solution for my boss where you drag the CSV onto the program and it spits out another CSV. I would've liked to have the ability to grab an Excel file, but that requires installing another library... can't do it.
https://github.com/Microsoft/BashOnWindows
You can compile C++ in Visual Studio and build a binary for Linux with gcc.
What about Julia and R? I have never worked with them, I am just wondering that they are not mentioned.
http://r4stats.com/articles/popularity/
R has actually already surpassed Matlab. Now R has some funky sides to it (Which you don't need to use) and R also has many people who were not good at programming making horrible examples. It surprised me how functional R is and there is a lot of Scheme in the under belly. The tools and libraries are just getting better and better.
R in the past 4 years has really become amazing. I left Python for R and it has been an amazing ride for me with the Hadleyverse of libraries. Millions has been invested into R with Microsoft even making it a part of SQL Server and Azure after buying R Revolutions. The tools that have been coming out are amazing.
Julia has been a promise on the horizon which I haven't had need of. For my workflow R has been dead on pleasure to use and my data sets are not so large that I need it. I also could use R with Spark if that ever becomes an issue.
Matplotlib inherits most of its baggage from originally being meant to mimic Matlab plotting that many were then familiar with. As an aside, I find the pandas interface to plotting with matplotlib to generally be much easier to work with.
https://pypi.python.org/pypi/matplotlib
My feeling is that the python language is still one of the nicest around. It takes quite a bit of practice before you get good at writing it though. Distribution etc is a bit rubbish, but you normally go through that pain once and then just leave it alone.
I'd rather listen to a podcast going in-depth on that theme.
It has some warts (it is weakly typed in some respects) but the only languages that fix those warts have a pale shadow of Python's ecosystem and you typically cannot prototype as fast in them.
As for tooling, it's probably got the best REPL (IPython) of any language.
For example: you can't assign the result of an "if" statement. Why? Because it's a SyntaxError, no real reason. There is even an "ifExp" in the language grammar, but that's only for inline ifs.
You can't have statements in lambdas, and map and filter are "unpythonic". Yet everybody feels like list comprehensions are the best thing after sliced bread, despite being the same thing.
Closures are also clunky: you can define another named function inside a function and call it afterwards, and you can use functools.partials from the stdlib, but I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method.
Ultimately, to me it feels like this all hurts the composability of the idioms of the language. List comprehensions can be nested, but they feel clunky and they're in a syntactical wall garden. You can compose expressions, but not statements.
Documentation.
It's just a preference. Many tasks have more than one obvious way. But if you're asking to add a new feature, you should explain why it's worth the downside of adding yet another way to do it.
Do you mean something like a ternary operator? You can certainly do: x='foo' if condition else 'bar'.
In fact you can even do multiple assigments: (x,y) = ('foo1','foo2') if condition else ('foo3', 'foo4')
where 'Foo' may also be a function call.
>I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method.
There's a few pycon talks on "a single method class should not be a class" but I'd say that's the single responsibility principle at its purest along with the community needing to move to more lightweight structures like namedtuples.
Why do you need everything to be an expression? Sure, a variable lookup takes a nanosecond, but that's a small price to pay for readability.
The fact that Python has an if expression and a lambda expression, but they were intentionally, not accidentally limited to one line should indicate there are some benefits to the trade-off.
I'll at least agree I've met a lot of python snobs who say don't use the built in map/filter functions and things like that in favour of comprehensions, but that's hardly representative of the language.
And please. List comprehensions can be nested, just like every other language can be abused if you really want to try.
I'm sure there are immutable versions of those same data structures hidden somewhere in the standard library, but I haven't looked.
I did stumble upon pyrsistent (https://github.com/tobgu/pyrsistent) a while ago which does provide proper immutable (and persistent) data structures for python.
[1]: https://www.youtube.com/playlist?list=PLQpqh98e9RgUcEmbXmI6R...
Edit: obligatory "what were they smoking" responses aside, anybody to chime in and complete/correct these early Python tidbits?
I've always heard this explained along the lines of "adds 1 to whatever x is, then puts that value into x, so x is one more than it was before".
The human brain is very good at interpreting things in context and it's really trivial for even middle school kids to understand that `=` in math is different from `=` in programming.
Do you want an example of something that beginner programmers struggle with? Pointers.
Also these things take time, even C++, I saw recent presentations from BMW[1] and Sony[1] that only now in 2017 they are transitioning from C to C++11 (not C++14) for some specific embedded development.
[1] - https://fosdem.org/2017/schedule/event/succes_failure_autono...
[2] - http://sched.co/9OOs
I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet the high-school kid who thinks this says that 1=0.
Now, like the rest of us, high-school kids can get tripped up by assignment and its consequences. Functional programming offers us great tools to deal with that. But the 1=0 argument is not credible to your average procedural programmer who's been doing assignment since the age of fourteen, and is in full command of basic algebra. A much better argument would be that Haskell lets you take advantage of algebra as an analogy, and Python doesn't unless you're unusually disciplined.
Edit: removed a word for grammar.
It wasn't at all confusing to me as an elementary school kid in BASIC, so I doubt it. The variables = named boxes metaphor was a fairly standard part of the pedagogy.
Immutability is great, sure, but let's not pretend that imperative sequences of instructions aren't basic and common things humans have to deal with and quite natural.
There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages.
I noticed that a lot of people who enjoy Go come from Ruby or Python. Go's type system is clearly antiquated and weak, but it's a straight upgrade from a dynamically typed language, which is why it's finding an audience with the Python/Ruby crowd.
This sounds like wishful thinking. (Your wish, apparently... certainly not mine. :-) I have seen no evidence that Python is on the way out. If I look at the languages asked for in HN's "Who's Hiring" thread, Python is #1. Even so, there are dynamically typed functional languages, like Clojure and Elixir, that are definitely on the way up.
Your post history seems to suggest you are heavily involved in Python. I'm not. I don't write Python, I don't write Go, I have no dog in this race. I'm just observing trends, like I've been doing for the 30+ years I've been in this industry.
And these past few years, I've observed enough hints that people are moving from Python and Ruby in droves. And also that no large projects would be started in either of these languages today. Python/Ruby are going to stay around forever, no doubt, but much more as a glue/infrastructure language to write scripts here and there (and TensorFlow might help Python stay relevant for a bit longer too).
Many other comments already discussing this, but I have to add this. I don't think that has ever confused more than a handful of high school students because you are almost certainly bringing an understanding of "=" that you acquired at a much higher level of math.
For a lot of students, "=" isn't even what you would consider the "equality" operator... it's the simplify operator. That is:
has, for them, One and Precisely One answer. (You know this to be true, because your brain has already supplied that answer, and you already know that "3 + 1" is not an acceptable thing to put in that blank, even if a later understanding swoops in to say "Well, yes it is..." You still first knew the One and Precisely One answer.) So it's not the "equality" operator for them.(I will give this kudo to Common Core, it tries much harder to avoid grinding the "simplify" definition into children's heads than older curricula.)
I don't think they get much collision with the "simplify" operator while programming because the contexts are too different.
I'd also submit that the conception of mathematical statements existing timelessly in some abstract math space would be foreign to them, and it is not hard for them to develop the "intuition" that "x = x + 1" is simply a statement that "after" this statement x will be one greater.
The only people who have trouble with "x = x + 1" are mathematicians trained to a very particular formal level, where they understand the idea of equality more deeply than a high school student but still haven't noticed that operators and formalisms change between branches of math all the time and insisting on your precise definition of an operator hasn't yet inhibited you from understanding the branches of math that redefine it themselves. Granted, no branch of math uses a definition that looks like the imperative programming version (even mathematical formalizations of imperative programming tend not to use = for assignment from what I can recall), but it's still just one more definition in a constellation of definitions, not the uniquely odd one out. You're going to have a hard time with homotopy type theory if you insist on your conventional = definition, for instance.
I have no doubt that beginners soon learn any different meaning of "=" over time, but why reuse the operator in the first place? Is it really making it "easier" for the beginner? At least with BASIC the context switch was easier as it was strictly imperative. Python tries to mix in more declarative concepts.
The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?
That's a different question than "Has it confused a whole lot of high school students?"
"The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?"
Assuming by "more important ones" you mean more important mathematical ones, that's extremely easy to answer: They can't and they haven't. Very few programming languages look anything like conventional mathematics. Most of the popular programming languages are wildly adhoc from a mathematical perspective. But while some mathematically-inclined folks consider that some sort of damning criticism, they must also address the fact that there are no known practically useful languages that are not at least partially adhoc. Haskell is the closest and the community is well-aware of the places where even it cuts substantial mathematical corners. However, the developing languages that don't cut mathematical corners are only useful on toy problems right now, with the occasional triumphant breakthrough on a very particular problem. It's hard to program in languages where successfully creating a "sort" algorithm is a modestly impressive feat.
Compared to the other wild liberties taken relative to conventional mathematics, rewriting two parallel horizontal lines to mean "assignment" is hardly even interesting... after all, assignment itself, as an operation embedded in time, isn't very "mathematical", requiring rather a lot of formal machinery to represent, and goodness help you if you try to formalize what a multi-core system is really doing. It's merely one of the more obvious deviations from math, but arguably the more numerous and profound subtle ones are much more important.
There isn't really anything more to debate. Your position appears to be that such details are "uninteresting", even for an aspiring high-level language like Python, because there are harder problems to solve. I suspect many academics would disagree, which I infer from their language designs.
Stronger type systems don't come for free. They come at the expense of slower prototyping.
The use of "=" for assignment is only confusing if you are already used to using for equations, and even then it's only confusing for a very short time, since it's obvious that the two (assignment vs equations) are completely different things. Python is hardly the first language to use it, by the way; I got started with BASIC on a Commodore 16 which used X=X+1, before I even knew about equations.
I find it especially amusing you cite typescript and the node ecosystem as superior. I've never seen such an unreliable and constantly changing ecosystem with dozens of frameworks and libraries ever in recent history.
And the whole library/build ecosystem works a lot better - partly the problem is harder for Python because many "python" libraries rely on native code (whereas JNI is relatively rare), but it seems there are still four or five different ways to build and package Python projects and to work at an organization with a large Python codebase you end up having to understand all of them. (Every few years I see a blog post on how the packaging problem is totally solved now, for real this time, but at this point I've stopped believing them).
Seriously? Maven was one of the things that made me run away screaming from the Java ecosystem.
Beyond that there's a working central repository where all the important libraries are (and it's one of the few ecosystems that actually enforces code signing of all published libraries), and also a free repository server that you can run on-premises (and that's a normal JVM app that runs like anything else in the ecosystem) and use for private publishing and/or to proxy remote repositories to make sure you will always be able to rebuild any previously successful build even if a remote repository goes down. The release plugin enforces good practices by default, e.g. you tag a release and rebuild from that release, ensuring you can always recreate any given release; you may build a -SNAPSHOT which depends on another -SNAPSHOT, which makes it lightweight to make a change to an upstream library and check that it has the right effect on your downstream application (and the first-class IDE integration dovetails very nicely with this), but releases are only allowed to depend on releases, which ensures they're reproducible and immutable. None of this should be hard, and I think other ecosystems are gradually getting it right, but Maven just seems to have managed to make all the right choices and avoid all the pitfalls. You don't hear as much about it as you do about, say, NPM, but I think that's at least partly because it rarely goes wrong, so a lot of the time it's invisible to developers.
That, along with its horrible XML markup abortion, was exactly what I hated about it. Any behavior that was even moderately unusual was a monumental pain to implement.
Build scripts by their very nature need to be turing complete because the need for customization isn't rare enough.
>Beyond that there's a working central repository where all the important libraries are
Python got this 17 years ago, a good 4 years before maven even existed.
It is not supposed to be Turing complete, for things that need that customization, as the GP stated, you use extensions.
For anyone who likes maven, checkout cargo in Rust. It got everything right, and made build extensions easier to integrate.
They really don't. The build process should be simple and the same for every project; any actual logic can go in first-class code, that's what it's for (whereas finding out that a file somehow wasn't built, or got substituted before being built, makes for an extremely unpleasant surprise when investigating an issue). I find Turing-complete build systems end up with an analogue of https://martinfowler.com/bliki/SnowflakeServer.html - the "snowflake build", where every module builds slightly differently.
1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size)
2) Django. Play is ok, but for web stuff I think Django does a little better job.
3) Ease to find help. Finding someone to write scala is hard. Usually means hire a Java or a Haskell guy and train them. Way more people know Python.
4) Easier to metaprogram. Sometimes, metaprogramming is awesome. Don't do it nonstop, but sometimes it is amazing. Reflection and macros and all of that exists, but it gets seriously awful to deal with.
5) Code readability. I read scala fine, but it can still take a while to parse a file to know what is going on. Trying to think through crazy scalaz or something can hurt your head, even if you get it.
6) No SBT
Now this is not to say all is perfect, things I do miss from Scala:
1) When you really do need high performance, you can get there without dropping to C.
2) Compile time checks catch many many errors. Really sucks if you write something in prod and get a ValueException at runtime. Obviously this means you missed a test, but a scala codebase with say 25% test coverage will be generally less likely to have runtime erors than a Python codebase with even 75% coverage.
3) IDE support. Mypy is a work in progress, but click though stuff still works a little bit better in Scala. Scala is not Java good at this though due to implicit magic, so this is becoming more of a wash.
True, but 95%+ of the issues you'd catch with unit testing in Python you catch during compilation in Scala, and that can be an incremental compile rather than a full compile. So once you have a properly set up dev environment the feedback loop takes less than 2 seconds in practice, though the one-off setup to reach that point is a lot fiddlier than for Python.
> 2) Django. Play is ok, but for web stuff I think Django does a little better job.
Heh, I don't like either, I'm a huge fan of Wicket (the one time I had to use Django I wrapped it in a Wicket-like layer I called smoff, which I think might even still be out there). Django is too page/request-oriented for my liking, I think a component-oriented library leads to much better design when you're making actual UIs. For REST endpoints spray is the best thing I've ever used, in any language: having your route definition look more-or-less like a route definition but being regular code that you can refactor in all the regular ways is amazing, especially when you get to the point of wanting to use e.g. custom directives and you can just click through to the standard directives and they're just ordinary code that you can adapt the same way as any other code.
> 4) Easier to metaprogram. Sometimes, metaprogramming is awesome. Don't do it nonstop, but sometimes it is amazing. Reflection and macros and all of that exists, but it gets seriously awful to deal with.
I think if you can't do it with Shapeless it's probably not worth doing. The typeclass-derivation stuff is more boilerplate than it should be, but it does work well apart from that, and always leaves you with something more-or-less understandable. Whereas some of the Python metaclass tricks I've seen have just been completely crazy.
> 5) Code readability. I read scala fine, but it can still take a while to parse a file to know what is going on. Trying to think through crazy scalaz or something can hurt your head, even if you get it.
I think you have to remember to compare code that does the same amount, not code that's the same length. Like, sometimes there will be a 1-liner in Scala that I'll have to mentally expand out to 6 lines to understand - but in Python the same code would have been 6 lines in the first place. And I think there's a huge benefit to being able to see a whole class definition on a single page, so I'd rather have the "compressed" single-line version even if it takes slightly longer to read in isolation than the "expanded" six-line version.
> 6) No SBT
Agreed. Can't stand it, have no idea why it's popular. I just use maven.
Not sure I agree with either of those. Compiler catches different types of error compared to Unit tests. Lots of ways especially when dealing with external libs or APIs where compile can't catch anything.
> Django wicket etc
To each their own. I despise SPAs, and neither code them nor use them if I can help it. DRF is really good for rest endpoints though.
> Meta programming
meh, different levels of it. Look at using Django ORM for some queries, vs say Slick. Slick is a bit gross.
> 1 liner vs 6 liner
Meh. In practice, Python is very terse also. Java vs Scala is a big line of code difference. I have not found Scala vs Python is that different.
It can if those libraries/APIs are written to use types effectively. In the early days of Scala there weren't many native libraries that did so, but there's a pretty established native-to-Scala ecosystem these days.
> To each their own. I despise SPAs, and neither code them nor use them if I can help it.
Um, agreed, which is exactly why I love Wicket ? I think we must've misunderstood each other at some level.
> Meh. In practice, Python is very terse also. Java vs Scala is a big line of code difference. I have not found Scala vs Python is that different.
In a lot of code I agree, but I think the cases where you will see "crazy scalaz or something" are precisely those cases where those things save a fair few lines. If you can write it in a readable line of Python, that will usually translate directly into an equally readable line of Scala.
Only programming Scala for one year, and it has been so depressing that it is beginning to affect my mental health. Mostly around sbt -- inconsistent incremental compiler issues, having more than one sbt causes a lock file I can't avoid, and even if they succeed, I get corrupt class files, so down to the one... and then getting inconsistent coverage report results, running all of the tests all over again because the report is no longer accurate, sbt and scala compiler are so dog shit slow that I'm back to "making tea" and "making sandwich" time during the edit & test cycle. Waiting just two extra seconds can interrupt a flow, waiting 12 minutes and you've lost it entirely.
Having worked with 20 or so languages professionally, this is probably the least productive I've ever been in my career.
Scala seems mega-boss hard.. please tell me it gets better
Once you get used to working with the type system you'll need tests a lot less - the cycle becomes edit/save/look at IDE "problems" tab, and that catches the overwhelming majority of issues, so you only resort to running the tests every couple of hours. It takes a while to make the transition though.
(Their intersection of uses isn't total, of course; Python's still got Go handily beat for numpy-ish stuff and interactive use. See Julia for a possibly-superior post-90s competitor in those areas, though I've only played with it.)
This definitely should not be interpreted as a slight on Go, many people would very happily trade that lack of benefits to get that lack of drawbacks.
[1] https://github.com/ksimka/go-is-not-good
But that's not to say it doesn't include good stuff.
I'd say support for lightweight threading, CSP (channels), structural typing, fully embracing first-class functions (crippled python lambda, anyone?), and a build-system integrated into the language rather than left to 3rd-party-tools are all distinctly post-90s features, for a mainstream language.
Also, gofmt is a huge boon. The Go community focuses on ecosystem and ergonomic human factors of development feels distinctly post-90s-lanauge to me.
Also, the 90s saw an intense, misguided focus on "object-oriented-programming", which Go completely, mercifully ditches. In that sense, it's post-90s. :)
(Well, OK, maybe OO-style programming is good for UIs -- thinking of stuff like iOS/Cocoa apis and Unity.)
https://talkpython.fm/100
Or directly here:
https://talkpython.fm/episodes/transcript/100/python-past-pr...
The Python team does an incredible job at making the language evolve. This is a 20+ years old language, with billions of lines written in the world, and allowing a huge number of paradigms. It still matures, steals ideas, makes hard compromise on growth vs compat, etc. I know very few other techs that can even compare to this level of legacy/flexibility.
E.G: the current debate on the mailling list about the "delayed" keyword: https://mail.python.org/pipermail/python-ideas/2017-February...
(Python-idea is a fantastic mailling list BTW. You learn a lot about programming, community management, Python and humans. It's very approachable, yet you read some very talented people. Sign up ! https://mail.python.org/mailman/listinfo/python-ideas)
Coding in 2.x is now a pain. You can't see that if you are stuck in 2.7. 3.X doesn't seems appealing because what it brings on the table is not shinny. But the hundreds of small fixes hugely add up, and the experience is not the same at all on any project that takes more than a few days.
The good things is, Python 3 won. Nobody starts a new project in 2.x, most important 3rd party libs are have been converted and legacy code is ported every day. Porting a big code base is not really hard (2to3, python-future and python-six do most of the work) and can take only a few hours if you know what you are doing. Which is nothing given Guido have us 15 years to do it.
Honestly I had more time porting from Django 1.5 to 1.9 and DRF 1 to 2.
Python 3.6 is a wonderful release and a bliss to use. pathlib, f-string, better error handling, absolute imports, diminished verbosity, transparent unicode support, stable asyncio, unpacking everywhere, improved windows support, wheels for so many things, subprocess pools, pip+venv included (although debians admin excluded them, grrrr)... Everytime you go back to an earlier version it feels clunky.
The problem is, there are very few tutorials showing you the current best practices. I still read plenty of .format(), os.path.join(), manual subprocess/threads handling, etc.
People are still complaining you can't provide a standalone Python program while nuikta have been compiling very well Python for years now. It's even yum/apt installable.
Whether you are in Python 2 or 3 though, the ecosystem makes it all.
I'm amazed at where I find Python these days. It's the official language for colleges in France, it's installed on Linux and Mac by default, on the raspi (en consequently a recommended language for all students in the UK). It's at Google, Facebook, Instagram, Apple, Disney/Pixar, Sony, the CNES, the NASA, Mozilla, Docker...
But also in very heterogeneous places. Blender uses it to script, but most GIS as well. I got clients from everywhere using it: mathematicians, physicists, geographers, sysadmin, bankers, big data analysts, deep learning researchers... In big and small ways.
Plus there are so many great 3rd party tools: requests, django, sqlalchemy, numpy, pendulum, begins, jupyter, httpie, faker, marshmallow, autobahn, crossbar, pew are fantastic.
But how do you discover those ? The ecosystem is so huge, even curated lists such as https://github.com/vinta/awesome-python are intimidating.
On strengh of Python is that it's good a little script upt to big projects. but there is an enormous list of things to learn if you want to get out of the scripter mind set and start coding a big project.
- virtualenv. Wait virtualenvwrapper ? Wait pew ? wait pip ? wait conda ?
- t...
As someone looking to expand from simple Python scripts to serious Python projects, this is my primary issue. Do you have any recommendations?
Edit: NSFW!