Compendium of Wondrous Links VI


wondrous_links

  • They finally found all those buried Atari cartridges, and confirmed a beloved urban legend. Just wonderful.
  • This episode of @ExtraCreditz follows up an idea I always had about education. The key is being demanding, but allowing a lot of opportunities.
  • Amazing book introduction, showing how no one is immune to think that they are stupid. Lots of things in live are hard.
  • Readability in code is not about being literary. Is about making the code easy to understand. You don’t read code, you explore it.
  • The Great Works of Software. The premise is extremely interesting. What are the most influential pieces of software?
  • The hilarious (is funny because it’s true) Programming Sucks and a follow-up What programming is Like.
  • Is programming a dead end job? I still can’t help but feel sad each time that a (good) developer decides to move into management.
  • It’s easy to forget how much the things have changed in term of software distribution. What Writing and Selling Software Was Like in the 80′s (yep, also from The Codist. You should subscribe)
  • The computer world is very dominated by English, and even so with latin alphabet. This idea about making a computer language in Arabic is fascinating. It not only shows how difficult is to set up an environment without problems out of “the ASCII world” (the magnitude is not comparable, but trying to code in languages like French or Spanish has a lot of friction), but it also shows up how alien (yet beautiful) a different alphabet looks. I wonder how code and programming will be if the dominant language would’ve been something like Chinese or Arabic.
  • What is the “Agile mindset” anyway? The graph is very interesting. Specially the “Chaos labeled as Agile” side.
  • I don’t really like the idea of “rivalry” against Vim and Emacs. I prefer to consider them two valid options. But this article goes into explaining their different appeals and why they have been around since an extremely long time ago in computer-years.
  • 10 Most common Python mistakes. Good to check.

Compendium of Wondrous Links vol V


wondrous_links

Compendium of Wondrous Links vol IV


wondrous_links

Compendium of Wondrous Links vol III


wondrous_links

Compendium of Wondrous Links vol I


wondrous_linksAs a way of collecting interesting reads across the Internet, I plan to keep a relatively regular posts with some articles and posts that I’ve read, mostly related to development, software and tech world in general.

Here it goes the first edition.

Hope you enjoy it!

Vim as IDE. Are you getting the wrong parts?


There are a lot of discussion about how to make Vim “an IDE”. Vim is a great text editor, but when we are developing, there are lots of extra tools that are very useful. Code completion. Easy navigation through files and classes. Source control integration. Syntax checking. Navigation that understand the semantics. Integrated debugger.

My problem with IDEs (and I have used a few over the years) is that they give you a lot of support, but at the cost of increasing the complexity. They are slow for a lot of common operations and they use a lot of resources. Code completion, the good kind that will allow you to get the types of a method, not just finish your words (which most of the time is trivial), is useful when developing on a static language, but since I  program in Python is something that I can’t find good use of it. I just don’t use all that stuff, so I don’t feel I can justify to pay the price.

Another problem with IDEs is that they tend to be designed, by default, to the newbie. That’s not necessarily a bad thing, Vim is a pretty intimidating tool because is totally crazy for the rookie. But it generates a bloated environment to start with. If you open Eclipse, a popular IDE (and one I’ve used for some years), you’ll get a relatively small frame for the code, and a lot of extra stuff surrounding it. Logs, file navigation, class definition, a huge toolbar, maybe even a TO DO list…

This is a lot of stuff!

This is a lot of stuff!

For example, think about file navigation. Sure, it’s useful to move around. But it is used only at certain points in time. Most of the time, it’s just used as an entry point to code, and then the navigation can be achieved, either just moving around in the same file, by a referral from the code (like going to a method definition), or just searching on the whole project. In case you need to go to an specific file, you can then show the navigation window, or even better, search by filename. That only happens during small periods of time, so the rest of the time the window is just wasted space on screen. The same thing happen for a task list. It is useful to know the next step. But not while you’re working in one task.

Hey, it is possible to hide the navigation window, and display it only at the proper moment, to save space. I have done that. But it’s not there by default, so most of the people I know just keep it open “just in case, giving context”. They just get used to it, and don’t perceive it as a problem, But having half of your screen full of information that is irrelevant 95% of the time is a huge price to pay. And certainly not a good use of an IDE. The good parts of an IDE are things like automatic compilation and deployment, refactoring tools (not just renaming), debugging, help with the types in static languages, automatic generation of code, etc. Not showing everything, all the time.

Mimicking the wrong parts of an IDE

Mimicking the wrong parts of an IDE You can do better.

Vim is a text editor, but it is also sort of a philosophy. It is not about showing stuff, but about having stuff available at the right moment, with a quick command. It is not just about using hjkl to move around and having an insert mode. It’s about being precise. It is difficult at first, because you can’t simply discover what are the available options, but it also pays off in terms of focus and clean environment. When programming, the most important part is to keep as few things into mind as possible. Keeping all relevant information, which is already enough, but nothing more than can distract you for the task. It is also about doing one thing, and not a hundred. I use other tools for things like source control and debugging. After all, we have the whole OS to work as our IDE.

I use a small number of plugins in Vim. When you learn a little about it, you find out that it’s amazing the number of features and stuff that can be achieved “out of the box”, and how little extra is actually needed to have a really productive environment. It’s just that we need to move from the usual “browse through menus” world that most of software uses, and devout some time to, well, study and learn. It’s really worth it.

Vim speed is not really the point


500px-Vimlogo.svg

I am a Vim user. And a Vim fan.

I was fiddling around for some time, you know, just knowing the basics, because it is convenient to do small changes on servers without having to worry about installing anything. Just the basics, insert mode, some search, save,

and a couple more things. Then, around two years ago, I decided to give it a try as my main editor, after watching a presentation of a co-worker (my boss, actually) about how to use Vim (he has been using Vim for around 20 years)

At the beginning, it is quite difficult, to be honest. You have to relearn everything about editors. But I was doing OK after one or two weeks, so I kept using it. I was also forcing myself into improving my usage, reading about it and learning tricks…

Then, after a while of using it and read a lot of instructional material (I cannot recommend “Practical Vim” by Drew Neil strongly enough. It’s a FANTASTIC book), everything started to make sense. Let’s be serious, the problem with Vim is not exactly that is “difficult” per se, it’s that it is so alien to any other text edition experience, that you have to forget everything that you know about how to edit text. That’s why I don’t agree that the Vim learning curve is a myth. Because, when we first heard of Vim, we already have 10+ years of using things like Word, NotePad or Gmail to write text. We need time to assimilate how to edit text “the Vim way”. And that takes time to assimilate, as your muscular memory works against you.

And, yes, the Vim way is awesome. But it is awesome not for the reason that usually someone will think at the start. There is the perception that Vim is awesome because is fast. It is not.

Continue reading

Mis softwarevaches para trabajar (y II)


Continuando el post que escribí el otro día acerca de los cachivaches que uso para trabajar, voy a hablar también un poco de el software que utilizo.

Trabajo programando en Python sobre OS X, de manera que muchos de los programas que comento están orientados a este entorno. Mi trabajo es desarrollando código para servidores que luego corren en Linux, así que muchas de las herramientas pueden usarse en Linux. He usado recientemente también HTML, JavaScript y Ruby, siendo el entorno totalmente aplicable.

Continue reading