Thành viên VIP
Today I talk about the problems of newbies. I occationally look into the site Stackoverflow.com and stiil wonder why some "developers" have trivial problems such as "NullPointerException" or "won't work as expected" or "how to RegEx..." or "how to use Stream..." etc.
All the problems are more or less selfmade because they, the wanna-be developers, learn a programming language by starting to work immediately with a tool that is not only confusing, but also very complex. The tool complicates the matter and obstructs the learning process more than it helps them. OOPL (Object Oriented Programming Language) requires a good portion of abstract thinking. Without it the learners should look for another job. And the tool whose name is IDE (Integrated Development Environment) suggests a learning wonderland for the newbies. What a delusion !
First: OOPL is a high-level programming language, but it is also a philosophy of Object Imagination. An object is like a living species which is either alive or dead. A species is only alive when it is BORN. Otherwise the species won't exist. An Object exists only if it is INSTANTIATED. Otherwise it won't exist and a NullPointerException is assured. Newbie-developer confuses the naming with existing. The difference is between the word cow (naming or declaration) and a cow herself (born or instantiated).
Then the different way how a species exists (growing, walking, crawling, swimming, flying, etc.), feeds (herbivore, carnivore, sunlight assimilation, etc..) Each process is a complex procedure. Beside the primitive statements such as if-else, do-while, for, etc. OOPL bases on numerous APIs (Application Programming Interfaces). Without the APIs an OOPL degenerates to a 3GL like C (3rd Generation Language). The APIs are the "processes" (or to be more precise: a group of little independent programs). They wrap the OOPL around the OS environment (e.g. files, path, networking, etc.) and make a 3GL to an OOPL. If you don't know how a species (e.g. a hog or a cow) lives you never are able to breed the animal with any tool. Exactly like that, if you don't understand the basics of OOPL and how the APIs work you won't be able to develop an application.
Finally a species can only thrives in its favorable environment. In the nature species move and wander to the favorable places where they could temporarily or permanently sojourn. If you breed a species you have to create a similar favorable environment for it. If you don't know how to build, for example, a sty for your hogs your hogs could perish under the bad conditions (because of your nescience.) If you want to develop an OOPL application with whatever development tool you have firstly to master the language, then to understand the tool before you could start to develop. Otherwise you fail badly. A sty without a healthy airflow could choke the animals. A mis-adjusting of the IDE settings could lead to a "file not found" or a "NullPointerException".
In real life: lots of farmers fail badly because they don't master the farming technique. So they blunder their farm to ruin. Lots of newbie-developers often run into nightmares because they fail to master the language and to understand the tool (or IDE) before they start to work with. The problems are very visible with newbies who "develop" Java on Android. They learn how to code in JAVA or KOTLIN, but they fail to understand the relationship between JAVA/KOTLIN and the "required" resources (e.g. XML) demanded by the tool.
The fairy tales about Netbeans, Eclipse, Android studio, etc. (e.g. IDE quickens the development process) are neither imaginary, nor real. Those who master the OOPL and the development process rarely rely on any IDE, but on their knowledge. It's because an IDE is just a tool. Newbies who firstly jump on the IDE wagon because of the touted feature "SMART & QUICK" usually run into the worst nightmare that their "developed" codes won't work properly, produce either weird exceptions and send incomprehensible error messages. At the end, instead of on-time delivery, they fail to meet the development term because their IDE outsmarts them so much and causes too many unpredictable delays. I myself developed a lot of (big) applications using a relatively simple, but comfortable editor JEDIT which never patronizes me with "method suggestions", nor delays my development work with weird empty coding frames, or with complaints about mis-adjusting settings.
Why IDE won't be useful with small projects? Because it simply causes too much overhead.
- Usually an IDE produces several directories whose paths are set and used internally within the IDE environment. Outside IDE the app could run into path-problems (file not found or NullPointerException, etc.)
- Too many directories usually cause confusion and problems with package-imports
- Bad performance. Too many little objects (or classes) frequently cause codes-(re)loading or Garbage-Collection. As the result the system is too busy with itself at the expense of code execution.
- Bad maintenance for outsiders. For debugging it' s always hard to follow the executing thread when numerous methods of different little classes from different "packages" are involved.
the weird message: "Java “The superclass ”javax.servlet.http.HttpServlet“ was not found on the Java Build” but other problem"
I always remember that my 1st car, an old VW Beetle (build year 1880), was so simple and so easy to maintenance and to repair. Today, my Audi TT-S (build year 2017) is so complex and so complicated that I do not even attempt to change a bulb! AND: we, people, complain about wasting of resources. We demand all kinds of recycling...by the others (and not by us ourselves).
We complain about the imperfection of OOPL, the sluggish internet and the buggy applications, but we still waste and complicate the resources with numerous directories and little classes by our little apps.
Sửa lần cuối: