I started a fork of a diary application which is written in bash, because I thought there are some things missing and some features could be added – and the repository of the original author was really old.

I started to pretty it up and implement some 21st-century things so it becomes a really nice note-taking application.

So, initially the application was called “diary” and developed on sourceforge, by Jamie Briggs. Someone created a fork, named “diary-f”, which added some features.

The lastest change in the original repository is from February 2013, which is almost two years ago by now. The last change in the repository of the fork is from three years ago – even longer, yes!

So, the application per se is really good one. It is just a small shell script, but it works really good for me. Anyways, I missed some features, namingly:

• Multiple separate entries per day
• Everything should be kept in git, so I know when I edited the articles
• GPG encryption everywhere

I started implementing multi-file support directly in the “diary-f” repository, but then decided to create a fork, as it won't be compatible with the original software anymore. By now, three things are done in the repository: I refactored the codebase to fit my coding style (well, it is still bash, isn't it?), mutli-file support as said and git support. I want to implement gpg support next and maybe the ability to add attachements to entries. And after these things are implemented, I want to be able to search the entry repository for certain entries in a simple way, which could be difficult, given the fact that everything is encrypted in there.

---

If you're interested in the application, I'd welcome pull requests for almost everything. Contributing guidelines are:

• Document your work, how do things work?
• KISS
• DRY

That's basically it. I'm looking forward to your patches! tags: #bash #git #open source #programming #shell #tools

I have a problem. I want to write a small application. It should be a commandline application, but maybe I want to extend it later with a GUI or even a web interface. But I don't know what language to write it in.

This article could also be named “Which is the right tool for the job?”

The idea is simple: I want to write a journal-application, where one can take notes, tag them, query the journal for entries, optionally provide filters before printing them to print only some of them and so on.

I want to be able to encrypt them with gpg and I want to write posts to the journal with vim. I want to be able to configure these steps, of course, so I can use a certain key for encrypting the journal or maybe another editor (for these emacs lovers out there).

It should be designed to be extensible, so I can add a GUI or web interface later on. Or maybe a tex output, so I can compile a PDF out of it or something. Posts should be written in standard markdown, so this wouldn't be a big deal.

But I don't know what language to write it in. The languages which I can or would choose from are:

• C
• C++
• Haskell
• Rust
• Java (not really...)
• Scala (not really either, it's still JVM)
• Ruby
• Python (by extending jrnl)
• Racket
• Lua
• Bash (I really don't want to write it in bash, but it's still a possibility)

As you can see, the first four languages are compiled languages, then Java and Scala are (lets call it) Semi-Compiled languages and the others are scripting languages. All of these languages have certain advantages over others.

The compiled languages

... have the advantages that they are fast. Haskell and Rust also have the advantages that if the compiler does not fail compiling the sources, the program just works ™.

Also, learning C++, Haskell or Rust would be a really great experience and may be beneficial later in a job or something.

The semi-compiled languages are also (kind of) fast, but they are JVM-languages, so I won't look into them here...

The scripting languages

Writing the application in a scripting language would have some other advantages: They would be much more flexible and I'd be faster writing the application (compared to Rust or Haskell, which I would need to learn with the application). I don't need to learn Ruby, I know a fair bit of Racket and I guess I can get productive with Python or Lua really fast.

Bash is another option and I'm actually an bash script for an almost similar job right now. I could simply extend this script, that would be an option, of course.

So which is the right tool for the job?

Can you tell me? I don't know which tool is the right tool for the job. After all, I don't think I should write such an application from scratch. So, for me, there are two options left: Extending jrnl, which is an Python script, or extending diary (I do not even find a link for this anymore), which is a bash script. Extending the bash script would be an easy job, I guess. But it wouldn't be as flexible as the Python tool is already. tags: #bash #c #c++ #haskell #programming #racket #rust #shell #tools

I'm back from the 31c3, which was absolutely awesome for me! It was my first time at the congress and I met a lot of great people there, so it was a great success.

Richard Stallman, Matthew Garret and other great guys were hanging around at the 31c3, I had a chat with the gnupg maintainer and some students from the Netherlands, people from the Free software foundation and listened to discussions with a gnunet developer.

We, as a project, presented our semester project by giving a lightning talk and hacked a lot on it, too.

So, from my perspective, it were awesome days and I will be there next year again! tags: #programming #software #ccc

So, it's just a few days before christmas, so let me post a short update on waysome! We're currently implementing EGL support and we should be able to implement the API-window interfacing afterwards, which enables one to issue window-moving though the API.

I guess this pretty awesome! Actually, EGL gives us a hard time, because the interface just sucks.

We have already more than 2k commits merged into the development branch, more than 600 issues/pull requests were opened and nearly 600 are already solved. After window moving is implemented, we will start with heavy testing and debugging, to get it to a certain state where it is stable and as much as possible bugs are removed.

I actually hope we can get a basic window manager until the end of the semester, as we're running a bit out of time here.

You are welcome to contribute or just watch it (but we would really prefer that you send us patches, contribute by testing and so on) on github. tags: #programming #open source

When creating an open source project it is really important to get stuff done and working as fast as possible. As soon as the initial project phase is over, things calm down and if the stuff is not working properly at this point, people lose interest.

So, you should try really hard to avoid that and get stuff done as fast as you can, so you have something to show. This does not mean that your stuff should be complete or everything should work as expected, but you should be able to show some basic features of the software, so you can inspire others to hack on the project and improve it.

Because that's what keeps a project living: people and contributors which want to bring the project forward. And if you can show them things, they might get enthusiastic about the project and start contributing!

So, you should try really hard to get something which basically works.

Speaking of my semester project, we're almost at the point where we have something which basically works. We have some very basic functionality, which means we can start a terminal and use it (not everything works as it should, but we're working on it). So, we can show something.

The problem with software is that you don't actually see what amount of effort is put into it. An experienced programmer can, of course, see it, but not the average guy from the street. So, with complexity of software and source code, the need to get something which basically works and can be used, increases rapidly. We in our project have written source code since end of September, we just hit and passed the 30k LOC mark. That's great, because we have a great infrastructure of code, which is really powerful in my opinion. But, by now, we “only” can start a terminal and have some background image. We are not yet able to do more things. This will change in the next few weeks, but by now, a user can only see some really basic stuff. But there's a huge amount of effort put into the project.

The User can't see it. This is were things get complicated (also in regard of our assessment of our supervising professor). As soon as some more infrastructure is merged, we can actually start implementing the API, which can then be used to actually show things, so we hopefully won't have this problem in a few weeks anymore. But until then, I consider this stuff as really critical.

We also have to provide a documentation of the project phase, which will be included in our grading as well, so at least that is not as ciritcal as it seems, but I would really love to have a working software at the end of the project phase. And by now, I don't see we get there. It is not that much left to do, but much enough...

So, in my humble opinion, it is really important that one gets working stuff (in a open source project), so it can be shown to others and can advertise itself thereby.

tags: #programming #open source

So I had a post about my frustrations on programming languages some time ago (the actual date of the previous article on the topic is not right, because I did some blog switching foo since). With this article I try to rethink the whole problem. My conclusion will be different from the conclusion of the previous article!

Haskell, Racket and the others

So, I said in the last article that I want to have a look into the following programming languages:

• Haskell
• Go
• D
• Crystal

And well, I learned a bit of Haskell and it is an awesome language from what I can see so far. But then things changed, I started a semester project I'm now heavily involved in, which is in C. I also had several programming courses at my university where the requirement was C++ and Java, so things got stuck somewhere. I stopped learning Haskell. Sadly.

But in the past few days and weeks, I got my head into a new programming languages, as the careful reader of this blog already knows: Racket. Racket is a Lisp dialect. I comes with an wonderful documentation, a rich feature set (a nice REPL, a documentation tool, package manager which works really well and tries to avoid the dependency hell), is fast and easy to both read and write (at least from what I can tell by now). Racket is kind of my new love in manner of programming languages. I started learning it by implementing problenms from project euler and I want to write a small IRC bot in it, as soon as I consider myself as advanced enough to achieve this.

So, Racket is a functional programming language, but also supports non-functional programming paradigms. This basically means that you also can write OOP-stylish and imperaitvely in Racket. You might say “Yuck!” now, because it is not a pure functional language – but it is really good for me, and I can get my feet wet with functional programming slowly! This matters most for me!

The other languages listed are less important for me. I don't want to learn Go, D or even Crystal anymore. I think, functional programming languages are my next (kind of) goal in life. A lot of people state that they became better programmers after learning a functional language (Haskell in particular). And because my overall goal is to become better at what I love doing, I consider functional programming as one of my main goals in life now. That may sound really vain or limited, but well, I also have other goals in life! They just don't fit into this article, of course!

So,... Haskell?

My goal is still learning Haskell some time, and I will, as soon as I consider myself a good Racket hacker! But for now, Racket has a better learning courve for me. I read a lot about the functional programming languages out there, mainly Lisp/Scheme like languages and Haskell. And a lot of people state that Haskell is a bit more advanced because of its syntax, because you have to consider operator prescendence and some other things, which you don't have to care about in Lisps. So, I can start with a simple language, learning the functional approach, and continue with something like Haskell afterwards.

I saw a wonderful explanation on youtube on Monads just yesterday. I understand everything in this video, except the fourth part, which actually covers Monads. This is also one of the points why I don't start away with Haskell. I want to fully understand the concepts first.

It would be really great to have a course about functional programming at my university, but unfortunately there is none. One Prof has a by-choice-event students can subscribe to, but unfortunately not this or next semester. I hope I will be able to attend the course in one year.

If not, I hope I can do something with functional programming in my bachelors thesis or in my masters degree, if I continue studying. Would be neat. If not, there are maybe some non-university courses around.

But is Racket fulfilling?

Of course it is! You can actually do everything you can do in pure functional programming languages! I just found out how to do function composition and partial application of functions. It is not as simple as in Haskell, but it works exactly the same way (don't consider my statements here too serious, I'm just learning and it feels like it is the same...).

For example, we have this smart piece of Haskell code here:

take5 = take 5

take5 is now a function which is composed of passing 5 to the take function. It takes now 5 values from a list and returns them as new list. Wonderful and simple!

But you can also do this in Racket. I don't know how to do this problem in Racket, as the take function in Racket expects the list as first argument and the number as second. So would need to switch arguments, and I actually don't know how to do this in Racket.

So lets do another example of partial application:

(define (add1-to-list)
  (curry map add1 ))
(add1-to-list (list 1 2 3))
; -> '(2 3 4)

As you can see, I created a function which returns a function that maps the add1 function on a list. Afterwards I applied this function to a list. So it is the same as in Haskell, but with a bit more verbosity, of course.

Side-note: I just found out (thanks to the Racket IRC channel) how to do flipping of arguments:

(define-syntax (flip stx)
  (syntax-case stx ()
                   [(_ f x ...) #`(f
                                   #,@(reverse (syntax->list #'(x ...))))]))

That's the syntax rule, but it is very verbose. Using it is rather short:

(flip / 12 4)
; -> 1/3

But not as nice as you can do it in Haskell. But anyways, that's hairsplitting and I will end this here and now.

Conclusion

• Racket is awesome.
• Haskell is Awesome.
• Functional programming is awesome.
• Yeah!

---

So, to finallize this article now: I'm learning functional programming! It is awesome, concise and clean. It seems to be the best approch to abstract complex problems and address the problem of complexity and abstraction (wanna know more about this, watch the linked youtube video)! I'd love suggestions on tutorials, papers and other reading material to get better. Feel free to send me everything you might consider as a good starting point to get my feet even more wet.

tags: #programming #haskell #racket

I already wrote about the project me and some friends at my university are currently doing. One of my team mates came up with the idea of porting the codebase from C to C++, yesterday the appropriate issue was opened Yesterday, to discuss it. I'm not sure what to think.

The idea is to port the codebase as soon as possible to C++. I do not like this idea entirely, as I think the port should be done after the project phase, but not within. I consider myself at a newbie-like level when it comes to C++ and I think other project members feel almost the same, maybe better, but not on an expert level or whatsoever. Given the fact that we're already running out of time, I think a port of the (30K LOC) codebase would quite take some time and would cause the project to be delayed even more.

So I'm trying to push back on that part. A port after the project phase would be another question, which I want to talk about here.

First of all: I don't think a port to another language is required, as I consider the codebase as very clean and carefully designed. The architecture is good, the code is well documented, the abstractions are clearly defined. A port to another programming language would have a certain level of impact on this, but I think we are able to handle that. I see the improvements which could be made by a port to a OOP(-like) language, though.

Having inheritance build into the language, having a template-like system in the language and having methods, virtual functions and the like would cause some redesign but also some improvements.

My project mate suggested C++ as language. Now, the careful reader knows that I don't like C++ that much. Some of my points are maybe valid, some not. But well, this is a very opinion-based topic, and I won't go into further detail or discussion about that topic here. What I think, though, is that it would be nice to port to a language which gives us more power (simplifying to the terminus “power” here to refer to possibilities to do abstractions, building complexity and the like) and security. I think C++ gives us more power about the code, which is very good. I don't think C++ gives us more security, meaning secure code. I think one can very simply do the same mistakes in C++ as in C, speaking of semantics of the code. For example you can create data races, thread related problems or memory corruption in C++ as well as in C.

That given, I consider C++ as an improvement to the code, but not the best possibility. My opinion is currently that a port to Rust would be a much better option, as Rust gives us memory safety, prevents us from doing nasty things with memory, including all the thread stuff. Given the fact that none of us is able to write Rust on an expert level by now, the question of doing the port within the project phase or after is answered automatically. Also, Rust is not stable yet. I would at least wait for version 1.0 of the Rust language before doing the port, possibly saving some time of Rust-to-Rust porting.

I still don't think a port is necessary and I really like the code we produce. I can see the advantages over staying in C, but for me personally, the disadvantages overweight by now. This may change in future, but for now and for the rest of the project phase, this is my opinion on the topic.

The discussion on github is not done yet, of course. I will carefully propose my opinion there, as this has become a very explosive topic by now. This article was just written to be a short overview over the topic and also to be a summary of my thoughts.

tags: #programming #c #rust #c++ #software

This is the third part of my series about C++.

After some serious discussions with several people, I came to a conclusion. Well, not really a conclusion, as it was clear from the beginning of the series or even before, when I started to learn C++ at my university, but a point where I can say that C++ is not as shitty as I thought before.

Well, even the word “bullshit” isn't the right terminus.

C++ does some things which seem to be really really weird when you first start learning it. After all, I wouldn't suggest it as first programming language to a newbie!

I still consider the syntax of C++ as bloated and not really helpful in certain ways, as (for my taste) one can hide too much of the relevant stuff. One cannot directly see what's happening in a piece of code without knowing the stuff around the code, the infrastructure or at least the types of the variables. Other languages solve this “problem” much better.

I had a discussion with a friend of mine who is really into C++ and he explained the benefits, which I fully understand. I also had a discussion with a friend who is at most a C++-Critic. Both of them made valid points.

After all, it is a matter of taste whether you like C++ or you don't. I do not like it. I can see its benefits over C, but I consider other languages as better. C++ has a historical background, of course. I don't want to ciritcize this, but I think there are other languages which adress the problems C++ addresses much better today.

I'm speaking of D, Rust, Go and the like, of course. I also consider languages like Haskell, Erlang, the whole Lisp Family and the JVM stuff as better solutions to most problems. Not only that I consider them as easier to learn, but also much easier to maintain and less cluttered with language elements one has to understand to work on an existing codebase. tags: #programming #c++

When developing open source software, one cannot chose who participates on the project. At least not when it's the kind of open source project “I start something on github/bitbucket/whatever and if people want to contribute, they can do it”.

When developing open source software in a team, for example in a project from your university or so, you can, indeed, choose your project members. You can't do this every time, because some universities have some fucked up rules that project members get chosen randomly or something, but sometimes you can.

So here are some short notes what you definitely have to take care of when you're in the position where you can choose your project members:

• Review capabilities

Your project members must be able to do constructive reviews, spreading positive criticism. Otherwise, they'll freak you out! I gurantee it!

I always try to be constructive when reviewing source code. I try to avoid terms like “this sucks” or “this is complete bullshit” – these just worsen the mood in the team!

• Skills are not enough – you need enthusiasm

You can choose the most skilled guys around. You won't succeed with your project. Choose people that are not that familiar with the environment but who have enough enthusiasm to succeed. I guarantee you – they will surprise you!

I don't think I'm the most skilled programmer out there – of course not. But I have enthusiasm which keeps me attached to something and I'm willing to improve myself every single day. I think that's much more important than skills per se.

• Enthusiasm + Skills + 24/7 work = Burnout

This is more an advice for you directly, but it can also help you when choosing your project members. If you have enthusiasm and enough skills to succeed with your project, don't work 24/7. It will kill you! Take a break every 7 days or something. Do something else. In another environment. You will be much more efficient afterwards, when coming back to the original project!

I noticed this myself, after 8 weeks of daily working on a project, I had to stay back for one day. The day after that day was much more relaxed than the days before!

• Less skills, but will to learn is more valueable then the other way round

I also like to suggest: Choose members who are not that skilled but willing to learn new stuff. If you do the other way round, they might do a great job, but they won't get better and they will do mistakes over and over again.

As I already said, I don't consider myself as the most advanced programmer out there, but I'm willing to improve. I make mistakes – everyone does, of course! But I always try to think back of previous mistakes I made and I'm constantly trying to avoid making them again.

• If your lifeblood is in the project – always remember that for other project members this is not true

It's sad, but some people do open source just for the sake of open source, their graduation or some assessment at the end of the term or something like that. Always remember: These people are everywhere. And if they are in your project (you may not notice that when choosing them), you can't change that. Just take it as is.

When I'm writing software, my heart is really in it. For others, this is not true. I had a hard time learning this, but it's true. Sadly.

---

Of course, these points aren't carved in stone. But they are taken from my experience and maybe others can confirm. At end, everyone has to make their own experiences.

tags: #programming #open source

At this very moment, I'm writing code for waysome, our wayland based window manager. And it really bothers me that most of the wayland codebase is not documented.

Basic documentation for the API of wayland is simply missing. In some cases, it is obvious what a function gets as parameters, but in other cases it is not. And wayland is not the only problem here, there are other libraries which lack of documentation.

I do not understand why people don't consider documentation as code. For me, documentation is source code and because of that, everything which gets written has to be documented in a proper way.

Also, the wayland people suck when it comes to their build environment. Their documentation is doxygen based. But you cannot generate the documentation using “make doc” or something similar. You just can't, it does nothing.

I don't know what they are doing all day long, but I know it's not documentation.

/endrant

tags: #programming