February 02
On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder wrote:
> On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
>> On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:
>>> On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:
>>>> On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:
>>>>>
>>>>> Also look forward to the future when you don't need to install Visual Studio to get the linker as it will ship with DMD (If it doesn't already? It's been a while since I've checked.)
>>>>
>>>> It is. But there is another problem. D is a SYSTEM programming language, not just some productivity language. It means there is still dependency on the system libs! Heck, even Rust given up with jemalloc in favor of system allocator by default, if this says something...
>>>> Of course the problem with packaging the libs with compiler installation can be solved by using same approach MinGW did, like people say, or even using the MinGW libs if it is possible.
>>>
>>> Mingw libs and headers are also included in recent dmd. Except of rare cases you may not need anymore to install vs or build tools.
>>>
>>> Kind regards
>>> Andre
>>
>> I don't get people complaining about and they are usually misinformed as well. You can install VC++ for 1.5 GB using the Build Tool install. Of that 1.5 GB 1 GB are library files and most of that is for the static libraries for the runtime. The last time this came up someone was developing on a cheap tablet or something with 16 GB of space that isn't expandable.
>
> I think that the reason why people complain is that not everybody thinks in the same way as you.

Never said otherwise, I can have my own opinion and people can have theirs and I can have the opinion that their opinions are silly.

> Seriously, the last time I had to install D on my freshly reinstalled Windows partition, I almost gave up before finishing the installation procedure, because it once seemed I was doomed to unavoidingly install the X GB of Visual Studio environment (or its build tools, same problem) just to install a small D compiler needed to build my tiny single-file tools (Basil, Pendown, etc) on Windows.

Well at least you said "X GB" instead of just fabricating an incorrect number like everyone else :). And how did you get that small compiler to work in the first place? I guess you've never had to install your Windows operating system. I can only imagine you complaining about having to install a 20 GB operating system just to be able to install a small D compiler to build a tiny single-file tool. The D compiler can be small and your tool and be tiny because the complexity of what is actually going on is hidden from you, you don't have to worry about it. But alas people still complain with horrible metaphors.

> By luck, I tried the Mingw option, which worked and this saved my day, but I think you have no idea how unlikely people will click on this Mingw option, and how this little install menu design can turn off people from D if they were just trying to experiment it as a Python or Ruby alternative, because **not everyone** is willing to start that LONG and HUGE Visual Studio thing just to try the finally-not-so-swift D compiler which seems to need it.

Lol, I can't help but laugh "long" and "huge" visual studio thing. As I sit here downloading a 40 GB file, you have no idea the meaning of long or huge. What you need are the VC++ runtime libraries and the linker. Visual Studio is an IDE, they are two different projects and you don't need the IDE to compile and link programs on Windows.

There's your problem, you are comparing D, a language that compiles to native machine code with interpreted languages that are specifically designed to be overly simplistic and go to great lengths to hide operating system and architecture specific problems. Hardly a fair comparison and D will probably never be as simple to use as those, as you don't need any development system libraries to use those languages. That's the benefit of an interpreted language.

> IMO, the two most urgent things you should improve to avoid immediately pushing people away from their curiosity about D is :
>
> 1/ make D's web site landing page show D advantages from the user point of view : why D would be better than Python etc to make file processing scripts, GUI applications, web servers, etc

Have you even been on the front page? Literally the first example I was met with:

https://dlang.org/

"Start a minimal web server"

#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
    import vibe.d;
    listenHTTP(":8080", (req, res) {
        res.writeBody("Hello, World: " ~ req.path);
    });
    runApplication();
}


> 2/ make the installation process quick and easy : you download a <50MB installer executable, click install, and in less than 2 minutes you are ready to go.
>
> For 1, you should really consider putting this text on the landing page :
>
> "D is a powerful and expressive language which compiles directly to efficient, native machine code.
>
> It is the culmination of decades of experience implementing compilers for many diverse languages and has a unique set of features:
>
>     high level constructs for great modeling power
>     high performance, compiled language
>     static typing
>     direct interface to the operating system API's and hardware
>     blazingly fast compile-times
>     memory-safe subset (SafeD)
>     maintainable, easy to understand code
>     gradual learning curve (C-like syntax, similar to Java and others)
>     compatible with C application binary interface
>     limited compatibility with C++ application binary interface
>     multi-paradigm (imperative, structured, object oriented, generic, functional programming purity, and even assembly)
>     built-in error detection (contracts, unittests)"
>
> Followed by THREE examples :
>
> 1. a very simple one which shows D basic syntax "a la JavaScript", by showing how to declare an string array, initialize it with [ "apple", "banana", "orange" ], how to iterate on them, print them, etc
>
> 2. a small "hello world" web server example (the one using vibe.d you see IF you select that example)
>
> 3. a small GUI example (opening a window with a menu, two radio buttons and a scroll view, using dlangui)
>
> All directly visible, with a small text explaining how it is easy to :
> 1. make JavaScript/Python/Ruby like file scripting
> 2. easily develop web servers with vibe.d
> 3. easily develop multiplatform (Win/Mac/Linux) desktop with dlangui (which rocks btw)
>
> And for the second point, about the installer, put the quick & easy installation option (Mingw) above and selected by default.
>
> Or completely ignore those advices, and be happy what you think is already perfect for D's newcomers :)

It's not really my decision and I never said anything was good about what D is already doing. It needs to chuck that optlink linker garbage into the bin where it belongs.


February 02
On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder wrote:
> On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
>> [...]
>
> I think that the reason why people complain is that not everybody thinks in the same way as you.
>
> [...]

DMD64 could be released for windows now, with -m64 the default just like under linux or osx. This would work. Actually people still download the 32 bit compiler after all so this is not so crazy that it defaults to -m32
February 03
On Saturday, 2 February 2019 at 20:50:58 UTC, Basile B. wrote:
> On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder wrote:
>> On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
>>> [...]
>>
>> I think that the reason why people complain is that not everybody thinks in the same way as you.
>>
>> [...]
>
> DMD64 could be released for windows now, with -m64 the default just like under linux or osx. This would work. Actually people still download the 32 bit compiler after all so this is not so crazy that it defaults to -m32

For DMD to be a truly multi-platform language (Windows/Linux/MacOS), consistency across platforms should always be a must, never an option.

Using -m32 by default on Windows, while -m64 is the default on Linux and MacOSX, needlessly breaks that cross-platform promise, and thus creates compilation problems that could easily have been avoided by using a consistent behavior across platforms.

And I've experienced this problem first hand...

D is clearly what I call an "almost" cross-platform language.

It could be close to perfection on that aspect, but unfortunately a few poor decisions here and there regularly breaks its cross-platform behavior in a very annoying way.




February 03
On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
> Using -m32 by default on Windows, while -m64 is the default on Linux and MacOSX, needlessly breaks that cross-platform promise, and thus creates compilation problems that could easily have been avoided by using a consistent behavior across platforms.

Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest.

Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.
February 03
On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:

> You can also set the default architecture to x86_64 for all dub projects as described here
>
> https://dub.pm/settings.html

Is this a typo:

%APPDATA%\dub\settings.json

Shouldn't it be:

%APPDATA%\roaming\dub\settings.json

or:

%APPDATA%\local\dub\settings.json

I've never seen any software create it's folder at the top level of %APPDATA%.
February 03
On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:

> You can also set the default architecture to x86_64 for all dub projects as described here
>
> https://dub.pm/settings.html

But OTOH, creating a settings.json file in c:\ProgramData with the following contents:

{
	"defaultArchitecture": "x86_64",
	"defaultCompiler": "ldc"
}

has solved my dub linking problem. Perhaps creating this file could become part of the Windows install process, or at least, an option during installation.
February 03
On Sunday, 3 February 2019 at 10:20:41 UTC, Ron Tarrant wrote:
> On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:
>
>> You can also set the default architecture to x86_64 for all dub projects as described here
>>
>> https://dub.pm/settings.html
>
> Is this a typo:
>
> %APPDATA%\dub\settings.json
>
> Shouldn't it be:
>
> %APPDATA%\roaming\dub\settings.json
>
> or:
>
> %APPDATA%\local\dub\settings.json
>
> I've never seen any software create it's folder at the top level of %APPDATA%.

The environment variable APPDATA points to the roaming folder.

Kind regards
Andre
February 03
On Sunday, 3 February 2019 at 09:23:59 UTC, rikki cattermole wrote:
> On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
>> Using -m32 by default on Windows, while -m64 is the default on Linux and MacOSX, needlessly breaks that cross-platform promise, and thus creates compilation problems that could easily have been avoided by using a consistent behavior across platforms.
>
> Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest.
>
> Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.

I agree, but IMO this is one more reason to use 64 bit as the new Windows default.

There will always be old PCs running on 32 bit OS, but many statistics corroborate the fact that most Windows users have now switched to the 64 bit version.

That's especially true for PC gamers, if you simply look at the Steam statistics :

https://store.steampowered.com/hwsurvey/
(click on OS Version)

February 03
On Sunday, 3 February 2019 at 11:30:34 UTC, Ecstatic Coder wrote:
> On Sunday, 3 February 2019 at 09:23:59 UTC, rikki cattermole wrote:
>> On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
>>> Using -m32 by default on Windows, while -m64 is the default on Linux and MacOSX, needlessly breaks that cross-platform promise, and thus creates compilation problems that could easily have been avoided by using a consistent behavior across platforms.
>>
>> Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest.
>>
>> Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.
>
> I agree, but IMO this is one more reason to use 64 bit as the new Windows default.
>
> There will always be old PCs running on 32 bit OS, but many statistics corroborate the fact that most Windows users have now switched to the 64 bit version.
>
> That's especially true for PC gamers, if you simply look at the Steam statistics :
>
> https://store.steampowered.com/hwsurvey/
> (click on OS Version)

As far as I understand, it is technically possible to provide a 64 bit dmd which defaults to x86_64 for windows. The release pipeline needs to adapted. To get this right, this will take several days of work (assumption).

Kind regards
Andre
February 03
On Sunday, 3 February 2019 at 10:49:59 UTC, Andre Pany wrote:

> The environment variable APPDATA points to the roaming folder.

I didn't know that. Thank you, Andre.
1 2 3 4 5 6