Wednesday, January 24, 2018

Important programming languages to learn (a break from C++17 and friends)

A break from C++17 and friends. If I had to name the programming languages that are important to learn I would include LISP somewhere near the top of the list (no pun intended). One thing that speaks in favor of LISP is the fact that learning it will develop your programmer mind in ways that other programming languages will not. The other factor in favor of learning this language is the doors it will open for you. Armed with your knowledge of LISP you will be able to use a great number of good tools and platform. In Linux for example there is a large number of implementations available (Steel Bank Common Lisp, GNU Common Lisp and possibly others). LISP is also available on the Java VM in the form of Clojure, ABCL, KAWA (a Scheme) and possibly other implementations. For a few years now Lisp is also an option when programming for the Erlang VM as LFE (Lisp flavor Erlang). Erlang has a Virtual machine (BEAM) that has interesting characteristics and is certainly worth taking a look at. However, Erlang (the primary language for this platform) is not a language that has the same availability as Lisp so learning Erlang might be considered too large an investment. Fortunatly with a dialect of Lisp available you now have an interesting alternative. Here is me fooling around in the Erlang LFE REPL:
Erlang R14B04 (erts-5.8.5) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]

lfe: (set mytuple #(1 "Winston Churchill"))
#(1 "Winston Churchill")
lfe: (element 1 mytuple)
1
lfe> (element 2 mytuple)
"Winston Churchill"
lfe: (defun nth (n atuple) (element n atuple))
nth
lfe: (nth 1 mytuple)
1
lfe: (nth 2 mytuple)
"Winston Churchill"
lfe: (defun doubleit (x) (* 2 x))
doubleit
lfe: (doubleit 2342342342)
4684684684
I create a tuple and peek at the values inside using the 'element' function. Since 'element' feels a little long I define a function named 'nth' to mimic a function available for List in other Common Lisp implementation, I also create a simple function 'doubleit'. Here is me fooling around in the GNU GCL REPL:
GCL (GNU Common Lisp)  2.6.7 CLtL1    Feb  1 2012 09:07:26
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

::(defvar *mylist*)

*MYLIST*

::(setf *mylist* '(1 "WInston"))

(1 "WInston")

::(nth 1 *mylist*)

"WInston"
>>(nth 0 *mylist*)

1
::(defun doubleit (x) (* 2 x))

DOUBLEIT
::(doubleit 4598349)

9196698
Clojure alone is enough of a reason to learn Lisp. Even more so now that Clojure Script is available.

Friday, January 5, 2018

Fooling around with C++17 (part 1)

New years resolution

In 2018 I will be back writing post here and I will try to be more consistent. I will eventually go back to the subject of 'dynamic like' Java programming but just for fun I will start the year by looking at C++17 (including x14 and x11) C++ is starting too look like a 21 century programming language so I think it is well worth looking at a few features that are starting to make programming really more productive. WARNING: this is not a C++ style guide.

auto this, auto that

C++14 and 17 extend the power of auto and really make it more productive. In C++11 they added the posibility of using auto for the return type of functions but you still had to provide the type using the new arrow syntax. In C++14 they completely removed the need to explicitly provide the type. Here is an example with both syntax:
class LazyCoder
    {
    public:
        auto get_it_Cv11 () -> int
            {
            return 11;
            }

        auto get_it_Cv17 ()
            {
            return 17;
            }
    };
I don't think this is the best use of auto since the type in function declaration is also good documentation (better than comments). In C++11 you could use auto for local variable declaration, for loop variables, function parameters. With C++14 and C++17 you can now also use auto when declaring a variable in the scope of an 'if' and also when doing structured bindings (similar to other languages 'destructuring')
    // Create a tuple
    auto tuple = std::make_tuple(3, 7);

    // C++14
    int i, j;
    std::tie(i,j) = tuple;

    assert (i == 3 && j == 7);

    // C++17 (look ma, no explicit variable declaration)
    auto [x, y] = tuple;

    assert (x == 3 && y == 7);

    // and then ...
    if (auto t = (x != y))
        {
        // I can use t here
        cout << "This is getting ridiculous like t=" << t << endl;
        }
C++z17 has one more trick up its sleeve. The 'structured binding' works with user data types.
    // I have this struct defined somwhere
    struct Zmas
        {
        int z, w;
        };

    // Now I can do this:
    Zmas zmas {7, 11}; // Uniform intialization with curly brackets (next post)
    
    // The number of items between square bracket here must match the number of public 
    // members of Zmas
    auto [z, w] = zmas;

    assert (z == 7 && w == 11);
Of course C++11 addition of auto was already a major improvement when working with complicated types but the latest extensions are even more icing on the cake. For more details about auto check out C++17 Structured Bindings

Sunday, January 17, 2016

Dynamic like programming with statically typed Java.

It's been a while since I posted anything here. These days I'm working on a Java project where I have made a lot of good design choices. A lot of those ideas turn around the concept of using a "dynamic like" programming style with a statically typed language. When you think about it, a lot of the flexibility and power that comes from using dynamic languages comes from using APIs where Maps and Tuples are often used in some places where a statically typed language would use classes. Of course, dynamic languages often have syntactic support for Maps and Tuples that greatly simplify using them. Still, in the comming series of post I will show how Java programming can benefit from a more widespread use of Maps and Tuples. I'll show how using some well known pattern can help compensate for the lack of syntactic sugar.

Saturday, November 8, 2014

Nothing beats Bash scripting for file manipulation

One of its strength of course is that it comes standard with most Linux distro. You can also have the power of bash scripts under Windows using Cygwin. A powerful element of bash scripting is its capacity to use external utilities like AWK or SED.
I use AWK a lot so let me share with you a way to integrate AWK script in bash scripts without having to use separate files. Here is the simplest way I found:

1) Put the script in a variable using cat and heredoc

vtest=$(cat - <<-'_EOT_'
    /^[ \t]*package[ \t]+[a-zA-Z_]+/ {
        print $0
    }
    /^[ \t]*import[ \t]+/ {
        print $0
    }
    {}
_EOT_
)
Simply feed the heredoc to cat and then put this in a variable using command substitution. Don't forget the single quotes around the _EOT_ at the top.

2) Feed the script to AWK using a redirected echo expression as if it were a file (-f).

awk -f <(echo "$vtest") file_to_process

In this case here, notice the use of double quotes around the variable to preserve the end of line and other formatting info. I use this if the AWK scripts gets complicated enough and readability becomes a factor. Of course you don't want to abuse this by putting really large scripts inside variables. In my example the script was made meaningless by removing a few lines for simplification but because of the nice formatting with heredoc you can still clearly see that both the java package and import statements received special treatment (the script was used to process Java source files).
What do you think about this trick ?

Wednesday, October 15, 2014

Next step selecting an alternate programming language

Ok it's down to ADA or Object Pascal (the Free Pascal compiler). I still have to check the license for FP in more details but it looks good. Two languages that have compilers on several platform and libraries to go along. I have worked with Turbo Pascal and Delphi years ago and the Free Pascal version of the language is a very close clone of Delphi so the learning curve should not be too bad. I have played a little with ADA and so far I think the language has very interesting features. I might actually start a more detailed thread about my ADA experimentations. What do you think ? Does anyone out there have any comments about either language ?

Tuesday, August 19, 2014

Separating the user interface form the rest of the code

Before I go back to my exploration of alternate programming languages a short one on design (or is it management ?). Every programmer knows that when you write code that might eventually get used in a GUI application a basic good practice is to always clearly separate the GUI code from the code implementing the actual functions. No big news here. There are a lot of tricks and design principles to help towards the goal of keeping things separate and of course any decent programmer should know about design patterns like MVC. Unfortunately, good design principles can be ignored or neglected if someone else is writing the actual code and additional control mechanism are needed (even you might benefit from additional safeguards). Code reviews can help. Automated unit test will also often help by encouraging developers to encapsulate and write more focused classes. Today's design or management trick is:
- Ask the programmer to write the functions in a separate module (module A)
- Ask him to provide a command line utility (module B) to call the functions in module A
Of course this does not provide an absolute protection against bad programming but it adds another level of control. This can be similar to what automated unit tests provide but not exactly the same since:
- It is fairly easy to check that module B uses A but not the reverse (no circular dependencies). You might not have the same level of isolation for the unit test code and the tested code.
- It is more focused on separating the two parts of the code. The part that implements the user interface (command line for this part of the project) from the part that implements the functions.
= The end product will often be a useful deliverable (this is the best application of this trick)
Of course writing a command line utility should not remove the requirements for automated unit tests.
If the result is not perfect, you or the other programmer doing the work will get another shot at cleaning up the API of module A when the time comes to use the module with the GUI. What do you think about this. Do you have any tricks to help you use good design principle ?

Sunday, August 17, 2014

Escape from the land of C (prologue)

Ok. I'm having a look at ADA. One of rare languages that actually was compared to the aberrant C language to compare productivity. More in my next blog.