I think one issue that pops up in many languages is the distinction between functions that have side effects and those that don't. In C++ you see standard library higher-order-functions that accept lambdas or other functions, but the documentation says "the function passed should not produce side-effects." You also see this in Clojure functions, and functions you might write might also expect only side-effect-free functions. The problem is that the functions you pass may not be functions you wrote, they might come from another library and then to be most confident, you must go and look up the source or docs to feel sure. I don't think a naming convention is enough, since many may not use the convention. For languages where this is important, I wish there was a compiler or runtime check for these things so the user didn't have to take responsibility. Almost as if functions were split into two "function types", those with and those without side effects. Maybe starting at the lowest level of the core language library, some functions would be noted as causing side-effects, and then any function built that called those functions would automatically be categorized as such, and on up to the top, so that side-effects-beget-side-effects and function parameters that require non-side-effect-functions wouldn't allow those to pass.
Anyway, it is a problem that is not solved by a naming convention.
I don't know Haskell, but assumed it would probably tackle this problem based on all the praise I've seen it get for things like this and its general type system.
(The type () implies "no interesting return value").
This function could only be written via deliberate subversion of the type system. Instead it must be
print :: String -> IO ()
Which is similar, but the return is marked by this IO type. Essentially this restricts you to ensure that side effecting functions are executed in explicit sequence and cannot "poison" pure types.
I have read many times that you need a solid understanding of the Haskell implementation as well as various extension to make the code as performant as it is elegant. True?
Right now, that's truer than many would like. However, when GHC 8 (the new version of the compiler) drops in the next couple months, most of the performance tuning will involve putting a single line of code at the top of each performance-critical file. That line will make all evaluation within the file strict instead of lazy.
A lot of the performance and predictability problems in Haskell come from its laziness, so the ability to toggle that on and off on a per-module (read: per-file) basis will be a game changer.
That does sound significant. I will be curious to hear more about that. Can you recommend a good go-to resource for all the latest news and discussions on Haskell?
Mostly I just read various people's blog posts and follow links (for example, I think I first found Stack on [1]). I also spend occasional time in the IRC, which can be useful but isn't a comprehensive news source by any means.
I hear some of the mailings lists are informative - iirc there's a haskell-beginners one which will probably cover major updates in tooling, feature releases, and so on. Good luck!
One hundred percent agree. Having come to places like this several times in my career I'm ready to start looking into lead. I'm getting bored of the deficiences of programming and would love someone else to deal with this crap.
Jai proposed a solution where like c++ you have to name the variables you're closing over but optionally require that all functions called by the function not access any other variables
You are talking about object methods, in which const has meaning limited to the object's data, and nothing else -- you can still do side-effects. I'm talking about also anonymous lambdas (modern c++ feature) and non-object functions. There is no way to say in C++ (or even a more functional language like Clojure) if a function has side-effects or not.
Anyway, it is a problem that is not solved by a naming convention.