☆ Yσɠƚԋσʂ ☆LISP is ugly
vettnerkI raise you this:
imgs.xkcd.com/comics/lisp_cycles.png
bdonvrDirectly linking the file of an XKCD should be illegal
I’ll let Randall Munroe decide that himself, considering the fact that he peovides URLs for hotlinking below the comics
I don’t mean the act of embedding or direct linking in general, but in link aggregators these comics are well known for their alt text, which cannot be seen from the direct link.
I think a good practice might be embedding the comic directly in your comment along with a “source” link.
McSinyxthese comics are well known for their alt text
It’s title text, or in web comic circles, hover text. The linked comic’s alt is simply Lisp Cycles.
SnipingNinjaIt’s actually this:
Lisp Cycles: I’ve just received word that the Emperor has dissolved the MIT computer science program permanently.
FedoraLinking to images should be illegal
I learned Lisp at uni and hated it. Thankfully that was long enough ago that I’ve forgotten everything I learned about it.
davelI’m sorry to hear you learned nothing.
addieYeah - pure functions and immutable data aren’t always the right answer, but appreciating that they’re damn good most of the time is a good first step. Writing obvious code that does exactly what it appears to do at first glance and not one thing more? Your colleagues will thank you when they have to work with your stuff.
And metaprogramming and tail call optimization and and…. At least other languages are starting to catch up with this 60 year old language, by for instance implementing lambda expressions.
HumanBehaviorByBjork [any, undecided]are there any JS fans who argue that it’s elegant? i thought the supposed advantage was that it’s flexible and universal.
Well, universal, anyway.
Weirdly, I’ve seen plenty of people who appear to genuinely like Js and Ts.
🔻Sleepless One🔻It’s a stockholm syndrome kind of thing.
Well my Js isn’t looking like that and it is really easy not too. But bad people write bad code.
jevans ⁂I know it’s not nearly as nested as this, but nesting in Rust annoys the hell out of me.
impl { fn { for { match { case => { } } } } }is something I’ve run into a few times
darcythe loop or match statement could possibly be extracted to another function, depending on the situation. rustc will most likely inline it so its zero cost
Just use this syntax
let myResultObject = getResult() let item = match myResultObject { Ok(item) => item, Err(error) => { return } };
How does that change anything? Sorry if it wasn’t clear, this was assuming a function call in the for loop that returns either a Result or enum.
Oh sorry, I misread what you typed and went on a tangent and just idly typed that in.
One thing you could do for your situation if you’re planning on iterating over some array or vector of items is to use the inbuilt iterators and the chaining syntax. It could look like this
let output_array = array.into_iter() .map(|single_item| { // match here if you want to handle exceptions }) .collect();The collect also only collects results that are Ok(()) leaving you to match errors specifically within the map.
This chaining syntax also allows you to write code that transverses downwards as you perform each operation, rather than transversing to the right via indentation.
It’s not perfect and sometimes it’s felt a bit confusing to know exactly what’s happening at each stage, particularly if you’re trying to debug with something mid way through a chain, but it’s prettier than having say 10 levels of nesting due to iterators, matching results, matching options, ect.
I definitely use that syntax whenever I can. One of the situations where I get stuck with the nested syntax that I shared is when the result of the function call in the for loop affects the inputs for that function call for the next item in the loop. Another is when I am using a heuristic to sort the iterator that I’m looping over such that most of the time I can break from the loop early, which is helpful if the function in the loop is heavy.
It feels like maybe this could be a code structure issue, but within your example what about something like this?
fn main(){ let mut counter = 0; let output_array = array.into_iter() .map(|single_item| { // breaks the map if the array when trying to access an item past 5 if single_item > 5 { break; } }) .collect() .map(|single_item| { // increment a variable outside of this scope that’s mutable that can be changed by the previous run counter += 1; single_item.function(counter); }) .collect(); }
Does that kinda syntax work for your workflow? Maybe it’ll require you to either pollute a single map (or similar) with a bunch of checks that you can use to trigger a break though.
Most of the time I’ve been able to find ways to re-write them in this syntax, but I also think that rusts borrowing system although fantastic for confidence in your code makes refactoring an absolute nightmare so often it’s too much of a hassle to rewrite my code with a better syntax.
Thanks for this! I’ll see if I can work something like this in.
Back when I was still in school, I ran a few tests on real world LISP and Java (the then dominant language, this was in the late days of Sun Microsystems succes).
Turns out most LISP programs had fewer parentheses then Java had braces, parens and brackets.
Java follows the paradigm of boilerplate oriented programming.
If your code looks like this, you seriously need to reconsider your code