www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What Makes A Programming Language Good

reply Walter Bright <newshound2 digitalmars.com> writes:
http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
Jan 17 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
So, why do users still get a scary linker error when they try to compile a program with more than 1 module? IMO, sticking to the C-ism of "one object file at a time" and dependency on external build tools / makefiles is the biggest mistake DMD did in this regard. Practically everyone to whom I recommended to try D hit this obstacle. rdmd is nice but I see no reason why this shouldn't be in the compiler. Think of the time wasted by build tool authors (bud, rebuild, xfbuild and others, and now rdmd), which could have been put to better use if this were handled by the compiler, who could do it much easier (until relatively recently it was very hard to track dependencies correctly). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-progra
ming-language-good/ 
So, why do users still get a scary linker error when they try to compile a program with more than 1 module?
What is that message?
 IMO, sticking to the C-ism of "one object file at a time" and dependency 
 on external build tools / makefiles is the biggest mistake DMD did in 
 this regard. Practically everyone to whom I recommended to try D hit 
 this obstacle. rdmd is nice but I see no reason why this shouldn't be in 
 the compiler. Think of the time wasted by build tool authors (bud, 
 rebuild, xfbuild and others, and now rdmd), which could have been put to 
 better use if this were handled by the compiler, who could do it much 
 easier (until relatively recently it was very hard to track dependencies 
 correctly).
dmd can build entire programs with one command: dmd file1.d file2.d file3.d ...etc...
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 11:05:34 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright  
 <newshound2 digitalmars.com> wrote:

 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
So, why do users still get a scary linker error when they try to compile a program with more than 1 module?
What is that message?
C:\Temp\D\Build> dmd test1.d OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html test1.obj(test1) Error 42: Symbol Undefined _D5test21fFZv --- errorlevel 1 1) The error message is very technical: a) does not indicate what exactly is wrong (module not passed to linker, not that the linker knows that) b) does not give any indication of what the user has to do to fix it 2) OPTLINK doesn't demangle D mangled names, when it could, and it would improve the readability of its error messages considerably. (I know not all mangled names are demangleable, but it'd be a great improvement regardless)
 dmd can build entire programs with one command:

     dmd file1.d file2.d file3.d ...etc...
That doesn't scale anywhere. What if you want to use a 3rd-party library with a few dozen modules? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 11:11:01 +0200, Vladimir Panteleev  
<vladimir thecybershadow.net> wrote:

   a) does not indicate what exactly is wrong (module not passed to  
 linker, not that the linker knows that)
By the way, disregarding extern(C) declarations et cetera, the compiler has the ability to detect when such linker errors will appear and take appropriate measures (e.g. suggest using the -c flag, passing the appropriate .d or .obj file on its command line, or using a build tool). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
prev sibling next sibling parent reply Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:
On 01/18/11 03:11, Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 11:05:34 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:
 
 Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
So, why do users still get a scary linker error when they try to compile a program with more than 1 module?
What is that message?
C:\Temp\D\Build> dmd test1.d OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html test1.obj(test1) Error 42: Symbol Undefined _D5test21fFZv --- errorlevel 1 1) The error message is very technical: a) does not indicate what exactly is wrong (module not passed to linker, not that the linker knows that) b) does not give any indication of what the user has to do to fix it 2) OPTLINK doesn't demangle D mangled names, when it could, and it would improve the readability of its error messages considerably. (I know not all mangled names are demangleable, but it'd be a great improvement regardless)
 dmd can build entire programs with one command:

     dmd file1.d file2.d file3.d ...etc...
That doesn't scale anywhere. What if you want to use a 3rd-party library with a few dozen modules?
Then I would expect the library vendor provides either a pre-compiled binary library, or the means to readily generate same -- whether that means a Makefile, a script, or what have you. At that time, there is no need to provide DMD with anything -- unless you are one-lining it a la 'dmd file1 file2 file3 third_party_stuff.lib'. Forgive me if I misunderstand, but I really don't want a language/compiler that goes too far into hand-holding. Let me screw up if I want to. -- Chris N-S
Jan 18 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 12:07:21 +0200, Christopher Nicholson-Sauls  
<ibisbasenji gmail.com> wrote:

 That doesn't scale anywhere. What if you want to use a 3rd-party library
 with a few dozen modules?
Then I would expect the library vendor provides either a pre-compiled binary library, or the means to readily generate same -- whether that means a Makefile, a script, or what have you.
Why? You're saying that both the user and every library maintainer must do that additional work. Why should the user care that they have to deal with pre-compiled libraries in general? The only thing the user should bother with is the package name for the library. D can take care of everything else: check out the library sources from version control, build a library and generate .di files. The .di files can include pragmas which specify to link to that library. There are no technical reasons against this. In fact, DSSS already does most of this. AFAIK Ruby takes care of everything else, even when the library isn't installed on your system.
 Forgive me if I misunderstand, but I really don't want a
 language/compiler that goes too far into hand-holding.  Let me screw up
 if I want to.
So, you want D to force people to do more work, out of no practical reason? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Vladimir Panteleev:

 So, you want D to force people to do more work, out of no practical reason?
When you develop a large system, the nice hand holding that works with small systems often stops working (because the whole language ecosystem is often not much designed for hierarchical decomposition of problems). In this situation you are often on your own, and often the automatic features work against you because their work and actions are often opaque. So those programmer develop a mistrust toward a compiler+tools that hold too much your hand. A related problem is visible in old automatic pilot systems. They are very useful, but when their operative limits are reached (because some emergency has pushed the plane state outside them), they suddenly stop working, and leave the human pilots in bad waters because the humans don't have a lot of time to awake from their sleepy state and understand the situation well enough to face the problems. So those old automatic pilot systems were actively dangerous (new automatic pilot systems have found ways to reduce such problems). To solve the situation, the future automatic D tools need to work in a very transparent way, giving all the information in a easy to use and understand way, showing all they do in a very clear way. So when they fail or when they stop being enough, the programmer doesn't need to work three times harder to solve the problems manually. Bye, bearophile
Jan 18 2011
parent el muchacho <nicolas.janin gmail.com> writes:
Le 18/01/2011 11:45, bearophile a écrit :
 Vladimir Panteleev:
 
 So, you want D to force people to do more work, out of no practical reason?
When you develop a large system, the nice hand holding that works with small systems often stops working (because the whole language ecosystem is often not much designed for hierarchical decomposition of problems). In this situation you are often on your own, and often the automatic features work against you because their work and actions are often opaque. So those programmer develop a mistrust toward a compiler+tools that hold too much your hand. A related problem is visible in old automatic pilot systems. They are very useful, but when their operative limits are reached (because some emergency has pushed the plane state outside them), they suddenly stop working, and leave the human pilots in bad waters because the humans don't have a lot of time to awake from their sleepy state and understand the situation well enough to face the problems. So those old automatic pilot systems were actively dangerous (new automatic pilot systems have found ways to reduce such problems). To solve the situation, the future automatic D tools need to work in a very transparent way, giving all the information in a easy to use and understand way, showing all they do in a very clear way. So when they fail or when they stop being enough, the programmer doesn't need to work three times harder to solve the problems manually. Bye, bearophile
My 2 cents: There is no need for transparency in the compilation and linking processes if things are well defined. Armies of developers in Java shops that include banks trust their IDE to do almost everything, be it eclipse, Netbeans or IntelliJ, sometimes the 3 at the same time in the same team. This is the case in my team, where some developers use IntelliJ while others use eclipse, out of the same source code repository. Both IDEs can compile and debug the software and the final build is made by a big ant file which can check out, generate code, build with javac and run tests. So there are 3 build systems in parallel. One task of the ant file is run once by each developer to generate the code and then the build is entirely handled by the build system, is the compiler of the IDE. There is no need to specify any dependency in the ant file. Of course, the IDE's compiler needs to be told where to find the library dependencies because we don't use Maven yet, but apart from taht, there is no need to specify anything else. This is in contrast with the horrible makefiles that still cripple most C++ projects, and still prevent C++ shops to benefit from efficient IDEs. Having worked both on large C++ systems and Java systems, my only conclusion is: make is a huge waste of time.
Jan 29 2011
prev sibling parent reply Trass3r <un known.com> writes:
 Then I would expect the library vendor provides either a pre-compiled
 binary library
As soon as you provide templates in your library this isn't sufficient anymore.
 or the means to readily generate same -- whether that
 means a Makefile, a script, or what have you.
We must avoid having the same disastrous situation like C/C++ where everyone uses a different system, CMake, make, scons, blabla. Makefiles aren't portable (imo stuff like msys is no solution, it's a hack) and especially for small or medium-sized projects it's often enough to compile a single main file and all of its dependencies. We really need a standard, portable way to compile D projects, be it implemented in the compiler or in some tool everyone uses. dsss was kind of promising but as you know it's dead.
Jan 18 2011
next sibling parent Gour <gour atmarama.net> writes:
On Tue, 18 Jan 2011 10:32:53 +0000 (UTC)
Trass3r <un known.com> wrote:

 We must avoid having the same disastrous situation like C/C++ where
 everyone uses a different system, CMake, make, scons, blabla.
I agree (planning not to use blabla build system, but waf). Otoh, I hope D2 will also be able to avoid things like: http://cdsmith.wordpress.com/2011/01/16/haskells-own-dll-hell/ However, for now I'm more concerned to see 64bit DMD, complete QtD (or some other workable GUI bindings), some database bindings etc. first... Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 18 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/11 4:32 AM, Trass3r wrote:
 Then I would expect the library vendor provides either a pre-compiled
 binary library
As soon as you provide templates in your library this isn't sufficient anymore.
 or the means to readily generate same -- whether that
 means a Makefile, a script, or what have you.
We must avoid having the same disastrous situation like C/C++ where everyone uses a different system, CMake, make, scons, blabla. Makefiles aren't portable (imo stuff like msys is no solution, it's a hack) and especially for small or medium-sized projects it's often enough to compile a single main file and all of its dependencies. We really need a standard, portable way to compile D projects, be it implemented in the compiler or in some tool everyone uses. dsss was kind of promising but as you know it's dead.
You may add to bugzilla the features that rdmd needs to acquire. Andrei
Jan 18 2011
parent reply Trass3r <un known.com> writes:
 the features that rdmd needs to acquire
Well something that's also missing in xfBuild is a proper way to organize different build types: (debug, release) x (x86, x64) x ... But that would require config files similar to dsss' ones I think.
Jan 18 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Trass3r" <un known.com> wrote in message 
news:ih4ij7$1g01$1 digitalmars.com...
 the features that rdmd needs to acquire
Well something that's also missing in xfBuild is a proper way to organize different build types: (debug, release) x (x86, x64) x ... But that would require config files similar to dsss' ones I think.
FWIW, stbuild (part of semitwist d tools) exists to do exactly that: http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/apps/stmanage/stbuild http://www.dsource.org/projects/semitwist/browser/trunk/bin Although I'm thinking of replacing it with something more rake-like.
Jan 18 2011
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ih4p4o$1r1o$1 digitalmars.com...
 "Trass3r" <un known.com> wrote in message 
 news:ih4ij7$1g01$1 digitalmars.com...
 the features that rdmd needs to acquire
Well something that's also missing in xfBuild is a proper way to organize different build types: (debug, release) x (x86, x64) x ... But that would require config files similar to dsss' ones I think.
FWIW, stbuild (part of semitwist d tools) exists to do exactly that: http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/apps/stmanage/stbuild http://www.dsource.org/projects/semitwist/browser/trunk/bin
Oh, and an example of the config file: http://www.dsource.org/projects/semitwist/browser/trunk/stbuild.conf
 Although I'm thinking of replacing it with something more rake-like.

 
Jan 18 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 11:05:34 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 
 Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright 
 <newshound2 digitalmars.com> wrote:

 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-progra
ming-language-good/ 
So, why do users still get a scary linker error when they try to compile a program with more than 1 module?
What is that message?
C:\Temp\D\Build> dmd test1.d OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html test1.obj(test1) Error 42: Symbol Undefined _D5test21fFZv --- errorlevel 1 1) The error message is very technical: a) does not indicate what exactly is wrong (module not passed to linker, not that the linker knows that)
There could be many reasons for the error, see: http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined which is linked from the url listed: http://www.digitalmars.com/ctg/optlink.html and more directly from the FAQ: http://www.digitalmars.com/faq.html
   b) does not give any indication of what the user has to do to fix it
The link above does give such suggestions, depending on what the cause of the error is.
 2) OPTLINK doesn't demangle D mangled names, when it could, and it would 
 improve the readability of its error messages considerably.
    (I know not all mangled names are demangleable, but it'd be a great 
 improvement regardless)
The odd thing is that Optlink did demangle the C++ mangled names, and people actually didn't like it that much.
 dmd can build entire programs with one command:

     dmd file1.d file2.d file3.d ...etc...
That doesn't scale anywhere. What if you want to use a 3rd-party library with a few dozen modules?
Just type the filenames and library names on the command line. You can put hundreds if you like. If you do blow up the command line processor (nothing dmd can do about that), you can put all those files in a file, say "cmd", and invoke with: dmd cmd The only limit is the amount of memory in your system.
Jan 18 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 13:28:32 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 What is that message?
C:\Temp\D\Build> dmd test1.d OPTLINK (R) for Win32 Release 8.00.8 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html test1.obj(test1) Error 42: Symbol Undefined _D5test21fFZv --- errorlevel 1 1) The error message is very technical: a) does not indicate what exactly is wrong (module not passed to linker, not that the linker knows that)
There could be many reasons for the error, see:
Sorry, you're missing the point. The toolchain has the ability to output a much more helpful error message (or just do the right thing and compile the whole project, which is obviously what the user intends to do in 99% of the time).
 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined

 which is linked from the url listed:

 http://www.digitalmars.com/ctg/optlink.html

 and more directly from the FAQ:

 http://www.digitalmars.com/faq.html

   b) does not give any indication of what the user has to do to fix it
The link above does give such suggestions, depending on what the cause of the error is.
This is not nearly good enough. I can bet you that over 95% of users will Google for the error message instead. Further more, that webpage is very technical. Some D users (those wanting a high-performance high-level programming language) don't even need to know what a linker is or does.
 2) OPTLINK doesn't demangle D mangled names, when it could, and it  
 would improve the readability of its error messages considerably.
    (I know not all mangled names are demangleable, but it'd be a great  
 improvement regardless)
The odd thing is that Optlink did demangle the C++ mangled names, and people actually didn't like it that much.
I think we can agree that there is a significant difference between the two audiences (users of your C++ toolchain who need a high-end, high-performance C++ compiler, vs. people who want to try a new programming language). You can make it an option, or just print both mangled and demangled.
 dmd can build entire programs with one command:

     dmd file1.d file2.d file3.d ...etc...
That doesn't scale anywhere. What if you want to use a 3rd-party library with a few dozen modules?
Just type the filenames and library names on the command line. You can put hundreds if you like. If you do blow up the command line processor (nothing dmd can do about that), you can put all those files in a file, say "cmd", and invoke with: dmd cmd The only limit is the amount of memory in your system.
That's not what I meant - I meant it doesn't scale as far as user effort in concerned. There is no reason why D should force users to maintain response files, make files, etc. D (the language) doesn't need them, and nor should the reference implementation. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
parent reply Jim <bitcirkel yahoo.com> writes:
      dmd  cmd

 The only limit is the amount of memory in your system.
That's not what I meant - I meant it doesn't scale as far as user effort in concerned. There is no reason why D should force users to maintain response files, make files, etc. D (the language) doesn't need them, and nor should the reference implementation.
I have to second that. Your main.d imports abd.d which, in turn, imports xyz.d. Why can't the compiler traverse this during compilation in order to find all relevant modules and compile them if needed? I imagine such a compiler could also do some interesting optimisations based on its greater perspective. The single file as a compilation unit seems a little myopic to me. Its reasons are historic, I bet.
Jan 18 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 14:47:29 +0200, Jim <bitcirkel yahoo.com> wrote:

 I imagine such a compiler could also do some interesting optimisations  
 based on its greater perspective.
Compiling the entire program at once opens the door to much more than just optimizations. You could have virtual templated methods, for one. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Jim wrote:
 Why can't the compiler traverse this during compilation in order to
 find all relevant modules and compile them if needed?
How will it find all the modules? Since modules and files don't have to have matching names, it can't assume "import foo;" will necessarily be found in "foo.d". I use this fact a lot to get all a program's dependencies in one place. The modules don't necessarily have to be under the current directory either. It'd have a lot of files to search, which might be brutally slow. ... but, if you do want that behavior, you can get it today somewhat easily: dmd *.d, which works quite well if all the things are in one folder anyway.
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 15:51:58 +0200, Adam Ruppe <destructionator gmail.com>  
wrote:

 Jim wrote:
 Why can't the compiler traverse this during compilation in order to
 find all relevant modules and compile them if needed?
How will it find all the modules? Since modules and files don't have to have matching names, it can't assume "import foo;" will necessarily be found in "foo.d". I use this fact a lot to get all a program's dependencies in one place.
I think this is a misfeature. I suppose you avoid using build tools and prefer makefiles/build scripts for some reason?
 The modules don't necessarily have to be under the current
 directory either. It'd have a lot of files to search, which might
 be brutally slow.
Not if the compiler knows the file name based on the module name.
 ... but, if you do want that behavior, you can get it today somewhat
 easily: dmd *.d, which works quite well if all the things are in
 one folder anyway.
...which won't work on Windows, for projects with packages, and if you have any unrelated .d files (backups, test programs) in your directory (which I almost always do). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Vladimir Panteleev:
 I think [file/module name mismatches] is a misfeature.
Maybe. 9/10 times they match anyway, but I'd be annoyed if the package names had to match the containing folder. Here's what I think might work: just use the existing import path rule. If it gets a match, great. If not, the user can always manually add the other file to the command line anyway.
 I suppose you avoid using build tools and
 prefer makefiles/build scripts for some reason?
Yeah, makefiles and build scripts are adequately fit already. That is, they don't suck enough to justify the effort of getting something new. I've thought about making an automatic build+download thing myself in the past, but the old way has been good enough for me. (If I were to do it, I'd take rdmd and add a little http download facility to it. If you reference a module that isn't already there, it'd look up the path to download it from a config file, grab it, and try the compile. If the config file doesn't exist, it can grab one automatically from a central location. That way, it'd be customizable and extensible by anyone, but still just work out of the box. But, like I said, it stalled out because my classic makefile and simple scripts have been good enough for me.)
 ...which won't work on Windows, for projects with packages, and if
 you have any unrelated .d files (backups, test programs) in your
 directory (which I almost always do).
Indeed.
Jan 18 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 16:58:31 +0200, Adam Ruppe <destructionator gmail.com>  
wrote:

 Yeah, makefiles and build scripts are adequately fit already.
Then the question is: does the time you spent writing and maintaining makefiles and build scripts exceed the time it would take you to set up a build tool? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
Vladimir Panteleev wrote:
 Then the question is: does the time you spent writing and maintaining
 makefiles and build scripts exceed the time it would take you to
 set up a build tool?
I never spent too much time on it anyway, but this thread prompted me to write my own build thing. It isn't 100% done yet, but it does basically work in just 100 lines of code: http://arsdnet.net/dcode/build.d Also depends on these: http://arsdnet.net/dcode/exec.d http://arsdnet.net/dcode/curl.d The exec.d is Linux only, so this program is linux only too. When the new std.process gets into Phobos, exec.d will be obsolete and we'll be cross platform. I borrowed some code from rdmd, so thanks to Andrei for that. I didn't use rdmd directly though since it seems more script oriented than I wanted. The way it works: build somefile.d It uses dmd -v (same as rdmd) to get the list of files it tries to import. It watches dmd's error output for files it can't find. It then tries to fetch those files from my dpldocs.info http folder and tries again (http://dpldocs.info/repository/FILE). If dmd -v completes without errors, it moves on to run the actual compile. All of build's arguments are passed straight to dmd. In my other post, I talked about a configuration file. That would be preferred over just using my own http server so we can spread out our efforts. I just wanted something simple now to see if it actually works well. It worked on my simple program, but on my more complex program, the linker failed...but about the stupid assocative array opapply. Usually my hack to add object_.d from druntime fixes that, but not here. I don't know why. undefined reference to `_D6object30__T16AssociativeArrayTAyaTyAaZ16AssociativeArray7opApplyMFMDFKAyaKyAaZiZi' Meh, I should get to my real work anyway, maybe I'll come back to it. The stupid AAs give me more linker errors than anything else, and they are out of my control!
Jan 18 2011
prev sibling parent reply Austin Hastings <ah08010-d yahoo.com> writes:
On 1/18/2011 10:31 AM, Vladimir Panteleev wrote:
 Then the question is: does the time you spent writing and maintaining
 makefiles and build scripts exceed the time it would take you to set up
 a build tool?
For D, no. When I tried to get started with D2, there were a lot of pointers to kewl build utilities on d-source. None of them worked. None of them that needed to self-build were capable of it. (Some claimed to "just run," which was also false.) So I wound up pissing away about two days (spread out here and there as one library or another would proudly report "this uses build tool Z - isn't it cool?!" and I'd chase down another failure). On the other hand, Gnu Make works. And Perl works. And the dmd2 compiler spits out a dependency list that, with a little bit of perl foo, turns into a makefile fragment nicely. So now I have a standard makefile package that knows about parsing D source to figure out all the incestuous little details about what calls what. And I'm able, thanks to the miracle of "start here and recurse," to move this system from project to project with about 15 minutes of tweaking. Sometimes more, if there's a whole bunch of targets getting built. What's even more, of course, is that my little bit of Makefile foo is portable. I can use make with C, D, Java, C++, Perl, XML, or whatever language-of-the-week I'm playing with. Which is certainly not true of "L33+ build tool Z." And make is pretty much feature-complete at this point, again unlike any of the D build tools. Which means that investing in knowing how to tweak make pays off way better than time spent learning BTZ. =Austin
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings <ah08010-d yahoo.com>  
wrote:

 None of them worked.
Most of those build utilities do exactly what make + your perl-foo do. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
parent reply Austin Hastings <ah08010-d yahoo.com> writes:
On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
 On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings
 <ah08010-d yahoo.com> wrote:

 None of them worked.
Most of those build utilities do exactly what make + your perl-foo do.
No, they don't. That's the point: I was _getting started_ with D2. I had no strong desire to reinvent the wheel, build tool-wise. But the tools I was pointed at just didn't work. I don't mean in a theoretic way - "this tool doesn't detect clock skew on a network that spans the international date line!" - I mean they wouldn't compile, or would compile but couldn't parse the D2 source files, or would compile but then crashed when I ran them. =Austin
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings <ah08010-d yahoo.com>  
wrote:

 On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
 On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings
 <ah08010-d yahoo.com> wrote:

 None of them worked.
Most of those build utilities do exactly what make + your perl-foo do.
No, they don't.
Actually, you're probably right here. To my knowledge, there are only two build tools that take advantage of the -deps compiler option - rdmd and xfbuild. Older ones were forced to parse the source files - rebuild even used DMD's frontend for that. There's also a relatively new tool (dbuild oslt?) which generates makefiles.
 That's the point: I was _getting started_ with D2. I had no strong  
 desire to reinvent the wheel, build tool-wise. But the tools I was  
 pointed at just didn't work.
When a tool works for the author and many other users but not for you, you have to wonder where the fault really is. Besides, aren't all these tools open-source? The one time I had a problem with DSSS, it was easy to fix, and I sent the author a patch and everyone was better off from it. Isn't that how open-source works? :) -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 19.01.2011 07:35, schrieb Vladimir Panteleev:
 On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings <ah08010-d yahoo.com>
wrote:

 On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
 On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings
 <ah08010-d yahoo.com> wrote:

 None of them worked.
Most of those build utilities do exactly what make + your perl-foo do.
No, they don't.
Actually, you're probably right here. To my knowledge, there are only two build tools that take advantage of the -deps compiler option - rdmd and xfbuild. Older ones were forced to parse the source files - rebuild even used DMD's frontend for that. There's also a relatively new tool (dbuild oslt?) which generates makefiles.
 That's the point: I was _getting started_ with D2. I had no strong desire to
 reinvent the wheel, build tool-wise. But the tools I was pointed at just
 didn't work.
When a tool works for the author and many other users but not for you, you have to wonder where the fault really is. Besides, aren't all these tools open-source? The one time I had a problem with DSSS, it was easy to fix, and I sent the author a patch and everyone was better off from it. Isn't that how open-source works? :)
When you're learning a language, you want to get familiar with it before starting to fix stuff.
Jan 19 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Daniel Gibson wrote:
 When you're learning a language, you want to get familiar with it before 
 starting to fix stuff.
I tend to learn things by fixing them :-)
Feb 07 2011
next sibling parent Gour <gour atmarama.net> writes:
On Mon, 07 Feb 2011 01:06:46 -0800
Walter Bright <newshound2 digitalmars.com> wrote:

 I tend to learn things by fixing them :-)
Heh...this is called 'engineer'. ;) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Feb 07 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 02/07/2011 10:06 AM, Walter Bright wrote:
 Daniel Gibson wrote:
 When you're learning a language, you want to get familiar with it before
 starting to fix stuff.
I tend to learn things by fixing them :-)
¡ great ! Though original authors often do not appreciate this attitude very much, early fans even less ;-) [whatever your true interest, humility, and, hum, say, "good will"] Denis -- _________________ vita es estrany spir.wikidot.com
Feb 07 2011
prev sibling parent reply "nedbrek" <nedbrek yahoo.com> writes:
"Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
news:op.vpjlwrletuzx1w cybershadow.mshome.net...
 On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings <ah08010-d yahoo.com> 
 wrote:

 On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
Actually, you're probably right here. To my knowledge, there are only two build tools that take advantage of the -deps compiler option - rdmd and xfbuild. Older ones were forced to parse the source files - rebuild even used DMD's frontend for that. There's also a relatively new tool (dbuild oslt?) which generates makefiles.
Can someone tell me the corner case that requires a build tool to parse the whole source file? My make helper is awk, it just looks for the "import" and strips out the needed info... Thanks, Ned
Jan 19 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"nedbrek" <nedbrek yahoo.com> wrote in message 
news:ih6o0g$2geu$1 digitalmars.com...
 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
 news:op.vpjlwrletuzx1w cybershadow.mshome.net...
 On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings <ah08010-d yahoo.com> 
 wrote:

 On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
Actually, you're probably right here. To my knowledge, there are only two build tools that take advantage of the -deps compiler option - rdmd and xfbuild. Older ones were forced to parse the source files - rebuild even used DMD's frontend for that. There's also a relatively new tool (dbuild oslt?) which generates makefiles.
Can someone tell me the corner case that requires a build tool to parse the whole source file? My make helper is awk, it just looks for the "import" and strips out the needed info...
Just as a few examples: mixin("import foo.bar;"); // or enum a = "import "; enum b = "foo."; enum c = "bar;"; mixin(a~b~c); // or static if(/+some fancy condition here+/) import foo.bar;
Jan 19 2011
next sibling parent "nedbrek" <nedbrek yahoo.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ih7dj0$s4j$1 digitalmars.com...
 "nedbrek" <nedbrek yahoo.com> wrote in message 
 news:ih6o0g$2geu$1 digitalmars.com...
 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
 news:op.vpjlwrletuzx1w cybershadow.mshome.net...
 On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings 
 <ah08010-d yahoo.com> wrote:

 On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
Actually, you're probably right here. To my knowledge, there are only two build tools that take advantage of the -deps compiler option - rdmd and xfbuild. Older ones were forced to parse the source files - rebuild even used DMD's frontend for that. There's also a relatively new tool (dbuild oslt?) which generates makefiles.
Can someone tell me the corner case that requires a build tool to parse the whole source file? My make helper is awk, it just looks for the "import" and strips out the needed info...
Just as a few examples: mixin("import foo.bar;"); // or enum a = "import "; enum b = "foo."; enum c = "bar;"; mixin(a~b~c); // or static if(/+some fancy condition here+/) import foo.bar;
Thanks! Fortunately, I am the only one on this project, so I will be careful to avoid such things! :) Ned
Jan 19 2011
prev sibling parent el muchacho <nicolas.janin gmail.com> writes:
Le 19/01/2011 20:20, Nick Sabalausky a écrit :
 "nedbrek" <nedbrek yahoo.com> wrote in message 
 news:ih6o0g$2geu$1 digitalmars.com...
 "Vladimir Panteleev" <vladimir thecybershadow.net> wrote in message 
 news:op.vpjlwrletuzx1w cybershadow.mshome.net...
 On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings <ah08010-d yahoo.com> 
 wrote:

 On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
Actually, you're probably right here. To my knowledge, there are only two build tools that take advantage of the -deps compiler option - rdmd and xfbuild. Older ones were forced to parse the source files - rebuild even used DMD's frontend for that. There's also a relatively new tool (dbuild oslt?) which generates makefiles.
Can someone tell me the corner case that requires a build tool to parse the whole source file? My make helper is awk, it just looks for the "import" and strips out the needed info...
Just as a few examples: mixin("import foo.bar;"); // or enum a = "import "; enum b = "foo."; enum c = "bar;"; mixin(a~b~c); // or static if(/+some fancy condition here+/) import foo.bar;
This is exactly the reason why the build system must be included in the compiler and not in external tools.
Jan 29 2011
prev sibling parent reply Jim <bitcirkel yahoo.com> writes:
Adam Ruppe Wrote:
 Maybe. 9/10 times they match anyway, but I'd be annoyed if
 the package names had to match the containing folder.
This is enforced in some languages, and I like it. It'd be confusing if they didn't match when I would go to look for something. I think it would be a good idea for D to standardise this. Not only so that the compiler can traverse and compile but for all dev tools (static analysers, package managers, etc). Standardisation makes it easier to create toolchains, which I believe are essential for the growth of any language use.
Jan 18 2011
next sibling parent reply spir <denis.spir gmail.com> writes:
On 01/18/2011 06:33 PM, Jim wrote:
 Adam Ruppe Wrote:
 Maybe. 9/10 times they match anyway, but I'd be annoyed if
 the package names had to match the containing folder.
This is enforced in some languages, and I like it. It'd be confusing if they didn't match when I would go to look for something. I think it would be a good idea for D to standardise this. Not only so that the compiler can traverse and compile but for all dev tools (static analysers, package managers, etc). Standardisation makes it easier to create toolchains, which I believe are essential for the growth of any language use.
The D styleguide requires on one hand capitalised names for types, and lowercase for filenames on the other. How are we supposed to make them match? Denis _________________ vita es estrany spir.wikidot.com
Jan 18 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:

 The D styleguide requires on one hand capitalised names for types, and 
 lowercase for filenames on the other. How are we supposed to make them 
 match?
Why do you want them to match? Bye, bearophile
Jan 18 2011
parent reply spir <denis.spir gmail.com> writes:
On 01/18/2011 07:10 PM, bearophile wrote:
 spir:

 The D styleguide requires on one hand capitalised names for types, and
 lowercase for filenames on the other. How are we supposed to make them
 match?
Why do you want them to match?
Because when a module defines a type Foo (or rather, it's what is exported), I like it to be called Foo.d. A module called doFoo.d would certainly mainly define a func doFoo. So, people directly know what's in there (and this, from D's own [supposed] naming rules :-). Simple, no? Denis _________________ vita es estrany spir.wikidot.com
Jan 19 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
spir:

 Because when a module defines a type Foo (or rather, it's what is 
 exported), I like it to be called Foo.d.
Generally D modules contain many types. Bye, bearophile
Jan 19 2011
parent reply spir <denis.spir gmail.com> writes:
On 01/19/2011 12:56 PM, bearophile wrote:
 spir:

 Because when a module defines a type Foo (or rather, it's what is
 exported), I like it to be called Foo.d.
Generally D modules contain many types.
Yep, but often one is the main exported element. When there are several, hopefully sensibly related, exported things, then it's easy to indicate: mathFuncs, stringTools, bitOps... while still following D naming conventions. Was it me or you who heavily & repetedly insisted on the importance of consistent style, in particular naming, in a programming community (I strongly support you on this point). Why should modules not benefit of this? For sure, there are case-insensitive filesystems, but only prevents using _in the same dir_ (or package) module names that differ only on case. I guess. Denis _________________ vita es estrany spir.wikidot.com
Jan 19 2011
parent bearophile <bearophileHUGS lycos.com> writes:
spir:

 Yep, but often one is the main exported element.
That's not true for Phobos, my dlibs1, and lot of my code that uses those libs.
When there are several, hopefully sensibly related, exported things, then it's
easy to indicate: mathFuncs, stringTools, bitOps... while still following D
naming conventions.<
D module names are better fully lowercase. This is their D standard... Bye, bearophile
Jan 19 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 19 Jan 2011 12:57:42 +0200, spir <denis.spir gmail.com> wrote:

 Because when a module defines a type Foo (or rather, it's what is  
 exported), I like it to be called Foo.d. A module called doFoo.d would  
 certainly mainly define a func doFoo. So, people directly know what's in  
 there (and this, from D's own [supposed] naming rules :-). Simple, no?
I actually tried this convention for a project. It turned out a not very good idea, because if you want to access a static member or subclass of said class, you must specify the type twice (once for the module name, and another for the type) - e.g. "Foo.Foo.bar()". Besides, it's against the recommended D code style convention: http://www.digitalmars.com/d/2.0/dstyle.html -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 19 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.710.1295434677.4748.digitalmars-d puremagic.com...
 On 01/18/2011 07:10 PM, bearophile wrote:
 spir:

 The D styleguide requires on one hand capitalised names for types, and
 lowercase for filenames on the other. How are we supposed to make them
 match?
Why do you want them to match?
Because when a module defines a type Foo (or rather, it's what is exported), I like it to be called Foo.d. A module called doFoo.d would certainly mainly define a func doFoo. So, people directly know what's in there (and this, from D's own [supposed] naming rules :-). Simple, no?
If I have a class Foo in it's own module, I call the module (and file) "foo". I find this to be simple too, because this way types are always capitalzed and modules are always non-captialized. Plus, like Vladimir indicated, this makes it a lot easier to distinguish between the type ("Foo") and the module ("foo").
Jan 19 2011
prev sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 18.01.2011 18:41, schrieb spir:
 On 01/18/2011 06:33 PM, Jim wrote:
 Adam Ruppe Wrote:
 Maybe. 9/10 times they match anyway, but I'd be annoyed if
 the package names had to match the containing folder.
This is enforced in some languages, and I like it. It'd be confusing if they didn't match when I would go to look for something. I think it would be a good idea for D to standardise this. Not only so that the compiler can traverse and compile but for all dev tools (static analysers, package managers, etc). Standardisation makes it easier to create toolchains, which I believe are essential for the growth of any language use.
The D styleguide requires on one hand capitalised names for types, and lowercase for filenames on the other. How are we supposed to make them match? Denis _________________ vita es estrany spir.wikidot.com
Filenames should match with the module they contain, not with the contained class(es).
Jan 18 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jim wrote:
 Adam Ruppe Wrote:
 Maybe. 9/10 times they match anyway, but I'd be annoyed if the package
 names had to match the containing folder.
This is enforced in some languages, and I like it. It'd be confusing if they didn't match when I would go to look for something. I think it would be a good idea for D to standardise this. Not only so that the compiler can traverse and compile but for all dev tools (static analysers, package managers, etc). Standardisation makes it easier to create toolchains, which I believe are essential for the growth of any language use.
Forcing the module name to match the file name sounds good, but in practice it makes it hard to debug modules. What I like to do is to copy a suspicious module to foo.d (or whatever.d) and link it in explicitly, which will override the breaking one. Then, I hack away at it until I discover the problem, then fix the original.
Jan 18 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Walter Bright Wrote:
 Forcing the module name to match the file name sounds good, but in practice it 
 makes it hard to debug modules. What I like to do is to copy a suspicious
module 
 to foo.d (or whatever.d) and link it in explicitly, which will override the 
 breaking one. Then, I hack away at it until I discover the problem, then fix
the 
 original.
This would admittedly impose some constraints, but I think it would ultimately be worth it. It makes everything much clearer and creates a bunch of opportunities for further development. I'd create a branch (in git or mercury) for that task, it's quick and dirt cheap, very easy to switch to and from, and you get the diff for free.
Jan 18 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Jim Wrote:

 Walter Bright Wrote:
 Forcing the module name to match the file name sounds good, but in practice it 
 makes it hard to debug modules. What I like to do is to copy a suspicious
module 
 to foo.d (or whatever.d) and link it in explicitly, which will override the 
 breaking one. Then, I hack away at it until I discover the problem, then fix
the 
 original.
This would admittedly impose some constraints, but I think it would ultimately be worth it. It makes everything much clearer and creates a bunch of opportunities for further development.
I don't see such benefit. First off, I don't see file/module names not matching very often. Tools can be developed to assume such structure exists which means more incentive to keep such structure, I believe rdmd already makes this assumption. It also wouldn't be hard to make a program that takes a list of files, names and places them into the proper structure.
 I'd create a branch (in git or mercury) for that task, it's quick and dirt
cheap, very easy to switch to and from, and you get the diff for free.
Right, using such tools is great. But what if you are like me and don't have a dev environment set up for Phobos, but I want to fix some module? Do I have to setup such an environment or through the file in a folder std/ just do some work on it? I don't really know how annoying I would find such a change, but I don't think I would ever see at as a feature.
Jan 18 2011
prev sibling parent reply Thias <void invalid.com> writes:
On 18/01/11 20:26, Walter Bright wrote:
 Jim wrote:
 Adam Ruppe Wrote:
 Maybe. 9/10 times they match anyway, but I'd be annoyed if the package
 names had to match the containing folder.
This is enforced in some languages, and I like it. It'd be confusing if they didn't match when I would go to look for something. I think it would be a good idea for D to standardise this. Not only so that the compiler can traverse and compile but for all dev tools (static analysers, package managers, etc). Standardisation makes it easier to create toolchains, which I believe are essential for the growth of any language use.
Forcing the module name to match the file name sounds good, but in practice it makes it hard to debug modules. What I like to do is to copy a suspicious module to foo.d (or whatever.d) and link it in explicitly, which will override the breaking one. Then, I hack away at it until I discover the problem, then fix the original.
Couldn’t you do exactly the same thing by just copying the file? cp suspicious.d suspicious.orig edit suspicious.d
Jan 18 2011
parent "Nick Sabalausky" <a a.a> writes:
"Thias" <void invalid.com> wrote in message 
news:ih52a8$2bba$1 digitalmars.com...
 On 18/01/11 20:26, Walter Bright wrote:
 Jim wrote:
 Adam Ruppe Wrote:
 Maybe. 9/10 times they match anyway, but I'd be annoyed if the package
 names had to match the containing folder.
This is enforced in some languages, and I like it. It'd be confusing if they didn't match when I would go to look for something. I think it would be a good idea for D to standardise this. Not only so that the compiler can traverse and compile but for all dev tools (static analysers, package managers, etc). Standardisation makes it easier to create toolchains, which I believe are essential for the growth of any language use.
Forcing the module name to match the file name sounds good, but in practice it makes it hard to debug modules. What I like to do is to copy a suspicious module to foo.d (or whatever.d) and link it in explicitly, which will override the breaking one. Then, I hack away at it until I discover the problem, then fix the original.
Couldn’t you do exactly the same thing by just copying the file? cp suspicious.d suspicious.orig edit suspicious.d
That's what I do. Works fine. (Although I keep the .d extension, and do like "suspicious orig.d")
Jan 18 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/18/11, Walter Bright <newshound2 digitalmars.com> wrote:
 You can put
 hundreds if you like.
DMD can, but Optlink can't handle long arguments.
Jan 18 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 On 1/18/11, Walter Bright <newshound2 digitalmars.com> wrote:
 You can put
 hundreds if you like.
DMD can, but Optlink can't handle long arguments.
Example?
Jan 18 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/18/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 1/18/11, Walter Bright <newshound2 digitalmars.com> wrote:
 You can put
 hundreds if you like.
DMD can, but Optlink can't handle long arguments.
Although now that I've read the error description I might have passed a wrong argument somehow. I'll take a look.
Jan 18 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Vladimir Panteleev:

 IMO, sticking to the C-ism of "one object file at a time" and dependency  
 on external build tools / makefiles is the biggest mistake DMD did in this  
 regard.
A Unix philosophy is to create tools that are able to do only one thing well, and rdmd uses DMD to do its job of helping compile small projects automatically. Yet the D compiler is not following that philosophy in many situations because it is doing lot of stuff beside compiling D code, like profiler, code coverage analyser, unittester, docs generator, JSON summary generator, and more. D1 compiler used to have a cute literary programming feature too, that's often used by Haskell blogs. Here Walter is pragmatic: docs generator happens to be quicker to create and maintain if it's built inside the compiler. So it's right to fold this rdmd functionality inside the compiler? Is this practically useful, like is this going to increase rdmd speed? Folding rdmd functionality inside the compiler may risk freezing the future evolution of future D build tools, so it has a risks/costs too. Bye, bearophile
Jan 18 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 11:22:36 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:

 Folding rdmd functionality inside the compiler may risk freezing the  
 future evolution of future D build tools, so it has a risks/costs too.
Nobody needs more than one (good) D build tool. How many build tools does Go/Scala/Haskell/etc. have? Regardless if it's in the compiler or not, the only real requirement is that the source is maintainable, and the barrier to contribute to it is low enough (hurray for GitHub). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-18 10:22, bearophile wrote:
 Vladimir Panteleev:

 IMO, sticking to the C-ism of "one object file at a time" and dependency
 on external build tools / makefiles is the biggest mistake DMD did in this
 regard.
A Unix philosophy is to create tools that are able to do only one thing well, and rdmd uses DMD to do its job of helping compile small projects automatically. Yet the D compiler is not following that philosophy in many situations because it is doing lot of stuff beside compiling D code, like profiler, code coverage analyser, unittester, docs generator, JSON summary generator, and more. D1 compiler used to have a cute literary programming feature too, that's often used by Haskell blogs. Here Walter is pragmatic: docs generator happens to be quicker to create and maintain if it's built inside the compiler. So it's right to fold this rdmd functionality inside the compiler? Is this practically useful, like is this going to increase rdmd speed? Folding rdmd functionality inside the compiler may risk freezing the future evolution of future D build tools, so it has a risks/costs too. Bye, bearophile
I would say that in this case the LLVM/Clang approach would be the best. Build a solid compiler library that other tools can be built upon, including the compiler. -- /Jacob Carlborg
Jan 18 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Vladimir Panteleev wrote:
 IMO, sticking to the C-ism of "one object file at a time" and dependency 
 on external build tools / makefiles is the biggest mistake DMD did in 
 this regard.
You don't need such a tool with dmd until your project exceeds a certain size. Most of my little D projects' "build tool" is a one line script that looks like: dmd foo.d bar.d There's just no need to go farther than that.
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 22:17:08 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Vladimir Panteleev wrote:
 IMO, sticking to the C-ism of "one object file at a time" and  
 dependency on external build tools / makefiles is the biggest mistake  
 DMD did in this regard.
You don't need such a tool with dmd until your project exceeds a certain size. Most of my little D projects' "build tool" is a one line script that looks like: dmd foo.d bar.d There's just no need to go farther than that.
Let's review the two problems discussed in this thread: 1) Not passing all modules to the compiler results in a nearly-incomprehensible (for some) linker error. 2) DMD's inability (or rather, unwillingness) to build the whole program when it's in the position to, which creates the dependency on external build tools (or solutions that require unnecessary human effort). Are you saying that there's no need to fix neither of these because they don't bother you personally? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/11 11:37 PM, Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 22:17:08 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Vladimir Panteleev wrote:
 IMO, sticking to the C-ism of "one object file at a time" and
 dependency on external build tools / makefiles is the biggest mistake
 DMD did in this regard.
You don't need such a tool with dmd until your project exceeds a certain size. Most of my little D projects' "build tool" is a one line script that looks like: dmd foo.d bar.d There's just no need to go farther than that.
Let's review the two problems discussed in this thread: 1) Not passing all modules to the compiler results in a nearly-incomprehensible (for some) linker error. 2) DMD's inability (or rather, unwillingness) to build the whole program when it's in the position to, which creates the dependency on external build tools (or solutions that require unnecessary human effort). Are you saying that there's no need to fix neither of these because they don't bother you personally?
I think the larger picture is even more important. We need a package system that takes Internet distribution into account. I got word on the IRC that dsss was that. It would be great to resurrect that, or start a new project with such goals. Andrei
Jan 18 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-19 06:55, Andrei Alexandrescu wrote:
 On 1/18/11 11:37 PM, Vladimir Panteleev wrote:
 On Tue, 18 Jan 2011 22:17:08 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 Vladimir Panteleev wrote:
 IMO, sticking to the C-ism of "one object file at a time" and
 dependency on external build tools / makefiles is the biggest mistake
 DMD did in this regard.
You don't need such a tool with dmd until your project exceeds a certain size. Most of my little D projects' "build tool" is a one line script that looks like: dmd foo.d bar.d There's just no need to go farther than that.
Let's review the two problems discussed in this thread: 1) Not passing all modules to the compiler results in a nearly-incomprehensible (for some) linker error. 2) DMD's inability (or rather, unwillingness) to build the whole program when it's in the position to, which creates the dependency on external build tools (or solutions that require unnecessary human effort). Are you saying that there's no need to fix neither of these because they don't bother you personally?
I think the larger picture is even more important. We need a package system that takes Internet distribution into account. I got word on the IRC that dsss was that. It would be great to resurrect that, or start a new project with such goals. Andrei
I've been thinking for a while about doing a package system for D, basically gems but for D. But I first want to finish (finish as in somewhat usable and release it) another project I'm working on. -- /Jacob Carlborg
Jan 19 2011
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Andrei wrote:
  We need a package system that takes Internet distribution
 into account.
Do you think something like my simple http based system would work? Fetch dependencies. Try to compile. If the linker complains about missing files, download them from http://somewebsite/somepath/filename, try again from the beginning. There's no metadata, no version tracking, nothing like that, but I don't think such things are necessary. Worst case, just download the specific version you need for your project manually.
Jan 19 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 19.01.2011 14:56, schrieb Adam Ruppe:
 Andrei wrote:
   We need a package system that takes Internet distribution
 into account.
Do you think something like my simple http based system would work? Fetch dependencies. Try to compile. If the linker complains about missing files, download them from http://somewebsite/somepath/filename, try again from the beginning.
That'd suck horribly for bigger projects, and also when you've got a lot of dependencies, I guess.
 There's no metadata, no version tracking, nothing like that, but
 I don't think such things are necessary. Worst case, just download
 the specific version you need for your project manually.
I don't think it's such a big burden to list the dependencies for your project. Or, even better: combine both ideas: Automatically create and save a list of dependencies by trying (like you described). Then when you release your project, the dependency list is there and all dependencies can be fetched before building. Cheers, - Daniel
Jan 19 2011
parent Adam Ruppe <destructionator gmail.com> writes:
Daniel Gibson wrote:
 That'd suck horribly for bigger projects, and also when
 you've got a lot of dependencies, I guess
Maybe, especially if the dependencies have dependencies (it'd have to download one set before knowing what to look for for the next set), but that is a one time cost - after the files the first time, no need to download them again. It could probably cache the dependency list too, though I'm not sure the lag of checking it again is that bad anyway. Though, IMO, the biggest advantage for a system like this is for small programs instead of big ones. If you're doing a big program, it isn't much of an added effort to include the deps or manually script the build/makefile. You probably have some compile switches anyway. For a little program though, it is somewhat annoying to have to list all that stuff manually. Writing out the command line might take longer than writing the program!
 Or, even better: combine both ideas: Automatically create and
 save a list of dependencies by trying (like you described).
Yea, that'd work too. It could possibly figure out whole packages to grab that way too, instead of doing individual files. It'd be a little extra effort, though.
Jan 19 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/11 7:56 AM, Adam Ruppe wrote:
 Andrei wrote:
   We need a package system that takes Internet distribution
 into account.
Do you think something like my simple http based system would work? Fetch dependencies. Try to compile. If the linker complains about missing files, download them from http://somewebsite/somepath/filename, try again from the beginning. There's no metadata, no version tracking, nothing like that, but I don't think such things are necessary. Worst case, just download the specific version you need for your project manually.
I'm not sure. A friend of mine who is well versed in such issues suggested two sources of inspiration: apt-get and cpan. As a casual user of both, I can indeed say that they are doing a very good job. Andrei
Jan 19 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-19 14:56, Adam Ruppe wrote:
 Andrei wrote:
   We need a package system that takes Internet distribution
 into account.
Do you think something like my simple http based system would work? Fetch dependencies. Try to compile. If the linker complains about missing files, download them from http://somewebsite/somepath/filename, try again from the beginning. There's no metadata, no version tracking, nothing like that, but I don't think such things are necessary. Worst case, just download the specific version you need for your project manually.
That doesn't sound like a good solution. I think you would have to manually specify the dependencies. -- /Jacob Carlborg
Jan 19 2011
prev sibling parent reply retard <re tard.com.invalid> writes:
Wed, 19 Jan 2011 13:56:17 +0000, Adam Ruppe wrote:

 Andrei wrote:
  We need a package system that takes Internet distribution
 into account.
Do you think something like my simple http based system would work? Fetch dependencies. Try to compile. If the linker complains about missing files, download them from http://somewebsite/somepath/filename, try again from the beginning. There's no metadata, no version tracking, nothing like that, but I don't think such things are necessary. Worst case, just download the specific version you need for your project manually.
A build tool without any kind of dependency versioning support is a complete failure. Especially if it also tries to handle external non-D dependencies. It basically makes supporting all libraries with rapid API changes quite impossible.
Jan 19 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
retard wrote:
 A build tool without any kind of dependency versioning support is a
 complete failure.
You just delete the old files and let it re-download them to update. If the old one is working for you, simply keep it.
Jan 19 2011
next sibling parent reply retard <re tard.com.invalid> writes:
Wed, 19 Jan 2011 19:41:47 +0000, Adam Ruppe wrote:

 retard wrote:
 A build tool without any kind of dependency versioning support is a
 complete failure.
You just delete the old files and let it re-download them to update. If the old one is working for you, simply keep it.
I meant that if the latest version 0.321 of the project 'foobar' depends on 'bazbaz 0.5.8.2' but also versions 0.5.8.4 - 0.5.8.11 (API but not ABI compatible) and 0.5.9 (mostly incompatible) and 0.6 - 0.9.12.3 (totally incompatible) exist, the build fails badly when downloading the latest library. If you don't document the versions of the dependencies anywhere, it's almost impossible to build to project even manually.
Jan 19 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 I meant that if the latest version 0.321 of the project 'foobar'
 depends on 'bazbaz 0.5.8.2'
Personally, I'd just prefer people to package their damned dependencies with their app.... But, a configuration file could fix that easily enough. Set one up like this: bazbaz = http://bazco.com/0.5.8.2/ Then it'd try to download http://bazco.com/0.5.8.2/bazbaz.module.d instead of the default site (which is presumably the latest version). This approach also makes it easy to add third party servers and libraries, so you wouldn't be dependent on a central source for your code. Here's a potential problem: what if bazbaz needs some specific version of something too? Maybe it could check for a config file on its server too, and use those directives when getting the library.
Jan 19 2011
parent reply retard <re tard.com.invalid> writes:
Wed, 19 Jan 2011 20:01:28 +0000, Adam Ruppe wrote:

 I meant that if the latest version 0.321 of the project 'foobar'
 depends on 'bazbaz 0.5.8.2'
Personally, I'd just prefer people to package their damned dependencies with their app.... But, a configuration file could fix that easily enough. Set one up like this: bazbaz = http://bazco.com/0.5.8.2/ Then it'd try to download http://bazco.com/0.5.8.2/bazbaz.module.d instead of the default site (which is presumably the latest version). This approach also makes it easy to add third party servers and libraries, so you wouldn't be dependent on a central source for your code. Here's a potential problem: what if bazbaz needs some specific version of something too? Maybe it could check for a config file on its server too, and use those directives when getting the library.
How it goes is you come up with more and more features if you spend some time THINKING about the possible functionality for such a tool. Instead of NIH, why don't you just study what the existing tools do and pick up all the relevant features. Why there are so many open source tools doing the exactly same thing is that developers are too lazy to study the previous work and start developing code before the common sense kicks in.
Jan 19 2011
parent Adam Ruppe <destructionator gmail.com> writes:
retard wrote:
 How it goes is you come up with more and more features if you spend
 sometime THINKING about the possible functionality for such a tool.
It, as written now, does everything I've ever wanted. If I try to do every possible function, it'll never be done. The question is what's trivially easy to automate, somewhat difficult to do by other means, and fairly useful. I'm not convinced building falls under that *at all*, much less every random edge case under the sun.
Jan 19 2011
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 19 Jan 2011 21:41:47 +0200, Adam Ruppe <destructionator gmail.com>  
wrote:

 retard wrote:
 A build tool without any kind of dependency versioning support is a
 complete failure.
You just delete the old files and let it re-download them to update. If the old one is working for you, simply keep it.
You're missing the point. You want to install package X (either directly or as a dependency for something else), which was written for a specific version of Y. Your tool will just download the latest version of Y and the whole thing crashes and burns. Someone posted this somewhere else in this thread, I believe it's quite relevant: http://cdsmith.wordpress.com/2011/01/16/haskells-own-dll-hell/ -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 19 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Vladimir Panteleev wrote:
 Your tool will just download the latest version of Y and the
 whole thing crashes and burns.
My problem is I don't see how that'd happen in the first place. Who would distribute something they've never compiled? If they compiled it, it would have downloaded the other libs already, so any sane distribution *already* has the dependent libraries, making this whole thing moot. The build tool is meant to help the developer, not the user. If the user needs help, it means the developer didn't do his job properly. That said, the configuration file, as described in my last post, seems like it can solve this easily enough.
Jan 19 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Meh.

Just give us File access in CTFE and we'll be done talking about build
tools. Just run DMD on the thing and the app automagically tracks and
downloads all of its dependencies.

Im kidding. But file access in CTFE would be so damn cool. :)
Jan 19 2011
parent reply Mafi <mafi example.org> writes:
Am 19.01.2011 21:22, schrieb Andrej Mitrovic:
 Meh.

 Just give us File access in CTFE and we'll be done talking about build
 tools. Just run DMD on the thing and the app automagically tracks and
 downloads all of its dependencies.

 Im kidding. But file access in CTFE would be so damn cool. :)
What about the alternative import import("file.ext") //compile time string of the contents of file.ext You can do for example: mixin(import("special.d")); //c-style import/include
Jan 19 2011
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Mafi Wrote:

 Am 19.01.2011 21:22, schrieb Andrej Mitrovic:
 Meh.

 Just give us File access in CTFE and we'll be done talking about build
 tools. Just run DMD on the thing and the app automagically tracks and
 downloads all of its dependencies.

 Im kidding. But file access in CTFE would be so damn cool. :)
What about the alternative import import("file.ext") //compile time string of the contents of file.ext You can do for example: mixin(import("special.d")); //c-style import/include
Then you have to add -J command line switches for the location of the importable files.
Jan 19 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-19 21:13, Adam Ruppe wrote:
 Vladimir Panteleev wrote:
 Your tool will just download the latest version of Y and the
 whole thing crashes and burns.
My problem is I don't see how that'd happen in the first place. Who would distribute something they've never compiled? If they compiled it, it would have downloaded the other libs already, so any sane distribution *already* has the dependent libraries, making this whole thing moot. The build tool is meant to help the developer, not the user. If the user needs help, it means the developer didn't do his job properly.
I would say it's for the user of the library. He only cares about the library he wants to use and not its dependencies.
 That said, the configuration file, as described in my last post,
 seems like it can solve this easily enough.
-- /Jacob Carlborg
Jan 20 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
It's a cute blog post. It suggests that it will be good to: Getting Code: 1) Have a central repository for D modules that is easy to use for both submitters and users. - D code in such repository must Just Work. - I must stress that having a shared community-wide style to write D code helps a lot when you want to use in your program modules written by other people. Otherwise your program looks like a patchwork of wildly different styles. - D language must be designed to help writing code that works well both on 32 and 64 bit systems, helping to avoid the traps listed here: http://www.viva64.com/en/a/0065/ - Path-related problems must be minimized. - Probably D the package system needs to be improved. Some Java people are even talking about introducing means to create superpackages. Some module system theory from ML-like languages may help here. Figuring Out Code: - D compiler has to improve its error messages a lot. Error messages need to become polished and sharp. Linker errors are bad, they need to be avoided where possible (this means the compiler catches some errors before they become linker errors). C# compiler also gives a standard error number for each error, that allows to read about the error and its causes and solutions. Writing Code: - Interactive Console: it will be good to have sometime like this built in the D distribution. From the article:
Further, while I know there are people who like IDEs, for me they serve to
cripple the exploratory play of coding so that it’s about as fun as filling out
tax forms.<
In this regard I think D has to take two things into account: - People today like to use modern IDEs. So the core of the language too needs be designed to work well with IDEs. Currently D doesn't look much designed to be IDE-friendly. - On the other hand I see it a failure if the language requires a complex IDE to write code. I am able to write complex Python programs with no IDE, this means that Python is well designed. One more thing: from a recent discussion with Walter about software engineering, it seems that computer languages are both a design tool and engineering building material. Python is better than D for exploratory programming (http://en.wikipedia.org/wiki/Exploratory_programming ), or even to invent new algorithms and to explore new software ideas. D is probably better than Python to build larger software engineering systems. Lately Python has added several features to improve its "programming in the large" skills (decorators, Abstract Base Classes, optional annotations, etc), likewise I think D will enjoy some little handy features that help both exploratory programming and "programming in the small", like tuple unpacking syntax (http://d.puremagic.com/issues/show_bug.cgi?id=4579 ). There are features like named arguments (http://en.wikipedia.org/wiki/Parameter_%28computer_programming 29#Named_parameters ) that are useful for both little and large programs, named arguments are one of the things I'd like in D still. Bye, bearophile
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 12:10:25 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:

 Walter:

 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
It's a cute blog post. It suggests that it will be good to: Getting Code: 1) Have a central repository for D modules that is easy to use for both submitters and users.
Forcing a code repository is bad. Let authors use anything that they're comfortable with. The "repository" must be nothing more than a database of metadata (general information about a package, and how to download it).
 - D code in such repository must Just Work.
This is not practical. The only practical way is to put that responsibility on the authors, and to encourage forking and competition.
 - I must stress that having a shared community-wide style to write D  
 code helps a lot when you want to use in your program modules written by  
 other people. Otherwise your program looks like a patchwork of wildly  
 different styles.
I assume you mean naming conventions and not actual code style (indentation etc.)
 - Probably D the package system needs to be improved. Some Java people  
 are even talking about introducing means to create superpackages. Some  
 module system theory from ML-like languages may help here.
Why?
 Writing Code:
 - Interactive Console: it will be good to have sometime like this built  
 in the D distribution.
I don't think this is practical until someone writes a D interpreter. Have you ever seen an interactive console for a purely-compiled language?
 - People today like to use modern IDEs. So the core of the language too  
 needs be designed to work well with IDEs. Currently D doesn't look much  
 designed to be IDE-friendly.
How would DMD become even more IDE-friendly that it already is? What about -X?
 One more thing: from a recent discussion with Walter about software  
 engineering, it seems that computer languages are both a design tool and  
 engineering building material. Python is better than D for exploratory  
 programming (http://en.wikipedia.org/wiki/Exploratory_programming ), or  
 even to invent new algorithms and to explore new software ideas. D is  
 probably better than Python to build larger software engineering  
 systems. Lately Python has added several features to improve its  
 "programming in the large" skills (decorators, Abstract Base Classes,  
 optional annotations, etc), likewise I think D will enjoy some little  
 handy features that help both exploratory programming and "programming  
 in the small", like tuple unpacking syntax  
 (http://d.puremagic.com/issues/show_bug.cgi?id=4579 ). There are  
 features like named arguments  
 (http://en.wikipedia.org/wiki/Parameter_%28computer_programming
29#Named_parameters  
 ) that are useful for both little and large programs, named arguments  
 are one of the things I'd like in D still.
I have to agree that named arguments are awesome, they make the code much more readable and maintainable in many instances. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Vladimir Panteleev <vladimir thecybershadow.net> wrote:

 - I must stress that having a shared community-wide style to write D  
 code helps a lot when you want to use in your program modules written  
 by other people. Otherwise your program looks like a patchwork of  
 wildly different styles.
I assume you mean naming conventions and not actual code style (indentation etc.)
Likely he meant more than that. At least such is the impression I've had before. I am not vehemently opposed to such an idea, and I definitely agree that naming conventions should be observed, but I have at times had the impression that bearophile wants all aspects of code to be controlled by such a coding style. -- Simen
Jan 18 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Vladimir Panteleev:

 Forcing a code repository is bad.
In this case I was not suggesting to force things :-) But having a place to find reliable modules is very good.
 This is not practical.
It works in Python, Ruby and often in Perl too, so I don't agree.
 I assume you mean naming conventions and not actual code style (indentation
etc.)
I meant that D code written by different people is better looking similar, where possible. C/C++ programmers have too much freedom where freedom is not necessary. Reducing some of such useless freedom helps improve the code ecosystem.
 - Probably D the package system needs to be improved. Some Java people  
 are even talking about introducing means to create superpackages. Some  
 module system theory from ML-like languages may help here.
 Why?
- Currently D packages are not working well yet, there are bug reports on this. - Something higher level than packages is useful when you build very large systems. - Module system theory from ML-like languages shows many years old ideas that otherwise will need to be painfully re-invented half-broken by D language developers. Sometimes wasting three days reading saves you some years of pain.
 I don't think this is practical until someone writes a D interpreter.
CTFE interpter is already there :-)
 How would DMD become even more IDE-friendly that it already is?
- error messages that give column number - folding annotations? - less usage of string mixins and more on delegates and normal D code - More introspection - etc
 I have to agree that named arguments are awesome, they make the code much more
readable and maintainable in many instances.<
I haven not already written an enhancement request on this because until few weeks ago I have thought that named arguments improve the usage of functions with many arguments, so they may encourage D programmers to create more functions like this from Windows API: HWND CreateWindow( LPCTSTR lpClassName, LPCTSTR lpWindowName,DWORD style,int x, int y, int width, int height, HWND hWndParent,HMENU hMenu,HANDLE hInstance,LPVOID lpParam); but lately I have understood that this is not the whole truth, named arguments are useful even when your functions have just 3 arguments. They make code more readable in both little script-like programs, and help avoid some mistakes in larger programs too. Bye, bearophile
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 13:27:56 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:

 Vladimir Panteleev:

 Forcing a code repository is bad.
In this case I was not suggesting to force things :-) But having a place to find reliable modules is very good.
 This is not practical.
It works in Python, Ruby and often in Perl too, so I don't agree.
I think we have a misunderstanding, then? Who ensures that the modules "just work"? If someone breaks something, are they thrown out of The Holy Repository?
 I assume you mean naming conventions and not actual code style  
 (indentation etc.)
I meant that D code written by different people is better looking similar, where possible. C/C++ programmers have too much freedom where freedom is not necessary. Reducing some of such useless freedom helps improve the code ecosystem.
It also demotivates and alienates programmers.
 - Currently D packages are not working well yet, there are bug reports  
 on this.
 - Something higher level than packages is useful when you build very  
 large systems.
 - Module system theory from ML-like languages shows many years old ideas  
 that otherwise will need to be painfully re-invented half-broken by D  
 language developers. Sometimes wasting three days reading saves you some  
 years of pain.
I'm curious (not arguing), can you provide examples? I can't think of any drastic improvements to the package system.
 I don't think this is practical until someone writes a D interpreter.
CTFE interpter is already there :-)
So you think the subset of D that's CTFE-able is good enough to make an interactive console that's actually useful? -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Vladimir Panteleev:

 I think we have a misunderstanding, then? Who ensures that the modules
 "just work"? If someone breaks something, are they thrown out of The Holy  
 Repository?
There is no single solution to such problems. It's a matter of creating rules and lot of work to enforce them as years pass. If you talk about Holy things you are pushing this discussion toward a stupid direction.
 It also demotivates and alienates programmers.
Many programmers are able to understand the advantages of removing some unnecessary freedoms. Python has shown me that brace wars are not productive :-)
 I'm curious (not arguing), can you provide examples? I can't think of any
drastic
 improvements to the package system.
I was talking about fixing bugs, improving strength, maybe later adding super-packages, and generally taking a good look at the literature about the damn ML-style module systems and their theory.
 So you think the subset of D that's CTFE-able is good enough to make an
 interactive console that's actually useful?
The built-in interpreter needs some improvements in its memory management, and eventually it may support exceptions and other some other missing things. Currently functions can't access global mutable state in the compile-time execution path, despite they don't need to be wholly pure. But in a REPL you may want to do almost everything, like mutating global variables, importing modules and opening a GUI window on the fly, etc. SO currently the D CTFE interpreter is not good enough for a console, but I think it's already better than nothing (I'd like right now a console able to run D code with the current limitations of the CTFE interpreter), it will be improved, and it may even be made more flexible to be usable both for CTFE with pure-ish functions and in a different modality for the console. This allows to have a single interpreter for two purposes. Most modern video games are partially written with a scripting language, like Lua. So a third possible purpose is to allow run-time execution of code (so the program needs the compile at run time too), avoiding the need of a Lua/Python/MiniD interpreter. Bye, bearophile
Jan 18 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 14:30:53 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:

 Vladimir Panteleev:

 I think we have a misunderstanding, then? Who ensures that the modules
 "just work"? If someone breaks something, are they thrown out of The  
 Holy
 Repository?
There is no single solution to such problems. It's a matter of creating rules and lot of work to enforce them as years pass. If you talk about Holy things you are pushing this discussion toward a stupid direction.
If a single entity controls the inclusion of submissions into an important set, then there will inevitably be conflicts. Also I still have no idea what you meant when you said that Python, Ruby and Perl do it. AFAIK their repositories are open and anyone can submit their project.
 I'm curious (not arguing), can you provide examples? I can't think of  
 any drastic
 improvements to the package system.
I was talking about fixing bugs, improving strength, maybe later adding super-packages, and generally taking a good look at the literature about the damn ML-style module systems and their theory.
I meant examples of why this is useful for D. (Why are you damning the ML-style module systems?) -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
prev sibling parent reply el muchacho <nicolas.janin gmail.com> writes:
Le 18/01/2011 13:01, Vladimir Panteleev a Ă©crit :
 On Tue, 18 Jan 2011 13:27:56 +0200, bearophile
 <bearophileHUGS lycos.com> wrote:
 
 Vladimir Panteleev:
It also demotivates and alienates programmers.
I don't believe so. I've never seen any C++ programmer who has worked on other languages like Java complain about the Java naming conventions or the obligatory one class = one file. Never. In the contrary, I believe most of them, when going back to C++, try to follow the same conventions as much as possible.
Jan 29 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 29.01.2011 21:21, schrieb el muchacho:
 Le 18/01/2011 13:01, Vladimir Panteleev a Ă©crit :
 On Tue, 18 Jan 2011 13:27:56 +0200, bearophile
 <bearophileHUGS lycos.com>  wrote:

 Vladimir Panteleev:
It also demotivates and alienates programmers.
I don't believe so. I've never seen any C++ programmer who has worked on other languages like Java complain about the Java naming conventions or the obligatory one class = one file. Never. In the contrary, I believe most of them, when going back to C++, try to follow the same conventions as much as possible.
I often find one class = one file annoying. I haven't done much with C++, but some stuff with Java and D1. I mostly agree with javas naming conventions, though. Cheers, - Daniel
Jan 29 2011
parent foobar <foo bar.com> writes:
Daniel Gibson Wrote:

 Am 29.01.2011 21:21, schrieb el muchacho:
 Le 18/01/2011 13:01, Vladimir Panteleev a Ă©crit :
 On Tue, 18 Jan 2011 13:27:56 +0200, bearophile
 <bearophileHUGS lycos.com>  wrote:

 Vladimir Panteleev:
It also demotivates and alienates programmers.
I don't believe so. I've never seen any C++ programmer who has worked on other languages like Java complain about the Java naming conventions or the obligatory one class = one file. Never. In the contrary, I believe most of them, when going back to C++, try to follow the same conventions as much as possible.
I often find one class = one file annoying. I haven't done much with C++, but some stuff with Java and D1. I mostly agree with javas naming conventions, though. Cheers, - Daniel
I just wanted to remind that the accurate Java rule was one _public_ class per file. You can have more than one class in a file as long as only one is declared public. I dunno about your experience but mine was that this is not a problem in practice, at least not for me. As usually said bout this kind of things, YMMV.
Jan 29 2011
prev sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Vladimir Panteleev wrote:

 On Tue, 18 Jan 2011 12:10:25 +0200, bearophile <bearophileHUGS lycos.com>
 wrote:
 
 Walter:

 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-
programming-language-good/
 It's a cute blog post. It suggests that it will be good to:

 Getting Code:
 1) Have a central repository for D modules that is easy to use for both
 submitters and users.
Forcing a code repository is bad. Let authors use anything that they're comfortable with. The "repository" must be nothing more than a database of metadata (general information about a package, and how to download it).
I'm pretty happy that my Fedora repositories are just a handful, most of which are setup out of the box. It's a big time saver, one of it's best features. I would use / evaluate much less software if I had to read instructions and download each package manually.
 - D code in such repository must Just Work.
This is not practical. The only practical way is to put that responsibility on the authors, and to encourage forking and competition.
True, though one of the cool things Gregor did back the days with dsss is automagically run unittests for each package in the repository and publish the results. It wasn't perfect but gave at least some indication.
Jan 18 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn  
<lutger.blijdestijn gmail.com> wrote:

 I'm pretty happy that my Fedora repositories are just a handful, most of
 which are setup out of the box. It's a big time saver, one of it's best
 features. I would use / evaluate much less software if I had to read
 instructions and download each package manually.
I don't see how this relates to code libraries. Distribution repositories simply repackage and distribute software others have written. Having something like that for D is unrealistic.
 True, though one of the cool things Gregor did back the days with dsss is
 automagically run unittests for each package in the repository and  
 publish
 the results. It wasn't perfect but gave at least some indication.
I think that idea is taken from CPAN. CPAN refuses to install the package if it fails unit tests (unless you force it to). -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Vladimir Panteleev wrote:

 On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
 <lutger.blijdestijn gmail.com> wrote:
 
 I'm pretty happy that my Fedora repositories are just a handful, most of
 which are setup out of the box. It's a big time saver, one of it's best
 features. I would use / evaluate much less software if I had to read
 instructions and download each package manually.
I don't see how this relates to code libraries. Distribution repositories simply repackage and distribute software others have written. Having something like that for D is unrealistic.
Why? It works quite well for Ruby as well as other languages.
Jan 18 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 18 Jan 2011 14:36:43 +0200, Lutger Blijdestijn  
<lutger.blijdestijn gmail.com> wrote:

 Vladimir Panteleev wrote:

 On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
 <lutger.blijdestijn gmail.com> wrote:

 I'm pretty happy that my Fedora repositories are just a handful, most  
 of
 which are setup out of the box. It's a big time saver, one of it's best
 features. I would use / evaluate much less software if I had to read
 instructions and download each package manually.
I don't see how this relates to code libraries. Distribution repositories simply repackage and distribute software others have written. Having something like that for D is unrealistic.
Why? It works quite well for Ruby as well as other languages.
Um? Maybe I don't know enough about RubyGems (I don't use Ruby but used it once or twice for a Ruby app) but AFAIK it isn't maintained by a group of people who select and package libraries from authors' web pages, but it is the authors who publish their libraries directly on RubyGems. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jan 18 2011
parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Vladimir Panteleev wrote:

 On Tue, 18 Jan 2011 14:36:43 +0200, Lutger Blijdestijn
 <lutger.blijdestijn gmail.com> wrote:
 
 Vladimir Panteleev wrote:

 On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
 <lutger.blijdestijn gmail.com> wrote:

 I'm pretty happy that my Fedora repositories are just a handful, most
 of
 which are setup out of the box. It's a big time saver, one of it's best
 features. I would use / evaluate much less software if I had to read
 instructions and download each package manually.
I don't see how this relates to code libraries. Distribution repositories simply repackage and distribute software others have written. Having something like that for D is unrealistic.
Why? It works quite well for Ruby as well as other languages.
Um? Maybe I don't know enough about RubyGems (I don't use Ruby but used it once or twice for a Ruby app) but AFAIK it isn't maintained by a group of people who select and package libraries from authors' web pages, but it is the authors who publish their libraries directly on RubyGems.
Aha, I've been misunderstanding you all this time, thinking you were arguing against the very idea of standard repository and package *format*. Then I agree, I also prefer something more decentralized.
Jan 18 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/11 6:36 AM, Lutger Blijdestijn wrote:
 Vladimir Panteleev wrote:

 On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
 <lutger.blijdestijn gmail.com>  wrote:

 I'm pretty happy that my Fedora repositories are just a handful, most of
 which are setup out of the box. It's a big time saver, one of it's best
 features. I would use / evaluate much less software if I had to read
 instructions and download each package manually.
I don't see how this relates to code libraries. Distribution repositories simply repackage and distribute software others have written. Having something like that for D is unrealistic.
Why? It works quite well for Ruby as well as other languages.
Package management something we really need to figure out for D. Question is, do we have an expert on board (apt-get architecture, cpan, rubygems...)? Andrei
Jan 18 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-18 17:29, Andrei Alexandrescu wrote:
 On 1/18/11 6:36 AM, Lutger Blijdestijn wrote:
 Vladimir Panteleev wrote:

 On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
 <lutger.blijdestijn gmail.com> wrote:

 I'm pretty happy that my Fedora repositories are just a handful,
 most of
 which are setup out of the box. It's a big time saver, one of it's best
 features. I would use / evaluate much less software if I had to read
 instructions and download each package manually.
I don't see how this relates to code libraries. Distribution repositories simply repackage and distribute software others have written. Having something like that for D is unrealistic.
Why? It works quite well for Ruby as well as other languages.
Package management something we really need to figure out for D. Question is, do we have an expert on board (apt-get architecture, cpan, rubygems...)? Andrei
I'm not an expert but I've been thinking for a while about doing a package system for D, basically RubyGems but for D. But I first want to finish (finish as in somewhat usable and release it) another project I'm working on. -- /Jacob Carlborg
Jan 19 2011
parent reply Gour <gour atmarama.net> writes:
On Wed, 19 Jan 2011 14:07:27 +0100
Jacob Carlborg <doob me.com> wrote:

 I'm not an expert but I've been thinking for a while about doing a=20
 package system for D, basically RubyGems but for D.=20
Have you thought about waf (which already has some support for D as build system) and it is intended to be build framework? (http://waf-devel.blogspot.com/2010/12/make-your-own-build-system-with-waf.= html) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 19 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-19 14:39, Gour wrote:
 On Wed, 19 Jan 2011 14:07:27 +0100
 Jacob Carlborg<doob me.com>  wrote:

 I'm not an expert but I've been thinking for a while about doing a
 package system for D, basically RubyGems but for D.
Have you thought about waf (which already has some support for D as build system) and it is intended to be build framework? (http://waf-devel.blogspot.com/2010/12/make-your-own-build-system-with-waf.html) Sincerely, Gour
Never heard of it, I'll have a look. -- /Jacob Carlborg
Jan 19 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-01-19 18:44, Jacob Carlborg wrote:
 On 2011-01-19 14:39, Gour wrote:
 On Wed, 19 Jan 2011 14:07:27 +0100
 Jacob Carlborg<doob me.com> wrote:

 I'm not an expert but I've been thinking for a while about doing a
 package system for D, basically RubyGems but for D.
Have you thought about waf (which already has some support for D as build system) and it is intended to be build framework? (http://waf-devel.blogspot.com/2010/12/make-your-own-build-system-with-waf.html) Sincerely, Gour
Never heard of it, I'll have a look.
1. it uses python, yet another dependency 2. it seems complicated -- /Jacob Carlborg
Jan 19 2011
parent reply Gour <gour atmarama.net> writes:
On Wed, 19 Jan 2011 19:40:49 +0100
Jacob Carlborg <doob me.com> wrote:

 1. it uses python, yet another dependency
True, but it brings more features over e.g. cmake 'cause you have full language on disposal.
 2. it seems complicated
Well, build systems are complex... ;) Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 20 2011
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
I missed a lot of this thread and coming in part way through may miss
lots of past nuances, or even major facts.

On Thu, 2011-01-20 at 10:19 +0100, Gour wrote:
 On Wed, 19 Jan 2011 19:40:49 +0100
 Jacob Carlborg <doob me.com> wrote:
=20
 1. it uses python, yet another dependency
=20 True, but it brings more features over e.g. cmake 'cause you have full language on disposal.
Waf and SCons (both Python based) are top of the pile in the C/C ++/Fortran/LaTeX build game, with CMake a far back third and everything else failing to finish. In the Java/Scala/Groovy/Clojure build game Gradle beats Maven beats Gant beats Ant, for the reason that Groovy beats XML as a build specification language. Internal DSLs using dynamic languages just win in this game. (Though the Scala crew are trying to convince people that SBT, a build tool written such that you use Scala code to specify the build is good. It is a priori but it has some really critical negative design issues.)
 2. it seems complicated
=20 Well, build systems are complex... ;)
Definitely. Well at least for anything other than trivial projects anyway. The trick is to make it as easy as possible to specify the complexity easily and comprehensibly. Make did this in 1978, but is not now the tool of choice. Autotools was an heroic attempt to do something based on Make. CMake likewise. SCons, Waf, and Gradle are currently the tools of choice. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 20 2011
parent reply Gour <gour atmarama.net> writes:
On Thu, 20 Jan 2011 10:13:00 +0000
Russel Winder <russel russel.org.uk> wrote:

 SCons, Waf, and Gradle are currently the tools of choice.
Gradle is (mostly) for Java-based projects, afaict? Sincerely, Gour --=20 Gour | Hlapicina, Croatia | GPG key: CDBF17CA ----------------------------------------------------------------
Jan 20 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-01-20 at 12:32 +0100, Gour wrote:
 On Thu, 20 Jan 2011 10:13:00 +0000
 Russel Winder <russel russel.org.uk> wrote:
=20
 SCons, Waf, and Gradle are currently the tools of choice.
=20 Gradle is (mostly) for Java-based projects, afaict?
It is the case that there are two more or less distinct domains of build -- JVM-oriented, and everything else. There is though nothing stopping a single build system from trying to be more universal. Sadly every attempt to date has failed for one reason or another (not necessarily technical). Basically there seems to be a positive feedback loop in action keeping the two domains separate: basically the tools from one domain don't work well on the opposite domain and so no-one uses them there, so no evolution happens to improve things. In this particular case, Gradle has great support for everything JVM-related and no real support for C, C++, Fortran, etc. All attempts to raise the profile of the Ant C/C++ compilation tasks, which Gradle could use trivially, have come to nothing. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 20 2011
parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Russel Winder wrote:

 On Thu, 2011-01-20 at 12:32 +0100, Gour wrote:
 On Thu, 20 Jan 2011 10:13:00 +0000
 Russel Winder <russel russel.org.uk> wrote:
 
 SCons, Waf, and Gradle are currently the tools of choice.
Gradle is (mostly) for Java-based projects, afaict?
It is the case that there are two more or less distinct domains of build -- JVM-oriented, and everything else. There is though nothing stopping a single build system from trying to be more universal. Sadly every attempt to date has failed for one reason or another (not necessarily technical). Basically there seems to be a positive feedback loop in action keeping the two domains separate: basically the tools from one domain don't work well on the opposite domain and so no-one uses them there, so no evolution happens to improve things. In this particular case, Gradle has great support for everything JVM-related and no real support for C, C++, Fortran, etc. All attempts to raise the profile of the Ant C/C++ compilation tasks, which Gradle could use trivially, have come to nothing.
Do you have an opinion for the .NET world? I'm currently just using MSBuild, but know just enough to get it working. It sucks.
Jan 20 2011
parent Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-01-20 at 19:24 +0100, Lutger Blijdestijn wrote:
[ . . . ]
=20
 Do you have an opinion for the .NET world? I'm currently just using MSBui=
ld,=20
 but know just enough to get it working. It sucks.=20
=20
I thought .NET was dominated by NAnt -- I have no direct personal experience, so am "speaking" from a position of deep ignorance. SCons and Waf should both work. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 21 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-20 10:19, Gour wrote:
 On Wed, 19 Jan 2011 19:40:49 +0100
 Jacob Carlborg<doob me.com>  wrote:

 1. it uses python, yet another dependency
True, but it brings more features over e.g. cmake 'cause you have full language on disposal.
I would go with a tool that uses a dynamic language as a DSL. I'm assuming you can embed the the dynamic language completely without the need for external dependencies.
 2. it seems complicated
Well, build systems are complex... ;) Sincerely, Gour
Hm, right. I was actually kind of thinking about a build tool, not a package system/tool. But it seemed complex anyway, it should be able to be quite simple. -- /Jacob Carlborg
Jan 20 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 18/01/2011 16:29, Andrei Alexandrescu wrote:
 Package management something we really need to figure out for D.
 Question is, do we have an expert on board (apt-get architecture, cpan,
 rubygems...)?

 Andrei
I agree. Having worked on Eclipse a lot, which uses OSGi as the underlying package management system, I really stand by it's usefulness. For larger projects it is chaos without it (more or less chaos depending on the particular situation). -- Bruno Medeiros - Software Engineer
Feb 04 2011
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Interestingly, my own experience with Ruby, a few years ago, was
almost 180 degrees opposite of the blogger's.

The two most frustrating aspects were documentation and deployment.
The documents were sparse and useless and deployment was the
hugest headache I've ever experienced, in great part due to Rubygems
not working properly!

They've probably improved it a lot since then, but it reinforced
my long-standing belief that third party libraries are, more often
than not, more trouble than they're worth anyway.
Jan 18 2011
parent Brad <brad.lanam.comp_nospam nospam_gmail.com> writes:
In digitalmars.D, you wrote:
 The two most frustrating aspects were documentation and deployment.
 The documents were sparse and useless and deployment was the
 hugest headache I've ever experienced, in great part due to Rubygems
 not working properly!

 They've probably improved it a lot since then, but it reinforced
 my long-standing belief that third party libraries are, more often
 than not, more trouble than they're worth anyway.
I only poked into RubyGems briefly and I had the same impression at the time. Perl's CPAN is much more mature. Much of the time, I feel as you do about 3rd party libraries. They try to do too much, are inflexible and not customizable. But many of the perl packages on CPAN are written to address a single task, are flexible and easy to use. I use several and have my favorites. Others are not worth the trouble. But this problem is going to happen to any system. Some of the packages are simply useless, poorly designed, too specific, not supported, out of date, etc. But other packages are well designed, well supported, work great. Some haven't changed in ages and work well. I think counters can help -- how many downloads, indicating popularity. How many _recent_ downloads, or a histogram of downloads by month so the user can tell if the package is out of date. Don't like the rating systems much, but that's also a possibility. An integrated bug database and forums similar to sourceforge would be very useful. You can check activity and see if the author of the package is active and keeps on top of problems. -- Brad
Jan 20 2011
prev sibling next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Jesse Phillips Wrote:
 It makes everything much clearer and creates a bunch of opportunities for
further development.
I don't see such benefit.
It's easier for the programmer to find the module if it shares the name with the file. Especially true when faced with other people's code, or code that's more than 6 months old, or just large projects. The same goes for packages and directories. The relationship is clear: each file defines a module. The natural thing would be to have them bear the same name. It lets the compiler traverse dependencies by itself. This is good for the following reasons: 1) You don't need build tools, makefiles. Just "dmd myApp.d". Do you know how many build tools there are, each trying to do the same thing. They are at disadvantage to the compiler because the compiler can do conditional compiling and generally understands the code better than other programs. There's also extra work involved in keeping makefiles current. They are just like header files are for C/C++ -- an old solution. 2) The compiler can do more optimisation, inlining, reduction and refactoring. The compiler also knows which code interacts with other code and can use that information for cache-specific optimisations. Vladimir suggested it would open the door to new language features (like virtual templated methods). Generally I think it would be good for templates, mixins and the like. In the TDPL book Andrei makes hints about future AST-introspection functionality. Surely access to the source would benefit from this. It would simplify error messages now caused by the linker. Names within a program wouldn't need to be mangled. More information about the caller / callee would also be available at the point of error. It would also be of great help to third-party developers. Static code analysers (for performance, correctness, bugs, documentation etc), packet managers... They could all benefit from the simpler structure. They wouldn't have to guess what code is used or built (by matching names themselves or trying to interpret makefiles). It would be easier for novices. The simpler it is to build a program the better. It could be good for the community of D programmers. Download some code and it would fit right in. Naming is a little bit of a Wild West now. Standardised naming makes it easier to sort, structure and reuse code.
 I'd create a branch (in git or mercury) for that task, it's quick and dirt
cheap, very easy to switch to and from, and you get the diff for free.
Right, using such tools is great. But what if you are like me and don't have a dev environment set up for Phobos, but I want to fix some module? Do I have to setup such an environment or through the file in a folder std/ just do some work on it?
You have compilers, linkers and editors but no version control system? They are generally very easy to install and use. When you have used one for a while you wonder how you ever got along without it before. In git for example, creating a feature branch is one command (or two clicks with a gui). There you can tinker and experiment all you want without causing any trouble with other branches. I usually create a new branch for every new feature. I do some coding on one, switch to another branch and fix something else. They are completely separate. When they are done you merge them into your mainline.
Jan 18 2011
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Jim Wrote:

 Jesse Phillips Wrote:
 It makes everything much clearer and creates a bunch of opportunities for
further development.
I don't see such benefit.
It's easier for the programmer to find the module if it shares the name with the file. Especially true when faced with other people's code, or code that's more than 6 months old, or just large projects. The same goes for packages and directories. The relationship is clear: each file defines a module. The natural thing would be to have them bear the same name.
Like I sad, I haven't seen this as an issue. People don't go around naming their files completely different from module name. There are just too many benefits to do it otherwise, I believe the include path makes use of this.
 It lets the compiler traverse dependencies by itself. This is good for the
following reasons:
 1) You don't need build tools, makefiles. Just "dmd myApp.d". Do you know how
many build tools there are, each trying to do the same thing. They are at
disadvantage to the compiler because the compiler can do conditional compiling
and generally understands the code better than other programs. There's also
extra work involved in keeping makefiles current. They are just like header
files are for C/C++ -- an old solution.
This is what the "Open Scalable Language Toolchains" talk is about http://vimeo.com/16069687 The idea is that the compile has the job of compiling the program and providing information about the program to allow other tools to make use of the information without their own lex/parser/analysis work. Meaning the compile should not have an advantage. Lastly Walter has completely different reasons for not wanting to have "auto find" in the compiler. It will become yet another magic black box that will still confuse people when it fails.
 2) The compiler can do more optimisation, inlining, reduction and refactoring.
The compiler also knows which code interacts with other code and can use that
information for cache-specific optimisations. Vladimir suggested it would open
the door to new language features (like virtual templated methods). Generally I
think it would be good for templates, mixins and the like. In the TDPL book
Andrei makes hints about future AST-introspection functionality. Surely access
to the source would benefit from this.
No, you do not get optimization benefits from how the files are stored on the disk. What Vladimir was talking about was the restriction that compilation unit was the module. DMD already provides many of these benefits if you just list all the files you want compiled on the command line.
 It would simplify error messages now caused by the linker. Names within a
program wouldn't need to be mangled. More information about the caller / callee
would also be available at the point of error.
Nope, because the module you are looking for could be in a library somewhere, and if you forget to point the linker to it, you'll still get linker errors.
 It would also be of great help to third-party developers. Static code
analysers (for performance, correctness, bugs, documentation etc), packet
managers... They could all benefit from the simpler structure. They wouldn't
have to guess what code is used or built (by matching names themselves or
trying to interpret makefiles).
As I said, have all these tools assume such a structure. If people aren't already using the layout, they will if they want to use these tools. I believe that is how using the import path already works in dmd.
 It would be easier for novices. The simpler it is to build a program the
better. It could be good for the community of D programmers. Download some code
and it would fit right in. Naming is a little bit of a Wild West now.
Standardised naming makes it easier to sort, structure and reuse code.
rdmd is distributed with the compiler... do you have examples of poorly chosen module names, which have caused issue?
 Right, using such tools is great. But what if you are like me and don't have a
dev environment set up for Phobos, but I want to fix some module? Do I have to
setup such an environment or through the file in a folder std/ just do some
work on it?
You have compilers, linkers and editors but no version control system? They are generally very easy to install and use. When you have used one for a while you wonder how you ever got along without it before. In git for example, creating a feature branch is one command (or two clicks with a gui). There you can tinker and experiment all you want without causing any trouble with other branches. I usually create a new branch for every new feature. I do some coding on one, switch to another branch and fix something else. They are completely separate. When they are done you merge them into your mainline.
No no no, having git installed on the system is completely different from have a dev environment for Phobos. You'd have to download all the Phobos files and Druntime into their proper location and any other dependencies/issues you run into when you try and build it. Then you would need a dmd installation which used your custom test build of Phobos.
Jan 18 2011
next sibling parent reply Jim <bitcirkel yahoo.com> writes:
Jesse Phillips Wrote:
 This is what the "Open Scalable Language Toolchains" talk is about
 http://vimeo.com/16069687
 
 The idea is that the compile has the job of compiling the program and
providing information about the program to allow other tools to make use of the
information without their own lex/parser/analysis work. Meaning the compile
should not have an advantage.
Yes, I like that idea very much. I wouldn't mind having a D toolchain like that. Seems modular and nice. The point is not needing to manually write makefiles, or having different and conflicting ways to build source code. The D language itself is all that is needed for declaring dependencies by using import statements, and the compiler could very well traverse these files along the way.
 Lastly Walter has completely different reasons for not wanting to have "auto
find" in the compiler. It will become yet another magic black box that will
still confuse people when it fails.
I'm not talking about any magic at all. Just plain D semantics. Make use of it.
 2) The compiler can do more optimisation, inlining, reduction and refactoring.
The compiler also knows which code interacts with other code and can use that
information for cache-specific optimisations. Vladimir suggested it would open
the door to new language features (like virtual templated methods). Generally I
think it would be good for templates, mixins and the like. In the TDPL book
Andrei makes hints about future AST-introspection functionality. Surely access
to the source would benefit from this.
No, you do not get optimization benefits from how the files are stored on the disk. What Vladimir was talking about was the restriction that compilation unit was the module. DMD already provides many of these benefits if you just list all the files you want compiled on the command line.
I never claimed that file storage was an optimisation. The compiler can optimise better by seeing more source code (or a greater AST if you will) at compile time. Inlining, for example, can only occur within a compilation unit. I'm arguing that a file is not the optimal compilation unit. Computers today have enough memory to hold the entire program in memory while doing the compilation. It should be up to the compiler to make the best of it. If you need to manually list the files then, well, you do unnecessary labour.
 It would simplify error messages now caused by the linker. Names within a
program wouldn't need to be mangled. More information about the caller / callee
would also be available at the point of error.
Nope, because the module you are looking for could be in a library somewhere, and if you forget to point the linker to it, you'll still get linker errors.
I didn't say "no linking errors". I said simpler errors messages, as in easier to understand. It could, for example, say where you tried to access a particular function: file and line number. A linker alone cannot say that. Also, you wouldn't have to tell the linker anything other than where your libraries resides. It would find the correct ones based on their modules' names.
 It would also be of great help to third-party developers. Static code
analysers (for performance, correctness, bugs, documentation etc), packet
managers... They could all benefit from the simpler structure. They wouldn't
have to guess what code is used or built (by matching names themselves or
trying to interpret makefiles).
As I said, have all these tools assume such a structure. If people aren't already using the layout, they will if they want to use these tools. I believe that is how using the import path already works in dmd.
Standards are better than assumptions.
 No no no, having git installed on the system is completely different from have
a dev environment for Phobos. You'd have to download all the Phobos files and
Druntime into their proper location and any other dependencies/issues you run
into when you try and build it. Then you would need a dmd installation which
used your custom test build of Phobos.
It seems I misunderstood you. Of course you have to download all dependencies before you build something. Otherwise it wouldn't be a dependency, would it? How many megabytes are these, 15? Frankly, I don't see the problem. What is it really that you don't like? I'm trying to argue for less manual dependency juggling by using the specification that is already there, your source code. The second thing, I guess, is not being overly restrictive to files as compilation units. It made sense long ago, but today it is arbitrary. Remember, C/C++ even compels you to declare your symbols in a particular order -- probably because of how the parsing algorithm was conceived at the time. It's unfortunate when it becomes language specification.
Jan 18 2011
parent Adam Ruppe <destructionator gmail.com> writes:
Jim wrote:
 I never claimed that file storage was an optimisation. The compiler
 can optimise better by seeing more source code (or a greater AST if
 you will) at compile time. Inlining, for example, can only occur
 within a compilation unit. I'm arguing that a file is not the optimal
 compilation unit. Computers today have enough memory to hold the
 entire program in memory while doing the compilation. It should be up
 to the compiler to make the best of it.
Note that dmd already does this, if you pass all the files on the command line at once. My new build.d program fetches the dependency list from dmd, then compiles by passing them all at once - it's a really simple program, just adding the dependencies onto the end of the command line (and trying to download them if they don't exist). So then you wouldn't have to do it manually either.
Jan 19 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/19/2011 05:16 AM, Jesse Phillips wrote:

 This is what the "Open Scalable Language Toolchains" talk is about
 http://vimeo.com/16069687

 The idea is that the compile has the job of compiling the program and 
providing information about the program to allow other tools to make use of the information without their own lex/parser/analysis work. Meaning the compile should not have an advantage. Let us call "decoder" the part of a compiler that scans, parses, "semanticises" source code; and (syntactic/semantic) tree the resulting representation of code. What I dream of is a decoder that (on demand) spits out a data-description module of this tree. I mean a source code module --ideally in the source language itself: here D-- that can be imported by any other tool needing as input the said tree . [D is not that bad as data-desription language, thank to its nice literal notations (not comparable to Lua, indeed, but Lua was designed for that). It's also easy in D, I guess, to define proper types for the various kinds of nodes the tree would hold. D's main obstacle AFAIK is data description must all be put in the module's "static this" clause (for some reason I haven't yet understood); but we can survive that.] Denis _________________ vita es estrany spir.wikidot.com
Jan 19 2011
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Adam Ruppe Wrote:

 Vladimir Panteleev wrote:
 Your tool will just download the latest version of Y and the
 whole thing crashes and burns.
My problem is I don't see how that'd happen in the first place. Who would distribute something they've never compiled? If they compiled it, it would have downloaded the other libs already, so any sane distribution *already* has the dependent libraries, making this whole thing moot.
But if they haven't done any development on it for the last year, but the library it depends on has...
 The build tool is meant to help the developer, not the user. If
 the user needs help, it means the developer didn't do his job
 properly.
Isn't the developer the user?
 That said, the configuration file, as described in my last post,
 seems like it can solve this easily enough.
Jan 19 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Jesse Phillips wrote:
 But if they haven't done any development on it for the last year, but
 the library it depends on has...
Unless you give library authors write access to your hard drive, it doesn't matter. They can't make your old, saved version magically disappear. If you then distribute that saved version with the rest of your app or library, it Just Works for the customer. I think I'm now at the point where I've spent more time posting to this thread than I've ever spent maintaining makefiles! If I have a different perspective on this from everyone else, there's really no point talking about it further. We might as well just go our separate ways.
Jan 19 2011
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Adam Ruppe Wrote:

 Jesse Phillips wrote:
 But if they haven't done any development on it for the last year, but
 the library it depends on has...
Unless you give library authors write access to your hard drive, it doesn't matter. They can't make your old, saved version magically disappear. If you then distribute that saved version with the rest of your app or library, it Just Works for the customer.
You can have the author release packaged libraries for developers to use and the author should do this. So this begs the question of what is the repository for? Why is the tool going out to different URLs and downloading files when you are supposed to use the pre-built lib? I believe the reason for pushing a system like rubygems is not so that the original author can compile their program, it is already setup for them. The purpose is to make it easier on those that want to start contributing to the project, those that are using the library and need to fix a bug, and those that want to take over the project long after it has died. Having a standard way for which things are built, having easy access to all relevant libraries, and knowing you can find most of what you need in one place. Those are the reasons.
 I think I'm now at the point where I've spent more time
 posting to this thread than I've ever spent maintaining makefiles!
 
 If I have a different perspective on this from everyone else, there's
 really no point talking about it further. We might as well just
 go our separate ways.
Jan 19 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Jesse Phillips wrote:
 You can have the author release packaged libraries for developers
 to use and the author should do this. So this begs the question of
 what is the repository for?
It's so you have a variety of libraries available at once with minimal hassle when you are originally writing something. I really don't care about those libraries' implementation details. I just want it so when I type "import something.lib;" in my program it actually works. If something.lib's author wants to use other.thing, great, I just don't want to think about it anymore than I think about his private classes or functions.
 Why is the tool going out to different URLs and downloading files
 when you are supposed to use the pre-built lib?
The second level of downloads is an implementation detail, aiming to provide the illusion of a pre-built lib when the author didn't actually provide one. The first level of downloads (the things you actually import in your own program) are there for your own convenience. It's supposed to make this huge ecosystem of third party libraries available with the same kind of ease you get with Phobos. You just write "import std.coolness;" and it works. No downloading anything, no adding things to the command line. I want third party modules to be equally available. But, just like you don't care if Phobos uses zlib 1.3.x internally or whatever, you shouldn't care if third party modules do either. Phobos comes with "batteries included"; so should everything else.
 Having a standard way for which things are built, having easy
 access to all relevant libraries, and knowing you can find most
 of what you need in one place. Those are the reasons.
We agree here. The difference is I'm only interested in the top most layer - the modules I import myself. I couldn't care less about what those other modules import. In my mind, they are just like private functions - not my problem.
Jan 19 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Adam D. Ruppe Wrote:

 Jesse Phillips wrote:
 You can have the author release packaged libraries for developers
 to use and the author should do this. So this begs the question of
 what is the repository for?
It's so you have a variety of libraries available at once with minimal hassle when you are originally writing something. I really don't care about those libraries' implementation details. I just want it so when I type "import something.lib;" in my program it actually works. If something.lib's author wants to use other.thing, great, I just don't want to think about it anymore than I think about his private classes or functions.
Perfect, so what you want is a is a repository of pre-built packages which have all the bells and whistles you need.
 Why is the tool going out to different URLs and downloading files
 when you are supposed to use the pre-built lib?
The second level of downloads is an implementation detail, aiming to provide the illusion of a pre-built lib when the author didn't actually provide one.
And this is where things stop "just working." You are providing an illusion that isn't their. And it is one that is very fragile. You can of course ignore the issues and say the software must be maintained to support newer versions of the libraries if the feature is to work. I don't have an answer as to whether this is acceptable. The only way to find out is if a successful build tool takes this approach.
 The first level of downloads (the things you actually import in
 your own program) are there for your own convenience. It's
 supposed to make this huge ecosystem of third party libraries
 available with the same kind of ease you get with Phobos. You
 just write "import std.coolness;" and it works. No downloading
 anything, no adding things to the command line.
Right, and since the files are going to be downloaded you have to decide what you want to do with them. Pollute the programmers project with all the third-party libraries he imported? Save them to a location on the import path? Both of these are reasonable, but both have drawbacks. It is more common to place third-party libraries into a reusable location.
 I want third party modules to be equally available. But, just
 like you don't care if Phobos uses zlib 1.3.x internally or
 whatever, you shouldn't care if third party modules do either.
 Phobos comes with "batteries included"; so should everything else.
Yes this is generally how Windows software is developed. Linux on the other hand has had a long history of making libraries available to all those who want it. Of course it is usually only something to worry about for much larger libraries, at which point we have package managers from our OS (well some of us do).
 Having a standard way for which things are built, having easy
 access to all relevant libraries, and knowing you can find most
 of what you need in one place. Those are the reasons.
We agree here. The difference is I'm only interested in the top most layer - the modules I import myself. I couldn't care less about what those other modules import. In my mind, they are just like private functions - not my problem.
Right, unless you are making the software that is trying to hide those details from you. I think there is a fine line between the person using the libraries and the person that is adding libraries for other people. We want the barrier to entry of both to be as minimal as possible. So the question I want to put forth is what is required to be done for that library writer to commit his work for use by this magical tool? Should it be compilable without any command line flags? Should it contain all relevant code so their aren't external dependencies? Does it need to be packaged in a tar ball? Can it reside in a source repository? Does it need to be specified as an application or library? Creating such a system around your simple needs just means it won't be used when things become less simple. Creating a complex system means it won't be used if it is too hard to use or it doesn't work. DSSS seemed to provide a great amount of simplicity and power... the problem is that it didn't always work.
Jan 19 2011
parent reply Gary Whatmore <no spam.sp> writes:
Jesse Phillips Wrote:

 DSSS seemed to provide a great amount of simplicity and power... the problem
is that it didn't always work.
I always wondered what happened to that boy. He had impressive coding skills and lots of pragmatic common sense. There was at least one weakness in his persona if he left D, he was dumb enough to not realize the capability our language has now. That's just plainly stupidest thing to do wrt programming languages.
Jan 19 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/11 9:04 PM, Gary Whatmore wrote:
 Jesse Phillips Wrote:

 DSSS seemed to provide a great amount of simplicity and power... the problem
is that it didn't always work.
I always wondered what happened to that boy. He had impressive coding skills and lots of pragmatic common sense. There was at least one weakness in his persona if he left D, he was dumb enough to not realize the capability our language has now. That's just plainly stupidest thing to do wrt programming languages.
Gregor left when he started grad school, and grad school asks for all your time and then some more. http://www.cs.purdue.edu/homes/gkrichar/ Andrei
Jan 19 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.01.2011 00:54, schrieb Adam D. Ruppe:
 Jesse Phillips wrote:
 You can have the author release packaged libraries for developers
 to use and the author should do this. So this begs the question of
 what is the repository for?
It's so you have a variety of libraries available at once with minimal hassle when you are originally writing something. I really don't care about those libraries' implementation details. I just want it so when I type "import something.lib;" in my program it actually works. If something.lib's author wants to use other.thing, great, I just don't want to think about it anymore than I think about his private classes or functions.
 Why is the tool going out to different URLs and downloading files
 when you are supposed to use the pre-built lib?
Pre-built libs aren't all that useful anyway, for several reasons: 1. Templates 2. different operating systems: there would have to be pre-built libs for Windows, OSX, Linux and FreeBSD (if not even more) 3. different architectures: there would have to be pre-built libs for x86, AMD64 and, thanks to GDC and LDC, for about any platform supported by Linux.. Just provide source, so people can build their own libs from it or just compile the sources like their own source files. This can still be done automagically by the build-tool/package management. Cheers, - Daniel
Jan 20 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
 Pre-built libs aren't all that useful anyway, for several reasons:
By "pre-built" I mean all the source is in one place, so the compile Just Works, not necessarily being pre-compiled. So if you downloaded mylib.zip, every file it needs is in there. No need to separately hunt down random.garbage.0.5.3.2.tar.xz as well. Bascially, the developer can compile it on his machine. He sends me the files he used to build it all in one place. That way, it is guaranteed to work - everything needed is right there.
Jan 20 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 20.01.2011 14:48, schrieb Adam Ruppe:
 Pre-built libs aren't all that useful anyway, for several reasons:
By "pre-built" I mean all the source is in one place, so the compile Just Works, not necessarily being pre-compiled. So if you downloaded mylib.zip, every file it needs is in there. No need to separately hunt down random.garbage.0.5.3.2.tar.xz as well. Bascially, the developer can compile it on his machine. He sends me the files he used to build it all in one place. That way, it is guaranteed to work - everything needed is right there.
Ah, ok. I'd prefer a dependency-system though, so if mylib needs random.garbage.0.5.etc it should fetch it from the repository as well. So when there's a non-breaking security update to random.garbage, mylib automatically gets it upon rebuild. However, when there are breaking changes, random.garbage needs a new version (e.g. 0.6.etc instead of 0.5.etc).
Jan 20 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 However, when there are breaking changes, random.garbage needs a new
version (e.g. 0.6.etc instead of 0.5.etc). IMO the best way to do that would be to get everyone in the habit of including the version in their modules. module random.garbage.0.6; import random.garbage.0.6; That way, it is explicit, in the code itself, what you need and what the library provides. This also lets the two versions reside next to each other. Say I import cool.stuff.1.0. cool.stuff imports useless.crap.0.4. But I want useless.crap.1.0 in my main app. If they were both called just plain old "useless.crap", the two imports will probably break something when we build the whole application. But if the version is part of the module name, we can both import what we need and use it at the same time. There would be no "import useless.crap" module provided that actually does work. At best, it'd say pragma(msg, "useless.crap.1.0 is the most recent, please use it"); If the thing without version annotation actually compiles, it'll break eventually anyway, so forcing something there ensures long term usefulness. The bug fix version wouldn't need to be in the module name, since they are (ideally) forward and backward compatible. Unit tests could probably confirm that automatically.
Jan 20 2011
parent reply so <so so.do> writes:
On Thu, 20 Jan 2011 16:30:40 +0200, Adam Ruppe <destructionator gmail.com>  
wrote:

 IMO the best way to do that would be to get everyone in the habit
 of including the version in their modules.

 module random.garbage.0.6;

 import random.garbage.0.6;
Even better, we could enforce this to only module writers. module random.garbage.0.6; import random.garbage; When you compile, you have to provide a path anyhow, less hostile to user and you don't have to change the code.
Jan 20 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
 When you compile, you have to provide a path anyhow, less hostile to
 user and you don't have to change the code.
One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.)
Jan 20 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 20 Jan 2011 09:58:17 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:

 When you compile, you have to provide a path anyhow, less hostile to
 user and you don't have to change the code.
One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.)
Hm... I thought the symlink was meant to point to binary-compatible bug-fix releases. So for example, if you need libwhatever.so.4.2, you have a symlink called libwhatever.so.4 which points to the latest point revision that is binary compatible with all 4.x versions. I think you still simply link with -lwhatever, but the binary requires the .so.4 version. I have seen a lot of libs where the symlink version seems to have nothing to do with the linked-to version (e.g. /lib/libc.so.6 -> libc-2.12.1.so), that doesn't really help matters. Given that almost all Linux releases are compiled from source, it's quite possible that one OS' libwhatever.so.4 is not compiled exactly the same as your libwhatever.so.4 (and might be binary incompatible). This is definitely an issue among linuxen. -Steve
Jan 20 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-20 15:58, Adam Ruppe wrote:
 When you compile, you have to provide a path anyhow, less hostile to
 user and you don't have to change the code.
One of the things implicit in the thread now is removing the need to provide a path - the compiler can (usually) figure it out on its own. Try dmd -v and search for import lines. But requiring it on the user side just makes sense if versioning is important. Your program won't compile with a different version - you aren't importing a generic thing, you're depending on something specific. It should be explicit. (Btw, this is the big failure of Linux dynamic libraries. They started with a decent idea of having version numbers in the filename. But then they ruined it by having generic symlinks that people can use. They start using libwhatever.so when they really wanted libwhatever.so.4.2. It's a symlink on their system, so Works for Me, but if they give that binary to someone with a different symlink, it won't work. Gah.)
This is where the "bundle" tool (often used together with rails) shines. It's basically a dependency tool on top of rubygems which creates like a bubble for your application. * You specify, in a in a gemfile, all the package/libraries your application depends on, if you want to can also specify a specific version of a package. * Then when you want to deploy your application (deploy your rails site to the server) you lock the gemfile and it will create a new locked gemfile. The locked gemfile specifies the exact version of all the packages (even those you never specified a version for). * Later on the server you run "bundle install" and it will use the locked gemfile and it will install the exact same versions of the packages you had on your developer machine. -- /Jacob Carlborg
Jan 20 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-01-20 13:12, Daniel Gibson wrote:
 Am 20.01.2011 00:54, schrieb Adam D. Ruppe:
 Jesse Phillips wrote:
 You can have the author release packaged libraries for developers
 to use and the author should do this. So this begs the question of
 what is the repository for?
It's so you have a variety of libraries available at once with minimal hassle when you are originally writing something. I really don't care about those libraries' implementation details. I just want it so when I type "import something.lib;" in my program it actually works. If something.lib's author wants to use other.thing, great, I just don't want to think about it anymore than I think about his private classes or functions.
 Why is the tool going out to different URLs and downloading files
 when you are supposed to use the pre-built lib?
Pre-built libs aren't all that useful anyway, for several reasons: 1. Templates 2. different operating systems: there would have to be pre-built libs for Windows, OSX, Linux and FreeBSD (if not even more) 3. different architectures: there would have to be pre-built libs for x86, AMD64 and, thanks to GDC and LDC, for about any platform supported by Linux..
And then one library for each of the compilers (ldc, gdc and dmd), do the math and one will soon realize that this won't work. Although pre-built libraries that only work for a given platform might work.
 Just provide source, so people can build their own libs from it or just
 compile the sources like their own source files. This can still be done
 automagically by the build-tool/package management.

 Cheers,
 - Daniel
-- /Jacob Carlborg
Jan 20 2011
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 18/01/2011 05:20, Walter Bright wrote:
 http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
"I quit being a professional programmer." I usually avoid discussions and dismiss out of hand opinions about software development from those who no longer develop code (did that recently with my boss, to cut off a discussion). Mostly for time saving, it's not that I think they automatically wrong, or even likely to be wrong. Still, I read that article, and it's not bad, there are some good points. In fact, I strongly agree, in essence, with one of the things he said: That language ecosystems are what matter, not just the language itself. At least for most programmers, what you want is to develop software, software that is useful or interesting, it's not about staring at the beauty of your code and that's it. This, any language community that focuses excessively on the language only and forsakes, dismisses, or forgets the rest of the toolchain and ecosystem, will never succeed beyond a niche. (*cough* LISP *cough*) -- Bruno Medeiros - Software Engineer
Feb 04 2011
next sibling parent so <so so.do> writes:
 "I quit being a professional programmer."

 I usually avoid discussions and dismiss out of hand opinions about  
 software development from those who no longer develop code (did that  
 recently with my boss, to cut off a discussion). Mostly for time saving,  
 it's not that I think they automatically wrong, or even likely to be  
 wrong.
We are still in the stone age of programming, what has changed in last 10 years? Nothing.
Feb 04 2011
prev sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/2/4 Bruno Medeiros <brunodomedeiros+spam com.gmail>:
 language ecosystems are what matter, not just the language itself. At least
 for most programmers, what you want is to develop software, software that is
 useful or interesting, it's not about staring at the beauty of your code and
 that's it.
My view is that "language ecosystems matters TOO", but it's not enough if the language itself, or the platforms it's tied to makes me grit my teeth. What good is earning lots of money, to buy the finest food, if I only have my gums left to chew it with? (Figuratively speaking, of course)
Feb 06 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bruno Medeiros:

 That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-) Bye, bearophile
Feb 04 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 02/04/2011 09:55 PM, bearophile wrote:
 Bruno Medeiros:

 That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-)
A key point is, imo, whether the eco-system grows, and how harmoniously, is completely unrelated to whether your language is "very good", or how good it is --compared to others of similar vein. I would say these are close to orthogonal dimensions, with probability close to 1 ;-) (sorry for unclear formulation, I guess you get the point anyway). Denis -- _________________ vita es estrany spir.wikidot.com
Feb 04 2011
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 04/02/2011 20:55, bearophile wrote:
 Bruno Medeiros:

 That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-) Bye, bearophile
I disagree. I think an average language with an average toolchain (I'm not even considering the whole ecosystem here, just the toolchain - compilers, debuggers, IDEs, profilers, and some other tools) will be better than a good language with a mediocre toolchain. By better I mean that people will be more willing to use it, and better programs will be created. Obviously it is very hard to quantify in a non-subjective way what exactly good/average/mediocre is in terms of a language and toolchain. But roughly speaking, I think the above to be true. The only advantage that a good language with bad toolchain has over another ecosystem, is in terms of *potential*: it might be easier to improve the toolchain than to improve the language. This might be relevant if one is still an early-adopter or hobbyist, but if you want to do a real, important non-trivial project, what you care is what is the state of the toolchain and ecosystem *now*. -- Bruno Medeiros - Software Engineer
Feb 16 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, February 16, 2011 09:23:04 Bruno Medeiros wrote:
 On 04/02/2011 20:55, bearophile wrote:
 Bruno Medeiros:
 That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-) Bye, bearophile
I disagree. I think an average language with an average toolchain (I'm not even considering the whole ecosystem here, just the toolchain - compilers, debuggers, IDEs, profilers, and some other tools) will be better than a good language with a mediocre toolchain. By better I mean that people will be more willing to use it, and better programs will be created. Obviously it is very hard to quantify in a non-subjective way what exactly good/average/mediocre is in terms of a language and toolchain. But roughly speaking, I think the above to be true. The only advantage that a good language with bad toolchain has over another ecosystem, is in terms of *potential*: it might be easier to improve the toolchain than to improve the language. This might be relevant if one is still an early-adopter or hobbyist, but if you want to do a real, important non-trivial project, what you care is what is the state of the toolchain and ecosystem *now*.
There are people who will want a better language and will be willing to go to some effort to findand use one, bet there are plenty of programmers who just don't care. They might like to have a better language, but they're not willing to go togreat lengths to find and use one. So, even if they're presented with a fnantastic language that they might like to use, if it's a pain to use due to toolchain issues or whatnot, they won't use it. Every barrier of entry reduces the number of peoplle willing to use a particular programing language. For someone to be willing to put up/work passed a particular barrier of entry, the effort has to appear to be worthwhile to them. And often, it won't take much for a particular barrier of entry to be enough for someone to not try a language which they think _might_ be much better but don't know is much better, because they've never really used it. So, until the toolchain is reasonable to your average programmer, your average programmer isn't going to use the language. Now, by no means does that mean that the toolchain is the most important aspect of getting people to use a new language, but it _does_ mean that if you want to increase your user base, you need a solid toolchain. To get your language ironed out, you need a fair-sized user base, but there's also no point in growing the user base to large sizes long before the language is even properly usable. So, I don't know what point in the development process is the best time to really be worrying about the toolchain. As it stands, D has generally worried more about getting the language right. Now that the spec is mostly frozen, the focus is shifting towards ironing out the major bugs and fixing the major wholes in the toolchain (such as the lack of support for 64-bit and shared libraries). So, D has definitely taken the approach of trying to iron out the language before ironing out the toolchain. Regardless, it's definitely true that problems with the toolchain are preventing people from using D at this point. How good the language is if you can put up with some of its problems or how good it will be once those problems are solved is irrelevant to many programmers. They want a good toolchain _now_. And when most programmers are used to dealing with toolchains with virtually no bugs (or at least not bugs that they typically run into), they're not going to put up with one with as many bugs as D's has. We're really going to need a solid toolchain for D to truly grow its user base. And we're getting there, but it takes time. Until then though, there are a lot of programmers who won't touch D. - Jonathan M Davis
Feb 16 2011
prev sibling parent retard <re tard.com.invalid> writes:
Wed, 16 Feb 2011 17:23:04 +0000, Bruno Medeiros wrote:

 On 04/02/2011 20:55, bearophile wrote:
 Bruno Medeiros:

 That language ecosystems are what matter, not just the language
 itself.
This is true, but only once your language is already very good :-) Bye, bearophile
I disagree. I think an average language with an average toolchain (I'm not even considering the whole ecosystem here, just the toolchain - compilers, debuggers, IDEs, profilers, and some other tools) will be better than a good language with a mediocre toolchain. By better I mean that people will be more willing to use it, and better programs will be created. Obviously it is very hard to quantify in a non-subjective way what exactly good/average/mediocre is in terms of a language and toolchain. But roughly speaking, I think the above to be true. The only advantage that a good language with bad toolchain has over another ecosystem, is in terms of *potential*: it might be easier to improve the toolchain than to improve the language. This might be relevant if one is still an early-adopter or hobbyist, but if you want to do a real, important non-trivial project, what you care is what is the state of the toolchain and ecosystem *now*.
Surprisingly this is exactly what I've been saying several times. I'd also like to point out that part of the potential for new languages comes from the fact that you can design much cleaner standard & de facto libs before it takes off. Some of the issues with "old" languages come from the standard utilities and libraries. It sometimes takes an enormous effort to replace those. So, 100% of the potential doesn't come from redesign of the language, it's also the redesign of tools and the ecosystem. I'm also quite sure it's a redesign every time now. There are simply too many languages already to choose from. Some examples of failed designs which are still in use: PHP's stdlib with weird parameter conventions and intensive use of globals, (GNU) C/C++ build tools, Java's wasteful (in terms of heap allocation) stdlib, C++'s thread/multicore unaware runtime, C++'s metaprogramming libraries using the terrible template model, Javascript's "bad" parts from the era when it still was a joke. However there has been a constant flux of new languages since the 1950s. I'm sure many new languages can beat Java and C++ in several ways. But in general a new language isn't some kind of a silver bullet. Advancements in language design follow the law of diminishing returns -- even though we see complex breakthroughs in type system design, better syntax and cleaner APIs, something around 5-50% better usability/productivity/safety many times isn't worth the effort. I've seen numbers that moving from procedural programming to OOP only improved the productivity about 20-40%. Moving from OOP language 1 to OOP language 2 quite likely improves the numbers a lot less. As an example, Java's toolchain and its set of available libraries are so huge that you need millions of $$$ and thousands of man years to beat it in many domains. There simply isn't any valid technical reason not to use that tool (assuming it's the tool people typically use to get the work done). If you need a low cost web site and only php hosting is available at that price, you can't do a shit with D. Some hardcore fanboy would perhaps build a PHP backend for D, but it doesn't make any sense. It's 1000 lines of PHP vs 100000 lines of D. And reclaiming the potential takes forever. It's not worth it.
Feb 16 2011