Hi,
Recently I made a graphic, plotting code length vs speed from the Julia
benchmarks and I was surprised how strongly it favors Julia:
<https://lh3.googleusercontent.com/-7IPcrjXuxFY/VICwQ3TrgRI/AAAAAAAAJV0/_HmDWZiBrXQ/s1600/benchmarks.png>
<https://lh3.googleusercontent.com/-7IPcrjXuxFY/VICwQ3TrgRI/AAAAAAAAJV0/_HmDWZiBrXQ/s1600/benchmarks.png>
(I removed comments, newlines an normalized the length. For the speed I
simply took the average of the benchmarks. Fortran has some weirdly high
values in the csv on JuliaLang though.)
Well using code length as a metric is a difficult issue, but I was happy
about the nice, empty area around Julia ;)
This could be strongly biased though, maybe someone with more knowledge
about the benchmarks can immediately point out, that Julia is simply the
most polished one.
Am Donnerstag, 4. Dezember 2014 19:12:24 UTC+1 schrieb Páll Haraldsson:
>
>
> Hi,
>
> This is my first post here and since I've gotten your attention, my
> answer: Julia is (or seems to be) good at "everything".[*] But I'm just not
> sure.. [You could stop reading here.]
>
> I think Julia could be the last language people need to learn (and should
> be the first).[*] Maybe I'm being incredibly naive thinking no *better*
> language will come along and I need to qualify that[*] but it seems people
> here, when saying the Wired article has it wrong (e.g. Bezanson), are being
> modest (or know better than I do). Maybe I just do not have enough
> perspective on languages/paradigms out there. I'm probably ignorant on
> (new) language/paradigm research..
>
> Is Julia ready for prime time (0.3.3 considered stable)? I see some talk
> of breaking changes ("Array nirvana" and "staged functions" (for C++) will
> they break anything?). I already recommend Julia for technical computing
> (quant/financial) at least (to learn/try); there may be issues (especially
> for those doing non-technical) - for now. That seems to be changing fast.
>
> I would be preaching to the choir saying Julia is great for its target
> audience. But why do you just want to unify all of technical computing in
> one language and not all of computing? "A fresh approach to technical
> computing" might stop other people from considering Julia. I guess it's
> good to have a niche but I hope other people do not get scared away.
>
> What is needed is to support all the important platforms so that people
> will not overlook Julia as "it doesn't support my work or run on my
> platform". This means the web (JavaScript as an "assembly language"
> target), Android (and iOS..).
>
>
> At least Bezanson seems to like (love?) Scheme ("femtolisp"). I wander if
> Scheme/Lisp (or any language) is *clearly* better than Julia for anything?
> Or would he stop using Scheme except to maintain Julia's core.. [Maybe
> femtolisp should be removed from Julia (e.g. to bootstrap Julia)..]
>
> While functional style is getting more popular, people seem to like
> imperative and Julia isn't either or. Can/should !-functions be enforced?
> It is only a recommendation?
>
> I know Lisp-syntax is "simple". Maybe non-infix notation is "better" in a
> language but only for the interpreter it seems; or in regular math, had it
> been used first/what people are used to. I and most people just don't see
> it. I wander if there is anything to this other than preference. The
> S-expressions that come with Lisp and infix, do they have an inherent
> advantage that Julia can't match? In other words, I think that means, are
> Julia's "Lisp-like" macros and its homoiconicity as powerful as Lisp's?
>
> As for the (linked) lists (L in Lisp), of course we need lists (and trees)
> sometimes and Julia has them, but as a basic data structure of a language,
> seems to me to be a performance killer. I do not see caches (locality of
> reference) going away any time soon..
>
>
> As all (Turing-complete) languages are equivalent in a sense, one can't be
> more "powerful" than another; "C can implement Lisp", but without that
> exception ("Greenspunning"), programming a new runtime, languages with real
> macros can be more powerful. I used to associate macros with Lisp, are
> there (m)any other "ALGOL-like"/non-S-expression/not-list-based languages
> with real macros? Is Julia a first? I understand macros are the key to
> Lisp's power and Lisp is said to be the most powerful language.
>
>
> In short is there any area where another language (which one and for what)
> would be (*clearly*) better (not just slightly, see my metric below)? Maybe
> I'm not asking the right people.. I can assume people here have language
> theory covered (the basic three (more?) categories including logic
> programming/Prolog) that I know (and, I guess, a deeper understanding than
> I do).
>
>
> If course which language (syntax) is best, is partly a value judgment;
> maybe somewhat a personal taste and objectively there may be no best
> language.
>
>
> People focus much on the speed of Julia. My metric is not (just) the
> speed. I see basically just that dimension (parallel is part of that) and
> then readability as important. And that means how short the programs can be
> (without getting cryptic). I could maybe go with programming fault rates as
> a third or safety/fault-tolerance (see Erlang or hard real-time) as some
> third/fourth metric but fault rate is stated as being (roughly) independent
> of lines of code. So let's just stick with how short you can make code
> (while keeping readability) as a metric. Is there a reason Lisp or Prolog
> (or Haskell or other language I know less about) should win that metric (by
> a non-trivial/low constant amount at least)? Are there likely to be (m)any
> as good available or better ones available in the future? While also being
> good on the speed metric? I would really like to know because I really know
> of no other language. Any candidates that are even about as good? OCaml and
> Racket come to mind, just not sure they can compete and win.
>
>
> Readability is maybe subjective and Perl and Haskell are not, at least to
> me.. Julia is, but maybe it's just my upbringing in imperative..
>
>
>
> * Caveats/possible doubts for some
>
> What I mean by "best language" is judging it on the language merits not
> based on any particular missing library for some specific use. [However, I
> would like to know where they need improving, especially for "non-technical
> use", to see how "practically best" Julia is and possibly improve the
> situation.] Imagine if other languages did not have a headstart. Given the
> library headstart, I also think Julia would be best since you can use
> (almost) any library you are likely to need right now. Are there important
> libraries/languages that can't be supported right now or theoretically. And
> how mature is the support for R, MATLAB (does it include Octave support?),
> Java and C++?
>
> You can call Java, meaning the JVM. Would it be impossible reuse Java code
> without the JVM or the other way to compile Julia (a executable or the
> whole environment) to Java (or CLR)? Is a C2Java available/possible? As
> Julia2C (and f2c) is available and assuming C2Java, couldn't Julia run in
> the JVM? Or in JavaScript (see Emscripten C2JavaScript compiler).
>
> Yes, you can't call all languages. It seems though, all that matter,
> except maybe Objective-C/Swift, C#, COBOL? and few others; which ones are
> not callable right now? Is CLR support in general possible or important?
>
>
> Parallel
>
> In the long run, supporting parallel and resulting speed seems to be what
> would make or break new languages and I just do not know what language
> could be best at parallel. Any theoretical reason to suspect another
> language than Julia? Auto-parallel would be nice; any reason another
> language could do better with auto-parallel than Julia? That is, did the
> developers shoot themselves in the foot, not doing pure functional (or lazy
> vs. eager)? Microsoft made some "breakthrough" recently so imperative
> languages are not (much?) worse off than pure functional. Anyone know more
> about this?
>
> I assume Julia has, at least non-parallel, speed covered. If not (for now)
> I assume it could at least never get slower than C than by some low
> constant factor (if not, it can call C anyway so not a big problem). I just
> trust the developers when they say that they can close the gap with C. And
> I assume C (for non-parallel) using restrict keyword can't really be beat
> by much speed-wise in any language. Assembly included. [Still, will Julia
> support assembly directly (or does already?) in any way? Could it be done
> in some way that is still portable (translated for other CPUs?).]
>
>
> Garbage collection
>
> Is a plus for almost all programmers and while some disagree even that
> seems not a good objection to Julia as best for everything (eventually). GC
> can be disabled (possibly helping with real-time functionality in the short
> term) or by calling C. Java has hard-real-time GC (even concurrent). I
> assume Julia could to (an implementation issue and not a "language" one)
> use all the GC algorithms Java can. I assume multi-dimensional arrays will
> not be an issue (seem to recall some array issues with Java's GC that were
> overcome).
>
> For game programming, would it be a good strategy to disable GC and run GC
> manually at every vblank? Would beat C/C++ with malloc/free?
>
>
> Game programming
>
> I mentioned games and a friend replied, "you wouldn't use Julia", au
> contraire?! At least 3D games are about the only heavy users of computer
> power (and often physics heavy) I can think of for ordinary users. Would
> any other language (C++) be clearly better/faster? See next for event
> driven:
>
>
> GUI programming
>
> GTK (does it also work (well) for Windows/Mac with Julia?). With C++
> recently covered Qt should work (perfectly eventually?). Would any other
> language be clearly better for GUI work with Qt (or otherwise)? Plex
> language for GUI and/or business application? [What is currently best?]
>
> Even RAD/Visual Basic-style programming is just based on BASIC (or Pascal
> in case of Delphi or lately what C#?). Julia doesn't have the GUI part of
> that equation but could and it wouldn't be any worse as a part of a such
> larger system, right?
>
> Same argument for individual games or engines (Unity uses JavaScript, C#,
> could use Julia).
>
>
> Android could work (already?), iOS probably (Apple requires using XCode to
> submit to the app store, ok w/Julia2C?).
>
>
> Database programming
>
> Julia supports *databases* but does it support the relational model as
> best as possible? I'm not sure what should be in the languages themselves.
> Not too familiar with:
> https://en.wikipedia.org/wiki/Dataphor
>
> See: https://en.wikipedia.org/wiki/The_Third_Manifesto
>
> I have mixed feelings about OO in relation to RDMS (see ORM).
>
> For an opposing view to relational-only-best-programming, see (nothing
> "should" use separate relational database, use only objects in memory):
>
> http://prevayler.org/
>
>
> At least PHP can't support this concept but this has been ported e.g. to
> C# and I think Julia could (should?) have an implementation. Not seeing if
> multiple dispatch (not "regular OO") should be any problem.
>
> [I haven't yet looked into it much, Julia has some serialization support
> and not much else needed.]
>
>
>
> Maybe there are better 4GL languages? I only know Informix 4GL (and Delphi
> in the GUI world).. not ABAP (SAP's), RPG or some later (or earlier 4GL's
> that most have "died"..?).
>
> I see Julia supports ODBC (most (relational) databases covered) and
> SQLite, MongoDB (and JSON). Any data(base) problems you know of?
>
> PostgreSQL at least supports Python for stored procedures. I assume an
> extension for Julia could be done..
>
> SQL or MDX (not really competitors to Julia, no more than other
> non-Turing-complete ("non-programming") languages (HTML, XML). Could query
> languages be better worked into Julia. Macros would help? Maybe changed
> syntax (SQL->LINQ)?
>
>
> First programming language
>
> I see three (more?) universities have started teaching Julia. For Matrix
> methods (I guess replacing MATLAB). I don't know if any have used it as a
> first language, but why not..?
>
> Unlike many common alternatives (e.g. C/C++/Java) I understand Julia
> avoids Hoare's "billion dollar mistake" - pointers (and like newer Java
> etc. has GC and easier than OO Java or Ruby).
>
>
> First programming language for (really young) kids
>
> May not compete directly with Scratch, Alice etc. but note Scratch is
> really a "GUI-wrapper" using Squeak language (a dialect of Smalltalk).
>
> Julia even could be competitive here.
>
>
> Hard real-time
>
> Something like the Metronome GC algorithm could work Julia?
> http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/41809/1/04-2432A.pdf
>
> Then at least I'm sure Julia *could* work but would it be "best" for that
> "environment":
>
> Could Julia do similar to Atom? I don't know it or the other languages,
> like those two for real-time:
> http://lambda-the-ultimate.org/node/4488
> "You might take a look at Atom, which is a DSL embedded into Haskell, and
> is used to produce real-time code for commercial products. It's open
> source, so you can see what they do. You could also look at the book
> Compiling Esterel, or some of Stephen Edwards' papers on the same topic.
>
> Synchronous reactive programming languages, like Esterel and Lustre,
> typically execute the `whole graph` (whole program) on a per-cycle basis."
>
> https://en.wikipedia.org/wiki/Esterel
> "Difficult to compile in the general case, but simple correctness criteria
> exist"..
>
>
> AI
>
> Lisp (and Prolog(?)) was popular for AI. Isn't "symbolic" pretty much
> covered in Julia? Is Julia worse for something like that? Or anything you
> can think of that Lisp is good for?
>
> Most have probably not heard of Replicode language for strong AI and I do
> not really know to much about it or even if it's Turing-complete or right
> to compare that to regular "programming languages".
>
> [Any AI languages/"systems" I should know about?]
>
>
> Formal methods
>
> https://en.wikipedia.org/wiki/Z_notation
> "Why Z?" with "Because it is the ultimate language!"
>
> I just do not know enought about Z-notation or formal in general, is Z
> even a programming language (Turing-complete)? Just a "specification
> language"?
>
>
> Operating systems (including "web browser" (OSes))..
>
> Linus famously doesn't like C++, wander if he would like Julia.. Would or
> could Julia be considered a "systems programming language" (is Lisp..?)?
> Seen articles saying so.. *Could* Julia at least work with C to build an OS
> or even in Linux? That is made work to without major changes to the
> *language*? But possibly to the implementation. Lisp machines had their own
> OS written in Lisp. Maybe they only had single-tasking (non-preemptive) and
> not fair to say OS in the modern sense (were just running Lisp?).
>
>
> Alien OSes (such as RISC OS?)
>
> Only three platforms, but could be extended to run in non-Unix..
>
>
> * "Exotic" hardware
>
> Decimal floating point hardware. DFP (or even BCD) can be emulated, just a
> library issue or native instructions used. And supporting both the hardware
> and software format. I may recommend some small changes to core
> (non-library) Julia just the same.. Not sure if a library (a first step)
> will do.
>
> It seems Julia can support all current hardware (Julia2C) and as I'm not
> up to speed on GPU's I reserve judgment there, but would like to know if
> Julia supports "automatically" or could (OpenCL.jl is not for that?). Same
> with FPGA's (unusual bitwidths.. But see myhdl.org "From Python to
> Silicon!") using Julia as a HDL.. And Micron's automata processor.
>
>
> Microcontrollers
>
> 4-bits are out.. but very hard to find anyway.
>
> 8-bit and 16-bit almost dead? Seems would work but 32-bit (ARM) is killing
> them anyway..
>
> Even Python had been proposed for microcontrollers:
> http://www.micropython.org/
>
> Since even Python can work, including for interrupt handling, then I
> assume Julia could work in that space also.
>
>
>
> Adapteva's co-processor CPU. Very memory constrained (32 KB per core for
> code, data and stack.. best not to use more..). How small could Julia
> executables get (or the parts of executable, kernels, the coprocessor would
> run)?
>
> GreenArray Forth chips are another story.. even more constrained..
>
>
> Lower than 32-bit CPUs (or maybe non-standard 18/36-bit etc..)
>
> Yes for serial; impossible for parallel (atomic issues)? Then Julia would
> be "worse" than C, but not really in the modern age..
>
> 8-bit bytes assumed (and no support for non-two's complement CPUs) is also
> hardly a limitation (except FPGA support?).
>
>
> Binary-coded decimal (4-bit) also not an issue, BCD not a means to an end,
> seems fixed or floating point decimal would be better.
>
>
>
> Quantum computers
>
> Quantum computing, I do not know to well, has at least one programming
> language, probably better than Julia in that case..
>
>
> Am I missing major areas?
>
> Best regards,
> Palli.
>
