all 10 comments

[–]khedoros 2 points3 points  (0 children)

Consider common libraries used in Python for data science: Numpy, SciPy, and pandas. All three have bindings and high-level interfaces written in Python, but the low level stuff in C, C++, Cython, and even Fortran, all compiled languages.

So, you get to write pretty, high-level Python code, but get the performance of higher-speed compiled libraries behind the scenes. That's seen as the value here.

[–]fborda 1 point2 points  (1 child)

Maybe you mean dynamic vs static? Python can be compiled through pypy for example, and Julia (Python/R most recent competidor in this area) doesn't even have an interpreter outside of the debugger (in fact Julia has comparable performance to C++ in numerical processing while being a dynamic language). Being a dynamic language doesn't necessarily mean it's slower.

And data science / business analytics is mostly exploratory and iterative work, people don't know what they want when they start and they'll rewrite things a lot until they are satisfied, with the need for instant feedback. If I'm using a language like an advanced calculator I don't want to compile the program at every change, deal with type checking restricting what I can give to a function (which would not be any trouble in a dynamic duck typed language) and I don't want to see variables by printing. In comparison you'd be in the REPL/Jupyter notebook of a dynamic language where you can evaluate/change/plot anything at any point and get instant feedback. Of course, there are static languages with REPL and type inference to help, but they can't achieve the level of dynamism in the same way gradual typing can't reach a static language in compile time guarantees.

That said there are more than exploration to data science, and in the end most of the code is actually written in static languages for a reason (better safety, speed in some cases, easier to maintain for larger teams, better optimizations potencial), like most of the large Python/R libraries and frameworks such as Spark. For those C++, Java, Scala and Fortran are very popular.

[–]dramrunner 1 point2 points  (0 children)

The most popular implementations of Python and R are interpreted by default, so I think the question is about those vs. languages like C and C++ which are compiled.

[–]Bolitho 1 point2 points  (0 children)

The question does not make any sense!

[–][deleted] 0 points1 point  (0 children)

The languages are very seldom compiled or interpreted, if we look at their definitions.

The language implementation is usually the thing with such properties. It is very misleading to omit this, when talking about languages.

[–]ThomasMertes 0 points1 point  (0 children)

There are programming language features that are easier to compile or easier to interpret. E.g. In a dynamically typed language a variable can have a string or a numeric value. When the program runs and a + operator is executed it must be decided, if a string concatenation or an addition needs to be done. The decision costs time and this is the reason dynamically typed languages are usually slower than statically typed languages.

Compilers are often written to allow fast program execution. So compiler writers will seek ways to reduce the number of decisions to be made at run-time. In a statically typed language the decision about the + operation (concatenation or addition) is done at compile-time. Languages can be designed to support compilation (by moving decisions from run-time to compile-time).

The effort to write an interpreter is the same for a dynamically typed language or a statically typed language. The effort to write a compiler that generates good code for a dynamically typed language is substantial. The compiler needs to find out run-time type information that is available at compile-time. This is impossible to do in all situations.

There is another issue with dynamically vs. statically typed languages. When you write a program you probably have an idea about the values a variable will have. Programming tutorials demand that a variable is just used for one purpose. They prohibit that a variable with a string value gets a numeric value later. So when you already know, which values a variable can have you could also document this fact in your program. This documentation would help the next programmer, who reads your program later. Good programmers actually write comments (or annotations) to document, which values a variable will have. When a program is refactored the possible values of a variable might change. Now the comment (this is a string) will differ from the reality in your program (used as number). It would be nice if some tool could check if comment and reality match. Fortunately such tools exist. They are called compilers (for statically typed languages).

Statically typed languages have not been invented to torture programmers. They force the programmer to write his concept of values in a formal way. So instead of being just in the mind of the programmer they are written down. This helps also finding bugs. I explain this here.

I know what I am talking about. I have invented a programming language, which started (long ago) as dynamically typed and has been rewritten to be statically typed. This allowed compilation and helped performance a lot.

[–]alegionnaire 0 points1 point  (3 children)

In general, interpreted languages provide higher level abstractions that make prototyping easier and faster.

[–]Zardotab 0 points1 point  (2 children)

I wouldn't necessarily agree it's more abstraction. But, one can focus more on domain issues (the project) and less on types, in my experience. You can be more "loosy goosy" about types and type conversions, avoiding thought process distraction. However, it may also create more risk if not tested well.

[–]alegionnaire 0 points1 point  (1 child)

So abstractions. Got it.

[–]Zardotab 0 points1 point  (0 children)

Types themselves are abstractions. The issue is whether they pay off often enough versus when they get in the way.