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

51–60 of 129 posts

Re: Loopless Programming

#51

Post by 3xblah »

jameshart wrote: post #20

Most programmers have worked in a largely loopless programming language: SQL. IT lets you easily build the same sort of ‘Boolean state for every item’ as this discusses, but it requires you to be much more explicit about which items you want to line up next to one another if you’re joining two lists together. In modern languages we usually just use mapreduce like functional approaches to handle the same sort of thing…

Is there a difference between loopless and "largely loopless".

https://docs.oracle.com/cd/B28359_01/appdev.111/b28370/loop_...

The wiki author, who also wrote J for C Programmers, never uses the word "unusual". He uses the words "different" and "better".

Is it only the parent comment that invokes the word "unusual". The comment also implies J is not a "modern language", whatever that means..

Re: Loopless Programming

#52

Post by whateveracct »

johnday wrote: post #48

Almost any functional programming language has the same power and quality of life in programming, except with the added bonus that things have names . If you come up with a new looping construct (which you probably won't), just create a type class for it and you're done; any data structure you want now has that construct, if you give it a sensible implementation. It would be very unusual to write a Haskell program wi…

And even when recursion does show up, the return value tends to "read" better. Like "the sum is the head of the list plus the sum of the tail." Whereas with an imperative loop, I have to either recognize an idiom or manually execute the loop in my brain's VM.

Re: Loopless Programming

#53

Post by whateveracct »

agumonkey wrote: post #38
jadbox wrote: post #7

As far as explicit loops, I probably use write out a loop once a month and maybe not even that often. Using map/filter/reduce [as well as sugar funcs until/any/all] solves virtually all the common cases of working with lists. Granting it's not sufficient if you're writing specialized code like sorting arrays efficiently, but for general development, going higher-order is the way to go.

You can say this now but not long ago map/filter/reduce were almost esoteric.

I'd say even just 5 years ago they were weird FP features, with LINQ being the most mainstream version. Now Go is the only mainstream language without them hehe.

Re: Loopless Programming

#54

Post by NOGDP »

inimino wrote: post #41
NOGDP wrote: post #25

Earlier quoted context omitted.

It is wherever '+'/(equivalent function) overloading is a thing - C++, Haskell, Rust, etc. There isn't even a good reason to think of it as a loop, because for different types it may not be a loop at all.

You seem to have missed the point of the original remark that (x + y) is a statement, and you're missing the point of my clarification. > "(x + y) is an expression rather than a statement". 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 obvio…

> 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 algebra/numerical libraries come with these defined for you. In languages without polymorphism, such as C, you might have special names for these functions instead, such as vector_add. The actual use of these would look like '(x + y)' in Haskell, Rust, C++, etc. and 'vector_add(x, y)' in C, and would (or at least could) be expressions.

> . Which, by the way, includes idiomatic C++, Haskell, and Rust, in all of which overloading (+) to do something so specific would at best be seen in a purpose-specific library (like numpy) only, but isn't automatically present in the language.

Linear Algebra types/functions aren't automatically present in most languages. A library can be implemented to use this syntax to add vectors/matrices/whatever very easily, and many are [1][2]. Even if the library doesn't use '+' as the operator for eg. vector addition, it could, and it chooses to not use '+', but that is not very important.

> In most languages that most programmers use, for loops are common, and if all of those are replaced by expressions, you get a more expressive language (for dealing with arrays).

I'm not sure what you mean by 'more expressive'? Maybe you prefer a more declarative/functional programming style but for loops have their place in imperative languages. J doesn't actually force you to write all of you code in that style - the language has constructs that can be used to construct loops that look like imperative C [3].

> That's the point that the article is making, and you haven't addressed it at all.

The features described in this article are equivalent to a library implemented on top of Haskell, Rust, C++. The usage of such a library would even look almost exactly the same.

[1] http://arma.sourceforge.net/docs.html#part_classes [2] http://hackage.haskell.org/package/linear [3] https://www.jsoftware.com/docs/help701/dictionary/ctrl.htm

Re: Loopless Programming

#55

Post by misterdoubt »

3xblah wrote: post #51
jameshart wrote: post #20

Most programmers have worked in a largely loopless programming language: SQL. IT lets you easily build the same sort of ‘Boolean state for every item’ as this discusses, but it requires you to be much more explicit about which items you want to line up next to one another if you’re joining two lists together. In modern languages we usually just use mapreduce like functional approaches to handle the same sort of thing…

Is there a difference between loopless and " largely loopless". https://docs.oracle.com/cd/B28359_01/appdev.111/b28370/loop_... The wiki author, who also wrote J for C Programmers, never uses the word "unusual". He uses the words "different" and "better". Is it only the parent comment that invokes the word "unusual". The comment also implies J is not a "modern language", whatever that means..

PL/SQL is not SQL.

Re: Loopless Programming

#56

Post by 7thaccount »

jameshart wrote: post #20

Most programmers have worked in a largely loopless programming language: SQL. IT lets you easily build the same sort of ‘Boolean state for every item’ as this discusses, but it requires you to be much more explicit about which items you want to line up next to one another if you’re joining two lists together. In modern languages we usually just use mapreduce like functional approaches to handle the same sort of thing…

From someone who has experience in mostly SQL, Python, Linux commands, and a smattering of other languages that I've played with (Haskell, Common Lisp, F#, Ada, Prolog, Julia, Forth, Fortran...etc) I can say that J and modern APL systems are completely different in a lot of ways. Yes functional languages have a lot built around map/fold/filter that is very similar to J's tacit programming, but the implementation makes all the difference. With J you just have math basically (assuming you don't use the non idiomatic if-then constructs). I'm not saying J is better than Haskell at all, but keep in mind that when they say "loopless" it's possible that what they're trying to convey is that there are no imperative loops AND the combination of dynamic typing and tacit trains means you have something terse with zero boiler plate.

Re: Loopless Programming

#57

Post by misterdoubt »

theamk wrote: post #46
inimino wrote: post #41

Earlier quoted context omitted.

You seem to have missed the point of the original remark that (x + y) is a statement, and you're missing the point of my clarification. > "(x + y) is an expression rather than a statement". 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 obvio…

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.

Re: Loopless Programming

#58

Post by kragen »

NOGDP wrote: post #11

> Looping - performing a computation repeatedly - is what programs do. In most computer languages, all loops are expressed by one of two statements: > Do While - repeat a code block until a condition is met > For - repeat a code block, with a loop index indicating how many times the block has been repeated. > Programmers trained on scalar languages have spent many years internalizing the Do-While and For paradigms. D…

It's disappointing to see someone aggressively defending their ignorance like this. It's okay if you don't understand what the article is saying, but it's unfortunate that you are blaming that on the article.

Maybe your time would be better spent solving some coding challenges in J or another array language like Dyalog APL, Kona, or A+, then comparing your solutions with others’ using the same language, rather than posting voluminous comments about how your lack of understanding means there's nothing to understand. It probably won't change your life, but it might be a useful tool in your mental toolbox when you're using more mainstream languages like R, SQL, or Octave; libraries like TensorFlow, Numpy, Pandas, PyTorch, or parts of Boost; or hardware like GPUs or processors with NEON and SSE.

(Related: Blub.)

Re: Loopless Programming

#59

Post by hinkley »

k__ wrote: post #42
hinkley wrote: post #3

I recall another language that was trying to do something similar. In most languages you have to decide about x:1 versus x:* relationships very early and it’s a painful refactor to go back and fix it. This one tried to fix it as well so that much of the time you only changed the variable declaration and the code just worked. jQuery made a similar observation, and many of its functions are list comprehensions. If they…

What's the inverse behavior?

Ah, yes.

I meant fail on an operation on an empty set. The number of times that I’ve had a potentially empty set is a fraction of all situations. Often a select all/select none situation, and adding a flag for silent failure in that case is cheap compared to all of the other bugs I’ve had to fix.

Re: Loopless Programming

#60

Post by NOGDP »

kragen wrote: post #58
NOGDP wrote: post #11

> Looping - performing a computation repeatedly - is what programs do. In most computer languages, all loops are expressed by one of two statements: > Do While - repeat a code block until a condition is met > For - repeat a code block, with a loop index indicating how many times the block has been repeated. > Programmers trained on scalar languages have spent many years internalizing the Do-While and For paradigms. D…

It's disappointing to see someone aggressively defending their ignorance like this. It's okay if you don't understand what the article is saying, but it's unfortunate that you are blaming that on the article. Maybe your time would be better spent solving some coding challenges in J or another array language like Dyalog APL, Kona, or A+, then comparing your solutions with others’ using the same language, rather than p…

Are you trying to address anything I've said, or just ranting for another reason?
Post reply on HN