You can look at the source for Doom 3, it is written in C with
classes more than C++. But that was years ago, and Carmack has
taken an interest to functional programming so perhaps they are
more up to date nowadays.. although I'm guessing they have a ton
of legacy code written in C style and C with classes style..

  Perhaps he is using a haskell IDE for eclipse?

Am 28.09.2013 04:37, schrieb Froglegs:
>    You can look at the source for Doom 3, it is written in C with
> classes more than C++. But that was years ago, and Carmack has
> taken an interest to functional programming so perhaps they are
> more up to date nowadays.. although I'm guessing they have a ton
> of legacy code written in C style and C with classes style..

It is still C++. It is a multi-paradigm language.


>
>    Perhaps he is using a haskell IDE for eclipse?

EclipseFP is a very nice one, http://eclipsefp.github.io/.

Or we is doing Android or embedded development.

--
Paulo

On Friday, 27 September 2013 at 11:35:29 UTC, Bruno Medeiros
wrote:
> "Hardware does get faster more rapidly than software gets slower -- I'm finding Eclipse perfectly usable on modern hardware."
>
> https://twitter.com/ID_AA_Carmack/status/383334141078429697
>
> I would have liked some more details on what he is using Eclipse for though. Is it Android development? And even so, is it just Java or C/C++ too? Especially significant given Manu's recent comments that:
> "I've never met a C++ developer that likes Eclipse ;)"
> :p

Its probably for Android, Carmack essentially jumped ship to
OculusVR and joined as CTO, who are not looking into doing
support for it on mobile platforms. Don't let the CTO role
fool you, he is there to code at least that is what the tone
of his tweets have been. I think he is having the time of
his life working in a more upstarty environment.

> I do like C++, but every time I look what is happening post C++11, tend to be glad to spend most of my time in JVM/.NET land, specially because I deal a lot with teams full of developers with an average skill set.
>
>
>
> --
> Paulo

 Eh? C++11 makes things easier/better IMO, C++14 also has a few good things in it.  Really I'd say the main issue with C++ is how slow they are at adding some of the really important things(no modules until C++17(if then) --)

  personally I don't give a fig about developers with average skill sets, but even they are better off with newer features like auto, lambda, shared_ptr/unique_ptr

Am 28.09.2013 12:40, schrieb Froglegs:
>
>> I do like C++, but every time I look what is happening post C++11,
>> tend to be glad to spend most of my time in JVM/.NET land, specially
>> because I deal a lot with teams full of developers with an average
>> skill set.
>>
>>
>>
>> --
>> Paulo
>
>   Eh? C++11 makes things easier/better IMO, C++14 also has a few good
> things in it.  Really I'd say the main issue with C++ is how slow they
> are at adding some of the really important things(no modules until
> C++17(if then) --)

Except:

- You still need to know C and C++98 to deal with old codebases and compiler errors;

- Not everyone can use C++11 and C++14, either due to company policy or set of available compilers

- It is 4 years time until 2017, plus the time compilers will need to adopt it, how relevant in the industry would that standard still be?

>
>    personally I don't give a fig about developers with average skill
> sets, but even they are better off with newer features like auto,
> lambda, shared_ptr/unique_ptr

Good luck working in code bases of big companies.

--
Paulo

On Sat, Sep 28, 2013 at 1:23 PM, Paulo Pinto <pjmlp@progtools.org> wrote:

> - It is 4 years time until 2017, plus the time compilers will need to adopt it, how relevant in the industry would that standard still be?


This argument is not much valid anymore.
Most language or library features are implemented for testing before a
proposal is voted in (because of previous fisaco)
C++14 draft is fully supported in Clang at this time, and is even modified
real time from votes happening this week.

I mean, except if you work with Visual Studio, compiler adoption is not
really that long now.
The only real barrier is company policy. Now I don't want to work on a
company that impose artificial limitations on improvements
(other than time obviously).

Am 28.09.2013 15:26, schrieb Klaim - Joël Lamotte:
>
> On Sat, Sep 28, 2013 at 1:23 PM, Paulo Pinto <pjmlp@progtools.org
> <mailto:pjmlp@progtools.org>> wrote:
>
>     - It is 4 years time until 2017, plus the time compilers will need
>     to adopt it, how relevant in the industry would that standard still be?
>
>
> This argument is not much valid anymore.
> Most language or library features are implemented for testing before a
> proposal is voted in (because of previous fisaco)
> C++14 draft is fully supported in Clang at this time, and is even
> modified real time from votes happening this week.
>
> I mean, except if you work with Visual Studio, compiler adoption is not
> really that long now.
> The only real barrier is company policy. Now I don't want to work on a
> company that impose artificial limitations on improvements
> (other than time obviously).


Except the world of C and C++ is not just clang, gcc and visual studio, there are lots of compilers out there besides those.

Secondly, on the enterprise world of Fortune 500 consulting, where I work, most of the time one is required to use whatever toolchain the customer's IT allows for.

Working with latest standards is a startup thing, or small team projects.

There are lots of realities out there.

--
Paulo

On Sat, Sep 28, 2013 at 3:59 PM, Paulo Pinto <pjmlp@progtools.org> wrote:

> Except the world of C and C++ is not just clang, gcc and visual studio, there are lots of compilers out there besides those.
>
>
That is discutable, but it's hard to find evidence on which compilers are the most used (I'm thinking also about the Metrowerks, Borland and Intel compilers).


> Secondly, on the enterprise world of Fortune 500 consulting, where I work, most of the time one is required to use whatever toolchain the customer's IT allows for.
>
>
Yes but what I meant is that you chose to work with that constraint, I did
that and don't want to anymore because it just kills improvements for
everybody to not being able
to at least try see what's the cost of upgrading a compiler.


> Working with latest standards is a startup thing, or small team projects.
>
>
Tell that to Facebook.
Ok I guess it's a recent company, but it's not small. The point is that the
real problem is more the availability of C++ programmers that knows enough
to
improve the situation constantly, and the willing of managers to empower
them to do so.
It have nothing to do with team size.
I've seen startup go exactly the other way just because keeping the tools
at old stable versions is what the technical director is used to.
It don't mean it's bad or not.

It just mean time of implementation in most compilers is not a argument "in general" if you prefer.


> There are lots of realities out there.
>

More than you might think :D

On Fri, Sep 27, 2013 at 5:50 AM, PauloPinto <pjmlp@progtools.org> wrote:

> Doom, http://www.youtube.com/watch?**v=1PhArSujR_A<http://www.youtube.com/watch?v=1PhArSujR_A>
>
>
I thought it was Wolfenstein 3D

Paulo Pinto:

> By writing D instead. :)

D helps avoids several C++ traps, but it's far from being not-bug-prone.

Bye,
bearophile