Earlier quoted context omitted.
Except that a machine language program would be thousands if not millions of times as long. Readability is relative. Java is unreadable to my grandmother. Turkish is unreadable to me. In other words, the opinion of someone who hasn't learned a language regarding its readability is irrelevant. It is true that the way you read a language like this is different from the way you read Java. You don't expect to grok a line…
> Except that a machine language program would be thousands if not millions of times as long. Oi, I seriously doubt that. Seriously, millions? It's all math. Take a couple of assembler instructions per operation. I bet there's 256 byte assembler demo's out there...
A raytracer in 7 lines of 'K'
31–40 of 41 posts
Re: A raytracer in 7 lines of 'K'
#32You know, 7 lines or not, name your goddamned variables. I'd fire someone who presented me with code like this.
I worked at a K shop last summer, and when I was learning the language, I tried using sensible variable names. I was told in no uncertain terms that, when you write K, local variables should be one letter, globals should be two, and functions should be three. It sounds like a total disaster, but after about two weeks (which is a long-ass time to learn a language), everything made perfect sense, and I really enjoyed u…
Also, I'm curious how their database stacks up: what's it better/worse at? It seems like magic for a program so small to do so much so well. I'd like to know what the tradeoffs are. (Either that or move to their universe.)
Re: A raytracer in 7 lines of 'K'
#33You know, 7 lines or not, name your goddamned variables. I'd fire someone who presented me with code like this.
Using single letters in a piece of code helps in outlining the structure, instead of the contents. That is why mathematical formulas are written with x, y, and z instead of long names. The idea is that we are emphasizing the generic relations, not what might be fed to the function. Similarly, when writing functional code it is good style to use single letters instead of long names.
I went through something like this hacking in Lisp, actually. When I started out, I used long descriptive variable names; it's the CL style anyway (MULTIPLE-VALUE-BIND, anyone?) Over time, I found myself using shorter and shorter names, to the point where my code is now of the sort that some of the commenters here would apparently fire me for it. Yet it's not like I somehow became less passionate about readable, clear code. What gives?
It took me a while to figure out. As programs get shorter (because the level of abstraction gets higher), the shape of the code itself becomes increasingly meaningful. (I mean the physical shape of the code as it appears on the screen.) This is doubly true of languages with very regular syntax like Lisp and K, and is a huge advantage to such regularity. Partly this is just that, since the program is shorter, more of it fits on one screen. But I think it's a deeper and more mysterious effect than that. You begin to develop an intuition for different patterns that have different semantics, as it were. Grokking these patterns becomes a big part of what you do when you read this sort of code. This effect is weaker in mainstream languages, so it's not surprising that people aren't aware of it. (Edit: although I used to joke that I could tell how good C# code was by printing out reams of it, hanging it on a wall, and stepping back 15 feet. That's an example of the effect too. It's just that in more powerful languages you don't have to step back 15 feet to see it.)
When you're working in a verbose language, long variable names are indispensable. You've got a whole lot of lines of code to read through, and a name like "x" does nothing to orient you as you switch contexts. But exactly the opposite is true of dense, concise programs. Variable names as long as even, say, "customerID" will dominate such programs textually, obscuring their natural shape. To increase overall clarity, you have to shorten those names to a length consonant with their semantic role. In other words, this style evolved not because people don't care about readability but because they are trying to maximize it. A convention like "one letter for local vars, two for global, and three for functions" is exactly the sort of thing that would help achieve this in a language like K.
Ironically, I have given a verbose expansion of what you just said:
Using single letters in a piece of code helps in outlining the structure, instead of the contents.[...] The idea is that we are emphasizing the generic relations
My excuse is exploratory writing: I've been meaning to write about this for a while to clarify how it works in my head. And I don't have time to make it shorter :)
Re: A raytracer in 7 lines of 'K'
#34Earlier quoted context omitted.
Breaking into many lines and renaming variables would go a long way to make this code look more like C.
For a transformation in the opposite direction, here's a first draft interpreter for J (a related language) in J-ish C. http://www.jsoftware.com/jwiki/Essays/Incunabulum It segfaults, because it's written in rather non-portable C that assumes sizeof(function pointer) == sizeof(int), among other things. It's an interesting piece of code, though. I don't completely understand it - I'm confused by the concept of rank in…
Rank shouldn't be something to get confused about; if it is you're probably overthinking it.
What did you find confusing about it?
Re: A raytracer in 7 lines of 'K'
#35Earlier quoted context omitted.
Using single letters in a piece of code helps in outlining the structure, instead of the contents. That is why mathematical formulas are written with x, y, and z instead of long names. The idea is that we are emphasizing the generic relations, not what might be fed to the function. Similarly, when writing functional code it is good style to use single letters instead of long names.
Absolutely. These conventions are not arbitrary and the people working within them are not stupid. That they would lead to poor code in a completely different language is beside the point. I went through something like this hacking in Lisp, actually. When I started out, I used long descriptive variable names; it's the CL style anyway (MULTIPLE-VALUE-BIND, anyone?) Over time, I found myself using shorter and shorter n…
Re: A raytracer in 7 lines of 'K'
#36Earlier quoted context omitted.
For a transformation in the opposite direction, here's a first draft interpreter for J (a related language) in J-ish C. http://www.jsoftware.com/jwiki/Essays/Incunabulum It segfaults, because it's written in rather non-portable C that assumes sizeof(function pointer) == sizeof(int), among other things. It's an interesting piece of code, though. I don't completely understand it - I'm confused by the concept of rank in…
Please take this not as an insult but as invitation to offer help. Rank shouldn't be something to get confused about; if it is you're probably overthinking it. What did you find confusing about it?
Thanks for the offer, but I didn't get that far because I decided I was better off focusing on Erlang for the time being. I'm very curious about that language family, I'm just trying to not spread myself too thin. When I get back to it, I'll try working through the J labs - it's probably a much better way to pick it up than untangling a semi-obfuscated interpreter.
Re: A raytracer in 7 lines of 'K'
#37Earlier quoted context omitted.
Please take this not as an insult but as invitation to offer help. Rank shouldn't be something to get confused about; if it is you're probably overthinking it. What did you find confusing about it?
I found the way that the linked interpreter above implements dimensions rather confusing, mostly. Thanks for the offer, but I didn't get that far because I decided I was better off focusing on Erlang for the time being. I'm very curious about that language family, I'm just trying to not spread myself too thin. When I get back to it, I'll try working through the J labs - it's probably a much better way to pick it up t…
I think it'd be easier to untangle if you already had a working knowledge of the language but given the line-noisy look of J I can't blame you for trying the shortcut.
The interactive J labs are very good. You might also find the J for C programmers discussion of rank particularly helpful if you are looking at learning by understanding an implementation.
I figure the array languages will make a minor comeback soon what with gpus / larrabee / etc showing up on the horizon and what with more-versatile input devices showing up (making it easier to go back to funky symbols instead of line noise).
Re: A raytracer in 7 lines of 'K'
#38Earlier quoted context omitted.
I worked at a K shop last summer, and when I was learning the language, I tried using sensible variable names. I was told in no uncertain terms that, when you write K, local variables should be one letter, globals should be two, and functions should be three. It sounds like a total disaster, but after about two weeks (which is a long-ass time to learn a language), everything made perfect sense, and I really enjoyed u…
Do tell us more about your experience. I'm fascinated with this stuff from afar. Also, I'm curious how their database stacks up: what's it better/worse at? It seems like magic for a program so small to do so much so well. I'd like to know what the tradeoffs are. (Either that or move to their universe.)
K is super-great at vector operations; element-wise addition between two lists of equal length, for example; more powerfully, mapping lists to functions.
The DB stuff we were doing were columnar databases, so it was incredibly fast at doing data analysis and correlations. Not so fast at adding single rows, but if you wanted to take a list of transactions and compare things day-over-day, or do sophisticated statistical operations, you simply had to write a line or two, and watch it take multiple million-element lists and give you an answer in milliseconds. I'm still pretty convinced it was voodoo magic.
When I used it, there was a pretty hefty license fee, but there's a trial version which limits the amount of memory it will use, but can still do quite a bit to give you a sense of the speed (as long as you're doing it right). Remember, no stinkin' loops!
Re: A raytracer in 7 lines of 'K'
#39Earlier quoted context omitted.
Do tell us more about your experience. I'm fascinated with this stuff from afar. Also, I'm curious how their database stacks up: what's it better/worse at? It seems like magic for a program so small to do so much so well. I'd like to know what the tradeoffs are. (Either that or move to their universe.)
Sorta forgot about this thread, but hopefully ou see this. K is super-great at vector operations; element-wise addition between two lists of equal length, for example; more powerfully, mapping lists to functions. The DB stuff we were doing were columnar databases, so it was incredibly fast at doing data analysis and correlations. Not so fast at adding single rows, but if you wanted to take a list of transactions and…
I was kind of afraid you would say that. I wish they'd open-source it.
It's such a pity that Peter Seibel didn't include Arthur Whitney in Coders at Work. I suggested him, IIRC, but he didn't get in. As far as I'm concerned he belongs in the top echelon. Here is what Roger Hui, the J guy and no slouch, said (I love this story):
Someone once asked Peggy Lee who she thought was the best jazz singer. Her answer was, You mean besides Ella? Likewise, the answer to the question Who's the best programmer? is Besides Arthur?
Edit: maybe if I'd included that in my suggestion to Seibel it would have helped :)
Re: A raytracer in 7 lines of 'K'
#40Earlier quoted context omitted.
I found the way that the linked interpreter above implements dimensions rather confusing, mostly. Thanks for the offer, but I didn't get that far because I decided I was better off focusing on Erlang for the time being. I'm very curious about that language family, I'm just trying to not spread myself too thin. When I get back to it, I'll try working through the J labs - it's probably a much better way to pick it up t…
Yeah I've not studied that interpreter so if that's your specific interest no luck sadly; rank is an easy idea but wouldn't surprise me if there's some trick to it in an implementation that short. I think it'd be easier to untangle if you already had a working knowledge of the language but given the line-noisy look of J I can't blame you for trying the shortcut. The interactive J labs are very good. You might also fi…
What specifically do you see as the fit between GPUs and array languages?