The Julia Programming Language

Post by pron » Sat, Feb 18, 2012, 7:31 PM UTC

StefanKarpinski wrote: post #78

andrewcooke wrote: post #30

this is surprisingly complete for a relatively new(?) project. one notable restriction is that inheritance is only for interface, not implementation. also, can anyone find a sequence abstraction (like lists)? arrays seem to be fixed size and i don't see anything else apart from coroutines. am i missing something?! [perhaps not, if it's intended for numerical work. on reflection i am moving more and more towards gener…

pron is right: you can inherit behavior from abstract types and abstract types, unlike interfaces, can have code written to them. (In single-dispatch OO languages, you are in the strange situation that you can write code to interfaces if they are arguments but not if they are the receiver of a method; thus, you're in a situation where you can either dispatch on an interface or you can write code for it, but never bot…

Post by cscheid » Sat, Feb 18, 2012, 7:38 PM UTC

ced wrote: post #51

jfager wrote: post #11

Earlier quoted context omitted.

Matlab, Octave, Mathematica, and other mathematical programming environments use 1-based indexing, it's a well-established norm for the domain.

Does 1-based indexing have any advantage, beyond familiarity to scientists?

Post by muuh-gnu » Sat, Feb 18, 2012, 7:56 PM UTC

ViralBShah wrote: post #83

muuh-gnu wrote: post #75

Earlier quoted context omitted.

> he begin/end is due to Matlab Octave has solved this by allowing both matlab-style "end", as well as block-specific endings, like "endif", "endfunction", "endfor", etc. Having several end end end endings without any hint of what they are closing is one of the ugliest parts of matlab. Even though you are reimplementing this for compatibility reasons, it is rather sad that you chose to make this the default behaviour…

The language is still quite young and is certainly going to mature. Also, it is open source. So, please do not lose heart, not just yet. :-)

Post by andreasvc » Sat, Feb 18, 2012, 8:16 PM UTC

ViralBShah wrote: post #81

fijal wrote: post #39

Earlier quoted context omitted.

Python+numpy+scipy does work only if you actually don't write much python or at least not run much python. Otherwise it sucks

I wouldn't say that it sucks - that's way too strong. I am one of the authors of Circuitscape ( http://www.circuitscape.org ), which uses python+numpy+scipy. The community loves it, the fact that its python, open source, embeddable in other tools, etc. However, much of the code is written in a vectorized style for performance reasons, as is the case with many high level scientific computing languages. This leads to u…

Post by StefanKarpinski » Sat, Feb 18, 2012, 8:20 PM UTC

dkarl wrote: post #112

StefanKarpinski wrote: post #71

Earlier quoted context omitted.

I huge part of the goal here is to reduce the need for the "unholy mix of C, C++, fortran, matlab, octave, R and python routines" in both academic research work and machine learning / data science code in industrial settings. The whole project kicked off with me ranting about how I was sick of cobbling things together in six or seven different languages. So interop is a very, very high priority. We have pretty good C…

in any language where objects are boxed, it becomes very tricky. We're working on it, however Naive question (and I'll hold my tongue on my naive guesses): I understand why it is necessary to box user-defined types on the JVM, but why build this restriction into a new language that doesn't run on a restricted platform? Especially when performance and C interop are high priorities? Or perhaps I misunderstood, and your…