Re: C++ launched its community survey, too
On Sunday, 11 March 2018 at 02:21:30 UTC, Laeeth Isharc wrote: On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition. Watch this space... And we have warp which is a C preprocessor written in D, just saying ;)
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition. Watch this space...
Re: C++ launched its community survey, too
On Wed, Mar 07, 2018 at 03:52:19PM +, Nick Treleaven via Digitalmars-d wrote: > On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote: > > As Andrei wrote in TDPL, (and I paraphrase,) it sucks when built-in > > types have magical abilities inaccessible to user code. This is a > > common defect in many programming languages... the "magical" > > behaviour is wonderful when it works. But if you need something that > > said "magic" doesn't cover, you're left up the creek without a > > paddle. In D, however, you're given the tools to build your own > > equivalents of language built-ins. > > Not true for implicit construction of a user-defined type. So you > can't have a `struct Pointer` wrap a pointer fully because you can't > pass null to a function taking a Pointer. You can't do the same for > Algebraic element types, they're not Algebraic. In C++ you can, but > it's by default, so you get implicit construction even when the *type > author* didn't intend it to work. Yeah, D does still have some dirty corners where built-in types still have "magical" behaviour. It's much better than other languages in this regard, though, AFAIK. T -- Why do conspiracy theories always come from the same people??
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote: As Andrei wrote in TDPL, (and I paraphrase,) it sucks when built-in types have magical abilities inaccessible to user code. This is a common defect in many programming languages... the "magical" behaviour is wonderful when it works. But if you need something that said "magic" doesn't cover, you're left up the creek without a paddle. In D, however, you're given the tools to build your own equivalents of language built-ins. Not true for implicit construction of a user-defined type. So you can't have a `struct Pointer` wrap a pointer fully because you can't pass null to a function taking a Pointer. You can't do the same for Algebraic element types, they're not Algebraic. In C++ you can, but it's by default, so you get implicit construction even when the *type author* didn't intend it to work.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote: On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite -2018-02 > > Andrei I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support. The main problem with that is that the fact that as soon as you're willing to break backwards compatability in C++, then you lose one of the major benefits of C++ (that the same code compiles pretty much forever) No, you wouldn't, just do what D did with the 2.0 branch: put all the breaking changes in a new version, while continuing to support those clinging to old codebases with an older branch. D did it and survived the branch with much less resources, I see no reason C++ couldn't do the same with their massive resources. and that if you're willing to give up on that, you might as well be using another language like D or Rust. I'm sure that there's a crowd who would love to break some aspects of backwards compatability with C++ and stick with it rather than switching to another language, but if someone actually really tried to fix C++, you wouldn't end up with C++ anymore. You might not end up with D or Rust, but it would definitely be a new language, and if you're willing to do that, why stick with C++? Those people are more likely to leave when you don't clean up C++, including deprecating bad features. Users are always coming and going: you need to have some vision of what C++ will evolve into that will keep a lot of them, while still keeping enough backwards compatibility that most don't leave. However, the way the politics works at any large, successful organization is that the ones pushing to maintain the status quo win out: after all, they've won out so far, so they clearly know what they're doing? Then, they inevitably fade away, as they lose touch with reality in their bubble. The _only_ time this pattern breaks is if they're on the verge of dying and the crisis allows for radical change, such as when they brought Steve Jobs back to Apple and let him clean house, and that's almost always too late. C++ is not in crisis yet, so nothing will happen. The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. There are ways to clean up that C integration though, as D has shown with one approach. There's no reason to carry around this legacy baggage forever. C++ stagnates because of a lack of creativity, will, and vision, which is going to happen to any organization that gets fat and successful. There are many things they could do to change this descent, but they lack those essential ingredients to do them.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei
Alexandrescu wrote:
https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
Andrei
I have submitted, already. My major complaints boils down to
the fact that they refuse to deprecated features due to
religious like devotions to backwards compatibility support.
Well, not religious but... they are removing things too slow.
There is a paper about stability and velocity of C++ that
proposes to widen things to move forward faster and... btw I
complained about exactly that as well. Things are getting bigger
and bigger, just discard things. I also complained about the
following:
1.- everyone is saying stop the preprocessor... modules support
no preprocessor after import... ok, then, why feature test
macros? They should be enums or constexpr but never a
preprocessor macro.
2.- the single thing that bothers me the most... initialization
is a mess, especially after adding {} vs (). With good intention,
but the cognitive overhead and room for surprises is too big.
3.- if constexpr cannot simply compete with static if. I
suggested adding: if constexpr that does not require a template
function, and some alternative if constexpr mechanism (I do not
care about the name or if it is a separate feature) that can
conditionally compile structs or block scopes a la version() in
D. This feature is needed to kill the preprocessor if they really
want to take that seriously, especially with modules on its way.
BTW, I have been trying a bit of D lately and I like how flexible
things such as opDispatch and static if are. I love modules as
well. I like a lot also the fact that you do not need to be
prefixing all things all the time because of potential hijacking.
The static reflection has also been useful for me. I was just
coding a SNES ROM parser but that was enough already to show some
of the advantages.
Re: C++ launched its community survey, too
On Wed, Feb 28, 2018 at 09:46:49PM +, TheFlyingFiddle via Digitalmars-d
wrote:
> On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:
>
> Just to give some background. At work I spend most of my time
> maintaining legacy systems adding some small features or replacing
> subcomponents. So most of what I do is reading code and making some
> minor changes (unless it's buggy code then you get to rewrite :))
In spite of my job title being SW engineer, this actually almost exactly
describes what I do. :-D Well, OK, sometimes a larger feature is asked
for and I get to write fresh code, but 90% of my daily duties is reading
other people's code, fixing bugs, and making relatively minor changes.
[...]
> Perl is a maintenance nightmare. It just takes so much time to figure
> out what the code actually does. Particularity if it has been changed
> by multiple people over the years.
That applies to almost any code changed by a large number of people over
the years. :-D Especially when it's code written in a commercial
environment where there's a high turnover and people are forced to
implement last-minute hacks due to customer demands and impractically
tight deadlines. Over time, the hacks accumulate on top of each other
into a brittle tower of cards that pretty much is guaranteed to break at
the slightest change, mostly in apparently unrelated places where you
won't notice until something blows up later.
Sometimes I just have to shake my head and walk away, and admit defeat
that I *don't* understand what the code does, and neither do I want to,
because I might need therapy afterwards. :-D
> That's the main reason Perl is at the top of my most disliked
> languages.
In my case, that also applies to badly-maintained C/C++ code!
[...]
> > And the whole thing about == vs === is just one huge WAT. It "makes
> > sense" if you understand why it's necessary, but it just begs the
> > question, why, oh why, wasn't the language designed properly in the
> > first place so that such monstrosities aren't necessary?!
>
> Another personal favorite.
> function foo($myArray) {
>return $myArray['test'];
> }
>
> $myString = "hello, world";
> $test = foo($myString);
>
> echo $test; // $test = 'h'; Because you know 'test' auto converts to 0.
Hahaha... yeah. This is one of the things that make me hate dynamically
typed languages so much. Your types can change from under you at any
time without any warning, usually with disastrous consequences, but
should you be so unlucky as to have said consequences masked by more
"convenient" auto type conversions, you quickly find yourself wishing
for a real type system. Like when you mistype the name of an optional
field in a data structure, and the receiving code simply ignores the
mistyped field. No warnings or indications whatsoever of what went
wrong.
[...]
> > > Compared to them, programming in C++ or Java for that matter is
> > > like a dream.
> >
> > C++ is hardly any better, actually:
> >
> > https://bartoszmilewski.com/2013/09/19/edward-chands/
>
> Yeah... C++ is interesting in that way. Mostly what I have seen is
> that for any given project they have a strict policy of how to do
> memory management and error handling.
Yes, essentially the only way to work with C++ in a sane way is to
restrict yourself, either by convention or by policy, to a strict subset
of C++. Google, for example, places heavy restrictions on what parts of
C++ are allowed in their codebase. Full C++ contains just too many
pathological things that code that's actually free-for-all in that way
quickly becomes completely unmaintainable.
Reminds me of a C++ project I had to work with once, where useful work
was done in dtors via side-effects. Good luck figuring out what the
code does from glancing at it! (It begins with a mystified "why does
this function only contain some variable declarations and nothing
else?", and goes downhill from there.)
> Also it's not really a pleasure reading C++ templates :D.
C++ template syntax makes me cringe every time I see it. Reminds me of
all those battle scars I accumulated in the 2 decades or so I was
actively using C++.
[...]
> The awful and nice part of Java is that since your forced to do things
> a certain way then things will actually be done in that way. In this
> case OOP and all of that. It's nice when you read the code, awful when
> you actually have to code in it.
I dunno, I've seen Java code written in a way that's anything but OO,
with 10-page long functions that contain essentially the entire program,
and other clear symptoms of spaghetti code and general cloudiness in the
author's mind. All "nicely" wrapped up, of course, in a class, complete
with a bow-tie, in lip service to OO.
As somebody once said, A true programmer can write assembly code in any
language. :-D
> > > Only thing missing is the ability to do arbitrary system calls
> > > during compilation :D
> >
> > AKA
> >
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:
Just to give some background. At work I spend most of my time
maintaining legacy systems adding some small features or
replacing subcomponents. So most of what I do is reading code and
making some minor changes (unless it's buggy code then you get to
rewrite :))
The idea of sigils is actually not a bad one. It does, after
all, have basis in natural languages. But the way it was
implemented in Perl is, shall we say, rather quirky, leading to
all sorts of unexpected interactions with other things and
generally become a cognitive burden in large projects, where a
disproportionate amount of time is spent fighting with syntax
rather than getting things done. (E.g., is it @$x[$y] or $x->y
or ${x}{y} or ${x->$y}[$z] or something else?)
Perl is a maintenance nightmare. It just takes so much time to
figure out what the code actually does. Particularity if it has
been changed by multiple people over the years.
That's the main reason Perl is at the top of my most disliked
languages.
Yeah, that's 10 trains worth of WATs right there. :-D
And the whole thing about == vs === is just one huge WAT. It
"makes sense" if you understand why it's necessary, but it just
begs the question, why, oh why, wasn't the language designed
properly in the first place so that such monstrosities aren't
necessary?!
Another personal favorite.
function foo($myArray) {
return $myArray['test'];
}
$myString = "hello, world";
$test = foo($myString);
echo $test; // $test = 'h'; Because you know 'test' auto converts
to 0.
Now PHP does have many WATs but it's still simpler to read than
Perl so it has an edge over Perl for me atleast.
Compared to them, programming in C++ or Java for that matter
is like a dream.
C++ is hardly any better, actually:
https://bartoszmilewski.com/2013/09/19/edward-chands/
Yeah... C++ is interesting in that way. Mostly what I have seen
is that for any given project they have a strict policy of how to
do memory management and error handling. Also it's not really a
pleasure reading C++ templates :D.
Java... well, Java is a walled garden, a somewhat nice (if
verbose) one that's somewhat detached from reality, but
forcefully anchored to it by big commercial interests. As a
language it's not too bad; the core language is pretty nicely
designed -- in an idealistic, ivory tower sort of sense.
But in practice, it's more of a Write Once, Debug Everywhere
deal. The verbosity and IDE dependence sucks. The OO
fanaticism also sucks (singleton classes IMO is a big code
smell, esp. when it's really just syntactic lip service to the
OO religion for what's essentially global functions). The lack
of real generics is total suck, and a showstopper for me. Even
the half-hearted attempt at generics that they shoehorned into
it later doesn't fully save it from being sucky. The only
saving grace of Java is the extensive library support -- you
can find just about anything you might imagine as a library,
which saves you from dealing with the suckier parts of the
language. Most of the time.
The awful and nice part of Java is that since your forced to do
things a certain way then things will actually be done in that
way. In this case OOP and all of that. It's nice when you read
the code, awful when you actually have to code in it.
Only thing missing is the ability to do arbitrary system calls
during compilation :D
AKA
compile-my-source-code-and-get-a-trojan-installed-on-your-system. :-D If this ?
(mis)feature ever gets merged into DMD, give me a call right
away -- I have a lot of source code to sell you. For free. :-D
Why must you ruin my perfect plan of getting a free botnet! :D
Re: C++ launched its community survey, too
On Wed, Feb 28, 2018 at 06:45:29PM +, TheFlyingFiddle via Digitalmars-d
wrote:
[...]
> My least preferredlanguage of all times would be Perl. With (PHP 5.3)
> coming in at a close second :)
>
> Perl is just... I get it, you can write somewhat nicer bash scripts in
> the language.
I was actually a Perl (5) fan for many years, before finding D. As you
said, it's very nice for replacing brittle (and ugly!) shell scripts,
not to mention with superior performance instead of spawning a
subprocess (somtimes multiple) for basically every command, even
fundamental things like evaluating an expression. (Though bash may have
built-in some of it... but still.)
PHP is just... well, OK, one has to admit that the idea of embedding
code in HTML and vice versa in a smooth syntax that you can easily
transition into and out of, was an extremely clever one. It removed the
burden of constant escaping (aka the leaning toothpick syndrome) that
was prevalent in such kind of code back in the day. But other than
that.. PHP has some pretty serious fundamental design flaws that became
calcified as features because just about everything depended on it, and
after a while, it was just a monster of a language, most eloquently
described as:
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
> But people... they just go with it and build these huge crazy systems
> that somehow 10+ years later become my problem.
Yeah... Perl is great for one-off scripts and clever hacks. But the way
it's designed also makes it not very scalable. Once you get past a
certain size, the quirky syntax and general looseness (in typing,
semantics, data structures, etc.) just start becoming more and more of a
maintenance burden.
At least, that was the case for Perl 5, which was around the time I
found D and left Perl behind. Can't speak for Perl 6 or later.
> The designer of Perl was clearly insane. Let's store everything in fun
> global "invisible" variables, functions don't specify arguments... And
> lets have the first letter of the variable define how/what $, @, %,
> with fun auto conversions everywhere :D.
The idea of sigils is actually not a bad one. It does, after all, have
basis in natural languages. But the way it was implemented in Perl is,
shall we say, rather quirky, leading to all sorts of unexpected
interactions with other things and generally become a cognitive burden
in large projects, where a disproportionate amount of time is spent
fighting with syntax rather than getting things done. (E.g., is it
@$x[$y] or $x->y or ${x}{y} or ${x->$y}[$z] or something else?)
D's dot syntax, by comparison, is worlds better. One dot to rule 'em
all. Symmetry is powerful. ;-)
> PHP is better but there is some really weird stuff in it.
Actually, IMO, PHP is far worse than Perl. Perl is pretty crazy, yeah,
but it does have a certain kind of logic behind it (albeit a twisted
one, just like its creator :-P), a kind of consistency that makes you go
"yeah, in retrospect it *does* make sense, even though it's still really
weird". PHP, OTOH, is full of exceptions and corner cases *without* any
underlying consistency. There is no pattern to it, not even a twisted
one, it's just a bunch of arbitrary exceptions and special cases that
you basically have to memorize. And random things just Don't Work(tm),
just because they don't, for no discernible reasons whatsoever. Like
the inability to overload class constructors, even though polymorphism
is supported, a very strange combo. And the word "overload" is used in
a strange, different sense, just to confuse you.
> Of the top of my head is the auto type conversion system. This works,
> by design...
>
> //PHP
> $a = 5;
> $b = $a * "10 trains";
> echo $b; //$b is now 50... Fun and interesting stuff right there
Yeah, that's 10 trains worth of WATs right there. :-D
And the whole thing about == vs === is just one huge WAT. It "makes
sense" if you understand why it's necessary, but it just begs the
question, why, oh why, wasn't the language designed properly in the
first place so that such monstrosities aren't necessary?!
> Compared to them, programming in C++ or Java for that matter is like a
> dream.
C++ is hardly any better, actually:
https://bartoszmilewski.com/2013/09/19/edward-chands/
Java... well, Java is a walled garden, a somewhat nice (if verbose) one
that's somewhat detached from reality, but forcefully anchored to it by
big commercial interests. As a language it's not too bad; the core
language is pretty nicely designed -- in an idealistic, ivory tower sort
of sense.
But in practice, it's more of a Write Once, Debug Everywhere deal. The
verbosity and IDE dependence sucks. The OO fanaticism also sucks
(singleton classes IMO is a big code smell, esp. when it's really just
syntactic lip service to the OO religion for what's essentially global
functions). The lack of real generics is total suck, and a showstopper
for me. Even the half-hearted attempt at
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 10:15:13 UTC, Zoadian wrote: On Wednesday, 28 February 2018 at 00:53:16 UTC, psychoticRabbit wrote: It should have gone to the Java developers - cause they deserved it. C++ is the worst thing to have ever come out of computer science! yes c++ is not the greatest language (thats why i use D). but java is the worst language i've ever used. My least preferredlanguage of all times would be Perl. With (PHP 5.3) coming in at a close second :) Perl is just... I get it, you can write somewhat nicer bash scripts in the language. But people... they just go with it and build these huge crazy systems that somehow 10+ years later become my problem. The designer of Perl was clearly insane. Let's store everything in fun global "invisible" variables, functions don't specify arguments... And lets have the first letter of the variable define how/what $, @, %, with fun auto conversions everywhere :D. PHP is better but there is some really weird stuff in it. Of the top of my head is the auto type conversion system. This works, by design... //PHP $a = 5; $b = $a * "10 trains"; echo $b; //$b is now 50... Fun and interesting stuff right there Compared to them, programming in C++ or Java for that matter is like a dream. But when I can, I always use D. Mainly because unlike every other language, it has static introspection, ctfe and mixins. A whole new world of expressive power is gained by this. Only thing missing is the ability to do arbitrary system calls during compilation :D
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 19:03:54 UTC, Mark wrote: On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote: On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support. You're not the only one who thinks so - https://www.youtube.com/watch?v=ND-TuW0KIgg ;) Modules couldn't make it but we have a new syntactic sugar for SFINAE. [someone should make for Dlang too]
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 12:06:38 UTC, Stefan Koch wrote: On Wednesday, 28 February 2018 at 11:32:32 UTC, Atila Neves wrote: On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote: On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago). I'm working on this. Atila You do ? Please link me to your progress if you can. I had an earlier version with could successfully #include nanomsg, then I ran into problems doing the same thing with curl, and restarted from scratch. My DConf talk submission is on this. Atila
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 11:32:32 UTC, Atila Neves wrote: On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote: On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago). I'm working on this. Atila You do ? Please link me to your progress if you can.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. I think you can have C plus another language just fine. In C++ you use extern "C" as a wrapper, you could easily run a completely different parser within an extern "C" block and build a different type of AST for it. This was probably out of reach in the 80s and early 90s when compiler resources was an issue, but with LLVM and gigabytes of RAM I think it would be quite reasonable to do something like that. People don't do it because the basic counter argument always is "but we already support C through linkage", but that doesn't mean that there would be no real productivity advantage to building C into the language. Not that I would do it if I designed a system level language, mostly because I think it would be better to build tools for transpiling code from C to the new language. C is a dead end now, I think. Ola
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote: On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago). I'm working on this. Atila
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: On Tue, Feb 27, 2018 at 01:33:18PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] [...] Not strictly true. My old C++98 project no longer compiled with the latest g++, because it contained things allowed in C++98 that are no longer allowed in C++17. Some things were relatively simple to fix, but others were quite painful to fix, so I ended up using --std=c++11 as a workaround instead. In the frustrating process of trying to fix things C++17 complains about, I threw in the towel and decided to rewrite it in D instead. [...] The fun with C++ the same expression means completely different things in C++98 and C++11 fon< fun< 1 >>::three >::two >::one and there's no context change, it's parsing rules that changed. https://gustedt.wordpress.com/2013/12/18/right-angle-brackets-shifting-semantics
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 00:53:16 UTC, psychoticRabbit wrote: It should have gone to the Java developers - cause they deserved it. C++ is the worst thing to have ever come out of computer science! yes c++ is not the greatest language (thats why i use D). but java is the worst language i've ever used.
Re: C++ launched its community survey, too
On 2/27/2018 9:41 AM, H. S. Teoh wrote: And just about every new dmd release, people fume on this forum about regressions and gratuitous code breakages. On Tuesday, sure. Then on Wednesday the same people propose breaking changes :-) Everybody wants it both ways, including me.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei "If you could wave a magic wand and change one thing about any part of C++, what would it be, and how would that change help your daily work?" Deprecate C++, endorse D, and allocate all existing resources to either improving D, or implementing a fork of D. "Do you have any additional feedback for C++ standardization?" It's time for C++ to retire, and make room for better, emerging languages. I hate having to use it.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei really, online surveys are dodgy at best. btw. Bjarne Stroustrup recently received the 2018 Charles Stark Draper Prize for Engineering - https://www.nae.edu/Activities/Projects/Awards/DraperPrize/DraperWinners/2018Draper.aspx I think that is dodgy too. Why give someone a prize for creating C++. I just don't get it. It should have gone to the Java developers - cause they deserved it. C++ is the worst thing to have ever come out of computer science! The only reason it's still with us, is because corporations are stuck with it, and force it on us all, cause it's too expensive for them to replace. I want no part of it. The answer to Q:15 => I'd go back in history and make Stroustrup a fluffy dog, or a fluffy cat or something.
Re: C++ launched its community survey, too
On Tuesday, February 27, 2018 15:28:21 H. S. Teoh via Digitalmars-d wrote: > On Tue, Feb 27, 2018 at 09:44:45PM +, bachmeier via Digitalmars-d wrote: > > On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: > > > Granted, though, this is a lot easier than having to write JNI > > > wrappers or (carefully!) translate C headers into D. It would be > > > nice if you could actually just copy-n-paste a C header into an > > > extern(C) block in D and have it Just Work(tm), but practically all > > > C headers are dependent on macros one way or another that it would > > > require including an entire C processor inside the D compiler, which > > > is not exactly an inviting proposition. > > > > Walter has said that he has considered doing that now that DMC is > > Boost licensed: > > https://forum.dlang.org/post/p58q2l$1d35$1...@digitalmars.com > > Wouldn't that cause compatibility issues with gdc/ldc? It wouldn't if the idea were to move parts of dmc into the frontend, and _something_ would have to be put in the frontend for such a thing, even if it meant accessing the C/C++ compiler via library rather than adding the C/C++ stuff into the frontend itself. But I don't know what Walter is thinking exactly. - Jonathan M Davis
Re: C++ launched its community survey, too
On Tue, Feb 27, 2018 at 09:44:45PM +, bachmeier via Digitalmars-d wrote: > On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: > > > Granted, though, this is a lot easier than having to write JNI > > wrappers or (carefully!) translate C headers into D. It would be > > nice if you could actually just copy-n-paste a C header into an > > extern(C) block in D and have it Just Work(tm), but practically all > > C headers are dependent on macros one way or another that it would > > require including an entire C processor inside the D compiler, which > > is not exactly an inviting proposition. > > Walter has said that he has considered doing that now that DMC is > Boost licensed: > https://forum.dlang.org/post/p58q2l$1d35$1...@digitalmars.com Wouldn't that cause compatibility issues with gdc/ldc? T -- Give me some fresh salted fish, please.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote: On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite -2018-02 > > Andrei I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support. The main problem with that is that the fact that as soon as you're willing to break backwards compatability in C++, then you lose one of the major benefits of C++ (that the same code compiles pretty much forever) and that if you're willing to give up on that, you might as well be using another language like D or Rust. I'm sure that there's a crowd who would love to break some aspects of backwards compatability with C++ and stick with it rather than switching to another language, but if someone actually really tried to fix C++, you wouldn't end up with C++ anymore. You might not end up with D or Rust, but it would definitely be a new language, and if you're willing to do that, why stick with C++? The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. - Jonathan M Davis Yes I know that backwards compatibility comes with benefits, but gosh darn it, it doesn't stop me from complaining about it. Even more so it's very popular language to develop video games on it.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: Granted, though, this is a lot easier than having to write JNI wrappers or (carefully!) translate C headers into D. It would be nice if you could actually just copy-n-paste a C header into an extern(C) block in D and have it Just Work(tm), but practically all C headers are dependent on macros one way or another that it would require including an entire C processor inside the D compiler, which is not exactly an inviting proposition. Walter has said that he has considered doing that now that DMC is Boost licensed: https://forum.dlang.org/post/p58q2l$1d35$1...@digitalmars.com
Re: C++ launched its community survey, too
On Tue, Feb 27, 2018 at 01:33:18PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
[...]
> The main problem with that is that the fact that as soon as you're
> willing to break backwards compatability in C++, then you lose one of
> the major benefits of C++ (that the same code compiles pretty much
> forever)
Not strictly true. My old C++98 project no longer compiled with the
latest g++, because it contained things allowed in C++98 that are no
longer allowed in C++17. Some things were relatively simple to fix, but
others were quite painful to fix, so I ended up using --std=c++11 as a
workaround instead. In the frustrating process of trying to fix things
C++17 complains about, I threw in the towel and decided to rewrite it in
D instead.
[...]
> The other problem is that many of C++'s problems come from being a
> superset of C, which is also a huge strength, and it would be a pretty
> huge blow to C++ if it couldn't just #include C code and use it as if
> it were C++.
Not strictly true either. Most modern C header files come wrapped with:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif __cplusplus
because without that, a lot of C headers actually would *not* compile.
Granted, though, this is a lot easier than having to write JNI wrappers
or (carefully!) translate C headers into D. It would be nice if you
could actually just copy-n-paste a C header into an extern(C) block in D
and have it Just Work(tm), but practically all C headers are dependent
on macros one way or another that it would require including an entire C
processor inside the D compiler, which is not exactly an inviting
proposition.
> To truly fix C++ while retaining many of its strengths would require
> fixing C as well, and that's not happening.
[...]
Actually, C and C++ have already somewhat diverged. The C subset of C++
is an actually older dialect of C, and no longer 100% compatible with
modern C. Though it's true that it's still 95% compatible, which is
Good Enough(tm) for most purposes.
T
--
A program should be written to model the concepts of the task it performs
rather than the physical world or a process because this maximizes the
potential for it to be applied to tasks that are conceptually similar and, more
important, to tasks that have not yet been conceived. -- Michael B. Allen
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:25:32 UTC, JN wrote: On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei D community survey is coming soon? :) Yes. Stay tuned.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago).
Re: C++ launched its community survey, too
On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote: > On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu > > wrote: > > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite > > -2018-02 > > > > Andrei > > I have submitted, already. My major complaints boils down to the > fact that they refuse to deprecated features due to religious > like devotions to backwards compatibility support. The main problem with that is that the fact that as soon as you're willing to break backwards compatability in C++, then you lose one of the major benefits of C++ (that the same code compiles pretty much forever) and that if you're willing to give up on that, you might as well be using another language like D or Rust. I'm sure that there's a crowd who would love to break some aspects of backwards compatability with C++ and stick with it rather than switching to another language, but if someone actually really tried to fix C++, you wouldn't end up with C++ anymore. You might not end up with D or Rust, but it would definitely be a new language, and if you're willing to do that, why stick with C++? The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. - Jonathan M Davis
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei D community survey is coming soon? :)
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 17:46:58 UTC, Adam D. Ruppe wrote: On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote: And just about every new dmd release, people fume on this forum about regressions and gratuitous code breakages. Not all deprecations/code breakages are *regressions* and *gratuitous*. You just need to do a cost/benefit look at it. For C++ though, supporting decades of very widespread use is doing to adjust the cost calculus of a change relative to D, of course. +1
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 18:42:20 UTC, H. S. Teoh wrote: [snip] Well, OK, there *have* been backward-incompatible changes in the C++ standard (I experienced some myself just these past 2 weeks while updating an old C++98 project of mine... which was also motivation for ditching C++ completely and migrating the whole codebase to D). But you're not going to see the sort of fundamental change that will fix some of the longstanding inherent design problems with C++, because that would mean alienating the majority of existing C++ projects out there. Even if the C++ committee went ahead with such a revision, it will surely not fly: nobody will want to implement it. The economic way of thinking is to consider whether the marginal benefit of a breaking change on all future code and whether that would exceed the marginal cost of a breaking change requiring old projects to be re-written. As most of us recognize, if the amount of old code that needs to be re-written is large and the cost of re-writing it is high, then it would overwhelm any changes of little benefit. Thus, I'm not sure this resistance to backward-incompatible changes is something all that specific to C++. I would guess that if D were as popular as C++, then the rational thing to do would be to be slow moving and be very careful about making costly breaking changes.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote: On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support. You're not the only one who thinks so - https://www.youtube.com/watch?v=ND-TuW0KIgg ;)
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 19:01:57 UTC, jmh530 wrote: The economic way of thinking is to consider whether the marginal benefit of a breaking change on all future code and whether that would exceed the marginal cost of a breaking change requiring old projects to be re-written. As most of us recognize, if the amount of old code that needs to be re-written is large and the cost of re-writing it is high, then it would overwhelm any changes of little benefit. Thus, I'm not sure this resistance to backward-incompatible changes is something all that specific to C++. I would guess that if D were as popular as C++, then the rational thing to do would be to be slow moving and be very careful about making costly breaking changes. "The economic way of thinking is to consider whether the marginal benefit of a breaking change on all future code would exceed the marginal cost of a breaking change requiring old projects to be re-written."
Re: C++ launched its community survey, too
On Tue, Feb 27, 2018 at 05:46:58PM +, Adam D. Ruppe via Digitalmars-d wrote: > On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote: > > And just about every new dmd release, people fume on this forum > > about regressions and gratuitous code breakages. > > Not all deprecations/code breakages are *regressions* and > *gratuitous*. > > You just need to do a cost/benefit look at it. For C++ though, > supporting decades of very widespread use is doing to adjust the cost > calculus of a change relative to D, of course. Of course. The amount of code breakage caused by a new release of dmd is surely less than the amount of code breakage that would be caused by an implementation of a new backward-incompatible C++ standard. That's why it's not going to happen. Well, OK, there *have* been backward-incompatible changes in the C++ standard (I experienced some myself just these past 2 weeks while updating an old C++98 project of mine... which was also motivation for ditching C++ completely and migrating the whole codebase to D). But you're not going to see the sort of fundamental change that will fix some of the longstanding inherent design problems with C++, because that would mean alienating the majority of existing C++ projects out there. Even if the C++ committee went ahead with such a revision, it will surely not fly: nobody will want to implement it. We saw a similar situation, though on a smaller scale, with the whole D1/D2 Tango vs. Phobos fiasco. Even today that scar still persists in outsiders' perception of D, despite all our efforts to bury that ugly past. T -- Winners never quit, quitters never win. But those who never quit AND never win are idiots.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote: On Tue, Feb 27, 2018 at 05:33:52PM +, 12345swordy via Digitalmars-d wrote: On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 > > Andrei I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support. And just about every new dmd release, people fume on this forum about regressions and gratuitous code breakages. T Which doesn't bother me at the slightest as there are reasonable trade offs for this.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote: And just about every new dmd release, people fume on this forum about regressions and gratuitous code breakages. Not all deprecations/code breakages are *regressions* and *gratuitous*. You just need to do a cost/benefit look at it. For C++ though, supporting decades of very widespread use is doing to adjust the cost calculus of a change relative to D, of course.
Re: C++ launched its community survey, too
On Tue, Feb 27, 2018 at 05:33:52PM +, 12345swordy via Digitalmars-d wrote: > On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: > > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 > > > > Andrei > > I have submitted, already. My major complaints boils down to the fact > that they refuse to deprecated features due to religious like > devotions to backwards compatibility support. And just about every new dmd release, people fume on this forum about regressions and gratuitous code breakages. T -- It only takes one twig to burn down a forest.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei ... and D is listed as an alternative.
C++ launched its community survey, too
https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei
