4 ms·

True. I think some FP people, especially the new converts, seem to hold a weird view that simple == shorter code, which is SIMPLY not true.

avmich 9y ago
Size often correlates with complexity. I suspect a size of certain kind can serve as a definition of complexity. In programming it's often the case that a shorter program is preferred to a longer.
- lucio 9y ago
  google code golf. In the productive world, an easier to understand program is better, even if that implies more code. Variable names like "TotalAmount" are better than "x". Also, a 10 line procedural code is better than a one-line function, just because is easier to understand, and easier to change in the right way when the specification change. (it will change 15 times before implementation)
  - avmich 9y ago
    Thank you. My experience tells me another story. More code in terms of code size in bytes isn't always more complex. For example, sometimes one wants to emphasize the similarities and analogies and spends extra bytes to show that. But that in my experience is rare - and while it could be beneficial for a novice or for a substantially unfamiliar code, for good code if soon becomes burdensome. TotalAmount instead of x would probably drive crazy most mathematicians. Or most APL programmers. And probably most people demonstrating code on a whiteboard. Even in more mainstream languages like Clojure or Haskell a lot of variables are rather short; it's unfortunate that C++ with history of Hungarian notation, Java or C# have a habit to use long names. There is a reason why mathematical notation exist. F = gmM / (R^2) is often preferable to "force is proportional to both masses and to inverse of square of the distance with proportionality coefficient gamma". My advice for you is to try develop a program in REPL fashion. Standard J package from Jsoftware has a good environment for that - you can launch a computation expressed in a line, see the result and if you aren't satisfied just copy the line, make changes and launch it again. Pretty convenient in comparison to classical save-compile-run-checkResults loop of, say, C++ development. One line is certainly easier to change 15 times before implementation when specification change.
- oh-kumudo 9y ago
  > Size often correlates with complexity. It can correlate with complexity positively and negatively. Which one explanation below is easier to understand? Photosynthesis? Or 'process used by plants and other organisms to convert light energy into chemical energy that can later be released to fuel the organisms' activities'? You could argue that Photo+Synthesis might be enough to imply the essential underlying mechanism of the process itself, but I think more people would prefer the latter just for clarity.
  - avmich 9y ago
    I don't think example with photosynthesis suggests anything here. Naming and describing are different things. You can certainly name verbs in J, like functions in other languages, and get the code both shorter and easier to understand, because it would be distracting to always read the long definition. I think more people actually prefer former almost always, except when defining what that the photosynthesis is.

avmich 9y ago

Size often correlates with complexity. I suspect a size of certain kind can serve as a definition of complexity. In programming it's often the case that a shorter program is preferred to a longer.

lucio 9y ago
google code golf. In the productive world, an easier to understand program is better, even if that implies more code. Variable names like "TotalAmount" are better than "x". Also, a 10 line procedural code is better than a one-line function, just because is easier to understand, and easier to change in the right way when the specification change. (it will change 15 times before implementation)
- avmich 9y ago
  Thank you. My experience tells me another story. More code in terms of code size in bytes isn't always more complex. For example, sometimes one wants to emphasize the similarities and analogies and spends extra bytes to show that. But that in my experience is rare - and while it could be beneficial for a novice or for a substantially unfamiliar code, for good code if soon becomes burdensome. TotalAmount instead of x would probably drive crazy most mathematicians. Or most APL programmers. And probably most people demonstrating code on a whiteboard. Even in more mainstream languages like Clojure or Haskell a lot of variables are rather short; it's unfortunate that C++ with history of Hungarian notation, Java or C# have a habit to use long names. There is a reason why mathematical notation exist. F = gmM / (R^2) is often preferable to "force is proportional to both masses and to inverse of square of the distance with proportionality coefficient gamma". My advice for you is to try develop a program in REPL fashion. Standard J package from Jsoftware has a good environment for that - you can launch a computation expressed in a line, see the result and if you aren't satisfied just copy the line, make changes and launch it again. Pretty convenient in comparison to classical save-compile-run-checkResults loop of, say, C++ development. One line is certainly easier to change 15 times before implementation when specification change.
oh-kumudo 9y ago
> Size often correlates with complexity. It can correlate with complexity positively and negatively. Which one explanation below is easier to understand? Photosynthesis? Or 'process used by plants and other organisms to convert light energy into chemical energy that can later be released to fuel the organisms' activities'? You could argue that Photo+Synthesis might be enough to imply the essential underlying mechanism of the process itself, but I think more people would prefer the latter just for clarity.
- avmich 9y ago
  I don't think example with photosynthesis suggests anything here. Naming and describing are different things. You can certainly name verbs in J, like functions in other languages, and get the code both shorter and easier to understand, because it would be distracting to always read the long definition. I think more people actually prefer former almost always, except when defining what that the photosynthesis is.