每天推薦一個 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!

PureCSS-Font

2018年11月2日：開源日報第239期