5 ms·

I love for loops because in one line I can grasp what the loop intends to compute and usually leads me towards what I should pay attention to when debugging. T

I love for loops because in one line I can grasp what the loop intends to compute and usually leads me towards what I should pay attention to when debugging. This all seems to require me to remember how it’s implemented and to think about what’s happening, which is more work than I’d like to do. Perhaps the assumptions you’d bring along when using a language like Julia alleviates it a bit, but still if someone else looks at my code they’ll have to look through all this fanciness.

marcus_holmes 8y ago
I did laugh at my own ignorance a bit when they say "given the simplicity of the method", apparently referring to an incomprehensible (to me) bunch of maths jargon. I sometimes wish I had better maths, but then it's so rarely I ever need it, I think I'm better off learning another language.
- Retric 8y ago
  It's not always obvious that you needed it when you don't understand it.
  - anonytrary 8y ago
    This. The more math you learn, the more relevant it becomes in everything you do. If you can't do calculus, you'll likely never see where it was you could have been using it to your advantage.
  - marcus_holmes 8y ago
    this is probably true. Thanks for the motivation to go learn some more :)
- cormullion 8y ago
  I don't think you need to be good at maths to use Julia. I'm glad I learned some basic trigonometry at school, though...
- romwell 8y ago
  >when they say "given the simplicity of the method" I think they meant the implementation, in the end, is not complicated: there are a few variables that get updated according to some formulas, and that's it; there's no branching, no need for fancy data structures, etc. The method itself is not simple - neither deriving it nor fine-tuning is intuitive, as can be said about other variations on the theme of gradient descent. The theme is simple: to reach a bottom of a hill, go in the steepest downhill direction[1]. Making it work - and making it work fast - requires modifications to this idea, which require quite a bit of work. [1]https://en.wikipedia.org/wiki/Gradient_descent https://en.wikipedia.org/wiki/Gradient_descent
trgn 8y ago
In more conventional scripting languages than Julia, I wish more people would write simple for-loops for simple problems, instead of cramming in some functional construct, just because the language allows it. The extra indirection, the added object allocation, the deepening of the call-stack, it all just crufts up the whole routine. For-loops are simple, execute tidily, and keep code localized, that's good stuff.
BeetleB 8y ago
>I love for loops because in one line I can grasp what the loop intends to compute and usually leads me towards what I should pay attention to when debugging. C++ programmer here. In my team I've actively pushed not to have for loops when something from the algorithms library will do (transform, copy_if, find_if, etc). The reason: Because I usually cannot quickly grasp what the for loop intends to compute - I'm quite surprised you're saying the opposite. I met with some resistance, as people aren't used to thinking in terms of algorithms. So I was slowly browsing our code base, finding for loops, and converting the trivial ones to calls to the algorithms library. Then I came across one for loop that was, frankly, a pointless loop. It didn't seem to do anything useful. I was sure it was a bug, but I couldn't tell from the context what the code was supposed to do. I emailed the committer, and he fixed it. Then I took the fixed version and converted it to an algorithms call. Then I made a presentation to the team showing some of my examples, including the one with the bug. That bug convinced many to start using other constructs. Every time you write a for loop for which there is an algorithm in the library, you are reinventing the wheel, and have a good chance of introducing a bug. (Sorry, probably a bit of a tangent to the whole thread).
- srean 8y ago
  Very true, wish your comment had more upvotes to bubble up to the top of the thread. Its a lot easier to miss edge cases, have off by one errors when one is manipulating iter count directly. Working with the abstraction natural to the problem reduces these. So manipulating /creating / merging rows, columns, blocks when working with arrays help avoid many of these problems. Usually the algorithm pseudocode is written in terms of such abstractions.
- RobLach 8y ago
  Compelling arguments here. What you’re saying is true in my experience as well in the cases you’ve explained.
- skgoa 8y ago
  > Because I usually cannot quickly grasp what the for loop intends to compute - I'm quite surprised you're saying the opposite. Yeah, a for loop breaks the relevant information up into several lines and depending on language it adds quite a bit of boilerplate.
Iwan-Zotow 8y ago
! INitial state, precondition, postcondition and increment right in front of your eyes. For-loops are rather rich in context information

marcus_holmes 8y ago

I did laugh at my own ignorance a bit when they say "given the simplicity of the method", apparently referring to an incomprehensible (to me) bunch of maths jargon. I sometimes wish I had better maths, but then it's so rarely I ever need it, I think I'm better off learning another language.

Retric 8y ago
It's not always obvious that you needed it when you don't understand it.
- anonytrary 8y ago
  This. The more math you learn, the more relevant it becomes in everything you do. If you can't do calculus, you'll likely never see where it was you could have been using it to your advantage.
- marcus_holmes 8y ago
  this is probably true. Thanks for the motivation to go learn some more :)
cormullion 8y ago
I don't think you need to be good at maths to use Julia. I'm glad I learned some basic trigonometry at school, though...
romwell 8y ago
>when they say "given the simplicity of the method" I think they meant the implementation, in the end, is not complicated: there are a few variables that get updated according to some formulas, and that's it; there's no branching, no need for fancy data structures, etc. The method itself is not simple - neither deriving it nor fine-tuning is intuitive, as can be said about other variations on the theme of gradient descent. The theme is simple: to reach a bottom of a hill, go in the steepest downhill direction[1]. Making it work - and making it work fast - requires modifications to this idea, which require quite a bit of work. [1]https://en.wikipedia.org/wiki/Gradient_descent https://en.wikipedia.org/wiki/Gradient_descent

trgn 8y ago

In more conventional scripting languages than Julia, I wish more people would write simple for-loops for simple problems, instead of cramming in some functional construct, just because the language allows it. The extra indirection, the added object allocation, the deepening of the call-stack, it all just crufts up the whole routine. For-loops are simple, execute tidily, and keep code localized, that's good stuff.

BeetleB 8y ago

>I love for loops because in one line I can grasp what the loop intends to compute and usually leads me towards what I should pay attention to when debugging. C++ programmer here. In my team I've actively pushed not to have for loops when something from the algorithms library will do (transform, copy_if, find_if, etc). The reason: Because I usually cannot quickly grasp what the for loop intends to compute - I'm quite surprised you're saying the opposite. I met with some resistance, as people aren't used to thinking in terms of algorithms. So I was slowly browsing our code base, finding for loops, and converting the trivial ones to calls to the algorithms library. Then I came across one for loop that was, frankly, a pointless loop. It didn't seem to do anything useful. I was sure it was a bug, but I couldn't tell from the context what the code was supposed to do. I emailed the committer, and he fixed it. Then I took the fixed version and converted it to an algorithms call. Then I made a presentation to the team showing some of my examples, including the one with the bug. That bug convinced many to start using other constructs. Every time you write a for loop for which there is an algorithm in the library, you are reinventing the wheel, and have a good chance of introducing a bug. (Sorry, probably a bit of a tangent to the whole thread).

srean 8y ago
Very true, wish your comment had more upvotes to bubble up to the top of the thread. Its a lot easier to miss edge cases, have off by one errors when one is manipulating iter count directly. Working with the abstraction natural to the problem reduces these. So manipulating /creating / merging rows, columns, blocks when working with arrays help avoid many of these problems. Usually the algorithm pseudocode is written in terms of such abstractions.
RobLach 8y ago
Compelling arguments here. What you’re saying is true in my experience as well in the cases you’ve explained.
skgoa 8y ago
> Because I usually cannot quickly grasp what the for loop intends to compute - I'm quite surprised you're saying the opposite. Yeah, a for loop breaks the relevant information up into several lines and depending on language it adds quite a bit of boilerplate.

Iwan-Zotow 8y ago

! INitial state, precondition, postcondition and increment right in front of your eyes. For-loops are rather rich in context information