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.
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.
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.
iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex
restart prompt, then: choco install mingw
(no machine reboots, disclaimer: I work at MSR, nothing related to this)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.
[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 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.
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.)
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.
classes = (student.current_classes() for student in students)
good_grades = [c.grade for grade in classes if grade > 3.0]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 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:
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.
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?
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.
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 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.
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'd rather listen to a podcast going in-depth on that theme.