Why should I learn this language that I've never heard of if it can't even do math in any sensible way? Not left-to-right, not order of operations, not lisp-like prefix. Who thought that was a good idea?
I'm lucky to know a little K. The language basically takes this one idea: instead of processing objects one by one with lambdas and the like, use bulk high-level operations on whole datastructures at once. And really runs with it. For example, it has an SQL DBMS written without loops, using only bulk vector operations.
Found it on the internet and was intrigued. Wrote them an email, got an educational version, read the manual very thoroughly, made up exercises and solved them, read and tried to understand a lot of code. I especially recommend "K finger exercises" http://www.kx.com/technical/contribs/eugene/kidioms.html . Then I taught my brother a little - he was into trading at the time, wrote his graduate thesis on time-series analysis and now works at a hedge fund.
My own personal opinion is that whatever language you're using (or, indeed, in mathematics) using redundant brackets is generally the best idea anyway.
Removes any ambiguity, easier to read, doesn't need you to remember precedence rules and there's negligible difference in execution speed.
Lisp's grammar doesn't do precedence, so effectively it forces you to fully parenthesize all expressions anyway. The brackets the poster was talking about aren't "redundant" in Lisp in the first place.
Isn't python (no brackets at all) an existence proof that you're wrong, though? The eye learns rapidly to ignore brackets. What it reads is indentation. And most editors will try to enforce indentation levels even without brackets present.
Or maybe you're just talking about parentheses in precedence grammars? I guess I have no objections there, but still: the fact that "multiplication has higher precedence than addition" is taught in grade schools and is used everywhere, in every language I know that supports precedence at all. What conceivable purpose could one have to buck this trend? All you gain is maybe a few lines of complexity in the parser (I mean, it's not like these things are hard to write) at the cost of a lifetime of newbie syntax errors.
If the newbie programmers are professionals worthy of the name, those errors won't make it into production. A less complex parser will have tremendous leverage by making it easier to craft syntax-aware programming tools. Smalltalk has a history of amazing ground-breaking programmer tools written by single individuals years ahead of their appearance in other languages. Contrast this with Ruby. I like Ruby a lot. It's a great language. The syntax is a bit hairy, however. Teams of people worked for a couple of years to produce an ANTLR parser which is independent of the Ruby VM's parser and could be used for programming tools.
A good programmer can just crank out a top-down Smalltalk parser in one day. If you make your language easy to work with, you get a more powerful toolset sooner. On top of that, the lowered barrier to entry gets you more real innovation in that toolset.
Well, order of precedence rules are much more complex in programming languages, and are not the same across languages. Mixing math with logic and bitwise operators without explicit parens is a classic "newbie" mistake.
Smalltalk also has different precedence rules. Assignment is highest, followed by unary ops, binary ops, then keyword messages. In some cases, this results in expressions evaluating left to right.
This is often the biggest complaint from outsiders. But it's easily solved by including parenthesis now and then. In 10 years of doing Smalltalk, I've never encountered a situation where this is ever an issue. I've never encountered a but caused by math expression precedence. Newb Smalltalkers might make the mistake, but they generally correct it in the next second. So much for the first impression of programmers who are unfamiliar with the language.
In 10 years of Smalltalk, I've also never encountered a situation where Smalltalk execution was slow -- it was always poorly designed (low-latency favoring in a high-latency environment) database IO. If anything, I've always been impressed with how fast the commercial VMs are.
My point: the "popular notions" about programming languages are often as misleading as urban legends.
>Why should I learn this language that I've never heard of if it can't even do math in any sensible way? Not left-to-right, not order of operations, not lisp-like prefix. Who thought that was a good idea?
Of the three choices you mention only one makes sense as an alternative: left-to-right instead of right-to-left.
Order of operations, as it turns out, has nothing at all to do with real computation (in the same way that pi really should have been defined as 2pi). Most educated people, after a moment of reflection, should agree with this statement. Getting rid of order of operations makes the parsing process simpler, both for the compiler and for your head. If order of operations wasn't so ingrained in your head there would be no reason at all to use it. K makes a lot of design decisions like these: doing what's right at the expense of what's common.
I'm not sure where order of operations came from, probably as a nicety for mathematicians dealing with complicated polynomials, but when computers came about it must've been clear that it was the wrong way to do things.
Here's a code snippet that makes order of operations look just as silly:
a*b+c%d%e+f*g^h*i*j*k-l / ugly with order of operations, hidden levels of complexity
Lisp prefix form, from a mathematical point of view, certainly makes more sense than order of operations. The reason it isn't used in K is, for one, K is inline, and two, Lisp syntax demands a lot more written code than K, and this goes against the philosophy of K. K wants to create the shortest programs in the shortest amount of time.
For example, something that is perfectly natural in K
2+7%3*2+5 / k, 9 characters - 1 level deep
looks ridiculous in Lisp
(+ 2 (% 7 (* 3 (+ 2 5))))
;Lisp, 25 characters - 8 spaces, 8 parentheses, 4 levels deep
;Two parentheses and one level of nesting for each operation
for the reason that Lisp is not as rabid about brevity as K is. (And how could it be. K is a much newer language.)
This leaves left-to-right evaluation. One argument against left-to-right evaluation is the following code:
f g
where f is any function. For instance
g:3
f:{1+x}
f f g
5
and so on. But this presumes that you accept two axioms (1. you should read left-to-right as in English 2. functions should precede operands). I am currently of the opinion that left-to-right evaluation is better given a left-to-right read order
g f f / 5, fictional example
because I've yet to discover sound reasoning why mathematicians believe the function should precede the operand. (The answer may be that there isn't a reason, and mathematicians did it that way only because they never cared enough to pay close attention to syntax. Or perhaps it's because written mathematics "executes" in English, and not in an interpreter.)
The language designer has defended right-to-left evaluation with the following statements. "Why right-to-left?"
so that it reads left to right.
note k executes left of right, e.g. syracuse operation: 1+3*
the basic math notation is:
f g h x
executes right to left but reads
f of g of h of x
I remain unconvinced, especially since there are benefits to left-to-right execution (presuming left-to-right read order) including on-the-fly processing. It just seems more natural to me, mathematically, though I admit it would be very unnatural for me to write in such a way.
K is a beautiful language with a lot of nice features. Anything truly innovative is going to look new and different, and in K you get the statement
3*2+5 / yields 21
There are a lot of unusual looking things in K. There are also lots of very powerful ones. But these won't reveal themselves until you spend a time looking at the language. So my suggestion is if you are intrigued by the powerful stuff, keep looking, and don't be turned off by the strangeness of the simple stu...
From what I gather, it's used mainly by quantitative analysts in finance (so called "quants"), but I'm sure it could be applied to a wide variety of other fields.
Nifty reference, thanks. You absolutely have to read the description in the original page though. The K looks pretty much line line noise; I've seen raw sendmail scripts that look cleaner. As terse as the language might be, a little whitespace and naming conventions might still be a good idea for us newbies...
a little whitespace and naming conventions might still be a good idea for us newbies
The culture around K is fanatical about concision. This goes back to APL, though the K people (following the lead of Arthur Whitney, the designer of K and Q) take it further than anybody else. To the unfamiliar, K looks like a bad joke (check out the 40 lines of code at http://www.nsl.com/k/s/s.k, which implement the spreadsheet at http://www.nsl.com/papers/spreadsheet.htm), but these people know what they're doing. Whitney's product includes the language interpreter, a massively scalable RDBMS, a web server, and God knows what else, and the last time I downloaded it, the total size was 380 KB. My experience with that stuff was that the more I looked at it, the more in awe I became. It's a shame it's not more widely available.
If anyone is interested in some examples, take a look at projecteuler.net - it's a series of mathematical/programming puzzles.
After you solve a particular problem you gain access to a forum where people detail their solution. A good amount of the solutions tend to be written in these APL languages (J, K) and may serve as a nice way to learn.
26 comments
[ 2.7 ms ] story [ 69.3 ms ] thread3*2+5 / yields 21
Why should I learn this language that I've never heard of if it can't even do math in any sensible way? Not left-to-right, not order of operations, not lisp-like prefix. Who thought that was a good idea?
Also, they recently made q/kdb+ available for download http://www.kx.com/developers/software.php , which turned some of my friends on to it :-)
Removes any ambiguity, easier to read, doesn't need you to remember precedence rules and there's negligible difference in execution speed.
Or maybe you're just talking about parentheses in precedence grammars? I guess I have no objections there, but still: the fact that "multiplication has higher precedence than addition" is taught in grade schools and is used everywhere, in every language I know that supports precedence at all. What conceivable purpose could one have to buck this trend? All you gain is maybe a few lines of complexity in the parser (I mean, it's not like these things are hard to write) at the cost of a lifetime of newbie syntax errors.
A good programmer can just crank out a top-down Smalltalk parser in one day. If you make your language easy to work with, you get a more powerful toolset sooner. On top of that, the lowered barrier to entry gets you more real innovation in that toolset.
This is often the biggest complaint from outsiders. But it's easily solved by including parenthesis now and then. In 10 years of doing Smalltalk, I've never encountered a situation where this is ever an issue. I've never encountered a but caused by math expression precedence. Newb Smalltalkers might make the mistake, but they generally correct it in the next second. So much for the first impression of programmers who are unfamiliar with the language.
In 10 years of Smalltalk, I've also never encountered a situation where Smalltalk execution was slow -- it was always poorly designed (low-latency favoring in a high-latency environment) database IO. If anything, I've always been impressed with how fast the commercial VMs are.
My point: the "popular notions" about programming languages are often as misleading as urban legends.
Well, Ken Iverson did, and he won a Turing for his trouble.
Of the three choices you mention only one makes sense as an alternative: left-to-right instead of right-to-left.
Order of operations, as it turns out, has nothing at all to do with real computation (in the same way that pi really should have been defined as 2pi). Most educated people, after a moment of reflection, should agree with this statement. Getting rid of order of operations makes the parsing process simpler, both for the compiler and for your head. If order of operations wasn't so ingrained in your head there would be no reason at all to use it. K makes a lot of design decisions like these: doing what's right at the expense of what's common.
I'm not sure where order of operations came from, probably as a nicety for mathematicians dealing with complicated polynomials, but when computers came about it must've been clear that it was the wrong way to do things.
Here's a code snippet that makes order of operations look just as silly:
Lisp prefix form, from a mathematical point of view, certainly makes more sense than order of operations. The reason it isn't used in K is, for one, K is inline, and two, Lisp syntax demands a lot more written code than K, and this goes against the philosophy of K. K wants to create the shortest programs in the shortest amount of time.For example, something that is perfectly natural in K
looks ridiculous in Lisp for the reason that Lisp is not as rabid about brevity as K is. (And how could it be. K is a much newer language.)This leaves left-to-right evaluation. One argument against left-to-right evaluation is the following code:
where f is any function. For instance and so on. But this presumes that you accept two axioms (1. you should read left-to-right as in English 2. functions should precede operands). I am currently of the opinion that left-to-right evaluation is better given a left-to-right read order because I've yet to discover sound reasoning why mathematicians believe the function should precede the operand. (The answer may be that there isn't a reason, and mathematicians did it that way only because they never cared enough to pay close attention to syntax. Or perhaps it's because written mathematics "executes" in English, and not in an interpreter.)The language designer has defended right-to-left evaluation with the following statements. "Why right-to-left?"
I remain unconvinced, especially since there are benefits to left-to-right execution (presuming left-to-right read order) including on-the-fly processing. It just seems more natural to me, mathematically, though I admit it would be very unnatural for me to write in such a way.K is a beautiful language with a lot of nice features. Anything truly innovative is going to look new and different, and in K you get the statement
There are a lot of unusual looking things in K. There are also lots of very powerful ones. But these won't reveal themselves until you spend a time looking at the language. So my suggestion is if you are intrigued by the powerful stuff, keep looking, and don't be turned off by the strangeness of the simple stu...I'm also interested in what industries this language perfoms well.
The culture around K is fanatical about concision. This goes back to APL, though the K people (following the lead of Arthur Whitney, the designer of K and Q) take it further than anybody else. To the unfamiliar, K looks like a bad joke (check out the 40 lines of code at http://www.nsl.com/k/s/s.k, which implement the spreadsheet at http://www.nsl.com/papers/spreadsheet.htm), but these people know what they're doing. Whitney's product includes the language interpreter, a massively scalable RDBMS, a web server, and God knows what else, and the last time I downloaded it, the total size was 380 KB. My experience with that stuff was that the more I looked at it, the more in awe I became. It's a shame it's not more widely available.
After you solve a particular problem you gain access to a forum where people detail their solution. A good amount of the solutions tend to be written in these APL languages (J, K) and may serve as a nice way to learn.