replicat

I'm new to Fish and really liking it so far but the list type is really confusing me.

Something that I find really non-intuitive about fish is the list data type.

You can set a list like this

set my_list a b c
echo my_list[1] #a

But if you try this it doesnt work:

function mklist
  echo a b c
end
set lst (mklist)
echo $lst[1] # a b c

Putting the echo in quotes doesnt work either.

You can do:

function mklist
    echo a b c
end
set lst (string split " " -- (mklist))
echo $lst[1] # a

But needing to always split your return values is kinda terrible.

So it seems like what fish expects you to do is echo multiple lines.

function mklist
    echo a
    echo b 
    echo c
end
set lst (mklist)
echo $lst[1] # a

Its just very weird to me that it doesnt understand a comma delimited string to be a list.

I feel like I must be missing something.

Edit: FWIW I think I get why they designed it like this after thinking some more. It just feels weird.

This requires you to be explicit about returning lists. Otherwise any echo with spaces would be treated as a list and not a single value

I haven't freelanced since the Craigslist / Fiverr days but I'm looking to get back in the game.

Figured this question might be helpful to others as well.

In this post, I hope to clarify and expand on some of the points and rebut some of the counter-messaging that we have witnessed.

A tile-based visual programming game where players solve boolean logic puzzles.

I am self-promoting here. I made this game.

In my decade-plus of maintaining my dotfiles, I’ve written a lot of little shell scripts. Here’s a big list of my personal favorites.

• Evan Hahn

The ghosts of ancient Hackers past still roam the machines and—through the culture they established—our minds. Their legacy of the forging of craft lingers. A deep and kinetic craft we’ve extended and built a passionate industry on. We are driven by the same wonder, sense of achievement, and elegance of puzzle-solving as they were. Still driven by “The Right Thing.” These constitutional ideas, the very identity of programmers, are increasingly imperiled. Under threat. The future of programming, once so bright and apparent, is now cloaked in foreboding darkness, grifts, and uncertainty.