Sunday, November 18, 2012

Micah Martin has done the Coin Change Kata in Clojure. His collegue did it in Ruby (presented in the end of the Micah's post). I don't like either of the solutions. The Clojure one is almost unreadable - it's extreamly hard to understand what's really going on - take, map, mapcat, repeat - it's just too many too general constructs for such a simple problem. The Ruby one is readable and straitforward, though it's imperative and uses mutable vars, which I don't like very much these days.

So, let's look at what code I wrote in 5 minutes in F#. What's interesting, it worked the first time as was compiled:

Tuesday, November 13, 2012

Maybe monad in F#

F# supports writing custom monads very well. Take a look at (famous :) maybe monad which is just 6 lines of code:

Tuesday, November 6, 2012

->, ->> and thread-it

One guy suggested to use -> macro as often as possible instead of ->>. However, his final code doesn't look as clear as it should be (yes, it *should* be: we're coding in clojure).

I think, this is a great opportunity to use wonderful thread-it macro from "Clojure in Action" book:

Thursday, November 1, 2012

Clojure: Multimethods vs Protocols

Let's measure how much multimethods are slower that protocols:

  • multimethods are roughly as fast as protocols
  • clojure maps as fast as records
  • "class" notation is in order of magnitude slower than "map" notation

Friday, October 12, 2012

(Semi) first look at Clojure

OK, it's time for Clojure (again). Let's look at the (now famous :) Fibonacci function:


It took ~9 seconds which's not so good as would be (however, I'm not very frustrated about that :)
What about the language itself, it feels very 'tired' - it has little build-in constructs and, I believe, it's extremely flexible. Time will tell if I'm right... :)
However, there's one annoying thing - lazy sequences, which I almost hate in C# (IEnumerable) because they must not be mixed with any side effects, which is rather hard to achieve in such a primarily imperative language as C#. So, I have a believe that laziness is very much nicer in Clojure :)  

Monday, September 10, 2012

iPad

I can't realize how android devices are able to be sold having iPad is in the market.

Tuesday, August 14, 2012

Uncle Bob about software architecture

Uncle Bob summarizes the latest research in the field of software architecture (Ports and Adapters (GOOS), DCI by Coplien etc): The Clean Architecture

Thursday, August 2, 2012

Functions and Methods

"...things such as functions and methods look essentially the same, but they derive from very different ideas. A method reflects a behavior expected in the domain, and a function reflects a unit of execution in the machine. A message and a function call might be identical, in syntax and in how they are implemented inside a machine. But who sends the message to whom, how that message is interpreted, and what kind of code will be necessary to respond will be quite different."

— David West, "Object Thinking"

Wednesday, July 25, 2012

Why should we do code katas

"When the guidance comes from someone who is a genuine Master programmer, then it’s possible he/she is trying to show us something we don’t even know we don’t know. How can we find out, other than by exploring the suggested path?" Why should we do code katas.

Saturday, July 14, 2012

Checking arguments for null in Nemerle: revisited

It's turned out that Nemerle has full fledged design-by-contract feature! Let's see how the code from the previous post can be rewritten:

It's really both elegant and powerful compared to hand-written "if (arg == null) throw new ArgumentNullException(...)" or using the Microsoft contracts library.

Contracts may be bond right to arguments themselves:

Which causes: "Nemerle.Core.AssertionException: assertion ``name != null && name.Length > 0'' failed in file Main.n, line 107: The ``Requires'' contract of parameter `name' ha s been violated." Amazing! :)

However, if checking for null value is what's only needed, there's one more option: the NotNull macro attribute:

Friday, July 13, 2012

Checking arguments for null in Nemerle

An impossible thing in languages like C# and F#:

Thursday, July 12, 2012

Nemerle. Finally.

It took 5 seconds compiled in debug. What I'm extremely interested in the moment that Nemerle macros. However, Visual Studio support seems as poor as for F# :( No even "find usages" or "rename"... Uh...

Update 21.06.15, new code:


Result in Release configuration - 1.45 seconds.

Sunday, July 8, 2012

Binary trees in F#: functional polymorphism

That's it. Having no class hierarchy with its usual noisy methods overriding and so on, we've got polymorphism - succinct and highly readable. Wow!

Friday, June 29, 2012

Now, F#

OK, let's look at Fibonacci in F#:
It took 4 seconds compiled as debug (and 3 seconds compiled as release). Very, very impressive, I must say. The code looks as clean as Erlang equivalent, however pattern matching in Erlang is obviously more power - it supports matching function arguments and binding variables right in the patterns. However, this is the very first day I learn F#, so I may be mistaken about its pattern matching features. If this is the case, I'll sure update this post later.

Update 21.06.15


Result: 1.38 seconds in Release configuration.

Saturday, June 16, 2012

Uncle Bob about passion for programming and chicken farms

"...we face a lot of pressure to move into management. If you are a software developer for three or four years, you leverage up and you start running a group. I find that very unfortunate.
We need good managers, but software developers typically don’t have those skills and they don’t want those skills.
When they feel the pressure to move in that direction, many of them fail. Maybe they pursue some career in marketing and lose their origin passion for what they were doing. I have certainly faced that several times. I have been a programmer, then I have run a group, then I went back to be a programmer, then I ran a division, then I went back to be a programmer and I ran a company. And now I’m programmer that does a lot of speaking and talking and I am very happy with that.
Some people don’t have that love because they got into software development because of the wrong reasons.
Some of them develop the love because they find out it’s very good to be a programmer and some of them lose the love because they find themselves in an environment that crushes that love out of them. It’s an environment where they are driven by deadlines and driven by pressure and they have to work overtime and after a while they ask themselves: why did I get into this horrible situation?
Then they leave and become a chicken farmer.", Uncle Bob

Sunday, June 10, 2012

Another Erlang book

I've just finished (not cover-to-cover though) reading Erlang Programming book. And started to read Erlang and OTP in Action. It seems that the latter is much more practical and deep, while the former is very nice for beginners as it introduces the Erlang language itself in great details, touching the OTP not so well. So, I rather happy with the order I've been reading this exciting books! :)

p.s. It seems that a task very nicely fitting to solve it in on Erlang (protocol parsing on bit level) suddenly appeared on my current work...

Monday, June 4, 2012

Erlang: quicksort

The code exhibits exactly what the algorithm does. It's really impressive!

Wednesday, May 30, 2012

Erlang: beginning

So, now Erlang language. The first impression is good. Very good:

Compare this with other languages. It took 17 seconds to complete (as twice as longer than C# version, but three times faster than Ruby). Interestingly than all four cores of the CPU was loaded for 25% during the test.

Thursday, February 9, 2012

Bus-oriented architecture

Nat Pryce wrote interesting thoughts about bus-oriented architecture:

"I like event-based systems, especially with content based multicast. I've usually used the style in distributed systems not in a single process.

The big benefit is that you can easily change the components in the system without fiddling with the "wiring" between them.

However, there is a trade-off. The event bus hides the dependencies between your components. It looks like every component only has a dependency on the bus, but really they have connections to whichever
other components produce events they must react to or react to events that they produce. If you are not careful, the protocols between components can become an unintelligible, fragile mess.

If you design the system right, you can back out the real dependencies from your components subscription and advertisement definitions and thereby visualise the real architecture of the system with graphviz or
whatever. But usually it's up to you to expose that information at your component interfaces or even design a component system that has interfaces which can be interrogated in this way.

The other difficulty with event buses is that it's hard to compose components into larger components, unless you create a hierarchy of buses. That's doable in-process but is harder in a distributed system.

So, my steer is if components must rapidly come and go, an event bus can pay off. But if they don't, explicit wiring will be more helpful to understand the system and keep tabs on architectural cruft creeping in."