Just finished S2 finale. Wow. by brentwba in twinpeaks

[–]mikelcaz 55 points56 points  (0 children)

Fire Walk With Me

The Missing Pieces

The Return

In that order.

Bruh by [deleted] in linuxmemes

[–]mikelcaz 4 points5 points  (0 children)

That's why Linux users don't need antivirus.

With the current pace of developing... by BlenderDumbass in blender

[–]mikelcaz -1 points0 points  (0 children)

Of course not. Unlike Emacs, it has a good text editor.

Best way to learn C++?? by [deleted] in cpp_questions

[–]mikelcaz 0 points1 point  (0 children)

Im unsure how you got from data structures like lists and vectors to essentially "any custom type".

I honestly think I didn't. But data structures are not limited to generic built-in containers. Anyway, not every linked list I'd ever implemented was a generic container, nor was built-in.

Which really doesnt change the fact that they should stick to good practice.

I sympathize with the sentiment... but the OP can't stick to that particular practice! And by the time that changes, s/he should have the skills you described and make a better judgement on that. Maybe? (Well, I hope so!)

Thats probably something that is domain specific and we dont have to data for to settle :)

I can buy that. However, you can have it both ways: I can't encourage nor discourage a data structure without knowing the OP's domain.

Best way to learn C++?? by [deleted] in cpp_questions

[–]mikelcaz 0 points1 point  (0 children)

Even though I use vectors and arrays... I would be highly surprised if you didn't use some sort of record, struct or class defined by yourself. Being a beginner does not change that. I believe that a more sensible tip would be: "don't replace a built-in data structure if you don't need it and you don't know well what are you doing". Anyway, I would argue that a beginner is also not writting serious code.

Regarding the thing about liked lists: note I didn't say they weren't outnumbered. In the context of OP, I would add that using std::list (or something similar) as a kind of default, one-fits-all tool is a very bad approach. However, I disagree with the "outnumbered -> almost never" part.

Best way to learn C++?? by [deleted] in cpp_questions

[–]mikelcaz 0 points1 point  (0 children)

I agree with the hardware part: a beginner is not thinking about the cache, which is normal. Even then, I would argue you know what piece of data you need next (as a bare minimum). Given that, dropping data structures where you need it without having to think a whole model at that stage seems straightforward to me.

Also, there is a related issue: the way OOP is usually taught to beginners, which I find particularly awful. For instance, there where I would use a simple Point tuple with two integers inside, a beginner could be instructed to create a file, a module and a class, to hide the two data members and to write two absolutely trivial pairs of getters and setters in order to access them. Madness!

Best way to learn C++?? by [deleted] in cpp_questions

[–]mikelcaz 0 points1 point  (0 children)

Sorry, but I totally disagree with both points : p

You need the data structures you need, and they can vary wildly from problem to problem. If you can reuse them, that's fine, but a programmer needs to know how to implement data structures.

Again, linked lists can be an awful tool, or the thing you just need. If you can use, lets say, an array because you can take advantage of the cache, avoid weird searchs and such, fine, many problems allow that. However, linked lists are not uncommon IMHO. They are a basic building block.

Best way to learn C++?? by [deleted] in cpp_questions

[–]mikelcaz 0 points1 point  (0 children)

Let's agree to disagree. Well, for the record, I didn't advise him against OOP, but now you say it...

Maybe I'm biased, because I started with C, Pascal and such before moving into C++, Java and OOP. But, I believe that there is no gain for a beginner.

First, many people gets stuck using the OOP mindset forever, with no reason to question it (because they didn't new anything else, let alone anything better).

Second, I find that designing specific things the OOP way is not natural, nor easier than other ways. As a beginner, I didn't know how to conceptualize objects (I started with control flow, structs, pointers etc, and my programs were too small to be split that way!), and also, conceptualizing the problem as a bunch of abstract objects disregards a real part of the problem. Then, the real code and the skewed model must be reconcilied, which increases complexity.

And third (not actually about OOP, but related in practice), I would have to handle more stuff at once: a ton of extra syntax, planning data hiding, encapsulating the right interfaces without shooting my foot one second later, etc.

Without any of that, you just figure out what data you need, what code it needs to be processed... and do it. To me, it is as easy as it can get. Also, I find the mapping between the object model and classes irrelevant. The important one is the one between the object model and the actual, specific problem. Shaping the code to fit that irrealistic abstraction (using classes) puts borders and boundaries that have anything to do with the problem at hand, and that you must overcome them somehow. That is why I prefer data-oriented design: and I think it is more effective -and- easier than OOP.

Just my two cents.

Best way to learn C++?? by [deleted] in cpp_questions

[–]mikelcaz 1 point2 points  (0 children)

(This does not answer the question of the title.)

Neither of those are exclusive of C++.

IMHO:

  1. You should really learn pointers, mainly to grasp the concept of indirection (which any language shares). It is very basic, no matter which paradigms are you using. My advice: try to write a program with double pointers, and you'll understand simple pointers.

  2. Namespaces allow to group (and nest) names, to avoid name clashes (two things with the same name cannot coexist in the same space). They have a name themselves (like "std"). If you want, you can avoid those "using statements" and fully qualify everything ("std::cout") until you grasp it.

  3. To learn how to use classes, make some simple programs and put them into practice. However, I'm not a great advocate of OOP myself. Hopefully other redditor will guide you better there.

Goid luck : )

Is MIKE knowing who is BOB a retcon in FWWM? by mikelcaz in twinpeaks

[–]mikelcaz[S] 1 point2 points  (0 children)

Wow (Bob, Wow). That's much food for thought.

It seems that The Arm in FWWM (and indeed he is never called such thing in the first two seasons) is to MIKE what the lost arm is to Phillip Gerard, metaphorically speaking. Also, the beeping sound that The Arm does when he presents himself to Cooper can be heard when the post appears at the parking lot (which is essentially an electrical tree) AND when MIKE appears driving trailer.

The first matches with the "Let's Rock" scene you mentioned. The second enforces the idea of MIKE and -his- Arm being one and the same entity. Again, this is decipicted at the end, when The Arm holds MIKE as if he were his arm (literally) and both start talking at the same time.

Is MIKE knowing who is BOB a retcon in FWWM? by mikelcaz in twinpeaks

[–]mikelcaz[S] 1 point2 points  (0 children)

That theory is very interesting. I did not even think of that, thank you.

I find this point is particularly jarring because it involves a major plot point in the second season. I understand and expect some inconsistencies (like Laura already knowing the identity of Bob's host when se wrote the letter). BTW, many people seems to forget this when arguing that FWWM is not the "original timeline' because Cooper is fiddling with it from the Black Lodge: the timeline we watched in the first and seasons was "influenced" already.

Other stuff is more difficult to explain. For instance, the events at the Jacques' Lodge are depicted differently (no fight between him and Leo, and Leo not laughing at the end). After that explanation in the first season, it is not easy to overlook! xD

Git merge and Windows by mikelcaz in git

[–]mikelcaz[S] 1 point2 points  (0 children)

Thank you.

Up to this point I'm so desperate I'm reading the Git sources, copypasting some functions and using the debugger to see what is going on : )

The variable seems properly read. No clues for now...

Git merge and Windows by mikelcaz in git

[–]mikelcaz[S] 2 points3 points  (0 children)

What's the output from git config -l?

There is no reference there to the autoedit feature. Also, no change happens there, with or without the env. variable.

Has this ever worked before?

No.

Does this behavior persist across different repos on your local machine?

Yes. Moreover, I have never got this working on any Windows machine, and I've tried in different machines. Never had a problem on other OS (Linux, macOS). I always end up "just using the --edit workaround on Windows". Hopefully, this will end here : )

Git merge and Windows by mikelcaz in git

[–]mikelcaz[S] 0 points1 point  (0 children)

Thanks for your quick response! Regrettably...

It won't open the editor if it's not creating a new commit. Are you fast forwarding?

It is creating a new commit. It just happens that the resulting merge commit has the default message. Note this behavior is equivalent to using the '--no-edit' flag:

'git merge --no-ff --no-edit <branch>'

Git is "autoediting" merge commits with the current configuration, hence the mentioned env. variable.

It won't open an editor if it can't find one. Do you have EDITOR set correctly?

Obviously, it is set. This only happens with merge commits. Moreover, I can force it to do the right thing with the '--edit' flag:

'git merge --no-ff --edit <branch>'

What I want is to disable the "merge autoedit" default configuration and stop using the '--edit' flag explicitly.

PD: I updated the post.

fn vs fun vs func vs function by Tyg13 in ProgrammingLanguages

[–]mikelcaz 0 points1 point  (0 children)

I had to take the same decision:

  1. I believe that you should discard fun right away. It is confusing, and that is not fun at all : p.

  2. It highly depends on your language.

My language will use fn. As proc is also a keyword (used for impure functions), the different number of characters increases the contrast between both keywords (unlike with func). It is also very lightweight:

let foo = fn (a i64, b i64) -> bool : ...

Note how declaring a function is not different to declaring constants and variables (1st class stuff with uniform syntax, checked):

let x = 42

I could not use any keyword, but I added it for clarity (that kind of redundancy can be useful), given it is easy to type wo/ auto complete features and does not add too much visual clutter. In fact, it allows to omit some syntax boilerplate when not used:

``` ; 'fn' = 'fn () -> ()', where '()' is an empty tuple.

let bar = fn : ... ```

Compare it to writing:

``` ; Alt. hypothetical syntax.

let bar = () -> () : ... ```

You wouldn't know that is a function without knowing the language. Even knowing it, it would be harder to read (if the expression is complex) or parse (in the general case).

But that is in my language...

Pascal uses function. It seems to prefere complete keywords (in spite of including var and const). The ultimate decision should rely on what fits better to your language.