xenon325:

> Doesn't http://wiki.dlang.org/DIP25 fix this ?

I think DIP25 is designed to be only a partial solution, it's not a complete memory safety story.

Bye,
bearophile

On Monday, 1 February 2016 at 07:13:32 UTC, xenon325 wrote:
> On Sunday, 31 January 2016 at 16:18:21 UTC, bearophile wrote:
>> And currently it's dead-easy to write unsafe code even in @safe D functions:
>>
>> int[] foo() pure @safe {
>>     int[2] a = [10, 20];
>>     auto b = a[];
>>     return b;
>> }
>> void main() {}
>
> Doesn't http://wiki.dlang.org/DIP25 fix this ?

No, it only works for `ref`.

On Saturday, 30 January 2016 at 20:48:01 UTC, bearophile wrote:

Hello bearophile,

> In Ada you can be productive if you use it for the purposes it was invented for, but most times you don't write that kind of code.
>
> I miss some Ada features, and I've missed the strictness of the Ada compiler that catches lot of bugs, but for most things today I prefer a more modern languages.

For quite some time I was looking at Ada as potential language to write multi-platform desktop application, but, being the big language which requires lot of time and energy to invest into learning/mastering it, I, somehow, feel reluctant seeing that there is practically no open-source community around Ada, no truly open-source compile -- what would happen if AdaCore would simply pull the plug since I do not believe there are enough
people capable to maintain/develop FSF GNAT, so I'd appreciate if you can write few words about Ada vs D hoping that the latter it one you are recommending for new (gui) projects?

I simply hope that D can provide me with most/all the features I'd expect from the language like Ada, but but even more modern features, more choices when it comes to developing GUI desktop app, more compiler choices, better tooling and, of course, much bigger community of open-source enthusiasts.


Sincerely,
Gour

gour:

> For quite some time I was looking at Ada as potential language to write multi-platform desktop application, but, being the big language which requires lot of time and energy to invest into learning/mastering it, I, somehow, feel reluctant seeing that there is practically no open-source community around Ada, no truly open-source compile -- what would happen if AdaCore would simply pull the plug since I do not believe there are enough
> people capable to maintain/develop FSF GNAT, so I'd appreciate if you can write few words about Ada vs D hoping that the latter it one you are recommending for new (gui) projects?
>
> I simply hope that D can provide me with most/all the features I'd expect from the language like Ada, but but even more modern features, more choices when it comes to developing GUI desktop app, more compiler choices, better tooling and, of course, much bigger community of open-source enthusiasts.

Ada language has several nice features worth stealing (I'd like both D and Rust to add constrained values, static preconditions, ranged subtypes, and annotations to control access to global variables), and if you're writing a train control system, a space probe/satellite, a military machine control, a hardware-constrained device that needs to be very reliable (like a medical machine working inside the body) then using Ada/SPARK could be reasonable.

But for an average multi-platform desktop application Ada is not a good idea. The main problem is not the language itself (that is very verbose, but that's not a show-stopper), but the tooling (very scarce, and very pricey, very few compilers, very few IDEs, etc), the community (small), and the libraries (not many). A sufficiently rich and sufficiently determined group of programmers could probably write a regular desktop application in Ada, but you're walking uphill for not enough reason. Sometimes worse is better because it's actually overall better.

There is a recent thread about Ada on Reddit, but unfortunately the best comment in that page has being deleted... :-)
https://www.reddit.com/r/programming/comments/49y7sc/11_myths_about_ada/

Bye,
bearophile

bearophile <bearophileHUGS@lycos.com> writes:


Hello bearophile,

and thank you very much for your insightful reply!

> But for an average multi-platform desktop application Ada is not a good idea. The main problem is not the language itself (that is very verbose, but that's not a show-stopper), but the tooling (very scarce, and very pricey, very few compilers, very few IDEs, etc), the community (small), and the libraries (not many). A sufficiently rich and sufficiently determined group of programmers could probably write a regular desktop application in Ada, but you're walking uphill for not enough reason. Sometimes worse is better because it's actually overall better.

Very useful info and I've arrived to the same conclusion.

> There is a recent thread about Ada on Reddit, but unfortunately the best comment in that page has being deleted... :-)

I was reading it several times and possibly noticed it, but now it does not matter since I consider myself as D user. ;)


Sincerely,
Gour

-- 
Bewildered by the modes of material nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge.

I work on a large multi-platform desktop shrink-wrap application.  It is a large application, with a code base of over 400,000 files.  The majority of which is C++, although there is some JavaScript in the mix in some of the corners of the UI.  The code base is about 30 years old... so you probably can imagine that the code has room for improvement.

For an existing project of that size, it makes no sense to try to throw it out and start over.  That would be recklessly ill-advised.

I was fantasizing:  if the app were to be written today, what would be suitable languages?

C++17, is a shoe in, since that corresponds to reality (if looked at through a carnival mirror, since the actual code is smeared across C++89 - C++98/03 - C++11/14 - C++17 like cities built on top the ruins of cities, and its turtles all the way down).

Since I'm a D fanboy, I put D on the list.  And I think these as well:  C#, F#, Go*, C, Lua (with some core functionality in C), Java, Groovy*, Scala*, Swift.  And maybe, at a stretch, Ada*, Clojure*, Kotlin*.

* I've no practical experience in these languages.

A friend of mine said I should add Rust* to the list.  I'm not familiar with Rust, so today is my "dive into Rust" day.  That's how I got here.  (Hi Walter!  Hi Bearophile!  I've been away for a long while.)

In my fantasy, the biggest challenge with a large multi-platform application is the tooling and support.

So some of the questions that are meta-language related are...

What are the IDEs like?  People want to have bother-free version control, enjoyable debugging experience, works on the target platforms, manage very large projects.  C++ has excellent support by Visual Studio, and very good support by Xcode.

What do the standard libraries offer?  C++ has a reasonably nice standard library.

What off-the-shelf libraries can be leveraged?  C++ has Boost, and many others.  A vibrant ecosystem.

Can the language "do the job"?  Part of "doing the job" is interoperating with the target platform.  In this fantasy case, Win32 with GDI/GDI+ (possibly .NET as a viable alternative), and Cocoa.  If that involves writing a C-API bridging layer from Language X to Host Platform, that is friction.  A fantasy project this size can absorb that kind of friction.

Can we hire 100+ programmers willing to use that language?

Those things are important, even though they are outside the domain of the language itself.  Toolchains.  IDEs.  Tool vendor stability.  Debugging.  Large project management.  Version control.  Suitability.  Community & ecosystem.  Human resources.

Since my love-hate relationship with C++ is well known, in my do-over fantasy world, I hope there is a better suited language.

And "make your own language" is not on the table.  I've read Aho's dragon book... I've tried that... it is VERY HARD to make your own general purpose language, and will consume 10+ years of your life.  Bjarne Stroustrup said, "If you do anything useful it will haunt you forever after, and if you have a major success you get decades of hard manual labor - meaning you have to work on the manual."  *hugs* to Walter & Andrei.

A cautious person would probably say "Use Swift on Mac, use C# or F# on .NET on Windows.  Write the code twice.  Boom, done."  That's been tried, turns out maintaining parity that way does not work out so well.  Case in point:  check out Office for Windows, and Office for Mac.

Step back...

Why am I sharing this on this forum?

I think these meta-language issues need to be thought about to help D gain more traction.  In addition to the core language issues that Andrei has already discussed in depth, and were mentioned again in this thread.

And I really love D.  It speaks to me.  It is the language I wish C++ was.  If I could have created a language, I would compare it against D as my gold standard.

I look at the history of RemObjects, and how they had a distributed object technology... but to support it they had to become a language vendor (of Oxygene, their version of Delphi, which is Apple/Wirth's Object Pascal), and then had to create their Elements compiler, and extend it to support multiple target platforms, and then extend it more to support multiple languages (Object Pascal, C#, Swift, Java) in their ecosystem.  And now they've jumped into the IDE game.  It is interesting to note that where they started and how they got to where they are is an interesting journey of necessity.

On 09/03/2017 11:26 AM, Eljay wrote:

> I put D on the list.

Been there, done that. Decision makers rationalize any other choice pretty easily:

- Python is 20 times slower: "We don't need speed."

- Python has a global lock: "We will start RESTful separate processes."

- Python's memory foot print is huge: "We will use less processes and use coroutines."

- Python does not provide static type-checking: "We will use pylint." People submit code that are broken: "They should use pylint."

- Similar other items where Python is inferior: "We'll deal with those when they become issues."

- Python is better on this one item: "Great! We choose Python."

> Hi Walter!

He's still hanging around... ;)

> Hi Bearophile!

I'm afraid bearophile has moved to greener pastures. I've run into bearophile on Reddit on Rust-related threads. He uses a different name there.

> Can we hire 100+ programmers willing to use that language?

D companies are known to interview in e.g. C++ but tell the candidates that they will be coding in D.

Ali

On Sunday, 3 September 2017 at 19:40:27 UTC, Ali Çehreli wrote:
>
> Decision makers rationalize any other choice pretty easily:
>

There is a useful method in the book "Thinking Fast and Slow" to try to be rational about a choice.

1/ Before looking the different solitions, make a list of relevant criterion for the problem at hand, and associate weights. For example I need to choose a language, let's choose Platform Support (weight 5), Familiarity (weight 4) and Speed (weight 2).

2/ Rate each alternatives alongside the choosen criterion.
For example D gets 3/5 in Platform Support, 4/4 in Familiarity and 1/2 in Speed.
That makes 3 + 5 + 1 = 9 points.

3/ And then _without further thinking_ choose the one with the most point.

In the book the example used was with hiring, but I suspect it applies to many type of decisions instead.

This method is supposed to outperform intuitive reasoning for hiring. In particular overcome some biases. However biases still find a way in the choice of criterions.

On Sunday, 3 September 2017 at 19:40:27 UTC, Ali Çehreli wrote:
> > Hi Bearophile!
>
> I'm afraid bearophile has moved to greener pastures. I've run into bearophile on Reddit on Rust-related threads. He uses a different name there.

*sigh*

On Sunday, 3 September 2017 at 19:40:27 UTC, Ali Çehreli wrote:
> Been there, done that. Decision makers rationalize any other choice pretty easily:

In my fantasy, I'd be the decision maker.  ;-)

In reality, along all my career, usually the decision as to the language used was made usually by (non-engineer) management, or sometimes by the principle developer by fiat.

And merits of the language was but one of many factors, but I think the foremost factor was whichever language the decision maker was familiar with, or enamored with.  (In your example, hence... PYTHON!  I actually like Python, but I've only used it for scripting purposes.  Less than 1 kLOC.)

Often times in the projects I have been on, that decision maker has long since moved on to different projects or left the company.

And the language decision is nigh impossible to change.  Except...

On my current project, the original language was Object Pascal.  At some point in the early 90s, the Object Pascal code was mechanically transformed into C++89 code.

Even though that was a very long time ago, there are still Object Pascal idioms present in the code.  Which are not idiomatic C++.

Semi-ironically, Object Pascal is still around, and has it's own following.  Although now referred to as Delphi or Oxygene or Freescal.  They're all Object Pascal.

Regarding the project language choice, the one thing I have found consistent from all my projects is:  picking a locked-down proprietary language is invariably a bad decision.  Languages like PowerBuilder Powerscript or Forte Tool or Meditech Magic or PickOS PickBASIC.

My apologies to devs that enjoy Powerscript or Tool or Magic or PickBASIC.  I'm not saying that those languages cannot be enjoyable.  The nature of proprietary languages make the projects tied to them at their mercy.

Whereas with D, if I don't like dmd, I can use gcd, or ldc.  Or if D doesn't support my favorite platform -- obviously Amiga OS, the one best OS ever made -- I could in theory do the work to leverage D as a front end to my toolchain.

Hmmm, maybe that doesn't make sense.  Sorry if I didn't express myself clearly.