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
-
With idiomatic LISP, the issue is that people usually take its name too literally. Every shit is shoved into lists, and you never know whether you have a tuple or a list or even code.
With idiomatic C, you'd have a tuple in a struct, a list in an array, and you'd (usually) not hand over executable code at all.
That's another thing with LISP, self modifying code. It's how people thought AI would be like. Turned out it wasn't - all that came out of that was an unmaintainable mess.
Oh and that you can redefine the whole language in LISP is also a weakness and not a strength because it means that every fucking project is de facto in another language. The only kind of devs who like that is people working on one-off stuff that nobody will ever touch again after them. -
The only thing I like about implicit returns is that it shortens already tiny functions by a little bit.
Used outside of that niche it just irritates or infuriates me. Especially when there are implicit returns at multiple indent levels throughout the function. That practice should burn along with its practitioners.
Related Rants
The more you look, the worse it gets
My Gripe With Implicit Returns
In my experience I've found that wherever possible code should be WYSIWYG in terms of the effects per statement. Intent and the effects thereof should always be explicit per statement, not implicit, otherwise effects not intended will eventually slip in, and be missed.
It's hard to catch, and fix the effects of a statement intent where the statement in question is *implicit* because the effect is a *byproduct* of another statement.
Worse still, this sort of design encourages 'pyramid coding recursion hell', where some users will first decompose their program into respective scopes, and then return and compose them..atomically as possible, meaning execution flow becomes distorted, run time state becomes dependent not on obvious plain-at-sight code, but on the run time state itself. This I've found is a symptom of people who have spent too much time with LISP or other eye-stabbingly fucky abominations. Finally implicit returns encourage a form of thinking where programmers attempt to write code that 'just works' without thinking about how it *looks* or reads. The problem with opaque-programming is that while it may or may not be effortless, much more time is spent in reading, debugging, understanding, and maintaining code than is spent writing it--which is obviously problematic if we have a bunch of invisible returns everywhere, which requires new developers reading it to stop each and every time to decide whether to mentally 'insert' a return statement.
This really isn't a rant, as much as an old bitter gripe from the guy that got stuck with the job of debugging. And admittedly I've admired lisp from afar, but I didn't want to catch the "everything is functional, DOWN WITH THE STATE" fever, I'm no radical.
Just god damn, think of the future programmer who may have to read your code eventually.
devrant
scripting
ruby