This week's book giveaways are in the Jython/Python and Object-Oriented programming forums. We're giving away four copies each of Machine Learning for Business: Using Amazon SageMaker and Jupyter and Object Design Style Guide and have the authors on-line! See this thread and this one for details.
[I put it here because don't know where else fits. If some more knowledgeable Rancher know can easily move it thanks ]
We professionals(industry and academia) define programming, as a general human activity, to mean the act of extending or changing a system’s functionality.
Programming is a widespread activity that is done both by nonspecialists (e.g., consumers who change the settings of their alarm clock or cellular phone) and specialists (computer programmers, luckily the audience for this thread).
In a setting of construction of software systems, programming is the step between the system’s specification and a running program that implements it. The step consists:
in designing the program’s architecture and abstractions and
coding them into a programming language.
This is a broad view, perhaps broader than the usual connotation attached to the word “programming” by common people. It covers both programming “in the small” and “in the large”. It covers both (language-independent) architectural issues and (language-dependent) coding issues. It is based more on concepts and their use rather than on any one programming language.
We as professionals also find that this general view :
is natural for teaching programming.
It is unbiased by limitations of any particular language or design methodology.
When used in a specific situation, the general view is adapted to the tools used, taking into account their abilities and limitations.
Both science and technology
Programming as defined above has two essential parts:
a technology and
its scientific foundation.
The technology consists of:
practical techniques, and
allowing us to do programming.
The science consists of a broad and deep theory with predictive power, allowing us to understand programming. Ideally, the science should explain the technology in a way that is as direct and useful as possible.
If either part is left out, we are no longer doing programming. Without the technology, we are doing pure mathematics. Without the science, we are doing a craft, i.e., we lack deep understanding. Teaching programming correctly therefore means teaching both the technology (current tools) and the science (fundamental concepts).
Knowing the tools prepares the student for the present.
Knowing the concepts prepares the student for future developments.
More than a craft
Despite many efforts to introduce a scientific foundation, programming is almost always taught as a craft. It is usually taught in the context of one (or a few) programming language(s) (e.g., Java, complemented with Haskell, Scheme, or Prolog). The historical accidents of the particular languages chosen are interwoven together so closely with the fundamental concepts that the two cannot be separated.
There is a confusion between tools and concepts. What’s more, different schools of thought have developed, based on different ways of viewing programming, called “paradigms”: object-oriented, logic, functional, etc. Each school of thought has its own science. The unity of programming as a single discipline has been lost.
Teaching programming in this fashion is like having separate schools of bridge building: one school teaches how to build wooden bridges and another school teaches how to build iron bridges. Graduates of either school would implicitly consider the restriction to wood or iron as fundamental and would not think of using wood and iron together.
The result is that programs suffer from poor design. Here’s an example based on Java, but the problem exists in all languages to some degree.
Concurrency in Java is complex to use and expensive in computational resources. Because of these difficulties, Java-taught programmers conclude that concurrency is a fundamentally complex and expensive concept. Program specifications are designed around the difficulties, often in a contorted way. But these difficulties are not fundamental at all. There are forms of concurrency that are quite useful and yet as easy to program with as sequential programs (e.g., stream programming as exemplified by Unix pipes). Furthermore, it is possible to implement threads, the basic unit of concurrency, almost as cheaply as procedure calls. If the programmer were taught about concurrency in the correct way, then (s)he would be able to specify for and program in systems without concurrency restrictions (including improved versions of Java).
[Arguing with an engineer is a lot like wrestling in the mud with a pig. After a few hours, you realize that he likes it] [Learn code first? no we apply to learn programming(or also)first thanks]
www.merriam-webster.com wrote:pro·gram·ming | \ˈprō-ˌgra-miŋ, -grə-\
variants: or less commonly programing
Definition of programming
1 : the planning, scheduling, or performing of a program
2a : the process of instructing or learning by means of an instructional program
b : the process of preparing an instructional program for a device (such as a computer)
Now let's look at program:
www.merriam-webster.com wrote:pro·gram | \ˈprō-ˌgram, -grəm \
Definition of program (Entry 1 of 2)
1 [ Late Latin programma, from Greek ] : a public notice
2a : a brief usually printed outline of the order to be followed, of the features to be presented, and the persons participating (as in a public performance)
b : the performance of a program
especially : a performance broadcast on radio or television
3 : a plan or system under which action may be taken toward a goal