4 ms·

I had some fun with J. But it's (you know what I'll say) too cryptic.. Let's take an example from RosettaCode. For instance, merge sort: merge =: ,`((

by lcedp 13y ago

I had some fun with J. But it's (you know what I'll say) too cryptic.. Let's take an example from RosettaCode. For instance, merge sort: merge =: ,`(({.@] , ($: }.))~` ({.@] , ($: }.)) @.(>&{.))@.(*@*&#) split =: </.~ 0 1$~# mergeSort =: merge & $: &>/ @ split ` ] @. (1>:#) I could probably write it, but read what it does in a few weeks?

michaelfeathers 13y ago
Maybe it takes more than a few weeks. People half-way across the world read text like this everyday: 中國哲學書電子化計 C looks like that to most non-programmers. We forgot how much we have acclimated to already.
- lcedp 13y ago
  Actually it's a very good example. Is 中 a word? Or 中國 a word? Or 中國哲 is a word? One can't say until they read a full sentence, making sense of it and distinguishing words from context. Similarly, can you clearly distinguish operators here ",`(({.@] , ($: }.))~` ({.@] , ($: }.)) @.(>&{.))@.(@&#)"? Sure, we can acclimate to a lot. Assembler is also a language. But nobody gonna write Hacker News in it.
  - gd1 13y ago
    Don't mistake looking complex for being complex. These languages have very simple and clean grammars (or they'd fall apart quickly), which is quite a contrast to the dog's breakfast that is modern C++. A simple grammar = simple to read once you've learnt the syntax. There's no issue in having a lot of symbolic operators if they all work in a clean and consistent way.
    - kd0amg 13y ago
      Unfortunately, J's grammar isn't the cleanest. It uses juxtaposition to mean about a dozen different things depending on whether the tokens are data, first-order functions, or second-order functions and how many are juxtaposed. A variable could stand for any of these. If there are variables in the expression, you have to know which variables stand for which kinds of objects in order to parse the expression.
silentbicycle 13y ago
You'd be surprised. I'm more familiar with k (kona) than J, but many of those seemingly inscrutable blocks of punctuation become recognizable as a unit pretty quickly. You can, of course, break huge expressions like that apart and name the chunks. kona: https://github.com/kevinlawler/kona https://github.com/kevinlawler/kona A free implementation of a k3.2-like language. There are equally strange patterns that you are probably used to. For example, I see stuff like PORTB &=~(1<<3); when doing embedded development. That's C, and unlike in J, in C I have to also keep track of order of operations.
gd1 13y ago
I find it much easier to read some Q/KDB I've written earlier than the equivalent C++ or C#/Java. For three reasons: 1) It is extremely terse. A small block of code will do what pages of boilerplate class definitions, interfaces, setters/getters, declarations, typedefs etc. will achieve. There is usually no need to navigate through a spaghetti chain of virtual function calls. 2) It is interpreted. I can quickly (without compiling) cut out chunks of the code and run them to understand what they are doing. I can create variables on the fly, fill them with test data, and run the function. If it calls another function, I execute the name of the function and it returns the function code, since functions themselves are first class variables. 3) It actually becomes easy to read because it is easy to parse, for both machine and human. K/Q is read right to left, and so breaks some traditional conventions. For example, 5*6+3 will evaluate to 45, not 33. At first this can be disconcerting, but eventually you will realise that parsing a line of code no matter how complex it looks is quite simple - you mentally start at the rightmost token and start gobbling. This is probably why the interpretor is so fast as well. As someone mentioned below, I'm not sure why you'd consider it "too cryptic". Anything is cryptic when you first encounter it. I suppose the difference is that Q/KDB provides an (extremely valuable) solution to the financial world - the handling of big data long before it was even called that (a tick database with billions or trillions of rows) so there is a valid motivation to learn the language and it doesn't feel cryptic at all once you've immersed yourself in it.
- lmm 13y ago
  Python wasn't cryptic when I first encountered it. There are many things wrong with python, but using ordinary words for operators ("or", "in") was one thing it got very very right, and I wish there was a more functional/typed language that took the same approach.
  - beagle3 13y ago
    APL and K draw their inspiration from math. Python wasn't cryptic, but it is confusing unless you have a programming background. the fact that "and" and "or" short circuit. The fact that "1/2 is 0" (at least before Python 3), and that "1000+1000 is not 2000", even though "1000+1000 == 2000" Or that "0.3*3 <> 0.9" (if you knew that <> means not equal)
rossjudson 13y ago
Why do you think a given language must have only one representation? There are core concepts at the heart of J and K. This tight syntax is one way they can be expressed, but there are others. We are certainly not limited to the simplistic character editors of the past. More than one simultaneous representation of a program can be shown and worked with -- concise, extended, graphical...

by lcedp 13y ago

michaelfeathers 13y ago

Maybe it takes more than a few weeks. People half-way across the world read text like this everyday: 中國哲學書電子化計 C looks like that to most non-programmers. We forgot how much we have acclimated to already.

lcedp 13y ago
Actually it's a very good example. Is 中 a word? Or 中國 a word? Or 中國哲 is a word? One can't say until they read a full sentence, making sense of it and distinguishing words from context. Similarly, can you clearly distinguish operators here ",`(({.@] , ($: }.))~` ({.@] , ($: }.)) @.(>&{.))@.(@&#)"? Sure, we can acclimate to a lot. Assembler is also a language. But nobody gonna write Hacker News in it.
- gd1 13y ago
  Don't mistake looking complex for being complex. These languages have very simple and clean grammars (or they'd fall apart quickly), which is quite a contrast to the dog's breakfast that is modern C++. A simple grammar = simple to read once you've learnt the syntax. There's no issue in having a lot of symbolic operators if they all work in a clean and consistent way.
  - kd0amg 13y ago
    Unfortunately, J's grammar isn't the cleanest. It uses juxtaposition to mean about a dozen different things depending on whether the tokens are data, first-order functions, or second-order functions and how many are juxtaposed. A variable could stand for any of these. If there are variables in the expression, you have to know which variables stand for which kinds of objects in order to parse the expression.

silentbicycle 13y ago

You'd be surprised. I'm more familiar with k (kona) than J, but many of those seemingly inscrutable blocks of punctuation become recognizable as a unit pretty quickly. You can, of course, break huge expressions like that apart and name the chunks. kona: https://github.com/kevinlawler/kona https://github.com/kevinlawler/kona A free implementation of a k3.2-like language. There are equally strange patterns that you are probably used to. For example, I see stuff like PORTB &=~(1<<3); when doing embedded development. That's C, and unlike in J, in C I have to also keep track of order of operations.

gd1 13y ago

I find it much easier to read some Q/KDB I've written earlier than the equivalent C++ or C#/Java. For three reasons: 1) It is extremely terse. A small block of code will do what pages of boilerplate class definitions, interfaces, setters/getters, declarations, typedefs etc. will achieve. There is usually no need to navigate through a spaghetti chain of virtual function calls. 2) It is interpreted. I can quickly (without compiling) cut out chunks of the code and run them to understand what they are doing. I can create variables on the fly, fill them with test data, and run the function. If it calls another function, I execute the name of the function and it returns the function code, since functions themselves are first class variables. 3) It actually becomes easy to read because it is easy to parse, for both machine and human. K/Q is read right to left, and so breaks some traditional conventions. For example, 5*6+3 will evaluate to 45, not 33. At first this can be disconcerting, but eventually you will realise that parsing a line of code no matter how complex it looks is quite simple - you mentally start at the rightmost token and start gobbling. This is probably why the interpretor is so fast as well. As someone mentioned below, I'm not sure why you'd consider it "too cryptic". Anything is cryptic when you first encounter it. I suppose the difference is that Q/KDB provides an (extremely valuable) solution to the financial world - the handling of big data long before it was even called that (a tick database with billions or trillions of rows) so there is a valid motivation to learn the language and it doesn't feel cryptic at all once you've immersed yourself in it.

lmm 13y ago
Python wasn't cryptic when I first encountered it. There are many things wrong with python, but using ordinary words for operators ("or", "in") was one thing it got very very right, and I wish there was a more functional/typed language that took the same approach.
- beagle3 13y ago
  APL and K draw their inspiration from math. Python wasn't cryptic, but it is confusing unless you have a programming background. the fact that "and" and "or" short circuit. The fact that "1/2 is 0" (at least before Python 3), and that "1000+1000 is not 2000", even though "1000+1000 == 2000" Or that "0.3*3 <> 0.9" (if you knew that <> means not equal)

rossjudson 13y ago

Why do you think a given language must have only one representation? There are core concepts at the heart of J and K. This tight syntax is one way they can be expressed, but there are others. We are certainly not limited to the simplistic character editors of the past. More than one simultaneous representation of a program can be shown and worked with -- concise, extended, graphical...