Street coder 1.4.1-1.4.2

Original: https://livebook.manning.com/book/street-coder/chapter-1/19
Translation: Zhu Kunrong

Cátia Matos photo: https://www.pexels.com/en-us/photo/1072179/

1.4.1 Too many technologies

Our ongoing quest for the best technology stems from the silver bullet fallacy. We think there is a technology that can multiply our productivity. Actually not. For example, Python is an interpreted language. You don't need to compile Python code - it runs right away. Even better, you don't have to specify the type of the variable, which makes you faster, so Python must be a better technology than C#, right? not necessarily.

Since you didn't take the time to declare the type of your code and compile it, you missed the error you just wrote. This means you can only find them in test or production environments, which is much more expensive than simply compiling source code. Most technologies are a trade-off for increased productivity. It's your proficiency in technology and skills that increases productivity, not what technology you're using. Yes, there are better technologies, but they don't make an order of magnitude difference.

When I wanted to develop my first interactive website in 1999, I had absolutely no idea how to write a web application. If I start trying to search for the best technology, I'll have to teach myself VBScript or Perl. Instead, I used Pascal, which I am most familiar with. This is the least suitable language for this purpose, but it works. Of course, there will be many questions. When the program hangs, the process still lives in memory on a random server in Canada, and the user has to call the service provider each time and ask them to restart the physical server. Still, because of my familiarity, Pascal allows me to quickly develop a prototype. Instead of months of developing and learning, I can write and release code in just three hours.

I hope you can also use the tools that suit you in your own way.

1.4.2

The earliest programming paradigm I remember was the structured programming languages in the 1980s. Structured programming languages are basically written in blocks like functions and loops instead of line numbers, GOTO statements,
Blood, sugar and tears. It makes it easy to read and maintain code without sacrificing performance. Structured programming sparked my interest in languages like Pascal and C.

After at least 5 years of my study of structuring, I came across the next paradigm: Object Oriented Programming, or OOP. I remember there weren't many computer magazines back then. This is a big deal that will allow us to write better code than structured programming ever did.

After OOP, I think I might encounter a new paradigm every five years. Actually they appear faster. In 1990, the Java language compiled using managed JIT, JavaScript web scripts,
With the advent of Java in the 1990s, we were exposed to compiled managed programming languages, and functional programming that suddenly became mainstream in the late 1990s.

to 2000. In the next decade, we will see more applications using layering. Rich client. thin client. Generics. MVC, MVVM, MVP. Asynchronous programming began to introduce promises, futures, and finally, reactive became. Microservices. More functional programming concepts like LINQ, pattern matching and immutability made it into mainstream programming languages. It's a buzzword tornado.

I haven't listed design patterns or best practices. We have countless best practices, tips and tricks on almost any topic. There are many manifestos about why we should indent source code with tabs or spaces, and the obvious final answer to this is spaces.

We assume a paradigm, a pattern, a framework, or a library of tools to solve our problem. This is not realistic given the complexity of the problems we face. And blind use of these tools will create more problems in the future: they may introduce new domain knowledge to learn and certain bugs. They might even let you change the design. This book will make you feel more confident that you are using patterns correctly during code reviews.

---

This article is from Zhu Kunrong's WeChat public account "Malt Bread", the public account id "darkjune_think"

Developers / sci-fi enthusiasts / hardcore console players / amateur translators, please indicate.

Weibo: Zhu Kunrong
Station B: https://space.bilibili.com/23185593/

Communication Email: [e-mail]