
Selecting a Programming Environment - iamwil
http://williamaadams.wordpress.com/2012/08/31/selecting-a-programming-environment/
======
TheNewAndy
When programming in C, I think it is far better to leave the compiler you use
as a free variable. Program to a standard (C90 is sensible, because there are
still compilers that only support this standard... including one from a small
multinational in Redmond) and then you are free to use whichever compiler
produces the best code.

A similar approach applies to the standard library. Write to the language
standard, and you are good to go everywhere.

Though, I'm also dubious about using C90 for multi-threaded stuff given that
there is no concept of threads in the language until C2011.

~~~
heretohelp
It's pretty normal these days to rely on GCC varargs. Among my people (the
unix tribe), few care if Microsoft will ever support C99 or anything else for
that matter.

You can use a macro to swap between varargs/stdarg.h if you want to be able to
use the LLVM toolchain in addition to gcc.

MSVC++ can go suck fruit wax.

------
PayUpPal
"If you program long enough, you come to realize that there is no “one
language to rule them all”"

Than you program some more and, if you're smart, you realize there's Common
Lisp.

~~~
dpkendal
Except that Common Lisp is a kludge, a relic, and a sad victim of 30-year–old
compromises. It's also practically abandonware, with no new specification
since 1994's ANSI Common Lisp. (Itself mainly clarifications to CLtL2.)

Modern Lisps — of which Clojure is currently the leader of the pack — would be
a far better choice today.

~~~
chimeracoder
Not to start a Lisp-vs-Lisp side-conversation here, but if we're going to go
with a 'modern' Lisp, I'd prefer one that doesn't add syntax and which
supports proper tail-call elimination.

It's not like we have a lack of those, either - Racket's my personal favorite;
aside from the robust standard library, the scoped languages give me hope that
the 'Lisp curse' has finally been reversed.

------
freyrs3
musl & klib are great together if you're going to live in C land. I'd also add
``caffeine`` and ``libev`` if you're targeting a platform a Unix like platform
and need to do network programming.

<http://github.com/dmw/caffeine> <http://software.schmorp.de/pkg/libev.html>

~~~
wonderzombie
I glanced at klib and I noticed that a bunch of the implementations were
straight up macros. This— this seems like crazy talk to me. But I am not a C
programmer, and I've spent very little time in C++ until very recently.

Can someone shed some light on this? The trade-off may well be worth it, but
I'm only aware of the negative trade-off, not the positive.

~~~
ANTSANTS
I only saw the kind of macros you're probably thinking about (on the order of
#define min(X, Y) ((X) < (Y) ? (X) : (Y))) in kbit.h, but I didn't look at the
source to all the components. What klib does seem to use the preprocessor
quite a bit for, however, is implementing generic functions and datatypes --
in other words, since the only significant difference between the
implementation of a linked list whose nodes have "payloads" of 2 bytes, and
one where the payloads are twice as large is, at the language level, the size
of the respective payloads, we would ideally like some kind of code generating
"function" that will take a datatype of some size and produce an appropriate
linked list implementation. C++'s function templates exist for this sole
purpose, but in C, we have to abuse its preprocessor to get a similar result.

If you take a look at the source of klist.h, the preprocessor stuff is a bit
hairy, but it basically leaves you with a "compile time function", KLIST_INIT,
that takes a datatype and generates, via simple textual substitution, an
implementation of a linked list where each node of the list carries a payload
of that datatype. klib_test.c includes a simple usage case.

Just to be clear, the preprocessor is generating real functions (inline ones,
but functions nonetheless), not simply textually inserting the appropriate
list code every time you use one of the macros like kl_next(iter) defined at
the end of klist.h.

Check out the GCC docs on macros (and particularly, the section on
concatenation) to get a better understanding of how klib implements this.
<http://gcc.gnu.org/onlinedocs/cpp/Macros.html>

As for how "crazy" it is to do this with the preprocessor, it's just the most
convenient alternative in C to manually copying and pasting a generic list
implementation yourself and editing in the correct type information, so it's a
fairly common practice. You'll know code that _really_ abuses the preprocessor
when you see it -- I would advise then to run.

------
erikb
Selecting a single environment for all future software projects seems strange
to me. Isn't it better to learn about changing parts of your environment
depending on the context?

------
mark_l_watson
William is really talking more about selecting programming languages and Lua
and C certainly cover a lot of programming use cases.

I have my own comfort zone (Clojure, JRuby, and Java with IntelliJ and
RubyMine) and I am glad William has his.

~~~
georgemcbay
His Arduino callout limits the available practical options greatly. In his
situation minus Arduino, I'd go with Go. It works really well on ARM devices
like the Raspberry Pi and all the way up to Windows/Linux/Mac x64.

Go is my current first-choice language if I have the choice. Of course, in
today's very segmented platform (web, desktop Windows, desktop Mac, desktop
Linux, Android, iOS, WinPhone, et al) era, there's really no one language for
everything. Even C falls down in some areas.

~~~
Father
HaXe and HaXeNME come pretty close. Especially NME with which you can create
GUIs and games compile to c++, compile to html5 using jeash, create native
phone apps, and compile SWFs all from the same code. With HaXe itself the code
usually needs a bit of modifying depending on the target. They added java
recently to it which is not yet available for NME. If anything; it's fun to
play with.

------
ilaksh
I like the web stack. I like CoffeeScript and Node.js with Chrome or Firefox.
Doesn't cover everything, but does handle a lot of cases. If I have to have a
native mobile then I might use something like Phonegap or Trigger.io. If I
have need native desktop then I might use App.js. For Arduino I would use
noduino if possible.

