K as a Prototyping Language
cs.nyu.edu
cs.nyu.edu
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.
3*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:
a*b+c%d%e+f*g^h*i*j*k-l / ugly with order of operations, hidden levels of complexity
For example, something that is perfectly natural in K
2+7%3*2+5 / k, 9 characters - 1 level deep
(+ 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
This leaves left-to-right evaluation. One argument against left-to-right evaluation is the following code:
f g
g:3
f:{1+x}
f f g
5
g f f / 5, fictional example
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
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
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.
I'm also interested in what industries this language perfoms well.