Moonside

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