Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Loopless Programming

code.jsoftware.com

Post reply on HN
Print view View original

81–90 of 129 posts

Re: Loopless Programming

#81

Post by thenewnewguy »

jonny383 wrote: post #78

This article doesn't actually list any self-claimed "fundamental deficiencies". There's a reason that C (any many other languages) have been using pre and post conditional loops for over fifty years - because it's what the machine actually does, and they are straight forward to follow. The article mentions "A C programmer would write", and then shows two nested for loops. This is almost correct, but I think any good…

I have no real comment on C vs J in this instance, but I find it ironic these two statements appear in the same comment:

> There's a reason that C (any many other languages) have been using pre and post conditional loops for over fifty years

> The J language was written in 1990. It's now 2019. The language is just wrong.

Is some practice being old good or bad?

Re: Loopless Programming

#82

Post by jonny383 »

thenewnewguy wrote: post #81
jonny383 wrote: post #78

This article doesn't actually list any self-claimed "fundamental deficiencies". There's a reason that C (any many other languages) have been using pre and post conditional loops for over fifty years - because it's what the machine actually does, and they are straight forward to follow. The article mentions "A C programmer would write", and then shows two nested for loops. This is almost correct, but I think any good…

I have no real comment on C vs J in this instance, but I find it ironic these two statements appear in the same comment: > There's a reason that C (any many other languages) have been using pre and post conditional loops for over fifty years > The J language was written in 1990. It's now 2019. The language is just wrong. Is some practice being old good or bad?

It's highlighting that C (and related languages) have been using loops for over fifty years, and that J has been around for 29 years with no marketshare. Therefore, it's safe to assume that A) C is correct, and people use loops for a reason, and B) J is wrong.

Re: Loopless Programming

#83

Post by [deleted] »

misterdoubt wrote: post #57
theamk wrote: post #46

Earlier quoted context omitted.

I can tell you that at least in Python, for loops are not common for math. In fact, if I saw a C-style for loop counting indices, I’d defect it in any code I review. For simple things, you have list comprehensions and things like “sum”, while for complex things one should reach for numpy.

A list comprehension is still a for loop. Using `for x in list` instead of `for i in len(list)` is a nice bit of sugar, but still a for loop. That said, high-performance Python does generally discourage the use of loops in favor of vectorised operations.

[deleted]

Re: Loopless Programming

#84

Post by brudgers »

misterdoubt wrote: post #57
theamk wrote: post #46

Earlier quoted context omitted.

I can tell you that at least in Python, for loops are not common for math. In fact, if I saw a C-style for loop counting indices, I’d defect it in any code I review. For simple things, you have list comprehensions and things like “sum”, while for complex things one should reach for numpy.

A list comprehension is still a for loop. Using `for x in list` instead of `for i in len(list)` is a nice bit of sugar, but still a for loop. That said, high-performance Python does generally discourage the use of loops in favor of vectorised operations.

I agree Python list comprehensions have loop semantics. But in fairness, a list comprehension in Python is an expression not a statement. Maybe it's best to think of Python's list comprehensions as loops with an implicit return.

Re: Loopless Programming

#85

Post by NOGDP »

inimino wrote: post #73
NOGDP wrote: post #54

Earlier quoted context omitted.

> The point isn't that (x + y) wouldn't be a statement in other languages, rather than point is that in languages the reader of the article is most likely to be familiar with, you would use a for loop to solve the problem, and obviously a for loop is a statement, not an expression. No, in other languages you would write one function that specifies how to perform an operation per type, then reuse that, and most linear…

> This seems like a pretty low-effort write-up. You're not the audience for the article and that's what this entire thread shows. You missed the fact that you were not the audience, and that makes this a low-effort dismissal. Rather than trying to get the point of the article, you're picking on minutiae and trying to pick it apart. This is why we can't have nice discussions about programming languages. The audience f…

I'm not trying to prove the article wrong, my point is only that it's not well written and filled with baseless claims such as:

> J's approach to iteration is vastly better than other languages.

Re: Loopless Programming

#86

Post by inimino »

jonny383 wrote: post #82
thenewnewguy wrote: post #81

Earlier quoted context omitted.

I have no real comment on C vs J in this instance, but I find it ironic these two statements appear in the same comment: > There's a reason that C (any many other languages) have been using pre and post conditional loops for over fifty years > The J language was written in 1990. It's now 2019. The language is just wrong. Is some practice being old good or bad?

It's highlighting that C (and related languages) have been using loops for over fifty years, and that J has been around for 29 years with no marketshare. Therefore, it's safe to assume that A) C is correct, and people use loops for a reason, and B) J is wrong.

> safe to assume

Assuming that because something is popular it must be good is an example of assuming that things are as they should be, or deriving ought from is[1]. Assuming that because something is unpopular, it must be "wrong" is worse.

Do you make all your technical decisions based on what is most popular? Do you always assume that whatever has not become popular must be "wrong"?

[1]: https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem

Re: Loopless Programming

#87

Post by jonny383 »

inimino wrote: post #86
jonny383 wrote: post #82

Earlier quoted context omitted.

It's highlighting that C (and related languages) have been using loops for over fifty years, and that J has been around for 29 years with no marketshare. Therefore, it's safe to assume that A) C is correct, and people use loops for a reason, and B) J is wrong.

> safe to assume Assuming that because something is popular it must be good is an example of assuming that things are as they should be, or deriving ought from is[1]. Assuming that because something is unpopular, it must be "wrong" is worse. Do you make all your technical decisions based on what is most popular? Do you always assume that whatever has not become popular must be "wrong"? [1]: https://en.wikipedia.org/w…

Except I'm not assuming it's wrong because it's unpopular. Read the original comment, I clearly stated why it's wrong. My last comment was giving you a possible explanation as to why the witnessed behavior has occurred.

Also, please show me one successful software package (and by successful, I mean largely consumed by consumers and a product leader) that does not use looping techniques.

Like all technical decisions, they are made by using the most correct and appropriate choice. Which is why the industry has been using pre and post condition loops since the beginning. This "don't use loops" attitude is equivalent to trying to reinvent the wheel.

Re: Loopless Programming

#88

Post by brudgers »

stewbrew wrote: post #80

2 questions: - Doesn't "loopless" actually mean "implicit looping"? (unless you assume infinite parallelization) - How do you debug a chain of "loopless" functions when some corner case invalidates your assumptions?

1. The article describes different types of loops. If you buy that, then "looping" can mean several similar but distinct things. To me, the big distinction is whether or not we "know" how long the input is. Or more broadly, whether or not we can assert that the input terminates.

If we can assert that that the input terminates then we can use "for i; while i 2. If the second form of looping -- calling input.next -- is like what you mean by "loopless" then debugging corner cases means something like looking at crash logs. But debugging any crash means looking at crash logs.

Or sometimes it means just restarting the system. Which is what a lot of debugging looks like at the interesting scale of widely distributed significantly concurrent computation.

3. For problems of interesting size, assumptions about the data can be made based on statistical analysis of the input. Then corner cases become statistical anomalies that may or may not be worth engineering against. Systems crashing are as inevitable as off by one errors.

Re: Loopless Programming

#89

Post by blt »

stabbles wrote: post #28

C++ devs are encouraged to do loopless programming by using algorithms in the standard library; plus C++20 ranges should improve the ease of loopless programming. Where J shines is array based programming. The C++ algorithms are concerned with vectors, but in J you can combine matrices, vectors and scalars in concise expressions.

The C++ library has a huge limitation: algorithms return a single iterator that cannot be further consumed by other algorithms. This makes it impossible to chain algorithms in a manner like LINQ. The ranges library will make a dramatic difference for this programming style.

Re: Loopless Programming

#90

Post by lgas »

defen wrote: post #75
kragen wrote: post #72

Earlier quoted context omitted.

Try watching this video; it will only take you 8 minutes, but within 3 minutes you should have an idea of why array languages are different from having an ndarray library available in Rust or having typeclasses in Haskell: https://www.youtube.com/watch?v=a9xAKttWgP4 After you watch that you will of course suspect that APL and other array languages like J are a sort of DSL for things like numerical linear algebra, whi…

Pretty mind-blowing. Any Haskell experts want to attempt a point-free version of the function that calculates the next generation for an arbitrary matrix in Conway’s Game of Life?

If you use a the right representation of the board in Haskell then you don't have to write a function to calculate the next generation at all, you can just use Comanadic extend, as Chris Penner does here: https://github.com/ChrisPenner/conway/blob/master/src/Conway...
Post reply on HN