Bash should have been the greatest scripting language of all

The scripting Balkans

You cannot invoke functions contained in a script written in Python in another script written in Node/JS. So, what are we going to do? Are we going to rewrite these functions in Javascript? No, because the idea was to reuse someone else’s work in ours. Therefore, I am usually not going to waste my time porting Python to Javascript or the other way around. The solution is therefore to call the Python script as an external program in my javascript script. Instead of writing:

y = f(x1,x2)

We will write:

y = exec(“/usr/bin/prg -func f -arg1 {x1} -arg2 {x2} “)

(Note that the string interpolation in the exec function should obviously escape the shell arguments correctly.)

External process execution is a solution, not just to the scripting Balkans, but to the entire programming Balkans. It does not matter in which language the program prg was written. Every programmer can use his own preferred programming dialect, while we can still reuse his work. As long as the program executes a meaningful amount of work, process/program chaining is very usable substitute for function chaining.

Therefore, Bash has its fundamentals right, by providing at the heart of the language the process chaining primitives that facilitate code reuse of external programs.

What is wrong with Bash

Its horrible syntax for strings, lists, and tables creates a programming nightmare:

echo ${#stringZ}

Yes, it does something, but I guess that you cannot guess what exactly. It does the same as what the following would do:

echo strlen($stringZ)

echo $stringZ.length()

Now you probably guessed correctly what it does. So, yes, Bash certainly wastes our programming time by forcing us to endlessly Google for what its horrible syntax means. Instead of doing something useful, we are now supposed to look up what its diarrhea of punctuation mess is all about:

for sound in “${!animals[@]}”; do echo “$sound – ${animals[“$sound”]}”; done

The syntax above is truly abnoxious. Close your eyes and try to write down that statement again. When they designed this mess, did they really  believe that people have no better things to do than to remember that kind of trash? This kind of syntax is totally disrespectful of the users and their precious time. Furthermore, there is absolutely no need to do it that way. No other scripting engine forces you into that kind of mess. So, they can’t say that there is a compelling reason for this, can they?

How much punctuation mess do we need before all our needs for punctuation mess have completely been satisfied?

Another problem is that the user-defined functions in Bash cannot return something like a table or a list or even a string. We do this all the time in other scripting languages. Therefore, the excuse cannot be that the user should not want to desire to do this. He does it elsewhere already and successfully so!

Besides that, there is also no way to load native foreign functions (FFI). Users do this all the time in other scripting languages. So, again, they cannot argue that there is no need for this. There is obviously a real need to do so, while Bash does not allow it.

Bash is a GNU project

Like in all other GNU projects, there is no real user community around Bash:

http://www.gnu.org/software/bash

The GNU project does not want to use infrastructure such as github — which is understandable — but they do not use any alternative either. They use a mailing list. That amounts to systematically sending the entire issue list to all users, even if they are interested in just one single issue. Mailing lists generate too much noise. Users do not like them.

The Bash documentation does not contain user comments. There is no user interaction there either. In theory, users would be encouraged to explore the GNU sources, as these sources are supposedly licensed under the GPL, but in practice these sources are also exceedingly difficult to find and manipulate!

The GNU project could impossibly be listening to their users, because with what infrastructure exactly would they be doing that?

Furthermore, if you ever manage to talk with Bash maintainers — just try to get hold of someone and you will see what I mean — you will understand that they are impossibly conservative. They seem to think that the existing Bash implementation is pretty much what it should be. There is surely no need to fundamentally improve it!

Conclusion

In order to tap into the wealth of existing external code, it is necessary to favour process chaining over function chaining in that context. It opens the door to reusing way more source code than just sticking to your own scripting language. In the internal context of our own programs, however, there is no need to do that. There we need first-class functions. Unfortunately, Bash does not have them. Furthermore, Bash suffers from the same self-inflicted source code readability issues as Perl. This problem — understandably — turns Bash into a non-starter for many programmers. All the syntactic noise and punctuation mess could easily be replaced by functions, just like in other scripting languages. In short, we need a shell scripting language that avoids these pitfalls.

Advertisements

Bitcoin regulations could only ever apply to bitcoin-fiat exchanges

Bitcoin regulations are possible and even realistic for centralized exchange platforms, such as for example bitstamp, virtex, or kraken, that send and receive fiat money through the banking system.

Regulation do not necessarily reach peer to peer exchange platforms (p2p). Since such p2p platform relegates the actual exchange to the two individuals selling and buying, it does not perform regulated acts itself. Concerning the two individuals trading, there are no regulations that apply across the globe to individuals trading from their own country.

But then again, the fiat to bitcoin exchange is not the essential bitcoin act.

The essential bitcoin act takes place when the bitcoin miners decide to add a signed bitcoin transaction to a block and decide to store this block in the blockchain.

The bitcoin miners apply pre-established rules when performing their core job and do not listen to anybody at all while doing so.

No regulator on the globe, in any of its 200+ jurisdictions, should ever hope that the cryptocurrency miners would listen to him. If a majority of any cryptocurrency mining community ever did so, its users would immediately repudiate their miners and join an alternative cryptocurrency. It would definitively crash the value of the cryptocurrency and effectively destroy it.

Regulators should understand that something like bitcoin only has value, exactly because its miners do not listen to them. In other words, the true, unique selling proposition of bitcoin lies exactly in the fact that regulators are being neutralized. Without regulators, there would be no need for bitcoin, and therefore bitcoin would not even exist.

What is money

According to Wikipedia:

Money is any item or verifiable record that is generally accepted as payment for goods and services and repayment of debts in a particular country or socio-economic context or is easily converted to such a form. The main functions of money are distinguished as: a medium of exchange; a unit of account; a store of value. The money supply of a country consists of currency (banknotes and coins) and, depending on the particular definition used, one or more types of bank money.

In terms of David Hilbert’s Entscheidungsproblem, a definition should allow us to implement the predicate function isMoney(x) that will return true if x is money or false if it is not. As usual, the Wikipedia definition is only weakly predicatable. I do not say that the definition is wrong, but the definition is still unsatisfactory, because it is not readily usable for the purpose of computation. It is just not effectively computable. In other words, for many otherwise valid purposes, this definition must be considered to be useless.

Let’s say that the following alternative definition of money is not necessarily more correct, but rather more decidable and more computable.

Say that our person knows about n different products, numbered from 1 to n. Our person can trade in these products. This establishes the function tr(x,i,j) = y, where our person can trade x units of product i and in the best case receive y units of product j. This allows us to further establish the roundtrip trade losses function rtl, defined as: rtl(x,i,j) = tr(tr(x,i,j),j,i)) If our person trades x products i for y products j, and then trades back these y products j, he may receive only z products x back, incurring a loss of x – z.

Here we assume that when an arbitrarily-chosen person buys an arbitrarily-chosen product and sell that product back, this person will most likely incur a (roundtrip) loss. This is not always the case. Wholesalers, for example, will buy a product and sell it to retailers, expecting to make a profit.

In order to make the losses comparable, we will express them in proportion to the amount of product traded. The proportional roundtrip trade losses prtl for product x, when traded for product y, are: prtl(x,i,j) = (x – tr(tr(x,i,j),j,i)) / x.

Now we can finally attempt to define money. If for any quantity x, for a given product k and a given product l, the roundtrip trade losses ptrl(x,k,l) are smaller than the roundtrip trade losses ptrl(x,i,j) incurred for any arbitrarily picked product pair i,j, then k or l is a currency (or both are currencies):

∀ x,i,j ∈ N, 1<= i,j,k,l <= n, ptrl(x,k,l) <= ptrl(x,i,j) => isMoney(k) or isMoney(l)

From there we can classify products as currencies or non-currencies. If the distance between their best proportional roundtrip losses and the average (or median) roundtrip losses is smaller than the distance to the currency pair, then they are non-currencies.

You can verify that what we conventionally consider to be currencies have indeed very low proportional roundtrip losses, especially when traded against another currency. According to the metrics established by the definition proposal in this article, bitcoin is unambiguously a currency.