HN2new | past | comments | ask | show | jobs | submitlogin

> quicksort=: (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

Please, no. Glyphs / characters are not a scarce or constrained resource in software development. The major resource constraint is developer time spent writing, reading and debugging code. APL (and its descendants) are specifically designed to make these challenges far more difficult than they need to be.



I think it's worth suspending judgement and opinions about what you think a programming language should be and evaluate it on its own terms. The preceding is a terse form of the code, you can write it more verbosely. But just like regex, terse forms can be very useful once you understand them.


I could also see either the existing chain of ascii glyphs becoming more legible with some wisely-chosen syntax highlighting, or an editing environment where the ascii glyphs are used to produce something distinctive, and that might change how developers relate to the symbols.


Funny that you should say that. APL was designed to be easy to read, like how mathematicians can look at an equation and immediately get a feel for it.

"Notation as a Tool of Thought": http://www.jsoftware.com/papers/tot.htm


Also, another argument for this notation, is that you condense patterns to be very close to one another. Notice in Java and C# when you start using language features that support something like 'fluent' notation where you just append operators and the data 'flows' through. Eventually you'll start seeing obvious improvements, for instance a 'map' followed by a 'concat' might be better off as a 'collect'. APL and J focus on the idea of making very high level things accessible with symbols, and since the underlying structure is always an array, it's easier to judge what things are doing and when the operations can combine. What's more, once you combine them, you give clues to the compiler about your intent, and often further optimizations can be done.

It reminds me a bit of SQL Databases, in that the more indexes and constraints you add, the more the query execution can draw from to change the route a calc takes in order to try and do it more efficiently.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: