Post A0dB7YOxqfa1cbF3uC by self@mastodon.linuxlusers.com
 (DIR) More posts by self@mastodon.linuxlusers.com
 (DIR) Post #A0dB7HBDsVUGD3gLcu by self@mastodon.linuxlusers.com
       2020-10-28T18:29:45Z
       
       1 likes, 0 repeats
       
       I'm kicking around this idea that, when learning a new programming language, it is more helpful to start with examples of things that one should *not* do, rather than what one *should* do.My logic here is that the things you *can* do in a language are effectively infinite, however what you *can't* (or shouldn't) do is a very finite and relatively manageable number.Obviously at some point you learn how to do things correctly, but I'm curious if this method lessens the initial pre-grok haze.
       
 (DIR) Post #A0dB7Pb2aOtOJRp4ym by self@mastodon.linuxlusers.com
       2020-10-28T18:30:29Z
       
       0 likes, 0 repeats
       
       Does this seem logical? Would love some feedback from my fedi friends with more programming experience (virtually all of you ha).
       
 (DIR) Post #A0dB7SQA5IyN4ZkvwG by ScumbagDog@social.linux.pizza
       2020-10-28T18:35:54Z
       
       0 likes, 0 repeats
       
       @selfHow are you supposed to know that a given concept is bad (or rather, how it is bad), if you have no better case/concept to compare it to? I think showing bad practices to weed them out early does make sense, but the learner needs to understand the basic concepts and good practices first, in order to reflect on why a bad practice is considered bad.
       
 (DIR) Post #A0dB7YOxqfa1cbF3uC by self@mastodon.linuxlusers.com
       2020-10-28T18:38:53Z
       
       0 likes, 0 repeats
       
       @ScumbagDog For example, watching a video like this: https://www.youtube.com/watch?v=j0_u26Vpb4wIt not only shows you bad patterns (some obvious and universal) but it also helps you grok why things aren't done a certain way. I always hate the feeling I get learning something new and I'm just repeating a pattern because "it's just done that way". You obviously can't understand the entire history of every convention and pattern when you're new, and that blind following of things is what I'm trying to minimize.
       
 (DIR) Post #A0dB7dMfOdiH0vCnWC by ScumbagDog@social.linux.pizza
       2020-10-28T18:52:31Z
       
       0 likes, 0 repeats
       
       @selfThat video also assumes that you know the basics of c/c++. Don't get me wrong, I think the concept of looking at bad code is a great way to deepen your knowledge in the given language, but an absolute novice (at least within the paradigm) would look like a question mark once you start throwing a little terminology around.For example, you have no chance at knowing why gotos are bad unless you know what control structures such as if and while are.
       
 (DIR) Post #A0dB7gd5G3cz8huS1Y by self@mastodon.linuxlusers.com
       2020-10-28T19:14:31Z
       
       0 likes, 0 repeats
       
       @ScumbagDog I agree with everything you said, but I am assuming this is a person's N+1 language being learned - so general concepts would already be grok'd. Do you thing that makes a significant difference? I'm also dyslexic, so I always have a hard time learning anything new at all, and I tend to not learn well with traditional methods that work for most people. So what works for me here may not be anything close universal, ha
       
 (DIR) Post #A0dB7nWbcXbaWdvsOm by ScumbagDog@social.linux.pizza
       2020-10-28T19:35:47Z
       
       0 likes, 0 repeats
       
       @selfI don't think number of languages known matter - paradigms do. A Haskell and C program are two very different beasts to master, and knowing the practices of one, does not imply knowing the practices of the other. Compare that to a Haskell and Lisp program or C and Pascal program, and the similarities are much more pronounced (but not the same, of course)
       
 (DIR) Post #A0dB7sNvYEdNbAuW48 by cy@fedicy.allowed.org
       2020-10-28T20:01:01.617287Z
       
       0 likes, 0 repeats
       
       @ScumbagDog @self Haskell is a declarative language, which in my experience is dramatically different from an imperative language. In Haskell, you tell the computer what the situation is then say “So, uh, go solve that somehow okay?” whereas in C, Lisp, or Pascal you tell the computer what to do to solve it. So Haskell, Caml, certain pattern matching mini-languages, Sympy, those are what I see as similar.Though certain C optimizations can be seen as declarative, like where you tell it for(i=0;i<4;++i) and the computer goes to solve the problem “somehow”, either with a loop or an unrolled loop depending. So there are even similarities between C and Haskell. Ultimately they all boil down to a sequence (or sequences) of machine code instructions being fed to a CPU core.