proj-plbook-plChSciLangs

Table of Contents for Programming Languages: a survey

Languages for scientific, numerical, or mathematical computation

MATLAB and Octave

Internals and implementations

Core data structures: todo

Number representations

Integers

Floating points todo

array representation

variable-length lists: todo

multidimensional arrays: todo

limits on sizes of the above

string representation

Representation of structures with fields

todo

R

features:

free tutorials:

books:

best practices and style guides:

libraries:

Retrospectives:

Opinions:

Opinionated comparisons:

Lists and tours of libraries:

Gotchas:

is.list(x) to test if an object is actually a vector." [65]

Types [72]:

R internals

Julia

Julia tutorials

Julia features

"

Julia retrospectives

Julia opinions

    Performance issues including long startup time and JIT lags
    Somewhat obscure syntax and problems with interoperability with other languages
    Poor text formatting facilities in the language and lack of good unit testing frameworks
    Unsafe interface to native APIs by default
    Unnecessarily complicated codebase and insufficient attention to bug fixing

Despite all this, I think the language can find its niche as an open-source alternative to MATLAB because its syntax might be appealing to MATLAB users. I doubt it can seriously challenge Python as the de-facto standard for numerical computing." [83]

"

lenticular 42 days ago [-]

It's extremely expressive. Notably, Julia is homoiconic, with full lisp-style macros. It also has multiple dispatch, which is a far more general technique that OO single-dispatch. This makes it very easy to define modular interfaces that work much like statically-typed type classes in Haskell. This allows you, for example, to define a custom matrix type for your bespoke sparse matrix layout and have it work seamlessly with existing linear algebra types.

I've done a lot of work in both Python with Scipy/Numpy, and Julia. Python is painfully inexpressive in comparison. Not only this, but Julia has excellent type inference. Combined with the JIT, this makes it very fast. Inner numerical loops can be nearly as fast as C/Fortran.

Expanding on the macro system, this has allowed things like libraries that give easy support for GPU programming, fast automatic differentiation, seamless Python interop, etc.

tombert 42 days ago [-]

I'm not sure how I feel about multi-dispatch...I've had a few headaches chasing down problems with multimethods in Clojure...I'd have to try using Julia full-time to see how it feels.

I was unaware that Julia was homoiconic...I'm somewhat of a Lisp fanboy so I might need to give the language another chance.

lenticular 42 days ago [-]

There's pretty big differences in usage between multimethods in Clojure and Julia. I've used both a decent amount. All functions in Julia are multimethods by default. If you don't use type annotations, a new method will be generated whenever you call the function with new argument types. This explicit type specialization is a very important part of why Julia can have such a consistently fast JIT despite its dynamicity.

Errors from missing or conflicting methods tend to not happen much in practice.

https://docs.julialang.org/en/v0.7.0/manual/methods/

nicoburns 42 days ago [-]

> If you don't use type annotations, a new method will be generated whenever you call the function with new argument types.

Damn. That's a pretty clever trade off between dynamic and static types.

vanderZwan 42 days ago [-]

I vaguely recall a talk by Stefan Karpinsky where he mentions meeting one of the big names in compiler land (working on V8 or something) and they said Julia's JIT is just a lazily evaluated AOT compiler, and as a result much simpler than the JITs typically seen in other languages.

tombert 42 days ago [-]

Forgive a bit of ignorance here, but that doesn't sound terribly different than overloading functions in C++. Am I way off on that?

KenoFischer? 42 days ago [-]

The difference is run-time (semantically) vs compile time. If you had overloading at runtime in C++, you wouldn't need virtual functions or any of the thousands of OO "patterns" (visitor, factory, etc.), that are working around the lack of this capability. " -- [103] todo digest this

"

kgwgk 42 days ago [-]

> Julia is homoiconic

It depends on what you understand by homoiconic:

https://stackoverflow.com/questions/31733766/in-what-sense-a...

eigenspace 42 days ago [-]

This is why the language creators usually avoid using the word 'homoiconic' because every time one uses that word there's a finite probability of being bogged down in an incredibly uninteresting semantic argument.

Instead, people prefer to say that julia code is just another (tree-like) data-structure in the language and it can be manipulated at runtime with functions or compile time with macros or at parse time with string macros and now with Cassette.jl[1] we can even manipulate the form of code that has already been written and shipped by other packages all with first class metaprogamming tools. It seems to me that even if Julia is not 'truly homoiconic', that we seem to get the touted benefits of homoiconicity to the point that it seems like an unimportant distinction.

[1] https://github.com/jrevels/Cassette.jl

Athas 41 days ago [-]

Then why not just say 'Julia has macros'? Lightly perusing the description of Julia's features, that seems like a clear way of expressing what it is.

(I also vaguely recall Julia describing its type system as "dependent" in way that goes against convention. Maybe they just liked controversy in the early days!)

eigenspace 41 days ago [-]

What I just said is why Julia people don’t tend to call it homoiconic or dependantly typed. It lead to so many semantic arguments that most just talk about actual features such as macros and various multiple dispatch features instead of using words like homoiconicity and dependant typing.

zem 41 days ago [-]

"macros" are unfortunately used by C and lisp to describe two different things, and both usages are as widely popular as their parent languages (i.e. very). "

-- [104] todo digest this

Julia opinionated comparisons

Julia Internals and implementations

Core data structures: todo

Links:

Number representations

Integers

Floating points todo

array representation

variable-length lists: todo

multidimensional arrays: todo

limits on sizes of the above

string representation

Representation of structures with fields

GENESIS

LabView

Mathematica

"symbolic manipulation and solving"

Simulink

"continuous-time dynamic systems"

Modelica

"mechanical, electrical, etc systems"

Verilog-AMS

"analog and mixed-signal electronics"

Esterel

"reactive control systems"

SBOL

"synthetic biology systems"

Church

http://v1.probmods.org/

WebPPL

http://probmods.org/