Dan wrote:
> Alexander Panek Wrote:
> [...]
> You obviously were quite offended by this line of thought.

Might be. The reason for this may lie in the circumstances of my "career" as a programmer. I'm not attending university yet, I am just having my last year's finals at school. This means, problems of academic level are just new to me, but I'm constantly gaining bits of knowledge how to achieve different kinds of goals. However, I love beautifully designed systems in general, solving problems in the most elegant way. This *may* involve implementing a sorting algorithm at times, to achieve the goal of providing an elegant solution for a given problem. Yet, this is not an every-day obstacle. Good programmers are not anymore those, who can write the fastest algorithms with as few lines as possible, using almost no memory.. programming is more than that.

In fact, it's not programming alone. I've attended a school for Electrical Engineering the last five years, where I've learned different kinds of ways to solve problems. There are mathematical ways, graphical ways, weirdo-graphical ways (yea.. VBA-like :P), semi-mathematical ways and analog electronic that can achieve what you want. Still, it's not the knowledge in detail alone that makes a good EE, it's the knowledge of what tools and environments are available that makes a good engineer, in general. Apart from that.. I think programmers, and engineers in general are the laziest people you can find, when it comes to solutions, but that doesn't make them bad engineers.

Kind regards,
Alex

Lars Ivar Igesund Wrote:

> Dan wrote:
> 
> > 
> > I just use phobos.  It gets the job done, instead of trying to be everything and anything the user might possibly want to interact with; like the Java libraries.
> > 
> > I find the Java libraries are so freakin' huge and multipurpose that they couldn't possibly be even close to efficient or practical for any one solution.
> > 
> > Likewise I fear for Tango, as it's got that OO gleam in it's eye and is implementing classes for crypto.. I mean.. crypto!?  What's next, a math class?  *shudders*
> 
> Seriously, classes don't inherently mean in-efficient as you seem to believe. Tango puts it's pride in being an efficient library, and if it is provably slower than other solutions, whether they are OO or procedural, then we would like to know, as it is most likely a bug. Note that the overhead with classes most often are related to the allocation cost. In very many cases, when it makes sense to keep the ojbect a live for a period, keeping state can you help you make many operations more efficient than if they had to be done repeatedly through a free function, quickly overcoming the initial allocation cost. This also often leads to easier overall use. Then you have the cases where the related operations (especially disk IO) are so expensive in itself, that whether classes are used or not, won't be noticed in the grand scheme of things. They may however ease use through encapsulation.
> 
> As for the String class; Yes, Tango has one, but do also have free functions for the same operations, and in most cases we provide versions that do not induce heap activity.
> 
> Additionally we try to design the library to be flexible and easy to use, and coherent with itself. We even worry about binary sizes.

~~

That's respectable.

On that note, I think I'll examine the Tango sources.  Whomever is working on Tangobos is definitely doing us all a favor.

So if I could demonstrate that many (if not all) of these implementations should really be using a struct for strictly performance reasons, for example, would that have any weight?

I find that structs tend to be able to do alot in D, with Interfaces being the only remaining thing I miss.

freeagle wrote:
> And majority of people will tell you that only one instance of FreeBSD is a better thing than hundreds of instances of linux

Me included.  But that's OT.

The things about a "standard library".. first of all, it's "standard", second, it's singular.

I want to (eventually) use D on the PS3.  If you've got some giant standard library, then porting it to new platforms becomes burdensome. Welcome to smelly town.

In my job, we don't need tons of library support.  Basic math, basic containers, basic algorithms.  As a matter of fact, we (and about a billion other people) have been using C and C++ and the associated (relatively small other than that iostreams crap) stdlibs for a long time now.  Crypto in the standard library?  NFW!

KISS guys, KISS..  why not retarget Tango as an addition to Phobos? Something more kitchen-sink'ish?  (ala Python)

Community or not, it's Walter's language.  Luckily for us, Walter is really freakin' smart about this kind of stuff, and he'll decide, and we'll all thank him for it.

--Steve

Dan Wrote:
> On that note, I think I'll examine the Tango sources.  Whomever is working on Tangobos is definitely doing us all a favor.

Oh my...

I went through tango.core.Array and tango.math.Math and personally found several rather junior mistakes like:

int abs(int x){
  return x > 0? x : -x;
 // should be: return x &= 0x7FFF_FFFF;
}

and all sorts of template mess in Array and String just to implement things like find as well as several equivalents to opAssign, opAdd, opCat etc.

I spent three minutes quickly trying out a template that could implement find on an array of any type using delegates or functions, as well as trying to remember what an operator overload would be classified as; and to be honest I did find it somewhat disorienting so I can understand that part.

I wonder if Phobos is likewise written...

Dan wrote:
> 
> So if I could demonstrate that many (if not all) of these implementations should really be using a struct for strictly performance reasons, for example, would that have any weight?

Certainly, it would definately be an interesting excercise.

> 
> I find that structs tend to be able to do alot in D, with Interfaces being the only remaining thing I miss.

We do have some classes that we are aware would fit better as a struct, but the lack of struct constructors prevent that for now. Similarly, lack of an interface notion prevents some usages.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Stephen Waits wrote:
> freeagle wrote:
>> And majority of people will tell you that only one instance of FreeBSD is a better thing than hundreds of instances of linux
> 
> Me included.  But that's OT.
> 
> The things about a "standard library".. first of all, it's "standard", second, it's singular.
> 
> I want to (eventually) use D on the PS3.  If you've got some giant standard library, then porting it to new platforms becomes burdensome. Welcome to smelly town.
> 
> In my job, we don't need tons of library support.  Basic math, basic containers, basic algorithms.  As a matter of fact, we (and about a billion other people) have been using C and C++ and the associated (relatively small other than that iostreams crap) stdlibs for a long time now.  Crypto in the standard library?  NFW!

Then don't port the crypto functions.  Seems like the obvious answer. I'm sure Phobos also has plenty of stuff you won't need.  Whichever you go with, just port the parts you need.

> KISS guys, KISS..  why not retarget Tango as an addition to Phobos? Something more kitchen-sink'ish?  (ala Python)

> Community or not, it's Walter's language.  Luckily for us, Walter is really freakin' smart about this kind of stuff, and he'll decide, and we'll all thank him for it.

It's pretty clear that Walter would prefer other people to take over the job of library design so he can concentrate on what he does best: compiler design.  But it seems clear also that he wants to keep Phobos around as a place where he can dump in little additions now and then, like std.metastrings.

I wonder if there might be some benefits to separating phobos and tango both out into a core lib containing only the barest essentials required to run D code (e.g. object and gc and not much else), and everything else.  Seems like it would be helpful in your case, at least.  It would seem somehow reassuring to me to be able to clearly see what's essential and what's optional.  But in the end the linker should discard whatever you don't use, so, from a practical standpoint, it's not so necessary.

--bb

Dan wrote:
> 
> Oh my...
> 
> I went through tango.core.Array and tango.math.Math and personally found several rather junior mistakes like:
> 
> int abs(int x){
>   return x > 0? x : -x;
>  // should be: return x &= 0x7FFF_FFFF;
> }

...

That's *so* wrong...
You may want to save yourself some embarrassment by checking code before you post it here:
=====
$ cat test.d
import std.stdio;

int abs(int x) {
    return x &= 0x7fff_ffff;
}

void main() {
    writefln(abs(-2));
}
$ dmd -run test.d
2147483646
=====
hint: abs(-2) != 2147483646 :P

(Most computers use a representation called "two's complement" to store signed integers. See http://en.wikipedia.org/wiki/Two's_complement for details)


Though returning an _unsigned_ integer instead of a signed one would arguably improve the "abs" function. (Try calling the current version with int.min to see what I mean)

Bill Baxter wrote:

> I wonder if there might be some benefits to separating phobos and tango both out into a core lib containing only the barest essentials required to run D code (e.g. object and gc and not much else), and everything else.  Seems like it would be helpful in your case, at least.  It would seem somehow reassuring to me to be able to clearly see what's essential and what's optional.  But in the end the linker should discard whatever you don't use, so, from a practical standpoint, it's not so necessary.

This is what Tango already do. Tango's phobos.lib is just the language essentials. The only external interface coming from there is for the GC, threading and Object.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Dan wrote:
> 
> I went through tango.core.Array and tango.math.Math and personally found several rather junior mistakes like:
> 
> int abs(int x){
>   return x > 0? x : -x;
>  // should be: return x &= 0x7FFF_FFFF;
> }
> 
> and all sorts of template mess in Array and String just to implement things like find as well as several equivalents to opAssign, opAdd, opCat etc.
> 
> I spent three minutes quickly trying out a template that could implement find on an array of any type using delegates or functions, as well as trying to remember what an operator overload would be classified as; and to be honest I did find it somewhat disorienting so I can understand that part.

You're welcome to submit suggestions if you think the current implementation can be improved.  Please note that any array routine must work for array literals, static arrays, and dynamic arrays, that duplicate generated code should be avoided whenever possible, and any default predicate should have its code inlined.  Also, predicate support must allow for any callable type, not just delegates and functions.


Sean

== Quote from Lars Ivar Igesund (larsivar@igesund.net)'s article
> Bill Baxter wrote:
> > I wonder if there might be some benefits to separating phobos and tango both out into a core lib containing only the barest essentials required to run D code (e.g. object and gc and not much else), and everything else.  Seems like it would be helpful in your case, at least.  It would seem somehow reassuring to me to be able to clearly see what's essential and what's optional.  But in the end the linker should discard whatever you don't use, so, from a practical standpoint, it's not so necessary.
> This is what Tango already do. Tango's phobos.lib is just the language essentials. The only external interface coming from there is for the GC, threading and Object.

Okay, but we can't mix-and-match the "core" of Tango with the "core" of Phobos since Phobos hasn't been broken apart (DMD's phobos.lib contains the language essentials and fun extra stuff, too). Can we just use the tango source with the standard phobos.lib? I wouldn't think that we could since object is defined differently and parts of Tango probably depend on the GC changes that Sean has made.  (Or is this what the "PhobosCompatibility" version is for?)

Maybe it's time to try to convince Walter to separate Phobos into at least two parts to make it easier for us to plug-in our own GC, etc.

In the meantime, I'll probably be using tangobos (http://www.dsource.org/projects/tangobos) rather than kicking the Phobos habit cold turkey.