tkf

Joined 14 years ago

Karma

178

Submissions

Member since

Jul 2

View on Hacker News

Recent submissions

Comment · 6 years ago

For composable nested parallelism, I think spawn and sync like Julia has would be great. If there is a variant of spawn that asserts there is no concurrency is required for the child task, I'd imagine the runtime can do more optimizations (Julia doesn't have it but there was an experimental PR [1]). But concurrency sounds like a very basic thing in JavaScript so I'm not sure if it fits well in the language. But I don't have experience in serious JavaScript programming so I don't know what fits best there. I'd imagine you can build some data parallel libraries already with web workers API.

[1] https://github.com/JuliaLang/julia/pull/31086

Comment · 6 years ago

Yeah, I get the point that it's nice to have basic things in the core language and stdlib. I'm rather on the "minimal language core" side in this discussion and I think it'd be better to not start adding more things in Julia Base and stdlib. At least not right now, to avoid accumulating "dead batteries." There are some non-trivial things to figure out for a composable data-parallel interface. For example, what the data collection interface should be to support folds over them? I'm using a minimalistic interface defined in SplittablesBase.jl for this but it's not wildly used outside my packages. So I'm not super confident that it's enough yet.

[1] https://github.com/JuliaFolds/SplittablesBase.jl

Comment · 6 years ago

Hi, the author here.

One of the hidden messages of the introduction is: watch Guy Steele's talks [1][2][3] if you are interested in data parallelism! These talks are not Julia-specific and the idea is applicable and very useful in any languages. My libraries are heavily inspired by these talks.

Of course, if you haven't used Julia yet, it'd be great if (data) parallelism gives you an excuse to try it out! It has a fantastic foundation for composable multi-threaded parallelism [4].

[1] How to Think about Parallel Programming: Not! https://www.infoq.com/presentations/Thinking-Parallel-Progra...

[2] Four Solutions to a Trivial Problem https://www.youtube.com/watch?v=ftcIcn8AmSY

[3] Organizing Functional Code for Parallel Execution; or, foldl and foldr Considered Slightly Harmful https://vimeo.com/6624203

[4] Announcing composable multi-threaded parallelism in Julia https://julialang.org/blog/2019/07/multithreading/

Comment · 13 years ago

Thanks for the explanation. It is hard feel this kind of nuance as my English is not that good. It's also good to know that he'd like that :)

Comment · 13 years ago

> The takeaway is that Elisp needs to learn to interface with other languages better.

This is exactly why @kiwanami developed EPC (a general RPC protocol/libraries for Emacs) and why I wrote Python binding: https://github.com/kiwanami/emacs-epc

He was also inspired by the article.

Comment · 13 years ago

I agree some of them are harder to setup in Windows. But it helps (or forces) developers to make these tools and languages cross-platform, which is good, I think. And I guess making them cross-platform is actually easier than implementing them purely in Emacs Lisp.

Comment · 13 years ago

I think "maximum extensibility" is not the philosophy of Emacs. Remember how long it took to have FFI support in Emacs (it was discussed in the article). Also, even with FFI, it is not possible to load non-free libraries. I think this shows some discrepancy from the philosophy to achieve "maximum extensibility". I would say GPL does not allow "maximum extensibility".

So the next question is: does the philosophy the author speaks of matches with the one of GPL, or rather, the one FSF and Stallman have in mind? Actually, I think these philosophies are different. If I remember correctly, in Emacs mailing list sometime ago, Stallman rejected idea of adding function to gcc to dump parse tree (or something similar) to use gcc from other software (I can't find the link right now). This was because non-free software could use gcc via CLI and "steal" the data from free software. Now, although it is the other way around, Emacs can use non-free external program. It matches with the philosophy by Matsuyama but I doubt that Stallman says it is the philosophy of Emacs.

I would say this philosophy is for author of Emacs Lisp program (though this was not what Matsuyama was talking about). You have many options. You could choose "maximum extensibility" but actually it is not doable due to GPL. You can follow FSF's philosophy (I am not sure what is it, but I believe there is). Somewhere in between, there is philosophy proposed by Matsuyama and it reflects current situation of Emacs very well, and I like it.

Comment · 13 years ago

Some awesome Emacs Lisp programs that relies on external programs:

mu4e: http://www.djcbsoftware.nl/code/mu/mu4e.html

not much: http://notmuchmail.org/

EDBI: https://github.com/kiwanami/emacs-edbi

ropemacs: http://rope.sourceforge.net/ropemacs.html

RSense: http://cx4a.org/software/rsense/index.html

GCCSense: http://cx4a.org/software/gccsense/index.html

emacs-ipython-notebook: http://tkf.github.io/emacs-ipython-notebook

emacs-jedi: http://tkf.github.io/emacs-jedi

request.el: http://tkf.github.io/emacs-request/

Well, the last three is my projects so you could exclude that :)

Also, we could add version conrolling interfaces such as magit and VC (relying on git/svn/hg/...) and advanced interpreter such as SLIME/nrepl.el/geiser.