Moonside

Moonside OP wrote

Reply to comment by neku in The perennial question of podcasting: which ones do you like? by Moonside

giving a list of every podcast i listen to makes me feel strangely vulnerable like "heres all my dumb interests and my justifications for them"?? anyway Enjoy

Personally I unsubscribed from a few just because having the need to sort the wheat from the chaff made some podcasts appear lower in my esteem. The biggest problem being that they were too Terminally Online: people from Twitter discussing outrage they learnt about from Twitter. Like discussing the Szechuan sauce debacle as a great moral digressions or James Damore - in other words, issues that were discussed into the death in a few days.

1

Moonside OP wrote

Reply to The perennial question of podcasting: which ones do you like? by Moonside

There's some overlap in the ones I listen to with the ones already mentioned

Fan podcasts

The Steven Universe Podcast is produced by the CN itself and hosted by a fan. Story boarders, producers and VAs get feature quite a bit and it's nice to hear them shoot shit in a pretty relaxed setting.

Everything's Coming Up Springfield consists of its hosts discussing a Simpsons episode with a guest for about an hour, but the discussions have a tendency to enthusiastically follow through all sorts of diversions. I think the earlier episodes are the best and the first episode with Alex Hirsch on Bart's Comet is one of the best so give that a try at first. Later on the show starts losing its steam as the most memorable episodes have already been picked.

Infotainment and education

I'm going to be honest - I find both books and video to be way superior content delivery formats to podcasting for any kind of learning, so the more a thinky podcast strays away from current affairs, journalism, interviews or discussion a podcast goes towards didactic stuff, the less enthusiastic I get since I could be just working on my desk taking notes. Never-the-less, two shows I listen to are so well done that even with my misgivings I like to recommend them.

History of Philosophy Without Any Gaps by Peter Adamson and History of Philosophy in India, by him and Jonardon Ganeri. Each episode is about 20 minutes long except for the interview ones that tend to be bit over half an hour long. I think this is roughly as good as has been done in the medium so far and perhaps as can be.

Miscellaneous podcasts

black fellas podcast (or is it African Dissent?) - an international tag team discusses various things from politics to dating as black people. Hasn't updated in a while and has only 7 episodes so far which means you can listen to them all and get it done, a thing I consider a positive.

My Worst Own Enemy is a somewhat rare beast, a mental health podcast. It's mostly not that self help orientated (which is good since I hate that kind of shit with passion) and mostly interviews scholars and practitioners in the field.

I tried to give a listen to The Adventure Zone and honestly I just couldn't pay attention to it enough or something. I usually listen while I'm on a walk but apparently the environment and its noises bring enough disruptions that I couldn't concentrate on the narrative. I've had similar troubles with audio books, which is a format I just can't digest at all. I stopped around the part after the murder mystery arc, but if you don't share my symptoms, go ahead! The first one in which they created their characters was fun, so it's not a thing you need to follow for 20 hours to get the first pay off.

1

Moonside wrote

Reply to Sherlock Hound by voxpoplar

This intro has a better female led "badass" action scene than what Hollywood can typically muster (and it's not even her show) and that scene with tons of cops must have taken 80% of the episode budget. And the intro is telling a proper story that start in media res, something that's so uncommon in fiction for children.

All I'm saying is that this intro truly is in the top tier of intros.

2

Moonside wrote

Reply to comment by devtesla in attn: moonside by hollyhoppet

Like I said in my other message, there was probably a mix up with Earthbound Brands being made, but the rights of the Mother series are a little bit more complicated than most Nintendo franchises given that Shigesato Itoi owns (at least some of) them. Like the Ness amiibo credits copyright to both Nintendo and Itoi, which makes me wonder if Itoi could in principle do something like this alone? But this particular case is false news, probably.

3

Moonside OP wrote

Reply to comment by neku in This is best programming comment of all time on Reddit by Moonside

Go lacks facilities for generic programming so you can't write in a sensible manner a function that operates on many different datatypes. This means you either need to write almost identical routines over and over or lose useful safety guarantees.

For example, consider a list containing strings ["lol", "lmao", "nada"] (a value of type List String) and a list containing integers [1, 2, 3] (a value of type List Integer). You wish to write two functions:

  1. length which returns the number of elements list contains.
  2. head which returns the first element of a list.

If your language supports generic programming, you can just write functions length and head that work on lists containing any type of values. But since Go doesn't, if you want to have certain safety guarantees, you need to write a version of these functions for each type. In this case, you need to implement lengthString, lengthInteger, headString and headInteger. The comment author does this kind of a process by hand from a single "master" source code file to keep himself sane, but the way he uses those Canadian Aborigine Syllabics makes it look as if Go supported generic programming.

The loss of safety guarantees (if you don't wish to implement essentially same routines n times) comes from that you can mix elements of different types together in code which fails at run time and comes crashing down. In generic programming, you can guarantee that routine outputs a value of type t if the input value was a list of values of type t, or concisely, the routine's type is List t -> t. (Your compiler can verify that your implementation abides by this rule, which is known as type safety in general.) As an another example, I can tell at a glance that a routine of type List t -> List t may

  1. drop elements from the input list,
  2. repeat some elements of the input list and
  3. rearrange elements of the input list

but can't do anything else. But if the type was List Integer -> List Integer I couldn't guarantee any of these properties. In fact a function I wrote, no matter what the parameter list is, could return the value [69] and the compiler would still say nice. Go is even worse, since the other option is interpreting all values of being the most general one, Object (or something like that). You can't even know that it's a list of Integers anymore, it could be a weird mix and you'll only know for sure when you program crashes.

Actually you can take the above reasoning even further. Suppose you have a routine of type String -> String. What can you say about it just based on its type? Hardly anything since all computation is essentially just transforming sequences of symbols into other sequences of symbols. There are as many implementations that pass the type checking as there are possible programs. But if you generalize the type into a -> a I can deduce what the routine does since there is only one possible implementation: take a parameter, do nothing with it and return it as the output. So using generics reduces code duplication, increases software safety and correctness and further helps reason about programs.

Soz that this was so long, but following Mark Twain, I just didn't have time to write anything shorter.

3

Moonside wrote

Reply to comment by twovests in I'm doing a big programming group project with four other undergrads by twovests

Now I can finally put my Undertale knowledge into use: she was a lot like Alphys good ending run (except Alphys was actually supercompetent in-story unlike the present person I'm talking about). Some problems:

  1. Stops communicating when she had problems
  2. the general lack of guts to just try out things
  3. All or nothing thinking when it came to implementation. I think that coders mostly implement one thing at a time, see if it works/compiles/passes the test and move on to the next thing and learn from the experience and apply it to further cases. This was totally absent. I think she tried to figure it out all in her head and if she felt any uncertainty, she just didn't try to code.
  4. Didn't habitually compile/test/see whether software worked and fix problems or annotate them if unfixed.
  5. Couldn't read official documentation Java had.

Honestly I'd say it was mostly a series of emotional issues more than anything else. You can't learn coding if you fear compiler/test feedback and trying out things and fall apart when things don't work.

2

Moonside wrote

Reply to I'm doing a big programming group project with four other undergrads by twovests

Could you convince them that writing documentation is a nice way to procrastinate and makes the implementation part easier? I swear I solved an implementation problem (which caused no small amount of headscratching) recently just by carefully specifying the function to be implemented. By doing that I ended up describing the cases correctly which then made the implementation trivial. It was a recursive function so a botched case analysis easily leads to incomprehensible behavior.

source control, etc. as fluff, nice to have, non-productive, etc.

¡Dios mío! I'm glad that I've used source control for very low importance projects so that I can use it without any real effort when it's needed.

The crappy part of programming really is that there are so many useful tools that you have to bring together and tinker with to make them good. Like to write good unit tests you presumably ought to be specifying your functionality in good enough detail, your testing framework presumably has a few knobs to be set, then you have to make testing and documentation work with your build system, for Git you need a .gitignore file and so on, all this upfront work and busy work that makes it all easy to skirt.

3