Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
-
Root797772yHow about Ruby’s:
array.map(&:method_name)
You can wrap it in a method and yield to a provided block, and it’s still shorter than both:
def apply(array, &block)
array.map do |item|
yield item
end
end -
No, you simply have a point of view on a picture at large. Code golf is not a serious time spent on writing good program, especially when we talk Haskell.
-
"Shorter code means less bugs" only makes sense in a statistical view but when the code is short for the sake of being short, but unreadable, then I'm pretty sure more bugs will surface than longer, but readable and maintainable code.
I have the feeling that such statements come from people who are obsessed with "manually compressing" code, which only makes sense in extremely performance critical parts, which is rarely the case in normal software projects anyway. -
@PonySlaystation In Haskell it's also a way to show off how smart you are because the best way to compress code manually is by introducing way too much abstraction. This also makes it very difficult to meaningfully discuss whether the abstractions are actually necessary.
-
atheist99892yWhen you mentioned character count, I thought this was going to be about code golf. I was disappointed...
-
@atheist It kinda is, except every online Haskell programmer is constantly participating.
-
I think "shorter code" means less boilerplate and ceremony.
Also for example, lambdas/closures are shorter than Java’s way of anonymous class instances.
It doesn’t mean character count like in code golf.
In this sense, I agree that shorter code means less bugs. -
@Lensflare Code that does fewer things is simpler and usually better. Code that does the same or more things in fewer characters is terser which isn't universally better. This code doesn't do fewer things than the JavaScript version, it just executes the same operation in a less direct way. In fact, I'd argue that it does more things than the JavaScript equivalent without achieving more.
-
@Lensflare I'm also not sure what you mean about Java, since like Java 8 there are lambdas and even lexical scoping.
-
@lbfalvy yeah I’m not up to date with Java. But for a long time lambdas were missing and I just wanted to provide an example for code that is needlessly large.
-
@bigmonsterlover I'm not suggesting that JavaScript is better, but this is a false dichotomy; we could absolutely have a lazy pure language with a similarly powerful type system without disregarding readability.
-
I screwed up the English translation to Sequence; it applies a list of applicatives to a single value to produce a list of results. The JS version is correct so I was thinking of the right thing, I just failed to encode it in a natural language.
-
@bigmonsterlover OCaml isn't lazy and it lacks HKTs, two things I think Haskell does perfectly and should be more frequently replicated. There is a very elaborate hack to force HKTs into OCaml but it lacks higher-kinded static assertions, instead the validity of a type expression is evaluated upon instantiation. Rust is a brilliant language for a different problem domain entirely. I'm unfamiliar with the others.
HKTs in OCaml: https://cl.cam.ac.uk/~jdy22/papers/...
Related Rants
Is it just the novice in me that finds the Haskell community's misguided obsession over character count really annoying? Learn You a Haskell For Greater Good states
> Shorter code means less bugs
A lot of people and resources seem to share this opinion, but it's obviously false. Simpler code means less bugs, but look at this function which just means "apply this applicative to each element of a list"
> sequence :: (Applicative f) => [f a] -> f [a]
> sequence = foldr (liftA2 (:)) (pure [])
This isn't "less buggy", it's fucking madness. The same in JS, the king of unreadable languages, would be:
function sequence(seq, val, apply = (f, x) => f(x)) {
seq.map(f => apply(f, val))
}
Seriously, how can you design a strictly typed language that gets beaten by JS in readability?
rant
usability
character count
haskell
js