On Thursday, 14 July 2016 at 12:38:44 UTC, Kagamin wrote:
> What's the reason to implement what can't work even for you alone?

Huh?  I need to explain the purpose of building prototypes?

On Thursday, 14 July 2016 at 12:57:06 UTC, Ola Fosheim Grøstad wrote:
> Huh?  I need to explain the purpose of building prototypes?

You mean your process describes building prototypes only?

On Thursday, 14 July 2016 at 13:11:36 UTC, Kagamin wrote:
> On Thursday, 14 July 2016 at 12:57:06 UTC, Ola Fosheim Grøstad wrote:
>> Huh?  I need to explain the purpose of building prototypes?
>
> You mean your process describes building prototypes only?

Yes?

You cannot easily iterate over the design of the core language without creating a mess. You can iterate the design of libraries and to some extent syntactical sugar.

On Thursday, 14 July 2016 at 12:12:34 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 14 July 2016 at 11:38:59 UTC, Chris wrote:
>> On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote:
>>
>>> Software design is an iterative process because one can't sort everything at once.
>>
>> Not true. Ola can. :) (I just couldn't resist ...)
>
> I don't have time for a long rant on this...

Now, now. Where's your sense of humor?

> But if you are designing a truly new langauge  (and D isn't), then you create prototypes, then you build a framework that is suitable for evolutionary design, then you spec it, then you try to prove it sound, then you implement it then you trash it, and redesign it and write a new spec. Once you have a foundation where most things can be expressed in libraries you have a good base for iterating and handing it to the world.

Such a language will never see the light of day. Never. And given the constant changes in the IT business, you'll have to constantly trash and re-implement things. Nobody will be able to use the language in the real world, and it's using a language in the real world that shows you where a language's strengths and weaknesses are. I fear that some of the younger languages are taking that path. They will be ready for use by the time we'll have quark based processors or switched to telepathy altogether :-)

What makes a language attractive is that you can actually use it - here and now.

> Of course, the first thing you ought to do is to look at existing knowhow related to language design.

Which is what D did.

> That's a no-brainer.
>
> The alternative, to just iterate, is what gives you languages like Perl and Php.

... which, in fairness, where never meant to be carefully designed languages. Just convenient hacks for everyday tasks.

On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
> Such a language will never see the light of day.

Many such languages exist.

> What makes a language attractive is that you can actually use it - here and now.

What makes a language attractive is that it has system support and provides solutions that save time. That's what languages like TypeScript, Python, C#, Java, Swift and Go attractive.

I follow several languages that are very attractive, but that I cannot use because they don't have system support. I am also using languages that are less attractive than the alternatives for the same reasons.

>> Of course, the first thing you ought to do is to look at existing knowhow related to language design.
>
> Which is what D did.

No, it did not build on existing knowhow in language design theory, it was a fair reinterpretation of the C++ programming model with a tiny bit of Pythonesque extensions.

> ... which, in fairness, where never meant to be carefully designed languages. Just convenient hacks for everyday tasks.

Perl and Php started as small and convenient scripting languages, but they were predominantly evolved in an iterative fashion for decades after that, and aggregated a lot of issues related to exactly iterative evolution.

Both C++ and D shows clear signs of their abstraction mechanisms not fitting well with the core language. Too many mechanisms, not generic enough. And that happened because significant changes came late in the process, after deployment. You can say the same thing about Go and error-handling, it sticks out like a sore thumb.

On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
>> Such a language will never see the light of day.
>
> Many such languages exist.

Like? I mean languages that can be used in the real world. Certainly not Nim. It's not usable yet, it may change drastically any time.

>> What makes a language attractive is that you can actually use it - here and now.
>
> What makes a language attractive is that it has system support and provides solutions that save time. That's what languages like TypeScript, Python, C#, Java, Swift and Go attractive.

... and they're all usable as in I can write software with them right now.

> I follow several languages that are very attractive, but that I cannot use because they don't have system support. I am also using languages that are less attractive than the alternatives for the same reasons.
>
>>> Of course, the first thing you ought to do is to look at existing knowhow related to language design.
>>
>> Which is what D did.
>
> No, it did not build on existing knowhow in language design theory, it was a fair reinterpretation of the C++ programming model with a tiny bit of Pythonesque extensions.

Examples?

>> ... which, in fairness, where never meant to be carefully designed languages. Just convenient hacks for everyday tasks.
>
> Perl and Php started as small and convenient scripting languages, but they were predominantly evolved in an iterative fashion for decades after that, and aggregated a lot of issues related to exactly iterative evolution.

Yes, exactly, they were never meant to be big languages, just scripting tools. Same happened to Python in a way. It should never have left the lab and infected millions of people.

> Both C++ and D shows clear signs of their abstraction mechanisms not fitting well with the core language. Too many mechanisms, not generic enough. And that happened because significant changes came late in the process, after deployment. You can say the same thing about Go and error-handling, it sticks out like a sore thumb.

There's never _the_ perfect time to deploy a language, just like there's never _the_ perfect time to buy a computer, the moment you leave the shop it's out of date. You're dreaming of a language that only exists in cloud cuckoo land and it will get you nowhere. But of course, it's much easier to criticize the players on the pitch from your comfy armchair than to actually go onto the pitch and play yourself. No language ever gets it 100% right, because there are conflicting demands, and it's trivial to point out flaws that are bound to arise out of conflicting demands.

On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote:
> On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
>>> Such a language will never see the light of day.
>>
>> Many such languages exist.

Didn't I say that I don't have time for a long rant? :-)

Simula is a pretty good example. In it's first incarnation it was a simulation language, then it was reformulated as a general purpose language.

Dart is a pretty good example. The extensions have been primarily syntactical AFAIK.

TypeScript is a pretty good example of a language that is both stable and wildly expansive, as the core language is JavaScript and TypeScript is a layer above the core language. It is getting pretty good actually.

Go is a reasonable example (despite the error handling blunder). It has not changed much in terms of the core language and IIRC it is based on earlier languages by the same authors.

The JVM is also a decent example of a core language that is fairly stable. It as based on the StrongTalk VM.

I could go on for a while.

> ... and they're all usable as in I can write software with them right now.

Plenty of languages are usable, both Pony and Pure are usable, but they are not widely used. So it currently does not make much sense for me to use them as they most likely would cause more trouble than they would save me.

> Examples?

Slices etc.

> Yes, exactly, they were never meant to be big languages, just scripting tools. Same happened to Python in a way. It should never have left the lab and infected millions of people.

Python was informed by an educational language, but was designed to appeal to professionals, so I don't think it applies to Python as much.


> There's never _the_ perfect time to deploy a language, just like there's never _the_ perfect time to buy a computer, the moment you leave the shop it's out of date.

Huh, I don't understand the comparison?

Anyhow, I don't upgrade until I hit some unacceptable performance issues. I have a 4 year old computer and have no performance issues with it yet. :-P

There is very little advantage for me to have a faster computer than where the software is deployed.


> You're dreaming of a language that only exists in cloud cuckoo land and it will get you nowhere.

Nope. Such languages exits, but they are not _system level_ programming languages.


> But of course, it's much easier to criticize the players on the pitch from your comfy armchair than to actually go onto the pitch and play yourself.

What makes you think that I am not playing? What you actually are saying is that one should not make judgments about programming languages or try to influence their direction.

> No language ever gets it 100% right, because there are conflicting demands, and it's trivial to point out flaws that are bound to arise out of conflicting demands.

What conflicting demands do you suggest applies to D?

I don't see them, so I hope you can inform me.

On Thursday, 14 July 2016 at 14:46:50 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 14 July 2016 at 14:11:25 UTC, Chris wrote:
>> On Thursday, 14 July 2016 at 13:39:48 UTC, Ola Fosheim Grøstad wrote:
>>> On Thursday, 14 July 2016 at 13:26:06 UTC, Chris wrote:
>>>> Such a language will never see the light of day.
>>>
>>> Many such languages exist.
>
> Didn't I say that I don't have time for a long rant? :-)
>
> Simula is a pretty good example. In it's first incarnation it was a simulation language, then it was reformulated as a general purpose language.
>
> Dart is a pretty good example. The extensions have been primarily syntactical AFAIK.
>
> TypeScript is a pretty good example of a language that is both stable and wildly expansive, as the core language is JavaScript and TypeScript is a layer above the core language. It is getting pretty good actually.

> Go is a reasonable example (despite the error handling blunder). It has not changed much in terms of the core language and IIRC it is based on earlier languages by the same authors.
>
> The JVM is also a decent example of a core language that is fairly stable. It as based on the StrongTalk VM.
>
> I could go on for a while.

I'm not convinced.

Dart & TypeScript are scripting languages for the Internet and cannot be compared to D and C++.

Go is an Internet/server language, very bare bones and designed for Google's code mines.

All three languages above where designed by big companies with certain commercial goals in mind.

I don't know much about Simula (your patriotic choice :), but it's pure OOP and as such cannot be compared to D either (which is multi-paradigm).

>> ... and they're all usable as in I can write software with them right now.
>
> Plenty of languages are usable, both Pony and Pure are usable, but they are not widely used. So it currently does not make much sense for me to use them as they most likely would cause more trouble than they would save me.

But you don't use them for a reason.

>> Examples?
>
> Slices etc.
>
>> Yes, exactly, they were never meant to be big languages, just scripting tools. Same happened to Python in a way. It should never have left the lab and infected millions of people.
>
> Python was informed by an educational language, but was designed to appeal to professionals, so I don't think it applies to Python as much.

But only in a "lab environment".

>> There's never _the_ perfect time to deploy a language, just like there's never _the_ perfect time to buy a computer, the moment you leave the shop it's out of date.
>
> Huh, I don't understand the comparison?

I.e you have to deploy it at some point, it will never be perfect before you deploy it - just as you have to buy a computer at some point. If you keep waiting for the next generation, you'll never buy a computer (has happened!).

> Anyhow, I don't upgrade until I hit some unacceptable performance issues. I have a 4 year old computer and have no performance issues with it yet. :-P
>
> There is very little advantage for me to have a faster computer than where the software is deployed.
>
>
>> You're dreaming of a language that only exists in cloud cuckoo land and it will get you nowhere.
>
> Nope. Such languages exits, but they are not _system level_ programming languages.

So they don't exist, because the perfect language is also a system level language.

>> But of course, it's much easier to criticize the players on the pitch from your comfy armchair than to actually go onto the pitch and play yourself.
>
> What makes you think that I am not playing? What you actually are saying is that one should not make judgments about programming languages or try to influence their direction.

I don't know whether I should be sad or angry to see someone with your knowledge and experience wasting his time endlessly ranting about D (while praising every other language under the sun). You could make valuable hands-on contributions to D, but choose to be the Statler & Waldorf of the community - only without the fun factor. It's tiresome and doesn't get us anywhere.

>> No language ever gets it 100% right, because there are conflicting demands, and it's trivial to point out flaws that are bound to arise out of conflicting demands.
>
> What conflicting demands do you suggest applies to D?
>
> I don't see them, so I hope you can inform me.

E.g. low-level control vs. safety (cf. the discussion about casting away immutable)

On Thursday, 14 July 2016 at 15:28:45 UTC, Chris wrote:
> I don't know much about Simula (your patriotic choice :), but it's pure OOP and as such cannot be compared to D either (which is multi-paradigm).

It wasn't pure OOP, not sure what you mean by that either.

Not sure what you mean by calling D multi-paradigm.

> I.e you have to deploy it at some point, it will never be perfect before you deploy it - just as you have to buy a computer at some point. If you keep waiting for the next generation, you'll never buy a computer (has happened!).

I still don't get the comparison. I don't buy a new computer until I am running out of RAM. Speed is no longer a big issue for me, not even with C++ compilation speed.

> So they don't exist, because the perfect language is also a system level language.

Who has been talking about perfect? Geez, system programming languages are lightyears away from perfect. And they are way way behind high level ones.

> It's tiresome and doesn't get us anywhere.

Then don't argue the point without having a real argument against it.  If your motivation is entirely defensive then you don't really achieve anything.  If your motivation is informational, then it can achieve something. E.g. you could enlighten me.

I don't agree with you that knowledge doesn't get people anywhere. I think it does, it just takes a lot of time, depending on where they come from. I don't know much about Andrei, but Walter does move over time.

> E.g. low-level control vs. safety (cf. the discussion about casting away immutable)

I don't think that is a very good argument. All it tells me is that D's approach to safety isn't working and that you need to do this by static analysis over a much simpler core language.

On Tuesday, 12 July 2016 at 05:15:09 UTC, Shachar Shemesh wrote:
> C++ fully defines when it is okay to cast away constness, gives you aids so that you know that that's what you are doing, and nothing else, and gives you a method by which you can do it without a cast if the circumstances support it.
>
> D says any such cast is UB.
>
> Shachar

Yeah C++ defines how you can modify const data after saying you can never modify data from a const qualified access path. §7.1.​6.1/3[1]

I still haven't found someone who can explain how C++ can define the behavior of modifying a variable after casting away const. Sure it says that if the original object was mutable (not stored in ROM) than you can modify it, but that is true of D as well, but the language doesn't know the object is not stored in ROM so it can't tell you what it will do when you try to modify it, only you can.

1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf