Last year in February V was announced. The language was designed by Alexander Medvednikov, who needed it for the development of Volt, a desktop client for chat applications. The writing of Volt, happened in Vid, a self-written text editor, also written in V.
V has quite a few interesting characteristics. Perhaps the most interesting, is the fact that V is written within itself. A first version was written in C, and after that it was developed further. The C version can also be found on Github.
On the website, V is described as follows:
Simple, fast, safe, compiled language for developing maintainable software.
As in most languages today, you can work in a modular way. V supports the development of modules very well, which makes it easy to develop packages, as we know them from npm and pip. Managing packages can be done with vpm, the package manager for V.
Something else the website claims is the following:
Compiles themselves in <1s with zero dependencies.
The question is of course: is this true? Much has been checked and said about this statement, but this is the piece of terminal output Alexander posted:
unzip v_linux.zip && cd v
./v -o ./v2 v.v # warm up
time ./v -fast -o ./v2 v.v
0.06s user 0.03s system 97% cpu 0.094 total
./v2 -o v3 v.v # make sure that V can still build itself
He also promises:
By January 2020 it should drop to 0.06 seconds.
What he’s basing this on is as yet unclear. He does not always respond in detail to substantive questions, nor does he always achieve the goals he sets for himself.
For example, the first stable version was due to be released in December 2019, but in the meantime both the website and Github have been updated to January 2020. Although that’s not too bad, it’s not the first time either.
There’s no garbage collection or reference counting. V cleans everything up during compilation. If your V program compiles, it’s guaranteed that it’s going to be leak free.
Next, on September 3, an issue is created because the example that V himself gives is leaking memory. There Alexander says he will solve the problem within a week. Even though the original author requested on an update two weeks later, this issue was never addressed. I’ve tested this problem, and it’s still in effect.
Furthermore, at the time of writing, the playground is not working (again). Earlier it was taken offline, because it was hacked.
There are also a lot of things that work well, you know. For example, hot code reloading works well in principle and translating C to V also seems to work reasonably well, if we look at the example provided.
Word in advance: I have made a few mistakes in the designs you are about to see. Some are intentional, some are not. Always check the datasheet before wiring up something and use some common sense.
If you develop prototypes from time to time, you may have designed schematics. A lot of people start with Fritzing, because it’s very easy to start with Fritzing.
My opinion about Fritzing’s earnings model is known thanks to my previous post, but also the technique of Fritzing is not ideal.This is not so much because Fritzing doesn’t work well, because it does, but because it doesn’t teach you the right techniques.
Getting started with our prototype in Fritzing
This is how the default starts in breadboard mode. This allows you to design with visual elements, schematics, as if you were looking at your prototype. That looks like this, for example:
This is still relatively easy to use. It doesn’t look very neat, but it’s easy to build on this drawing. However, the problem is already becoming visible. Imagine if we were to add five more motors to our robot:
This way of drawing clearly doesn’t work. The large parts take up far too much space and the connections have to be drawn far too close to each other. As a result, the whole thing becomes very messy and unreadable. The result is that you quickly make mistakes when reproducing these schematics.
This is still a very simple prototype: an Arduino that controls six engines via Bluetooth. There are no sensors, resistors, capacitors, LEDs, buzzers, converters, et cetera.
Designing schematics based on breadboard design
Therefore we stop with the “breadboard view” and switch to the second option within Fritzing, namely “schematics”. This of course sounds much more like what we want to make.
This also looks disastrous. That is logical, as we have not yet started to connect and clean up parts. Fortunately, Fritzing has a tool for us! Before we can use it, we place the parts the way we want them.
Now we can use Fritzing’s famous tool: autoroute. This tries to automatically make the connections of the components (based on our breadboard design), so that we have a good schematics view. The result is as follows:
Autorouting our schematics
As you can see, only five of the twelve connections are actually connected. The other connections were not made, because Fritzing didn’t succeed in doing so within a hundred attempts.
Originally I thought this was the case because Fritzing doesn’t want to draw lines through other lines, but this scheme is also proof that this is not the case.
I also noticed that in the breadboard view I accidentally connected the GND directly to the VCC. Such a mistake was relatively easy to make in the breadboard view, while in the schematics this would not happen very quickly. Of course I solved this immediately, after which I ran the autoroute again. At that moment everything is done again, and this work of art is created:
Excuse my words, but: What the fuck is going on here? I clicked on the autoroute a thousand more times out of amazement and it never happened again, so I assume this was a bug.
I was actually secretly pleased to see that there were more connections now than before, but every autoroute after this bug gave the same disappointing result:
Unfortunately. We haven’t made any progress yet. If we try to solve this neatly by hand, we end up with something like this:
After I first had to remove dozens of ratsnest lines, because there was such a line between each VCC and GND, I drew the lines myself. Of course this doesn’t work very well, because a lot of lines have to be drawn over each other and this makes it very difficult to get a clear overview.
It is clear that we need another solution. It doesn’t seem like it’s possible to make everything clear in one drawing. Maybe we should split it up into several drawings.
Unfortunately, Fritzing doesn’t have the support to do that in a good way. Before I switch to KiCad to show how to do it, I want to show what Fritzing does with PCB’s: the most important part. In the end, you want to be able to convert any good prototype into a PCB.
After I open the PCB view and manually place everything in a convenient place on my board, I click on autoroute. I expect Fritzing to try to use as few layers as possible and make sure a working PCB comes out.
Unfortunately, only the latter turns out to be true. Fritzing knows how to successfully connect everything, but that’s all there is to it. It doesn’t matter if it doesn’t work, but don’t offer it then.
A better alternative
Let’s move on to a solution that will hopefully work better. We’re going to split our design into several parts, each of which will be explained separately. This will keep the whole thing clear to work with.
We’ll get on with KiCad. This is an open source EDA that actually does work well. (KiCad, if you are reading this: your SSL certificate is not set correctly)
Create your first schematics
Let’s start all over again. Let’s learn from what we did wrong with the design in Fritzing. There, we tried to map out the whole system at once, and we saw that it didn’t even work with these small applications. We start by bringing our parts all into our project.
For some reason, this is already looking better, even though we haven’t done anything yet. In my opinion, KiCad feels much more professional than Fritzing.
Please note that I replaced the HC-05 here with a more serious Bluetooth module. The HC-05 is very nice when you are experimenting, but you don’t want to use it in your final product. So, in the prototyping process, start working with the module you want to use, so that you know if it works with your application.
Let’s make some standard connections, and indicate the connections between the elements with labels. KiCad natively supports this and this makes working with these schematics much clearer.
Now all our parts are on one page, together with the connections between all the parts. If we now want to expand or clarify parts, it can be done relatively easily. For example, we can add an LED to make it clear when the Bluetooth module is activated and we can make the current in the circuit clear. So I want this to work on a 12V battery and I want to give the motors 6V of that as well.
This is still far from enough to make a good PCB, but it gives a good picture of the difference in readability between Fritzing and KiCad. This is still far from enough to make a good PCB, but it gives a good picture of the difference in readability between Fritzing and KiCad.
On making PCBs in KiCad, I’ll go into it later. I do hope that you have gotten a picture of designing in KiCad and I would strongly advise you to take a look at it. Once you’ve started, you’ll never want to go back to Fritzing.
It is logical that Open Source organizations also like to earn money. Free software does not mean that there is no money to be made with it. After all, these developers must also be able to feed their families.
Strange methods of making money from open source software have been seen before. For example, OpenCollective is a collective that tries to support open source. One way is to persuade users to advertise by means of a message in the terminal.
This is an innocent way, of course. Funding had another approach. A developer named Feross Aboukhadijeh said that he had already spent 3,000 unpaid hours developing open source software and he wanted to see something in return. An understandable point of view.
To achieve this, he started with Funding, an experiment in which he placed advertisements in the terminals of the users of his software.
Of course, this caused a lot of commotion in the open source software world. A developer even went so far as to build an adblocker for the terminal. The turmoil was of course exactly what he wanted. He raised an important issue: how can we support the developers of the open source software?
After a few days Feross thought it was enough and he stopped the project. You can read his explanation on his blog.
Donations are still the best accepted way to make money from open source software. Unfortunately, donations are not made just like that, which is why creative ways need to be devised. For example, you can use donations to obtain extra content, “buy someone a coffee”, etc.
Many companies try to encourage you to donate, either by clearly displaying the button or by initiatives such as those of OpenCollective. One of the companies that strongly encourages donations is Fritzing, but they do so very misleadingly.
If you click on “Download”, you will not receive the download file, but will be automatically redirected to Paypal. You could then cancel the payment via Paypal to be sent back to the page, but then the Fritzing download still doesn’t load.
If you dive into the code, you’ll soon find out why. Fritzing has deliberately made sure that users who pay in this confusion, will see a different page than other users. This is the code of this form:
As you can see, the parameters “return” and “cancel_return” have two different values. This nonsense from Fritzing makes it very difficult to download this software in a normal way.
As a result, there will undoubtedly be more people looking at the alternatives to Fritzing. As the alternatives are very good, the number of users will gradually decrease. Furthermore, this will clearly reduce sympathy for the developers, which will undoubtedly reduce the number of donations in the long term.