This is _so_ relative to the background of the people doing the glancing. These days [1, 2, 3, 4].map(x => x + 12).filter(x => x % 2 == 0) is obvious at first glance. Twenty years ago most people would have begged you to rewrite it with for loops.
Right now I am in a hell of trying to figure out if the Scala codebase I'm working on is terrible or if I am just not fluent enough yet with FP and cats and related libraries. There are some points of style I'm confident are poor choices, but when it comes to other aspects that seem horribly convoluted to me... I'm still not sure if the code is written for somebody with more experience in the style, or if it's a poorly executed example of the style.
I would prefer to have small functions named after what it is accomplishing and then have 2 function calls..
something like
list_of_grades = [1 , 2, 3 4]
adjusted_list_of_grades =
apply_end_of_semester_grade_adjustment(list_of_grades)
odd_grades = remove_even_grades(adjusted_list_of_grades)
(IMO)
This is very true. I am running a project at work using Elixir, in a software group that writes most of its code in C. I am curious to see how our style evolves as we become more intimately familiar with functional tools like chained iterators.
But definitely the point stands, the readability of code is often a function of experience and ability on both the reader and writer's sides.
I'm not sure about it, but I have certainly seen some overengineered code using reduce().
... in 6 months when you’ve forgotten 80% of the context.
Nobody writes code like the op though (I'm pretty sure it's satire)
In other cases, side projects with an emphasis on learning, coding for fun, practicing, or just doing something neat, the clever code can meet other subjective standards for "goodness".
I'm sure most people don't care, but that doesn't make it less true.
That said, the older I get, the more I appreciate obvious code...
I agree with you in spirt, but I would change "you" to "a new teammate" in the above sentence.
Jokes aside, there is something fascinating about programming languages being abused like this.
Like tongue twisters and word games, ain't these basically the same thing in a programming language instead of a spoken language?
I definitely didn't know about |> def
I suppose ruby has dynamic def as well though.
I guess riddles of obscurity are kinda like using overly esoteric words in conversation. Does that seem like the right parallel?
When I see something like the elixir with too many pipes, I think of Dr Seuss rhymes, but when I see obfuscated code, it's kinda like gibberish.
Challenge accepted. Here's how far I've got so far:
$l=[nil,nil,nil,nil]
TracePoint.trace(:call) do |tp|
$l << tp.self
$l.shift
end
class Lol < BasicObject
def initialize(f)
@f = f
end
def method_missing(m, *a)
# puts $l[0].inspect
$l[0].send(m, @f, *a)
end
end
class BasicObject
def ►(&blk)
::Lol.new(self).instance_exec(&blk)
end
end
module FooBar
def self.foo(a)
if a < 0
a.► { bar -1 }
else
a.► { bar 1 }
end
end
def self.bar(a, b)
(a*b).► { puts }
end
end
FooBar.foo(4) FooBar = Module.new
def FooBar.foo(a) a < 0 ? bar(a, -1) : bar(a, 1) end
def FooBar.bar(a, b) self.puts [a, b].reduce &:* endI find this part curious. How does Elixir know that a and foo aren't references/calls, before reaching def? Does Elixir work |> chains backwards?