vaskir's blog

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:

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

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:

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

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 :)  

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

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

"...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"

"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 .

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:

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

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.

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!

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.

"...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 ...

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...

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

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.

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 s...