Some good reasons for learning python

President Obama thinks required programming language learning in high school is a great idea. So do I, and I think we should all start with python. Writing code with it is very fast. When software engineers tell you “I can do it in 10 minutes”, in C/C++ they mean 4h, in java they mean 2h and in python they mean it. You can really do anything. I’ve done some serial communication, bit level manipulation, network level event-based servers, multithreading, webservice providing and consuming, SQL and cassandra client faster than what I’ve been doing in any other language. It’s easy to learn. You can start your first program right now and be good at it in 2 weeks. It comes “batteries included”. You don’t have to install third-party libraries. Contrary to ruby, you don’t have to choose between the thousands of gems available, there’s almost always one official way to do things. Which leads to the next point: It’s simple to read someone else’s code. This is because it’s high level language and you quickly know all the librairies. It now has some IDEs. I know some people like to code in vi, but this is ugly and unproductive. Pydev is simple to install and supports a pretty good (or not so bad) auto-completion. This leads me to two opposing ideas (but you’ll understand where I stand): ...

February 21, 2013 · Florent Clairambault

TC65i development on Mac Os X (or Linux)

This is now on the wiki.

May 23, 2012 · Florent Clairambault

Technology brotherhoods

I often hear people talking about which technology is better between C / C++ / C# .Net / java. Most of the time, it’s more a political/brotherhood/community thing (like football, even thought frenchies like me aren’t so proud of their team now) than a technical talk. I find it absurd. Computer science is about efficiency and making more money. You can take into account the pleasure you have to work on a technology (as you will be more likely to be more efficient with it), but it should still remain about efficiency. ...

July 6, 2010 · Florent Clairambault

TC65 : Slow UDP reception

Introduction Receiving UDP datagrams on the TC65 is easy but inefficient. You need to create a new thread if you want to receive data asynchronously. There’s no way of knowing if a new datagram has been received or not without hanging on the ::receive( Datagram ); method. This is quite weird considering you can do it in TCP. The real problem is it’s freaking slow. The Cinterion documentation just tells you “This method blocks until a datagram is received.”. What it doesn’t say is that nearly each time, it blocks for 100 to 700 ms after UDP datagrams have actually been received. And worse, this slowness/sleeping avoids the program from treating data and finally throws a little java.io.IOException exception : “No buffer space available”. I tried to give the udp receiving thread a higher priority than the other threads, I tried to make the TCP reception thread sleep a lot just in case it would lock some kind of network object, I looked on how could this method be implemented but couldn’t find a solution and don’t believe there’s one. ...

May 10, 2009 · Florent Clairambault