The "blub paradox" and c++

Well, since you mentioned Haskell:

1. Pattern Matching. I find pattern matching to be much easier to read and write. Consider the definition of map and think about how it would be implemented in a language without pattern matching.

   map :: (a -> b) -> [a] -> [b] map f [] = [] map f (x:xs) = f x : map f xs 

2. The type system. It can be a pain sometimes but it is extremely helpful. You have to program with it to really understand it and how many bugs it catches. Also, referential transparency is wonderful. It only becomes apparent after programming in Haskell for a while how many bugs are caused by managing state in an imperative language.

3. Functional programming in general. Using maps and folds instead of iteration. Recursion. It's about thinking at a higher level.

4. Lazy evaluation. Again it's about thinking at a higher level and letting the system handle evaluation.

5. Cabal, packages, and modules. Having Cabal download packages for me is much more convenient than finding source code, writing a makefile, etc. Being able to import only certain names is much better than essentially having all the source files dumped together then compiled.

Memoize!

Try writing it in C++. Not with C++0x.

Too cumbersome? Okay, try it with C++0x.

See if you can beat this 4-line (or 5-line, whatever :P) compile-time version in D:

auto memoize(alias Fn, T...)(T args) { auto key = tuple(args); //Key is all the args static typeof(Fn(args))[typeof(key)] cache; //Hashtable! return key in cache ? cache[key] : (cache[key] = Fn(args)); } 

All you need to do for calling it is something like:

int fib(int n) { return n > 1 ? memoize!(fib)(n - 1) + memoize!(fib)(n - 2) : 1;} fib(60); 

You can also try something similar in Scheme, although it's a bit slower because it happens at run time and because the lookup here is linear instead of hashed (and well, because it's Scheme):

(define (memoize f) (let ((table (list))) (lambda args (cdr (or (assoc args table) (let ((entry (cons args (apply f args)))) (set! table (cons entry table)) entry)))))) (define (fib n) (if (<= n 1) 1 (+ (fib (1- n)) (fib (- n 2))))))) (set! fib (memoize fib)) 

C++ is a multiparadigm language, which means it tries to support many ways of thinking. Sometimes a C++ feature is more awkward or less fluent than another language's implementation, as is the case with functional programming.

That said, I can't think off the top of my head of a native C++ language feature that does what yield in Python or JavaScript does.

Another example is concurrent programming. C++0x will have a say about it, but the current standard doesn't, and concurrency is a whole new way of thinking.

Also, rapid development -- even shell programming -- is something you'll never learn if you never leave the domain of C++ programming.

Coroutines are an immensely useful language feature that underpin a lot of the more tangible benefits of other languages over C++. They basically provide extra stacks so functions can be interrupted and continued, providing pipeline-like facilities to the language that easily feed the results of operations through filters to other operations. It's wonderful, and in Ruby I found it very intuitive and elegant. Lazy evaluation ties in to this as well.

Introspection and run-time code compilation/execution/evaluation/whatever are massively powerful features that C++ lacks.

Having implemented a computer algebra system in both Lisp and C++, I can tell you that the task was much easier in Lisp, even though I was a complete novice to the language. This simplistic nature of everything being lists simplifies a great many algorithms. Granted, the C++ version was zillions of times faster. Yeah, I could've made the lisp version faster, but the code wouldn't be as lispy. Scripting is another thing that is always going to be easier is lisp, for example. It's all about using the right tool for the job.

Associative Arrays

A typical way of processing data is:

• reading the input and construct a hierarchical structure from it,
• creating indexes for that structure (e.g. different order),
• creating extracts (filtered parts) of them,
• finding a value or a group of value (node),
• re-arrange the structure (delete nodes, add, append, remove sub-elements based on a rule etc.),
• scan thru the tree and print out or save some parts of them.

The right tool for it is associative array.

• The best language support for associative arrays I've seen is MUMPS, where associative arrays are: 1. always sorted 2. they can be created on disk (so-called database), with the very same syntax. (Side effect: it's extremly powerful as database, the programmer has access to the native btree. Best NoSQL system ever.)
• My second prize goes to PHP, I like foreach and easy syntax, like $a[] = x or $a[x][y][z]++.

I don't really like JavaScript's associative array syntax, because I can't create, say a[x][y][z] = 8, first I have to create a[x] and a[x][y].

Okay, in C++ (and in Java) there are nice portfolio of container classes, Map, Multimap, whatsoever, but if I wanna scan through, I have to make an iterator, and when I wanna insert a new deep-level element, I have to create all the upper levels etc. Uncomfortable.

I don't say that there're no usable associative arrays in C++ (and Java), but typeless (or non-strict typed) script languages beats compiled ones, because they're typeless script languages.

Disclaimer: I'm not familiar with C# and other .NET languges, AFAIK they have good associative array handling.

What do we mean when we say that one language is "more powerful" than another? When we say that a language is "expressive?" Or "rich?" I think we mean that a language gains power when its field of view narrows enough to make it easy and natural to describe a problem -- really a state transition, no? -- that lives within that view. Yet that language is considerably less powerful, less expressive, and less useful when our field of view widens.

The more "powerful" and "expressive" the language, the more limited its use. So maybe "powerful" and "expressive" are the wrong words to use for a tool of narrow utility. Maybe "appropriate" or "abstract" are better words for such things.

I started out in programming by writing a whole bunch of low-level stuff: device drivers with their interrupt routines; embedded programs; operating-system code. The code was intimate with the hardware and I wrote it all in assembly language. We wouldn't say that assembler is in the least abstract, yet it was and is the most powerful and expressive language of them all. I can express any problem in assembly language; it's so powerful that I can do anything I please with any machine.

And all of my later understanding of higher-level language owes everything to my experience with assembler. Everything I learned later was easy because, you see, everything -- no matter how abstract -- must in the end accommodate itself to the hardware.

You might want to forget about higher and higher levels of abstraction -- that is, narrower and narrower fields of view. You can always pick that up later. It's a snap to learn, a matter of days. You'd be better off, in my opinion, to learn the language of hardware¹, to get as close as you can to the bone.

¹ Perhaps not quite germane, but car and cdr take their names from the hardware: the first Lisp ran on a machine that had an actual Decrement Register and an actual Address Register. How 'bout that?

I learn't Java, C\C++, Assembly, and Java Script. I use C++ to make a living.

Though, I would have to say I like Assembly programming and C programming more. This is inline mostly with Imperative programming.

I know that programming Paradigms are important to categorize data types, and give higher programming abstracted concepts to allow powerful design patters and formalization of code. Though in a sense, each Paradigms is a collection of pattern's and collections to abstract the underlying hardware layer so you don't need to think about the EAX, or IP internally within the machine.

My only problem with this, is it allow's peoples notion and concepts of how the machine work to be turned into Ideology's and ambiguous assertions of what is going on. This bread's all kinds of wonderful abstractions on top of abstracts to some ideology goal of the programmer.

At the end of the day, its better to have a good clear mindset and boundaries of what the CPU is and how computers work under the hood. All the CPU cares about is executing a series of instructions that move data in and out of memory into a register and performs a instruction. It has no concept of data type, or any higher programming concepts. It only moves data around.

It becomes more complex when you add programming paradigms into the mix because our view of the world are all different.

is there some powerful language feature or idiom that you make use of in a language that would be hard to conceptualize or implement if you were writing only in c++?

Are there any useful concepts or techniques that you have encountered in other languages that you would have found difficult to conceptualize had you been writing or "thinking" in c++?

C++ makes many approaches intractable. I would go so far as to say that most of programming is hard to conceptualize if you limit yourself to C++. Here are some examples of problems that are much more easily solved in ways that C++ makes hard.

Register allocation and calling conventions

Many people think of C++ as a bare metal low level language but it really isn't. By abstracting away important details of the machine, C++ makes it hard to conceptualize practicalities like register allocation and calling conventions.

To learn about concepts like these I recommend having a go at some assembly language programming and check out this article about ARM code generation quality.

Run-time code generation

If you only know C++ then you probably think that templates are the be-all and end-all of metaprogramming. They aren't. In fact, they are an objectively bad tool for metaprogramming. Any program that manipulates another program is a metaprogram, including interpreters, compilers, computer algebra systems and theorem provers. Run-time code generation is a useful feature for this.

I recommend firing up a Scheme implementation and playing with EVAL to learn about metacircular evaluation.

Manipulating trees

Trees are everywhere in programming. In parsing you have abstract syntax trees. In compilers you have IRs that are trees. In graphics and GUI programming you have scene trees.

This "Ridiculously Simple JSON Parser for C++" weighs in at just 484 LOC which is very small for C++. Now compare it with my own simple JSON parser which weighs in at just 60 LOC of F#. The difference is primarily because ML's algebraic datatypes and pattern matching (including active patterns) make it vastly easier to manipulate trees.

Check out red-black trees in OCaml too.

Purely functional data structures

Lack of GC in C++ makes it practically impossible to adopt some useful approaches. Purely functional data structures are one such tool.

For example, check out this 47-line regular expression matcher in OCaml. The brevity is due largely to the extensive use of purely functional data structures. In particular, the use of dictionaries with keys that are sets. That is really hard to do in C++ because the stdlib dictionaries and sets are all mutable but you cannot mutate a dictionary's keys or you break the collection.

Logic programming and undo buffers are other practical examples where purely functional data structures make something that is hard in C++ really easy in other languages.

Tail calls

Not only does C++ not guarantee tail calls but RAII is fundamentally at odds with it because destructors get in the way of a call in tail position. Tail calls let you make an unbounded number of function calls using only a bounded amount of stack space. This is great for implementing state machines, including extensible state machines and it is a great "get out of jail free" card in many otherwise-awkward circumstances.

For example, check out this implementation of the 0-1 knapsack problem using continuation-passing style with memoization in F# from the finance industry. When you have tail calls, continuation passing style can be an obvious solution but C++ makes it intractable.

Concurrency

Another obvious example is concurrent programming. Although this is entirely possible in C++ it is extremely error prone compared to other tools, most notably communicating sequential processes as seen in languages like Erlang, Scala and F#.

This is an old question, but since no one has mentioned it, I'll add list (and now dict) comprehensions. It's easy to write a one-liner in Haskell or Python that solves the Fizz-Buzz problem. Try doing that in C++.

While C++ made massive moves to modernity with C++11, it's a bit of a stretch to call it a "modern" language. C++17 (which hasn't been released yet) is making yet more moves to come up to modern standards, so long as "modern" means "not from the previous millennium".

Even the simplest of comprehensions that one can write in one line in Python (and obeying Guido's 79 character line length limit) become lots and lots of lines of codes when translated to C++, and some of those lines of C++ code are rather convoluted.

A compiled library calling a callback, which is a user defined member function of a user defined class.

This is possible in Objective-C, and it makes user interface programming a breeze. You can tell a button: "Please, call this method for this object when you are pressed", and the button will do so. You are free to use any method name for the callback that you like, it is not frozen in the library code, you have not to inherit from an adapter for it to work, nor does the compiler want to resolve the call at compile time, and, equally important, you can tell two buttons to call two different methods of the same object.

I have not seen a similarly flexible way to define a callback in any other language yet (though I'd be very interested to hear about them!). The closest equivalent in C++ is probably passing a lambda function that performs the required call, which again restricts the library code to be a template.

It is this feature of Objective-C that has taught me to value the ability of a language to pass any type of objects/functions/whatever-important-concept-the-language-contains around freely, along with the power to save them to variables. Any point in a language that defines any type of concept, but does not provide a means to store it (or a reference to it) in all the available kinds of variables, is a significant stumbling block, and likely a source of much ugly, duplicated code. Unfortunately, baroque programming languages tend to exhibit a number of these points:

• In C++ you cannot write down the type of a VLA, nor store a pointer to it. This effectively prohibits true multidimensional arrays of dynamic size (which are available in C since C99).

• In C++ you cannot write down the type of a lambda. You can't even typedef it. Thus, there is no way to pass around a lambda, or store a reference to it in an object. Lambda functions can only be passed to templates.

• In Fortran you cannot write down the type of a namelist. There is simply no means to pass a namelist to any kind of routine. So, if you have a complex algorithm that should be able to handle two different namelists, you are out of luck. You can't just write the algorithm once and pass the relevant namelists to it.

These are just a few examples, but you see the common point: Whenever you see such a restriction for the first time, you usually won't care because it seems such a crazy idea to do the forbidden thing. However, when you do some earnest programming in that language, you eventually come to the point where this precise restriction becomes a real nuisance.