by Robert Zaremba

A simple way for polymorphism and structured programming - Go interfaces

On 2015-01-08 I was presenting different polymorphism methods at Institute of Computer Science University of Wrocław. I’m a big fan of simplicity in IT. During that presentation I was trying to persuade why we need simplicity in IT: both for maintenance and high quality software. One of the most important programming language feature to make a program source code more conscious is polymorphism.

Polymorphism is a very broad term. It can mean anything from having different shapes to sharing some functionality. It can be very powerful (eg Haskell, Agda), mean (C), flexible / dynamic (Python) or powerful-obscured (Scala). There are hundreds of features researches are implementing in theirs programming languages. However, It’s a difficult art to select a minimum set of features which will bring simplicity and productivity.

My lecture leads to one language which accomplish that art pretty well: Go. It still lacks few features to get a really good productivity (eg genetics, however thanks to go generate we have some workaround).

I’m calling this achievement Zen of Go: it provides a minimal, basic syntax and constructs in a spirit of Zen of Python, powerful runtime with build-in coroutine scheduler (in Go we call them goroutines), convenient structures for parallelism and static typing - just to name few of them. What’s really important the language is minimalist - check the Go lang spec and try to compare it to any other popular language.

All in all, the overall result is remarkable. There are thousands of blog posts about Go, both positive and negatives (in my opinion people who present Go in a bad shape either didn’t use Go or they use it in a wrong domain - think about using assembler in web programming). One is sure: a lot of companies are migrating their software to Go (with Google in the first place). Recently, with 1.4 release Go become first class language on Android. Companies are happily sharing success stories. This proves that decisions for simplicity and a dynamic (weak) polymorphism (which is the usual wart in the negative go related articles) are working well for big projects. Personally I’m using Go in production since the end of 2012 and I’m very happy for it. It doesn’t fit well for all domains I’m working in (eg. for data mining environments like matlab or lua-torch are better situated) - but as always, let’s use the right tool for the job.

Please enjoy my presentation:

Bottom line after presentation @ii

During the presentation there was a weird guy who was suggesting that Rob Pike will kill for not using go.talks (he even didn’t know a name of the tool). I’m still alive!

Frontend components in React

Last week I made a presentation for meet.js PL about React. meet.js is a free front-end meetup organized by web enthusiasts in 6 major Polish cities - Warsaw, Gdańsk, Poznań, Wrocław, Cracow and Katowice.

In a nutshell, I presented why we chose React among other available options (ember.js, angular, backbone ...) in AgFlow, where I’m leading an application development.

Also I try to highlight some problems with MVC pattern everywhere.

I really like a way of React frontend components development. It makes more clear for us to implement use cases views.


meet.js notes

After the presentation I was asked several times how react handles relation with a model we want to present. During the talk a wanted to highlight that React is not about implementing a Model, but a way to construct visible components with some state. React is simple. It is super simple, you can learn it in 1h. On the other hand what is model? Which functionality it should provide? React does one thing and does it the best (for me)!

There are bunch of libraries which handle non visible part of web front-end, which we can easily incorporate for:

  • browser-server real-time synchronization
  • routing
  • collections
  • router
  • history
  • schema
  • cache, storage
  • templates (still we didn’t encounter a use-case to even think about them)
  • proxy ...
  • notifications

It’s worth nothing that some of those features are such easy to achieve, that we don’t need to use a heavy machinery to implement it.

In Angular I can do X

Sure, there are bunch of features implemented in Angular which are not available in React. I admit that React is not as powerful as Backbone. Again: React does one thing and does it the best (for me)! But we are super satisfied what it does.

We could afford for a choice of technology. We chose React.