On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote:
>
> I find your aversion to femtolisp difficult to understand, probably
> because I tend to think of Julia as a Lisp with the following key
> features:
>
I don't really have an aversion to femtolisp. I understand it's an awesome
implementation of Scheme.
If you "think of Julia as a Lisp" (including Scheme, right?) then when
would you prefer Lisp (or Scheme) for new things after Julia came along?
I "learned" Scheme (and ML) in the "programming language Uni course", never
to use them (or other functional languages) again. That is, I put in quotes
as we didn't go into macros if I recall, it may have been mentioned as a
concept.
But given these two (very important) differences
>
Why "very important"? I understand there is a difference in the syntax, is
it important as in better *fro something*? Or just different.
> Modern CL implementations can be very fast, but it turns out that the
> type system of CL is not rich enough to allow optimizations necessary
> for generic numerical code (at least without a lot of biolerplate).
>
What I thought. What I'm getting at, if Julia is better at somethings (e.g.
the above) must it then be worse for other things?
>
> but infix
> clearly makes macros easier because the AST is much cleaner.
This is the thing I do not get, is non-infix then a problem in Julia? Will
(user) code get bigger more complicated?
The core of Julia is generic enough to be a potential substitute for all
> dynamic languages in the long run, as the language matures.
Not already? Then some dynamic language should currently be better, I would
like to know why.
> I am not so
> sure that current technology allows a single language to be good at
> everything, languages like C seem to be difficult to replace with
> dynamic languages in some situations.
>
Why? For C, Julia seems already better for almost all users. If "languages
like C" means C++, I could see all new code in Julia and C++ as legacy.
What other "like C" do you mean?
>
> Best,
>
> Tamas
>
> On Thu, Dec 04 2014, Páll Haraldsson <pall.ha...@gmail.com <javascript:>>
> wrote:
>
> > 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.
>
>
