"Reader Q&A: “Will C++ remain indispensable…?”" by Herb Sutter

[Lynn McGuire]

"Reader Q&A: “Will C++ remain indispensable…?”" by Herb Sutter:
http://herbsutter.com/2013/09/12/reader-qa-will-c-remain-indispensable/

Of course. The need for speed will always be
present.

Lynn

 

[Jorgen Grahn]

"Reader Q&A: ?Will C++ remain indispensable???" by Herb Sutter:
http://herbsutter.com/2013/09/12/reader-qa-will-c-remain-indispensable/

Of course. The need for speed will always be
present.

Never mind speed -- what other mainstream languages are C-compatible
but suck less than C? What other mainstream languages are high-level,
yet provide static typing?

/Jorgen

PS. I didn't follow the link.

 

[osmium]

Never mind speed -- what other mainstream languages are C-compatible
but suck less than C? What other mainstream languages are high-level,
yet provide static typing?

So could we say C++ is the Fortran of the 21st century? On a scale of 1 to
10, I would give C++ a -5 for elegance, a +9 for "wartiness"..

 

[Lynn McGuire]

Never mind speed -- what other mainstream languages are C-compatible
but suck less than C? What other mainstream languages are high-level,
yet provide static typing?

/Jorgen

PS. I didn't follow the link.

The article is about how mobile devices are switching
back to C++ for "performance per watt". Facebook and
Google already swapped their server side scripts back
to C/C++ better performance years ago and now the
mobile devices are heading that way also.

Lynn

 

[woodbrian77]

So could we say C++ is the Fortran of the 21st century? On a scale of 1 to
10, I would give C++ a -5 for elegance, a +9 for "wartiness"..

You didn't say what you think is better! C++ has its
warts. I don't think anyone will argue with that.

Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net

 

[woodbrian77]

The article is about how mobile devices are switching
back to C++ for "performance per watt".

Is switching back the right term? Anyway, I wonder who
is leading the way in terms of using C++ on mobile devices.

Facebook and
Google already swapped their server side scripts back
to C/C++ better performance years ago and now the
mobile devices are heading that way also.

Ebenezer doesn't have to switch because I've been saying
for years that little scripts have a tendency to become
big messes. I took my own advice a few months ago and
converted a Python test program to a C++ program. Hasn't
paid off yet, but long term it may.

Brian
http://webEbenezer.net

 

[Jorgen Grahn]

Is switching back the right term? Anyway, I wonder who
is leading the way in terms of using C++ on mobile devices.


Ebenezer doesn't have to switch because I've been saying
for years that little scripts have a tendency to become
big messes. I took my own advice a few months ago and
converted a Python test program to a C++ program. Hasn't
paid off yet, but long term it may.

There's definitely a place for other languages and IMO a C++
programmer is handicapped if she doesn't know and use some of them.

And yet ...

Since ten years ago I've been writing a lot of stuff in Python.
I really like the language. But more recently, I find if I go back
and try to extend those programs, I no longer understand them. The
lack of static typing makes them fuzzy and hard to get a grip on.

So I tend to convert them to C++ whenever they need extending.
It usually doesn't take a lot of time, and in the end I have something
/solid/, understandable and extensible. It feels like taking the
original program and filling in the missing pieces which make it
complete.

Stroustrup says in his books that he believes static typing is vital
in a large system. I tend to agree, because I find it's so hekpful in
/small/ systems.

This affects my Python programs, but not my simpler shell scripts and
Perl code. And I believe it extends to varios dynamic langages which
I haven't tried.

/Jorgen

 

[Melzzzzz]

Never mind speed -- what other mainstream languages are C-compatible
but suck less than C?

What you mean by that?

What other mainstream languages are high-level,
yet provide static typing?

Haskell?

 

[Jorgen Grahn]

What you mean by that?

That (a) easy and natural access to the many C APIs and C libraries is
a more important factor than speed, and (b) C itself is inadequate,
and (c) I can think of no others.

Haskell?

I wouldn't call Haskell mainstream ... but I am biased against
functional programming as a general technique.

/Jorgen

 

[Bo Persson]

Scott Lurndal skrev 2013-09-13 21:17:

The "performance per Watt" measure isn't driving choice of language or
conversion to C or C++, but rather driving consolidation
via virtualization and driving lower-power designs at new nodes (e.g. the
14nm Atom just shown at IDF). Rewriting applications from java/python/php
to C++ can't be cost effective when contrasted with purchasing new,
more efficient, hardware (e.g. a 20w TDP haswell instead of a 65w TDP sandybridge).

It actually can be.

When you are already using low-power designs AND have moved your server
centers close to the arctic circle (to save on cooling), looking at more
efficient programs is the logical next step.

We are talking megawatts here.


Bo Persson

 

[see.my.homepage]

What other mainstream languages are high-level,

yet provide static typing?

Not sure what do you mean by "mainstream", but in the high-level with static typing and non functional category Ada seems to tick all checkboxes:

http://www.ada2012.org/

Interestingly, Ada has built-in facilities for integration with C and C++ (actually, for most programmers gcc will be the compiler of choice anyway, which makes the integration even easier), so can be an interesting alternative for those C++ programmers who would like to expand their toolset.

 

[Tobias Müller]

Never mind speed -- what other mainstream languages are C-compatible
but suck less than C? What other mainstream languages are high-level,
yet provide static typing?

I hope that Rust will eventually fill that hole. It's not mature yet, but
evolving quickly.

Tobi

 

[woodbrian77]

Scott Lurndal skrev 2013-09-13 21:17:



It actually can be.

When you are already using low-power designs AND have moved your server
centers close to the arctic circle (to save on cooling), looking at more
efficient programs is the logical next step.

I'd rate efficient programs higher since not many polar bears
use computers.

 

[woodbrian77]

I hope that Rust will eventually fill that hole. It's not mature yet, but
evolving quickly.

http://www.rust-lang.org/

I'd suggest

"A short summary of features" -> "Feature summary"

"A very small taste of what it looks like" -> "An example
of what it looks like"

I'm not seeing the on line generation of Rust code.

 

[Öö Tiib]

Never mind speed -- what other mainstream languages are C-compatible
but suck less than C? What other mainstream languages are high-level,
yet provide static typing?

None of the programming languages sucks (so it is hard to measure that
"less"). Each has some warts that are easy to overcome with policies and
some tools that aid to follow those policies.

On one hand good programmer can write good software using any language and
on other hand monkey can't write software anyway. What really sucks is how
that large number of programming languages causes stupid arguments and
everybody lose thanks to inability to interact and to deal with actual
problems.

Matching quote from well-known Jewish legend:

And so God scattered them upon the face of the Earth, and confused
their languages, so that they would not be able to return to each
other, and they left off building the city, which was called Babel
"because God there confounded the language of all the Earth"

PS. I didn't follow the link.

Me neither. Programming language can't be "indispensable". It can be
either used or forgotten and not used. Thousands of good developers
prefer C++ and so they write software in C++. Enforcing them to avoid
it ... now that is expensive.

 

[Lynn McGuire]

The article isn't about how 'mobile devices are switching back
to C++'. It's an attempt to answer a question posed by a reader
regarding the future indispensibility of the C++ language. Mobile devices
based on Android are still programmed at the application level in Java,
and on Iphone using Objective C.

The "performance per Watt" measure isn't driving choice of language or
conversion to C or C++, but rather driving consolidation
via virtualization and driving lower-power designs at new nodes (e.g. the
14nm Atom just shown at IDF). Rewriting applications from java/python/php
to C++ can't be cost effective when contrasted with purchasing new,
more efficient, hardware (e.g. a 20w TDP haswell instead of a 65w TDP sandybridge).

scott

Wrong. Go read up on Facebook getting a 2X
payback on cpu cycles by converting their PHP
code into C++:

http://news.softpedia.com/news/With...-PHP-Flexibility-and-C-Raw-Speed-133973.shtml

"As one of the biggest websites in the world and certainly one of the
most complex, Facebook is looking at any trick in the book to squeeze
some more performance out of its infrastructure. One of the most
ambitious undertakings, one it kept quiet about until now, HipHop for
PHP is a project designed to speed up the popular programming language.
In short, HipHop 'translates' PHP code into "highly optimized" C++ code
which is then compiled and run on the servers."

Lynn

 

[Lynn McGuire]

The article isn't about how 'mobile devices are switching back
to C++'. It's an attempt to answer a question posed by a reader
regarding the future indispensibility of the C++ language. Mobile devices
based on Android are still programmed at the application level in Java,
and on Iphone using Objective C.

The "performance per Watt" measure isn't driving choice of language or
conversion to C or C++, but rather driving consolidation
via virtualization and driving lower-power designs at new nodes (e.g. the
14nm Atom just shown at IDF). Rewriting applications from java/python/php
to C++ can't be cost effective when contrasted with purchasing new,
more efficient, hardware (e.g. a 20w TDP haswell instead of a 65w TDP sandybridge).

scott

And btw, I wrote a Smalltalk to C++ converter several
years because of Win16 issues and performance. I got
a modern Win32 C++ program and a 100X performance
increase. My customers loved it!

Lynn

 

[Melzzzzz]

On Sat, 14 Sep 2013 08:17:19 -0700 (PDT)

http://www.rust-lang.org/

Heh,
{- Rust implementation
fn main() {
let nums = [0, 1, 2, 3];
let noms = ["Tim", "Eston", "Aaron", "Ben"];

let mut evens = nums.iter().filter(|&x| x % 2 == 0);

for evens.advance |&num| {
do spawn {
let msg = fmt!("%s says hello from a lightweight thread!",
noms[num]);
println(msg);
}
}
}
-}

import Control.Concurrent

main = do
let noms = ["Tim", "Eston", "Aaron", "Ben"]
evens = [x | (x,y) <- zip noms [0..], even y]
vars <- mapM (\x -> do
var <- newEmptyMVar
forkIO $ do
putStrLn
$ x ++ " says hello from a lightweight thread!"
putMVar var () -- signal finished
return var) evens
mapM_ takeMVar vars -- thread join(s)

Rust is not bad, but I prefer Haskell

 

[Jorgen Grahn]

None of the programming languages sucks (so it is hard to measure that
"less"). Each has some warts that are easy to overcome with policies and
some tools that aid to follow those policies.

I disagree. It's true that no language is a silver bullet, and it's
true that you can do very decent work in C. But it's also true that
you can do that work a whole lot better in C++. Policies and tools
are not replacements (unless the tool is a C++ compiler).

/Jorgen

 

[Melzzzzz]

On Sat, 14 Sep 2013 08:17:19 -0700 (PDT)

// This is changed example as trunk version bring lot of changes...

fn main() {
let nums:[int,..4] = [0, 1, 2, 3]; // compiler can't infer type now
let noms = ["Tim", "Eston", "Aaron", "Ben"];

let mut evens = nums.iter().filter(|&x| x % 2 == 0);

for num in evens { // new syntax for for
let nom = noms[*num]; // &num cannot be captured in closure
do spawn {
let msg = fmt!("%s says hello from a lightweight thread!",
nom);
println(msg);
}
}
}

Heh, I started to learn Rust as language is really functional style
friendly