61–70 of 93 posts
Earlier quoted context omitted.
Kdb+ is incredible. It blows away any of the current attempts at time series data stores out there (eg; InfluxDB, OpenTSDB). Unfortunately, Kx Systems failed to allow it to reach mass popularity by keeping licenses extremely expensive. Startups simply can't afford to outlay $100k+/year for a tiny cluster.
I wonder if anybody compared Kdb+ with Jdb, a J DB system.
I am blown away to see how frequently APL seems to come up on HN these days, a language I used professionally for over ten years. As much as I love it I have to say one of the issues with APL is that it was way ahead of it's time. Because of that it struggled to run on computers of that era. I was introduced to the language in 1982~ish. Like I said, I used it extensively, attended and presented at APL conferences and…
Earlier quoted context omitted.
Isn't the inventor of K+/Q currently writing his own operating system? Haven't heard any progress about that in a long time, hope it actually gets some use. Sure, won't be the next Linux, but maybe more than the next ColorForth.
ColorForth is not an OS. For C. Moore, an Operating System is a non-thing.
I am blown away to see how frequently APL seems to come up on HN these days, a language I used professionally for over ten years. As much as I love it I have to say one of the issues with APL is that it was way ahead of it's time. Because of that it struggled to run on computers of that era. I was introduced to the language in 1982~ish. Like I said, I used it extensively, attended and presented at APL conferences and…
Lisp was also far ahead of its time, but many Lisp features like garbage collection and lambdas have made it in to mainstream programming languages. Has anything similar happened with APL?
I am blown away to see how frequently APL seems to come up on HN these days, a language I used professionally for over ten years. As much as I love it I have to say one of the issues with APL is that it was way ahead of it's time. Because of that it struggled to run on computers of that era. I was introduced to the language in 1982~ish. Like I said, I used it extensively, attended and presented at APL conferences and…
Lisp was also far ahead of its time, but many Lisp features like garbage collection and lambdas have made it in to mainstream programming languages. Has anything similar happened with APL?
Also, the [1] https://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgo...
Earlier quoted context omitted.
Stuff like +/v is easier to reason about, but it's also handled by special code which runs a lot faster. At some point I need to do a blog on all the horrible things that happen inside your computer (cache hits, memory being swapped in and out, stacks popping) when you do an interpreted, explicit loop; bytecode, AST or whatever. There are R&D interpretors which claim to remove this overhead for trivial for loops,whic…
> handled by special code which runs a lot faster This is just another way of saying "we don't have a compiler, so don't process data at the element level if you want speed". It is not an advantage of the language, but a disadvantage. If you have a compiler, then it's only valid for aggressive, machine-specific optimizations. This is articulated by statements like "the library function is marginally faster than an op…
I encourage you to try writing an FFT routine in C yourself and compare it to FFTW, where they basically wrote a compiler for doing FFTs. It's also worth doing in an interpreted language in an array-wise fashion versus with a for-loop. You should get something like a factor of 100,000 speed up.
I am blown away to see how frequently APL seems to come up on HN these days, a language I used professionally for over ten years. As much as I love it I have to say one of the issues with APL is that it was way ahead of it's time. Because of that it struggled to run on computers of that era. I was introduced to the language in 1982~ish. Like I said, I used it extensively, attended and presented at APL conferences and…
You ever try the modern Dyalog offering with .NET, SQL, and R interop? Pretty cool stuff although I don't really use the language. There is a guy here writing a compiler for Dyalog APL that runs on a GPU, but is only a few pages of APL. If that isn't the future, I don't know what is.
Looks like the site is hugged to death :-( My only experience with APL-like languages was playing with K for a few months. It's amazing, no other language can do so much in a few characters. Here's a list of hundreds of snippets: http://code.kx.com/wiki/Qidioms To give a taste of K style, I'll try to explain one of those snippets here. The problem statement is to merge three arrays x, y, z under control of another ar…
$ txr This is the TXR Lisp interactive listener of TXR 173. Use the :quit command or type Ctrl-D on empty line to exit. 1> (let ((l '#"abcd 123456789 zz") (i '(1 0 1 1 2 1 2 1 1 0 1 0 1 0 1))) (gun (pop [l (pop i)]))) (#\1 #\a #\2 #\3 #\z #\4 #\z #\5 #\6 #\b #\7 #\c #\8 #\d #\9) Conversion to string: 2> (let ((l '#"abcd 123456789 zz") (i '(1 0 1 1 2 1 2 1 1 0 1 0 1 0 1))) (cat-str (gun (pop [l (pop i)])))) "1a23z4z56…
There's no such requirement, < (and by extension <<) returns the same result for 0 1 0 2, "0102" or "abac".
Earlier quoted context omitted.
> handled by special code which runs a lot faster This is just another way of saying "we don't have a compiler, so don't process data at the element level if you want speed". It is not an advantage of the language, but a disadvantage. If you have a compiler, then it's only valid for aggressive, machine-specific optimizations. This is articulated by statements like "the library function is marginally faster than an op…
Forcing your compiler to figure out you're doing something trivial on a rank-n array is silly. So is writing all the overhead and logic (where a typo can break things) which goes into a for or while loop instead of two characters: +/ I encourage you to try writing an FFT routine in C yourself and compare it to FFTW, where they basically wrote a compiler for doing FFTs. It's also worth doing in an interpreted language…
What is the alternative, if there is no canned procedure for it?
The procedure has to be written somewhere, somehow, in some language.
If compilers are silly, assembly, I guess?
Earlier quoted context omitted.
$ txr This is the TXR Lisp interactive listener of TXR 173. Use the :quit command or type Ctrl-D on empty line to exit. 1> (let ((l '#"abcd 123456789 zz") (i '(1 0 1 1 2 1 2 1 1 0 1 0 1 0 1))) (gun (pop [l (pop i)]))) (#\1 #\a #\2 #\3 #\z #\4 #\z #\5 #\6 #\b #\7 #\c #\8 #\d #\9) Conversion to string: 2> (let ((l '#"abcd 123456789 zz") (i '(1 0 1 1 2 1 2 1 1 0 1 0 1 0 1))) (cat-str (gun (pop [l (pop i)])))) "1a23z4z56…
> I won't bother implementing the apparent requirement that the indices be digit characters from a string; I consider it a serious blemish on the language, if it's doing it implicitly. There's no such requirement, < (and by extension <<) returns the same result for 0 1 0 2, "0102" or "abac".
Obviously, there is here a language-level requirement in K that 0, "0" or "a" all denote an index zero, at least in the exemplified situation.
Though that may help get points on http://codegolf.stackexchange.com, it comes across as rather arbitrary.
We could easily acheive the same thing without pushing it into the language, at the cost of making a function call, which could have a one-letter name.
12> (defun $ (x)
(cond
((numberp x) x)
((chr-digit x))
((chr-isalpha x) (- (chr-tolower x) #\a))))
13> ($ #\b)
1
14> [mapcar $ "cdba"]
(2 3 1 0)
15> [mapcar $ #(1 3 9 5)]
#(1 3 9 5)
16> [mapcar $ "012a3"]
(0 1 2 0 3)