(untitled)

Julia thread? I just came back to Julia for the first time after briefly trying it out six months ago, and tried making some basic GUI stuff with it. I was very positively surprised, the GTK bindings basically worked out of the box after a simple Pkg.add("Gtk"), and were fairly easy to use. And there are a few GUI libraries using it as a backend that let you write Elm-like functional reactive GUI's as well, though I haven't looked into that yet because the basic bindings fit my needs so far. I like this language a lot. It reminds me a lot of Common Lisp with its dirty macros that let you implement your own syntax, and an object system based around multiple dispatch, and C/Java-like performance with a dynamic language. I have a few projects in mind for the next few months that will require some numerics and data processing, and I've more or less decided to use Julia for those.

I absolutely love Julia, its everything I wish Javascript could been. Neither Python nor Ruby ever came close to the power of high order functions that you have in Javascript. You can tell the Julia designers were strongly influenced by Coffeescript and the improvements that were made with adding Python/Ruby iterator methods over container types. No more stupid ass for/while loops where you have to manipulate all the iteration variables by hand like in C, now its like Python for loops that combine everything from foreach-like iterator functions, to mapping functions and comprehensions are all built into the for loop. I like that its not an object oriented language so that you have freedom to pass functions everywhere and not get cockblocked by class scope(just like Javascript). And what really kills Javascript is that there are no I/O and systems libraries (and dont tell me that node is a Javascript library because its not, its Javascript wrappers over a C++ API). I have a feeling were going to see Julia get used a lot in backend web programming to replace node.

Its easy to see why so many machine learning and data mining programmers would escape to Python from R considering how awful R is. Its too bad more people dont give notice that the syntax of Julia is just as intuitive as Python but is so much better in how it can handle large array sets.

>>1506 If you think that R is bad and abused for things it shouldn't be used for, just wait until you see Matlab.

>>1511 >Likes Julia >Hates Matlab Did I stumble upon an alternate dimension? All joking aside, I don't really like Julia all that much. It seems to me like a competitor to python (That one XKCD comic with the '13 competing standards' comes to mind) that borrows a lot pythonic syntax, but chooses to forgo a lot of conventions for the sake of individuality and doesn't really add much new to the table (the thing that really frustrated me was Julia's pretty nonchalant way of just using 1-based array indexing, despite being influenced by Python). I find writing in python a lot more bearable than Julia. If you don't mind me asking, what's wrong with Matlab? I use it for most of my engineering classes and absolutely love it. While a lot of my complaints for Julia can be seen in Matlab, Matlab at least has god-like documentation) It's incredibly useful for a lot of data analysis and (at least in my opinion) is very easy to create pretty complex scripts (pic related is a Lorentz-Attractor thing I made for one of my classes)

>>1521 >>Likes Julia >Hates Matlab the person youre quoting never said he hates Matlab If you like Python over Julia then I would suggest that you post in the Python thread as you seem to be fishing for a language war with cheap bait

>>1521 Matlab is an okay DSL for multiplying matrices of floating point numbers and for very short scripts calling Fortran functions. Trying to make it do anything more than that is asking for trouble. Matlab is a proprietary, closed source, slow, weakly typed dynamic language with ludicrously high licencing costs, which lacks lexical closures, proper scoping, or proper namespaces. It is so far removed from any other paradigm than procedural programming in global scope that it makes you put each function in a separate file. Yet it is routinely abused for fairly large projects because many engineers unfortunately aren't trained in anything else. It ticks almost every single checkbox for a bad language that I can think of. Also, in the one domain where it's supposed to be the best, calling library functions on matrices of real numbers, it loses out against Mathematica on many benchmarks because Mathworks just leeches off external libraries like the MKL and doesn't spend much R&D into improving their own algorithms. For things like solving differential equations, the built in solvers like ODE45 just fail utterly compared to other commercial solvers like Mathematica's NDSolve, since it doesn't adapt automatically to stiff problems and doesn't even throw proper warnings in cases where it is numerically unstable. I switched to Mathematica as my default math DSL as soon as my college classes stopped mandating the tools used, and never found a reason to use Matlab again, except in the few cases where an employer required it. I like Julia because it's a good lispy general-purpose programming language that still has nice syntax for math-related stuff, and if I want to roll my own symplectic differential solver in it, it's fast enough to let me do that without having to switch to a different language or losing the advantages of the better algorithm due to writing in a slow language.

>>1526 i like the part where you say why julia is a good language, but your complaints about matlab can be forgone if you talk about octave :) i love u my friends

>>1525 Hey man, I wasn't trying to start anything, swear. I was just exaggerating Arisu's point to transition into my pov. I just really don't understand Julia, and wanted to know why Matlab was viewed kind of negatively, as the poster seemed to suggest. >>1526 >far removed from any other paradigm than procedural programming in global scope that it makes you put each function in a separate file. You can have function in Matlab, you can put them at the end of the file. But I understand your frustration. > engineers unfortunately aren't trained in anything else. It ticks almost every single checkbox for a bad language that I can think of. Yeah, to be fair, I guess I'm just used to Matlab's weirdness and am kind of lazy to learn Mathematica. That might change over the summer... Isn't Mathematica also closed source, tho? Or is this a case where one product is clearly superior to the other but people just don't want to make the switch? >like Mathematica's NDSolve, since it doesn't adapt automatically to stiff problems and doesn't even throw proper warnings in cases where it is numerically unstable Holy soykaf that's awesome You make pretty good points... I still don't really understand what sets it apart from python at a lower-base level since it seems like it's pretty similar, at least syntax-wise. You do complain about warnings, but I've found that Matlab's warnings are usually specific enough that you could probably figure out what's wrong with it, but there have been times when (and disclaimer, I've used Julia through Juliabox, so I"m not sure how much this applies elsewhere), I run a cell and it doesn't catch syntax errors until a couple of cells later when I run a particular function in a previous cell. >>1527 I've definitely heard of Octave... How is it? Is it literally GNU-flavored Matlab? Or is it something completely different?

>>1531 >Is it literally GNU-flavored Matlab? Or is it something completely different? I haven't worked with matlab too much. As you may know GNU flavoured things often lack the pretty interfaces but have no problem delivering good computing. Octave is very powerful and surprisingly intuitive. I liked working with it when I had to. There is a course on ML by Andrew Ng that teaches you the basics of ML and expects you to code them in Octave. I recommend it greatly.

>>1531 >at least syntax-wise. Syntax means absolutely nothing when comparing two languages. It is mostly an aesthetic issue, and unfortunately there aren't many languages that do this, but you could easily write an alternate syntax for any language and plug it into its compiler to produce the exact same code as the original syntax; OCaml and Reason are such an example. Anyway, >I still don't really understand what sets it apart from python at a lower-base level Julia is a few orders of magnitude faster than Python. And faster than Matlab and Octave too, go look at the benchmarks on the Julia website. This is partly because it's a typed language, which means that it will catch most errors when you compile the program rather than blowing up while it's running. It's also a considerably more sound language than Python overall: for example it doesn't make useless distinctions between statements and expressions, it doesn't disallow some things (like statements in lambdas) just because the main developer doesn't like them, and it has much better means of abstraction (lisp macros).

BTW, Julia just got a new major release: https://github.com/JuliaLang/julia/blob/release-0.6/NEWS.md

>>2001 Imho, the biggest advantage of Julia over Python in terms of abstactions is the fact that Julia has a decent type system. That and CLOS-like multiple dispatch, which I really wish that more languages had.

>>2020 Agreed. # GADT using Julia's abstract & parametric types abstract type expr{T} end struct In <: expr{Int64} int::Int64 end struct Bo <: expr{Bool} bool::Bool end struct Add <: expr{Int64} a :: expr{Int64} b :: expr{Int64} end struct Mul <: expr{Int64} a :: expr{Int64} b :: expr{Int64} end struct Eql{T} <: expr{Bool} a :: expr{T} b :: expr{T} end # Haskell type signature would be calceval :: expr{T} -> T calceval(e::In) = e.int calceval(e::Bo) = e.bool calceval(e::Add) = calceval(e.a) + calceval(e.b) calceval(e::Mul) = calceval(e.a) * calceval(e.b) calceval(e::Eql) = calceval(e.a) == calceval(e.b)

>>2140 Hey, that's pretty neat. Although, one of the nicer parts about GADT's is typechecking, which is pretty complicated. I'm assuming you can't properly create a type signature for calceval, right? Not that this is a big complaint. Abusing GADT's shouldn't be what Julia is used for (I made a post doing so in Haskell >>1813).

>>2201 Right, the type definitions ensure that any expression stored in the GADT is properly typed, meaning that the basic DSL I wrote here is properly typechecked. The Eval function indeed does not have a type signature.so in theory one of the overloaded methods could be made to return something not of type T for an input with type expr{T}. I can type code_warntype(calceval,Tuple{expr}), which will make Julia tell me the inferred output types of every method of calceval, along with the inferred types of every intermediate variable in the AST to track down where things go wrong if it returns something too untyped like "Any". The output is then: Variables: #self#::#calceval e::Mul Body: begin SSAValue(1) = (Main.calceval)((Core.getfield)(e::Mul, :a)::EXPR{INT64})::Int64 SSAValue(0) = (Main.calceval)((Core.getfield)(e::Mul, :b)::EXPR{INT64})::Int64 return (Base.mul_int)(SSAValue(1), SSAValue(0))::Int64 end::Int64 Variables: #self#::#calceval e::Sub Body: begin SSAValue(1) = (Main.calceval)((Core.getfield)(e::Sub, :a)::EXPR{INT64})::Int64 SSAValue(0) = (Main.calceval)((Core.getfield)(e::Sub, :b)::EXPR{INT64})::Int64 return (Base.sub_int)(SSAValue(1), SSAValue(0))::Int64 end::Int64 Variables: #self#::#calceval e::Add Body: begin SSAValue(1) = (Main.calceval)((Core.getfield)(e::Add, :a)::EXPR{INT64})::Int64 SSAValue(0) = (Main.calceval)((Core.getfield)(e::Add, :b)::EXPR{INT64})::Int64 return (Base.add_int)(SSAValue(1), SSAValue(0))::Int64 end::Int64 Variables: #self#::#calceval e::Bo Body: begin return (Core.getfield)(e::Bo, :bool)::Bool end::Bool Variables: #self#::#calceval e::In Body: begin return (Core.getfield)(e::In, :int)::Int64 end::Int64 Variables: #self#::#calceval e::EQL Body: begin return ((Main.calceval)((Core.getfield)(e::EQL, :a)::EXPR{T} WHERE T)::ANY == (Main.calceval)((Core.getfield)(e::EQL, :b)::EXPR{T} WHERE T)::ANY)::ANY end::ANY Meaning that it has proved that every method except the one for Eql returns T with an input of expr{T}. It can't do the same for Eql because it involves a call to calceval for something of type expr{T} which may be overloaded by say, a third party user of the library by some extension of the GADT made by the user, so it can't make any assumptions about the return value of subcalls to eval. However it can infer the return types for particular values of T: >> code_warntype(calceval,Tuple{Eql{Int64}}) Variables: #self#::#calceval e::Eql{Int64} Body: begin SSAValue(1) = (Main.calceval)((Core.getfield)(e::Eql{Int64}, :a)::EXPR{INT64})::Int64 SSAValue(0) = (Main.calceval)((Core.getfield)(e::Eql{Int64}, :b)::EXPR{INT64})::Int64 return (SSAValue(1) === SSAValue(0))::Bool end::Bool It would be great if you could add a type signature contract though, to ensure that any method definitions of calceval are typed and return T for expr{T} inputs. You could probably write an assertion macro to automatically prove that such a contract is satisfied by the current set of methods though, using repeated calls to code_warntype.

>>1502 https://danluu.com/julialang/ There a few issues with julia, which largely come from it being new and under development. I hope that these issues get resolved quickly, because it really seems like a nice language that I'd like to see people adopt.

Intel wrote a Julia to C transpiler! https://github.com/IntelLabs/julia/blob/j2c/j2c/Julia2C.pdf

There was a great hackernews thread on Julia recently: https://news.ycombinator.com/item?id=15471737

>>2805 That post is from 3 years ago. The julia people actually fixed a lot of his criticisms since then even though that guy is is kind of an idiot and has some weird grudge against julia.

I'm kind of hyped up for Julia's 1.0 release and API stabilization somewhere in the middle of next year. Julia has now gotten to the point where some of its libraries such as differentialequations.jl are best-in-class, and a few libraries that are close to getting to that point but where development has been paused until the 1.0 language stabilization. Imho, what I really like about the language is that it combines the ease of using external packages (like in Python, just import and write a quick script), with the relative ease of writing packages. Julia has a ton of compiler introspection tools to see what intermediate forms (lowered typed Julia code, LLVM IR, Assembly, etc) that an expression compiles into from the repl and has some really nice benchmarking packages, which makes optimizing Julia code feel really interactive. It encourages you to learn what makes something fast or slow, lets you check whether something is inlined, etc etc. In most other languages this is annoying enough to do that you wouldn't bother with it, with the possible exception of Haskell where checking core to see if you'll run out of memory due to laziness or not is common practice because you can get hit hard if you don't.

i just spent the day learning julia and i really like it. probably going to end up replacing python as my go-to scripting language. i'm having some trouble with optimization though. do any of you more experienced julia programmers see anything blatenly wrong with this function? it works correctly, just runs too slow. convolve2D!(nextstate::Matrix, state::Matrix, kernel::Matrix) kw, kh = div.(size(kernel),2) w, h = size(state) w_indices = ((-kw):kw).%w.+1 h_indices = ((-kh):kh).%h.+1 for i in 1:w stateslice = state[w_indices, :] for j in 1:h nextstate[i,j] = vecdot(stateslice[:, h_indices], kernel) h_indices .%= h h_indices .+= 1 end w_indices .%= w w_indices .+= 1 end end from looking at the profiler it seems like i might be doing something really stupid with the indexing. i just can't figure out a better way to handle the cyclic boundary conditions. i tried lots of different access patterns... even tried copying each row to a buffer and repmat-ing it to avoid all the matrix slicing and modular arithmatic... no luck.

>>5048 looks like lainchan ate my indents. sorry about that.

>>5048 Try putting @code_warntype in front of your call to the function in order to make it print out the lowered AST, and see if it highlights anything.

>>5048 state[w_indices,:] makes a copy of the slice. So you are creating a k x n copy (k is kernel size, n is state's size) of the state matrix for each row of the matrix. It makes your algorithm O(k^2 n^3) instead of O(k^2 n^2). Try replacing state[w_indices,:] with view(state, w_indices, :). view creates a view into the matrix instead of copying it.

>>5048 Also, does it run slowly compared to the same algorithm written in another language, or does it just run slowly? One thing you could try is vectorizing the other way when convolving with the Kernel in order to improve cache locality, if the Kernel is much smaller than the matrix. Matrices are stored in column major order.

>>5048 Also, for cache friendliness, you should put the for j in 1:h loop on the outside and the for i in 1:w inside, since julia matrices are column major. Also, if you use for loops everywhere instead of allocating vectors and matrices everywhere in your loops, it should be a lot faster. Julia loops are very fast, so use them as freely as you want to.

>>5051 Oh lol I'm dumb. That doesn't actually make it n^3 it's still n^2.

>>5050 Thank you anon! >>5051 Ah this was something I was unclear on. I thought the interpreter turned slices into a view. I'll try that. This only helps by eliminating the copy though, right? It's not going to do anything for cache locality? >>5052 >does it run slowly compared to the same algorithm written in another language It's hard to say. I've done variations of this algorithm in plenty of languages, but I usually take a slightly different approach depending on the language. It's vastly slower than my C implimentation, but I expected that because I was doing some fairly complicated memory management to avoid copies. Right now it's probably on the level of what I could do with numpy, but I'm trying to get it roughly up to par with tensorflow. Something I forgot to mention was that it's actually not too bad for smaller arrays (~100x100 doubles with a 30x30 kernel), but it slows down by a factor of about 15 when I double the size. If this is purely an access pattern thing, is there a way to get the interpreter to use a particular data structure? Maybe something like this https://en.wikipedia.org/wiki/Z-order_curve . >One thing you could try is vectorizing the other way when convolving with the Kernel in order to improve cache locality I did experiment with this quite a bit and this ended up being the fastest vectorization. I even tried doing partial sums on the kernel rows. Maybe that option would be more viable with the views you mentioned earlier because the profiler did show higher allocations when I tried that. >Matrices are stored in column major order. I vaguely remember reading that this was the case in Julia but I wasn't sure. Correct me if I'm wrong: M[:,1] gives the first row M[1,:] gives the first column So if I'm iterating through M[i,j], the j loop should be inside the i loop? >>5054 >if you use for loops everywhere instead of allocating vectors and matrices I'm still get used to exactly what allocates things in Julia. Not used to gc languages... The only allocations I see are the two points where I take slices of the state (which I could replace with a view to get rid of?). Are there others? Do you think it would be better to write my own loop for the dot product, or even just call cblas directly? Thanks for all the help.

>>5051 >>5065 >slice() I just checked the docs and it looks like the correct function is actually sub(): >sub(A, inds...) >Like getindex(), but returns a view into the parent array A with the given indices instead of making a copy. Calling getindex() or setindex!() on the returned SubArray computes the indices to the parent array on the fly without checking bounds. Gave me marginal speedups but I think cache locality is the bigger issue. 52.312636 seconds (40.81 M allocations: 234.599 GiB, 17.55% gc time)

>>5067 that time stamp is for 200 convolutions on a 201x201 matrix.

>>5065 M[:,1] gives the first column and M[1,:] gives the first row. So the i loop should be inside the j loop. vecdot is fine especially with array views. Array views should reduce the allocations a lot compared to the array slice. The problem with array views in julia 0.6 is that an array view does allocate the view in the heap, which slows things down. That's mostly why I said to write loops. Though I'm pretty sure julia 1.0 should fix that so that array views only stack allocate and thus are efficient. I don't think you will be able to get julia to use a particular data structure unless you code it yourself. >>5067 You might want to check that you're looking at the julia 0.6 docs instead of julia 0.4 docs. They changed the function from sub to view for array views. This is the 0.6 docs https://docs.julialang.org/en/stable/devdocs/subarrays/

>>5065 I feel like you should be using fourier transforms to do convolutions with that large a kernel. Isn't this algorithm usually for like 3x3 or 5x5 kernels?

OffsetArrays function conv2d!(nextstate::Matrix{T}, state::Matrix{T}, kernel::Matrix{T}) where {T} kh, kw = size(kernel) khl = div(kh,2) kwl = div(kw,2) khr = mod(kh,2)!=0 ? khl : khl-1 kwr = mod(kw,2)!=0 ? kwl : kwl-1 kernel = OffsetArray(kernel, -khl:khr, -kwl:kwr) h, w = size(state) for j in 1:h for i in 1:w s = zero(T) for b in -khl:khr for a in -kwl:kwr # circle around at state's borders ip = mod1(i-a, h) jp = mod1(j-b, w) s += state[ip,jp] * kernel[a,b] end end nextstate[i,j] = s end end nextstate end Ayyy.

>>5089 Woops using OffsetArrays not just OffsetArrays

>>5074 normally, yes. in this case, i have reasons for not wanting to do that. >>5089 Woah, thanks for that. It's super readable. I see what y'all meant by looping instead of using views/slices. It just seemed counter-intuitive to add two more nested loops instead of grabbing a sub-array and using the optimized vecdot... I'm going to try out your code to see how it compares. Maybe I'm over-complicating things here. Worst case I just basically translate that code to c and optimize it that way...

>>5099 Look up the @simd and @inbounds macros. https://docs.julialang.org/en/stable/manual/performance-tips/

https://insights.stackoverflow.com/trends?utm_source=so-owned&utm_medium=blog&utm_campaign=trends&utm_content=blog-link&tags=julia-lang%2Clua%2Cclojure%2Cf%23%2Chaskell%2Crust%2Cscheme%2Cracket%2Ccommon-lisp%2Clisp Looks like Julia is the most used lispy language now according to stack overflow. It passed Scheme/Racket/CL a while ago, and now it just passed Clojure. Considering that it's still pre-1.0 and that a lot of people are waiting for 1.0 to switch, that's quite promising. I really want a language with lisp macros and multimethods to truly break into the mainstream, to a larger extent than Clojure. Maybe Julia will be the Lisp family's equivalent of what Ruby was to the Smalltalk family?

>>5104 Comparing julia to ruby...**shudder** Not that ruby is a bad language but it's community in the west is just..well

>>5110 It's more that I really like the julia community as it is now. There are a lot of scientists, current/ex matlab, R, scientific python users and it's great. Of course I would like julia to be more popular though. More people should certainly program in a lispy language with multimethods.

>>5110 Ah right. I just meant "similar but with more familiar syntax for the masses". Not anything community related, Julia's community is unusually productive, and the very high productivity of the language has enabled some truly impressive single-person projects.

>>5089 >3.907722 seconds (5 allocations: 192 bytes) not bad at all (that's one convolution on a 200x200 matrix w a 30x30 kernel) not even close to fft speeds but it'll do for now. >>5102 thanks for the tip. @inbounds saved me almost a half second, but naiively adding simd actually made things slower. i'm going to read into it a little deeper. i've noticed vectorization actually tends to be relatively slow in julia. the '.' vectorization anyway, idk if the simd macro has anything to do with that. seems like the devs are working to improve that, so it's something to look forward to at least.

>>5116 >> i've noticed vectorization actually tends to be relatively slow in julia. the '.' vectorization anyway, idk if the simd macro has anything to do with that. seems like the devs are working to improve that, so it's something to look forward to at least. Well, it's really just syntax sugar for looping (broadcast). Unlike python/matlab where vectorization is absolutely necessary to offload work to C/C++/Fortran, Julia broadcast isn't intended to be faster than the loop constructs. It's a zero-ish cost abstraction which is there for conciseness more than anything.

>>5116 Btw, I don't know if you just need a 2D convolution function or are practicing using julia, but julia has a builtin 2D convolution function called conv2.

>>5116 >>5120 Yep, sin.(x) gets transformed syntatically into broadcast(sin, x) in julia. I'm guessing the broadcast function is not super simple, and so it doesn't get compiled as efficiently as a for loop would. Though the dot notation is pretty nice because it syntatically fuses multiple dot operations into one. For example, sin.(cos.(x) .+ cos.(y)) gets transformed into broadcast((a,b) -> sin(cos(a)+cos(b)), x, y). And if x is a n x 1 matrix and y is a 1 x m matrix, the result will be an n x m matrix.

>>5136 Right, and using .= to write the result into an existing allocated array, you can write 100% nonallocating code with it. I can't think of any other language that lets you do that this effortlessly. Sometimes replacing it with a loop with appropriate speed macros will be an optimization, but when you don't care too much about a 10% difference in number of CPU cycles used and just want to use memory efficiently, it's a godsend. Also, it works with sparse matrices: julia> sp = sprand(3,3,0.1) 3×3 SparseMatrixCSC{Float64,Int64} with 1 stored entry: [3, 2] = 0.954893 julia> sp .* sp .+ sp 3×3 SparseMatrixCSC{Float64,Int64} with 1 stored entry: [3, 2] = 1.86671

>>5149 Ya true I use it everywhere it my code. It's way too convenient to bother with the 10% increase a majority of the time.

>>5104 From my observations, people use StackOverflow when they don't know something and don't want to learn, but still want to do it. I figure Lisp has less activity there due to excellent documentation and books.

>>5157 Looking at the stack overflow questions, most Julia questions are about libraries or are domain-specific, rather than being about the core language though. Actually,now that you mention it, it's quite shocking to see the difference between the average lisp question and the average Julia question on stack overflow: https://stackoverflow.com/questions/tagged/lisp https://stackoverflow.com/questions/tagged/common-lisp https://stackoverflow.com/questions/tagged/racket https://stackoverflow.com/questions/tagged/julia-lang Lisp related questions are far more likely to be about core language features!

>>5188 That is very interesting. I don't know about lisp documentation, but julia has really good introductory documentation to me, someone with years of programming experience. I don't know how good lisp's or julia's documentation is for beginners though, but julia's seems to be pretty good looking at stack overflow questions. Another theory is that lisp's and julia's beginners come from very different backgrounds. Julia is starting to be used more and more in universities, and so the beginners probably have access to a lot of resources. While I don't think lisp is used in universities as much. Lisp beginners are probably hobbyists who came across lisp and wanted to learn it. They might not have easy access to as much learning resources as julia beginners.

>>5188 >Lisp related questions are far more likely to be about core language features! That's interesting, but I think that may also fall in line with my earlier statement. I wonder why StackOverflow is analyzed so much, from my perspective, it will fade into obscurity with all the rest. >>5193 >That is very interesting. I don't know about lisp documentation, but julia has really good introductory documentation to me, someone with years of programming experience. I don't know how good lisp's or julia's documentation is for beginners though, but julia's seems to be pretty good looking at stack overflow questions. To use Common Lisp, it was standardized over twenty years ago and hasn't changed since; every book written about it since then is still valid and there's many good books. Scheme is also accompanied by many good books. >Another theory is that lisp's and julia's beginners come from very different backgrounds. Julia is starting to be used more and more in universities, and so the beginners probably have access to a lot of resources. While I don't think lisp is used in universities as much. Lisp beginners are probably hobbyists who came across lisp and wanted to learn it. They might not have easy access to as much learning resources as julia beginners. From what I've seen, universities are more likely to use Java or Python these days. Many programming students have never heard of Lisp, which is just sad.

>>5188 Great power, great responsibilities.

>>5188 From looking at these questions I feel like lisp is just significantly harder for beginners to learn. It was definitely hard for me to learn lisp when I was a beginner programmer. I tried out tons of languages during that time. The parentheses and cruft from being decades old (car, cdr, etc) made it harder for me to learn lisp, compared to languages like python and even haskell. I think infix notation and f(x) notation has been pounded into people's heads from first grade and it's almost impossible for most people to let go of it.

>>5195 >every book written about it since then is still valid and there's many good books. That's true, but the problem is exactly that they're old. Personally I think the HyperSpec's layout should be given an update. It's very comprehensive but it's a pain to navigate for modern web standards, there's too much clicking to do to get anywhere. Racket's Scribble is an excellent example of what the HyperSpec should look like.

>>1531 >>1997 I love octave. Period. But its slow. I managed to work through half my master's progam using octave and not matlab. But on a given problem set Inhad to switch wo Incould handle it on time. I wasn't that great of a programmer at that time, so my experience might be biased, but same code runs slower on octaven than matlab. As far as Julia, I like the language, but it is not as fully fledged, which I guess is ok, given its young. I work as a data scientist, and I feel its data wrangling capabilities lacking when compared to R's tidyverse. But I must admit, I tried Julia a while ago, ao things might have changed, is there a decent data wrangling library? Also, for those hating on R, have you tried the tidyverse? It made change the way I think about R. I would love to hear your thoughts.

>>5285 Before julia I used to write in Matlab, sometimes python, C++, and R, depending on what kind of code I needed. Matlab and python would be for straightforward numerical stuff, linear algebra, optimization, and building bigger programs that might be used by people. C++ for things I needed to be very fast. R for data wrangling, analysis, plotting. Now I use julia and R. I use mainly ggplot and data.table, with a couple of other tidyverse functions. Julia is getting there but it is definitely not there yet. I even plot in julia by calling ggplot through RCall.jl. Though Plots.jl is a plotting library and it's ok. Query.jl is good for interacting with a large number of backend databases using the same code. Julia might be actually be the best language right now if you want to work with massive out of memory data but it's interactive data analysis is lacking. It's somewhat stabilizing right now but it'll be probably be a few months to a year or two before it gets good and the packages get stable. It will probably be years before it gets tidyverse level niceness. Another problem for me is the jit compile lag. Loading and plotting in plots.jl takes a few minutes the first time, so I can't just start up julia, load csv file, and do a scatter plot in 30 seconds like I can with R. People get around this by having julia always on with your favorite packages loaded.

>>5288 >jit compile lag i hope this is improved soon. i love how (in terms of features and design) julia scales seamlessly from interactive matlab-style data wrangling to deeply involved library development. the slow library includes is the only reason i still use python for the former case.

>>5289 Yep, it's one of the reasons I use R so much. They've been talking about heuristically interpreting julia code instead of always compiling it beforehand but that will probably take a while to get implemented.

Well, in my case, it's mostly plots.jl that takes a long time to load. The load time for the other libraries that I've used is tolerable. To some extent I think it's a matter of writing a good plotting framework for Julia in Julia, rather than bindings to other backends. I have high hopes for GLVisualize.jl. As it matures, i think it might be worthwhile to maintain a plotting package that only has that as its only backend, and doesn't have a gazillion dependencies. That together with better precompilation should improve time to first plot.

>>5295 Yeah Makie.jl uses GLVisualize and it looks pretty impressive.

i'm >>5048 thanks again for the help. got everything working fairly well (if still a bit slow). been rendering some pretty PDE solutions. sage because i don't actually expect anyone to give a soykaf

I just came across this Julia library: https://github.com/simonster/StructsOfArrays.jl The implementation of the data structure is really short! I'm honestly impressed: https://github.com/simonster/StructsOfArrays.jl/blob/master/src/StructsOfArrays.jl This is really annoying to do in C++, and Jai marketed itself as a data-oriented language with easy SoV as a core builtin language feature. The fact that Julia can do it with just generated functions metaprogramming is really impressive.

>>5370 Yep that library was used in this huge HPC project Celeste.jl to generate SIMDified code.