My impression also is that array thinking is crucial to getting good performance out of computer systems. In today's economy, though, we need to deal with multiple programming languages if we're going to get any of the really good jobs (either that or work in finance - those guys are starved for really good programmers, but even there having a background in multiple programming languages might help).
That said, here's my take on Julia's feature list: Multiple dispatch: we've got this, in a carefully tuned sense, we have better things to emphasize. Dynamic type system: we've got this. Good performance: we've got this. Room to play here, though. Built-in package manager: we've got this. Lisp-like macros and other metaprogramming facilities: we've got this. Call Python functions: use the cd facility (need documentation though). Call C functions directly: use the cd facility Powerful shell-like capabilities for managing other processes: see below Designed for parallelism and distributed computation: we need more work here Coroutines: related to parallelism, see below User-defined types: overrated, but see below Automatic generation of efficient, specialized code for different argument types: see below Elegant and extensible conversions and promotions for numeric and other types: see below Efficient support for Unicode, including but not limited to UTF-8: we've got this MIT licensed: GPL works just fine Mostly what I want for J is a compiler for a limited subset of the language. This would let us address a variety of performance issues, and would also introduce some new problems. Problems, though, that we should welcome. Hypothetically speaking, J (or subsets) could be a language for use on GPU clusters, on large distributed clusters, and for a variety of other contexts. There's no technical reason we couldn't have process management vocabularies in the language. But if we go there we'd need to support the resulting user community, and that needs someone to pilot it and support it. Lots of people, potentially. It's not just about the job possibilities - we'd need textbooks for teaching people and drawing connections to interesting topics, we'd need to support the academics who found some relevance in our approaches and we'd have to do that while managing to trim back some of the suggestions. It seems to me that we could have a J subset targeted at just the features needed to implement LAPACK and wired into gcc for code generation. It also seems to me that once we had this we could use that subset to bootstrap a J implementation. Lots of work needed to do that, though, and we'd probably need a lot of Roger Hui's help if we wanted to get that done any time soon. And then there's the support facilities. Honestly, nothing I am proposing here compares in importance to getting J version 8 to have the feature set of J version 6. But it's also good, I think, to have some momentum for future work going also. But a lot of Julia's feature set (user defined types, in particular) run counter to array thinking. Array thinking pushes arbitrary complexity into the high level components and regularity into the low level components. This means that its results tend to scale well and tend to expose problems early. But this can be a problem as much as a solution. Sometimes the right approach is not to scale well but to just hide the problems, and maybe even make them shiny and attractive. So I think we, as a community, have to be a bit more tolerant of that kind of thing. User defined types are about enshrining complexity at the lowest levels of the coding system, and it's an excellent tool for creating messes but it's a popular tool and maybe if we can bootstrap ourselves in J that will move us closer to this approach for messiness. And, of course, we've already got rather elegant support for existing numeric types, it's creating new ones where we start running into issues. Still, before user defined types, it would also be good to introduce process management, and process management demands a couple things from J - a notation and tool set for communicating with processes using J sentences (or a subset) as the language between them and also a notation and tool set for starting and stopping those processes. That said, quaternions are a good example of a useful numeric type that's not supported by J. Quaternions map rather nicely onto SSE instructions (http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions) and also map rather nicely onto opengl and onto directx. A problem, though, is that the internal organization needed for efficient and logical use in opengl conflicts with the internal organization neded for effecient and logical use in directx. Anyways... there's a ton of work to do, and I'm trying to motivate myself to start chewing into it. Thanks, -- Raul On Tue, Feb 4, 2014 at 1:38 PM, Devon McCormick <[email protected]> wrote: > I went to a talk about a year ago by the developers of this language: I > walked out at the break. > > The two important things I learned are: most people's understanding of > arrays is abysmal and Javascript's performance is pretty amazing. > > In fact, my frustration at the primitive state of understanding about > arrays was in part what motivated my recent J talk. > > Their performance comparison slide was where I noticed that Javascript was > the best performer for many of their tests. > > > > On Tue, Feb 4, 2014 at 1:21 PM, Raul Miller <[email protected]> wrote: > >> http://julialang.org/ >> >> What can we learn from this? >> >> I think we've a lot of catching up to do, on the implementation side, >> and on the integration side. (And maybe a few things to teach the >> folks at MIT, also.) >> >> Thanks, >> >> -- >> Raul >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > > > > -- > Devon McCormick, CFA > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
