Saturday, 8 February 2014

Sentence-like function declarations

One of my JavaScript functions had this declaration:
function deviation(words, ideal, maxWords) { ...
My biggest problem with this is that one cannot be sure what the role of the parameters is just by looking at the declaration. A possible solution could be to add a comment. That's a last resort: I believe that code should be simple and self-descriptive enough to be understood without comments. And here is my final refactoring that I like a lot but I've never seen anything like this before:
function calculateDeviation(ofWords, fromIdealSize, usingMaxWordsInOneGroup) { ...
There are benefits and disadvantages to this. The main benefit is that now it is obvious what the role of the parameters are without reading the body of the function or the documentation. The main disadvantage is that the parameter names are a bit weird when you use them through the body of the function. Maybe the ideal solution is to add a call-through function to the interfaces (exports if you use require or public methods if you use some kind of OO pattern): so someone who calls this function will know what the parameters are by reading the declaration only but at the same time you can use not-so-weird parameter names in the body of the private function.

Tuesday, 28 January 2014

2013

The obligatory 2013 summary

I had a wishlist to Microsoft 1 year ago. Since then they started sorting out the mess they created with their separate platform libraries. Microsoft changed even the licensing of the portable class libraries and made them available for Xamarin. Windows Phone is doing well on some markets and I can see at least one device a week on the tube here in London. The app market however still misses some key applications and I know about people leaving the platform because they miss some application. And this year at last Microsoft ported Photosynth to their mobile platform. Congrats guys.
Steve Ballmer's resignation was very exciting news. I really didn't like what the company (not) did under his leadership. But there are no effects in 2013 yet.
And there is a new Xbox. Depending on the next leader and what strategy Microsoft chooses, if they do choose a strategy at last, I still believe that Xbox is The Microsoft Product most households will have five years from now. Not that sure about any other Microsoft presence.

I asked Google to pioneer in the platform unification. They didn't and they did. Android is not going to desktop, at least not by Google. Others do it instead. What Google does is that they are transforming Chrome, the browser, into a full OS. That, and the success of the Chromebook is a more interesting way to rule the desktop world than a desktop Android.
Google also killed some of their products, including the RSS reader. That one resulted a rise of better RSS readers than The One. I have the feeling that Google reached that level of presence where they don't need to keep products alive that are good for the users but have no added value for Google. Living in the Google world (Gmail, Blogger, Picasaweb, Chrome, ...) it is not a good feeling.

I asked Apple to be amazing. They are not. Actually they had a very boring year. I switched to iPhone 5s after Nexus 4. It is still a decent device, it is still the best for me(!), but it is not outstanding.

This year was the debut of Firefox OS. I am watching it since the very first entry I had on this blog :)

On the front of programming this year's fad was the Functional Programming, and the ever-growing JavaScript presence on all possible hardware and software.

It was a quiet year in all other fields: curved TVs, 4k TVs, death of 3D TV (that wasn't ever alive), some Google Glass news, bigger and bigger mobile devices, ... practically 0 innovation.

Saturday, 25 January 2014

Why do we read code the ancient way?

This is a video about Code Bubbles. One year later the idea is applied to Visual Studio under the name Debugger Canvas (though it doesn't look that cool). I have only one question: Why on Earth are we still reading and debugging code in textfile-view four years later?! Actually the question is: Why we do it forty years later?

Sunday, 5 January 2014

Yet another post about Duck Typing

"If it walks like a duck, and quacks like a duck, it’s probably gonna throw exceptions at runtime."

The Three Articles

The first article in my rss reader I ignored. I know what duck typing is, so I don't read a post about it. Seeing the second title I raised my eyebrow. But when a third one appeared on the list I decided I need to read them: I don't follow fools' blogs, so three posts about the topic clearly means that something is worth a look there.
Eric Lippert expresses his confusion over the Wikipedia page about Duck Typing. I skimmed his article: he's pointing out some weaknesses of the Wikipedia's definition. Nothing interesting here; just this week I learnt from Wikipedia that ThisIsCamelCasing while it's common knowledge that thisIsCamelCasing. There are facts and there are community-edited articles. Let's move on and see what the other two posts are about. As I expected, those are reactions to the first one. Still nothing interesting... except! Except that Glenn Block calls Eric Lippert (the author of the original article) "one of the fathers of C#". Okaaay. So either The Fathers Of C# have no idea about the basic definitions of programming type systems and the IT industry is doomed, or I missed something. At this point I re-read Eric's post properly and a long journey's began.

My Two Pennies

I have no two pennies today. After reading some more articles and a research paper I still don't have a final conclusion. Here are three vague definitions of duck typing I have after all this reading:
"Structural Typing may be thought of as a kind of compiler-enforced subset of Duck Typing." (by Mark Rendle in the comments of Eric's post)
"Duck typing can be seen as the run-time, dynamically typed equivalent of structural typing" (from the publication above)
"Structural Typing which provides a way to do Duck Typing in a compiler safe manner that works with static types" (by Glenn Block)
The definition of early binding/late binding (or static typing/dynamic typing) are clear just as structural typing is. Duck typing is the only one that just doesn't feel like a well-defined entity but it still feels like "something": Python and JavaScript clearly have duck typing. And the C# dynamic keyword feels like it is not duck typing, but Glenn Block, among others, disagrees with this. And I myself also disagreed one hour ago. Occam's razor to the rescue: probably duck typing is not different from late binding. I accept this until I see a late binding that clearly is not duck typing.

Thursday, 26 December 2013

Which programming language to learn next

This is a revamp of an earlier post that started with my personal path of finding a language I'd like to master in 2014. After lots of discussion on different forums I've come to a nicer, and higher level view of this question that puts it in a different perspective. My hope is that this approach is more useful for the reader.
There is a common wisdom that a programmer should learn a new programming language every year. I think that would be too much and after a certain number one wouldn't benefit much from the next language. I agree in that one should know several different languages in order to see different ways of expressing and solving problems and to use that experience in their working environment. "Several" is not a specific number, but it is not less than 3 and not more than 7. Probably a wisely chosen five languages should be enough. Here is a way to group the languages that I believe can help in the process.

The basics

C or C++ with a touch of Assembly. Without these you will struggle to see and understand what's happening in the background when you use a higher level language in the future. You don't need to be proficient in any of these, but you should get to the level where you understand what happens on the stack during a function call and you can implement the basic data structures and algorithms with some performance constraints. On this level you are forced to think about the efficiency and this understanding comes handy in the future when a mere decision between HashSet and List will makes or breaks the efficiency of your code.

An OO language

C++, C#, Java. Pick one, master it. Learn the platform not just the language. Learn and apply the OO principles.

JavaScript

This one is not a for learning new concepts. If you really want to avoid it then you can. But it's definitely worth to familiarise with it: besides being the C of Internet it is the chosen language for cross-platform mobile development and you can program server-side (nodejs) or Windows 8 desktop apps in it as well. Sooner or later during your career it will catch you :)

A scripting language

Python is an obvious choice here, Ruby is another one. Perl, shell script and probably some dozen others are also on this list.

A functional language

Haskell, F# or Erlang. Haskell is THE language to learn if you want to master the functional programming principles. If, however, you plan to use the language for work then you are better of with F#. And there is Erlang somewhere in between.

One from the Lisp family

This level is mostly academic (except if you are working with AI) but I am sure one still can benefit enough from this. The problem is that the Lisp community is very fragmented (and Lisp syntax is (very (very)) strange). There are two major dialects and several minor languages. Today I would recommend Clojure: it targets the JVM and compiles to JavaScript. Both are such benefits that move the language to the "actually useful" field.

How to choose

If you want to choose your one language then you are reading the wrong blog. So you want to choose your nth programming language. First of all you should choose one that you like: you like the community, you like the company that controls the platform, you like the syntax, the libraries, the frameworks and the tools. One should not learn a language that they don't enjoy using. My second advice is: diversify. Choose from a group above that you have no experience with yet. My next one is Haskell.
Happy coding!

Tuesday, 10 December 2013

Strong passwords

Dear Microsoft,
I am writing to let you know that you are the only service provider I've ever used that doesn't let me use my 17-22 character long passwords. And to make it more controversial at the same time you don't forget to emphasize how important a strong password is.



The above was the original drafted blogentry, but by the time I am posting it this landed in my news reader. Now that makes the story complete.

And one more comment: the world would be a better place if everybody, including ops teams in the companies I've ever worked for, read xkcd. Besides that employees would stop storing server passwords in Excel files the passwords would also be really strong. FYI all brute-force password cracking software test against substitutions like o->0, s->$, l->1 and all the other tricks that make the usual corporate-security-policy-forced 8 character long passwords "strong".


Saturday, 30 November 2013

An engineer's business card

Recall the countless times you desperately needed a 1 KOhm resistor to fix an amplifier at a party, only to see the girl you were trying to impress slip away with an OCaml programmer?