I had similar thoughts when watching GoingNaive 2013:
http://bartoszmilewski.com/2013/09/19/edward-chands/
I was more and more scared with every talk and now I am valualizing my polymorphic types a'la Sean Parent

On 9/19/13 3:18 PM, Szymon Gatner wrote:
> I had similar thoughts when watching GoingNaive 2013:
> http://bartoszmilewski.com/2013/09/19/edward-chands/

Nice piece.

> I was more and more scared with every talk and now I am valualizing my
> polymorphic types a'la Sean Parent

That I think is sketchy advice.


Andrei

On Thursday, 19 September 2013 at 22:46:09 UTC, Andrei Alexandrescu wrote:
> On 9/19/13 3:18 PM, Szymon Gatner wrote:
>> I had similar thoughts when watching GoingNaive 2013:
>> http://bartoszmilewski.com/2013/09/19/edward-chands/
>
> Nice piece.
>
>> I was more and more scared with every talk and now I am valualizing my
>> polymorphic types a'la Sean Parent
>
> That I think is sketchy advice.
>

Tbh I am still testing the effects of this change and so far I do see psitive effects on the client code but I also see that what was obvious to users before (everyone understands that they should derive from polymorpic base to get polymorphic effect) is now confusing (how can I customize if I can't derive).

Please do elaborate on your view. Always interesting to read on design from smarter people :)

On 9/19/2013 3:18 PM, Szymon Gatner wrote:
> I had similar thoughts when watching GoingNaive 2013:
> http://bartoszmilewski.com/2013/09/19/edward-chands/


http://www.reddit.com/r/programming/comments/1mqpcq/edward_chands_by_bartosz_milewski/

https://news.ycombinator.com/item?id=6414162

On Fri, Sep 20, 2013 at 12:18:22AM +0200, Szymon Gatner wrote:
> I had similar thoughts when watching GoingNaive 2013:
> http://bartoszmilewski.com/2013/09/19/edward-chands/
> I was more and more scared with every talk and now I am valualizing
> my polymorphic types a'la Sean Parent

Quote:

	There was so much talk about how not to use C++ that it occurred
	to me that maybe this wasn’t the problem of incompetent
	programmers, but that straightforward C++ is plain wrong. So if
	you just learn the primitives of the language and try to use
	them, you’re doomed.

	... [big snippage] ...

	I can go on and on like this (and I often do!). Do you see the
	pattern? Every remedy breeds another remedy. It’s no longer just
	the C subset that should be avoided. Every new language feature
	or library addition comes with a new series of gotchas. And you
	know a new feature is badly designed if Scott Meyers has a talk
	about it. (His latest was about the pitfalls of, you guessed it,
	move semantics.)

This is sooo true. It reflects my experience with C++. Honestly, it got to a point where I gave up trying to following the remedy upon the patch to another remedy to a third remedy that patches yet another remedy on top of a fundamentally broken core. I just adopt my own C++ coding style and stuck with it. Unfortunately, that approach is unworkable in real-life projects involving more than one programmer.

At work, I dread every single time I need to look at the C++ module (which fortunately has been confined to a single module, although it's also one of the largest). For "performance reasons" they eschewed the built-in C++ try/catch constructs, and implemented their own replacements using preprocessor macros. You bet there are memory leaks, pointer bugs, and all sorts of nasty things just from this one "optimization" alone.  And it just goes downhill from there.

It's this endless cycle of a remedy upon a remedy upon a patch to a remedy that drove me to look for something better. I found D. :)

One of the outstanding features of D to me is that code written with simple language constructs are, surprisingly, actually correct. As opposed to C++'s situation of code being wrong by default until you learn the 8th circle black belt advanced level C++ coding techniques.

Anyway, this bit sounds interesting:

	It’s a common but false belief that reference counting (using
	shared pointers in particular) is better than garbage
	collection. There is actual research showing that the two
	approaches are just two sides of the same coin. You should
	realize that deleting a shared pointer may lead to an arbitrary
	long pause in program execution, with similar performance
	characteristics as a garbage sweep. It’s not only because every
	serious reference counting algorithm must be able to deal with
	cycles, but also because every time a reference count goes to
	zero on a piece of data a whole graph of pointers reachable from
	that object has to be traversed. A data structure built with
	shared pointers might take a long time to delete and, except for
	simple cases, you’ll never know which shared pointer will go out
	of scope last and trigger it.

Sounds like D's decision to go with a GC may not be *that* bad after all...

	Let’s take a great leap of faith and assume that all these
	things will be standardized and implemented by, say, 2015. Even
	if that happens, I still don’t think people will be able to use
	C++ for mainstream parallel programming. C++ has been designed
	for single thread programming, and parallel programming requires
	a revolutionary rather than evolutionary change. Two words: data
	races. Imperative languages offer no protection against data
	races — maybe with the exception of D.

Welp, time to get our act together and clean up that mess that is 'shared', so that D will actually stand a chance of lasting past the next 10 years... ;-)


T

-- 
Ruby is essentially Perl minus Wall.

Szymon Gatner:

> http://bartoszmilewski.com/2013/09/19/edward-chands/

From the blog post:

>Imperative languages offer no protection against data races — maybe with the exception of D.<

What about Ada and Rust?


>Ask any C++ guru and they will tell you: avoid mutation, avoid side effects, don’t use loops, avoid class hierarchies and inheritance.<

At Going Native 2013 there was a very good talk that among other things suggests to avoid raw loops in C++ code. But while this is good advice (so much that raw loops are becoming a bit of code smell for me), there are several situations where imperative loops keep being better for me. Explicit recursion is not always more readable and more easy to understand than imperative foreach loops.

While most functions could and should be strongly pure, I often like mutation and imperative code inside functions. Haskell is a purely functional language, but I prefer a mix, like D, Scala, F#, etc. So I have to say that perhaps "D is the best functional language"[1].

Bye,
bearophile

[1] that is as much false as saying that "Haskell is the best imperative language" as some haskellers sometimes say :-)

On Thu, 19 Sep 2013 16:48:43 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Fri, Sep 20, 2013 at 12:18:22AM +0200, Szymon Gatner wrote:
> > I had similar thoughts when watching GoingNaive 2013:
> > http://bartoszmilewski.com/2013/09/19/edward-chands/
> > I was more and more scared with every talk and now I am valualizing
> > my polymorphic types a'la Sean Parent
> 

Heh, I love the article's title. Although:

"[Edward Scissorhands is] a darker version of Pinocchio, shot in suburban settings."

I saw Edward Scissorhands as being a re-telling of Frankenstein: A grotesque, but kind, man-made creature is ostracized by the frightened villagers to ultimately tragic results.

Although it could be argued that Pinocchio is a lighter re-imagining of Frankenstein anyway.

> 
> It's this endless cycle of a remedy upon a remedy upon a patch to a remedy that drove me to look for something better. I found D. :)
> 

So true.

On 9/19/2013 4:32 PM, Walter Bright wrote:
> On 9/19/2013 3:18 PM, Szymon Gatner wrote:
>> I had similar thoughts when watching GoingNaive 2013:
>> http://bartoszmilewski.com/2013/09/19/edward-chands/
>
>
> http://www.reddit.com/r/programming/comments/1mqpcq/edward_chands_by_bartosz_milewski/
>
>
> https://news.ycombinator.com/item?id=6414162

And Bartosz responds in this one:

http://www.reddit.com/r/cpp/comments/1mqhxl/edward_chands_by_bartosz_milewski/

On Friday, 20 September 2013 at 02:24:31 UTC, bearophile wrote:
> Szymon Gatner:
>
>> http://bartoszmilewski.com/2013/09/19/edward-chands/
>
> From the blog post:
>
>>Imperative languages offer no protection against data races — maybe with the exception of D.<
>
> What about Ada and Rust?
>

Many people in the C family of languages tend to disregard the Pascal family.

Sometimes I dream of a world where Modula-2 would have taken C's place. :)

..
Paulo

On Thursday, 19 September 2013 at 23:50:04 UTC, H. S. Teoh wrote:
> On Fri, Sep 20, 2013 at 12:18:22AM +0200, Szymon Gatner wrote:
>> I had similar thoughts when watching GoingNaive 2013:
>> http://bartoszmilewski.com/2013/09/19/edward-chands/
>> I was more and more scared with every talk and now I am valualizing
>> my polymorphic types a'la Sean Parent
>
> Quote:
>
> 	There was so much talk about how not to use C++ that it occurred
> 	to me that maybe this wasn’t the problem of incompetent
> 	programmers, but that straightforward C++ is plain wrong. So if
> 	you just learn the primitives of the language and try to use
> 	them, you’re doomed.
>
> 	... [big snippage] ...
>
> 	I can go on and on like this (and I often do!). Do you see the
> 	pattern? Every remedy breeds another remedy. It’s no longer just
> 	the C subset that should be avoided. Every new language feature
> 	or library addition comes with a new series of gotchas. And you
> 	know a new feature is badly designed if Scott Meyers has a talk
> 	about it. (His latest was about the pitfalls of, you guessed it,
> 	move semantics.)
>
> This is sooo true. It reflects my experience with C++. Honestly, it got
> to a point where I gave up trying to following the remedy upon the patch
> to another remedy to a third remedy that patches yet another remedy on
> top of a fundamentally broken core. [... cutted]

I dislike C, and will take C++ safety and abstraction capabilities over C, unless forced to do otherwise.

Now, having said this. I hardly write any C++ nowadays.

In the types of projects we do, it is all about JVM and .NET languages.

Sometimes even replacing "legacy C++" systems by new systems done in those languages.

So writing C++, or even C, tends to be restricted to a few method calls.

For example, recently we had a project for real time data analysis on Windows.

It was a C#/WPF application. C++ was only used for the hardware interfaces and SIMD optimizations for a few algorithms.


>
> Sounds like D's decision to go with a GC may not be *that* bad after
> all...


I like GC enabled systems programming languages since I used Oberon, and had some contact with Modula-3.

Like many things in programming, the only way to convince other developers is to have them use such systems.

--
Paulo