(I’m taking risks with such a title 
)
During yesterday computer science practical session (just think of the most hellish thing you have ever done), I was wandering lazily in the program list of the computer where I was supposed to do Excel stuff (actually I had pretty most finished and I wasn’t really in the mood to do extra work), when I found an antique DevC++ installation in one of the menu. Launching the thing I started to do a calculator (yes, after VBA almost anything else to program sounds interesting) when I remembered the use of the const keyword applied to functions and methods which (C++ purists correct me if I’m wrong) compiler-check that the code inside the function/method doesn’t modify both the parameters or the internal class state.
After thinking about it I thought : « Hey actually that’s a nice idea » and indeed it somehow lessens what the functional enthusiasts may call one of the ‘imperative nightmare’, namely, the imperative’s side-effects :
« Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast with the imperative programming style that emphasizes changes in state.« .
Wikipédia, Functional programming
This feature is particularly important in the today context where search for performance leads to parallel programming, a field where functional language excels by using this feature that imply that every function calls are independent from the execution context of the program.
IMHO this could proves to be a good feature in C# : a compiler-enforced mean to behave in a (mimicked) functional way with readonly access to fields and parameters and, thus, both no pollution of the others class’ methods call and the absence of locks which would allow, for example, auto-parallelism by the runtime. Especially when C# tends to get more and more functional concepts integrated both in the core language and in the class library.
Comments 4
In C++, you can indeed mark your class member methods postfixed with the const keyword, which is a pledge that you won’t modify the internal state. The const keyword also applies in several other interesting places as well. You can apply const to pointers in the sense that you can make a pointer to const data, or a const pointer to data, or even both. The details of these aren’t relevant now, but I just want to ask a question: If one understands C++ sufficiently, isn’t it as easy to make good software with good libraries as it is with C#? Come to think of it, isn’t C# more superfluous than C++ – at least in written form – when it relies on the programmer implicitly knowing the internal function, whereas C++ would prefer it being explicitly told that you are not going to modify the object’s internal state with a method?
Posted 01 oct 2007 at 7 h 18 min ¶Then again, concerning functional programming, I don’t think the C# people would like the way of explicitly telling that sort of stuff to the CLR. The primary programming « doctrine » in .NET is that of the imperative type. It is nonetheless very interesting how these two concepts – imperative and functiona programmign – are being combined. I recommend you watch http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx in case you haven’t already. Hear what Anders has to say. He has some interesting ideas on how to cope with even the issue you are thinking about.
Posted 01 oct 2007 at 7 h 26 min ¶The const modifier, and especially the associated strict semantics, are a nice addition to C++ if used properly. I’ve had a few occasions during some jobs to see how nice it can be. However, I don’t really agree with your assessment that it lessens the « imperative nightmare » of non-functional languages, simply because it requires far too much care and feeding to work correctly. In other words, the default is open, with the option of adding restrictions.
I believe 90% of the programmers on this planet are too lazy (or too rushed by deadlines) to apply proper caution in this regard. Besides, the presence of const_cast gives you enough rope to shoot yourself in the foot multiple times, which will inevitably happen unless you have absolutely sublimely enforced coding standards.
Anyway, I prefer strong, but dynamic typing to strong static typing, complemented by a healthy side-order of unit tests and coverage data. What you lose in potential for safety you gain in prototypeability and speed of adaptation to changing conditions.
My 2¢
Posted 04 oct 2007 at 13 h 26 min ¶I personally think that it’s better to get compiler/runtime support for the style you use because it allows you to find errors more easily and sooner (you might be perfect but your coworker might not
). Breaking sometimes is justified but in most case it shouldn’t be possible, i.e. if the compiler disallow you to modify your internal state you are sure that it will be enforced by you and the ones who use your library.
I’m beginning to think, seeing how computer science is taught in my school :p , that the young programmers most of the time just know what they have learned in their school which is most of the time what a friend like to call « engineer language » and so they don’t have the time to assess what FP could bring in their traditional work, but as hopefully your link suggests (thanks for that one btw
) minds are beginning to change on that matter. A good example of how imperative and functional programming can blend together I recommend looking at Scala.
Which is better than nothing IMHO
. I think that the language should force strict semantic in code but at the same time allow multiple style where for example you would have to bypass this restriction. Scala and OCaml are examples of that.
I agree with you on the first part and that’s why I think C++ is a bad language because if you can write horrible code for a thing that works (until you go back to it again). A good quote on that said by Frederico Mena-Quintero which, I think, really describe what is C++ when used by most programmers : « C++ is really good at making people think that you can turn it into a real language, while in fact you do nothing but put crutches to clutter the code into simulating the features of real languages »
About the unit tests (and XP programming in general) I too think it’s one of the other revolution that is coming in the (OO) programming world (together with new methodology like Scrum which enforce things like unit testing and client relation everytime in the making process).
About typing, I’m a big believer in strong *and* static typing and the way you can « prove » that your program works contrary to language like Python which are abject in that sense (doesn’t mean that it isn’t adapted to some cases though, like someone said « Each tasks has its better suited language »).
Posted 04 oct 2007 at 14 h 04 min ¶Post a Comment