Development Environment 1

Since I started cross-pollinating with people who learned in a different environment from mine, I remember questions and remarks similar to this:

I’m using DevC++, what compiler are you using?

This evidences a lack of knowledge about what makes a development environment… a fragility in the ability to get things done that hangs for dear life on a particular way to do things with particular tools instead of knowing how the pieces fit together and being able to mix and match. Hopefully a bit of context can help fill the gaps.

This is the start of a series of posts aimed towards anyone who wants to start developing and needs to make sense of what they need to start developing software and how the pieces fit together, so that a particular tool or collection of tools isn’t what defines the reader, but what helps them be productive in a particular environment and circumstance.

The tools most commonly used in developing are: a text editor; an interpreter, or a compiler and linker; a debugger; an automatic build tool; a profiler; a static code analysis tool.

This series will not go in depth on how the tools work. Instead, I hope to give an overview of what they do, and some examples of known tools in the category. Almost every category of tool used in software development depends on the output of another one to work; thus the combination of tools that get you from code to finished product is called a “toolchain”.

Some programs bundle many or all of a particular toolchain together; some even let you swap tools within a category to better fit your needs and preferences. Those are called IDEs (Integrated Development Environments), and I’ll cover them last.

The Text Editor

First of all, with almost all certainty, your chosen language’s toolchain starts its with plain text. This means that you can write the code for it in any text editor. Many text editors provide “syntax highlighting”, which means that they understand enough of what certain programming languages mean and highlight the different elements of the source code for ease of reading. Just to be clear, the source code is what you actually write in a particular programming language to specify the steps that the final program needs to execute.

Here is a brief, vastly non-exhaustive list of gratis text editors:

  • TextEdit, the out-of-box MacOSX editor
  • Notepad, the out-of-box Windows editor
  • Gedit / Leafpad / Kate, the out-of-box editors which usually install with GNOME, XFCE and KDE desktop environments in Linux
  • Notepad++, an editor available for windows with some good features aimed at software development
  • Emacs (My editor of choice), a multi-platform and customizable text editor with its own learning curve. I recommend if you’ll use this put some time apart to learn the basics, then start learning to program, then put some time apart to learn to ease your programming using external modules.
  • Vi (I’ve not used this one extensively; it’s most used incarnation is Vim), is also multiplatform, also customizable, also has its own learning curve. It’s style is very distinct from Emacs’. As with Emacs, though, I recommend you set apart time to learn it properly before heading into progamming, then learn to customize it with plugins to ease your programming. It’s particularly important in that it’s standardized in POSIX, so you can expect consistent behavior.

The output of this program is a text file with source code, which is then processed by either the interpreter, the compiler, or the static code analyzer.

This is all for today. I expect we’ll cover the interpreter Tomorrow.


Some years ago, in a Japanese-Colombian conference, a guy who is half Japanese and half Colombian mentioned something they apparently say in Japan, roughly translated as:

Sooner or later, discipline overcomes intelligence.

This has resonated with me, and fits with anecdotes from elsewhere, echoing Paul Graham’s take that determination is the number one predictor for startup success, the tales of John Carmack’s incredible dedication and hard work, and the situations in which disciplined work and study have served me well.

I believe that discipline can be cultivated, like many other habits, so I will work on it this year.

I will start by writing a post each weekday, with no restrictions as to time, length and subject. I will then impose a schedule, and a length; I don’t really think a restriction on subject would help. The objective is to build discipline in this area, and grow it into others, then look at the fruits of it and see if it is worthwhile.

Last time I checked, I had above-average IQ; hopefully cultivating discipline will be a multiplicator of that gift, and this will be an better year than otherwise for that.

I’ll archive the texts written with discipline cultivation in mind under the “Daily Writing” category for future reference.

Starting the blog

In order to write more, and be able to share better, I dropped the development of my static site compiler and moved to wordpress.

Over the years I’ve set many rules and goals to achieve before starting to write; among those:

  • Setting up a multi-language website. I’m a native Spanish speaker in a Spanish speaking country, but the broader audience is English speaking.
  • Setting up a static website, and the appropriate generator, to make the maintenance painless — this one was so misguided it’s actually hilarious.
  • Writing a backlog of content, and work with that content in several different ways, including but not limited to: classifying it, running it through trusted people, embellishing it.
  • Getting some OSS projects up and running so I could talk about them — more hilarity ensued by not thinking this one through and noticing a lack of community around my obscure development.
  • Generally trying to improve who I am, so I could project a better picture of myself while remaining truthful. Part of this is related to a severe impostor-syndrome episode, caused in no small part by working on in-house, backoffice software during all of my career.

So what I’ve decided is this: I’ll throw everything overboard and start. I expect a backlog will eventually form, and everything will be nicer as I work and polish my workflow. I’ll write about many things, including what I’m doing now, what I’m reading about, and insights I develop.

This is a start which almost aligns, with a slightly amusing off-by-one error, with the start of 2016. This is a coincidence, as I’d been working on setting up the php and MySQL installation and making sure they played nicely with Lighttpd for a few days, and festivity-related “chores” intervened. I’ll roll with it, though and try and make a nice run.