3 ms·

Interesting syntax, a bit SQLish but.. friendlier? The source link is broken unfortunately, I'm wondering how performant it is. It made me immediately think of

Interesting syntax, a bit SQLish but.. friendlier? The source link is broken unfortunately, I'm wondering how performant it is. It made me immediately think of articles recently discussing using plain text manipulation through tools like awk, sed, cut, and cat as opposed to the current batch of distributed processing tools. A language like this strikes me as a step up from those tools in terms of writing readable and expressive data manipulation and a comfortable step down from complicated object notations.

brudgers 12y ago
My take is that it's an APL inspired language. I stumbled on it because I am interested in Iverson's APL refresh, J. It solves the problem of APL's specialized character set by mapping mathematical notation out to the same sort of psuedo-English as other programming languages. On the other hand, Iverson kept closer to his original intent and mapped everything to ASCII symbols in J. In a sense, I think all three languages occupy the same sort of space as Fortran and Matlab [and increasingly Python]: numerical modeling where `3` doesn't just represent the mass of a sack of beans but a particular three kilo sack of beans itself. What I found interesting is that it is only superficially more comprehensible than J or rather that J is only superficially less comprehensible. I need to look at the documentation in both. Symbols aren't any less syntactically clear than pseudo-English keywords. The advantage of J is that it assumes that the meaning of symbols isn't obvious. [APL]: http://pckeyboard.com/page/product/USAPLSET http://pckeyboard.com/page/product/USAPLSET [J]: http://www.jsoftware.com/ http://www.jsoftware.com/
- RodgerTheGreat 12y ago
  It reminds me even more of Q[0], a derivative of K which similarly replaces many operators with named words. I agree with your conclusion that given complex primitive operators a name seems to be only superficially more "intuitive" than an arbitrary symbol. The need to memorize some collection of primitives before programs can be read seems to be a troubling barrier to beginners in any APL-family language, and I'm not sure how it could be addressed. [0] http://code.kx.com/wiki/JB:QforMortals/overview http://code.kx.com/wiki/JB:QforMortals/overview
  - brudgers 12y ago
    I think the solution is not to fret to much over beginners and focus on the people who are trying to solve problems that make learning a new language worth it. It's like regular expressions - because they describe state machines there's a limit to how far you can dumb things down. Any programming language that seeks to map well to mathematical notation is going to have a particular set of abstractions and therefore require a particular mindset. We don't expect maths to be easy for beginners...taking off just a few of the painful sharp corners is considered a big big win. Why should other languages for describing computation be considered failures or successes under different criteria?
thisrod 12y ago
I think the examples would be clearer and shorter if they were written in AWK. They might not be showing Nial in its best light: they solve very simple problems, AWK's sweet spot, but a field where Nial is bloated by features that need more complicated problems in order to pay their overhead. The question is how often such problems actually arise.

brudgers 12y ago

My take is that it's an APL inspired language. I stumbled on it because I am interested in Iverson's APL refresh, J. It solves the problem of APL's specialized character set by mapping mathematical notation out to the same sort of psuedo-English as other programming languages. On the other hand, Iverson kept closer to his original intent and mapped everything to ASCII symbols in J. In a sense, I think all three languages occupy the same sort of space as Fortran and Matlab [and increasingly Python]: numerical modeling where `3` doesn't just represent the mass of a sack of beans but a particular three kilo sack of beans itself. What I found interesting is that it is only superficially more comprehensible than J or rather that J is only superficially less comprehensible. I need to look at the documentation in both. Symbols aren't any less syntactically clear than pseudo-English keywords. The advantage of J is that it assumes that the meaning of symbols isn't obvious. [APL]: http://pckeyboard.com/page/product/USAPLSET http://pckeyboard.com/page/product/USAPLSET [J]: http://www.jsoftware.com/ http://www.jsoftware.com/

RodgerTheGreat 12y ago
It reminds me even more of Q[0], a derivative of K which similarly replaces many operators with named words. I agree with your conclusion that given complex primitive operators a name seems to be only superficially more "intuitive" than an arbitrary symbol. The need to memorize some collection of primitives before programs can be read seems to be a troubling barrier to beginners in any APL-family language, and I'm not sure how it could be addressed. [0] http://code.kx.com/wiki/JB:QforMortals/overview http://code.kx.com/wiki/JB:QforMortals/overview
- brudgers 12y ago
  I think the solution is not to fret to much over beginners and focus on the people who are trying to solve problems that make learning a new language worth it. It's like regular expressions - because they describe state machines there's a limit to how far you can dumb things down. Any programming language that seeks to map well to mathematical notation is going to have a particular set of abstractions and therefore require a particular mindset. We don't expect maths to be easy for beginners...taking off just a few of the painful sharp corners is considered a big big win. Why should other languages for describing computation be considered failures or successes under different criteria?

thisrod 12y ago

I think the examples would be clearer and shorter if they were written in AWK. They might not be showing Nial in its best light: they solve very simple problems, AWK's sweet spot, but a field where Nial is bloated by features that need more complicated problems in order to pay their overhead. The question is how often such problems actually arise.