If the free lunch is over, where can we eat for free?

In the first part of this blog post, I wrote about why FP is mandatory for programmers that work on modern software projects. Summing it up, it was like this – modern hardware scales up by adding cores, therefore, if software wants to scale up and well, then it has to do it by going concurrent, and FP is a good choice to deal with concurrent programming issues.

In this post, I’ll write about some differences between traditional and FP programming and I’ll present one more reason about why FP is a good match with parallel programming.

You can write bad code in any language. That’s a fact. So there’s no magic in functional programming to turn a lame programmer in a brilliant one. On the other hand, you can write pretty good code in the functional paradigm by sticking with the tools provided by functional languages.

So, let’s have a look at this FP thing… First, it is evident that this is not your parent’s FP – map, filter, fold… Just a few of the most recurring spells you’d see in a Scala source and none of them was in the notes I jotted down during my University courses. Even looking at my LISP textbook I couldn’t find any reference to the map operation. (Just to help those with no FP background – map (transform in C++) is an operation that applies a transformation to each item in a collection. In other words, if you have a function that turns apples into pears, then – using map – you can turn your array of apples into an array of pears.)

Read moreIf the free lunch is over, where can we eat for free?

Lambda World 2018

Back in the XVI century, the Flota de Indias based in Cadiz set out to Americas carrying tools,  books, and settlers and carried back goods, from the new world.

In much the same way I went to Cadiz and set off for the brave new world of functional programming with the intent of carrying back news and techniques for my daily job.

Cadiz is an awesome and is a wonderful frame for one the best conference I attended in 2017 and 2018 – Lambda World.

As usual, I took a lot of notes and possibly soon or later they will land here. I plan to prepare a short summary with information about the conference and briefs of the speech I attended, much I did for Scala Italy. In the meantime, I warmly suggest these awesome notes (by Yulia). Stay tuned.

Scala Italy 2018

At the end of September, my employer sent me to the awesome city of Florence to attend the Scala Italy conference. Thanks to this patronage, this is the third year I’m able to be at the conference of the Italian Scala Community.

For the first time this year, the conference lasted two days with two distinct tracks – talks and workshops. The choice of one working and one non-working day can be a bit odd and likely a symptom of some ambivalence about the target audience. To keep the conference for Scala enthusiasts attending in their spare time or to move it to the professional realm, that’s the question. Given that the ticket price wasn’t very light on pockets, maybe half of the decision has already been made.

I dutifully took notes during all the talks so I’d like to prepare some posts with my notes. I noted that after I did so for ++it 2018 (Channels are Useful, not only for Water, Zero Allocation and No Type Erasure Futures, Time Travel Debug, ++it 2018 – Coroutines – coming soon… ?, ++it 2018 – Key Notes) conference organization put all the conference videos online. I’m pretty sure the same is going to happen for Scala Italy 2018 as well. So I’ll wait for your feedbacks before investing the time needed for writing all the blogs.

Read moreScala Italy 2018

Is Functional Programming functional to programming?

Some 25 years ago I took my class of advanced programming which included exotic paradigms such as logic and functional programming.

As most of the content of that course, FP went into a seldom-if-ever open drawer during my professional career.

Simply I never saw the needs to use Lisp or had the luxury to afford never changing values.

A few years ago (well not that few – just checked it was 2005) I read on DDJ that the free lunch was over. That has nothing to do with the charitable food bank, but it marked a fundamental twist in the computer performance evolution. Something that would have a strong impact on how software was going to be designed, written and tested.

Until 2005 no matter how your code was badly written and underperforming. You were assured that for free, just waiting for the next hardware iteration, your code would have run faster (bugs included)! This is like deflation in economics – why should I invest my money if keeping them in the matters for a year they increase their value?

Read moreIs Functional Programming functional to programming?

++it18 – Channels are Useful, not only for Water

High performance computing made quite some progress lately. Maybe you heard about the reactive manifesto (you should if you are a reader of this blog ;-)), if not, it is an interesting readying … if nothing else as a conversational icebreaker.

Basically the manifesto preaches for systems more responsive and reliable by reacting to requests and dusting it into smaller requests processed by smaller and autonomous systems. This is nothing new, but quite far from traditional processing where single monolitic application took care of requests from reception to response.

There are several programming patterns useful for implementing a reactive system, channels (and streams which are quite the same thing) are one of them. A channel allows you to define a data flow with inputs, computation units, merge, split and collector of information coming in sequence into your system. Once the dataflow is defined, the data flows into it and results come out from the other end.

In this talk Felix Petriconi describes his implementation of channels for C++.

Read more++it18 – Channels are Useful, not only for Water

Protecting you from danger

One of the interesting features of Scala is the trait construct. In Java you have interfaces, a stripped down class that lets you express the requirements for classes that implement it to have a given … interface. Just to keep this from an OO perspective – in a certain system all MovableObjects, must expose an interface to retrieve, say, position, speed and acceleration:

interface MovableObject {
    Point getPosition();
    Vector getSpeed();
    Vector getAcceleration();
}

class Rocket implements MovableObject {
    public Point getPosition() {
        return m_position;
    }

    public Vector getSpeed() {
        return m_speed;
    }

    public Vector getAcceleration() {
        return m_acceleration;
    }
    private Point m_position;
    private Vector m_speed;
    private Vector m_acceleration;
}

In Java the interface has no implementation part, just a list of methods that heir(s) must implement. This is a way to mitigate the lack of multiple inheritance in the Java language – a class can inherit at most from a single base class, but can implement as many interfaces as needed.

Scala traits are different in the sense they can provide an implementation part and fields. Now that I read the wikipedia definition, it looks like that traits are a bit more mathematically sound than interfaces (that’s what you can expect in functional language). Anyway, in plain English, traits are very close to C++ base classes (with some additions that is stuff for another blog post) in the sense that you can both require interface and provide common functionality.

Read moreProtecting you from danger

++it18 – Zero Allocation and No Type Erasure Futures

This talk by Vittorio Romeo tackles a subject that could go ignored if your programming style doesn’t feel the need for parallelism (or if it does, pthreads satisfies such a need). Futures have been introduced in C++ with 2011 ISO standard, they hardly can be deemed as novelty.

I’ve been hit by futures some 4 years ago when confronted with a large code base in Scala that exploited futures and actors. So, at least to save my ego, there is nothing wrong if you don’t know what a future is :-).

In brief a future is a way to model a concurrent operation. The future can be either in execution or succeeded with a result value, or failed with an error. As user, you request an async operation and you get a future of the expected result. You can set callbacks on the completion, or combine several futures together either by chaining or by synchronize them. As you may imagine futures vastly simplify the handling of async computation by hiding the synchronization and communication details and by providing a common and clear usage pattern.

So, no excuse, if you need to do async programming, you’d better know this tool.

Read more++it18 – Zero Allocation and No Type Erasure Futures

++it18 – Time Travel Debug

This talk presented a very interesting object – the debugger the could go backward.  But I don’t want to steal the scene, since Paolo Severini from Microsoft explained everything quite well in his talk. Here you can find the slides. Nedless to say errors are mine.

Everyone knows that debugging is twice as hard as writing the code in the first place. So if you’re as clever as you can be when you write it, how long will it take to debug it?

Debugging could be both hard and time consuming. Bugs can be difficult to replicate, especially those involving memory corruption, race conditions, or those that happen randomly or intermittently.

More often than not, it can be hard to spot the cause from logs or crash dumps. Also step by step debugging may require several restarts.

When doing step-by-step debugging is quite common something like:

step into, step over, step over, step over, step ov.. @!# I should have stepped into!.

The more information we can get from debugging tools the better. A tool that could tell “what just happened” would be very very useful.

Reverse debugging is such a tool. The idea is to record state by state everything happens in the CPU that’s executing the code and then the reverse debugger allows the programmer to play back and forth to spot the problem.

First ideas of such a tool dates back to 70s [NdM. I keep noticing that most of the computer science has been invented back in the 60-70s years. They just lacked the CPU resource for practical applications].

There are several tools for reverse debugging native code:

In this speech I will present TTD.

TTD is the reverse debugger for Windows. It is fully integrated with WinDbg. TTD can be used for all user-mode processes, for multithread and multicore

In order to use TTD, you need to set WinDbg to record data. This option needs to be explicitly enabled since has two main drawbacks – first all the program execution is slowed down and then quite a large amount of data is produced. You can expect anywhere between 5 and 50 Mb/s.

After recording has started, debugging works as expected, plus you can step back and forth and also continue backward or forward.

Take note that TTD works only in the latest versions fo Windows 10.

Interestingly you can perform queries on data collected during execution. Every line in the database matches an assembly instruction executed. So you can query how many times some instruction has been executed, how many exceptions have been thrown and so on.

[NdM: A working demo follows, unfortunately the time is quite constrained. A sample program to recursively compute the byte size of file in a directory tree is presented. The program just crashes when executed. So it is executed in WinDbg with TTD enabled. The execution halts as usual in the middle of exceptionland where nothing can be understood unless you speak advanced assembly. By pressing back a couple of time the debugger, going backwards, reaches the last function executed, the one who crashed. At this point Paolo places a breakpoint at the beginning of the function and – with a good implementation of the WOW effect – runs the program backwards. The execution back-reaches the function beginning and can be step forward to better understand why it crashed]

The presentation has been very interesting to show the tool capabilities. I tried an evaluation of UndoDB back in 2006, but it was as uncomfortable as it could be since it had to be used from command line. WinDbg+TTD is light years ahead in terms of usability.

Also I found very interesting the data query feature. Having the db of the program execution states allows the programmer to get a number of important statistics and events without the need of adding instrumentation or specific breakpoints.

The drawback is the execution time, but I guess that without a specific hardware support this is the price we have to pay still for some time in the future.

++it 2018 – Coroutines – coming soon… ?

I really enjoyed this talk and not only because the speaker is an old friend on mine. I met Alberto back in the Ubisoft days and he was and still is one of the best C++ programmers I know and for sure the only friend who submitted a proposal to the standard committee that got approved. On the other hand I have no friends who submitted a proposal to the standard committee that was refused. So all my friends who submitted… well I’m digressing.

This talk was in Italian, that is welcome, but… weird. Usually all talks are in English even for Italian conference. Anyway here’s my summary, as usual errors and mistakes are mine. You can find Alberto’s slides here.

Coming Soon to a Compiler Near You – Coroutines

Alberto is a C++ enthusiast programmer since 1990. In this hour he’s going to talk about coroutines, their history and their relation with C++ and C++ Technical Specifications (TS).

A suspend and resume point is a point in the instruction sequence where the execution can be suspended, other stuff is executed and then the execution is resumed from there.

The most common form of suspend and resume point is a subroutine call. The execution is transferred from the caller to the callee and when the callee is done, the execution is transferred back to the caller.

Coroutines are a generalized form of suspension and resume points, that allow you to manage where you want to suspend, transfer control and resume, without be constrained in the caller/callee format.

When is this pattern useful?

Read more++it 2018 – Coroutines – coming soon… ?

++it 2018 – Key Notes

Saturday 23 June 2018, was a sunny day in Milan. The ideal day to close yourself in Milano Bicocca University with many equally nerdy fellow programmers to attend the Italian C++ conference.

I discovered this conference, now in its 3rd edition, by chance, skimming through my neverending queue of unread tweets. A friend of mine and C++ guru twitted about this, so I bookmarked the website and as soon as this year edition was announced I was one of the first to register.

Also it is worth noting that this conference is free (as in beer), lasts a full day and includes the lunch. Talks are interesting and the conference is organized in two tracks with a single starting keynote and a single closing speech.

Although free, there are famous guests – last year Bartosz Milewski – quite a famous functional programmer and category algebra expert – held a speech about C++ and functional programming; this year the keynote was by Peter Sommerlad — C++ expert and member of the C++ ISO committee.

As usual my good intentions are to write and publish about each single talk I attended to.

Comparison with other conferences I attended, such as Scala Days, Scala Italy and Lambda World, is natural, although not always fair – ++it is completely free, while others come to a price (not light in case of Scala Days). I couldn’t fail to notice that age on average was older here than in the functional world. I won’t try an interpretation, but there could be more than one.

But, enough with babbling, let’s start with the keynote (based on my notes taken during the talk, errors or misunderstandings are just mine). You can find Peter Somerlad’s slides here. My comments at the end.

A – B – C : Agile, BMW, C++

In this talk prof. Somerlad basically tells about his professional career, era by era, providing a short list of lessons learned for each period.

He started programming on a HP pocket calculator. This device had some 50 steps of program instruction and no graphics whatsoever. Also TI calculators were more widespread at time, so he had to translate programs from one programming language to another one. Although very similar (they were all stack based) each calculator had some peculiarities.

One program he developed for fun was a ballistic simulation – define a force and a direction to fire a bullet that has to avoid a wall and hit a target. As said, the pocket gizmo has no graphics, but years later, the very same idea was re-instantiated with some graphics and sounds to become… Angry Birds.

Lessons learned:

  • Mentally execute code – there was no debugger;
  • Using the stack;
  • Reading foreign code (to translate from TI to HP);
  • Porting code;
  • Old simple ideas reamain useful.

The first home computer was a ZX Spectrum – an 8bits computer with rubbery keyboard that connected to a TV set and used a cassette recorder as mass storage. Each key was decorated with several keyword beside the standard letter and symbol you normally find on a key. When pressing a key, depending on the context, one of such a keyword appeared on the screen – automatically typed for you. Context was determined by pressing two shift keys. The correct combo produced the required effect.

At school he worked on a mainframe, that had a curious assembly language. Notable one instruction, by exploiting an indirection bit, could be used to create an infinite loop. He and another one student tried the instruction and the mainframe froze. After few seconds an angry System Administrator entered the room, asking them to quit what they were doing.

Lessons learned:

  • Basic, Z80 assembly and machine code, Pascal;
  • Keyboard shortcuts and meta layout;
  • Patience (loading from tape takes forever);
  • Dealing with errors from hardware.

In 1985 he landed his first job where he had to write a kind of customer management application on an Apple IIe. Now the software had to be professional and one requirement was that a cat could walk on the keyboard without causing a crash of the application. At times no commoditized databases were available and the few db engines available were very expensive. Since the Apple IIe had floppy discs, they may have to merge the two databases on two discs. The solution is to employ a merge sort, so he took the book from Niklaus Wirth “Data+Functions=Algorithms” and copied the merge sort implementation. Unfortunately the merge sort algorithm on the book was not stable, so Peter had to rewrite it from scratch.

Implementing the DB was quite a nightmare for many technical constraints – computer memory, mass storage size and computing power. The PC was an IBM with MS-DOS 1.x. This version had no directories. The Pascal language had no dynamic strings – they had to be statically sized.

As computer technology progressed he switched to a 386 compatible and turned to minix. During this period, Peter used PMate – an editor that sported macros, so that statement frames could be automatically generated.

Lessons learned:

  • do not trust programming books and commercial libraries;
  • before putting code in your book, always compile and test it;
  • programming should be supported by fast and powerful editor;
  • you should not need to type all of your code;
  • generic data driven solution make code simpler
  • automate tests.

1987 C and Unix courses

During this period Peter started teaching classes about C and Unix. In this classes shell, system programming and C were taught. Also he had to teach how to unlearn things to Cobol Programmers.

In 1988 he wrote some C guidelines – some are still actual today:

  • a function is too long if it does not fit in a 80×24 terminal; functions with longer code tells a failure in teaching software engineering.
  • a function should not take more than 3-5 parameters, if you need more, then you have to logically group them in struct. Windows API had function with 7 or more parameters, that why Peter swore never to program this OS.
  • Everything is an int, unless it is a pointer or a double. (The reason why we need to use the typename keyword today is a legacy of this choice made by K&R).
  • Program abstract data types using opaque structs and pointers.
  • Do not use scanf() ever in production code, use sscanf() instead and check its result.

Lessons learned:

  • K&R C, Unix, sh, awk, sed, vi, nroff, make, lex, yacc,…
  • You learn the most by teaching.
  • One can program in fortran/basic/cobol in any language.
  • abstraction, layering, cohesion.
  • the power of plain text, regexp, pipelines and scripting. Searching log files for what went wrong.

In 1989 Peter graduated. His master thesis was about a Modula-2 frontend for the Amsterdam Compiler Kit. In this year, also the first experiments with C++ using the Zortech C++ compiler. Writing code with this environment was quite intensive since any error in the code caused the whole machine to die. These were days before Protected Memory.

Lessons Learned:

  • Compilers and AST with polymorphic nodes (polymorphism via union);
  • Virtual Machine Languages (p-code, em-code). Java bytecode is very close to em-code;
  • more RAM and CPU power make compilation much faster;
  • ADT works even within a compile;
  • lex and yacc can be used in practice.

Conscript at Bundenswehr (the German Army). Peter worked in the Computer Center, on systems for Radar detection and analysis. This was quite a travel back in time. The computer was an 18 bits with core memory, switches to input bits into the main memory and tape for mass storage.

Also Peter found another computer history milestone – the VT100 terminal. This terminal defined what ANSI escape codes are today.

The language used for programming the system was Jovial a mix of pascal and algol that was later replaced by Ada.

Lessons learned

  • Computer and software history can be interesting;
  • Even hardware can be used beyond its expected lifetime;
  • source control is important (and copying floppy disc is not source control)

In 1990 he landed a job at Siemens and started working in OO programming environment. Here he worked with Erich Gamma and Andrè Weinard [NdM: I tried to look up this but haven’t found anything relevant, maybe I got the name wrong].

The system Peter was working at was a framework for C++ written in C++, named OOPU, intended to replace TOROS_OBER a C macro based OO system used for car diagnostic computer. Unfortunately OOPU was killed by internal politics. The reason was that a single programming environment had to be used across several business units, and other business units didn’t want to pay for it.

In this context Peter wrote an object inspector, named OBER, that showed the relations among objects (this was before DDD was invented). From architectural point of view this application sported an UI separated from the backend.

In 1991 Peter wrote the first C++ guidelines, although some are still applicable, many are obsolete because the language evolved and things can be done better.

1993 was the year of the PLoP (Pattern Languages of Programming), this was still before the Gang of Four Book. In this conferences many opportunities wer to learn and understand architecture by trying to explain patterns.

1995 is the year of GoF. The most important design pattern are:

Do not use the singleton since C++ has no fixed sequence of initialization. If you need singleton, think about design first. If you need globals, just use globals [NdM, I understand that singleton has some problems, but I don’t see what is the alternatives – globals lacks of encapsulation].

In PLoPs and EuroPLoP, patterns had a community, where knowledge was shared, and it offerd an environment to try out ides. Discussing how stuff has to be written and why.

With other participant of the PLoP/EuroPLoP, Peter wrote the book POSA – Pattern Oriented Software Architecture. This is less famous than Design Pattern by the Gang of Four, but tackled the same matter.

Layers vs. Tiers -Layers are different level of abstraction , you can swap a layer implementation with another; while in tiers, functionality spread on multiple tiers, all the the same level of abstraction employing different technologies.

Using layers the team can specialize, while using tiers the team needs to know everything.

Good abstraction is a skill. Too many layers are a problem if layers do nothing but pass values.

Lessons learned:

  • A prophet has no honor in his own country – get out to be heard;
  • good patterns require several rewrites;
  • Sharing teaches you to become a better author;
  • Get a good copy editor, when publishing;
  • Network to learn – attend and speak at conferences;
  • most important part of a conference are the breaks.

In 1997 he moved to Switzerland to take the job of Erich Gamma, more precisely to work on a small server framework www.coast-project.org. While in charge Peter extended and improved the library and developed C++ Unit Test and test automation in doing so. He delivered high-quality solutions using Agile Software development and Wiki wiki web.

In these years Peter came to some interesting conclusions about high quality software. First high quality leads to better developer and better retainment of those developer. Unfortunately high quality leads to canceled maintenance contracts. If nothing goes wrong, the customer doesn’t see the point in paying for something that is never used.

Also, counter intuitively, high quality leads to less business opportunities. Since the contacts between customer and developer are minimal and usually don’t escalate to top level management. So the developer has less chance to meet and know the decision makers of the customer company.

Also CUTE – the test environment – has been created to replace macro-ish test.

Lessons learned

  • to advance you need to take risks;
  • do not be shy to use your network;
  • if you can not change your organization change your organization;
  • leading a team and evolving it is gratifying
  • producing software with a superior quality might be bad for business
  • working software lives longer than intended.

1998 and Agile Development. It became evident that following rituals is not adhering to values. You can do all the scrum rituals, but without committing to its values. When doing agile the most important things are:

  • Unit Tests and TDD;
  • Refactoring and Simple Design;
  • Rhythm and feedback, i.e. thinking about what you do and what you achieve;
  • Open and honest communication.

Lessons Learned

  • be self sufficient, but accept and appreciate help;
  • as a patient you are responsible for yourself.

Since 2004, Peter started teaching agile and continued teaching C++, concurrent and network programming. Also started working on IDE and tools, with the goal to eliminate bad software.

In 2005 many people thought that refactoring tool for C++ was impossible to write. Peter worked to prove them wrong, and Cevelop is the result.

[NdM: The talk ran out of time about now.]

My comments

Despite being sympathetic with Peter, since we shared so much in terms of computer history, programming and software engineering, I have to admit that his talk didn’t leave me with much. Also I fail to see the lack of some self-celebration. Maybe the most interesting thought was that quality software leads to less business. The rest of the talk was enjoyable, but I couldn’t see the connection with C++ or the future (or the history) of this language.