[HN Gopher] Ode to J
___________________________________________________________________
Ode to J
Author : lelf
Score : 131 points
Date : 2020-04-10 11:31 UTC (11 hours ago)
(HTM) web link (zserge.com)
(TXT) w3m dump (zserge.com)
| antigirl wrote:
| We did J in university. I hated it. We also did assembly and I
| much ordered that instead
| 7thaccount wrote:
| I think I would also hate J, APL, Prolog, Haskell, Forth, or
| Lisp in University.
|
| The problem is that those languages require a completely
| different shift in software from the common imperative/OO style
| to something more declarative or in Lisp's case, just a bit
| different.
|
| In a typical university course, there isn't enough time to
| focus on learning those things and you stay so shallow with the
| material that the language seems useless. It seems like 1/2 of
| the Prolog subreddit is about homework assignments on things
| like list reversal. If you can already do that in Python/Java
| with a single method call, Prolog just seems like a really
| bizarre and inefficient method. Now once you take another step
| and see how it can figure out how to solve Sudoku without
| explicit instructions...that is cool.
|
| It's really the same thing with electrical engineering when the
| professor is trying to teach us microprocessors and assembly at
| the same time and it all seems like a waste when C is much
| easier. The assembly method probably teaches better, but I need
| more than just a few weeks to synthesize that information.
| Especially when you're getting slammed by other hard classes
| like differential equations at the same time. So perhaps you do
| hate J, then again, maybe you just need to learn it on your own
| schedule and not to answer arbitrary test questions about
| something you can already do in Java.
| aidenn0 wrote:
| I don't know how it is in J, but having fielded Lisp
| questions from students learning Lisp (usually 1/3 or 1/2 of
| a semester class on "Programming Languages" or "Functional
| Programming"), the assignments tend towards _terrible_
| questions, to the point where I don 't think I could come up
| with questions that were better suited to making someone hate
| the language.
|
| People come out of a class that used Common Lisp thinking
| that Common Lisp lacks any looping construct (it has
| several). It looks like the professor took a SICP (which uses
| scheme, not common lisp) based class as an undergrad, never
| looked at any language in the lisp family again, and then 20
| years later made up a syllabus using the half-remembered
| information using Common Lisp because they remember SICP had
| something to do with Lisp and taught it without actually
| trying to do any of the exercises.
| smabie wrote:
| It seems like array languages are really picking up steam on HN
| lately; It's a positive development. Every developer should learn
| at least one array language. They sound absolutely crazy before
| you start, but then you start writing some code and you realize
| there's a lot of wisdom in the coding style. It's not something
| you can appreciate only from afar, though.
| Zhyl wrote:
| Similar logic as to why array languages are good can also be
| applied to why Linear Algebra is a good thing to learn,
| especially when you're in a calculation-heavy field. A lot of
| stuff can be abstracted away in a robust way that makes
| repetition unnecessary whilst also being able to reason about
| your equations/code.
| haolez wrote:
| I like to play with array languages in my free time. I have a
| doubt regarding readability:
|
| For me, it's easier to read APL with the symbols than to read
| J/K. Does it get better if you work a lot with J/K?
| ThomasBHickey wrote:
| Long ago I was doing some analysis on a Sigma 5/CP-V machine.
| One of the few high level languages available was Xerox APL.
| For those without an APL keyboard they provided ASCII
| replacements (I don't rember what they were, but looked like
| $NDX, $ASG). After learning APL with the awkward mnemonics I
| was never able to read it with the special characters! J does a
| much better standard-character APL.
| kick wrote:
| Absolutely yes for J and for k, but I wouldn't necessarily deem
| it necessary to use one or the other "a lot" just to get an
| intuitive grasp readability-wise.
| klipt wrote:
| Are there any open source compilers for J (and similar
| languages)?
| vchak1 wrote:
| I'd also suggest looking at Pike's ivy as a simple example of
| an apl like system in go. https://github.com/robpike/ivy
| arabelladonna wrote:
| J. J is open-source.
|
| Also, for K:
|
| https://github.com/kevinlawler/kona
| https://bitbucket.org/ngn/k/src/master/
| moonchild wrote:
| J[1], ngn/k[2], oK[3], kona[4], and GNU APL[5] are the big oss
| interpreters. The main closed-source ones are Dyalog APL, Kx k,
| and Shakti k (which are still free for non-commercial use).
|
| 1: https://github.com/jsoftware/
|
| 2: https://bitbucket.org/ngn/k/src/master/
|
| 3: https://github.com/JohnEarnest/ok
|
| 4: https://github.com/kevinlawler/kona
|
| 5: https://www.gnu.org/software/apl/
| jim-jim-jim wrote:
| It seems like this blurb of code has appeared on HN quite a bit
| lately, and it's cool to see a breakdown of it.
|
| The next time I write C, I'm tempted to do it Whitney style like
| this. There really is something to be said about seeing
| everything at once.
| beagle3 wrote:
| Indeed. Be careful, though, many people find they can't go back
| to the level of verbosity they used to write (and which is
| often expected in a team)
| moonchild wrote:
| Dyalog and kx are hiring
| scythe wrote:
| Since this flurry of APL/J/K/A+/Q articles started, I've been
| wondering about the relationship between APLs and literate
| programming.
|
| They say that APL was developed to mimic mathematical notation,
| and I see the resemblance. But real works of mathematics consist
| of one or two lines of expressions separated by sentences and
| paragraphs explaining the goal of those expressions.
|
| So far in K "advertising" I only see the expressions and not the
| explanations. The explanation is there, but it's not a comment in
| the codebase; it's in a blog post that explains it. The code has
| many lines of expressions on top of each other, and nobody writes
| math that way.
|
| I feel like I'm missing something, basically. It's clear how to
| write K, but what are the best practices for making a large
| codebase readable? I shouldn't have to invent that myself, right?
| 7thaccount wrote:
| Assuming you write your code for a certain domain, I think most
| of your colleagues could follow along after learning a little
| k.
|
| I wrote a toy simulator for the domain I work in using
| something like 6 lines of APL code and sent it to someone good
| with APL. They replied back to the email pretty quickly with
| some tips on how to improve it and could generally get the gist
| of what I was trying to do while knowing nothing of the problem
| domain. It was really an interesting experience. I think with
| zero doc, a colleague of mine would immediately understand what
| I was doing after going through a short APL tutorial. It isn't
| magic, but not nearly as cryptic as people make it out to be.
|
| Edit: people do comment their APL code. I think a million loc
| project would be pretty difficult in APL, but the beauty is
| that you should be able to do some pretty powerful work in a
| few pages I would imagine.
| eggy wrote:
| I think you're right. Aaron Hsu's work in APL is inspiring
| and awesome. The source code to his data parallel compiler
| hosted on the GPU is 17 lines of APL! Read the abstract to
| his paper here:
|
| https://scholarworks.iu.edu/dspace/handle/2022/24749
| [deleted]
| kd0amg wrote:
| _The source code to his data parallel compiler hosted on
| the GPU is 17 lines of APL!_
|
| The co-dfns source I've seen[1] is much longer. Do you know
| if there's a write-up somewhere of the differences between
| that and Appendix B from the dissertation?
|
| 1: https://github.com/Co-dfns/Co-dfns
| ibdknox wrote:
| The 17 lines don't include the parser or the code
| generator, which most people would count as "part of a
| compiler" in a practical sense. They are usually the most
| mechanical parts of a compiler though, so there's
| relatively little to be excited about in them.
| vchak1 wrote:
| I think its important to distinguish between something
| that is a core piece vs all the other things that make
| the system usable. For example once you start adding
| error handling, and good error reporting, the complexity
| goes up by an order of magnitude. And in many cases the
| approach for the core does not necessarily scale out to
| the other contexts.
| moonchild wrote:
| > APL was developed to mimic mathematical notation
|
| APL was developed to _replace_ mathematical notation. Making it
| a computer language was almost an afterthought. Indeed, there
| have been some trivial mathematical proofs in j[1][2][3].
| Perhaps those give you a better idea of the connection?
|
| 1:
| https://code.jsoftware.com/wiki/Essays/Trains#Proof_of_Compl...
|
| 2:
| https://code.jsoftware.com/mediawiki/images/8/82/A_Proof_in_...
|
| 3:
| https://code.jsoftware.com/wiki/Essays/Ackermann%27s_Functio...
| clarry wrote:
| It'd be interesting to know how large the largest K programs
| actually are. And maybe see some code too.
|
| I suspect the things that work ok in a <50 line application
| start to work less well when you're approaching 500 lines.
| ectoplasmaboiii wrote:
| Not a large K program, but a company I used to work for
| maintains a large, open source q framework
| https://github.com/AquaQAnalytics/TorQ which is used in many
| large investment banks and hedgefunds.
|
| Funnily enough, the framework is actually a more expansive
| version of a tick system developed by Kx (the company that
| makes kdb) https://github.com/KxSystems/kdb-tick
|
| The Kx one is incredibly concise. When I first started
| working with it, it took me a while to figure out what was
| going on.
|
| The larger K/q programs get, the more they tend to look like
| "normal" code, but you still see a lot of these clever one
| liners hidden away in there.
| clarry wrote:
| > The larger K/q programs get, the more they tend to look
| like "normal" code, but you still see a lot of these clever
| one liners hidden away in there.
|
| Yep, that's what I suspected. TorQ confirms it.. giving
| everything a single-letter name will no longer do :-)
|
| I'm a bit surprised at the number of comments that explain
| what the next line does. I'm not sure what to think of
| that, but it reminds me of beginner tutorials explaining
| code for people who can't yet read it confidently; for
| obvious reasons, not a popular style among more
| conventional languages.
| scythe wrote:
| Thanks! This is the kind of thing I was looking for:
|
| https://github.com/AquaQAnalytics/TorQ/blob/master/code/pro
| c...
|
| I could imagine working on a codebase like that.
| eggy wrote:
| Yes J does attempt to be a concise notation like mathematical
| notation for working with concepts in a manageable way. Like
| mathematical notation it takes effort to learn the meanings of
| the symbols, however, once learned you require less boilerplate
| to explain the meaning of those arranged symbols unless you are
| teaching somebody how to code in J.
|
| Because the code is concise and includes all the important
| information, you can view most useful programs in one page, so
| it doesn't take much to work through the logic again if you
| have not touched it in a while. I put comments inline for
| attribution to a source, or a quick mnemonic to unravel some
| tacit J code.
|
| I loved J the first time I saw it back in 2011/2012. I had
| played with APL in the 80s. I have played with many languages
| (asm, Basic, C, Haskell, Joy, Forth, k, Lisp, Pascal, Ada,
| SPARK 2014, Python, Julia, F#, Erlang, R, etc.), and each
| paradigm shift has taught me to approach problems from many
| different angles. I use the language that suits my current need
| at hand. Frink is on my desktop at work for all of my
| engineering, unit conversion, small input program stuff.
| R/RStudio is there for my statistics work. Julia is replacing
| MATLAB for me. I wrote Blender 3D scripts in Python in the
| early 2000s to make 3D wood carvings from 2D photos.
|
| J is always open on my desktop, and is more than a desktop
| calculator. It is my scratchpad for mathematical and whimsical
| ideas or exploration. See Cliff Reiter's "Fractals,
| Visualization & J" for fun [1], or Norman J. Thomson's "J - The
| Natural Language for Analytic Computing" [1]. I just bought
| Thomson's book three month's ago for about $35. There's now a
| crazy $925 posting on Amazon! Somebody's creating sales from
| HN!
|
| "Mr. Babbage's Secret: The Tale of a Cypher and Apl" was also a
| fun book. It's not really an APL or programming book!
|
| [1] https://code.jsoftware.com/wiki/Books
| vchak1 wrote:
| While I really like array programming languages in general, I
| think what is really an elegant balance of readability and
| conciseness is the nile language and its application to
| rasterization. Highly concise, yet very readable.
|
| See this Bret Victor talk, at 25:03. https://vimeo.com/67076984
| eggy wrote:
| I love J, APL and the array languages in general. I am always
| looking for exercises to practice my J skills. I found this
| article by Tyler Limkemann called "Modeling the COVID-19 Outbreak
| with J"[1].
|
| I also follow tangentstorm and took some of this J-talks gui
| code[2], and mashed it up with Tyler's as a J learning exercise.
| I just put this up on my github. [3]
|
| I highly recommend tangentstorm's YouTube videos too![4]
|
| The concise J code, and the way it makes me approach a problem
| brings me joy! Given all of my coding projects in J fit on one
| page, I can revisit them later, and get right back in without
| worrying about having too many comments or documents to
| understand my code. I like refining the code over time for fun
| and learning even after it works, or somebody much smarter than
| myself shows me a different way to look at it.
|
| [1] https://datakinds.github.io/2020/03/15/modeling-the-
| coronavi...
|
| [2] https://github.com/tangentstorm/j-talks
|
| [3] https://github.com/rpherman/JLang/tree/master/COVID-19
|
| [4] https://www.youtube.com/user/tangentstorm
| okareaman wrote:
| Am I weird because I have no interest in terseness that you have
| to tease apart. It feels counter-productive. The programming golf
| (Code golf) contests and obfuscated C contests just seem like a
| waste of time to me. The whole point of programming languages is
| to allow humans to produce machine code using a more natural
| language closer human language that we are all already fluent in.
| smabie wrote:
| That's not the point of programming languages. The point of
| programming languages is to be more productive, it has nothing
| to do with natural language. In fact, natural languages are a
| poor fit for programming languages (see Cobol).
| ben509 wrote:
| Counterpoint: SQL is incredibly successful and its syntax
| uses natural language structures quite heavily.
|
| The problem Cobol has is that uses some natural structures,
| but then becomes very verbose because it only uses a few, and
| they often can't be combined, so it is very repetitive.
|
| It's not natural to say, I will buy eggs at
| the grocery store. And I will buy ham at the grocery
| store. And I will buy cheese at the grocery store.
|
| > The point of programming languages is to be more
| productive...
|
| But you should be productive not only in initially writing
| the code, but also in reading it later when you do
| maintenance.
|
| And what you see with most languages is extensive commentary
| to help future authors understand what's going on, and that's
| partly because terse languages tend to be cryptic.
| okareaman wrote:
| I wasn't advocating programming in natural language. Much too
| ambiguous. I'm saying "closer" to natural language so our
| cognitive load is reduced reading and writing in the language
| so we can focus on what matters - to be more productive as
| you point out.
| AnimalMuppet wrote:
| There was an attempt to do so, so that professional
| programmers would be unnecessary. The result was COBOL.
|
| I don't want "close to natural language" because it's too
| _verbose_. It 's like reading an article in _The New
| Yorker_ - it takes so long to get anything said that you
| forget what the point was.
|
| Of course, "too terse" isn't the answer either. There's a
| sweet spot. I suspect that the sweet spot varies, depending
| on the person and the kind of code.
| okareaman wrote:
| I'm not sure why ppl are misunderstanding what I am
| saying. I'm not advocating COBOL-like languages. I'm
| saying assembler is better than writing in machine code,
| C is better than assembler and it would appear for most
| programmers, Python and JavaScript are the best choice
| but nobody who wants to keep their job writes code in the
| style of minified JavaScript or obfuscated C.
| eggy wrote:
| To some APL and J are the equivalent of C to assembler.
| It is not obfuscated, it is concise: brief but
| comprehensive, and easy to understand if you take the
| time to learn it like you would other PLs. I think Ken
| Iverson's "Notation as a Tool of Thought" covers this
| pretty well [1 PDF].
|
| [1] http://www.eecg.toronto.edu/~jzhu/csc326/readings/ive
| rson.pd...
| kinleyd wrote:
| Recently I've been dabbling in q and kdb+. Would there be any
| benefit to dabbling in J instead?
| anonu wrote:
| Shakti seems to be the new flavor
| kinleyd wrote:
| I've taken a look at that as well. It seems to be heavily in
| development at the moment, though I'm keeping my eye on it.
| 7thaccount wrote:
| The creator of kdb+, the k language, and the q-sql DSL sold
| his share of Kxsystems (company that makes kdb+) to start a
| new venture called "Shakti" with a new version of his "k"
| language. Kdb+ is still around and developing, so I'd say
| they're forked at this point.
| smabie wrote:
| When a q like language is implemented for Shakti, I'll
| definitely switch. I personally find q a lot more
| comprehensible than k.
| kick wrote:
| J is probably the best language in the world to craft native
| GUIs (something k could never do very well, and now doesn't do
| at all).
|
| It also has a wonderful amount of books on it, most of them
| Creative Commons-licensed now (as all/most of Iverson's books
| are, I believe). It's significantly easier to learn for someone
| new to array languages yet who doesn't have the sort of hands-
| on training you can get with APL & k; you could go into the
| woods with nothing but the J interpreter tarball for a week and
| come out pretty having internalized the language, and it's even
| easier with some of the other books available.
|
| It's, of course, free software.
| gaze wrote:
| > J is probably the best language in the world to craft
| native GUIs
|
| How is that the case? I don't really see a grid system or
| anything like that. I much prefer delphi or wpf or something.
| 7thaccount wrote:
| Same concepts for the most part. I think K is a bit easier to
| understand and if you're lucky enough to work with a kdb+
| system, I'd focus on k & q to be honest.
| kinleyd wrote:
| Thanks. I downloaded the 64bit "on demand" version of q, kdb+
| and have been toying around.
| Jorge1o1 wrote:
| q and kdb+ would be the better choice in my opinion. I feel as
| if there is better documentation, books, and resources for q
| than J/k
| 7thaccount wrote:
| q and k are both part of the kdb+ database software suite. K
| is the language and q is a DSL wrapper over k with SQL
| primitives.
|
| J is an entirely different language and I think the doc is
| actually pretty decent. There are free books and tutorials
| and books you can buy on Amazon.
| 7thaccount wrote:
| I've done a little J in the past and have been playing with APL a
| lot lately.
|
| It is definitely a different way to think. My programs are taking
| a long time to write as I train my brain to think in this domain,
| but the code is very concise and generally not hard to follow
| afterwards. Everything is so interactive it's a joy.
|
| In particular, I enjoy how the poster broke the code down as I
| can only understand some of C code. It's cool to think I could
| create my own little J interpreter this quick.
| empath75 wrote:
| About halfway through reading that, I was thinking -- it would be
| fun to try and write this in Rust, and then i got to the bottom,
| and he had aleady done it. Much easier to read in rust.
| RodgerTheGreat wrote:
| The C version is 41 lines, and 1749 bytes. The Rust version is
| 295 lines, and 8289 bytes.
|
| The point of the Incunabulum is not really what it does (it's a
| REPL with a handful of half-implemented J verbs and no error
| checking), but the style it demonstrates. I think that
| rewriting a similar program in another language without even
| attempting to reproduce the style is rather missing the point.
|
| If you're interested in Rust, why not figure out what a
| semantically-compressed style looks like for it?
| tomp wrote:
| How much of that is due to the C preprocessor though? In
| theory, you could run the same preprocessor for Rust code (if
| you figure out some sensible macro shortcuts).
| clarry wrote:
| Not much at all.
|
| It's a completely apples to oranges comparison, with the
| rust version having some error handling, support for longer
| identifiers, tests, relatively idiomatic style with line
| breaks and indentation where you expect it, variables and
| type names longer than one or two characters, etcetra.
|
| You could compress it massively before going for the
| preprocessor. In fact, a few of the preprocessor macros
| just make the C version longer (when measured in lines)
| than it would be without those macros if lines were allowed
| to be as long as in the rust version (<70 chars vs 100
| chars). The printf macro (used only three times) actually
| makes the C code longer both in bytes and lines (or equal
| length in lines if you retain the 70 column limit).
|
| There's really only one macro (DO) that expands enough to
| save lines, but just barely. The shorthand for return saves
| quite a few bytes (but not so many lines) given that it's
| used everywhere.
| empath75 wrote:
| But why though. It's a terrible way to write code.
___________________________________________________________________
(page generated 2020-04-10 23:00 UTC)