Hi William,
Here are my two cents after nearly 30 years of writing code in many
different languages.
Writing in any functional language is exactly the same as in every other
functional language. The easiest way to learn and improve is by learning to
break down your problem into manageable steps. The simplest analogy I can
provide is the question and answer of: How do you eat an elephant? One bite
at a time.
Writing code is the thing you take a complex problem and break it down into
smaller chunks. Let's say I am asked to take an arbitrary git repository
and list all .txt and .png files in that git repository. I can just sit
down and begin writing but how would I do all that? I would first do it by
hand and record or memorize the steps I am taking. I would checkout the
repository, I would go through each directory and record all files that
have either a .txt or a .png extension, and provide the list of these files
and their path within the directory, maybe add their file size as well for
goot measure.
The next stage is writing maybe even in pseudo code or just pain text how
each step will work, lets take the crawling of the repo as an example of
what this would look like:
- Put the full path of the directory where the repo was checked out on a
list of directories to be processed
- Read contents of the directory where I checked out the repository
- For each file with a .txt and .png record the directory name a
'/' an the filename
- For each directory add them to the list of directories we need
to process
- Remove the now processed from the list of directories to be
processed
- Process the next directory on the list of directories to be
processed
- When no more directories are left to process we collected all files
with the.txt and .png extension
- Now we process the list of .txt and .png files and grab whatever
additional information we need for each file
- We now should have a structure with a full path for each .txt or .png
file (the keys) in the repository with associated as values the information
associated with each file
- All that is left it is a simple matter of printing out the structure
from the previous line one key at a time
Based on this list of steps above you can see where the loops would be, I
have indented those to make it easy to see which bits would go in a loop.
You now have the general structure of your code figured out and where you
will need loops you have an idea of what structures you will need to store
your data etc...
The above is completely language agnostic you can implement this in any
programing language all you need to do is figure out how to do each step
one at a time. You might not know how to list the contents of a directory
in your language of choice (in this case Perl) but that is easy enough to
look up. The same for finding the attributes associated with a file, again
this is easy enough to look up. Since you have this step by step plan you
can easily figure out how to do each bit and then just string them together.
I often add those above steps in my code as comments, and add the actual
code below each step. So I can see exactly what my goal is with each step.
Once that is done in your very first version of the code that produces the
desired results you stop walk away and have another look at it the next day
or so and clean things up as not a single person will write perfect code
from the start there always is something missing or something that you
would like to add (comments for instance). When done you have a working bit
of code that you can explain step by step as you have set down and
understood each step of the code. Having comments in the code is very
helpful for future you... when you look back at that code a year or two
from now you will be very happy to see the comments so you can understand
what you where thinking or how you broke down the problem back then when
you were still learning how to code in this language.
Keeping this code or even just the portion of the code that does the
walking through the directory structure in some code repository for future
reference will help you not have to reinvent that wheel in the future. As
it is highly likely that at some point a project will need something
similar but this time .pdf files are what you are looking for or maybe even
a user defined extension or all directories etc...
The most important thing about being a good developer in any language is
your ability to take a complex problem and break it down into small enough
parts that any monkey with a little bit of programming knowledge and a
search engine can figure out how to code each step.
Now as you get more experienced you might find that for certain things you
just know how to do that and you do not need to write it all down as you
can just do it in your head. But having worked with people that wrote
amazingly complex code form one of the developers of the DHCP protocol to
one of the people writing the guidance code for the patriot missile system
and optimizing games for the PS3's cell processor every good developer I
have worked with has sat there writing out the steps they needed to code
before ever opening a code editor simply because even truly brilliant
people need to break problems down into smaller steps to be able to
understand what it is they are going to have to code.
I hope that helps a bit.
Kind regards,
Rob
On Thu, May 30, 2024 at 6:59 PM William Torrez Corea <willitc9...@gmail.com>
wrote:
> I code but my logic is weak, i code 1000 lines of code but I don't
> understand the logic of the program. Can write 10 lines of code, get the
> result but I don't understand the concept.
>
> Can code the program but I can't interpret. My mentor told me: understand
> the concept because I talk nonsense.
>
> --
>
> With kindest regards, William.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄⠀⠀⠀⠀
>
>
>
