MFE: To do or not to do?

[pingu]

Another perspective on programming languages concerns the following:

1. It is a one-man show or a multi-team effort.
2. How easy to maintain and extend the code base.
3. The half-life of the software product.
4. How easy to interoperate with existing libraries.
5. How easy to debug.

These questions are also relevant in the context of a Python environment.

There is no silver bullet. At some stage you hit a wall with all languages. It is a question or knowing where it is and how to slow down before hitting it.

C++ is bad overall at all of these points. For 2 and 5, C++ is one of the worst if not the worst of the mainstream languages.

 

[Daniel Duffy]

C++ is bad overall at all of these points. For 2 and 5, C++ is one of the worst if not the worst of the mainstream languages.

Oops
Just out of curiosity, have you worked on (large) C++ projects?

Are the problems caused by the language or the way the developers 'use' the language? Can you quantify let's say the top [3,5] issues? and how does Python mitigate these shortcoming?

 

[pingu]

Oops
Just out of curiosity, have you worked on (large) C++ projects?

Are the problems caused by the language or the way the developers 'use' the language? Can you quantify let's say the top [3,5] issues? and how does Python mitigate these shortcoming?

I have and those projects were all IT related and a mess. We had to agree on what subset of C++ to use and not deviate of that subset to avoid problems.

Also, you can never separate the "language" from the way developers "use" the language.

You also seem really focused on Python as if it was your main competitor, which could be.
Python main advantage is that is very easy to read and understand. Also there is usually one obvious way of doing things and they become very clear with experience.

You should learn Python. The advantages will become obvious right away. There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.

 

[Daniel Duffy]

We had to agree on what subset of C++ to use and not deviate of that subset to avoid problems.

Can you be more specific?

BTW I don't see Python as a competitor. It's just another language, like all languages.

You should learn Python. The advantages will become obvious right away.
Can I do maths. Would love to.

There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.
This is a show stopper for certain classes of applications, e.g. process-control, medical, derivatives book etc.

 

[Yike Lu]

When I asked about customization, I was expecting you to use your particular expertise to filter down the possibilities and give some real examples. It's not helpful to point to a link.

Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes. Things that have to be implemented via the compiler are not customizations.

You should learn Python. The advantages will become obvious right away.
Can I do maths. Would love to.

There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.
This is a show stopper for certain classes of applications, e.g. process-control, medical, derivatives book etc.

The workarounds are completely and utterly standard. Numpy + scipy + pandas are the must have library stack for math under Python, but they are great libraries, fast, good syntax, and very standard.

In fact, it's far more accurate to say that Python is bad at low-latency, but high throughput math can be and is frequently done.

Daniel, the annoyance here is that the more you write, the more apparent it is that you don't have experience with really powerful high level languages, the best of which combine high level concepts with exceptional (although not best in class) execution speeds. This has happened to me over and over, the other side doesn't have the experience so therefore isn't even equipped to have a meaningful discussion. It's the Blub paradox (Beating the Averages). The power difference between Python and C++ is easily on the order of 10x (in terms of what I've personally been able accomplish in one vs the other). The lines of code required to do an arbitrary task is easily 10x less, which directly translates into maintainability.

 

[Daniel Duffy]

I have and those projects were all IT related and a mess. We had to agree on what subset of C++ to use and not deviate of that subset to avoid problems.

Also, you can never separate the "language" from the way developers "use" the language.

You also seem really focused on Python as if it was your main competitor, which could be.
Python main advantage is that is very easy to read and understand. Also there is usually one obvious way of doing things and they become very clear with experience.

You should learn Python. The advantages will become obvious right away. There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.

When I asked about customization, I was expecting you to use your particular expertise to filter down the possibilities and give some real examples. It's not helpful to point to a link.

Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes. Things that have to be implemented via the compiler are not customizations.


The workarounds are completely and utterly standard. Numpy + scipy + pandas are the must have library stack for math under Python, but they are great libraries, fast, good syntax, and very standard.

In fact, it's far more accurate to say that Python is bad at low-latency, but high throughput math can be and is frequently done.

Daniel, the annoyance here is that the more you write, the more apparent it is that you don't have experience with really . This has happened to me over and over, the other side doesn't have the experience so therefore isn't even equipped to have a meaningful discussion. It's the Blub paradox (Beating the Averages). The power difference between Python and C++ is easily on the order of 10x (in terms of what I've personally been able accomplish in one vs the other). The lines of code required to do an arbitrary task is easily 10x less, which directly translates into maintainability.

Yike Lu,
LOL
Thank you for telling me (incorrectly) which languages I do know. I won't go into the languages I used since 1972 So, what has it that APL, Smalltalk, Fortran, COBOL, Prolog, Lisp, Objective C, C++11, C# and Haskell don't have.

powerful high level languages, the best of which combine high level concepts with exceptional (although not best in class) execution speeds.

This means nothing.Can you be more specific? Do you mean the following features?

Python supports multiple programming paradigms, including object-oriented, imperative and functional programming or procedural styles. It features a dynamic type system and automatic memory management and has a large and comprehensive standard library.[28]

Many of these are shared by many languages, including C++11. C++17 will have even more features.

 

[Daniel Duffy]

This discussion remind me of the discussion on C++ versus

Smalltalk
Objective-C
Eiffel
Java

in the 80s and 90s.

They're back.

 

[Daniel Duffy]

Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes.

Been there, done that in C#, for example. It's a marginal feature, nice to have.

Cool, but probably not type safe??

Most production developers don't use these techniques (for a number of reasons).

Sorry about that, but I don't see how it improves things all that much.

 

[Yike Lu]

Python supports multiple programming paradigms, including object-oriented, imperative and functional programming or procedural styles. It features a dynamic type system and automatic memory management and has a large and comprehensive standard library.[28]

Many of these are shared by many languages, including C++11.

Ignoring other languages as it's not germane to the discussion. C++11 doesn't have dynamic types, nor automatic memory management. Smart pointers aren't automatic memory management (as attested by many segfaults that can still happen when they're used), and auto is not dynamic typing, it's static type inference. Are we even speaking the same language, have you bothered to make sure your definitions are right? And just so we're clear, so long as newer C++ has to inter-op with legacy C++ code, it will never have fully automatic memory management.

And to add, C++ classes are not first-class, the standard library doesn't have a string tokenizer (it's in Boost, it might make it in subsequent versions, which is years off), there is no package manager, no run-time interpreter.

 

[Yike Lu]

Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes.

Been there, done that in C#, for example. It's a marginal feature, nice to have.

Cool, but probably not type safe??

Most production developers don't use these techniques (for a number of reasons).

Sorry about that, but I don't see how it improves things all that much.

What exactly does customizing a language even mean to you then?

 

[Daniel Duffy]

What exactly does customizing a language even mean to you then?

It's your word, so you should define it.

 

[Daniel Duffy]

Ignoring other languages as it's not germane to the discussion. C++11 doesn't have dynamic types, nor automatic memory management. Smart pointers aren't automatic memory management (as attested by many segfaults that can still happen when they're used), and auto is not dynamic typing, it's static type inference. Are we even speaking the same language, have you bothered to make sure your definitions are right? And just so we're clear, so long as newer C++ has to inter-op with legacy C++ code, it will never have fully automatic memory management.

And to add, C++ classes are not first-class, the standard library doesn't have a string tokenizer (it's in Boost, it might make it in subsequent versions, which is years off), there is no package manager, no run-time interpreter.

One man's meat is another man's poison.

 

[Yike Lu]

It's your word, so you should define it.

No, you brought it up originally, referencing how customizable C++ was. What does it mean to you?

 

[Daniel Duffy]

the standard library doesn't have a string tokenizer (it's in Boost, it might make it in subsequent versions, which is years off)

Yes it does in C++11, it is called <regex>, but not in C++98.

See the link I posted.

 

[Daniel Duffy]

No, you brought it up originally, referencing how customizable C++ was. What does it mean to you?

In the sense that it can be extended by generic libraries. I am less interested in run-time reflection and such.
And it treats me like an adult. I like to take care of my own memory management. Garbage collection is meshuggah.

In summary, each to his own. At the end of the day.

 

[pingu]

And it treats me like an adult. I like to take care of my own memory management. Garbage collection is meshuggah.

Garbage collection is the future. it's here to stay. It seems you are stuck in the 80s when it comes to programming. C++ has libraries the implement GC. The reason GC is not part of the language has to do with the non-deterministic nature of the GC. There is a ton of legacy C++ code already written that can't take advantage of this.

From what I see, not a lot of new projects are being developed in C++ and that's the main issue going forward.

As, usual, we can bring Linus' opinion about C++

Linus Torvalds on C++

 

[pingu]

This is a show stopper for certain classes of applications, e.g. process-control, medical, derivatives book etc.

All those applications can be developed in python + C/C++ since the speed they need is not really as critical as you think and that's what people are doing now. Write 80-90% of the code in a high level language and only re-rewrite pieces that are time critical in C/C++.

 

[Daniel Duffy]

Garbage collection is the future. it's here to stay. It seems you are stuck in the 80s when it comes to programming. C++ has libraries the implement GC. The reason GC is not part of the language has to do with the non-deterministic nature of the GC. There is a ton of legacy C++ code already written that can't take advantage of this.

From what I see, not a lot of new projects are being developed in C++ and that's the main issue going forward.

As, usual, we can bring Linus' opinion about C++

Linus Torvalds on C++

You should get out more.

 

[pingu]

Hot from the presses:

Why I don't spend time with Modern C++ anymore

Why I don't spend time with Modern C++ anymore | Hacker News

 

[tfors]

I am in the Python/R camp, for reasons of inertia C++ skills will be still necessary/valuable in many settings, but I see more and more (not first hand, from snippets in the press) that at least the front office/research groups don't bother with it anymore and prototype with Python or another higher level language.