Take a look at Dart+Flutter.
Python would be OK. Ruby is nearly dead nowadays. JS itself is used rarely, better consider using TS (however I don’t recommend using them for anything other than web frontend). Go is a great language but it’s unpopular in GUI development.
DEL is supposed to delete one row of text
It’s not. It overrides a row on a punch card, i. e. one character.
Jenkins is not a modern CI. It is a historical milestone, but if you read an article you should see that it was replaced by other tools. Now I don’t recommend considering Jenkins for new projects. It it fast to set up but extremely hard to support and full of old bugs and legacy code. Writing Groovy pipelines is much harder than pipelines in gitlab/github/forgejo/etc. Tens of plugins you have to use even for simple tasks have inconsistent syntax, many of them are buggy, they often become unsupported or deprecated. This all consumes lot of resourses: I maintain an instance that eats ~4G of RAM being idle.
It’s not a proper fix, there are still cases when correct escaping is impossible and the function simply returns a error. I don"t know if if this possible at all to escape any string or if it is just because of lack of documentation, but anyway i wouldn’t call this a thing that is easy to fix.
Options. We’ve got lots of them. So many in fact, that you need two strong people to carry the documentation around. So many that it will be a cold day in hell before half of them are used. So many that you are probably not going to do your work right anyway. However, the number of options isn’t all that important, because we picked some interesting values for the options and called them …
Defaults. We put a lot of thought into our defaults. We like them. If we didn’t, we would have made something else be the default. So keep your cotton-pickin’ hands off our defaults. Don’t touch. Consider them mandatory. “Mandatory defaults” has a nice ring to it. If you change them and your system crashes, tough. See Figure 1.
it should be an easy fix
But it’s not. Have you read the article?
Premature optimization is the root of all evil. Implement algorithm the easiest way possible, profile your application, determine if this implementation a bottleneck or no. If yes, try other implementations, benchmark them and find the fastest one. Note that optimized go code can be faster than non-optimal code in rust, C, assembly or any other language.
Well, sometimes it is possible to write a loop with break or without it, and in such cases solution without break is better readable. But if you don’t see a simple way to avoid using break, use it. It is very common, as well as having multiple return statements in function. Even goto can be a good solution sometimes if it points to label located below and not very far.
However you should avoid some antipatterns. If you write an infinite loop that is interrupted only by break, it is highly likely that you are doing something wrong. Nested loops with multiple breaks or gotos are very hard to read and debug. Such code usually can and should be rewritten for better readability and to avoid possible errors (occasional hangs, for instance).
I agree. The problem is that we already have a lot of compatibility breaking options in gcc: different language standards, non-standard extensions, language features that can be disabled, warnings that can be turned into errors… Multiplying them is not the thing that will make a programming language/compiler better.
There’s nothing new in rust that was not already possible with C++. It is possible to change language syntax using macros and templates… if you want to write code that nobody will understand.
You have make, cmake, b2, meson etc. to define flags that you want using another syntax.
Well, every C/C++ compiler is overcomplicated because it has a preprocessor, provide numerous pragmas, attributes etc. etc. What you want is not just a new compiler, it is a new customizable language.
Did you read the gcc documentation? Don’t you think it is already overcomplicated?
Well, reference manual was enough for me. There’ nothing difficult. You probably have troubles with your lua code, try executing it in the standalone interpreter.
Terminus.
To be honest, I don’t care. If I dislike a default font somewhere, I change it, but there’s no a favorite one. The font must be readable, that’s all.
Authors should write it in the opposite order.
Each commit includes the diff
It doesn’t. ☺
I totally disagree. Git is not hard. The way people learn git is hard. Most developers learn a couple of commands and believe they know git, but they don’t. Most teachers teach to use those commands and some more advanced commands, but this does not help to understand git. Learning commands sucks. It is like a cargo cult: you just do something similar to what others do and expect the same result, but you don’t understand how it works and why sometimes it does not do what you expect.
To understand git, you don’t need to learn commands. Commands are simple and you can always consult a man page to know how to do something if you understand how it should work. You only need to learn core concepts first, but nobody does. The reference git book is “Pro Git” and it perfectly explains how git works, but you need to start reading from the last chapter, 10 Git Internals. The concepts described there are very simple, but nobody starts learning git with them, almost nobody teaches them in the beginning of classes. That’s why git seems so hard.
shis for shell.