On Sunday, 29 March 2020 at 13:34:44 UTC, Steven Schveighoffer wrote:
> On 3/28/20 1:09 PM, Denis Feklushkin wrote:
>> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>>> There have been a lot of this pattern happening:
>>>
>>> 1. We need to add feature X, to fix problem Y.
>>> 2. This will break ALL CODE IN EXISTENCE
>>> 3. OK, cancel the fix, we'll just live with it.
>>>
>>> Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.
>>>
>>> Some issues I can think of:
>> 
>> I have long wanted to offer but there was no suitable place. I would like to propose to trivial rename standart type names by this way:
>> 
>> int -> int32
>> ulong -> uint64
>> float -> float32
>> double -> float64
>> byte -> octet
>
> I would say no, for 2 reasons. One, this is basically renaming without benefit. All those types are well defined, and there is no problem with sizing. Two, you can already do this with aliases if this is what you wish for.

What about "real"? It is not defined. On x86 it means the old deprecated 80-bit float (that nobody should use). And on ARM it means 128-bit float. The worse part is, at least last I checked, Phobos only implements some functions only for real.

On Sun, 2020-03-29 at 12:00 +0000, Paulo Pinto via Digitalmars-d wrote: […]
> 
> The times that Groovy made any headlines in German Java conferences or local JUGs are long gone, I wonder where Groovy is being used above a single digit usage market share on the Java platform.

As with TIOBE Index, headlines are meaningless regarding traction.

Groovy is not a programming language with massive traction, but it has quite a lot, mostly it just happens quietly. Gradle is one use of Groovy, but so is Grails, and now Micronaut. Indeed many just use Groovy directly. See the list of users on https://groovy-lang.org/index.html

> I was quite surprised that Groovy actually managed to release the 3.0 version.

You weren't tracking Groovy seriously then. Groovy 3.0 was always going to happen. Now if you challege whether Groovy 4.0 will happen that is a wholly different situation.

> It is not my opinion, rather what any Java market analysis report will easily confirm.

That just confirms a Java bias of Java journalists.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>Is it time for D 3.0?

I am a dlang user and a long time community observer - as such i would be pleased to see D3 with proper implemented "lessons learned", instead of doing the
> 3. OK, cancel the fix, we'll just live with it.
..which is what all software developer know/has seen, knowing about its nasty consequences. IMO there is no alternative to D3 - either D3 or become the PHP of the system programming languages.

On 3/29/20 10:01 AM, Arine wrote:
> On Sunday, 29 March 2020 at 13:34:44 UTC, Steven Schveighoffer wrote:
>> I would say no, for 2 reasons. One, this is basically renaming without benefit. All those types are well defined, and there is no problem with sizing. Two, you can already do this with aliases if this is what you wish for.
> 
> What about "real"? It is not defined. On x86 it means the old deprecated 80-bit float (that nobody should use). And on ARM it means 128-bit float. The worse part is, at least last I checked, Phobos only implements some functions only for real.
> 
> 

I think real is an exception, and possibly available for migration to things like real80 or real128 and aliasing real to one of them. Simply because all floating points in D are implicitly convertable between them.

-Steve

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. The safe by default debate
> 2. pure by default
> 3. nothrow by default
> 4. String interpolation DIP
> 5. auto-decoding
> 6. range.save
> 7. virtual by default
> 8. ProtoObject
>

Let's go back to the original question.

If we going to go to D3, then we need a proper project plan so that people know what they are supposed to implement. That means that someone needs to decide what to implement. As the D community works today with DIPs which will yield a dozen different opinions, it will be impossible to even plan D3. It will take several years before even implementation will begin. In this case the outside opinions must be limited if you going to decide anything at all.

I can see in front of me that D3 will be a huge project if we also going to clean up the libraries, druntime, proper pay as you go and so on.

First question is, do we have the resources for such a project?
Do we have a good management model for such project?
Who will decide what to include in the project?
Who will write down everything that needs to be done?

On Sunday, 29 March 2020 at 18:24:33 UTC, IGotD- wrote:
> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>> There have been a lot of this pattern happening:
>>
>> 1. The safe by default debate
>> 2. pure by default
>> 3. nothrow by default
>> 4. String interpolation DIP
>> 5. auto-decoding
>> 6. range.save
>> 7. virtual by default
>> 8. ProtoObject
>>
>
> Let's go back to the original question.
>
> If we going to go to D3, then we need a proper project plan so that people know what they are supposed to implement. That means that someone needs to decide what to implement. As the D community works today with DIPs which will yield a dozen different opinions, it will be impossible to even plan D3. It will take several years before even implementation will begin. In this case the outside opinions must be limited if you going to decide anything at all.
>
> I can see in front of me that D3 will be a huge project if we also going to clean up the libraries, druntime, proper pay as you go and so on.
>
> First question is, do we have the resources for such a project?
> Do we have a good management model for such project?
> Who will decide what to include in the project?
> Who will write down everything that needs to be done?

The problem is not whether or not we need to come up with a list of things to implement. The problem is, who will implement it ? And the answer has always been, those who care, those who will use it, or Walter.

We have a lot of features in the pipeline. Just do `dmd -preview=?`.  But they are unfinished, and aren't getting activated. We have to get those through the door, first.

On 3/29/2020 2:41 AM, Russel Winder wrote:
> It is always a delicate balance of keeping a language vibrant and alive
> in the minds of those *not* already committed to it, and seeming a
> niche language dead to the mainstream.
> 
> Switching D to a proper semantic versioning system would, in my view,
> help keep D in the former category, and out of the latter one. If we
> get to D 2.999, I would suggest D has moved into to latter category.

D's development path simply doesn't fit into the semantic versioning system. It's one of continuous change, not long periods of stability punctuated by wrenching change.


> Yes I know Torvalds did the major version hack on Linux simply to avoid
> seeming stuck and stalled, not for any actual technical reasons, but it
> worked.

I'm not familiar with that, but it makes sense.

On Sunday, 29 March 2020 at 12:00:20 UTC, Paulo Pinto wrote:
> On Sunday, 29 March 2020 at 09:47:15 UTC, Russel Winder wrote:
>> On Sat, 2020-03-28 at 11:01 +0000, Paulo Pinto via Digitalmars-d wrote:
>>> […]
>>> 
>>> Groovy isn't properly a good exemple.
>>
>> I see no reason why it isn't, it is an evolving language following the semantc versioning model.
>>
>>> If it wasn't for Gradle and its use in Android, it would be long gone and forgotten.
>>
>> In you opinion. The evidence I see is that Groovy has more traction in Java sites than is immediately apparent. Clearly Kotlin is challenging the role of Groovy in many respects, but Groovy is still used by many orgsanisation fro dynamic programing. The analogy is where C++ codebases use Python or Lua.
>>
>>> And even there, there is a big pressure to replace it with Kotlin, in what regards Android build infrastructure.
>>
>> Kotlin rather than Groovy is the language of choice on the Android platform these days certainly, but there are a lot of JVM installation out there using Java, Kotlin, and Groovy – not to mention Scala, Clojure, etc. – all going along happily. Yes there are a lot of those installations that will only use Java.
>>
>>> So is the fate of any guest language until the main platform language catches up.
>>
>> Java can never catch up with Groovy, whereas is can catch up with Kotlin. Kotlin is the guest language you are talking of for most Java installation, not Groovy. Statis Groovy may be a dead thing, but Dynamic Groovy is far from dead.
>
> The times that Groovy made any headlines in German Java conferences or local JUGs are long gone, I wonder where Groovy is being used above a single digit usage market share on the Java platform.

IBM Security, one of the largest cybersecurity companies in the world. The most widely used enterprise-level SIEM (by quite a wide margin) uses Groovy extensively for its testing framework.

> I was quite surprised that Groovy actually managed to release the 3.0 version.
>
> It is not my opinion, rather what any Java market analysis report will easily confirm.

On Saturday, 28 March 2020 at 23:00:34 UTC, krzaq wrote:
> I'm notrea disputing that. I'm saying that D standarized the wrong names. Rust hit the bullseye, while C/C++ is somewhere in the middle. And the alias argument is IMO weak because of it being non-standard.

The first letters of a word count more for

To me the whole i8/u8/i16/u16/i32/u32 is just unreadable,

"float" and "double" are staple names in the native community for 32-bit and 64-bit floating point numbers.

Those names are used in C / C++ / OpenCL / CUDA etc.
C and C++ is the dominant native programming culture, why change name and syntax people already know?
The only other acceptable name would perhaps be "single" instead of "float" (like Pascal did). "float" being 64-bit in ocaml gets is particularly wrong. Sorry but there is very little to win by tryng to be clever with different names.

Also regarding integers.
We write "int" because it contains the information "this is an integer", that it is 32-bit is rarely _that_ interesting for perceiving the intent.

The new names are obvious Rust mistakes :) it solves no problem and they also departed from C integer promotion rules... and end up with casts everywhere, which is another level of unsafety.

On Sun, Mar 29, 2020 at 07:01:18PM +0000, Mathias Lang via Digitalmars-d wrote:
> On Sunday, 29 March 2020 at 18:24:33 UTC, IGotD- wrote:
[...]
> > If we going to go to D3, then we need a proper project plan so that people know what they are supposed to implement. That means that someone needs to decide what to implement.
[...]
> The problem is not whether or not we need to come up with a list of things to implement. The problem is, who will implement it ? And the answer has always been, those who care, those who will use it, or Walter.
[...]

Yes, herein lies the rub.  There is no shortage of good ideas and opinions in this forum, but when it comes time to actually write the code and make it work, the enthusiasm seems to evaporate and the manpower is nowhere to be found.  Grand plans have been drawn up in the past, and countless lists of tasks that need to be done.  None of that has made much of a difference.  The difference has mostly been made by a number of silent contributors who don't speak up much, but do most of the real work behind the scenes and make things tick.

This is the curse of the volunteer project: nobody gets paid so when they're told what to do rather than making their own choice about what to do, they just walk away.  We can invent grand plans all we like, but until there's somebody passionate enough to actually put in the hard work to implement said grand plan, nothing will actually happen.

Instead, what tends to get done is the itch that somebody wants to scratch, that doesn't always match what others want.


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N