Almost always happens to me when I´m working on the intermediate algorithm scripting challenges and also on projects, that I spend too much time bulding functions and methods and etc for one thing when I then i look at the solutions and tutuorials and it was just using 1 or 2 things to accomplish the same things.
Also, I feel i´m always using for loops 90% of the time lol. I have a hard time making things work when high order functions because of the returns and assignement with functions (scopes) and I feel I don´t have a right place to search for this kind of stuff (a cheat sheet for noobs would be nice for this kind of things, I´m considering building a similar app for a project ironically lol)
Hey it is natural to feel that way, for I have also felt that way as well. As you keep coding and build experiences, you will become familiar and comfortable with the general flow of algorithms and common data structures. Then you will become more efficient and things will be more intuitive for you
I spend most part of the past weekend listening videos about APL[0], this one[1]
was really good and explains the reason behind why programming is so
complicated:
Functional programming (and most programming languages), have a serie of
priciples:
Abstraction
Lambda abstraction
Data abstraction
Abstraction[2]:
A program is a representation (or a simulation) of something, that something
can be described by a series of facts (information, domain knowledge[3], etc.),
These facts can be represented as data by a program, but the
programmer needs to express/explain how this data should
be interpreted as those facts. A great example of this is the Magic Number[4]
or the number 42[4.5].
But a static representation of data is not enough, interactivity needs: actions,
time and state.
Actions can be represented by functions, time by control structures/flow[12],
state by variables. The programmer also needs to express/explain how all of this
should be interpreted.
You have to spend that “much time bulding functions and methods and etc for one thing”, because you are building a representation of the solution
using a limited set of tools (the programming language). The thing is, build a
representation of anything is hard[5]. That why programming is described as an
iterative process[6][7].
Lambda abstraction
This point to the use of design patterns, libraries and frameworks as a way of
“escape from language limitations”[8].
I think this is more of the JavaScript side than yours, in the video course of
SICP[10] the assignment (and scope) is described as something “philosophical
harder”. So at least, you are not alone.
The term magic number or magic constant refers to the anti-pattern of using
numbers directly in source code. This has been referred to as breaking one of
the oldest rules of programming, dating back to the COBOL, FORTRAN and PL/1
manuals of the 1960s. The use of unnamed magic numbers in code obscures the
developers’ intent in choosing that number, increases opportunities for
subtle errors (e.g. is every digit correct in 3.14159265358979323846 and is
this equal to 3.14159?) and makes it more difficult for the program to be
adapted and extended in the future. Replacing all significant magic numbers
with named constants makes programs easier to read, understand and maintain.
Iterative Refinement addresses the issue that problems are complex and multifaceted.
Getting everything right at once is nearly impossible. Instead, computer
scientists borrow iterative refinement from the physical sciences to tackle this
design problem. In essence, iterative refinement recommends stripping away all
inessential details at first and finding a solution for the remaining core problem.
A refinement step adds in one of these omitted details and re-solves the expanded
problem, using the existing solution as much as possible. A repetition, also
called an iteration, of these refinement steps eventually leads to a complete solution.
Pascal is for building pyramids —imposing, breathtaking, static structures
built by armies pushing heavy blocks into place. Lisp is for building
organisms — imposing, breathtaking, dynamic structures
built by squads fitting fluctuating myriads of simpler organisms into place.
The organizing principles used are the same in both cases, except for one
extraordinarily important difference: The discretionary exportable functionality
entrusted to the individual Lisp programmer is more than an order of magnitude
greater than that to be found within Pascal enterprises. Lisp programs inflate
libraries with functions whose utility transcends the application that
produced them. The list, Lisp’s native data structure, is largely responsible
for such growth of utility. The simple structure and natural applicability of
lists are reflected in functions that are amazingly nonidiosyncratic. In
Pascal the plethora of declarable data structures induces a specialization
within functions that inhibits and penalizes casual cooperation. It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures. As a result the pyramid must stand
unchanged for a millennium; the organism must evolve or perish.
[9] Sometimes you get the recommendation of “use design patterns,don’t use
libraries”, but in reality, libraries are design patterns.
Is not a coincidence that for some time Reactjs has this line in his
documentation “lots of people use react as the V in mvc.”[11]
The difference is: a library is developed and maintained by other person
(if that is something good or bad is not the point).
