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!
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
j/k
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.
Next I love ruby's block system, especially for stuff like this.It comes in super handy for a ton of stuff. Especially when I'm doing XML.
Also, there is another thing that I first discovered in pythonSave me a temporary variable, w00t.
Lastly, its not really a language feature, but in any object oriented language I love being able to serialize the objects. It's so simple to use pickle or any other serialization library and just write objects out to file or network. I never have to design a binary file format ever again. It's even better when you use Ruby and you can marshall objects into XML or YAML with a single method. Then you've got a human readable and editable file format that you can magically transform into objects again later. Super useful.
The GeekNights podcast is going strong. Listen!
This is less of a favorite feature, and more of a feature I wish we had. What about having the representation of the language independent of the code itself? I think this will eventually happen and could really revolutionize things. I believe the inklings of separating 'physical' representation from the code were there in some languages like Algol 60 and CS work in the 1960's, but it never caught on (perhaps hindered by other features of those works?).
... then ..."? Better yet, really like Perl's "$_"? If you want it to be displayed like this, turn it on. Otherwise, say you don't like this feature, and it will automatically replace the "$_"'s (either implicit or explicit) with the variable to which it refers. Again, no problem.
In a little more detail, suppose I write a C program. It will have lots of functions and conditionals with their "blocks" surrounded by braces.
But what if I prefer my "blocks" to be started and ended by brackets instead of braces. Better yet, what if I am tired of typing these and would like indentation to control this. Or whatever -- start end commands, if you like. The point is that these are minor sytactic idiosyncracies, and we all have preferences. Why not store the code in an underlying format (XML would be okay, were it not for the bulk of it)? As long as there is a one-to-one correspondence between all possible representations, you could view it however you want.
And so on for all syntactic features. Prefer "if-fi" construction to "if () {}"? Or "if
At this point, I feel like I am repeating myself, but let me continue for a little bit. It would let each user have his/her personal favorite representation. We already let them control the colors of their syntax highlighting, lets take it a step further.
Hell, if you want to use a graphical viewer for those C programs, akin to LabView, go for it! Or (in my opinion) a much better graphical programming environment with a graph structure. The point is: you write it how you want and save it. It appears to another coder how he/she wants it to appear, but the content is exactly the same.
In short: why isn't this done? It seems like a spectacular step in unifying programming languages a bit, and letting each user tailor his preferences while maintaining compatibility. As long as there was simple one-to-one correspondence, the translation from physical representation to underlying code and back would be quick and fairly easy to handle. Are there any modern projects which attempt this? Or *any* which attempt it with some success?
On a somewhat related note, is it possible to put a "hook" to a comment in the code, and with the proper viewer have that comment displayed along with the code (say when you click the "hook", move your mouse over it, or drag the "hook" to a "comment box")? If this last paragraph doesn't make sense, please ignore it.
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
Closures and Currying are two of my personal favorites.
Overloaded Functions are sweet.
I am also quite fond of operator overloading.
Ruby blocks, lambda functions, lazy evaluation.
:)
And C++
Marxist evolution is just N generations away!
Just to confuse people do this:
main() {
int x;
int y[2];
x=1;
y[1]=10;
printf("%d\n", y[x]);
printf("%d\n", x[y]);
}
What will happen?
My favourite thing is languages that can execute strings of their own code.
:= &("{ || nVar += 43")
For example, clipper can do this via blocks:
cVar
Python has the same thing via "exec":
>>> b
NameError: name 'b' is not defined
>>> exec "b=2"
>>> b
2
This means you can build up strings of code at runtime and execute them, or store field-specific database logic in another database table, and fetch it when needed.
C# is not quite so convenient - you have to build up a complete class and compile it, but it can all be done in memory at runtime so it's just a little more work. Clipper and python can both affect the current scope directly (which can be both bad or good, I suppose).
I believe ruby has blocks similar to clipper (probably better), but I don't use it, so I'm not sure. I also don't use perl, so I have no idea if it supports this...
This sig is part of your complete breakfast.
Functions as first class citizens, that is functions can be returned from functions and provided as arguments as functions. The basis of the functional paradigm and it makes life much much simpler.
Pattern matching (some ML:)
fun has_a [] = false
| has_a 'a'::_ = true
| has_a _::xs = has_a xs;
Simple elegent functions requireing much less if_then_else's.
Automatic garbage collection and bounds checking: enables me to write the code to do the job, not the memory management.
Polymorphic typing: I can write general functions:
fun contains x [] = false
| contains x x::_ = true
| contains x _::xs = contains xs;
That will work with any type for which equality is defined.
These are the reasons I hate C for general programming. The most important thing is efficient algorithms, without them no amount of low level optimization will help. With good algorithms, functional languages are now normally at least as fast... (and much much easier to debug and even verifiable).
From non-functional languages, the object model is wonderful when used properly.
Smalltalk & co's complete environment is a nice feature.
I also have a soft spot for BBC BASIC with its speed, interactivity and simplicity. These are combined to allow windowed applications including at least one web browser and anyone can start programming simple programs (which is missing from most modern computers)
Then there's the specialist languages. They have all sorts of nifty features (Mathematica is a good example) but I wouldn't expect them in an everyday language.
This is not the issue it was ten years ago, but one feature I absolutely want tightly integrated into my language is robust string handling. I still like perl's best (although perhaps only because I know it best). It simply seems to be more tightly integrated into the language as a whole.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
Hey, johnnyb, where else have you posted this question? When you get answers, will you analyze them and post your conclusions? It could be interesting.
A lawyer & digital forensics examiner. Also an expert on open source software (OSS).
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
I use Common Lisp.
Lisp has almost no syntax, so it's extremely regular (barring exceptions like LOOP). Because it's so regular, it's easy to build macros that do powerful things.
Macros can completely transform the source, at compile time, but with the full power of the language. Having that ability, together with simplicity, means that it's easy to build a complete mini-language for one's manager or web designer to use on the site, and easy for them to learn it, since you can explain the syntax in 5 minutes or less, and they don't have to learn 50 built-ins to use it.
Common Lisp's conditions system not only allows exception-handling, like Python, but can also have an entire protocol for controlling execution flow built on it. More about that in the conditions chapter of Peter Seibel's forthcoming book.
Lastly, having a generic-function-based object system means that a method can "belong" simultaneously to more than one class, at the same time. So, instead of having a method inside a class, you call a method with any number of objects of various classes, and it figures out from the type of the object what method to run, of all the similarly named methods. You can even specialize a method on a particular object or objects, instead of a particular class or classes! Multiple dispatch rocks.
Property law should use #'EQ, not #'EQUAL.
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.
Ranum is citing this as an example of a way that existing tools -- such as GCC -- could be enhanced in such a way that programmers using currently popular languages (C/C++) would have a better security safety net without having to be retrained in practices (like checking for buffer overflows) that while obvious are still under-utilized in most software. The whole article is interesting reading, but this remark about Perl's taint mode seems like one of the best concrete examples of a modern protective language feature.
DO NOT LEAVE IT IS NOT REAL
This is what I want: For the first criteria, if, at any point, you are forced to make contact with a 32-bit environment, then the platform fails the test.
For instance, if the platform requires you to use either Java or SQL, then it fails.
SQL fails because it is essentially an ASCII-based language that has almost no sense of primitive data types whatsoever, and its only undefined binary type, the binary BLOB, maxes out at 2^32 = 4 Billion bytes [so much for high-quality MPEGs of, e.g., Gone With The Wind].
Java fails because, as recently as the Java 1.5.x Beta, it cannot take long ints as array indices. For instance, the following will not even "compile" [i.e. "javac," whatever that is] under the Java 1.5.x Beta:
So your "middleware" for this hypothetical 64-bit platform is forbidden to touch either SQL or Java.As for the strong data typing, I want the environment to be natively aware of
According to Professor Kahan, Matlab has [or has had] some serious problems here: So: Any takers?The java code should have read as follows [I didn't notice that the shift operator had been caught by the
Languages without "real" unification feel unexpressive or too low level. Whenever I program in something other than prolog (which is most of the time) I miss it.
Example: [foo(A,x)|B] = [foo([p,q],x),C,d,e].
which implies that A = [p,q], B = [C,d,e], and C remains unconstrained.
There are 10 kinds of people: Those that understand ternary; those that don't; and those that don't care.
Mike
"Not an actor, but he plays one on TV."
How ironic that you used the English cognate a mere four words later!
how to invest, a novice's guide
You could do this in perl if you wanted to. For instance, you can code perl in Latin. It's done using the Filter::Util::Call module, which lets you preprocess your perl code. Read Damian Conway's discussion about it. He gives a simple example using Klingon keywords and talks about implementing a Switch function in perl.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
What do you mean by 'static lists'? Do you mean they're immutable?
You can do
to add to a list in a list. The syntax is tough, but I think it does what you mean. @{} is like a cast-to-list. should be helpful.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I'm surprised I haven't seen this listed yet. In java I use reflection often and at the cost of a little processing overhead, it allows me to add remove fields from a database with very little code change.
I generally like to use struts in web applications and find I often have to tranfer values from an action form to a java bean and vice versa. Using the org.apache.commons.beanutils package it is incredibly easy to do this, and beanutils uses reflection to do this with.
My second choice would be good regexp support. IMO, Perl is the best at this and I also like the Java regexp package in 1.4 as well.
#1 Garbage collection. a.k.a. automatic memory management. Not very sexy, but by far the single biggest productivity boosting feature of any language. I hate housework. It is just a waste of time.
:)
#2 No pointers, no buffer overruns, no memory corruption. Related to the first point. Memory corruption is just so hard track down. You can keep your pointers, I've already got an OS, I don't need to write my own.
After spending years programing asm and C on a platform with no memory protection (Amiga), and then later C++, I think I've paid my dues here.
#3 Stack traces. Not a language feature per se, but it takes a lot of the drudge work out of debugging.
#4 Python's 'for' loop for iterating over the contents of a list or array:
for thing in myarray:
mutate(thing)
It is easy to remember, easy to type, much easier to read, and you use it _all_ the time. Compared to the same code in C, C++ or Java, it is a godsend.
#5 Dictionaries, a.k.a. associative arrays. It just makes a lot of problems much much simplier and faster to solve. Sure, most other languages have dictionaries available as a class, but when they are seamlessly built into the language you use them as easily as any other primitive datatype.
--
Simon
Perl has a standardized documentation feature: PODs. You can embed all manner of documentation alongside your code and then see the output (much like a man page) by running 'perldoc [perl module]'. If you use classgen you get a POD skeleton in your perl modules.
I do agree that standardized documentation built into a language is quite powerful.
I dont remember what the syntax actually was but when you defined a structure, you could point into its members with with.
like if the structure had members x and y and structure was named coords you could do something like this
var own_x;
with coords
begin
x=own_x
y=123.13
end
yush
> #1 Garbage collection. a.k.a. automatic memory
> management. Not very sexy, but by far the single
> biggest productivity boosting feature of any
> language. I hate housework. It is just a waste of time.
Garbage collection does not free you from memory management. It simply converts one kind of problem into another: namely it eliminates accesses of unallocated memory, but it creates memory leaks instead. The thing is, it is not always easy to figure out when you no longer need a block of memory. That's with garbage collection it is supposed to be good practice to "free" your pointers anyway, by assigning NULL to them. Why they can't just use STL containers instead, I don't know.
> #2 No pointers, no buffer overruns, no memory
> corruption. Related to the first point. Memory
> corruption is just so hard track down. You can
> keep your pointers
You won't have any memory corruption if you don't use arbitrary indexes to access your arrays. For example, when iterating over a container, you run your iterator from ctr.begin() to ctr.end(); no corruption possible. The other cause of memory corruption is using unverified data to directly access your arrays. That happens when you ask the user for a number and then use it to index; this is wrong in so many ways, I can't even begin to list them all. Verify your data, and you will not have any data corruption.
> #3 Stack traces. Not a language feature per se,
> but it takes a lot of the drudge work out of
> debugging.
#include
backtrace_symbols()
> #4 Python's 'for' loop for iterating over the
> contents of a list or array:
>
> for thing in myarray:
> mutate(thing)
#define foreach(t,i,c) for(t i = c.begin(); i #5 Dictionaries, a.k.a. associative arrays. It
> just makes a lot of problems much much simplier
> and faster to solve.
map m;
> Sure, most other languages
> have dictionaries available as a class, but when
> they are seamlessly built into the language you
> use them as easily as any other primitive '
> datatype.
You can use map as easily as any other primitive data type of the same category: as an array.
m["january"] = 31;
cout "january has " m["january"] " days" endl;
Just because you can write it that way, does not mean you should. Should you blame makers of underware for letting you put it on over your clothes? Just because Superman can do it, does not mean you should.
Actually what I'm wanting to do, eventually, is write a book about great programming constructs people have probably never heard of, or don't understand well.
My last book took me 3 years to find the spare time to finish, so I don't suspect I'll have this done anytime soon.
I was originally going to just analyze scheme's features, but then I realized that many languages have features that need to be recognized, too. my original outline was going to be:
* Memory Management
* Symbolic programming - an intro to Scheme
* Functional Programming & Functional Programming Patterns
* Closures and higher-order functions
* Advanced Flow Control w/ Continuations
* Compile-Time programming 1: Macros
* Compile-Time programming 2: Partial Evaluation
* Compile-Time programming 3: C++ templates
* Lazy evaluation
* Lazy data structures
However, if I decide to open it up to other languages, I have no idea how I'm going to organize it or even how I will decide what to include.
Anyway, it was originally posted just to Advogato, but then I remembered that the only threads on Advogato that get any real response are flame-wars, which is sad because Advogato could be a real cool place. Then I thought "you know, this would make a good 'Ask Slashdot' as well. However, I don't expect the quality of responses on Ask Slashdot to be as good, although I expect there to be a LOT more of them.
Engineering and the Ultimate
- Strong typing: Much like pig and elephant DNA just don't splice, one should not be allowed to add characters to integers then divide by floats and expect a sensible result.
- Type inference: I want a language that can figure out what I'm doing without having to specify every last detail. And I want it to be able to tell me when I'm trying to splice said pig and elephant DNA.
- Higer order/first class/anonymous functions: makes life and coding so much nicer.
- Pattern matching: pretty and powerful.
- An interactive environment: why should I have to compile my whole freaking program to test one little function?
- Paradigm neutrality: if a problem is best solved with object, let me use objects. If an algorithm is most naturally expressed functionally, gimme that. If imperative code is what I need, let me use it. If I want to mix'n'match hand me the blender
- Native and byte-code compilation: choose between speed and portability depending on your needs
Thank goodness there's OCaml there to provide all this for me in one happy little package...-30-
Unrestricted integer size (e.g., Lisp bignums)
Have persistent objects between program invocations. It's so tedious and buggy to have to write to a file when a program ends and then read it again when you start it up again.
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).
I don't look at the features alone in a language. Usually, I look at what its primarly used for. I use C because it's a general-purpose language, that has a strong issued standard, with ANSI compiler compliance. I find that beginner programmers who like languages with lots of features(i.e C++), they get carried away and don't learn the language like they should. C++ is an extremely complex language, that is hard to use correctly.
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.