今日推薦開源項目：《漫畫創作 comicgen》
今日推薦英文原文：《Why Codeless Software is Doomed to Fail》
今日推薦開源項目：《漫畫創作 comicgen》傳送門：GitHub鏈接
推薦理由：一個在讓你能網頁上創作漫畫的項目，只需要組合那些圖片，之後加上自己寫的台詞。這個項目提供了不同人物的不同姿勢和表情，將它們和你獨特的故事組合起來，就能夠成為一個自己創作的漫畫（即使你並不會畫畫），展現出來的效果大概像這樣：
今日推薦英文原文：《Why Codeless Software is Doomed to Fail》作者：Wessel Badenhorst
原文鏈接：https://medium.com/@Wessel/why-codeless-software-is-doomed-to-fail-80871ca3ea07
推薦理由：能不寫太多代碼而是直接圖形界面完成的應用程序沒辦法像普通寫出的應用程序一樣靈活而容易自定義，這導致讓圖形界面實現複雜的程序變得困難
Why Codeless Software is Doomed to Fail
Every couple of years, the hope surfaces that a simple graphical interface will replace teams of developers. Business people to quickly and easily create beautiful expressions of their ideas and launch them into production seamlessly. A handful of startups in every generation take up this challenge, and they mostly fail.Why do people keep trying to breathe life into a solution that is so obviously doomed to fail is an interesting question, but a more useful question would be why is it doomed to fail, and what are the alternatives.
The reason why companies keep trying to create canvas driven development tools has 2 components. The first is that as a software engineer, you learn to map out your ideas in some visual representation. These simple flow charts, UML diagrams, or high fidelity mockups then have to be translated to code that a computer can interpret. During the design phase the process feels really smooth, you clarify your thoughts and produce a lot of value in a relatively short amount of time, if only the actual coding could be this frictionless. The second reason is that working with developers can be frustrating. Business people often have to contend with neverending lists of constraints in terms of what the 「system」 can and cannot do, or constant excuses for why deadlines were not met because of some unforeseen technical difficulty. Surely there has to be a better way. Where these two motivations meet, a business idea is born: 「Let』s create a tool that makes building software as easy as drawing up a flow diagram!」
At first glance, the idea has merit. There are more than enough examples of tasks that used to be really hard, but today are simple. One such example is the task of building a website. A little more than 12 years ago, building and hosting a website was a serious undertaking, costing thousands, and requiring many experts. Even small text changes took weeks and were a costly undertaking. Today you can spin up a beautifully designed website in a matter of minutes. A little further back in time you would have been very well paid if you were skilled at using spreadsheet software, a skill that has become a requirement for most entry-level office jobs.
If this trend holds, and it seems like it does, pretty soon even a regular high school kid should be able to build the next Netflix using nothing more than an easy 「click and drag」 interface.
This is the promise low-code platforms are built on. In every pitch to investors or potential business clients, the inevitability of codeless production products is pushed. These businesses mostly start out with some simple flow diagram based interface that lets you string the flow of data or user interactions together. Small blocks representing data sources can be dropped onto the canvas and connected to the software. Then, in theory, you can just press a button and your app, report, or tool is generated. See it just works!
At this point, the interface business has the client excited and ready to begin replacing all their expensive software engineers with business analysts who are experts at mapping business flow.
There are, however, two missing pieces that are conveniently left out, or overlooked. The examples of applications that left the domain of software engineers are very specific application. The Wix website does not make for a great backend for an analytics app, and Excel is a really poor database. It is precisely where you move outside of the parts that came in the box that you run into trouble. Suddenly there is not a box to just drop in to connect to your phone』s accelerometer and detect and unnatural movement. Your low-code provider either informs you that their tool was not made for your specific use-case, or you are told that you will have to build your custom functionality yourself, using their very friendly scripting language. The other missing piece is the fact that the visual diagram is a gross simplification of the actual solution. It pays no mind to the things that can go wrong or all the little details that are captured by a simple line. Once again these details need to be clearly expressed in a way that is accurate and unambiguous.
Suddenly you find yourself looking for programmers who are well versed in the specific low-code platform that you bought, and it is a really hard task.
The reality is that whenever you are building software with any level of custom functionality, as in it does not come in the box, you are going to need people who are comfortable writing code. These individuals are more comfortable writing code in code, and not in some code-picture hybrid. This is why low-code is bound to fail, the moment you need to create something in a domain that does not fit existing tools, you are already into the domain where you will eventually need programming done, and in that domain, you need a programming language, not a drawing tool.
What is the alternative?
Since the beginning of the computer age, we have seen a steady progression in the way in which we communicate with computers, from the binary programs written on punchcards to the explosion of modern programming languages like Python, Elixer, and Rust. What is happening is that the languages themselves are becoming more expression and more abstract. What this means is that the distance between an idea and the code you need to write is shrinking and that you need less and less code to express these ideas.
Programming, coding, or software engineering is and will remain the art of expressing complex ideas as clearly and completely unambiguously. It is firstly, coming up with these ideas, and secondly, this expression, that makes software projects hard to estimate and often expensive to complete.
Yes in future businesses will require fewer people to achieve the same results, but as we have learned from the productivity field, the moment you are able to do more, the amount that you wish to do explodes to match your newfound capacity. Your increase in output is also matched by your competitors, and you need to move as fast as you can just to remain relevant.
Rather than spend time on a Quixotic adventure in low code, find a dozen good software engineers, and free them to use the most expensive tools available. You will save yourself months of pain, and avoid a costly rewrite, the inevitable end of every low-code project
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
