Every now and then I have contact with a few programming languages and this is the subset that I believe it would give me a very close insight to the sum of the all languages that I’ve had contact with. Also, this subset is not only based on the choice of ideas that each language aggregate, but also on their usefulness and importance for the general programmer’s toolbox.
Just about the most awesome way to describe and manipulate words from regular languages. No matter if it’s used as communication purposes within some specification or if it’s used to crawl certain patterns within a large collection of texts. It’s useful even within the programming environment itself. And to contribute to its awesomeness, it’s one of the easiest and fastest things to learn. It’s useful even for non-programmers (think about that time when you want to rename all files from a folder to have better consistency).
You can visualize regex patterns using Regexper or any of its competitors.
Started as a simple tool to pretify common syntax used in text-based email. But now just about almost every major site visited by programmers (e.g. StackOverflow, Reddit, GitHub, Doxygen-generated ones) has some support for MarkDown. Or its recent attempt for a smart standardization to spread good common practices and inspire better interoperability among supporting tools.
You can think of MarkDown as a simple way to describe which parts of the text will be bold or will be the tittle for a subsection and so on. MarkDown is simple! MarkDown is simple enough to be accepted in non-programmer targeted products like blogging platforms (even WordPress) or discussion platforms.
A language that appeared in 1972 that is still interesting and it’s still important. Being the “portable Assembly”, operating system’s kernels are still written in C. Pieces of software dealing with low-level are still written in C. Embedded projects are still written in C.
C is not a popular language out of merits. C is just the right abstraction to forget about Assembly, but still have no overhead between your software and the machine. Compilers will do a fantastic job in no time for you.
C is an easy language to learn, adding just a few handful abstractions like subroutines and structures to learn. Of course, C is very low-level and you’re expected to face manual memory management (and memory leaks), bit by bit serialization, pointer to functions (no closures here), architecture and operating system differences and maybe things like varargs, setjmp and mmap. You should be able to understand the implications on performance some decision has. This insight is something C has been a great language at and will hardly be acquired learning another language.
Haskell is one of the languages I learnt this year. It’s a typed purely functional language. It’s a great language. It has great concepts to decrease the total number of lines of code you should write (like list comprehensions and pattern matching), a clever syntax and some great concepts you could learn (higher-order functions, currying, lazy evaluation…).
Not all about Haskell was new to me, as I had already learn functional programming through Scheme some years ago, but Haskell does a much better job. I hate Lisp naming conventions (car for the head of the list, seriously) and excessive number of parentheses. You shouldn’t have to follow my path. You should be introduced to functional programming with Haskell.
Also, look at how elegant this QuickSort is:
Ruby is another of these languages I learnt this year. It’s a purely object-oriented language. Some cleverness was invested around its syntax and I very much appreciate this. It’s a very dynamic language where every class is open and even things like attr_reader are methods.
Object-oriented programming is one of these must-have skills for a programmer and I think Ruby, being purely object-oriented, is a great language to learn this paradigm. Hide and encapsulate!
I choose to learn Ruby looking for a scripting language to empower a possible game engine that I might code. Ruby really impressed me. Ruby is so dynamic that even if I design a wrong class hierarchy or something, Ruby probably has a way to fix it. I don’t intend to design bad hierarchies, but I don’t know who will use my possible future game engine and this concern then becomes undeniably important.
Responsible for most of the web traffic, this is a pretty important and simple language to understand how web documents are structured. If you think I’m overestimating web, it’s because it’s one of the greatest things we have. But XML is not only about web, it’s about interoperable documents and protocols and it is used as such. You can find XML in use within vector formats, formats for office applications and even chat protocols. I think learning the basics of XML is a big deal.
I personally think that the LaTeX tools aren’t among the most polished tools. Just look at the Makefile generated by Doxygen to see the run-until-no-more-differences-found loop to work around inconveniences in the LaTeX tools. Or just look at the terrible error messages. Also, the syntax isn’t surprisingly pleasant.
But when you want to focus on the content, forget about the accumulated little formatting details and produce beautiful scientific papers, a book with consistently in-between linked references or even just a few math formulas, LaTeX is probably what you should, at least, consider.
Capable to automate the most surprising tasks in a computer, if you are using an Unix variant system. You could automate builds, customize software startup sequences and manage your system. But if you’re using an Unix variant system, you already may be aware of that.
No Java, C++ or Python in this list. Maybe I’ll do a part 2 of this article containing languages with a lesser chance to be used like SQL, MongoDB, OpenGL, R, GStreamer or some Assembly. Actually, I think Java, C++ and Python have a better chance to be used than Haskell, but if you learn every language in this list, C++, Java and Python will be easy to catch up and the lines of code you write will be more elegant.
Till today, I didn’t read a post defending PHP. There are all these texts attacking the language. And I dislike most of these texts I’ve read. I don’t like the attacked PHP language either. But what I dislike above all is the excessive use of fallacies. How could we have a logical discussion if we keep using them?
I don’t mind if you share a personal experience that cannot be used to prove a statement. If we’re lucky, your experience might be fun to read or will teach us to avoid specific behaviour in specific circumstances that may apply in specific ages.
I don’t mind if you carefully expose facts that the creators want to hide from us to affect our level of trust to such creators, as long as you use evidences to sustain such facts. You aren’t trying to logically prove something, but you text is also useful.
I don’t even mind if you create a text completely relying on fallacies, but I mind a lot if someone use such text to justify a decision. These texts, to my experience, tend to be fun anyway.
So, there are the two following linked texts about PHP, and in one of two, the author demonstrate more PHP knowledge than the other. Which one deserves more of your trust/attention?
Eu sempre me preocupei com acessibilidade, até um certo ponto, mas nessa situação costumei ser o tipo de “preocupado passivo”, não agindo muito mais que o básico. Entretanto, tem uma palestra que ocorreu no FISL14 sobre acessibilidade que me mostrou que um pouco de conhecimento é tudo que você precisa para melhorar muito a acessibilidade do conteúdo que você cria, pois o esforço necessário costuma ser negligenciável (tarefas que você precisa fazer de qualquer forma, mas fazer pensando na acessibilidade).
Enfim, assistir essa palestra é algo que eu recomendo a todos que criam conteúdo na web:
Essa palestra foi o que me ensinou a evitar links do tipo “clique aqui para saber mais” aqui nesse blog. Minha preocupação só diminui quando o conteúdo é inacessível de qualquer forma (filtros de imagens, por exemplo).
It’s been two months already since my last post on this blog. All this time (and more), I’ve been (among other tasks) working on my 2014 GSoC project, an HTTP server proposal to Boost. I’ve finally reached a point where I feel it’s ready for major review/feedback.
If you’re a C++ programmer, a native speaker or an HTTP researcher (or just a little of everything) and you want to help, I’d like to ask you to review the project (interface-wise) and give me feedback.
This isn’t my first time on GSoC, but the experience was very different. The communities, development model, targeted audience, knowledge domain, to name a few, were completely different. Also, this year’s project wasn’t as challenging as the last one (although this is very subjective).
I improved as a programmer, but this is limiting. Once you become able to write algorithms for turing-machine compatible devices, there isn’t much room for improvement and you need to hunt other skills to continue improving (e.g. security, parallelism…). Coding for the sake of coding solves no problems. I decided to take a break (not exactly now, but in a few weeks) to make a shift and start to increase the efforts I dedicate to my academic skills.
I aim to integrate this library into Boost, so I still want to invest effort in this project.
I created a new category on this blog to track the progress, so you’ll be able to have a separate rss feed for these posts. The new category URL is https://vinipsmaker.wordpress.com/category/computacao/gsoc2014-boost/.
Espero mostrar rapidamente o histórico do projeto e usar o tempo restante para a motivação, reservando 10 minutos ao final para perguntas. A motivação deve incluir uma pequena explicação de como funciona a web e seus principais pontos, comparações, becnhmarks (esse é um item mais difícil), limitações, exemplos e um “tutorial”.
Devo preparar uma nova aplicação de exemplo que explora características presentes no Tufão.
After a long time developing Tufão, it finally reached 1.0 version some hours ago. I’ve spent a lot of time cleaning up the API and exploring the features provided by C++11 and Qt5 to release this version.
This is the first Tufão release that:
- … breaks config files, so you’ll need to update your config files to use them with the new version
- … breaks ABI, so you’ll need to recompile your projects to use the new version
- … breaks API, so you’ll need to change your source code to be able to recompile your previous code and use the new version
- … breaks previous documented behaviour, so you’ll need to change the way you use features that were available before. But don’t worry, because the list of these changes are really small and are well documented below.
Porting to Tufão 1.0
From now on, you should link against tufao1 instead of tufao. The PKGCONFIG, qmake and CMake files were renamed also, so you can have different Tufão libraries in the same system if their major version differs.
The list of behavioural changes are:
- Headers are being stored using a Hash-table, so you can’t easily predict (and shouldn’t) the order of the headers anymore. I hope this change will improve the performance.
- HttpServerRequest::ready signal auto-disconnects all slots connected to the HttpServerRequest::data and HttpServerRequest::end slots before being emitted.
- HttpFileServer can automatically detect the mime type from the served files, so if you had your own code logic to handle the mimes, you should throw it away and enjoy a lesser code base to maintain.
The list of changes:
- The project finally have a logo (made by me in Inkscape)
- Deprecated API was removed
- Url and QueryString removed in favor of QUrl
- Headers refactored to inherit from QMultiHash instead of QMultiMap
- Constructor’s options argument is optional now
- setOptions method added
- Constructor takes a reference to a QIODevice instead a pointer
- Constructor takes a reference to a QAbstractSocket instead a pointer
- socket method returns a reference instead a pointer
- url returns a QUrl
- data signal was changed and you must use readBody method to access body’s content
- the upgrade’s head data is accessed from the request body from now on
- now the object auto-disconnects slots from data and end signals right before emit ready
- setCustomData and customData methods added
- Now HttpServerRequestRouter use these methods to pass the list of captured texts
- HttpServer uses reference instead of pointers in several places
- AbstractHttpServerRequestRouter refactored to explore lambdas features
- Tufão’s plugin system fully refactored
- It’s using JSON files as configuration
- It uses references instead pointers
- It receives 2 arguments instead of 3
- One more abstraction to sessions created to explore lambdas
- startServerHandshake is taking references instead pointers
- LESS POINTERS and MORE REFERENCES
- This change exposes a model more predictive and natural
- I’m caring less about Qt style and more about C++ style
- But don’t worry, I’ll maintain a balance
- Using scoped enums
- HttpFileServer uses/sends mime info
- Interfaces don’t inherit from QObject anymore, so you can use multiple inheritance to make the same class implement many interfaces
- HttpUpgradeRouter introduced
- HttpServer::setUpgradeHandler also
- Updated QtCreator plugin to work with QtCreator 2.7.0 and Qt 5
I want to improve the Tufão’s stability and performance, so now I’ll focus on a minor relase with unit testing and some minor changes.
After Tufão 1.0.1, I’ll focus on BlowThemAll.
You can see a visualization video based on the history of commits below.
This release deserves a wallpaper, so I made one. See it below:
You can download the source of the previous wallpaper here.
What are you still doing here? Go download the new version right now!