Hacker News Reader

Comment by untangle | Hacker News Reader

Neat little tribute article.

APL will not be reborn. If that was going to happen, this century's embrace of analytics and linear-algebra-rich machine learning would have propelled the upswell. It didn't and it won't.

Why? It's not the symbols. Not the keyboard. Nor the learning curve. Nor the lack of standardization, libraries, or GPU support. These are collateral damage, not primary drivers.

APL will not flourish because it is effectively a DSL with archaic I/O capability. It is a nearly-pure functional programming language. It's primary domain is mathematics. Native GUIs, networking, the web -- all uncompetitive add-ons.

In this sense, APL and Haskell share some DNA.

For dynamic systems modeling for my thesis, I reached for APL and Matlab. I still code Dyalog APL for recreation. Love it. But I wouldn't build a web app with it and a wouldn't run my company on it.

View on HN

I like your take, and Haskell is an apt comparison in this sense.

Another sense in which i think APL is... un-competitive is that its strengths (terse, mathematical, matrix-centered) are the easy parts of programming, i.e. the parts that are the most objectively quantifiable and verifiable (you just use math).

Accounting for numbers is trivial, accounting for human factors is a proverb.

I agree that Haskell is a good comparison. I think matrices and math are too closely focused on in array languages (and dismissals of array languages), though.

For fun I'm writing a "spreadsheet programming language" that borrows a little from array languages, and I think there's useful stuff to take away from them.

They make you focus on the data, and the transformations you want to effect on the data.

They make you think, "where there's one, there's probably many."

The implicit mapping over arrays for most functions and operators is a massive ergonomic win over "a formula for each row" in the spreadsheet model. (Excel "array formulas" but not shit.)

Some of the simple little abstractions are beautiful. Seriously, as someone who didn't know anything about array languages three weeks ago, I say go spend a day reading the first two parts of the J book (http://www.jsoftware.com/help/learning/contents.htm) up to "Rank". It's this humble little operator that makes the whole language sing and fit together masterfully, and I'm heartbroken my language's data model (and programming style) isn't a good fit for it.

Really, though, for me being able to have my (still hypothetical) non-programmer users type

  organisations[users.orgId]

instead of

  users.map(({ orgId }) => organisations[orgId])

is a no-brainer. Ditto just about any place I might want to use an anonymous function in JS, really:

  sort(people, by: people.age)

  sort(people, ({ age }) => age)

So simple. Pass an array of things to use as the sort key, not "a function to call on each item-to-sort".

Forget the cryptic syntax, "operator ambivalence" and math/matrix-focus, there's a lot of useful stuff in there that should be better known in language circles.

As for the grandparent's complaint of being "nearly-pure functional", that's the zeitgeist now -- functional transformation of data, with big ugly explicit data-replacement as the mutation story. That's not an impediment to use, it's an encouragement to use responsibly while not being too much of an encumbrance if you want to walk off the beaten track.

I'm not massively keen on the former (IMO having to write .map etc helps you get a better "feel" for what parts will have the biggest impact on performance), but the latter looks an awful lot like lenses, which are pretty great.

Of course, a lens is really just a pair of functions in disguise, so it wouldn't prevent you from sorting my more complex functions if needed.

You can do that last one pretty easily in JS with a helper function.

    function by (key) {
      return function (obj) {
        return obj[key]
      }
    }

    // sort(people, by('age'))

Not a bad solution. Having a top-level `by` function isn't a bad tradeoff if it's easily understood. For me there are two problems, though. Most importantly:

1. It doesn't generalise past lookups. Say I want to sort a list of numbers by their absolute value. In my spreadsheet language:

  sort(numbers, by: abs(numbers))

or filtering by some threshold:

  filter(numbers, by: numbers > threshold)

Both are "repetitive" -- we might prefer something with first-class functions to get closer to a point-free style, but my users won't care. And the repetition isn't actually useless, there are times you might really want that flexibility:

  filter(users.id, by: users.age > 21)

2. My language isn't big on first-class functions. One day it might get support for them for some use-cases where you just need that flexibility[1], but in the meantime they don't provide a lot of value, and they're not a good fit for my hypothetical future users.

If I told my hypothetical users that `by` returns a function, their response would probably be, "What is a function?" The unit of logic abstraction in my spreadsheet language is... slightly weird from a traditional programming perspective.

Thanks again for commenting constructively, though -- seeing a new ergonomic way to approach this sort of problem (or even just "tricks that could become idioms") is really useful.

[1]: If you needed to provide a 2-arg comparator to `sort` then a lambda would be much better -- my scheme would require you to evaluate the cross-product of comparisons, so sorting would have to take time O(n^2), which is no good. Thankfully single-item key functions seem sufficient for most purposes.

If you think about it, a decent stack is composed of languages. That's currently already often true, e.g. the use of IDL languages like protobuf/flatbuffers. Some languages offer integrated idl like Kotlin (data classes). Another example is html, where the UI is described using a dsl to specify elements and CSS for layout & appearance.

This fact caused me to think: should stack also not be made of other languages? Is there a place for a completely pure functional language? I mean, Haskell is nice, but get a bit awkward with I/O. Same for APL. C# has nicely integrated data querying, but from a distance is actually at least somewhat awkward. C# seems to be optimized for mutable domain objects; everything else can be nicely done but falls somewhat outside it's "identity".

I would love to be able to express functions, functors and math using a terse math-y language. Whether that be APL or some sort of blend of Haskell and APL (Haspell? spelling pun intended), I don't care, but it would be great if we can have nice integrations of these languages in a full stack. Sort-of like how TypeScript and JavaScript have dialects to enable React syntax to express HTML within it.

The same thought experiment can be applied to SQL. Can we have a data-querying language integrated right into, say, C# or Java?

The language Racket (https://racket-lang.org) sort of approaches this. It allows you to quickly switch which compiler a given source file is actually sent into, the goal being that you solve each problem with sub-languages particularly suited to the task at hand. For instance, the webserver language has HTML build in as a primitive.

C# kinda does have a data querying language built right in with LINQ query expressions, although they seem to have rather fallen out of favor.

Indeed. But you can still write functional style data querying languages using LINQ extension methods. IMO, LINQ based DB querying is revolutionary in terms of the flexibility and capabilities it provides. For complex Relational DB querying it's pretty great.

I tend to write raw SQL using Dapper these days, because hey, scalability and such, but for business apps and non-cloud apps, EF and other LINQ-based DB tools are great.

Re: The same thought experiment can be applied to SQL

I am a fan of "Table Oriented Programming" and believe OOP forced an unfortunate shift from data-oriented programming to code-oriented programming. I hope the pendulum swings back. APL is intended for mostly scientific applications, but it has some nice lessons for other domains, and RDBMS may be a door into common data-oriented programming.

I also believe that "Dynamic Relational" is needed to improve data-oriented mock-ups, experiments, and small-scale projects. The existing RDBMS are too "stiff" for some needs. We have dynamic programming languages, so why not for databases? Yes, there are some dynamic query languages, but they require throwing out SQL and starting from scratch, which cranks up the re-learning curve. Dynamic Relational only requires minor changes to SQL. (SQL ain't perfect, but so far a decent replacement has yet to gain traction. I'm personally a SMEQL fan.)

The ML family (SML, Ocaml, F#) is also pretty good with the mixture of functional and imperative constructs.

Having a part of the program known to be pure at compile-time, but another part effectful is something you see in the language F* (http://fstar-lang.org) - here you get monads, dependent types, a proof system, and the ML module system neatly packed into a general-purpose programming language.

Not as widely popular as O'Caml, F# or Haskell, but both as practical as Ocaml and as researchy as Haskell.

Also there's a free tutorial/book on the website.

The heart of my argument is mostly that integration in main languages should be pursued. F# can be mixed on assembly (project) level, but not on source level (like css in html or html in js/ts).

Is there a reason one wouldn’t just build the core engine of SIMD math software in APL, much like people build the core engines of medical-system software in Prolog?

Is Prolog really used for medical-system software? It seems to me that it turned out to be the wrong path taken by Japan's Fifth Generation Project.

In the early 80's I experimented with Prolog. Simple ideas were simply coded into programs; it was really very interesting. However, the need to understand the compiler's inner workings to get programs that ran efficiently by manually inserting "cuts" to limit backtracking ruins Prolog's claim to being simple to translate requirements into programs.

An even more serious problem with Prolog is the simplicity of it's model for logic. It is very easy to end up with requirements in the real world that don't easily fit the model. See for example the SHOOT problem in [1], where the concluding sentence is:

> As such, the claim implicit in the development of nonmonotonic logics--that a simple extension to classical logic would result in the power to express an important class of human nondeductive reasoning--is certainly called into question by our result.

Don't get me wrong, I was the Chief Scientist at a company with one Prolog based product. I still thinks its an interesting language, but I predict that it will remain eclipsed by much more general purpose programming languages.

[1] https://www.aaai.org/Papers/AAAI/1986/AAAI86-054.pdf

The popular narratives that 5th generation computing, expert systems, etc failed to deliver because it was the 'wrong path' to take is bs, basically the hardware designers weren't used to non-turing architectures, it was hard to find (and hire) programmers that fully understood both non-imperative paradigms and hardware integration, and government funded science (outside of black budget defense and intelligence projects) education and research started taking a nosedive during the 80s.

It is! You don't use it for diagnosis; you use it to formalize treatment guidelines (which are effectively 'expert systems' even on paper.) It runs alongside more ML-based models, glued together under business-logic written in something like Java.

You have got to give more details about this :)

>> In the early 80's I experimented with Prolog. Simple ideas were simply coded into programs; it was really very interesting. However, the need to understand the compiler's inner workings to get programs that ran efficiently by manually inserting "cuts" to limit backtracking ruins Prolog's claim to being simple to translate requirements into programs.

Where does this claim come from? Prolog is an automated theorem prover for first-order logic theories. There have certainly been various arguments about the pros and cons of it made by many different people (not all of whom were close to the development of the language), but the fact remains that its main characteristic is the automation of a proof process.

You can certainly find many flaws in Prolog if you look hard enough and choose your requirements carefully (for example- it has no functions! Why has it no functions? It should have functions! Therefore, it sucks).

I think a lot of the bad rep Prolog's got over the years is the result of promises by various sources that had nothing to do with its actual goal, which was to create a language with the syntax and semantics of FOL- which it achieves not perfectly, but way, way better than anything else out there.

>> I still thinks its an interesting language, but I predict that it will remain eclipsed by much more general purpose programming languages.

That's probably true, though :)

Yes, thanks for the correction. You are right, it is possible to learn to Prolog without understanding the inner workings of the compiler or even the Warren Abstract Machine, but that is how I understood why I had to put up with the cut operator in my programs.

I was originally sold on the idea of Prolog because of the many beautiful declarative examples found in introductory tutorials. The sad truth is that Prolog isn't magic and just like Functional Programming, Object-Oriented Programming, or even Structured Programming, there are wrinkles that one encounters that require a less than pure language semantics. In Prolog's case the semantics must be understood procedurally by understanding the order of goal searching and backtracking.

From Clocksin and Mellish [1]:

> So the moral is: If you introduce cuts to obtain correct behaviour when the goals are of one form, there is no guarantee that anything sensible will happen if goals of another form start appearing. It follows that it is only possible to use the cut reliably if you have a clear policy about how your rules are going to be used. If you change this policy, all uses of the cut must be reviewed.

The cut operator in Prolog is used to make programs more efficient or to make the language more expressive[2]. So there is little alternative but to accept it's use along with it's confusing and error prone semantics due to it having a meaning that is only in terms of the procedural semantics of Prolog[3]. From Clause and Effect, section 4.3 titled "Taming Cut"[4]:

> It is not easy to understand the full implications of using cut.

Prolog looks like it allows programming by specifying what is wanted rather than by specifying how to get to what is wanted. This appearance might even be partly justified, and it is certainly touted by Prolog's promoters. From the preface to Prolog for Programmers[5]:

> ... Prolog can be classified as a descriptive programming language, as opposed to prescriptive (or imperative) languages such as Pascal, C and Ada. In principle, the programmer is only supposed to specify what is to be done by his or her program, without bothering with how this should be achieved. ... In practice, however, Prolog can be treated as a procedural language.

I think this is misleading. In my mind it should end with the sentence: In practice, Prolog must be treated as a procedural language in addition to a descriptive language.

In their chapter devoted to cuts and negation, Sterling and Shapiro[6] say:

> With ingenuity, and a good understanding of unification and the execution mechanism of Prolog, interesting definitions can be found for many meta-logical predicates. A sense of the necessary contortions can be found in the program for same_var(X,Y), ...

This expects programmers to have a non-trivial understanding of Prolog's implementation. I was wrong to say that an understanding of the compiler was needed, but programmers do have to understand unification and the order of evaluation used by the language.

Finally, I believe that the cut operator also makes parallel processing implementations of Prolog very difficult. In this post Moore's law era this will cause problems for Prolog's performance without making more of the implementation leak though to the language semantics.

Logic and constraint programming are interesting techniques, and it's difficult to say where they will lead. Prolog is an important language in the history of programming languages. Perhaps Logic Programming will make a comeback aided by the new advances in automated theorem proving.

[1] Clocksin, W. F. and Mellish, C. S. Programming in Prolog. Springer-Verlag, 1981. p. 78.

[2] Bratko, Ivan. Prolog Programming for Artificial Intelligence. Addison-Wesley, 1986. p. 136.

[3] Roger, Jean B. A Prolog Primer. Addison-Wesley, 1986. p. 115.

[4] Clocksin, William F., Clause and Effect, Springer, 1997. p. 50.

[5] Kluźniak, Feliks and Szpakowicz, Stanisław, Prolog for Programmers, Academic Press, 1985. p xi.

[6] Sterling, Leon and Shapiro Ehud, The Art of Prolog, 2nd Ed. The MIT Press, 1994. p. 201.

>> This expects programmers to have a non-trivial understanding of Prolog's implementation. I was wrong to say that an understanding of the compiler was needed, but programmers do have to understand unification and the order of evaluation used by the language.

Actually, I'd go one step further and say that in order to make full use of Prolog you need to understand SLD resolution and definite clauses, otherwise you'll never really get what the hell is going on in there, or why the interpreter works the way it works. To program in Prolog you do need a non-trivial understanding not only of its implementation but also of the substantial theoretical work that led to its implementation as the prototypical logic programming language (e.g. see J. W. Lloyd, Foundations of Logic Programming).

The thing is, there is a lot more going on with Prolog than "here is a language that can be used to control a digital computer". Logic programming is the continuation of the work of the logicians of the early 19th century, the evolution if you like of mathematical logic. It has to be understood in that context- or not at all.

You make the point that there is an operational, or imperative, reading of Prolog code, that must be understood alongside the declarative one. That is correct, in my opinion, but I don't see why it's a problem. For one thing, programmers taught on imperative languages (i.e. the majority) should not really have a problem with the operational semantics of Prolog (e.g. what you see when you trace Prolog code in the four-port tracer, the order in which goals are called, succeed, fail and are retried etc). Understanding the semantics of the cut is maybe not trivial, but again that is a problem only if someone tried to sell you Prolog as an "easy" or "friendly" language; which it isn't.

More importantly, Prolog has its declarative reading also, which is something almost unique to it. So maybe Prolog is not a perfect, pure implementation of the declarative paradigm- so what? Should we throw the baby out with the bathwater and say, hey, Prolog is only 99% declarative, so I'll just stick with Java, which is 0% declarative? That doesn't make much sense! At least not if you somehow want to use declarative programming- if not, then Prolog is not an option anyway.

>> Finally, I believe that the cut operator also makes parallel processing implementations of Prolog very difficult.

You mean parallel execution of Prolog code? Not parallel implementations of the language? I don't see that the cut is a problem there, but then again I don't have any experience trying to parallelise Prolog code. There is again a promise that Prolog's execution scheme is uniquely disposed to parallel execution. Maybe it is, maybe it isn't. But that is not the most important characteristic of Prolog.

The most important characteristic, like my previous comment says, is that Prolog is an automated theorem prover for first-order logic theories. Anything else that it may do is by the by- and, conversely, any compromise it has to do on the way there, provided we're talking about pragmatic compromises necessary to get the language to work on limited resources (i.e. like the cut), is worth it.

Of the sources you quote I'm familiar with Clocksin & Mellish, Bratko and Sterling & Shapiro. Those are good books, although Bratko probably tries a bit too hard to make Prolog sound a bit like Pascal. I would also recommend Richard O' Keefe's The Craft of Prolog and George Lugger's "AI Algorithms, Data Structures, and Idioms in Prolog, Lisp, and Java", online here:

http://wps.aw.com/wps/media/objects/5771/5909832/PDF/Luger_0...

>> Perhaps Logic Programming will make a comeback aided by the new advances in automated theorem proving.

Nah, I don't think so. I think it will remain a niche thing, of interest primarily to academics and programmers who like obscure languages. But that's OK. Not every language needs to be Java or Python.

APL has flourished, as a DSL embedded in a language with excellent I/O. It's just got weird syntax and is called Numpy. Or Tensorflow. Or PyTorch...

Morgan Stanley used APL successfully in their bond trading business for many years... its by no means an insurmountable hurdle. Last I heard they were using Java tho’, lol. From one end of the verbosity spectrum to the other!

MS used APlus (http://www.aplusdev.org/index.html) a derivative of APL. I was there during the transition and a common attitude in the Fixed Income group was "You'll pry APlus out of my cold dead keyboard".

It will not become popular for one simple reason: you have to be smart to understand it. Want to be popular? Write a python^Wlanguage for people who shouldn't even be programming in the first place.

Reply on news.ycombinator.com