my other home
Here we go again, another system
According to Wikipedia, GC (Garbage Collection) was invented back at the dawn of computer science, (ca 1959) for the LISP language. Since its inception, GC made promptly clear that it didn’t play well with time constraints (see Humorous Annedoct in History of Lisp).
One of the (many?) shortcomings of Java is, at least in my humble opinion, the lack of unsigned integers. This may seem a minor problem, but it becomes a real annoyance when you have to deal with bits and bytes.
Consider the right shift. As a good C/C++ programmer you know that right shifting of a signed integer is generally bad. Java defined two bit-wise right shift operators: >> and >>>. The first extends the sign, so that -2 >> 1 evaluates to -1 and -2 >>> 1 evaluates to (-1 & 0x7FFFFFFF), i.e. the
So far, so good. So you may be surprised from the result of the following code:
class Surprise
{
public static void main( String[] args )
{
int result = -1 >>> 32;
System.out.println( "surprise: "+result );
}
}
I don’t want to spoil the result, so you may want to take some more time to think… Ready with your guess?
Well Suprise.java prints -1. That’s because the right hand side argument of the >>> operator is masked implicitly by 0x1F (i.e. taking values just between 0 and 31 included).
No warning is emitted during compilation, so you are pretty on your own – either you know or you don’t and trouble are ready to … byte you.
Here now and then, as a programmer, you have a hard time finding a good name for something. That thingy thing that eludes your wit and skill to name things. And that’s bad because it is hard to reason about unnamed entities. Symbols are deeply embedded in our brainwork and the right word has quite a power to drive thoughts efficiently and reliably.
As a programmer, you will be quite familiar with the abs function. I thought I was. In fact it was filed in my brain drawer with the absolute mathematical function. It takes a number and provides an always positive or zero result. Right?
Well, mostly. This morning, while typing in the scala REPL:
scala> Math.abs(Int.MinValue) res0: Int = -2147483648
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?
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.
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.
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?
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++.
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.