Slashdot Mirror
Favorite Programming Language Features?
johnnyb asks: "I'm curious what everyone's favorite programming language features are. I'm looking for both the general and the specific. I'm especially looking for features that few people know about or use, but are really useful for those who do know about them. What are your favorite programming language features?"
"A couple of examples to kick off the conversation:
- Continuations
Continuations are very interesting, because they can be used to implement a number of flow-control features such as exceptions, coroutines, cooperative multithreading, and are better at modelling web interactions. This is a more general feature, but most people use these in conjunction with either scheme or ML.
- Tuple-returning
It is a huuuuge time-saver when languages like Perl allow functions to return tuples. Instructions like '($a, $b, $c) = $sth->fetchrow_array()' is a wonderful thing.
- The flip-flop operator [Perl's '..' operator]
Another perlism that I just think is cool. Read more about it here.
Object-oriented programming.
;)
For me it's just easier.
(Especially with XCode displaying it as a little blue box, it makes the concept easier to grasp for beginners)
Error 407 - No creative sig found
Beautiful syntactical simplicity.
*cough*C*cough*
karma: ouch!
I think's java's concept of anonymous inner classes is simply superb... it enables runtime aggregation of small objects while preventing you from having to create hundreds of named external helper classes to implement the behavior.
It's certainly not an unknown feature, but I couldn't live without it.
DiscDividers tabbed plastic CD dividers: divider cards f
I feel the one of the strongest features of Java (or any language) is a standardized documentation feature (i.e. javadoc) and "readability". Being able to easily understand what another developer's intentions and "gotchas" are is invaluable. Perl, for example, can be obtuse without even trying very hard.
.. and now, 50 rebuttals from the Perl crowd.
It's simple: I demand prosecution for torture.
Yeah, Perl can be obtuse. Personally, I find that less-experienced programmers write clearer Perl code. Basically, there are many idioms and shortcuts that, used sparingly, can create extremely readable and intuitive code. However, just as using the same pronoun to mean several different things in the same sentence, using too many of these features makes code hard to read.
Take $_, for example. I am relatively inexperienced at Perl (I have used it a lot, but I don't know a ton about it), and I usually don't use $_ unless I'm absolutely sure it will be what I think it is. Often, I prefer to use a specific variable name in constructs like foreach where the variable will be used several times in the loop, just because it makes things a little clearer.
Personally, what I like about Perl is that, in the same way that PHP has functions for everything on earth, Perl has every data structure on earth built in. It's nice not to have to worry about how to organize data. Perl also just seems very intuitive to me. In my opinion, and inevitably opinions on this will differ, Perl makes concepts like pointers/references, hash tables/associative arrays, and arrays/lists simple enough that you can use them without extra effort, but versatile enough that you aren't stuck reinventing the wheel when you want a slightly different structure. That's basically one of the things that makes me prefer Perl to C--in C, I have to do so much stuff by hand: conversions, array insertions and such, but in Perl, everything does what it should without extra effort. Of course, Perl isn't for everyone or everything, since these built-in features come at a performance cost, but, for what I use it for (little scripts and such), it doesn't matter.
Maybe the ease of working with data is what makes the rest of Perl programs so sloppy or cryptic sometimes... I guess when you have to create and manipulate data structures by hand, you can (and must) put more thought into what the data structures should look like.
Tired of free iPod sigs? Subscribe to my blacklist
Ruby blocks, lambda functions, lazy evaluation.
:)
And C++
Marxist evolution is just N generations away!
But after the adjustment, I've truly grown to love its spartan clarity and simplicity. I can hardly stand to look at the redundant brace-littered syntax of Java, C or Perl now.
Mike
"Not an actor, but he plays one on TV."
1) I must be incrementable.
2) I must be dereferenceable.
3) You must get from begin to end in a finite number of steps.
4) The type you get when dereferencing I (I's value type) must be comparable to V.
Because of this, you can use the same find function to search through arrays, lists, vectors, maps, sets, strings, streams, and more, even though none of them inherit from each other or implement a common interface in the OOP sense.
Additionally, there's no complicated syntax for the user of the library:The great thing about abstraction is that it avoids duplication. Avoiding duplication lets you test/debug/prove correct once for greater reliability. Once you wrap your head around this simple example, you'll be surprised how deep the rabbit hole goes.
Complete agreement! It's much easier and readable. It would be great if MS used that for Visual Basic, instead of the ugly End If construct. Much more comfortable for people who have to work with VB every once and a while. Some people get too attached to the English language.
"it's not about aptitude, it's the way you're viewed" - Galinda
What makes Perl sloppy or cryptic was that it was designed to make it easy to create quick hacks. Remember Larry Wall's Great Programmer Virtues: Lazyness, Impatience and Hubris. Perl was designed to make laziness easy; once Perl was written, you could be very lazy in your programming and things would still work.
I'm an experienced programmer who's done relatively little Perl, although its use is increasing significantly in my work. Like you, I deliberately avoid use of $_ because I find it a very confusing concept, and I think it encourages the creation of confusing code. And even though you and I avoid it, the beginning Perl books are full of it and that makes it almost inevitable that most will use it.
For some reason, I always, always hated that $ you have to put in front of variable names. I know it makes all sorts of interesting things possible, but for some reason I've always found it hard to read.
Still, it's tough not to love associative arrays built into the language. It really makes a lot of normally tough things a snap, and I'm sure their coding of it is a lot faster than anything I would have done.
D
Clean syntax. Not one that forces me to lean on my shift key and decorate my code with punctuation characters. The "noise" gets in my way so much that I can't even stand to program in perl anymore. I just can't take syntax like sub foo { dostuff @{$blah->{woof}}; etc... } anymore. Semicolons drive me bats.
Python's ok. Tcl is closer to the ideal syntax, but oy what a feature poor language. Lisp's really nice. Forth would be about perfect, but it makes you work at such a low level most of the time (fact is, most people just don't build it up that much) that your code looks noisier than perl, more like APL even.
Of course I like modern features, like automatic memory management, structured exceptions, first class functions, pattern matching, currying, asynchronous execution, concurrency, and so on. But I just can't express concepts well in a language that makes me clad every expression in so much syntactic scaffolding.
I've finally had it: until slashdot gets article moderation, I am not coming back.
How ironic that you used the English cognate a mere four words later!
how to invest, a novice's guide
I don't believe that you understand the concept becuase it seems that your argument doesn't apply.
The whole point would be that you wouldn't see the idiosyncrasies of the way that he likes his code laid out, he would in essence give you compiled code and your development environment would display it for you however you liked to see it.
For example, take the way people develop HTML code; some code it in notepad, writing the raw code, others use graphical interfaces with WYSIWYG software that just lets them edit the finished product, and others may use something in between, but its all the same code; displayed for you the way you like it; in text or graphically, or in windows with your toolbars and your highlighting preferences and tab spacing. What if you could only view it in the program that it was originally writen in?
And as you tread the halls of sanity, You feel so glad to be, Unable to go beyond. I have a message, From another time..
Why in the world would any programmer care about whether they write "if { }" or "if ... fi", etc? I don't see the big advantage in indulging one's personal preferences about syntax. It's not like every person's brain has a completely different way of reading a program that makes it significantly easier to understand a unique brand of syntactic sugar...
Sure, you can develop in your own special IDE that gives you your unique syntax. But don't you ever look at code together with other programmers who might have different preferences? Don't you ever view code published in magazines and on web sites that can't pretty-print to your specification? Training yourself to strongly prefer some kind of private language is not a very good idea.
Though having used things like B::Deparse I can tell you that you'll lose some syntatic sugar, e.g. things like "$a++" or "$a+=1" might come back out as "$a=$a+1" (or vice versa), or special cases where a programmer chooses to format a single if() statement:
Even though it might have been cleaner and easier to read before it was broken out into a block.
You'll lose things like whether or not it had brackets, whether or not there was a line break, etc. Basically, you lose the special cases. Maybe that's a good thing in that it enforces uniformity, but there are cases (like in long lines wrapping) it's handy to drop some syntax and use some ugly shorthand. You'd have to pack around a lot of metadata to save that information (that might not be relavant to other "views"), or make blanket staments that all if() statements will look a certain way, all increment operations will look a certain way, etc.
You think it saves you another variable. In reality, a temporary variable gets used underneath that, because that's how computers work.
Well, yes, but since we're talking about favorite language features, I don't see your point. This is something that saves the programmer from having to create extra temporary variables himself since the language does it for you. Try to keep up.
As long as the different representations are not too far off then it's probably not a big deal. But I work a lot together with other developers looking at the same code at the same time and if our dialects were mutually incomprehensible that would not be a good thing.
Multiple representations can be very powerful - editing html code in parallel with the rendered version makes a lot of sense. But even in this case there is not a one to one mapping - it's not just syntax but semantics that vary (i.e. the rendered version has no semantics whereas the html or xml code may). I wonder if you could find two real programming languages that you could usefully and bidirectionally translate between and not lose a lot in the process.
So then the perfect language is one where all the real programmers have done all the work for you, and you're just a little script monkey.
... I notice that capable men are still at a premium in our society; we still need the man who is intelligent enough to think of the proper question to ask." (The Evitable Conflict, can be found in I, Robot or other collections)
To that I answer by quoting Dijkstra: "if we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent': the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger." (EWD1036, page 11)
And so for example even your 10-line, 40-token launcher is too long; its information content can be expressed succintly as "new Webserver(80)" or even "Webserver 80" in any properly designed language.
When electronic calculators came out, accountants did not say "the calculators do all the arithmetic for you, and you are not a real accountant" (or did they?) Similarly for spreadsheet. The reality is, each time they are relieved of a chore, they find a more worthwhile thing to spend their time on, such as analysing various what-if scenerios, which had been intractible until the advent of spreadsheets --- a fine programming language in its own right. I now quote Asimov on the general idea: "The Machines are only a tool after all, which can help humanity progress faster by taking some of the burdens of calculations and interpretations off its back. The task of the human brain remains what it has always been; that of discovering new data to be analyzed, and of devising new concepts to be tested.
Yes, but does anyone do anything serious in standard Prolog? I found even using Eclipse's (www.icparc.ic.ac.uk/eclipse) extended Prolog, with all the extra functional features just too damn fiddly, even for something well suited to solution by Prolog-like techniques (optimal scheduling).
What are you going to do when you need a true 128-bit environment? It used to be that 32-bits seemed like more than anyone could ever use. Now that's starting to no longer be the case for certain applications, and 64-bit is becoming more important.
I don't think it's reasonable to expect certain bit lengths for primitive types (unless your application is very specialized, i.e. nobody else is ever going to want to run it). Primitive integer types are never going to be able to do all the computations necessary (wake me up when they sell cheap 4096-bit computers to compute RSA keys); the primitive types should be seen as tools for performing a fairly limited range of computing tasks (ditto with floating point; IEEE 754 is not a magic cure-all for numerical robustness). The rest is up to the programmer, language designer, or library designer.
Also, I'm not sure what you're talking about with regards to SQL, but none of that stuff is really closely defined in the SQL standard itself. Many high-quality databases are more than capable of storing more than 4 GB of data in a single field. Storage size limitations reflect the underlying database backend more than the programming language used. The native protocols for databases are more than capable of transferring data in pure binary as well.
I think this is one of those rites of passage all experienced programmers probably go through. At some stage, your experience of different languages gets to the point where you understand that the underlying concepts transcend the syntax of any specific language. A natural next step, particularly if you've seen the sort of parsing graphs used by compilers, is to assume that throwing out the "awkward" text syntax in favour of some whizzy graphical scheme will make things much easier. Some people have even done PhDs on this subject.
Unfortunately, when you try it in practice, you find it's not nearly as clear-cut as you thought. Like all that nasty, unnecessary punctuation found in many programming languages, it turns out that using a concise, precise text format is often far easier both to read and write than any graphical alternative. What can be done in one line of regex in Perl takes a whole screen of graphical representation via flow charts and state machines.
I wish you luck in your exploration of graphical alternatives, but I'm afraid the odds are pretty heavily that after a while, you'll come full circle, and understand that all that nasty "bracket crap" is there for a reason, and has survived for decades because that reason is sound.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This is certainly true to a point. There are three basic kinds of data used throughout the programming world: text, numbers and logic (true/false). Pretty much any mainstream general-purpose language provides basic arithmetic and logical operators, and then an extensive library of more advanced mathematics functions. With strings, you often get basic operators, but beyond those there's a world of difference between providing a couple of upper-/lower-case conversions and having things like regular expressions supplied as standard.
I think part of this problem is that what constitutes good support for strings isn't nearly as clear-cut as it is with numbers. Should we provide mutable and non-mutable types? How much should the regexes support? How do we deal with international issues?
The latter is a biggie that I think will become more significant as time goes on and markets expand worldwide. Frankly, most languages suck when it comes to dealing with translating text and working with foreign languages. Consider how many provide a function mapping a character onto its upper-case equivalent; what it's supposed to do with a German double-s? Some languages get text support spectacularly wrong: C++'s much heralded IOStreams system codifies structure that should be data, and thus makes itself almost completely useless for any sort of internationalised development; all the locales in the world won't change the fact that different languages use different word order conventions.
I think the underlying problem here is that text is fundamentally a complicated thing. Numbers, whether integers, fixed- or floating-point, have fairly well-defined rules (though as any numerical analyst will tell you, they don't necessarily match those of mathematics). Text, however, is on a different level. Even dealing with simple concepts like a case-insensitive comparison (assuming your input language even has cases in this sense) can be hugely complicated in practice, and complications like multiple word-forms multiply up to make it many times more difficult than typical mathematical code. It's more like expecting calculus to be built into a simple programming language, except that relatively few apps need that level of maths, while just about anything with a UI potentially needs that level of text support.
Even if you're only dealing with manipulations of well-structured text in a single language, not all processing fits neatly into the idioms offered by regular expressions. Regexes are powerful tools, to be sure, but I think we're still waiting for the not-quite-silver bullet in text processing to arrive. I expect this to be something based on higher level concepts than a simple list of characters, possibly to be very demanding of processing power (though viable with tomorrow's technology), and probably to revolutionise the international development community like nothing we've ever seen before.
So yes, I agree completely, good text processing is a very important feature for a programming language. If only any of them had it... ;-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.