6 ms·

The Virtus issue is simply an example of bad design. When you add magic that can't be guaranteed by the language, you're eventually going to run into problems.

The Virtus issue is simply an example of bad design. When you add magic that can't be guaranteed by the language, you're eventually going to run into problems. Just look at Hibernate. As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. And advanced type systems are not unique to functional languages. I'm also not clear on why the example testing code is better. It doesn't look much different from what I'd write in any language (excepting boilerplate). So yeah, correctness and testability. It's available in most languages. Also, what's up with all the single-letter variable names?

donjigweed 11y ago
<< As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. All of the FP languages I'm familiar with provide easy access to mutable collections.
sbergot 11y ago
> a language with no mutable types If we are talking about haskell, mutability is absolutely an option when it is the only way to write fast code. This is exactly what is done here: http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-ways-are-the-best/ http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-... > And advanced type systems are not unique to functional languages. "Advanced type system" does not really mean much. A bit like the weak/strong static typing distinction. However there are still significant differences between the c#/java/scala family and the haskell one. The fact that objects are not nullable by default and the absence of subtyping are considered as two big advantages for many people. > Also, what's up with all the single-letter variable names? when the code is abstract and the scope of a variable is less than three lines, it can be ok to use one letter for its name.
the_af 11y ago
> As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. There are always escape hatches for when you absolutely need mutability. > And advanced type systems are not unique to functional languages. True. It's just that a lot of progress (but not all, of course) in advanced type systems is pioneered by languages which are often described as functional. > So yeah, correctness and testability. It's available in most languages. Correctness and testability are properties of the software, not the language. As such, of course you can achieve them with your favorite one. But some languages provide better tools to achieve some degree of correctness and testability which would require a greater effort with other languages. > Also, what's up with all the single-letter variable names? This is standard practice in many functional languages. Whenever the abstractness goes up (or the "more general" something is), the identifiers become shorter, since the name itself "means less". Hence why you see code that does something to every x in some kind of container xs; what would you gain with longer identifiers, except maybe misleading the reader?
- PaulAJ 11y ago
  Also, any imperative algorithm can be translated into a functional algorithm with, at most, O(log n) increase in complexity, and usually with none.
kazagistar 11y ago
> Also, what's up with all the single-letter variable names? Words are not useful if your variables don't really have semantically meaningful names. Also, if your code is a simple one-liner, it does not really add too much benefit to name everything, if it is obvious from the (very local) context. For example, when I look at something like: ordered (x:y:xs) = x <= y && ordered (y:xs) I could do something like: ordered (first:second:remainingList) = first <= second && ordered (second:remainingList) ... but if anything, that will make it harder to read.
- deleted 11y ago
  [deleted]
- SparklingCotton 11y ago
  Then why did you call your variables x and y, and not y and x? Surprise: because there IS a semantic meaning to the order. The haskell variable naming convention is bad. What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope. I see a lot of haskell code that looks like FORTRAN. Haskell code is yet not written in large companies where there is a readability requirement. I just hope more programmers with a better taste for readability joins the Haskell ranks. The readability story needs to improve (and I see it improving a bit..)
  - BWStearns 11y ago
    >> Haskell code is yet not written in large companies where there is a readability requirement As a counterargument: Haxl at Facebook. https://github.com/facebook/Haxl https://github.com/facebook/Haxl The convention isn't terrible, it's just a convention and takes a bit to get used to. The (x:y:xs) pattern is useful for when you could at best describe x and y as thing1 and thing2 and xs as theRestOfTheThings. Since the extra letters add no real clarity it's not a bad way to keep things concise. Once you get used to the pattern it's better because if you see (x:y:xs) you know that the things themselves are less important than their order out of an array.
  - 11y ago

donjigweed 11y ago

<< As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. All of the FP languages I'm familiar with provide easy access to mutable collections.

sbergot 11y ago

> a language with no mutable types If we are talking about haskell, mutability is absolutely an option when it is the only way to write fast code. This is exactly what is done here: http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-ways-are-the-best/ http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-... > And advanced type systems are not unique to functional languages. "Advanced type system" does not really mean much. A bit like the weak/strong static typing distinction. However there are still significant differences between the c#/java/scala family and the haskell one. The fact that objects are not nullable by default and the absence of subtyping are considered as two big advantages for many people. > Also, what's up with all the single-letter variable names? when the code is abstract and the scope of a variable is less than three lines, it can be ok to use one letter for its name.

the_af 11y ago

> As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. There are always escape hatches for when you absolutely need mutability. > And advanced type systems are not unique to functional languages. True. It's just that a lot of progress (but not all, of course) in advanced type systems is pioneered by languages which are often described as functional. > So yeah, correctness and testability. It's available in most languages. Correctness and testability are properties of the software, not the language. As such, of course you can achieve them with your favorite one. But some languages provide better tools to achieve some degree of correctness and testability which would require a greater effort with other languages. > Also, what's up with all the single-letter variable names? This is standard practice in many functional languages. Whenever the abstractness goes up (or the "more general" something is), the identifiers become shorter, since the name itself "means less". Hence why you see code that does something to every x in some kind of container xs; what would you gain with longer identifiers, except maybe misleading the reader?

PaulAJ 11y ago
Also, any imperative algorithm can be translated into a functional algorithm with, at most, O(log n) increase in complexity, and usually with none.

kazagistar 11y ago

> Also, what's up with all the single-letter variable names? Words are not useful if your variables don't really have semantically meaningful names. Also, if your code is a simple one-liner, it does not really add too much benefit to name everything, if it is obvious from the (very local) context. For example, when I look at something like: ordered (x:y:xs) = x <= y && ordered (y:xs) I could do something like: ordered (first:second:remainingList) = first <= second && ordered (second:remainingList) ... but if anything, that will make it harder to read.

deleted 11y ago
[deleted]
SparklingCotton 11y ago
Then why did you call your variables x and y, and not y and x? Surprise: because there IS a semantic meaning to the order. The haskell variable naming convention is bad. What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope. I see a lot of haskell code that looks like FORTRAN. Haskell code is yet not written in large companies where there is a readability requirement. I just hope more programmers with a better taste for readability joins the Haskell ranks. The readability story needs to improve (and I see it improving a bit..)
- BWStearns 11y ago
  >> Haskell code is yet not written in large companies where there is a readability requirement As a counterargument: Haxl at Facebook. https://github.com/facebook/Haxl https://github.com/facebook/Haxl The convention isn't terrible, it's just a convention and takes a bit to get used to. The (x:y:xs) pattern is useful for when you could at best describe x and y as thing1 and thing2 and xs as theRestOfTheThings. Since the extra letters add no real clarity it's not a bad way to keep things concise. Once you get used to the pattern it's better because if you see (x:y:xs) you know that the things themselves are less important than their order out of an array.
- 11y ago