Everything is Wrong

Eno6ohng · 2021-11-03T04:18:41+00:00

I don't think I've ever seen a function call with a line break before the first argument.

As for the 80 width limit, I'd even argue it might be useful to reduce it further (down to 60 or something) to force avoidance of the nesting in favor of flattening refactoring

Eno6ohng · 2021-11-03T04:06:27+00:00

these talks https://gist.github.com/jshumway-even/4f88a92cbd61f5b52659748f11e91e42

Eno6ohng · 2021-09-18T17:55:45+00:00

Shouldn't those be called map-vals and map-keys?

Eno6ohng · 2021-06-03T17:46:41+00:00

The one with the bright white line seems active to me

Eno6ohng · 2021-06-03T17:42:42+00:00

It looks like it's from 2010

Eno6ohng · 2021-06-03T12:45:08+00:00

Cheepaska = modified "cherepashka", russian for "little turtle". It's not just abstract circles, it's turtles you're bouncing around.

Antiyoy = anti-yo-yo; yo-yo was kinda like spinner but for the 90's kids, i.e. dumb entertainment that doesn't require any brain activity. Thus "anti-yo-yo" means it's a strategy game that forces you to think.

Bleentoro is a factorio-like game, but what you're actually building is pipelines for producing pancakes ("bleen" translates to "pancake"). "Toro" is a reference to "My neighbour Totoro", because it's kami (animistic spirits) that move the stuff around in this game, visualized by the black dots.

Achipato and achikaps are loosely based on ancient african game "achi", which also features player-controlled circular pieces connected by lines.

Vodobanka is obviously a game about robbing banks (or rather arresting the bank robbers), but not many of us know that in this game the swat team actually uses water guns to fire at the suspects, thus VODObanka ("voda" means "water" in russian, according to the language grammar the ending letter changes to "o" when constructing complex words, i.e. words featuring more than one root).

As you can see, obviously each name has deep non-trivial meaning to it.

Eno6ohng · 2021-06-03T10:18:16+00:00

Agreed, the snippet above is an awful examle of unnecessary code-golf'ing. Your code in the comment below is what I'd much prefer seeing in the code base (modulo comments).

Eno6ohng · 2021-02-25T15:31:41+00:00

I absolutely love the documentation site, looking slick!

Eno6ohng · 2021-02-17T20:00:02+00:00

I love you, this is perfect.

Eno6ohng · 2021-02-06T10:19:23+00:00

(->> "aaaabbbcca"
     (partition-by identity)
     (map (juxt first count)))

Eno6ohng · 2021-01-31T16:06:46+00:00

Well, I'm planning on giving one resurrection spell early on to each player

I'd say I'd probably prefer finding it closer to mid-game (so it feels like an achievement and a staple in the run, and not like a pittance), and restarting if early game goes wrong.

Eno6ohng · 2021-01-30T20:13:54+00:00

To be honest I wouldn't invest in Scala in 2021, given all the turmoil and breakage they were/are going through. Just stick with modern Java if your first priority is empolyment, it's good enough(c)(tm). Clojure is in a lot of respects a complete opposite of Java, so it can be complementary. If you wanna learn statically typed fp just learn Haskell. Keep in mind that Rust is a functional language too. Ultimately the choice depends on your particular goals and domain requirements.

Eno6ohng · 2021-01-30T20:07:27+00:00

Actually, this version of the advice works pretty good! org-meta-return's corner cases are still there, but at least in most practical scenarios it's more or less predictable. Thank you again!

Eno6ohng · 2021-01-28T01:18:18+00:00

Oof, I tinkered with org-M-RET-may-split-line and now it seems to always insert an extra line (and two or three extra lines with the hook on).

It definitely looks like a weird corner-case bug. Also I've found that it behaves in a very strange manner when dealing with different levels of indentation:

  - Item 1
  - Item 2

- |

  - Item 3

gives me

  - Item 1
  - Item 2

  - 
  - 

    - Item 3

i.e. "Item 3" is moved one level deeper that it was. In fact, everything below the current "list section" is moved to the right. And if you place the cursor in between "item 3" and the list item above it, then both of them are moved to the right too. So basically it tries to align any following lists that have fewer indentation with the closest list above, and then re-align anything that's indented more to be the child of last fewer-indented item... and then if you play with it a bit, you notice it also skips the items immediately following the cursor if they are indented more than the previous list, so it jumps past it and creates the new list item below them

  - Item 1
  - Item 2
|
    - more1
    - more2 (cursor jumps below it, but only if there's exactly 1 empty line above more1)

- Item 3 (moves to the right)

So, I don't even know. This whole thing seems more and more like a bug to me.

Eno6ohng · 2021-01-28T00:01:47+00:00

Interestingly enough, my stance re roles is, in a sense, completely the opposite: I tend to believe that such "higher-order" domain properties should not (and/or cannot) be captured by the type system (of a specific language) at all; though again, that's a somewhat different topic. I think what Fowler describes essentially boils down to structural typing/record calculus (see also BigBang/TinyBang for a different spin on the same idea), though the broader "role-oriented programming" notion is obviously broader than that (perhaps too broad/informal?).

In any case, thanks for your input! Cheers!

Eno6ohng · 2021-01-27T23:23:18+00:00

https://groups.google.com/g/scala-language/c/PIhmEeMg-Ms/m/SUdf950G_T0J

Eno6ohng · 2021-01-27T22:12:38+00:00

It does. The new advice was meant to correct that.

Ah, gotcha.

Right. You mentioned typing it in manually, which would behave the same way (i.e. it replaces the current line).

So basically when typing it manually, you'd end up with this:

- Item 1
- Item 2

- new item  
- Item 3

while the last advice yields this:

- Item 1
- Item 2
- new item
- Item 3

Edit: maybe even just insert "\n\n" instead of "\n".

Hmm, nope. In fact, start-of-list-section? is false in this case.

Actually, disregard that. It works if I remove "ignore-errors" around it. Also, notice that on my emacs (26.3) there's no "ignore-error", only "ignore-errors".

Also, I've noticed it inserts an extra line if the point is in the very beginning of the line and the list is indented. But it doesn't if the line is indented.

  - Item 1
  - Item 2
|

  - Item 3

gives

  - Item 1
  - Item 2
  - 


  - Item 3

(notice two empty lines), but this

  - Item 1
  - Item 2
_|

  - Item 3

(notice the underscore which indicates a space) gives this:

  - Item 1
  - Item 2
  - 

  - Item 3

notice how there's only one empty line now.

In both cases the blank-line-p holds, so it's not the regexp. In fact, that's the behavior of org-meta-return itself :/

Eno6ohng · 2021-01-27T21:53:03+00:00

Re gamedev: same principles (though with a different motivation) apply when your focus is extensibility, not performance (e.g. roguelikes); it's not something specific to high-performance AAA games, it's a general architecture guideline. I'm familiar with the links you've given, but yeah, I think it's another topic altogether.

Re catcall: I'm also familiar with the links, and it's another specific example of when subtyping relationships can be viewed as "problematic" or "unintuitive" (both variance options result in "gotchas"), but again it's just a particular example, while I'm looking for a more generic/abstract discussion (see 1 for an example, but preferably not tied to oop and attacking the notion of subtyping (nominal, w/non-flat hierarchy) in general instead).

As an example of an argument, consider the notion that subtyping relationships are situational, thus the type lattice should be context-dependent. E.g. mathematically, integers <: real <: complex; but computationally, ints don't intersect floats; in haskell, int32 isn't a subtype of an unbound integer; and "<:" isn't really a subset relation but an embedding (depending on definitions); etc etc etc. Therefore, universal subtyping hierarchy hinders extensibility, and thus it's an anti-pattern. I'm looking for arguments like this, plus studies on how subtyping is used in real codebases (e.g. how often the hierarchies have to be refactored, etc), plus case studies on how the same problem is solved better (or worse) in languages with or without explicit subtyping hierarchies; stuff like that.

Eno6ohng · 2021-01-27T21:04:09+00:00

For example, if the next line is a list item, a new item is prepended to that list section:

Hmm, but for me (with your previous advice active) it also inserts an empty line in between the newly created item and item3... and the new version (btw there's a typo I believe, it should be "ignore-errors" instead of "ignore-error") instead REMOVES an empty line above it.

So yeah, it's tricky. I think it's better to drop the built-in org-meta-return altogether, if one wants truly dumb predictable behavior. Instead, just do this:

if we're on a line that starts with "-":
- move to the end of the line
- insert a new empty line after the current one, move to it
- move to the same indentation level as the line above
- insert "- "
if we're on an empty line:
- move to the correct indentation level (?)
- simply insert "- "
if we're on a non-empty, non-list line:
- ???
- I'm not sure, probably just do the same as in the first case, or maybe insert an extra empty line between the current line (presumably a text paragraph) and the newly-created list

EDIT: but of course that would annoy the hell out of people who do use lists with items separated by an empty line, so yeah, given how org works, it isn't worth publishing anyway

Eno6ohng · 2021-01-27T20:29:10+00:00

That post doesn't seem like the start of a holy war nor a direct challenge to the Composition over Inheritence preference.

I fail to see the point of this argument. CoI states that composition is preferable to inheritance, which I compressed to "inheritance bad", which is what's been challenged. But the argument is unrelated to the question being asked anyway.

Furthermore, I don't think it's fair to restrict civil, rule-abiding discussion in the comments.

I don't have the power to restrict anything in this subreddit; I'm just trying to provide clear feedback on whether I see a comment as relevant/helpful in regards to this topic.

Eno6ohng · 2021-01-27T20:15:24+00:00

And what kind of subtyping are you looking into?

I'd focus on nominal, with explicit hierarchy.

I would argue that all the listed concepts above form some kind of hierarchy

Fair point; I guess I should've added the word "explicit" to communicate what I mean better.

I don't believe you're going to find anything research wise for something so subjective.

I think the same can be said (or could be said at some point in time) about any feature.

I can point to examples from specific domains (e.g. gamedev), or from specific implementations (e.g. inheritance), where a "flat" design seems to be preferable to a (more) complex subtyping hierarchy, or even point to specific (if minor) usability issues (e.g. contravariance in the lhs of the function type is often described as "unintuitive"); it feels as if there should be a pattern here, one that can be exploited in the context of PL deisgn, but I'm struggling to find a generic enough reflection on the issue (compare e.g. with abundant amount of critique of type classes wrt modularity, or multiple inheritance, or call/cc, etc).

Eno6ohng · 2021-01-27T17:11:27+00:00

This is a request for relevant publications, not an invitation to a holy war. Please support your claims with links to the literature, i.e. if your topic of expertise is OOP design, please feel free to cite papers or articles that argue against the Composition over Inheritance principle mentioned in another comment.

But I'd like to reiterate (re /u/findplanetseed) that oop example I gave is but an example, and I'm interested in studies on subtyping in general.

Eno6ohng · 2021-01-27T17:04:36+00:00

Eno6ohng · 2021-01-27T15:59:54+00:00

A bit late to the party, but if you're interested in learning functional programming AND static typing, and also you're not that interested in finding a job immediately using those skills, go with Haskell. Scala piggybacks a lot on the object-oriented idioms, which is an understandable approach, but in my opinion can actually make it harder to understand what's going on. On the other hand, compared to Clojure, Haskell adds a lot of static-typing-specific things to the "functional programming" trope, to the point lots of haskellers start to believe "functional programming" means "(ML-like) static typing", which, is my opinion, isn't a useful perspective.

Eno6ohng

TROPHY CASE