Re: What Makes A Programming Language Good

[retard]

Wed, 16 Feb 2011 17: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*.

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 10 lines of D. And reclaiming the potential 
takes forever. It's not worth it.

Re: What Makes A Programming Language Good

[Jonathan M Davis]

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

Re: What Makes A Programming Language Good

[Bruno Medeiros]

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

Re: What Makes A Programming Language Good

[spir]

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

Re: What Makes A Programming Language Good

[Gour]

On Mon, 07 Feb 2011 01:06:46 -0800
Walter Bright  wrote:

> I tend to learn things by fixing them :-)

Heh...this is called 'engineer'. ;)


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: What Makes A Programming Language Good

[Walter Bright]

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 :-)

Re: What Makes A Programming Language Good

[Ulrik Mikaelsson]

2011/2/4 Bruno Medeiros :
> 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)

Re: What Makes A Programming Language Good

[spir]

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

Re: What Makes A Programming Language Good

[bearophile]

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

Re: What Makes A Programming Language Good

[so]

"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.

Re: What Makes A Programming Language Good

[Bruno Medeiros]

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

Re: What Makes A Programming Language Good

[Bruno Medeiros]

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

Re: What Makes A Programming Language Good

[foobar]

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
> >>   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. 

Re: What Makes A Programming Language Good

[Daniel Gibson]

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
  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

Re: What Makes A Programming Language Good

[el muchacho]

Le 18/01/2011 13:01, Vladimir Panteleev a écrit :
> On Tue, 18 Jan 2011 13:27:56 +0200, bearophile
>  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.

Re: What Makes A Programming Language Good

[el muchacho]

Le 19/01/2011 20:20, Nick Sabalausky a écrit :
> "nedbrek"  wrote in message 
> news:ih6o0g$2geu$1...@digitalmars.com...
>>
>> "Vladimir Panteleev"  wrote in message 
>> news:op.vpjlwrletuz...@cybershadow.mshome.net...
>>> On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings  
>>> 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.

Re: What Makes A Programming Language Good

[el muchacho]

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.

Re: Build tools (was: What Makes A Programming Language Good)

[Russel Winder]

On Thu, 2011-01-20 at 19:24 +0100, Lutger Blijdestijn wrote:
[ . . . ]
> 
> 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. 
> 

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.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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

Re: What Makes A Programming Language Good

[Jacob Carlborg]

On 2011-01-20 10:19, Gour wrote:

On Wed, 19 Jan 2011 19:40:49 +0100
Jacob Carlborg  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

Build tools (was: What Makes A Programming Language Good)

[Lutger Blijdestijn]

Russel Winder wrote:

> On Thu, 2011-01-20 at 12:32 +0100, Gour wrote:
>> On Thu, 20 Jan 2011 10:13:00 +
>> Russel Winder  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. 

Re: What Makes A Programming Language Good

[Steven Schveighoffer]

On Thu, 20 Jan 2011 09:58:17 -0500, 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.)


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

Re: What Makes A Programming Language Good

[Adam Ruppe]

> 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.)

Re: What Makes A Programming Language Good

[so]

On Thu, 20 Jan 2011 16:30:40 +0200, Adam Ruppe   
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.

Re: What Makes A Programming Language Good

[Adam Ruppe]

> 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.

Re: What Makes A Programming Language Good

[Daniel Gibson]

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).

Re: What Makes A Programming Language Good

[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.

Re: What Makes A Programming Language Good

[Daniel Gibson]

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

Re: What Makes A Programming Language Good

[Russel Winder]

On Thu, 2011-01-20 at 12:32 +0100, Gour wrote:
> On Thu, 20 Jan 2011 10:13:00 +
> Russel Winder  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.  

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: What Makes A Programming Language Good

[Gour]

On Thu, 20 Jan 2011 10:13:00 +
Russel Winder  wrote:

> SCons, Waf, and Gradle are currently the tools of choice.

Gradle is (mostly) for Java-based projects, afaict?


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: What Makes A Programming Language Good

[Russel Winder]

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  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.

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
> 
> 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.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: What Makes A Programming Language Good

[Gour]

On Wed, 19 Jan 2011 19:40:49 +0100
Jacob Carlborg  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

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: What Makes A Programming Language Good

[Brad]

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

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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

Re: What Makes A Programming Language Good

[Andrei Alexandrescu]

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

Re: What Makes A Programming Language Good

[nedbrek]

"Nick Sabalausky"  wrote in message 
news:ih7dj0$s4j$1...@digitalmars.com...
> "nedbrek"  wrote in message 
> news:ih6o0g$2geu$1...@digitalmars.com...
>>
>> "Vladimir Panteleev"  wrote in message 
>> news:op.vpjlwrletuz...@cybershadow.mshome.net...
>>> On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings 
>>>  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

Re: What Makes A Programming Language Good

[Gary Whatmore]

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.

Re: What Makes A Programming Language Good

[Jesse Phillips]

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.

Re: What Makes A Programming Language Good

[Jesse Phillips]

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.

Re: What Makes A Programming Language Good

[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?

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.

Re: What Makes A Programming Language Good

[Jesse Phillips]

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.

Re: What Makes A Programming Language Good

[Mafi]

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

Re: What Makes A Programming Language Good

[Adam Ruppe]

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.

Re: What Makes A Programming Language Good

[Adam Ruppe]

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.

Re: What Makes A Programming Language Good

[Jesse Phillips]

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.

Re: What Makes A Programming Language Good

[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. :)

Re: What Makes A Programming Language Good

[Adam Ruppe]

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.

Re: What Makes A Programming Language Good

[retard]

Wed, 19 Jan 2011 20:01:28 +, 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.

Re: What Makes A Programming Language Good

[Adam Ruppe]

> 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.

Re: What Makes A Programming Language Good

[Vladimir Panteleev]

On Wed, 19 Jan 2011 21:41:47 +0200, 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.


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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: What Makes A Programming Language Good

[retard]

Wed, 19 Jan 2011 19:41:47 +, 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.

Re: What Makes A Programming Language Good

[bearophile]

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

Re: What Makes A Programming Language Good

[Adam Ruppe]

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.

Re: What Makes A Programming Language Good

[retard]

Wed, 19 Jan 2011 13:56:17 +, 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.

Re: What Makes A Programming Language Good

[Nick Sabalausky]

"spir"  wrote in message 
news:mailman.710.1295434677.4748.digitalmar...@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"). 

Re: What Makes A Programming Language Good

[Nick Sabalausky]

"nedbrek"  wrote in message 
news:ih6o0g$2geu$1...@digitalmars.com...
>
> "Vladimir Panteleev"  wrote in message 
> news:op.vpjlwrletuz...@cybershadow.mshome.net...
>> On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings  
>> 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;

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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 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

Re: What Makes A Programming Language Good

[Jacob Carlborg]

On 2011-01-19 14:39, Gour wrote:

On Wed, 19 Jan 2011 14:07:27 +0100
Jacob Carlborg  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

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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

Re: What Makes A Programming Language Good

[Andrei Alexandrescu]

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

Re: What Makes A Programming Language Good

[Adam Ruppe]

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.

Re: What Makes A Programming Language Good

[Daniel Gibson]

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

Re: What Makes A Programming Language Good

[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.

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.

Re: What Makes A Programming Language Good

[Adam Ruppe]

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.

Re: What Makes A Programming Language Good

[Gour]

On Wed, 19 Jan 2011 14:07:27 +0100
Jacob Carlborg  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

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: What Makes A Programming Language Good

[spir]

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

Re: What Makes A Programming Language Good

[nedbrek]

"Vladimir Panteleev"  wrote in message 
news:op.vpjlwrletuz...@cybershadow.mshome.net...
> On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings  
> 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

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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
 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

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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
 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

Re: What Makes A Programming Language Good

[Vladimir Panteleev]

On Wed, 19 Jan 2011 12:57:42 +0200, spir  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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: What Makes A Programming Language Good

[Daniel Gibson]

Am 19.01.2011 07:35, schrieb Vladimir Panteleev:

On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings  wrote:


On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:

On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings
 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.

Re: What Makes A Programming Language Good

[bearophile]

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

Re: What Makes A Programming Language Good

[spir]

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

Re: What Makes A Programming Language Good

[spir]

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

Re: What Makes A Programming Language Good

[Vladimir Panteleev]

On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings   
wrote:



On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:

On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings
 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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: What Makes A Programming Language Good

[Austin Hastings]

On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:

On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings
 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

Re: What Makes A Programming Language Good

[Andrei Alexandrescu]

On 1/18/11 11:37 PM, Vladimir Panteleev wrote:

On Tue, 18 Jan 2011 22:17:08 +0200, Walter Bright
 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

Re: What Makes A Programming Language Good

[Jim]

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.

Re: What Makes A Programming Language Good

[Vladimir Panteleev]

On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings   
wrote:



None of them worked.


Most of those build utilities do exactly what make + your perl-foo do.

--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: What Makes A Programming Language Good

[Vladimir Panteleev]

On Tue, 18 Jan 2011 22:17:08 +0200, Walter Bright  
 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,
 Vladimirmailto:vladi...@thecybershadow.net

Re: What Makes A Programming Language Good

[Austin Hastings]

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

Re: What Makes A Programming Language Good

[Jesse Phillips]

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 complete

Re: What Makes A Programming Language Good

[Jim]

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.

Re: What Makes A Programming Language Good

[Nick Sabalausky]

"Thias"  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")

Re: What Makes A Programming Language Good

[Jesse Phillips]

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.

Re: What Makes A Programming Language Good

[Thias]

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

Re: What Makes A Programming Language Good

[Jim]

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.

Re: What Makes A Programming Language Good

[Walter Bright]

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.

Re: What Makes A Programming Language Good

[Walter Bright]

Andrej Mitrovic wrote:

On 1/18/11, Walter Bright  wrote:

You can put
hundreds if you like.


DMD can, but Optlink can't handle long arguments.


Example?

Re: What Makes A Programming Language Good

[Walter Bright]

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.

Re: What Makes A Programming Language Good

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:ih4p4o$1r1o$1...@digitalmars.com...
> "Trass3r"  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.
>
> 

Re: What Makes A Programming Language Good

[Nick Sabalausky]

"Trass3r"  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.

Re: What Makes A Programming Language Good

[Jacob Carlborg]

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

Re: What Makes A Programming Language Good

[Adam Ruppe]

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!

Re: What Makes A Programming Language Good

[Daniel Gibson]

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).

Re: What Makes A Programming Language Good

[bearophile]

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

Re: What Makes A Programming Language Good

[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

Re: What Makes A Programming Language Good

[Jim]

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.

Re: What Makes A Programming Language Good

[Trass3r]

> 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.