The loops are still there, they're just implicit. That's how APL-family languages can be parallelised easily.
It's notable that the first J interpreter, while written in C, has a similar style --- it defines a macro to run a loop "implicitly", and then uses that throughout:
https://code.jsoftware.com/wiki/Essays/Incunabulum
> The loops are still there, they're just implicit.
Obviously. I think the point is that loops should be considered "implemention details" at the compiler level, and us higher beings should be able to say what we want without troubling ourselves with them.
The article does have a heading "Examples of Implicit Loops", so the author acknowledges that the loops are there, but implicit. I guess "implicit-only-loops code" or "explicit-loop-less code" or whatever isn't as catchy a title, but I don't think anyone reading it expects it to be literally loopless code.
The current interpreter even has this!
In fact, the meat of many (most?) functions is implemented using the (functions underlying the) primitives. It's kind of fascinating to skim through, if you're already familiar with array programming. The code goes way out of its way to reduce the impedance mismatch between J and C semantics.
Sean Parent has a good talk about no loops in C++. His primary argument is that typically a loop is an algorithm you’re applying (map, filter, reduce…) and the raw loop masks the algorithm.
While I agree that a lot of loops could be better implemented as a map, filter or similar construct, there's still many loops where writing it as a loop makes it more clear what's going on.
For example, in our system we have orders. Each order has some order items as well as one or more invoice.
Due to reasons, some customers want to consolidate orders before processing them in our system. In that case all the items should simply be copied to the consolidated order, however for invoices we should accumulate values for the same invoice number and currency combo.
In addition, order items references the invoice they belong to, so we need to keep track of the new invoice id's so we can remap that reference.
Doing all this in a few nested loops makes the overall process very clear I think, each step in the loop being clear and logical. In that case, the loops highlight the algorithm I think.
I'm not sure how to implement the consolidation only in terms of map, filter and friends in a way which would be more clear.
> there's still many loops where writing it as a loop makes it more clear what's going on
I think that really depends on your language and what you are used to. For me, I would disagree.
> I'm not sure how to implement the consolidation only in terms of map, filter and friends in a way which would be more clear.
Tbh, when I read this, I'm thinking: is the data-structure wrong? Maybe you should have something like a "bundle" that contains orderItems and their invoice. It doesn't seem to make so much sense to keep an invoice ID in each orderItem. That makes sense in a relational db, but not when using objects.
I would model it like that (for lack of a better name than "bundle"):
Now orderItems and the invoice-amount are logically bundled together and identified by the invoice-id. Then, combining two orders becomes really simple: combinedOrder = order1 + order2
No loops needed, simply treating the data as monoids.
You might argue that it is not clear how that works and you are right for everyone who is not used to how monoids work. But everyone who is, independent of the language, will understand exactly what happens. On the other hand, someone who is not used to loops would probably argue that your loops are hard to understand.
It really boils down to what techniques one is familiar with.
I think I get your point, however the real world is muddy...
> I would model it like that
How does your model take into account orders where order lines do not map to an invoice, or which has invoices which no order lines references?
edit: interesting example btw, I do like a lot of aspects and it was fun seeing some "practical" Scala, haven't had a chance to dig in much. Much appreciated!
> How does your model take into account orders where order lines do not map to an invoice, or which has invoices which no order lines references?
If I understand you right, the latter seems easy: the list of orderItems would just be empty.
If there can be orderItems without invoice (why would that happen?) then I'd just add another field "plainOrderItems: List[OrderItem]" next to the bundles.
The rest of the code would not change.
That being said, there can surely be situations where modeling the data is not trivial. It's always exciting to model it in the best way to describe the problem at hand. And with this approach, sometimes you need to model different "views" to make combining things work.
> edit: interesting example btw, I do like a lot of aspects and it was fun seeing some "practical" Scala, haven't had a chance to dig in much. Much appreciated!
Obviously I can’t see the business logic but I would express this (or what I believe I understand of it) as a fold that accumulates a map of structures which organize the invoice(s) alongside the orders somehow. I suspect that would result in a kind of “inversion” of responsibility that might be unfamiliar at first, but may well result in a clearer relationship between the data elements to someone new to the code (and may make refactoring a lot easier).
It's very close to this, in C#-ish pseudocode, and barring errors introduced by my fried Friday brain. The duplicate invoice lookup isn't a linear search but I wanted to keep it simple. In reality order items have various sub-items, but lets ignore those.
It's not super elegant, but in my mind it's straight forward and should be easy for my colleagues to jump in and understand. Though I'd be delighted to be proved wrong.
var dstOrder = new Order();
var invoiceMap = new Dictionary<Invoice,Invoice>();
for srcOrder in SrcOrders do
{
for srcInvoice in srcOrder.Invoices do
{
// compares using invoice number and currency
var dstInvoice = dstOrder.Invoices.Find(srcInvoice);
if (dstInvoice == null) {
dstInvoice = dstOrder.AppendInvoice();
dstInvoice.CopyFrom(srcInvoice);
invoiceMap[srcInvoice] = dstInvoice;
}
else
{
dstInvoice.Amount += srcInvoice.Amount;
}
}
for srcItem in srcOrder.Items do
{
var dstItem = dstOrder.AppendItem();
dstItem.CopyFrom(srcItem);
// map old invoice reference to new (possibly consolidated) invoice
dstItem.Invoice = invoiceMap[dstItem.Invoice];
}
}
dstOrder.Save();
return dstOrder;
some of this is a little unclear. in particular how the source invoices are identified and mapped and therefore what invoiceMap really looks like. but here is a group/sum in a madeup datalog dialect:
that produces invoice/sum pairs. Orders and Invoices are your source relations. unique produces a set of unique source invoice ids, which drives the cardinality of the aggregate. the block notation is a scoping construct encapsulate the set cardinality changes.
not going to claim that this is inherently more readable or captures all the subtleties. but you can imagine that terse expressions of intent like this are more accessible to the reader and less error prone. if not, I should do a better job.
Sorry, I was in a bit of a hurry. An Invoice has essentially these fields:
id
InvoiceNo
InvoiceDate
Amount
Currency
The id is the unique id in the DB. For the purposes of consolidation we consider (InvoiceNo, Currency) as a tuple. For brevity I didn't include the failure mode of mismatching invoice dates, that can be checked in advance anyway so not terribly relevant.
The invoiceMap maps instance to instance, or the unique id to unique id if you like.
I guess my answer depends on what kind of DB this really is.
If the app is running off a SQL Backend, you could probably do this with some well thought out queries, however whether doing so in an ORM/ActiveRecord Environment (which is what this looks like) will be beneficial might be another matter.
For instance, if this was SQL and a Micro-ORM was involved, I'd instead try to grab all the data in one pass (With the right ones that's fairly simple,) Calculate my Insert set from that, and write out the new records. In that case though, there'd probably still be some form of LINQ/Looping, both on the level of business code, as well as under the wire. It would be more performant for sure, but to your point, IDK whether it would be more understandable
Map reduce and filter often are much more readable, but then sometimes a loop is clearer. I often see this when I use resharper's (a c# tool) auto refactor a loop into a linq statement , it can become unreadable.
Readability depends on both the underlying algorithm and its expression in code. Because LINQ has to work in existing languages, it can't express loopless algorithms as well as languages like J that have syntax designed to fit the style. You're probably also putting it at a disadvantage with the automatic translation, as you'll write different and cleaner array code if you approach the problem with array operations in mind.
The author is claiming (and I and many more practical-minded programmers agree) that in J, explicit loops are rarely needed, and usually not even helpful. As the J notation is designed for loopless programming, it has the same kind of bias, against loops. But knowing how J approaches things can be valuable. Most likely, many problems you think are unapproachable with map and reduce can be solved easily by knowing the right techniques.
Plus they may have hidden performance costs - or benefits. They may have function invocation and memory layout costs, but they may also be parallelised and optimized transparently. A regular for-loop is super efficient in terms of memory layout / access but it's by definition singlethreaded.
Yes, as always, it depends. The typical problem with array operations, e.g. in Fortran, is how well they're "scalarized", and the possible cost of not doing copy elimination over subroutine calls, for instance.
Presumably the exact semantics of a for-type loop depends on the language, but surely the C standard doesn't prevent auto-parallelization (including with SIMD vectorization, modulo arithmetic rules). Loops might also have OpenMP or other annotation.
> If the rank of the verb's operand is smaller than the rank of the verb, the verb is applied to the entire operand and it is up to the author of the verb to ensure that it produces a meaningful result in that case.
This instantly brings back all my frustration with getting broadcasting in numpy to work like I want / expect. I love getting the right dot products to work between an array of matrices and an array of vectors, but I don’t do it often enough to remember how, I have to slowly re-derive the incantation every damn time.
> J does contain while. and for. constructs, but they carry a performance penalty
Question - what is the state of the art of functional programming for performance? My experience in JavaScript, Python, and C++ is that using loop-hiding pure functional constructs is difficult to impossible to optimize, often much slower than explicit loops, and worse that it’s harder to refactor when you realize your nested loops are inside-out from what they need to be. I want to use functional more often, but I feel like I hit roadblocks in practice.
Part of the reason for that is because APL-family languages support this feature as a first class citizen and are designed with them in mind. Numpy has to, for better or worse, work within the confines of the Python grammar.
From the title I was sure this was going to be about the branch forward only pattern used in the Gripen, that John Carmack has briefly written about. In that pattern, there's a top-level loop, but other than that, no looping constructs or other backward-branches are permitted anywhere in the codebase.
A popular example given for this is often pcap/tcpdump filters— for perf reasons they have to be executed by the kernel, but because they're an untrusted user "program" being run in kernel space, they can only ever jump forward, ensuring an upper bound on their runtime.
Seems curious to ban functions. If you ban function-pointers then you can statically ensure there's no recursion (including mutual recursion). At that point, all function calls are in principle able to be inlined, so any backtracking is merely a compiler-level implementation detail.
iirc, OpenCL C does something similar, banning function pointers and recursion (including mutual recursion), although it does so for different reasons than this pattern.
It seems to me that this would be best ensured by writing the codebase in a custom language the compiler of which would put a loop around the whole code but the language itself wouldn't have loops. This could be yet another instance of "patterns mean 'I've run out of language'".
The idiomatic way would be to exit the array paradigm and use an imperative (while.) or functional (recursion) method. APL and J both have "repeat until convergence" functionality, which stops when the same result is returned twice in a row, but to use this you'd have to artificially create a result that changes each time.
When designing BQN I embraced the limited nature of array primitives, so that most primitives can only implement efficiently parallelizable programs and none of them can perform infinite loops. Flip this around and you get guarantees: if you create a function by composing primitives you know it will halt, and if you avoid using modifiers in complicated ways it's easy to prove good sequential and parallel bounds on the runtime.[0] Although BQN has no tail recursion (J also doesn't; Dyalog does), it's possible to implement loop functionality that uses only logarithmic stack space in the number of iterations, with low overhead (I just measured 30ns/iteration in CBQN for a simple incrementing loop).[1]
in K, there is an adverb form which is essentially equivalent to a while loop: apply a function or composition to a value repeatedly as long as a second function or composition of that value yields true.
It's basically an "escape hatch" when an algorithm cannot be cast into any more specific pattern, like iteration, a fixed-point, a reduction, etc. In practice it is needed very rarely.
Why so much hate for loops? Loops are just a nice notation for some computational constructs. Sometimes they are the clearer way to write an algorithm. Very often an algorithm becomes clearer when written in explicit loop form than in "vectorial" notation.
Loops do not need to be artificially slow to discourage them. Any modern programming language should be able to recognize the construct and compile it in the most efficient way. Saying that you must avoid loops because they are slow is a failure in a particular programming language, not in the concept of loop. After all, all languages managed to implement loops efficiently many decades ago.
I think the idea is that a loop in many cases doesn't express your intent. What you might want to do is to "set the property 'foo' to 'bar' on all items in an array".
What you might write is "create a variable and set it to zero, then iterate that variable as long as it's smaller than the number of items in the array, and do this between each iteration: take the item at the variables index and set its property 'foo' to 'bar'".
Of course any programmer will instantly see what's going on, but that's not from clarity but from prior experience and familiarity.
True. It is possible though for a language to avoid these iteration constructs as if they are needless plumbing as well. Consider the elegant type system of the XQuery language:
In XQuery, the root type is a flattened sequence. Flattened means not just that [1, [2, 3]] is flattened to [1, 2, 3], but also the a single object 42 is equivalent to a sequence of one object [42].
This means that if I write:
declare function local:prefixName($name)
{
fn:concat("prefix-", $name)
}
I can invoke it with a single name or a sequence of names without any explicit iteration.
It has drawbacks but using XQuery certainly highlights how much code we normally waste dealing with "things" and "sequences of things" separately.
(Than again working with XQuery also highlights how much code one can waste dealing with XML namespaces :)
Admittedly it's a worst case scenario, but the broader point still holds even with a foreach. You are still picking out each item individually instead of operating on the collection which is what you intend to do. You write "do this for every apple: peel it", instead of "peel the apples".
apples.forEach(peel) is pretty clear, and the distinction is actually important for some operations which could conceivably be applied either to the whole collection or to each item in the collection and thus could be ambiguous in plain English, like “gift wrap the apples.” That could mean giftWrap(apples) or apples.forEach(giftWrap).
I chose Rust syntax because it allows both chaining and using methods as functions, but avoided Rust-specific features. In addition to `collect` this example is missing `.into_iter()` that both examples would need: I interpreted `apples` as an iterator instead. Otherwise the first example would be clearer with a for loop.
I love me some forEach methods! It's still one off from completely avoiding the loop-think though. A syntax like "apples.'peel()" (where peel is a method on the individual apples) is what I imagine.
As a PS, I think the parent comment was referring to a (corresponding) "for apple in apples: peel(apple)" syntax though. The main point was that you don't have to bother with the manual index iteration as in my worst case example.
Well said! And when this clarity is lacking in a codebase, damn do I find it incredibly frustrating! Like, can’t you just tell me whether you are trying to operate on the items of the collection or the collection as a whole??? Why did you need to adopt this ambiguous formation??
> That's only true for languages that don't support looping over an iterable directly.
Even with loop-over-iterable semantics, explicit loops obscure intent compared to comprehensions and map/reduce/filter/etc.; they are better than C-style loops which in turn are better than conditionals + gotos, but that doesn't make them good at expressing intent in many common cases.
there is also a pretty big difference in what a compiler can do if we express the computation as a set of operations that transform the sets rather than a little rats nest of mutations and jumps.
if you wanted to vectorize the set/jmp version, you'd be trying to tease apart a problem which is undecidable in the limit. vectorizing the transformer version is trivial.
In python, the way you write this is more similar to how we express the intent, using dict/list comprehension. But the thing is, for anything more complex that your example, the comprehension notation is harder to read and make changes if you are not really used to it
That does look pretty nice for this example. I think the problem with it is that introduces too much new syntax that you have to memorize. The beauty of a for loop is that you can do _anything_ with it. And it all works with the same syntax.
for item in array:
item.foo = bar
for item in array:
item.foo = item.foo * 2
for item in array:
my_bar_func(item.foo)
If you special case certain uses of a for loop and add language syntax around it, of course you can make code terser. But it's nice to rely on a small set of very generally useful syntax.
> The beauty of a for loop is that you can do _anything_ with it.
That’s also the curse: a generic loop can be almost anything (looping over an iterable can't quite express anything, but it can do a lot), so seeing it tells you nothing.
C-style loops can do more (literally anything), and loop-over-iterable syntax has been generally preferred where it can be applied because it tells you more (even if only a little more) about what the block of code is doing up-front.
Constructs that are more specific than loop-over-iterable can be correspondingly more expressive.
I don't find that to be a convincing argument, because it suggests we should write "foo applied to bar" instead of "foo(bar)" in your code. It's just notation, just because it's new, doesn't mean it's bad.
There's maybe an argument to be made about there being _too much_ notation to learn, but notation makes sense for fundamental concepts (which loops clearly are).
Notation is important. It condenses thought and refines the concepts, making them more visible. In fact, some valid mathematical theory came about from figuring out proper notation and then playing around with it, sometimes in non-rigorous (albeit intuitive ways). e.g. consider how physicists wildly move dx and dy around in differential equations (much to mathematicians' dismay)
Ancient greek geometry textbooks were written in long form: "the square of the hypotenuse side is equal to the sum of squares of the other two sides". We can all agree that the "a^2+b^=c^2" notation is better.
The second code doesn’t put all the gizmos in the gizmo box. That’s your intent, but not the reality. All that syntax says is apply function to all elements. It is syntactic sugar for the code you put above; it’s a for each loop.
I'm talking about the readable sentences. The one you labelled as "an awkward way to speak" was unambiguous. The phrasing it seems you preferred was ambiguous. Personally, if I have to write the sentence down and the consumer of the sentence can't ask questions to clarify, I prefer the unambiguous wording. Ie, say exactly what you mean or you may not get what you want.
> A wife asks her husband, a software engineer, “Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6!” A short time later the husband comes back with 6 cartons of milk. The wife asks him, “Why the hell did you buy 6 cartons of milk?” He replied, “They had eggs.”
I think you will find that those “humans” you’ve been hanging out with are all programmers or mathematicians. “Humans” don’t talk like this. Most of them have never heard of set theory.
Maybe it's just my mother tongue, but "pour chaque entrée dans la base de données, prends la moyenne et affiche-la" sounds pretty ok (literally in English, for each entry in the database, take the average and print it)
> "For x in y" is literally what we say when speaking as humans unlike that quote thing.
What about:
"Can you unload the truck?"
The current context gives us implied knowledge that we're talking about the items in the truck and where it's getting unloaded to, such as a warehouse if we're near a warehouse door. We only expand on that verbally when we need to such as "Can you throw out the empty boxes in the truck?".
I think this is why programming is nonintuitive, you have to include important steps with very precise words that often go unsaid. Even "throw out" wouldn't convert to the correct intent if a computer executed that statement as is. You would end up literally throwing the empty boxes out of the truck instead of putting them into a dumpster or garbage can (the likely intent based on this example).
It's not _that_ verbose -- the trade off in clarity is pretty stark IMO.
In practice many people move between languages frequently daily. This syntax and semantics it provides are fairly different from that of popular languages.
Indeed. Also, this notation was lifted straight from Fortran 90 (which itself got it from Matlab, Algol, and the primitive slicing that was possible in older FORTRANs). The idea that a concise notation is helpful for the concept of “put a thing in all the buckets of an array” really is quite old. It does make a lot of sense.
Numpy is all about this. E.g y = np.sin(x). X and y are arrays and you can think of them as «all values of x and y» or «the physical variables x and y»
The PLT position on this is that loops are too expressive. We'd like to use the least powerful tool that can do the job. Loops can express all sorts of incorrect versions of the intended algorithm. It's preferable to try to identify the reusable structure in the algorithm (it might be a "scan" or a "fold", for example) and implement that once and for all. We then provide a simple interface to that algorithm, without any footguns.
> That's like saying a bag is too expressive because I can put all kinds of things into them.
That's entirely accurate. A bag is "too expressive", in that sense. Sometimes you want to constrain the kind of container so you don't put the wrong kind of thing in there.
Another analogy: types. "Any" will let you use anything, but sometimes you want to say "only allow Integers here".
What I intended to hint at is that a bag being expressive is not the issue. Yeah you sometimes want to label the bags, or make special purpose bags. But bags as they are are not too expressive. Them being expressive allows for all that other stuff. Their core utility is what we're after and the rest is secondary support and should be treated as such or else we get lost.
If we act like we're not actually dealing with bags at a fundamental level, we might mislead ourselves and spread the belief that the rules and labels around the bags are what matters. No, they help you (temporarily) to use the bags in a specific way in some context.
In fact, computers are extremely expressive, (bag like) things. The constraints are auxiliary. I think it's important that we keep reminding us what programming is and that it serves a direct purpose, while the bureaucracy is a support structure at best.
Constraints enable reasoning, both automatic and manual.
Loops fit the single-core CPU hardware paradigm extraordinarily well. As soon as you start targeting modern hardware, more constrained recursion/iteration schemes start to buy a lot more in terms of both developer time and compiler complexity.
Agreed that computers are extremely expressive. I think the constraints are necessary though, and not just bureaucracy. After all, what are bugs (especially harmful bugs) but a failure to constrain choices?
More practically, a List is too expressive, if all you need is a Set - which is true and generally good advice to use Set instead of List, if possible.
From what kind of programming hellhole do you come from, where using Set instead of List is good advice? Lists are very natural constructs for computers, sets aren't.
Sets specify a particular interface but not a particular implementation or backing data structure. You can substitute different implementations (including ones backed by lists, vectors, hash tables, and others) depending on your particular needs.
I don't think there's any _hate_ for loops, however, they are a very common pattern, so it's not unreasonable to argue it can be further refined/abstracted.
Most people agree that "for x in y: foo(x)" is an improvement over "for(int i=0; i<=n; i++) {foo(x)}". It's not wild to argue that "foo' x" is an improvement over "for x in y: foo(x)"
> Most people agree that "for x in y: foo(x)" is an improvement over "for(int i=0; i<=n; i++) {foo(x)}"
Well, I don't.
The second version is much clearer to me, for example, if I want to be sure about the running time of the code. Will it take one second or be instantaneous? The first example hides the length of y. I favor a programming style where all loops have clearly identifiable bounds. Using "iterators" hides these lenghts and makes the code much harder to reason about.
Clearer? Did you notice the second version contains a bug?
The first version makes it easier to spot said bug, because it's more concise and with fewer parts where you could make a mistake. Note that even in this very short piece of code it's easy to miss the bug; imagine in actual loops!
You have no guarantees about the running time of the code in either case, not without delving into the specifics of your programming language.
> I favor a programming style where all loops have clearly identifiable bounds. Using "iterators" hides these lenghts and makes the code much harder to reason about.
I find the opposite to be the case. Explicit loops with indexes make off-by-one errors likely, which is one of the most common kinds of error. It's impossible to make that kind of mistake with a foreach or map-over-this operation.
This is mostly a matter of perspective. An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best, in which case it's very easy to find and fix the silly problem.
On the other hand, code that hides things tends to be much harder to debug, when it invariably fails. Why is my program suddenly gobbling 10GB of memory? After several hours of profiling and debugging: ah, here's this particular combination of constructors that allocates and frees a stupid amount of memory for no reason.
> An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best, in which case it's very easy to find and fix the silly problem
Yes, but even better if you don't write the bug to begin with. It can also fail harmfully, like failing to trigger a segfault but producing the wrong computation, resulting in sending the wrong amount of energy to the X-Ray machine, the wrong amount of money in a bank operation, firing the wrong number of missiles, etc.
> code that hides things tends to be much harder to debug, when it invariably fails
In the general case, I agree. In the case of foreach loops (or maps or folds) the good thing is that they are well understood abstractions, not something your fellow coworker wrote and that you must understand from scratch. They are common idioms, just like you don't debug (under normal conditions) how a for-loop with an index works internally.
Yeah, I had to reread that because I'm pretty sure "silently wrong" is the worst case, and not harmlessly so; I would 100% prefer segfaults, which let me actually fix the problem or at least know something's wrong.
The analogous for loop would have you compute n from the size of y. You still don’t know, statically, the length of the loop in that case unless you statically know the size or length of y.
It has the same problem either way. Similarly, if you always know the size of n in the C style loop, then you would always know the size of y in the Python style loop.
The Python loop just has the benefit of being shorter (by a line and a few tokens).
Folks, folks! Can we not downvote loops at least? All we want, I think, are useful tools. For goodness' sake, isn't it obvious that loops are a useful tool?
Not a compulsory tool, not a forbidden tool, not a foolish tool, not obviously the correct tool in all situations, possibly not something that needs to be mainstream in every work flow? Sure, all of those. But ... we're downvoting loops now?
Loops are great if your programming languages supports iterables/iterators/generators (also async generators) like in js/ts for example.
Especially generator-to-generator combinators ie. [0] gives terse, transducer expressiveness over computation on finite/infinite streams, arrays, etc. (all iterables). It's easy to compose, jump into/out-of for-loops if needed for arbitrary yielding (ie. conditionally yielding multiple items, skipping some, halting etc); `continue`, `break`, nesting, yield, yield from (yield*), normal code in for-loops is very intuitive and terse, creating pleasant, understandable code.
Recently I had a chance to break down complex pipeline in finance project into small steps as generator-to-generator transducer functions (can you call generator-to-generator functor a trasducer?), higher order for steps that require extra inputs, leaving all pipeline pure and easy to reason about. Typescript was really helpful doing hard work where each step somehow modifies the input - leaving final result typechecked together with spotting bugs in intermediate steps ie. on their dependendency etc. really nice stuff.
Well, for me, because, compared to other notation, they usually obscure intent.
> Loops are just a nice notation for some computational constructs.
But... they're mostly not.
> Loops are just a nice notation for some computational constructs.
Sometimes, but even then if a language has decent abstraction features that’s usually best for the low-level implementation of a generic algorithm, which you should never have to see when actually applying the algorithm to concrete types. True, if you don't have a generic implementation available, YAGNI often argues in favor of a concrete one for the immediate use case, so generic implementations separated from immediate concrete use isn't the only place to use explicit loops.
Not hate for loops, but if you replace them with, say, array operations, you've removed the need to prove your loops correct -- or removed a possible source of error from getting them wrong. I guess what's clearer is a matter of opinion.
Reconstructing what was meant at high level from arbitrary loops is surely intractable, but could only be a property of a compiler, not a language. Should a compiler like GCC necessarily recognize a matmul loop nest and replace it with a GEMM call? XL always does -- which can make investigating it's optimization annoying -- but then it doesn't actually recognize GEMM.
Oh but in J loops exist, they are mostly implicit in the operation.
So it is not “loopless” per se, as the sigma notation for summation indicates a loop in a single construct, and it “can be written away” using Einstein’s notation.
if you're not writing explicit loops then you must be doing something else. is that something else interesting? you'd have to dig in a little bit to find out.
I've found this tends to happen in my Rust code too, and even in my JavaScript lately (though sadly it has performance costs in JS). It's true that 90% of loops in practice are just for processing collections, and that can be better served in most languages by using a harder-to-mess-up construct that's designed for the purpose.
It really does almost feel like an extension of the goto trajectory, since loops themselves were one of the purpose-built constructs designed to cover specific, common uses of goto.
I wonder if we'll see a "control-flow considered harmful" one day (this is a joke... mostly)
I recently was wondering how to write a program, in SQL, which generates consecutive integers - 0, 1, 2, 3... - up to an arbitrary input value. Only standard SQL is allowed, and familiar constructs are preferred - the code should be understandable to the maintainer.
In J it's i. <n>, like this - i. 5 produces 0 1 2 3 4 .
SQL is not turing complete, at least not without recursions. But you will still get very far when it comes to wrangling data. So far that you may not even need another tool for that purpose.
I think their point was that J and SQL target different domains, and each will be stronger in its respective domain. If I want to join two tables, filtering on some value, sorting, and viewing the first ten results, SQL will likely be the cleaner syntax. If I want to apply a polynomial function to a list of values, and calculate the standard deviation of the result, J will be much cleaner.
There's some similarity, at a high level, with how they work. But it doesn't really make sense to say one is, overall, better than the other, because they don't solve the same problem. It's like saying a hammer is better than a screwdriver.
Admittedly though, recursive CTE's like that are a bit of a minefield in practice. It's easy to confuse the query optimizer after chaining a few of those together, or to outright hit a recursion limit (32,767 in SQL Server).
BPF didn't have loops in the beginning either, but since Linux 5.3 it supports bounded loops as that seems to make programming a lot easier in many cases.
HN's top-voted comment at this moment begins: "Why so much hate for loops?" The item cited as 'hate for loops' is an introduction to 'loopless' programming in J, a universally admired language developed by Iverson. Whether LINQ or SQL etc. are also examples of 'hate for loops' or not ... I'm done.
For every web site there's a moment when user comments need to be declared 'not worth the pain of sifting through.' HN has crossed that threshold for me.
[Edit: My point is that we are crossing a sort of event horizon. Short-sighted micro-kvetching is becoming the largest single focus of user comments, upvotes, etc. on this site. Perennial examples: one-indexing vs zero-indexing; OO 'vs' FP; whitespace. You can list more yourself.]
> For every web site there's a moment when user comments need to be declared 'not worth reading.' HN has crossed that threshold for me.
So what you're doing is the exact same thing, but for HM ITSELF? /j
I don't think think the comment was unwarranted in this case, because the article makes no attempt to explain why what it says is a it admits is a building block of traditional programming is a bad idea. It just says "j does loops bad, do this instead"
...spawned a really interesting conversation on the PL design-tradeoffs of various special-purpose iteration/recursion schemes.
> J, a universally admired language developed by Iverson.
Even in hard-core PL communities that seems like a reach. Lots of PL courses exclude APL/J, which is a pretty strong empirical proof-point against universal (or even strong majority) admiration. Outside of PL enthusiast communities, array PLs sit somewhere between "niche" and "esoteric".
I think there is a lot to admire in APL, J, et al. They clearly had far-reaching influence. But there's also a reason that the dominant reaction is closer to "um... heh" than admiration. There's no need to over-state the case here.
It's notable that the first J interpreter, while written in C, has a similar style --- it defines a macro to run a loop "implicitly", and then uses that throughout: https://code.jsoftware.com/wiki/Essays/Incunabulum