I Accidentally Some Machine Learning – My Story of a Month of Learning Elixir
fredwu.me
fredwu.me
After this, people are still wondering why developers earn $100,000+ salaries.
1) The language was created by a researcher (Guido Van Rossum) at a research facility in the Netherlands [1]
2) Network effect - as more machine learning researchers and engineers in academia used it, the need for a language that could integrate with FORTRAN with similar performance came about, which lead to NumPy, SciPy, etc.
3) The language itself is pretty simple to grasp. There's multiple ways in Ruby itself to do something, while in Python there's at most one way to do something. Anecdotal - a lot of researchers I've worked with care more about the usability and ease of adoption of a language, compared to the expressivity.
[1] https://en.wikipedia.org/wiki/Python_(programming_language)#...
To get specific, the wording in PEP 20 is: "there should be one, and preferably only one, obvious way to do it". Note that the dominant idea here is that there should exist some obvious way. It's merely preferable that there be only one way. Again: this is sensible, but it's not good fodder for newcomers craving purity, or for detractors craving straw men.
PEP 20 itself is often elevated to religious levels of importance, as if it were a design document that served as a blueprint for the design of Python. It's absolutely not that; it was written by Tim Peters (not Guido!) fully eight years after Python's first release. Here's the original email that Tim sent to comp.lang.python on 4 June, 1999: https://groups.google.com/d/msg/comp.lang.python/B_VxeTBClM0.... Note how he finishes: "If the answer to any Python design issue isn't obvious after reading those -- well, I just give up <wink>." Tim is very particular about his winks, and that's not even a <0.5 wink> or a <0.9 wink>, but a full, unqualified <wink>.
To put all of those pieces together: (1) we have a short, tongue-in-cheek document written after-the-fact. (2) It's misinterpreted as a design document for an entire language and ecosystem. (3) A secondary portion of one of its points is misinterpreted to be the entirety of the point. (4) This is done by exuberant newcomers and skeptical detractors who don't accurately represent the Python culture as a whole. This is why you get the impression that the community is adamant about "one way to do it". It's a reasonable extrapolation from the visible evidence, but it's not true.
1. perl has always prided itself that "there's more than one way to do it" including repeated, prominent use of an acronym for that. see timtowtdi.
2. there is a theoretical idea kicking around out there that, if a language allowed for only one way to express any idea, then that language would be a better language (all else being equal) because if you and I always write the same code for the same task, we could easily maintain each other's work. see for example "egoless programming" or the ideas that led to Simonyi's "metaprogramming" (whether or not you agree)
3. perl is a mess
therefore, it might, given the history, make sense to say that about python as a way of trying to point out a salient difference from perl
Ruby's big disadvantage is that until Rails happened, it was relatively unknown in the English-speaking tech community. And though it has begun to broaden its reach since then, Rails (and, by extension, web dev) so dominates the conversation in that community that many people unconsciously forget it's a general-purpose language and are often unaware that there are libraries out there for doing non-web work in Ruby.
Python's early advantage for scientific stuff was its relative simplicity and its easy integration with extensions written in compiled languages. Interpreted languages will probably never be fast enough on their own for scientific computing, but a high-level interpreted language as an interface to fast compiled C and Fortran is good enough to attract people and introduce network effects which turn a moderate advantage into a big one.
Why they chose Python, rather than Ruby or something else, probably has to do with timing. They were already working on this stuff before Ruby made any in-roads in the western world. And, once you've got a few hundred thousand lines of code, customers, and an OSS ecosystem based around what you've built, you don't drop it and move over to another language.
Python also happens to be well-suited for the task. SWIG support, for hooking into the ATLAS C++ libs, and there were reasonable ways to hook into the FORTRAN libraries, as well (and FORTRAN is the gold standard for performance in the scientific computing world, or it was back then). So, the technical side of Python was pretty well-suited to the task, even early on. The fact that Python was beginning to show up in universities computer science programs probably helped with adoption, too, though back in the early days the people using Python for scientific computing often had to also spend time and effort on training their customers how to use Python, so it wasn't an easy path (they were facing off against Java using competitors who had a bit of a lead in the move away from FORTRAN and C++ in the industries where they work).
That said, before Python, there was a pretty large contingent of scientists using Perl, for a lot of the same technical reasons; and there still are in some fields. Biology and finance still have pretty big Perl presence in industry. So, again, it wasn't inevitable that Python would be the leader. It just happens that the people who work in those spaces wanted to use Python and built a ton of great tools for doing it. At some point, it becomes a no-brainer because the inertia of the ecosystem does so much of the work for you. So, people without strong opinions on language, but need to do this work will flock to the obvious choice, which is now Python.
I guess one could ask, "Why didn't Python take off as a web development language? Why did PHP first, and then Ruby, own so much of that market for so long?" Again, probably because of inertia plus some early movers who built valuable resources for the language, making it the easy choice for people without strong opinions. Scientific computing is a much smaller market, with a lot less room for a bunch of players to be "leaders", I think. So, even though web development has several strong ecosystems in many languages, I doubt scientific computing could be that disbursed and still be as effective.
Edit: Also Google. Google likes Python, and Google likes machine learning. And, with the already excellent scientific computing ecosystem (SciPy, NumPy, Jupyter/iPython), Tensor Flow was an easy fit.
Nice learning :)
- Switching from =~ to Regex.match? did not yield significant speed improvement
- Without any changes though, 2.4.0-preview1 ran the stemming in 19s, compared to the 25s on 2.3.1.
The ruby stemmer I used is this one: https://github.com/NeilNjae/porter2stemmer
[1] http://de.urbandictionary.com/define.php?term=Accidentally
"I accidentally 93MB of .rar files” and the rest is history.
Sometimes typos lead to memes.
it's also a monster at processing binary data streams via pattern matching.
It all depends.
The BEAM GC each process isolately, which means that if a process die before a GC is needed, the BEAM just clean the whole process memory. No need for a GC.
That is what happens most of the time.
http://www.techempower.com/benchmarks/#section=data-r12&hw=p...
I have no idea how well the implementations are on each of these or how well each platform works within the constraints of this benchmark.
"They were testing JSON benchmarks through the :browser pipeline, complete with crsf token generation. They had a dev DB pool size of 10, where other frameworks were given of pool size of 100. And they also had heavy IO logging, where other frameworks did no logging. We sent a PR to address these issues, and I was hoping to see true results in the latest runs, but no preview was provided this time and we weren't able to work with them on the errors."