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.

Does this seem logical? Would love some feedback from my fedi friends with more programming experience (virtually all of you ha).

Show thread

I've really been considering diving in deeper on C or C++, and that's what spurred this.

I've programmed in Python/PHP and of course hacked around with some shell scripting for at least 20+ years now.

I started my programming adventures with a C++ book as a kid and dabbled in C for microprocessors later... but I've never really wrapped my head fully around those two languages and it's kind of embarrassing.

There's just so much stuff written in those languages that I'd like to contribute too.

Show thread

How 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.

@ScumbagDog For example, watching a video like this:

It 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.

@ScumbagDog I don't know if that video was the best example, but I just grabbed it quickly. Hopefully the idea comes across ha.

That 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.

Or alternatively thr example with macro v function. There is no guarantee that a novice knows what a preprocessor directive is, so showing why a #define might sometimes yield unexpected result may just end up confusing them, rather than giving them that "eureka!" moment

@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

I 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)

@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.

My point is that they both share concepts (not fully, just some) that a C programmer would likely not know. Sure, Lisp and its dialects are procedural and Haskell is declarative, but if you know one, you likely also know what lambdas, declarations and tail-recursion is, which is present in the other. For a pure C programmer, these would be foreign concepts.

@self Also consider Rust. I started with C spent much of my career (and hobbytime) writing C++ and recently began learning Rust. Nothing wrong with C/C++ if those are the languages you want to use, but Rust is I think a decent advance and already has lots of amazing projects you can contribute to.

@happybeing 100%, Rust is the most exciting new language I'm aware of! The C/C++ thing isn't a practical decision, but rather just something to make me less useless on so many of the existing open-source projects I love haha.

I certainly want to learn Rust, but I also worry that with my Python/PHP background maybe learning more C and/or C++ would make the transition smoother. Or do you think it wouldn't make much difference and I should just dive in to Rust?

@self @happybeing have you done a lot of concurrency before? IMO the most important difference between C or C++ and Rust from a learners perspective is its concurrency model. It can really mess with your head and make it hard to do things that seem like they should be simple until you fully grasp Borrowing + Ownership.

@self there's certainly a benefit to knowing C/C++ and indeed what happens under the hood of a systems language, before learning Rust.

But even with this, borrowing and lifetimes are challenging, and I don't claim to understand them properly yet, but I can now understand lots of Rust code and have built a decent Rust CLI app:

So don't assume it's too much for you, there's lots of excellent docs, tutorials and folks to help, so you can always dip in and see.

@happybeing that sounds great, and very encouraging! Thanks so much! :)

@self you're welcome, feel free to ask for pointers.

What works for you will depend on your preferred way to learn, but head over to, and don't be shy to ask for help on the Rust forum and the two Discord channels, and here!

Tip: start by installing rustup and then use that to install the compiler and tools. VSCode works well with Rust if you use that.

@self At this point I would consider Go or Rust rather than C or C++.

Of the two, Go is easier but uses automatic memory management. Rust lets you avoid even the possibility of tiny GC pauses, but at the cost of making programming more complicated.

Sign in to participate in the conversation | Mastodon

Lusers unite! Despite the name, no loyalty or alignment with any software or technology are prerequisite - we welcome all! This instance is dedicated to inclusion and will not become yet another negative "tech" stereotype! For example, if you're not okay with people of different races or genders... please move along. If you think it's harmful for projects to adopt a code of conduct or ethical license... please move along. There are plenty of other Mastodon instances out there, and I would like to have be one of the few Linux/open-source related instances that does not reaffirm stereotypes!