How do I go about this? Are there any free resources that’ll help me get started?

I see people advising to start with a small project, but you need to get some basics down right? What language? How to develop it and stuff?

My only experience is some very basic C programming classes I took during school.

  • Sinthesis@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    18 days ago

    Learning a programming language , is pretty simple (didnt say it was easy)…its memorization. Maybe less so now with the advent of things like Copilot/AI assistants.

    Understanding what you’re trying to accomplish is possibly the harder part. I would rephrase your statement: “I want to learn how to build an application”. For this you can butter toast…with instructions.

    Pretend there are two people, one is the instructor and one is the toaster/butterer. There is a wall between them so one cant see what the other is doing and the end result is buttered toast. There are a couple resources; bread, butter, knife, toaster, plate.

    1st attempt the instructor says: Pick up bread, put it in toaster, take out bread and put on butter. Result: Untoasted bread, butter on hands

    2nd attempt the instructor says: Pick up bread, put in toaster, push switch down to toast, take out bread and use knife to put on butter. Result: Loaf of untoasted (did you check if toaster is plugged in?)bread with butter on both sides sitting on the counter (remember the plate?).

    See how specific you have to be about certain things? I would call this functional programming. Object oriented program takes it a bit farther in that the toaster is now classified with things like; browness level, electricity/plug state, slice/bay current occupancy, toast switch etc.

    • laurathepluralized@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      16 days ago

      This is a great analogy! To build on these points and the analogy: I like to think of my coding in terms of inputs, outputs, and what needs to happen to the inputs to get the outputs I want: that is, inputs->how->outputs. So for this buttered toast analogy, your inputs would be:

      • toaster
      • electricity
      • bread
      • butter
      • knife
      • plate
      • operator’s hands

      The desired output: toasted bread on the plate with butter spread on one side.

      The “how” is the sequence of specific instructions the instructor gives to the operator.

      This approach is even more helpful as you start working on larger projects; as you think about a problem you’re trying to solve, try to break the overall input->how->output into smaller modules of input->how->output, and then you can use those modules (often called “functions” or “methods”) in the overall “how.” Let’s say you want the instructor and operator to prepare a full breakfast with bacon, eggs, and buttered toast. You’ll have some more inputs, of course (frying pan, raw bacon, shelled eggs, stove, in addition to the toast components), but since you already made a known-good make_buttered_toast function, you can incorporate that function into the pipeline to go from your more comprehensive set of inputs to the full breakfast outputs, and you can make separate functions for making the bacon and making the eggs. Finally, your overall program can then call your bacon, eggs, and toast functions to result in the desired output of a full breakfast.

      Now here’s where breaking the problem down into smaller input->how->output chunks really comes in handy: one day, you are tweaking your breakfast-making code, and suddenly, your overall outputs have good bacon and good toast, but the eggs wind up dumped half-cooked on the stove. But since you made nice, modularized functions for toast, bacon, and eggs, you automatically know more where to start looking for the bug: the eggs function.

      There’s a lot of good advice in the responses to this post! Overall, I just wanted to emphasize what I wish I had learned much earlier on in my career: the benefits of thinking in terms of inputs->how->outputs and modularizing sub-problems in the overall program’s “how” into subproblems that can be independently considered, debugged, and re-used on future projects. (A secret for you: those of us who have been coding for a while often don’t start everything from scratch–we’ll re-use some functions or classes we wrote in the past, tweaking them as necessary for new applications, but not needing to start from a blank text editor :) ) Learning to write applications in code is exploring a new way of thinking about problems and how to solve them, and personally, I find it very rewarding!

      I wish you all the best on your coding journey!