Languages are very interesting things. They can either tie you up, or set you free. But no programming language can be everything to everyone, despite the fact that sometimes it looks like one does.
Languages are very interesting things. They can either tie you up, or set you free. But no programming language can be everything to everyone, despite the fact that sometimes it looks like one does.
What is it that you like about programming languages? What is it that you hate? What did you start on? What do you find yourself coding with most often today? Has your choice of programming languages affected other choices in software? (I.e. Lisp hackers tend to gravitate toward emacs, whereas others go to vi)
It is quite interesting to me the amount of influence that programming languages have on the way programmers think about how they do things. One example from one perspective is this; if you didn't know that most UNIXen were implemented in C, would you be able to tell? If so, why or why not? What are the different properties that UNIX has that makes it pretty obvious that it wasn't written by somebody programming in a functional language, or in an object-oriented language (or style)?
What I'm interested in hearing from people is what their favorite programming language is, and more importantly, why it is their favorite programming language. After those two are answered, ask yourself this; will it be your favorite language in 5 years? 2 years? 1?
I have gone through stages of love affairs with C, java, perl, python, and recently lisp. It seems that I fall in love with languages for the ways that they free me to write programs the way I want to write them. (case in point lisp, which lets me express things more elegantly than practically any other language, or perl, which lets me mainly slack by using implied variables and regular expressions) But like every lover, while I'm infatuated with the language, I'm ignoring its ugly parts. And eventually it's over, and I'm programming in a different language most of the time.
It seems that people use C often when it would be easier to code in a different language because C is standard; it's the bread and butter of UNIX. I've written programs in C for quite a while, but recently, it just feels like a waste of time to deal with things on such a low level when so many intermediate levels of abstraction have been handled for me in different programming languages and libraries. Then again, some people write the simplest programs in very high-level languages, and then expect all of their users to download a complete suite of tools to compile, install, and run their alien application. (Would you really try my software if I claimed to have written an excellent RDBMS if it required to you compile, install, and learn Miranda, Haskell, or Standard ML? Think as a user, not a programmer on this question)
Where is the balance between what's standard and what's not, reimplementing (square) wheels (poorly), using the abstraction that other programmers have already given us, sticking to the UNIX "spirit" of things, and being free as a programmer to express your code the way you want to rather than the way a language designer you've never met wants you to? How important is performance when taken into consideration against other concerns like ease of maintenance, ease of writing, program correctness, standardization, etc? Why is it that some languages seem consigned to a fate of being "flaky academic" programming languages when they're actually quite elegant and smooth? Who has driven the success and failure of languages really? Has it been companies doing what Sun has done for Java, or is it the hackers that actually use the language?
What's your dream programming language? Why haven't you written it yet?
What I'm trying to get at with all of these questions (aside than merely hoping to hear some interesting answers from fellow programmers) is that your individual answers to all of these questions make up what I think of as your "cultural set of assumptions". It seems strange that such a large portion of programmers are self-taught, but they end up going in similar directions in terms of how they think about programs. Is that because we're all human, or because we're all hackers? From the programmers I've worked with, their "cultural set of assumptions" is what makes them tick; it's what really makes the decision between one data structure or the other for solving the problem at hand. How has your cultural set of assumptions hindered or helped you as a programmer?
Many feel that functional programming languages are better tools than what we're using now. Phil Wadler has written a paper called "Functional Programming: Why no one uses functional languages" addressing many of the issues you bring up.
Like you, I went through stages of fascination with many different programming languages. I found the experience extremely rewarding, but am now programming in C. Looking back, the most useful thing I gained was exposure to a large variety of styles of programming. Each of these styles can be the right tool for the job (depending on the job, of course), but I find myself expressing them all rather comfortably in C, at the cost of exerting a little discipline.
For me, dealing with low level issues is not a waste of time. Quite the opposite, it feels like an important part of the craftsmanship involved in producing high quality code. In my free software work, I feel that the journey is the destination. My goal is not to produce the maximum amount of usable code in the shortest possible time, it's to create wondrous things. If I'm going to spend a huge amount of time on the design, algorithms, and analysis, the prospect of spending a little more to get memory management right is not at all bothersome. In fact, if I can fine-tune some of the lower level details, such as trying to optimize cache performance, so much the better.
But, I must emphasize, these are my goals. If your goals are different, the right tool for the job is likely to be different as well. First and foremost, have fun!
My favorite language is Chez Scheme for two reasons: syntactic abstraction and control abstraction.
Syntactic abstraction is macros. As opposed to other implementations of Scheme, Chez Scheme in my opinion has the best story on macros, and its macro system is among the most powerful I have seen.
Control abstraction is the power to add new control operations to your language. For example, backtracking and coroutines. More esoterically, monads in direct-style code. Control abstraction boils down to first-class continuations (call/cc). With the single exception of SML/NJ, no other language I know of has call/cc.
I know I will be using Scheme for years to come, and my company will also continue to use it in its systems. We code a lot in C++ and Delphi, but the Real Hard Stuff(tm) is done in Scheme because macros and continuations are big hammers. Despite Scheme being over 20 years old and despite demonstrated, efficient implementations of these "advanced" language concepts, I don't see new language designs adopting these features from Scheme. I hope this changes.
(Would you really try my software if I claimed to have written an excellent RDBMS if it required to you compile, install, and learn Miranda, Haskell, or Standard ML? Think as a user, not a programmer on this question)
A lot is getting rolled into this. What are the user's expectations? If the user wants the binary, the user should be able to download and go. If the user wants to build from source, it's ok to require the user to download a build environment. If the user wants to hack the source, it's ok to require the user to learn the language.
The problem today is that languages like Miranda, Scheme, and SML require a runtime system that has to be installed before the executable is run, and that runtime system is not part of standard Linux distributions like Red Hat. Aggravating the problem is that most of these language implementors don't release nicely packaged, e.g., rpms, versions of their runtime systems. If you want to release something implemented in a "nonstandard for Linux" language, then bite the bullet, work to get the runtime system better packaged, and then link to it.
I agree with raph. I've tried many languages, been infatuated with most of them, but I return to C to truly craft things. Be it standardization, availability, or a lack of information about the internals, I've found that most details aren't handled quite perfectly for my taste.
But the big win is not picking a "best" language. Rather, learning what each language has to offer, and understanding how those different philosophies can be used in any language is what really benefits you. The ideas don't change, just the syntax.
(1)What is it that you like about programming languages?
What I like 'bout them is it provides a way of expressing a solution in a nice and easy way, syntactically of course.
(2)What is it that you hate?
What really makes a language suck is when it is misapplied. For example, using COBOL to write a character based windowing library. I know it's sounds and looks horrible to even think about it but I really saw somebody do it.
(3)What did you start on?
I started with Assembly on a trainer, then PDP-11 BASIC, followed by PDP-11 Fortran, then Fujitsu COBOL. Then after landing an admin/programmer job, I had to learn C and shell programming 'coz the shop were using AT&T System 3 running an Oracle database. I had to skip CFront (now known as C++) because I don't know what that was during that time, it was either C or shell programming, no ifs or buts. I had to choose both 'coz shells were very easy to use than C. Most of the time, scripts were the obvious choice 'coz they were considered the universal glue for small programs written in C. Moreover, during that time, our Unix (boxes? or cabinets?) were very simple and easy to admin. Now, it has become very complex and popular. I was also aware of the community that were around Unix who were sharing code, but I was not active 'coz I had no code to give.
(4)What do you find yourself coding with most often today?
Most of the time I use VB, gcc, g++, Visual C++ and nasm.
(5)Has your choice of programming languages affected other choices in software?
Oh yeah, I'm definitely stuck with programs written on what I know, I cannot be good at Perl, Python, COBOL and Java all because of it.
I'm not that old mind you, it's just that the technology we were using were old, that's all. That was the late 80's and early 90's so it's just only a couple of years back.
But two might be.
We all learn lots of languages, but the older we get, the fewer we use. If you know that ahead of time, you can choose wisely.
You need a language that's balls-to-the-wall efficient, if you put the time in. You need another language that makes it quick to write throwaways.
You need a language that's rigorously strict, to write big programs and libraries meant to be used and re-used. You need another that's as slack as your brain, for noodling around.
You need a language that any professional can read. You need another that lets you have fun.
You need a language for low-level bit-twiddling cycle-counting every-nanosecond-counts inner loops. You need another for patching other programs together and munching data formats into shapes they were never meant to have.
Really big programs and important libraries need all the hard-ass rigor the language can give them, so that you can know something about the program and about each part of the program without having to check. One-off little programs don't need such rigor because it's no trouble to check, and anyway it would just get in the way.
While I agree you lose if program *exclusively* in one language, most people have a language they prefer. Mine is Python. I fell in love in Python overnight -- literally. I learned it in an evening, and started programming production-level with it the morning before. Within a few months, I even manage to get into the core Python implementation and add features and correct bugs -- because Python's beauty is not just skin deep -- the implementation is readable and organized too. About C being standard -- well: there is no reason to limit yourself to C. In a recent Gtk/GNOME lecture to the local LUG, I gave most examples in Python and C, and some of the more complicated ones in Python only. Few people there knew Python, but I don't think I've lost anyone because of it. In an upcoming Curses article I plan to post on IGLU, I plan to use Python examples exclusively. This is an experiment, which I hope will go over well.
For me, a prime example of raph's approach is that he chose to write our communal beanbag in C as an Apache module when almost everybody *takes it for granted* that web applications are written in a scripting language or as servlets. lkcl in hacking on mod_virgule shows another slant on the same approach: generate lots of C code really quickly.
I wish I was writing rproxy in Python, rather than C. I'm sure I would be much faster there, but I wouldn't be able to integrate it into other programs: it's not just a matter of being able to call Python from Apache, but rather to patch deeply into the application. I think we're likely to be in this situation for some time. There is a certain charm to writing in C and doing tricky things with select that are impossible in Java.
I think it bodes very well for Advogato that people can have such an interesting and polite thread about what is almost the canonical flame-war accelerant.
I hope people didn't misunderstand me, I didn't mean that it would be best to use just one programming language for everything, or that I did that. I don't - not even close. Using perl for everything or C for everything would REALLY be like pounding a nail with a wrench.
It's just that sometimes you develop temporary or permanent affinities not necessarily for a specific language, but for a certain way of doing things that happens to be embodied in a specific language. For example, in perl, the use of $_ is almost like using an implied subject in English. When I say:
Perl knows I'm talking about $_, just the same as when I'm talking about Perl and I refer to "it", you know that "it" in that context means perl. The concept of implied variables, regular expressions permeating so much of a language (to the point of being able to be arguments for functions, such as split(), in their regular form instead of in some intermediate form like a compiled regular expression data structure) and so on had me infatuated with perl for quite a while. Strange things such as the way objects were often implemented as blessed hashes made me wonder if that's the way people who implement OO systems do it too. I could see that in C, you could create a hash table, and have entries in the hash table either be instance variables or even pointers to functions. In that way, a hash table could be an object. I hadn't thought of objects in that way until I started doing OOP in perl.
For all of you folks who have grown up on C and imperative and OO languages, I strongly suggest you take a look at a functional language and even some of its simpler components that aren't usually present in imperative languages, like the map() function. (Which strangely enough has found its way into newer non-functional languages like perl and python. All for the good IMHO). Learning to think of some things in terms of map() will change your perspective on how things are and how they could be.
But in terms of just using one language all of the time, (to jolt back to the topic) - no way. It would be hell to write everything in perl, C, or java. But that doesn't necessarily mean that you wouldn't want to use the type of tricks that you learned from a specific programming language in the vast majority of your programs.
I really like Perl. It's extremely cool. But, you definitly need more than one language to be a Complete Programmer. I'd say C is great to know since most everything is written in it (at least have a basic understanding of it) and I bet Lisp would be handy to know, too. Of course, you'll also probably need asm at one point or other.
Of course, we all know the language any decent programmer has to know is, of course, the great and powerful C# *ducks, runs*
I agree with people that one language is insufficient, but I have hopes that there is at least one syntax that completely suffices.
Syntax wars have always been fighting the battle between S-expressions and free-form text. Sexps are better because they clearly show structure to the trained eye. Free-form is better because you can use any arbitrary character to represent what you want to say, and do it in the order you want.
Same thing with *ML (the document ones, not the functional programming languages)... structure is all fine and good, but you have to leave room for the unknown, and somehow incorporate it into the syntax.
So (sigh, yet another shameless plug), I've been developing Guilt, a language syntax that is designed to be translated into other existing syntaxes. My plan is to be able to write C or Perl or Python or Guile or Pliant or whatever, all using the same basic syntax. That means treating those other languages as libraries rather than languages per se.
Interested? Try joining the Figure mailing list.
Oh, and to answer the question... I'm language-agnostic. Let me learn a language, and I'll have fun using it for what it's worth. But there's no need to be religious about it, they're all just different forms of communication. Free verse is just as rewarding as rhyming couplets. So there.
I think, what it comes down to, is that programming languages, though each theoretically capable of doing anything a computer can do, each excel at a specific problem arena. The unfortunate side effect of that phenomena is the fact that our vision can often be limited by the tools we use. If, day in, day out, you use, eat, breathe, and live Perl, then sooner or later everything is going to seem like a text processing problem to you. Likewise, living on Python will have you thinking about every project in an OO fashion (both hyperbole, of course, but essentially true).
I feel this exists in the realms of syntax and grammar even more than the realms of built-in functionality and libraries (sorry, gord, but i have to disagree with you). Again, buried in a Perl paradigm is going to have you seeing $'s and @'s all over the place. You'll have a completely different appreciation for the disparities between a float and an int than someone who lives and breathes C. The way you think about blocks of code and I/O is likely different whether you're working with a stream-based language (like Perl, C, Lisp...) or a strongly line-based one (Python, Bash, Basic...).
This is a more prevalent phenomenon than, i think, most of us realize. Take COBOL, for example. Nowadays, noone would design a language like that. Why did it happen, then? Because the people who designed it were mired in the paradigms of the programming languages that were available to them at the time. Another example is Aspect-Oriented Progamming, which is still a difficult concept for many to swallow because most of our programming languages lack an adequate way of encapsulating it.
So, what does all this boil down to? Know your tools. Keep as many in your belt as possible. Look at a given problem from a tool-agnostic viewpoint and try to figure out which is best for the job. Try to keep an eye out for when you're wrong, and switch tools if possible. Learn new languages if/when you can, if only for brainstorming material.
Basically, be extended by your tools, not limited by them. We are craftsmen, and we owe it to our craft to do things well.
To clarify, jmelesky, I'm not advocating a single static syntax, rather one that has a standard way of imparting structure, and including subsyntaxes.
[console This is a little test...] [eol] [if [= myvar 42] [perl printf "Now let's go nuts in the Perl world.\n"; # And maybe write a comment or two. # ... which is possible because we're in a Perl block, and are # properly indenting our lines. We'll exit in a jiffy...] [guile (display "Yada, yada") (newline)]]
That's my little example. Nothing magic or earth-shattering, just the idea of settling on a syntax that allows convenient parsing for the computer (ignoring commands that aren't understood, as with HTML), and convenient embedding of arbitrary data (in this example, program text for Perl and Guile).
I'm still not expressing myself terrifically, but I hope this makes it clearer that I'm not taking a particularly controversial position.
My latest favorites are Forth and Scheme, two relatively simple yet cabable languages.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!