Thursday, November 17, 2011

Flex codebase is now worthless

Commercial giant Adobe believes his Flex codebase is now worthless and donates it to Apache foundation. I discovered the same early this year when I was developing on Flex Hero (4.5) platform.

No documentation, copy-and-paste development and paid development tools were epic fails. Glad to see the free market working towards extinction of technically inferior solutions.

Thursday, October 13, 2011

Facebook's first shot at search

Facebook platform features some mobile functionalities.

Among others, there is search:

This is first serious shot of Facebook at search functionality in terms of challenging Google.
I hope someone makes cool use of that and earns a lot of money :)

Wednesday, October 12, 2011

Clojure will not work

Clojure will not work. Here is why it will not work.

Based on:

Programming Language Checklist

by Colin McMillen, Jason Reed, and Elly Jones.

Slightly modified for clearer rant

You appear to be advocating a new:
[x] functional  [ ] imperative  [x] object-oriented  [ ] procedural [ ] stack-based
[ ] "multi-paradigm"  [x] lazy  [ ] eager  [ ] statically-typed  [x] dynamically-typed
[x] pure  [ ] impure  [ ] non-hygienic  [ ] visual  [ ] beginner-friendly
[ ] non-programmer-friendly  [x] completely incomprehensible
programming language.  Your language will not work.  Here is why it will not work.

You appear to believe that:
[ ] Syntax is what makes programming difficult
[x] Garbage collection is free                [ ] Computers have infinite memory
[ ] Nobody really needs:
    [ ] concurrency  [ ] a REPL  [x] debugger support  [ ] IDE support  [ ] I/O
    [ ] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[x] Scaling up to large software projects will be easy
[x] Convincing programmers to adopt a new language will be easy
[x] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers won't rely on them
[ ] "Spooky action at a distance" makes programming more fun

Unfortunately, your language has (checked only *unfortunate features*, Clojure has tail recursion):
[ ] semicolons  [ ] significant whitespace  [x] macros
[x] implicit type conversion  [ ] explicit casting  [ ] type inference
[ ] goto  [x] exceptions  [ ] coroutines
[x] reflection  [ ] subtyping  [ ] operator overloading
[ ] algebraic datatypes  [ ] recursive types  [ ] polymorphic types
[ ] covariant array typing  [ ] dependent types
[x] infix operators  
[ ] call-by-value  [ ] call-by-name  [ ] call-by-reference  [ ] call-cc

Unfortunately, your language lacks:
[ ] comprehensible syntax  [ ] macros
[ ] implicit type conversion   [ ] type inference
[ ] goto  [ ] exceptions  [ ] closures  [ ] tail recursion  [ ] coroutines
[ ] reflection  [ ] subtyping  [x] multiple inheritance  [ ] operator overloading
[ ] algebraic datatypes  [ ] recursive types  [ ] polymorphic types
[ ] covariant array typing  [ ] monads  [ ] dependent types
[ ] infix operators  [x] nested comments  [x] multi-line strings  [ ] regexes
[ ] call-by-value  [ ] call-by-name  [ ] call-by-reference  [ ] call-cc

The following philosophical objections apply:
[ ] Programmers should not need to understand category theory to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is its own compiler
[x] The most significant program written in your language isn't even its own compiler
[ ] No language spec
[x] "The implementation is the spec"
   [ ] The implementation is closed-source  [ ] covered by patents  [ ] not owned by you
[ ] Your type system is unsound  [ ] Your language cannot be unambiguously parsed
   [ ] a proof of same is attached
   [ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[x] Interpreted languages will never be as fast as C
[ ] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has never been shown possible
[x] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable

Your implementation has the following flaws:
[x] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[x] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[x] You require the compiler to be present at runtime
[x] You require the language runtime to be present at compile-time
[x] Your compiler errors are completely inscrutable
[ ] Dangerous behavior is only a warning
[ ] The compiler crashes if you look at it funny
[x] The VM crashes if you look at it funny  (see example below) 
[ ] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions

Additionally, your marketing has the following problems:
[x] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
   [ ] Graphics, simulation, or crypto benchmarks where your code just calls
       handwritten assembly through your FFI
   [ ] String-processing benchmarks where you just call PCRE
   [ ] Matrix-math benchmarks where you just call BLAS
[x] Noone really believes that your language is faster than:
    [x] assembly  [x] C  [x] FORTRAN  [x] Java  [x] Ruby  [ ] Prolog
[ ] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification

Taking the wider ecosystem into account, I would like to note that:
[ ] Your complex sample code would be one line in: _______________________
[ ] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Java but worse
[ ] You have reinvented C++ but worse
[ ] You have reinvented PHP but worse
[ ] You have reinvented PHP better, but that's still no justification
[x] You have reinvented Brainfuck but non-ironically

In conclusion, this is what I think of you:
[x] You have some interesting ideas, but this won't fly.
[ ] This is a bad language, and you should feel bad for inventing it.
[ ] Programming in this language is an adequate punishment for inventing it.


"The VM crashes if you look at it funny":
user=> (defmacro re2 [x] (str "a" ~x))
user=> (re2 1)
java.lang.IllegalStateException: Var clojure.core/unquote is unbound. (NO_SOURCE_FILE:0)
(only few people on Earth understand this error and actually no one of them understands why this error is not presented by compiler while defmacro)

Tuesday, October 11, 2011

New Python simple http request library


What and why

A successful attempt at simplifying HTTP requests in python.
Full support for cookies, headers, HEAD method and sessions (use of with block).
Code looks simple and clean (can't think of better complement).

Code example

>>> r = requests.get('', auth=('user', 'pass'))
>>> r.status_code
>>> r.headers['content-type']
>>> print r.cookies
{'requests-is': 'awesome'}


There are hooks available. One can have a function called pre-request or post-request.


This library is used internally at Twitter

Friday, September 16, 2011

No plugins in IE10 in Metro (smartphone) mode

Microsoft's IE 10 in Metro (smartphone) mode will not feature any plugins (not even Silverlight). It will only work with HTML5.

Actually this means that Silverlight is dead and Flash is rapidly drowning, despite late iPhone success.

Tuesday, July 19, 2011

The Baseball of Greed

Apple deals massive patent blow to HTC, Android in serious trouble | ZDNet

All right, there you have it. Patents just made Android die. Did it? Well.. at least in the US.

Now Europe has it's chance to outgrow USA technically. We don't have absurd laws that let one company basically smash other legitimate business with a Baseball of Greed.

Now I'll never buy anything from Apple not only for bad usability and aesthetic reasons, but also for moral ones. Any Apple user is from now on an enemy of free market!

Tuesday, July 5, 2011

Static hard typing is useless is method signatures

Consider following interface method signatures:
AlfaRomeoTargetProduct getByPK(java.lang.Integer languageVersionId, java.lang.Integer alfaRomeoId);

SigmaOmegaTargetProduct getByPK(java.lang.Integer sigmaOmegaId, java.lang.Integer languageVersionId);

And several other such getByPK methods. These were generated by O/R Mapping software. They are parts of the same application and are used together.

I've just spend at least half an hour looking for reasons for code below to explode:

productId = sigmaOmegaTargetProductDAO.getByPK(myObjectId, lvId, true).getProductId();

productId = alfaRomeoTargetProductDAO.getByPK(myObjectId, lvId).getProductId();

Until I checked the actual O/R Mapping code for getByPK.

For quirky reasons order of method attributes is shifted between various objects - sometimes languageVersionId is first, sometimes last.

Guess what? It should have been:

productId = alfaRomeoTargetProductDAO.getByPK(lvId, myObjectId).getProductId();

Static hard typing haven't prevented this error. I could be writting this code in dynamic language and save a lot of time.

It get's worse..

Let's suppose method signatures are fixed and myObjectId is always first and there is one more attribute lvId.

With language like python or ruby we could just ommit the switch/case structure and write:

dao = getDaoByName('alfaRomeoTargetProduct')
productId = dao.getByPK(myObjectId, lvId).getProductId()

We can't in java. Unless all of these O/R Mapping objects were using the same interface. Which is unsupported in O/R Mapping we use. So sad..

Moral: Static hard typing is useless. Even if no errors/inconsequences are present, static hard typing is counterproductive.

Monday, May 30, 2011

Want TextMate for Linux? Use kate!

Let's go through TextMate features with Kate in mind:

Ability to Search and Replace in a Project

That Eclipse-like goodie is actually better left to really powerful bash > find | sed && awk scripts. Otherwise you hit a wall rather sooner than later.

Auto-Indent for Common Actions Like Pasting Text

That of course is simply wrong thing to do. Usually one needs to guess what editor did and fix it manually. But kate has it of course if you insist.

Auto-Pairing of Brackets and Other Characters

Kate has it. Emacs has it. Vim has it. Basic prerequisite for any programming text tool.

Clipboard History

That would be cool. Oh wait, KDE has that..

Column Selections and Column Typing

Impressive but totally useless.

Completion of Words from Current Document

Kate has it.

CSS-like Selectors to Pinpoint the Scope of Actions and Settings

What? You know local scope for programming language you didn't know existed? How?

Declarative Language Grammars for Graceful Mixing and Hacking

Kate has it and even more. It has API for scripting:

Dynamic Outline for Working With Multiple Files

Kate is also very good with multiple files.

Expand Trigger Words to Code Blocks With Tab-able Placeholders

You should avoid programming language that needs this feature often. You'd be better off. Actually doing that breaks DRY principle - you should add a method/macro to your code instead of repeating it.

File Tabs when Working With Projects

Tabify Kate pluging

Foldable Code Blocks

Classic. Kate has it.

Function Pop-up for Quick Overview and Navigation

This is actually better than in Kate. I miss it.

Plug-able Through Your Favorite Scripting Language

As said above, Kate is scriptable both from KDE and via Kate plugins.

Recordable Macros With No Programming Required

As iMacros prooves it, this is wrong path. Macros needs programming to be useful. Otherwise they just break DRY principle as above.

Regular Expression Search and Replace (grep)

I'd bet my money Kate has world-class support for regexp (positional, grouping) here. I've changed original text:
    * Ability to Search and Replace in a Project
    * Auto-Indent for Common Actions Like Pasting Text
    * Auto-Pairing of Brackets and Other Characters
to HTML H4 headers:
<h4>Ability to Search and Replace in a Project</h4>
<h4>Auto-Indent for Common Actions Like Pasting Text</h4>
<h4>Auto-Pairing of Brackets and Other Characters</h4>
By replace
    \* (.*)

Run Shell Commands from Within a Document

Sure, type them without readline, without Ctrl+R history? Useless.

Support for Darcs, Perforce, SVK, and Subversion

Cool names. What do they do? Oh, you mean syntax highlihting? Kate has it. As for subversion: Integrating code revision control systems into text editor takes from you the power of text console. If you don't like console, you should work on it.

Support for More Than 50 Languages

Only 50?

Switch Between Files in Projects With a Minimum of Key Strokes

Kate beats strokes with one stroke (Alt+arrow).

Themable Syntax Highlight Colors

Kate has it.

Visual Bookmarks to Jump Between Places in a File

That is killer feature of Kate. It actually made me think TextMate is somewhat based on Kate.

Works As External Editor for (s)ftp Programs

With kate -u switch (use existing kate instance) you get to work on any project incredibly fast.

Works Together With Xcode and Can Build Xcode Projects

Cool, but I like both make and maven for a build system.

Wednesday, May 4, 2011

Encoding video with subtitles for playing on Xbox 360

mencoder HSE_0720.avi \
    -sub -subfont-text-scale 3 -utf8 \
    -o HSE_out.avi \
    -of lavf -lavfopts format=asf -ovc lavc -lavcopts vcodec=wmv2 \
    -oac lavc -lavcopts acodec=wmav2 

It encodes any video playable with mplayer so that it is playable on Xbox (via uShare or Media Center).

Subtitles are rendered into video stream, so output .avi is standalone.

Saturday, April 16, 2011

Being interchangeable part - survival guide

Employers much prefer that workers be fungible, rather than maximally productive

Java Enterprise (J2EE) and UML.
The good parts: standards (Hibernate, Servlets), deployments, security, runtime environment (JVM, app servers), maven. They make it easy to program.
The bad: Bloat of the code, static typing, Eclipse (slowness!), need to reaload classes while developing, UML instead of talking to your team. This makes us inefficient and slows us down.

Static typing creates an well-selling illusion of easy finding the way in the code. Object oriented programming/J2EE methodology and static typing turns 66% of programmer's day into of text generating mini-game (with comming up with cool class name being the fun part). Having to compile and reload the code wastes another 10%. Add 4% for coffee and frustration from slowness of tools... This leaves 20% of time to programm. No wonder that it takes several months to finish simple projects.

Why companies are pushing such ineffective technologies?

Labor cost is highest position in almost any company's budget. But it still obviously pays for them for you to be ineffective. Why? Because with java you are an interchangeable part of the system (just like an object implementtion). Ability to replace you makes your wage drop and makes you easier (more obedient) and cheaper to manage (with poor management).

We all fear the change. Knowing that we are easly expendable and totally unrelevant make us care for our job and put up with unreasonable requirements, methodologies and bad management.

Effectiveness distinguishes programmers from each other, it's our value and currency. By making our main asset irrelevant, Java (J2EE) hurts our souls and sips off our energy turing us into bland Eclipse operators.

How can we earn respect?

To break free, we need to go from irrelevant to being importand and catually appreciated for not being easly replacable.

How to break free: jedi

  • Become relevant by being technicaly perfect. Know alot. Bring cool new toys to development. Learn new things afterwork. Write blog, do opensource
  • Promote new technologies. Unknown terrain is an opportunity to show off your skills.
  • Write some software for company-wide use - it makes you seem less expendable. As a bonus, try to please your coworkers with clean, easy syntax or even nice DSL
  • Become part of usual landscape, be last one that comes in mind when staff reductions are near. Do some maintenance tasks that no one likes. Take care of fields no one wants to touch.
  • When you learn something at the expense of your current employee, stay with him till it's obvious it was worth it to invest. This might help creating better environment for all of us. Do however find other job if someone takes advantage of your passion and honesty.
  • Ask for code reviews and technical appreciation of your work. Treat it as part of your salary and be proud of praises. Remember to ask for position change when new duties come along. This costs employer very little, but makes you feel much better. Also writting new position in contract makes you more valuable and relatively less expendable.
  • If you are not appreciated technicaly, but know you do good work, find siths around you
  • Consider switchin career to Ruby
  • Consider switchin career to Python
  • Consider switchin career to Scala
  • Consider working for small company where technical team members do specialise and trust is the binding
  • Consider working in fast-paced environments, that take requirements from marketing not IT, have ambitious deadlines and is properly, competently and honestly managed.

How to break free: the dark side

  • Reinvent as much wheels as possible - custom solutions instead of well renown working ones. Effectively go away from java to 'my way of thinking'.
  • Go along Java bloat. Promote extensive unit testing, insist on using CMMI and/or bloated project management methodologies (PMI, Prince2). Use UML. Complicate database schemas.
  • Help lazy managers do the bad job. They are your best advocates in hard times.
  • Loudly preach good practices but don't follow your advice. Backstab and sucker-puch anyone that naively proposes something long-term sane, but more costly than dirty, bad hacks. You will become immediate treasure for your employer.
  • If you are medicore programmer or choosen programming career for money only, promote everything that slows work down. This gives you easy way to compete agains passionates (it frustrates them to start with). You also have passions that need the money - why would they take what you deserve?
  • Try locking company in your unique knowledge or abilities. If you have none, create an illusion that you do by learning something unpopular (ex: LISP or Perl).
  • Write or introduce software that seems brilliant speedup but actually hinders development. Example: software for class reloading and classes cached so that they actually often won't reload. Have explanation for every quirky case at hand - become competent in promoting that software.
  • Use years of experience and CS degree as arguments in discussions against others. Always agree with those with higher experience. Do not let self-tought barbarians gain any points or fields.
  • Help survice stone-age standards and solutions. Cunny enterprises only work with them, because it's cheap to buy programmers to do what everyone is already doing. Helping management promotes you.
  • Help kick out of the company every naive programmer that says it loud that bad things happen. Marginalize rebeliants. Kill all jedi.

Examples and inspirations:

  • Writting your own OR/Mapping with one well-selling feature that JPA doesn't have. Make sure it changes the way standard-users think about schema.
  • Suggesting use of LISP by selling on it's famous effectiveness and than wrapping it up so that it actually slows work down.
  • Sell in Clojure language (LISP for JVM) to be used (promotes you!) and forbidd anyone (but you!) to write macros. A perfect career cheat.
  • Insisting that beacause of security reasons (try something that kicked company's butt before, like XSS) all programmers must suffer quirky, undocumented, intentionaly badly written (by you) wrapups for every function in the code. Again, become unquestionable expert at solving issues there.
  • Oppose Agile methodologies at all costs and the same time promoting Java. Agile with java requires inhuman ability to write modular, clean code with no assumptions of future use. If you'd ever like Agile, switch language :)
  • Support your boss helping to survive old methodologies by finding or making up costs of dropping it. He will love for that.
  • Promote using in-code caches instead of external ones (like memcached). Cache is a root of all evil and creates alot of hard work.
  • Quickly assasionate everyone mentioning names of: Varnish, Scala or Play Framework
  • Do promote TDD methodology. It makes you seem enterprise-team-member (again, less expendable) and slows down work for the whole team. More time for coffe, less deadlines. More opportunities to write bad, proprietary locking-in solutions.
  • Remeber, you need to seem relatively (to your colegues) less expendable. Bring some bad things to development and sell it as importand innovations.
  • If company happen to invest in you or you learn something new, immediately apply for new job and ask for bigger salary. It works, because your current company paid alot of money for your education and next company just uses that knowledge. Repeat -> profit!

Dark side is easier, but it eats your soul. Think carefuly what shade of gray are your doings...

Wednesday, April 13, 2011

Find errors in compile-time with static typing

I've just read interesting article of upcomming (wishful thinking) Java replacement:

One of core points was:
Static Typing (find errors at compile time, not run time)

What is strong and static typing

Strong typing
is when a variable once assigned cannot be assigned objects of other type. Compiler checks it at compile-time and later runtime errors are thrown when types mismatch
Static typing
is when you declare type of variable at it's creation and it cannot change. This enables full compile-time checks. No need to check type at runtime.

Static typing is a major feature of language that makes code written in it run faster than ever possible with dynamicaly typed languages. But this comes at price of extreme difficulties with doing real-time evaluation/interpretation. Yes, staticaly typed languages typicaly use some binary (intermediate or direct) format (.class, .obj, .com) for running.

What types of errors only staticaly typed compilator can find and rule out?

  • Missassigment (assigning something awkward) of variables due to simple glitch or more serious code or documentation (API) misunderstanding.
  • Missusing a variable (for example very annoying runtime exceptions in Clojure when you use normal variable but list was expected (rest/cons and so on))

What is a common mistake is that some importand types of errors are affiliated with compilator, but not with static typing. For example compiler (linker to be exact) is able to catch a problem with using non-existand method as methods are symbols in libraries. Staticaly typed language would also enforce properly using that method (parameters).

Ruby makes a use of lack of compiler by providing method_not_found() method. It is requested if someone used a .methodThatDoesNotExist(). For one interesting application see Ruby chapter in '7 languages in 7 weeks' by Bruce Tate (already a must-have classic book).

What types of errors cannot be eliminated with static typing alone?

  • Off by one, buffer overflow, integer overflow, list out of range, invalid map key
  • SQL Injection, not coding for security
  • Bad logic, edge cases, not fulfilling the contract
  • I/O and concurrency problems
  • Lack of resources (db connections closed, out of memmory error, firewall)
  • Typical bugs like missing button or something not working in Internet Explorer.

Let's see.. Some serious and very common problems on this list. Somehow using a Map instead of List become less importand in face of SQL Injection... ain't it?

Testing to catch errors

As professionals, we test our software before our clients test it. We employ alot of cool and efficient techniques to protect our reputation:

  • Manual or automated iMacros,Selenium testing of requirements/contracts fullfillment
  • Testing while building - JUnit/Mockito
  • Code review, coding standards (variable naming), API documentation in-code, javadoc/pydoc/Clojure:doc..

These are not tied to languages, but to profesional attitude towards programming craft.

Static typing promises are lies

  1. Static typing prevents only minor set of problems of little relative importance (type error is many times less serious than 'Buy' button or PayPal integration not working.
  2. Static typing is actually much less usefull than strong typing. Scala language is strongly but not staticaly typed. Programmer doesn't have to waste time on type declaration (and comming up with a type name to begin with)
  3. Typicaly compiling takes so much time while developing software, that no runtime speedup is going to make up for it. I work with java framework that takes 90 seconds to fully rebuild (class reloading problems: IBM WAS restart required). Doing that few times an hour distracts me and my colegues so much, that after few hours we are frustrated and error prone (yes, programmer can also be error prone :).
  4. Staticaly typing to speedup runtime is premature optimization. One should code so that software works, apply test suites and if there are throughtput problems, find solutions then. Typical solutions orders of magnitude more efficient than static typing are: memcached, squid reverse proxy, load balancing that works (and another one), or fully featured accelerators like Varnish. Oh, web only solutions you say? Who cares about the rest? =D>


Happy developers with power at their hands are precious resources. Do not waste it in staticaly typed environment. Do not confuse static typing with compiler or linker. Do not confuse static typing with strong typing.

When choosing next languge for your project, start with interpreted languages considering frameworks maturity. If JVM (and J2EE deployment) is a must, take a look at Scala, Clojure, Jython or JRuby.

Thursday, April 7, 2011

Like C language and hate Java? Check Scala!

I've recently read a C praising article, that rants at Java:

Author seems to take it personally and is more biased than a scientist should be. But he is mostly right in his java rant.

In another chapter he mentions C lang problems, that he beliefs could be walked around. And this is where he is mistaken. Most C programmers read glibc and linux code and take it as example. Since there are obscure macros there, most programmers will write the same. The result is that coding C is no longer simple and will never be. Obscure macros will make any language fall (and fail) - and this is why Clojure will vanish after few moments of glory.

Most blows at Java are blows at lack of functionality, speed and inheritent code bloat. Java also indeed does some things the worst possible way, namely multiple inheritance.

Author is forced to admit that Garbage Collector and code divided into packages are seriously importand features of Java platform. If he ever did any web deployment, he'd also notice that jars, wars and ears packaging in J2EE are unique and save a lot of hassle. No other language has working deployment out of the box (maven war - one liner that builds the world).
Ooh.. maven :) Another killer app. In fact so good, everyone want to reinvent it.

Let's go through C wishlist, having Scala in mind.

Scala is functional (mostly, pragmaticaly they allow object state and imperative loops) programming language written in Java and running on JVM. You get J2EE packages, deployment and state of the art Garbage Collection for free.

Scala has also one nice feature - it's C-style formatted language

  • Package system -> inherited from java
  • Text substitution keyword instead of #define -> luckyly Scala has no preprocessing macros, so we don't need to fix that
  • Multiple return values -> just return an inline-built object. Side note: In python you'd just unpack a tuple:
    edata, newfunc, value = fReturnTuple()
  • Anonymous functions -> lambdas all the way in Scala, go ahead
  • Multi-line literal strings -> Scala has exactly the same multi-line operator """ as python
  • Flexible array ranges (not starting from 0) -> C-only problem. Real world has enums, iterators...
  • Regular expressions -> the author should take a deeper look at regexp librariers. RE is no longer slow. A missfire.
  • Reflection -> lol, actually someone here likes java more than he admits. Sure, there is reflection in scala
  • Closures -> full support in Scala
  • Way to detect overflow -> JVM anyone?


C language is broken. Has no namespaces (all functions are visible everywhere), most code uses obscure macros. Pointers syntax is complicated to a perl-level. C is error prone. C requires deeper understanding of machine and memory (ever switched 32bit code to 64bits?) that is practical for average programmer to learn... Only bad things happen when you program in C.

Instead of fixing Java with C, and wishing C had JVM features, one should look at Scala.

Wednesday, April 6, 2011

Pragmatic programmer - what I've learned

What I learned from:

Book cover of: The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas

Most things in this book is way beyond what CS students learn. At the same time these things are absolutely essential to become a programmer. This is good for self-tought programmers: we have a chance ;)

  • Do care about your work quality
  • Think about you work, how and why you do things
  • Individual mastery does metter
  • Think Kaizen, little steps towards perfection

Pragmatic philosophy

  • Never say 'impossible' - find solutions. Responsibility instead of excuses.
  • Poor excuses and lies are unprofessional
  • One broken window (smelly code) dooms and destroys stronges projects
  • Small, carlesly accepted scope changes lead to huge project failure.
  • You don't have to be perfect, you just need to be good enough.

Your assets

  • The best investment is always the knowledge
  • Knowledge depreciates with time. Fast.
  • Invest regularly. Read about your craft. Learn programming languages. My advice: start with lisp.
  • Stay in touch with other programmers and exchange views, knowledghe and code
  • If you don't know or understand something that just came up, do check it. Use every excuse to learn something new.

Approach to programming

  • DRY: don't repeat yourself. My comment: be lazy and automate or generate everything
  • Copy&paste is a sign to start thinking
  • Make your code easy to reuse but don't try to predict
  • Orthogonality. Get rid of links between unrelated modules or badly defined relationships
  • Expect orthogonality in project roles. If multiple people do simmilar tasks, those tasks are never done properly. My comment: Fuzzy responsibility is always a warning sign for a professional.
  • Be ready for a change in code (this is now called Agile Programming) or architecture. This is where you need to cunningly predict and overestimate a little.
  • Develop a system so that progress is easly visible. Ask for feedback early and often. My comment: If you are forced to develop and present whole system at once (waterfall) - you know managers are incompetent. Run!
  • DSLs - invent your own vocabulary. My comment: use monads and have every method return something (preferably this/self)

Estimating and harmonograms

  • Use adequate measure - if it takes 17 days, say 3 weeks.
  • Write down your estimates and compare to what happened. Take notes.
  • Harmonogram is always changing - do not let anyone force any date on you, unless no scope changes are possible. Watch out for managers that promise "no more changes" and later the same day ask for new features. Stop delivering any estimates to them. Try not to work with such people.


  • Descriptive variable names, natural language as values even when sending/storing data, text files as data source -> these are good things always and everywhere.
  • Use Linux and know your shell
  • Learn to use powerful text editor. My comment: Vim or Emacs. Eclipse only wastes your time. As for me, touch typing, knowing shell and mastering text editor are crucial programmers skills
  • Master text processing in python, perl, sed or awk. My comment: definately python
  • Understand what RTFM means. Learn newsgroups culture (now sadly extinct). Try saving other people time.

Fixing bugs

  • Don't panic. My comment: Chad Fowler says that professionals never panick.
  • Start with your code, assume you are the one to blame. No, that's not JVM bug. That's your bug.
  • Proove your theories by provoking a crash. Do not assume, make it crash.

Programming techniques

  • Have contracts in your code. My comment: basically try to have preprocessor or compiler warn you about changes in outer code. Ignore orthogonality here - you can delete uneeded contracts if decoupling/reusing.
  • Throw runtime execeptions (and let them fly)
  • Use asserts, especially in production code
  • Minimalise connections/bindings between modules
  • Use metadata to change local, specific behaviour


  • Accidential coding, programming by luck, "I don't know why this works" <- don't do this
  • Understand whole project and all used concepts
  • Do refactor code. My comment: never ask for permission, instead ask for forgiveness when caught refactoring
  • Do not use manual procedures. My comment: manual (step by step with printed instructions) procedures do not work. If it cannot be automated to a script, real person will make a mistake
  • Make sure that bug once found, never again happends

Pragmatic projects

  • Test your work before end users do
  • Slightly exceed expectations every time
  • Sign your work, be proud of your mastery

This book is a corner stone and a basic requirement to be any good in programming industry.

Friday, March 25, 2011

Closure in javascript and monad in python

What is a closure?

A closure is a function that returns a function parametrized by variables from lexical scope of the creator. Returned function encloses variables from outside of it's scope.

function createDestroyer(divId) {
    return function() {

var popupLayer = jQuery(document.createElement("DIV")))
popupLayer.attr("id", "popup5")
// fill popupLayer
// prepare layer closing button
var closeButton = document.createElement("A")
closeButton.addEventListener('click', createDestroyer("popup5"), false)

// other very good example is the anonymous function below:
repeats = 0
animationId = window.setInterval(function() {
    // animate something

    if (repeats++ > 100) {
        window.clearInterval(animationId); // access and capture outer scope variable
}, 250)

What is a monad?

A monad is a wrapper around data type. Each function called on a monad has access to wrapped data and returns the monad.

We have just seen one monad: jQuery. It wraps around any DOM element, each call returns jQuery object (so that we can chain for example ajax().css().show()) and each method has direct access to wrapped DOM node.

Effectively every object composition with methods that return instance (this) is a monad.

Let's build one in python (IDLE session dump):
>>> class MyMonad(object):
 def __init__(self, anArray):
  self.obj = anArray

 def add(self, elem):
  return self

 def butLast(self):
  self.obj = self.obj[:-1]
  return self

 def rest(self):
  self.obj = self.obj[1:]
  return self

 def toString(self):
  print str(self.obj)
  return self

>>> MyMonad([1, 2, 3, 5]).butLast().toString()
[1, 2, 3]
<__main__.MyMonad object at 0x90b556c>

>>> MyMonad([1, 2, 3, 5]).add("a").toString()
[1, 2, 3, 5, 'a']
<__main__.MyMonad object at 0x90d862c>

>>> MyMonad([1, 2, 3, 5]).butLast().add("a").rest().add(90).toString()
[2, 3, 'a', 90]
<__main__.MyMonad object at 0x90d83ec>

Always returning self is so useful (especially when creating DSLs), that I came to expect this feature everywhere ;)

Monday, March 14, 2011

LISP love

... or why Porsche Spider is cool

Few days ago I posted some unpleasant truths about LISP. Today is the day to straighten some things up: I love LISP. I won't use it for producing code, but still admire it, and think that it was a very good investment to learn a little of it.

Why you should learn LISP

  • It will make you better programmer to an extend you'd never think it was possible. If you only know one or two programming languages, you'll feel like a hacker.
  • Your code will become clearer and much shorter
  • You will swear when you encounter lack of that cool LISP feature in your production language. If your language lacks map, reduce or filter - you either implement it or change language to one that does have them (like ruby or python). This or that - you'll be better off to know what is possible.
  • If you use javascript, you will understand, that this underestimated language has nothing to be ashamed of, compared to Java. Quite contrary: java is primitive, feature-less, bloated, slow and ugly compared to javascript. You will learn, understand and love important javascript features like function as primary object, objects {created: 'like this'} and closures.
  • You will deeply understand recursion and actually start using it in your code. This means using trees as data structured and S-lists (lists that have both normal objects and nested lists of objects as members). If you take time to check out TCO (tail call optimization), you might however never again program your math algos in anything but LISP.
  • You will become more productive and efficient in all languages you use.

That's right, it pays to learn LISP (think Clojure).

Then why you ranted at lisp?

Because LISP is like a 1956 Porsche 550 Spider [movie1, movie2, history]. It's a miracle of racing car engineering, has great sound and stunning look. But by today's standard it's slow.

It might be bad taste to compare it to racing cars of today but... well.. it's slow.

  • It's classy.
  • James Dean owned it.
  • Racing it would make you better driver you imagine possible. It would make you a mechanic to own it.
  • It's slow by todays' standards. Spending 50x less money on a car would buy you ridiculously faster track car, easier to drive and more reliable.
  • And the worst: It's very hard to drive that little devil. You need talent to be fast with it.

Nothing will ever compare to the Spider. Nothing. But you wouldn't use it to race today.

It's even cheaper to use a purpose-build crouch rocket like Python or Ruby ;)

Thursday, March 10, 2011

LISP rant

I started to learn lisp december '10 with the book Programming Clojure. It was first language I started to learn in many, many years - being tied to Java.

I've been enlighted and astonished. LISP totally 0wned me for few months. I finally understood recursion, functional programming and many other important concepts of software craft.

I started to play with WebServices (AXIS) and twitter client. Then I wrote a very simple templating engine, similar to what can be seen in LIFT Framework. Started to think of building even more, but ...

then it came to me... I work too slow.

Yes, it took me far too much time to write all the above stuff. Was it my fault? Yes, of course. But it made me stop and look closer at the whole LISP thing.

Bad consequences of LISPing

  • At first glance, LISP (even Clojure) is as readable as Perl
  • LISP macros were a inspiration to C preprocessing macros. Anyone who ever tried to read huge code written in C, particularly GNU projects, would probably agree with me: this is unreadable stuff. You need to establish a parser in your head with a huge heap, just to read a few-liner.
  • Writing macros is the only possible reason to use LISP over other languages. But writing them is so damn hard, and you're stuck helpless with very unhelpful
    Var clojure.core/unquote is unbound
    every few minutes.
  • While having hard time with LISP, one might overlook how powerful Python become over last few years.
  • While wasting time on LISP one might not notice how Ruby is powerful enough to beat LISP with one hand, and serve you cold drinks while you enjoy your work. Yes, powerful enough. Can't imagine why would one want more than Ruby provides.
  • Clojure (no LISP actually) is not object-oriented at all. This makes you change the way you think, while the whole world of libraries is in fact fully OO. Hard stuff. Fun, but hard.
  • The whole concurrency-problem stuff that Clojure tries to solve so badly is way overrated. You just don't use global/class variables nor static fields (java) and you're good to go. In no time we'll see NoSQL databases or Memcached being used instead of IPC/SHM. General, simple, fast and handy. And thread-safe.
  • No one gives a damn what language you write your framework in. Customers care if they can easily navigate your website and if PayPal button works. Actually everyone should thing of end user and stop whinning about the whole languages stuff. PHP is better if your site written in PHP beats LISP elite code gardens.

These are bold statements, young man.

Yes sir! Thank you sir!

However I humbly ask you to please read these rants as LISP:
How I lost my faith (very long) - comp.lang.lisp | Google Groups - 2002
What are programming languages for? - by the same author, 6 years later.

Key quotes

What's more, once I got knocked off my high horse (they had to knock me more than once -- if anyone from Google is reading this, I'm sorry) and actually bothered to really study some of these other languges I found *myself* suddenly becoming more productive in other languages than I was in Lisp. For example, my language of choice for doing Web development now is Python.
There's another problem with the shorter-is-better premise, which is that the brevity of a program is much more dependent on the available libraries than on the structure of the language.
What I lost faith in was that Lisp was the best programming language for everyone (and everything), and that the only reason that people didn't use Lisp is that they were basically ignorant.
Unrelated, but too good to miss
In fact, I am in certain circles a notorious critic of UML, which I consider one of the biggest steps backward in the history of software engineering.


So.. sorry Clojure. Python won my heart by being simple (and not being PHP) when I was young. Now I'm mature and choose it because it's powerful enough for me and yet readable after years.

Wednesday, March 2, 2011

Steve Jobs: flash? No thanks.

Steve Jobs posted (2010) his reasons not to support flash on iPad and iPhone:

  1. Flash is closed, proprietary product and we (Apple) have own open WebKit standard for browsers that makes flash obsolete
  2. H.264 videos are widely available, so users won't miss any content. Flash games? We have our store full of games instead. No farmville, sorry :P
  3. Bad security record for flash technology. Poor performance.
  4. Without hardware video decodec, flash drains precious battery. <video> is hardware accelerated. This is very importand on mobile platforms.
  5. Mobile interfaces don't use mouse. They use Touch ©. So, ... no onmouseover or any other rollover effect - flash apps needs to be rewritten (so use HTML5 this time).
  6. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features.

Is he right?

Yes, because he has the money :> But also, sadly for flash developers, his is very, very right and insightful on flash technology. While having competing product (WebKit) is not an argument by itself, having open source competing product is. WebKit browsers made it possible to have animated demos in HTML5 on every possible device (Firefox/Chrome made it possible on non-mobile machines before).

Observe how mobile technology drawbacks (battery life, CPU performance) now drive the web industry. Drains battery == Bad idea. But my PC does not have a battery? -> PC is obsolete.

Third party development tools hinder innovation. Bold statement. But, sorry Adobe, this is so true. I made a few Flex apps (video players mainly) and noticed:

  • poor documentation, sometimes missleading - you really need to copy a widget from Adobe sources, you can't extend almost anything.
  • inconsistent, overcomplicated, legacy-based API
  • Simple things (including a image as background) made hard
  • Big Ball of XML. Impossible to enhance some of XML components with ActionScript code.

Bad developer experience, Flex is going in wrong direction. Flex 3 was pretty nice and much more powerful that javascript at the time it war released. But now HTML5-generation browsers are so fast that writting operating systems in javascript seems actually a good idea. Backed with full CSS3 support, the HTML reclaims what flash has taken.


HTML5 already won. Jump in and don't look back.

I've been informed that Apple decided to bring back the flash support for iOS. It's slow and quirky but it works and the doors are not closed. So, no, HTML5 still has a way to go before it prevails.

Tuesday, March 1, 2011

Being project-managed: survival guide

As programmers we are part of projects that are project-managed. Whatever that would mean, our payroll and job security often depend on projects' successes. If not, lucky you to work on badly managed, yet resorceful company. Go get a raise :)

For unlucky rest of us, I present this survival guide.

Duties of project manager

  • Deploying on time, high quality, working software
  • Fitting in budget constrains
  • Communicating clearly expectations and duties
  • Shielding programmers from client 'interference'
  • Establishing 'find the solution' and team working culture in face of trouble
  • Discovering and stopping 'just one more little change' stream - keeping scope under control
  • Taking the blame for failure or being a source of success

Types of project management

  1. Planning success. There is someone assigned to manage and he/she takes responsibility of leading the process from beginning to the great finish. Customers are happy and so is the internal team. Manager is exhausted, but drives home in Porsche.
  2. Planning failure
    • There is someone assigned to manage, but that person is not fully experiencing bad consequences of his/her mismanagement. For example: going over budged or finish date is not only his/hers problem. If manager cannot be fired after series of unsuccessful projects, or gets away with it because of unrelated (or unprofessional) factors, we have a problem..
    • The person assigned to manage has other duties in project. The more important are those duties, the bigger the failure.
    • Person in charge is paid for other things that could make up for project failure lack-of-bonus. Example of this would be never-negative bonus for both selling the project and for project implementation outcome. There is huge moral hazard here.
    • Someone is charged with management but no one is professionally evaluating his/her work.
    • A manager is a Holly Cow and knows that. Run away from project.
    • Your boss (or his boss.. or) is dependant on (family, love, sex, blackmail, friendship, drug dealer) the manager. This is really bad. Quit immediately if you discover such dependency or risk serious consequences.
    • No single person is doing all things described as PM duties. That actually can be played to make you a beneficent of process design failure. Think Wally from Dilbert series.

Why do I care?

Your work is evaluated in relation to the project. If project fails, you are part of failure. No raise, no respect. You should care about project management because projects needs to be managed to succeed, little beasts.

Persistence of management failures

If projects fail, how the company prevails? If you ask this, maybe you know too little of your company? Maybe you assumed wrong business model? What if your company earns 90% on hosting the solutions not on programming them? What if your clients also undergo moral hazard of not depending on project outcome? Example? A corporate manager in charge of huge budget that wants part of it for himself.
What if there are many projects in parallel and internal accounting process makes it impossible to evaluate financial outcome of managers work?
What if company makes so much money, that no one cares about projects you are part of?

Bad management sometimes exists also because of high pressure to use Project Management Methodologies (while forgetting WHY WOULD YOU USE THEM IN THE FIRST PLACE). If you use methodology just for a buzzword or have established a culture of 'I made this by the book, don't blame me' - your company might soon fail.

Bad management survival guide

  1. If bad management is common in your company, you'd probably benefit from quitting it unless you are paid very well. If you feel underpaid, there is no hope for raise unless you change jobs (because your work is judged in context to projects). Think twice however whether what you do, is worth more than you are paid - because that's the reason to have you employed. Do that every day - advice from Chad Fowler's 'Passionate programmer'.
  2. If you are offered some executive job, make sure that bad management won't affect you. If in doubt, assume that it does and refuse the offer. Team management is tedious no-fun, no-hacking job. Unless it would give you a huge raise (>25%), refuse. Why previous team leader quit? Got promoted or fired? Promoted to do what? What kind of person is he?
    Little raise + bad project management == frustrated programming team leader. Been there, done that.
  3. Do not ever try to fix company processes. Not only will you fail, but would seem like undermining your boss' position. That is a great "you're fired" opportunity. If you can't live with that, quit your job.
  4. If there are successful projects in your company, try to join those teams. Escape failure-generating platforms, managers, technologies. Be associated with winning or find solutions outside.
  5. Don't ever say it publicly in company what you think about bad project management. Suck it up, smile and do your job. Read Hackers and Painters by Paul Graham to understand why.
Any comments? :-)


Friday, February 25, 2011

Google updates search algorithm


Read @searchengineland
Read @google blog

What's new?

Google was lately (Jan '11) accused of allowing content farms to gain high page rank. We have their answer now (for US market). This is major change affecting 12% of search results, thus we have an revolution.

This actually is very impressive as Google is one of the biggest corporations in the world. They had a major flow undermining their credibility and they were able to come up with an proper answer in ... 3 weeks? Most medium companies wouldn't even had a plan in such a short term.


Google noticed that most of today's internet is copy & paste (aka webspam). They found a way to find out where the chain starts (ie. information/signal origin) and rank it waaay higher than copies. Good, wise, simple (to explain at least :).

Impact is on those who mainly copy content and on linking-only sites (without comments and so on). In short: the less home-brewn content, the lower the points in rank.

How that affects content farms

Since content farm is just automated copying of prepared content with little changes, whole farms hopefully get taken down with this change.

This is however a war for really big $money$ and webspammers might come up with something new, like using HBGary's idea of creating and managing whole fake societies (aka Sockpuppet Management Software). That would give them randomized social content, forums full of generated posts and so on. That would be hard to catch, because social activities are very, very hard to measure with math. Also facebook makes real humans' conversation very shallow:

Friday, February 11, 2011

End of Nokia?

There have been numerous posts about Nokia going down because of partnership with Microsoft.

I can't imagine any other reason to write such things than "being first with any blog post".

Granded, Microsoft is rightly hated by all of linux/java developers and Apple lovers. But why would such a partnership be bad for Nokia? And why it would be bad for us, customers?

Pros of this partnership

  1. Microsoft has way better developer tools than anyone. No, Eclipse cannot match Visual Studio for average developer. And this market needs thousands of developers, not just stars that code Java or lisp in simple text editor (like me :P).
  2. Microsoft knows how to drive developers to platform, how to document APIs, how to lay an infrastructure to making money developing for their platforms. They are very, very good a that.
  3. C#/ASP.NET community is huge and so far had nowhere serious to put their skills as far as mobile development goes.
  4. Nokia knows what is important in mobile devices and how to keep high quality. Microsoft does not know that.
  5. Nokia is light years ahead of Microsoft in terms of design of small devices. No, xbox 360 controller is not a small device. Kinect neither. They are great, but not small nor mobile.

What we have with Micronokia is a partnership of market leader in software development with strong player and recognized brand in mobile devices. Something like beer maker partnering with dvd-rental stores to make your evening even more enjoyable.

Now, what's BAD about that?

Cons of partnership

  1. Microsoft is dangerous trojan-horse, unfair player and evil incarnation in one. That's a real problem until you consider that all mayor enterprises probably are the same, just not prooven to be that evil so far. Besides, who cares?
  2. Microsoft is gonna sue everyone for infringing patents. Great, but that's american law problem and american market. And google has money for lawyers. I won't pay a penny no metter who wins the trial.
  3. Nokia partners with most heated ... wait..

There arguments are all either based on accusations or emotions. Take a look at Pros and use pragmatic common sense. We may all only benefit from strong, prepared players joining the market. Like maybe devices would drop prices? Or maybe someone finally does some cool mobile Xbox-aware toy?

Have faith brothers in free market...

Friday, January 21, 2011

Simple bounce demo of HTML5 canvas animation

Animation in canvas

No images used!

One of frames embedded inline

as img src="data:image/png;base64

Monday, January 17, 2011

Developer Driven Development?

One of bloggers argues that in development process, the developer part is the most important. Not the tests nor the processes, but brilliant star-like personality.

See the post and discussion below
There has also been a discussion on Hacker News lately

Of course I fully support the bloggers opinion - developer is the key to project success. Tests and procedures are very important, but good design, and clean, simple code is much more.

Unfortunately, what I believe is most common is the Get Me Promoted Methodology (GMPM), described here. (along with Asshole Driven Development and so on ;-)

Supply and demand

The fundamental fact of the software industry is that the demand for software exceeds the supply of good programmers by about an order of magnitude.

The problem with good design is that it's good because it takes under consideration future changes and maintenance. But TDD allows for less painfull maintenance of bad code. So what does a bad programmer do? He sells quick-dirty-hack-shit to your boss and gets promoted for that over your ass.

Yeah, ever thought why bad code exists? Most people work for money, not for deep soul-clearing feeling of sending out perfect lines of holy code.
That's the sad reality besides TDD buzzword...

Wednesday, January 12, 2011

Math generates beauty

It's not the first time math shows beautiful face, but this time everyone can appreciate it:

This incredible silky-hazy image generator is one of the most beautiful things I've ever seen on web. White background wallpaper with blue silk is like my dreams came true.

Monday, January 10, 2011

WebServices is a massive mess - AllegroWebAPI

Context note for non-Poland-based readers

Allegro is polish e-bay style auctioning service (actually e-bay was unable to compete with Allegro on local market). Allegro engeneers have set up a Web Service AllegroWebAPI, which is base for discussion below:

First WebServices encounter

I have recently read SOAP: S stands for Simple article, and became a little worried.
Till that moment I haven't considered WebServices as Evil incarnation, the way article's author describes it. I respected that technology as is seemed so Big and Professional. One can even get a Sun's certificate for it: certyfikowańá.

I decided to finally take a first step towards learning WebServices and went for Allegro Web API. Downloaded Axix 1.4 (Allegro uses very old style of WSDL), generated SOAP Proxy as ant suggests (polish, see scripts only) and used it to login to allegro.

Next I have inspected the SOAP proxy code that Axis generated and, man this is scary!

  • Proxy weights 1.5MB
  • Code has > 8000 lines
  • Coding style does not differ substantialy from C macro-cluttered garbage
  • methods do not return values, instead relying on side effects on Holder objects

Now this is WRONG path. This is not object programming and this is functional programming neither. This is Big ball of mud heading straight to unmaintainable, buggy applications.
How such a mess can be so widely used?

Few days later..

API changed. Whoa, my app no longer works - I need to regenerate my SOAP proxy just to log in. There is no way to know for application that WSDL needs to be reprocessed. Unless of course application reads developer forums. Mine doesn't, I'm toast...

The moral of this story


SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(...)), usually overlaid onto the HTTP 'POST' verb. This disregards many of HTTP's existing capabilities such as authentication, caching and content type negotiation, and may leave the application designer re-inventing many of these features within the new vocabulary. Examples of doing so may include the addition of methods such as getNewUsersSince(Date date), savePurchaseOrder(string customerLogon, string password, ...).

Please drop the SOAP - another rant about SOAP bloat.