Blog

I created an android app named "Chords+ Music Tools" back in 2011-2012, which provided computational chord fingerings, a reverse chord calculator, a simple calculator that taught you what chords were in what keys, and a scale calculator that showed you how to play different scales all over the fretboard (really for any fretted instrument from 3 - 8 strings, but targeted for guitar, ukulele, mandolin).

I ended up letting the android app lapse from the app store, but decide to bring the functionality over to my new website https://chords.plus and add some new features as well.

I think it's a helpful set of tools for musicians!  Helps you find different fingerings and ways of playing things that you might not have thought of otherwise.  

One thing that I'm experimenting with this time around, is using a simple self-trained neural net to sort the chords by ease of playing and quality of fingering.  I implemented a little tool that I used to provide my preferences when presented with a number of different chord fingerings, and then trained a simple neural net on it.

In the "Advanced Settings" block on the chord calculator page, you can choose which algorithm to use

I think usually the MLP strategy is better than my hand-written heuristic algorithm, but I do think there is some room for future improvement here.  May try a Convolutional Neural Net approach to see if that helps it pick up desired/undesirable relationships between strings better.

I do not think this is an original thought.

But it seems to me that javascript (and the ecosystem around it including typescript and node) has evolved to fulfill Java's original promise better than Java ever did.

In the introduction of the whitepaper "The Java Language Environment" [link] , written by James Gosling and Henry McGilton in 1996 ( the same year as the introduction of Java 1.0), Java is marketed with the following section

The Better Way is Here Now

Now there is a better way -- the Java ^TM programming language platform from Sun Microsystems. Imagine, if you will, this development world...

• Your programming language is object oriented, yet it's still dead simple.
• Your development cycle is much faster because Java technology is interpreted. The compile-link-load-test-crash-debug cycle is obsolete--now you just compile and run.
• Your applications are portable across multiple platforms. Write your applications once, and you never need to port them--they will run without modification on multiple operating systems and hardware architectures.
• Your applications are robust because the Java runtime environment manages memory for you.
• Your interactive graphical applications have high performance because multiple concurrent threads of activity in your application are supported by the multithreading built into the Java programming language and runtime platform.
• adaptable

I wrote an article back in 2015 entitled The Case for Lisp .  It lays out a simple argument, founded on expressiveness, for choosing Lisp.

Now I would like to lay out some reasons why one might not choose Lisp for a project. Focusing on Common Lisp for this article.

1. The very s-expression syntax which enables structural macros which gives lisp some extra expressiveness power vs most other programming languages, also serves to make the code harder to read for the vast majority of people. Perhaps the flexibility of s-expression syntax is overweighed by the increased cognitive overhead required to read the code.  Even after I spent quite a lot of time reading and writing lisp over a period of several years, I would still find it a bit more challenging to read lisp code than to read, for example, java code.
2. I think in the age of autocomplete and ide-assisted coding, lisp's OOP model and function comes before object mentality is less ergonomic than the dominant object.method paradigm.  Consider `(bark dog)` vs dog.bark() to see what I mean.  The latter syntax is extremely amenable to autocomplete in an IDE and provides some "namespacing" to the bark() method where it won't pollute the global autocomplete context but instead only comes up in the context of the dog object.

I wanted to compare the FFIs of a few popular programming language to evaluate 1. the ease of use of the FFI functionality and 2. their minimal overhead in a hot-loop scenario. I chose java, c#, php, and golang for my experiment.

This is in no way representative of FFI usage in the general case -- just indicative of overhead of calling a minimal function.

The code for this experiment is here: https://gitlab.com/vancan1ty/ffihotloopexamples .  The JNI code was based off of this github repo by RJ Fang: https://github.com/thefangbear/JNI-By-Examples .

All tests are run on my Dell Precision M4800 laptop. I evaluate three scenarios across several languages.

Scenario 1 is as follows -- we loop up to LOOPMAX --  which I set to 2000000000L -- and perform a few simple operations including a bit of modulus arithmetic and conditional logic to keep the loop from being unrolled by the compiler.

        Utilities util = new Utilities();
        long st1 = System.currentTimeMillis();
        long counter = 0;
        while(counter < LOOPMAX) {
            counter = util.addOne(counter);
            if(counter % 1000000 == 0) {
                counter = counter + 10;
            }
        }
        long et1 = System.currentTimeMillis();