每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，欢迎关注开源日报。交流QQ群：202790710；微博：https://weibo.com/openingsource；电报群 https://t.me/OpeningSourceOrg
今日推荐开源项目：《自己家的 HTML 和 CSS PureCSS-Font》传送门：GitHub链接
推荐理由：相信大家已经对这个画的各种画的作者有了深刻印象了，那么这次要介绍的就是纯 CSS 字体项目，你可以拿去放在各种各样的地方，不管是防止被复制粘贴带走你的文档亦或者别的用途都可以，如果你输入文本转换之后看看那几个字的 CSS 样式表……即使是写下几个字母，需要的样式表都会非常的长，顺带一提，不支持中文。
今日推荐英文原文：《The Efficiency In Coding Strictly》作者：Isaac Way
原文链接：https://medium.com/@isaaccway228/the-efficiency-in-coding-strictly-e79beceafa05
推荐理由：如果一个项目需要编写大量的代码，严格的结构化的语言会相当有帮助；但是如果它是一个新的尝试或者不需要编写太多代码，放弃结构将会是个好主意；在编程中需要灵活选择它们，作者在这篇文章中就介绍了选用严格结构化的语言与否会造成的一些影响。
The Efficiency In Coding Strictly
Before I get into what it could mean to code “Strictly” or even “Efficiently”, I’m first going to tell you just a little bit about my coding experience so you know where I’m coming from.
Static Vs. Dynamic
I’ve spent significant time coding in both dynamically typed and statically typed programming languages. For anyone who doesn’t know, statically typed languages (C, C++, Swift) are, generally speaking, languages that require the developer to give a variable a type when it’s declared. A dynamically typed language like (Python, Javascript) does not require you to specify a type for every variable. I don’t know exactly how much time I spent in these languages exactly, but if I had to guess I would think it’s split pretty evenly. ⅓ of my time was in C/C++/JS, and ⅓ of my time was spent in each of Swift and Python. I say this just to make the point that I have no preference among these languages, I use whatever I need to use to make whatever it is I need to make. Personally speaking, I very much enjoy coding in both Swift and Python which are both at opposite ends of the spectrum as far as strictness goes. C/C++ I don’t enjoy as much, but they’re cool but in the same way that a game boy color is cool. Don’t get me wrong, those languages are necessary in some areas of software even today, but they’re not “easy” to get things done compared to something like Swift, or Python.
For highly streamlined things like developing an high performing iOS app, where we know exactly what is expected, we tend towards a strict structured approach that assures quality if done right. On the other hand, if I were a researcher using Python I wouldn’t know what’s going to happen before hand. In this situation, it doesn’t make sense to have a strict structure because I don’t have a long term idea of what the process will look like and it changes day to day. Therefore, the highly flexible structure of something like Python allows you to quickly respond to these changes, and designed patterns that make doing some things easily suddenly start to make a lot less sense presented with the new situation. The code that the researcher would be writing is not a large and complicated system typically, rather it’s a few well thought out scripts and visualizations.
Being Strict Reduces Our Workload
When there’s not as much total code, it’s significantly easier to get it right as well as debug it. It’s easier to know what your variables are without being explicit. So we don’t need the strict structure in these situations, it serves us no benefit at all. If anything, trying to put this ill-defined process of research into a well defined design pattern might hurt us. That is why we need languages like Python, for when our tasks require high degrees of flexibility and problems that may not as easily be solved with a previously used solution. For any time we explore something new we necessarily must discontinue being strict, because if we are being strict we are using a predefined structure, and since the thing is new it is impossible to know it’s real structure. So Python throws away the structured approach and presents you with the minimal logic needed to create a working program, making it as easy as possible to make changes and bring in new ideas.
But It Also Limits Our Flexibility
On the other hand, the lack of structure in Python makes it relatively inefficient (when compared to something like Swift) at things where the requirements are always known beforehand, when the problem is known to fit a design pattern we can easily employ. The example I go back to an iOS App. If I’m using xcode to create GUI (Which is the native and preferred way to work in Swift) and link it to swift code, it is incredible to me that I can get a good looking, working App running in just a few hours of work. It may not do anything useful at that point, but it looks good, and it freaking works. That’s more than I can say about my experiences creating a Python GUI.
“Strict”
Prototype iOS UI Made In Swift. Took a few coding hours in total. ~140 lines of code.
One of my personal projects over last summer was a visualization tool that was to be made entirely using Python’s built in libraries. That means, using tkinter to create a GUI. I’m not saying it’s a good idea to use tkinter in a serious application, or any application for that matter, but the point is it’s not “strict”. It doesn’t make you use a specific design pattern or require you to structure your app in a certain way, it just gives you UI objects to work with and you place them within your app using various methods. The result was to make just a single UI, it took me weeks. I had to code UI elements from scratch (Which is fast in swift because the design patterns it makes you use, but slow in tkinter because it’s not made to use any specific design pattern). I had to code a grid system in that worked with tkinters. The code got ugly, fast. In the end, I ended up with something that’s usable but definitely not the prettiest, and not the most maintainable. And that is exactly what happens when I’m coding “not strict” when I should be coding “strict”. I waste a huge amount of time, I end up with something that’s hard to make sense of later because it’s so dissimilar to anything I will make in the future. I’m not saying it wasn’t worth doing, because I learned some important lessons as well as made something kind of cool. My goal was not to be efficient in making a valuable piece of software. If it had been, it would’ve been a much better option to be more strict and find a more suitable tool for the job. To make the exact same kind of tool with the same if not more capabilities would take a fraction of the time creating it using Swift. Although I haven’t actually done it as an iOS app in Swift, I would think it would take a few days at most.
“Not so strict”
Visualization tool written in Python using Tkinter. It took weeks of a few hours of coding a day. It totals over 500 lines of code. The majority of the time was spent implementing custom UI elements. I was required to create in code the logic for the table and how the rows were displayed. It required much more work that I would not have had to do, had I created the same application in Swift.
We can never be 100% strict if there exists no structure to make sure that we’re strict in any given situation. The language Swift presents a very structured approach to solving every single problem, and checks that it’s correct. In that way, the compiler combined with the design patterns in the language assures we are strict. It does so to such an extent, that the very process of creating something new becomes much faster. It eliminates a huge number of would-be developer errors, it assures that a familiar design pattern is used to solve the problem. The problem with this approach is, it is limited in what you can do and how you can do it: you cannot easily go outside the predefined structure. However, the structure can be expanded. What that means is, by implementing new problem solving capabilities within an inherently efficient set of rules, we necessarily make solving that problem faster than a less efficient set of rules. In a perfect world, every problem would have a “strict” solution, a solution that is already defined. But as we all hopefully know by now, the world isn’t perfect and neither are our solutions, so we are forced to find a balance.
Coding Strictly might mean using a statically typed programming language, but more generally it means knowing how solutions are going to be implemented ahead of time and making sure that the solution itself has been proven to work well, and then implementing that solution to a T. If we’re in a situation where efficiency and productivity matter we should be strict, but only if we are certain we actually have a suitable strict solution. Whether it’s a strict situation or a not-strict situation, well, that’s a decision best made by the developer at hand.
I hope you enjoyed this article. For any feedback please comment, for anything else email me at [email protected]. Thank you!
每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，欢迎关注开源日报。交流QQ群：202790710；微博：https://weibo.com/openingsource；电报群 https://t.me/OpeningSourceOrg