runald

This usually bites me when it see a function that takes a parameter named angle. I usually have to read the docs or inline comment to know if it's in radians or degrees. At worst case, I have to go to read the implementation to figure it out.

I first learned the word suzerainty from the game Trails from zero, where Crossbell is a vassal state that is held suzerain by the two dominant states surrounding it, Erebonia and Calvard. I first thought it was a typo too.

When starting, yes it's easy to replace code, even with a shitty design. If it had to take more than ten hundred thousands lines of code to realize that the design is wrong, then it means the author lacks enough awareness or foresight to plan ahead, and no amount of planning will fix that. Code should be replaced/rewritten if the earliest signs faulty design show up, which should be trivial if the code was and remains "disposable".

Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.

I can't seem to find such videos, but regardless, how many videos are there? How many of those are actually just fabricated to attract views? I'm really skeptical if there's really a whole community of flat-earthers. There are people profiting from this flat earth drama. See the youtuber "professor dave" for example. He gets an average of <50K views, except his flat earth videos which got 1M to 8M views.

I don't have any numbers on this, but I'm certain lots of "flat-eathers" are just trolls that enjoys annoying people who tries to act smug and smart, but in actuality failed to get the humour behind the flatness of earth. Anyone who is seriously trying to argue with flat-earthers have a very low bar for intelligence. Which is not to say that there aren't actual dumb people who actually believe the earth is flat, but I reckon those people are far below the minority.

This is funny because a lot of the classics fit in that category, especially the ones that was dug after the author's death and was published despite the author's will. If what you say is true, then some lovers of classic literature are nothing but voyeuristic consumers.

I may be missing something, but how do you get this to work vscode? It couldn't find the type definitions. But other than that, deploying works just fine.

It seems to be good in theory, but I'm not really buying into any of the implementations of ECS, CGS or whatnot until they have a working, non-trivial example. If they have really thought it far enough, then they should have at least have a complex game as a solution to a general problem they are addressing. The demo in that repo you linked can be trivially implemented, CGS or no. Someone could rebut with: it's only a demonstration, but it's easy to scale any game of any size. In theory yes, but theory and practice aren't always friends. The actual complex game could serve as a proof, and the author can enumerate the pain points and limitations of the framework.

Wouldn't that take too long? Not really, just copy an actual released game, but using shitty (I mean, free) assets and make up some random content. It should cut the total development time from a week to a month at most. By copying, I mean everything, from the main menu, to in game-menu, to the little bits of logic that makes a game fun and engaging.

Weird as in it goes against well-established practices. If there are good, compelling reasons to disallow multi-line lambdas, other languages would have adopted it. But no, the opposite is happening, newer and recent languages actually have multi-line lambdas. Get this, even java adopted multi-line lambdas. Crazy right? What's wrong with everyone?

There's nothing wrong with having to name a function. But there is something wrong with not having a choice and being forced to name a multi-line function. Just as you don't want to name every sub-expressions, you don't want to name every blocks of code. Unnecessarily naming things pollutes the namespace.

Where's the strawman? The premise was that functions that spans more than a line should be given a name because they are "unreadable". I have showed that, by this logic, anything that spans more than a line is "unreadable". You can't make special exceptions and say this only applies to lambdas. Lambdas (aka higher-order functions) are blocks of code just as much as anything else.

Have you actually used other languages like clojure, haskell, kotlin, go or ruby? Python is the weird one here for not allowing multi-line lambdas. There are legitimate and actual useful cases for multi-line lambdas, disallowing them does more harm than good.

If the idea of multi-line alone compromises readability, then why even have multi-line blocks at all? Function, loop and conditional blocks should all at most have one line each. I hope you can see the absurdity of this.

Link to the github issue?

Here's all the possible code that are shown https://pastebin.com/YyQwU7XZ

Agreed, but this is only a problem is you are biting more than you can chew. You can either learn the unfamiliar words to increase the comprehension rate, or find a material that is more suitable to your comprehension level. Comprehensible input is for reinforcing and contextualizing the previously learned words.

For some people, being unemployed (even mostly) means living on the streets and eating scraps of food to get by, so I do not understand what you are trying to signal here when you say can still be generous and donate despite being mostly unemployed. Unless of course, you have a several years worth of savings or a stable source of food and shelter, in which case you being unemployed is irrelevant. I understand the desire and passion to help, but speaking of empathy, some people may have a very different idea of what unemployment means.

What's the difference between the ebook and the one free one in the website?

I'm far from being an academic, but if I were to make a less snarky interpretation, "not unreasonable" would be written if the reasonableness isn't binary, meaning that "not unreasonable" doesn't necessarily mean "reasonable", and that interchanging the two might lead to a less accurate, stronger statement. Alternatively, one would write "not unreasonable" as a way of contrast relative to something that was previously claimed to be "unreasonable".

I can think lots of other reasons, but feeling clever isn't one of them. I mean, if someone would like to feel clever, there's probably a more eloquent synonym for that.

By readable, I think you mean you get to read some whole words thereby get the impression of better readability, but in actuality it doesn't not necessarily aid comprehension if you don't know anything about taylor series, or maths in general.

I'm not saying more descriptive variable names doesn't help, but saying that you are not into mathematics makes your point moot.

I already use golang for work, and now I'm just doing a little toy project in nim. What I like most about nim is that it has generics, and produces binaries with small size. I'm creating a graphical program with a http server running in the background, and mixing asynchttp with UI threads is a bit of a pain in the posterior. Granted, I'm new to the language, I'm considering using channels, maybe that will make it easier to share state between threads. At least compared to golang, nim hasn't been a smooth experience yet when it comes to threads.

Anyways, I'm just voicing my personal gripe with the use of whitespace-sensitive syntax. Nim is a overall a good language to use.

Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.

If you are comparing reading code with reading books, then surely you have read books that have unfamiliar words that you have to lookup the definition, and then you might have to recursively lookup the unfamiliar words in the definition as well. Then when you internalized the sub-definitions, then you return to what you were reading and have a better understanding.

The difference between code and books is that programmers can freely and naturally define functions. I wonder if some people complaining about too many functions never actually learned how to read code in the first place.

No, I meant if you think helpers are anti-pattern that results into a spaghetti code, then you must also think that standard libraries are an anti-pattern mess. I don't think there's a standard library that doesn't have helpers, unless we don't agree on what a helper is?

What about the "helpers" found in the standard library? How do you feel about those things?

You don't need even a static generator really, even just

  cat header.html page1.html footer.html > build/page1.html

would work

Depends on how many times you repeat yourself. A dozen of times? Sure. A hundred times? I don't think so. You can write a program that programmatically replaces the footer and header, provided that the content and layout is properly separated. But at that point, you might as well just have a build tool, and have your content and layout decoupled in the first place.

Fair point, lots of people never actually go past ten or more blog posts. Still, even a simple build tool in bash works better.

If you had to tediously write it over and over in proofs, why can't just you give it a name or an abstraction?

↑ As you would do in programming.

This one will have a dot.

Edit: Seems to be true, but porpoise's comments is a clear counterexample.

This one will not have a dot.

I'm not a Swede, but if an random person that I don't know waves at me for no discernible reason, I too would be cautious. Although, it's not clear if you wave at everyone you see, or just at people you need to interact with (such as a store clerk).

It sure is easy moving the goalposts around when you have no grounds to base on. Please, please you have said this much and haven't still even once defined what true functional programming™ is?

> It's unfunctional by definition.

There you go, more self-fulfilling tautologies. And for some magical reason, it's me that are making nonsense claims? How is "higher-order functions make heavy use of closures" a nonsense claim?

I have provided a very clear and direct counter-example that falsifies your core argument. On the other hand, you have provided zero actual rebuttals. In case it isn't clear, calling mine "nonsense, circular and tautological" and yours "by definition" doesn't count as an argument.

> The pseudo-functional style is a preference for how to write programs, and therefore immediately defensible as valid

Is the word style even relevant here? You can call it style, paradigm, or computational model, it doesn't change your point.

> What's not defensible, though, is equivocating on the meaning of "function" while simultaneously trying to lump the pseudo-functional style in with FP.

Ugh, I'm guessing your definition of "function" is a special amorphous one that changes meaning to conveniently support your claims.

> The moment one starts making heavy use of closures and carrying around state is the moment one forfeits the right to be smug about how unclean OO is, given the equivalence of objects and closures and given that one is no longer actually practicing FP.

No, repeating your statements don't make them true. Once again, see my original counter-example with haskell. If you insist in ignoring it, then fine with me. I'm done here.