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

On Wed, Feb 28, 2018 at 06:45:29PM +0000, 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 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.


> 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.

D to me is like the nexus of all the best things from the languages I worked with: it has the conciseness and expressive power of Perl and is suitable for one-off, shell-script-like utilities, yet with the safety of static typing and the sanity of clean syntax.  It also has a GC, one of the non-sucky aspects of Java, which saves it from being C hell in large projects where 90% of your mental energy is spent worrying about memory management instead of focusing on the problem domain, or C++ hell with a pathological syntax that must be parsed before it can be lexed. It has templates with a sane syntax, unlike C++, but goes beyond that with static introspection, CTFE, and mixins like you said.

D also empowers the user to build their own functionality where the built-ins aren't good enough. This is actually a huge point for me. Recently I started a thread complaining about the new int promotion deprecation rules, and not long after, somebody described an almost beautiful workaround that uses operator overloading and `alias this` to basically completely bypass the casts.  The fact that such a thing is *possible* in D speaks volumes.

If this were in, say Java, I would have basically been told, "what you want isn't supported. Suck it up, or go to another language". 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.  Language built-ins not good enough?  No problem: we give you the tools to write your own.

The concept of empowering the user (rather than shoehorn everything into a preconceived cage) is a powerful one, that would-be programming language designers would do well to take heed to.


> 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


T

-- 
By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth

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

On Wed, Feb 28, 2018 at 09:46:49PM +0000, 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 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

'cos I want one of my own. :-D


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."

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.

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.

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.

On Wed, Mar 07, 2018 at 03:52:19PM +0000, 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??

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...

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 ;)