General purpose always wins. Or should always win. Because in reality nobody has any idea what "the purpose" is in the grand scheme of things.
We need an ultra-general purpose language with good support for both OOP and FP, non-retarded type-system, decent performance, and a good "compile to readable JS" story... to unify this damn mess of "diversity" that forces us to over-specialize in narrow niches and drowns us in complexity.
(No, otoh, I don't think "general purpose" should mean "infinite power" or "maximum expressivity". There's are reason why we're not all using Common Lisp and Scala...)
Edit: Plus, you can pass your data structures out to Python or C for processing. And you can use a whole host of visualization tools.
I just dont see people with "software engineering" background taking any serious liking to it. So it creates DIVIDE between the "software engineering folks" (that want regular-looking-OOP-and-basic-FP architecting feature for APIs and stuff) and "data science folks" who just want to focus on the algorithms.
The litmus test for a "truly general purpose language" to me would be:
(1) write some algorithmic code in it (with not much concurrency and parallelism)
(2) write some (purposefully heavily overengineered) GUI or web-app (full-stack) code in it in a team of 3+ including at least one guy who's both really junior and another guy who's really sloppy
(3) write something making heavy use of networking, concurrency and parallelism
If all three feel EQUALLY natural in a language, than you've got a truly general purpose language. If not, look for something else.
And I know, people hate general purpose solutions just as much as they hate "expert generalist" people, and they have good reasons too, as we've all (or most) been burnt bad by contact with both such "solutions" and with such self-labeled people in the past. But just because we generally suck at "general purpose" doesn't mean we should stop trying!
> I just dont see people with "software engineering" background taking any serious liking to it.
I guess my point is that if you found Python general purpose enough, you'd likely find Julia general purpose enough too. If people with "software engineering background" take a serious liking to Python but not to Julia, then the reason probably isn't the language itself, but a combination of lack of popularity and a pre-conceived notion that the language is meant to be "scientific" not "general-purpose", that there aren't enough libraries, that the language might not survive, etc.
But it doesn't have to be that way. SQL is a domain specific language. Regex is a domain specific language. They take different API strategies: one goes for ubiquitous and standardized interfaces, the other goes for direct embedding. But they both prove that it's not necessary to write everything in a general purpose language.
There's nothing wrong with designing a language that is particularly good at data analysis, and which emphasises those features at the expense of others.
Swift is a general-purpose language, but I would say that its first purpose is for mobile development. (Or, at least, that's where it started.)
> Why would you use Swift as your new data science language when Julia was made for that purpose and Swift was not?
The author calls out Swift as being good because (1) TensorFlow is now supported for it specifically and (2) it is optimized for mobile development. The author seems to feel that being able to deploy machine learning applications to mobile devices (and optimized) is a great boon, and Python is not well-suited to this.
Anyway, it's not hard to get used to.
And honestly, it's because I do numerical programming that I value zero-based offsets. In addition to subscripting arrays (which I could do in any base), I use those subscripts in the math itself. For instance, the zeroth bin of an FFT indicates the zero frequency. I also choose the zeroth array element to represent the constant term (zeroth power) of a polynomial, and so on.
The common places where math notation uses 1-based subscripts (matrix notation) have more to do with people saying "first", "second", etc... With a few exceptions (the Hilbert matrix comes to mind), the base of the subscript isn't actually relevant to the math itself.
I do appreciate that zero is easier because of offset caluculations, but you really do get used to it and in most cases the compiler figures it out with almost no penalty.
What formulas do you regularly use which benefit from being 1-based? Note, I'm not asking for instances where the index doesn't really matter and the author of a paper simply chose base-1.
There are clearly cases where zero based is more natural. But I don't regularly use any cases where one based is an improvement.
I will admit that zero-based adds a lot of confusion when communicating to other people.
Funny how I always thought zero-based numbering was a hack. Just in computer science a hack will become the right way? Any other fields where hacks became the new norm due to technical restrictions?
Your statement is a opinion.
To add to the list of languages using arrays in a "gross" way: pgsql, pascal, lua.
Because of this, I figure any language that supports 1-indexing should also support arbitrary ranges for the indexing, like in Ada. (Basically, what's so special about 1?)
At age 0, you have no elements in your array of years. So the first year is also element 1.
If you want code to reflect the way you've done counting and arithmetic your whole life, you'd want it to start at 1.
Which to me is one step away from using the timepoint as the index iteself (zero as start), verus (1 year from zero).
How would you index the time before the first birthday?
Yeah, that's why put a smiley there. :-)
$[ = 1;
$| = 1;
Personally, I’m not aware of the ability to write mobile apps in Julia.
If I’m wrong, please post links, as that would certainly open up the conversation.
Machine/Deep Learning are not some novel application, we've been multiplying matrices since forever.
If you are starting with Python definitely start with Python 3 and you are future safe...
In Fortran, you can write linear algebra on n-dimensional arrays (similar as in numpy and julia) very compactly, i.e.
d(i) = TRANSPOSE(MATMUL(B(i,:),c))
But it get's more interesting. Think of tensor contractions. This is something where you probably want to implement your own algebra (say for relativistic quantum mechanics or for general relativity) -- or you just stick to the n-dimensional array again and use index-wise loops:
A(i,j) = B(k,l)*C(i,k)*D(l,j) ! note: compe up with better examples
Believe it or not: Many scientists are no good programmers. Cut-down domain specific languages are perfect to avoid them to loose time on weird compiler features such as "const", templates and all that overhead which is hard to regain in time.
Do you ? I've used Eigen and boost a lot of times and didn't ever need to "learn how the sausage is made", just looking at examples is enough to get stuff to work.
In contrast, domain specific languages have exclusive support for certain data types built right into the heart. There is a need for that.
Why on earth should data scientists ditch the IPython/Jupyter/SciPy/etc. ecosystem?
Obviously he may be wrong, but it’s certainly reasonable prediction.
"7. Performance closer to C" is a non-issue - all the parts where performance matters are going to run on CUDA anyway and there's no performance hit there, and very little computing time is spent in the actual python code.
Honestly, as someone who wrote matlab professionally for a couple years, the price is a joke, and the performance is jokier. The only reason that matlab still exists is that they use the same marketing tactics as drug dealers- it's free to universities, and super easy to use.
"I worked for Apple from July 2005 to January 2017, holding a number of different positions over the years" "This included managing the Developer Tools department, which was responsible for Swift Playgrounds for the iPad, Xcode, and Instruments, as well as compilers, debuggers, and related tools. In early 2017, I briefly ran the Tesla Autopilot team. We built a lot of great things, but Tesla wasn't the right fit for me."
Joined "Google Brain" in August 2017.
If it is so good at that, why are we waiting so long for expeditiousness on run-of-the-mill industry-standard non-specialized non-Apple linux machines?
So far, no Swift. :(
What’s required for data science is a healthy ecosystem of scientific computing tools. While js obviously isn’t as mature as python (anaconda stack + Jupiter, etc) or R (tidyverse etc) in this aspect, it has made great strides recently:
- observable notebooks
- simple-statistics / jstat
Furthermore, with tools like d3 + leaflet, js has very little competition when it comes to data visualiation.
A big thing holding js back is a mature library for data manipulation, hopefully this changes in the future (anybody know of any potential fills for this gap?).
I'm a big fan of Python, so I'm just curious what you mean here. Swift has a lot of great language features that Python lacks, in my opinion. (My first favorite: native option types. Second favorite: internal and external function parameter names. There are more, but these are my top two.)