[kazinator]

It is absolutely possible. I did C++ development as a regular job years ago, now I'm coding in C (for that type of coding).

What will get you off the C++ drug easily is Lisp.

Once I discovered Lisp, C++ had no place in my "personal spectrum" any more, but C (including the C-like subset of C++) still did. Well, it wasn't so sudden, mind you. More like: the more Lisp I knew, the less interest I had in C++.

(Idiotic lambda implementations and whatnot will not woo me back, sorry.)

[int_19h]

Automatic resource management killed C for me. The need to write endless towers of explicit error checks, or endless goto cleanup, and making sure that you explicitly clean up things in the right order, is the programming equivalent of washing your dishes by hand instead of using a dishwasher.

Now, if C had something like Go's "defer"...

[exDM69]

> Now, if C had something like Go's "defer"...

In GCC and Clang you can use __attribute__((cleanup)) to achieve this. I think MSVC has a similar construct.

I'm pretty sure I've seen a portable "defer" library for C somewhere.

[pjmlp]

> I think MSVC has a similar construct.

Microsoft rather focus in C++.

[svnpenn]

Sorry if this is a hated question - but are all Lisp the same rats nest of parenthesis?

ive always been interested in Lisp but that is so ugly - i would a JavaScript/Ruby/Python method chaining to 5 levels of nested parenthesis

[dkersten]

> ive always been interested in Lisp but that is so ugly

If it being ugly to you is enough to prevent you from trying a language, then I don't know what to tell you. Personally, I find javascript incredibly ugly, but that doesn't stop me from using it.

When Python was first picking up steam, I remember a lot of people complaining about how ugly significant whitespace was and how they didn't want to try it because of that. After using Python for a short time, the significant whitespace simply fades into the background and its not something you really ever think about, so its really not a problem. Lisp parentheses are the same. After a short while, they simply stop being something to think about and they fade into the background. Besides, Lisp programmers use tools to help them: paredit, rainbow parentheses and more recently parinfer. I now find editing with these so much more pleasant than editing any language that isn't based on s-expressions. Lisp syntax also tends to be very regular, few things breaking the s-expression rules.

> are all Lisp the same rats nest of parenthesis?

No, Clojure, for example, goes to a little bit of effort to remove parentheses. There are still enough to annoy people, but far fewer than other Lisp dialects. Clojure also mixes up the types of symbols it uses (eg function parameters are in [] instead) which helps to visually break things up, making it easier to read.

> i would a JavaScript/Ruby/Python method chaining to 5 levels of nested parenthesis

In Clojure you can replace something like this:

    (c (b (a 1 2)) 3 4)

with

    (-> (a 1 2)
        b
        (c 3 4))

[billsix]

I implemented a compile-time test framework in Gambit Scheme in 7 lines of code, and Python's yield in about 20 or so.

http://billsix.github.io/bug.html#_make_generator

Lisp code has few wasted moves. Programming in it does require changing your mindset of syntactic beauty. And once your mindset changes, you can make whatever syntax you want.

Perhaps the biggest hurdle is that the code is not best read linearly. The reader must understand the order of evaluation, which follows very simple rules, in order to understand the code correctly. That hurdle is definitely worth the jump.

[Ace17]

> Perhaps the biggest hurdle is that the code is not best read linearly. The reader must understand the order of evaluation, which follows very simple rules, in order to understand the code correctly.

Could you please give some details about how the order of evaluation differs from, say, C? Thanks!

[billsix]

They are very similar. They are both applicative-order, meaning that the arguments to a procedure are evaluated before the procedure is applied.

The evaluation of a lambda results in a function value, which captures the enclosing scope, but the procedure is not yet applied to anything.

But the main difference that I've seen anecdotally is that imperative programmers as a whole tend to get confused by nested expressions, or lets just say they prefer sequential statements over nested expressions. My assumption is that they don't fully understand the order of evaluation in their language of choice.

[kazinator]

Scheme and C evaluation rules are very similar: in both languages, the order of evaluation of function arguments is unspecified.

Common Lisp is left to right, so that (list (inc i) (inc i) (inc i)) will reliably produce (1 2 3) if i starts at zero.

[Koshkin]

> whatever syntax you want

“... any color as long as it’s black.”

[billsix]

You neglected to quote the full sentence, which wasn’t even long.

To change your mindset, read:

http://www.paulgraham.com/onlisp.html

Or instead, how bout this. show me your implementation of generators in the “user space” of your language of choice. Show me your compile-time test framework.

Both of these are relevant to the article, what C++ may provide to users in 2 years. But I did these on my own, without requiring Marc Feeley’s approval nor his implementation (he is the creator of Gambit)

[Koshkin]

Thing is, most of the programming languages suffer from this problem in one form or another. There’s two ways to avoid it - either by using indentation (Python, Haskell) or by using the “concatenation” syntax (Forth, Joy, Factor).