On 2013-08-19 22:18, Ramon wrote:

> An added major plus is D's bluntly straight interface to C. And a vital
> one, too, because let's face it, not being one of the major players in
> languages basically means to either not have a whole lot of major and
> important libraries or else to (usually painfully) bind them. D offers
> an excellent solution and gives me the peace of mind to not paranoically
> care about *every* important library coming with it.

You can use this tool to automatically generate bindings to C libraries:

https://github.com/jacob-carlborg/dstep

> Criticism:
>
> OK, I'm biased and spoiled by Eiffel but not having multiple inheritance
> is a major minus with me. D seems to compensate quite nicely by
> supporting interfaces. But: I'd like more documentation on that. "Go and
> read at wikipedia" just doesn't cut it. Please, kindly, work on some
> extensive documentation on that.

You can get quite close with interfaces and templates:

interface Foo
{
    void foo ();
}

template FooTrait
{
    void foo (); { writeln("foo"); }
}

class A : Foo
{
    mixin FooTrait;
}

class B
{
    void b () { }
}

class Bar : B, Foo
{
    mixin FooTrait;
}

-- 
/Jacob Carlborg

On 8/20/2013 12:02 AM, Jacob Carlborg wrote:
> On 2013-08-20 00:14, Walter Bright wrote:
>
>> Note the holding back of std.serialization until it has full support for
>> ranges.
>
> I guess we won't see any std.serialization then. It cannot fully support ranges
> until the backend does, in this case std.xml.

Why not?

On Tuesday, 20 August 2013 at 07:08:08 UTC, Jacob Carlborg wrote:
>
> You can use this tool to automatically generate bindings to C libraries:
>
> https://github.com/jacob-carlborg/dstep
>

Great stuff, Jacob! Congratulations.

One thing that is usually not mentioned in articles about D is that you don't need an IDE to develop in D. This was, if I remember it correctly, one of the design goals.

On Tuesday, 20 August 2013 at 00:08:31 UTC, Ramon wrote:
> Needing a min(), say for strings, ints and floats in a program one shouldn't end up with 3 times code but with code dealing with e.g. "any scalar" or even "anything comparable".

No matter how you cut it, you have to pay for dealing with different types in one function. Either by code-bloat or indirection. The asm for ints, floats, reals etc. are all different and require different code.

See here: http://forum.dlang.org/post/mailman.213.1376962388.1719.digitalmars-d@puremagic.com

On Tuesday, 20 August 2013 at 07:21:43 UTC, Walter Bright wrote:
> On 8/20/2013 12:02 AM, Jacob Carlborg wrote:
>> On 2013-08-20 00:14, Walter Bright wrote:
>>
>>> Note the holding back of std.serialization until it has full support for
>>> ranges.
>>
>> I guess we won't see any std.serialization then. It cannot fully support ranges
>> until the backend does, in this case std.xml.
>
> Why not?

As far as I understand the problem, current std.xml implementation does not allow to implement lazy range-based archiver in terms of Phobos.

Not however, that I have not delayed voting until std.serialization gets full support of ranges - only until its API gets support for ranges such that implementation can be later added in a non-breaking way, for example, with new archivers.

There is some small discussion on this topic. Unfortunately I had not take the time to study source deep enough to state what reasonable requirements can be here (ones that won't require Jacob to re-implelement half of the package) but I am definitely going to.

On 8/19/13, Ramon <spam@thanks.no> wrote:
>    Plus UTF, too. Even UTF-8, 16 (a very practical compromise in
> my minds eye because with 16 bits one can deal with *every*
> language while still not wasting memory).

UTF-8 can deal with every language as well. But perhaps you meant something else here.

Anyway welcome aboard!

On Tuesday, 20 August 2013 at 12:59:13 UTC, Andrej Mitrovic wrote:
> On 8/19/13, Ramon <spam@thanks.no> wrote:
>>    Plus UTF, too. Even UTF-8, 16 (a very practical compromise in
>> my minds eye because with 16 bits one can deal with *every*
>> language while still not wasting memory).
>
> UTF-8 can deal with every language as well. But perhaps you meant
> something else here.
>
> Anyway welcome aboard!

I think he meant that every "modern spoken/written" language fits in the "Basic Multilingual Plane", for which each codepoint fits in a single UTF16 code unit (2 bytes). Multiple codeunit uncodings in UTF-16 are *very* rare.

On the other hand, if you encode japanese into UTF-8, then you'll spend *3* bytes per codepoint, ergo, "wasted memory".

@ Ramon:
I think that is a fallacy:
http://en.wikipedia.org/wiki/UTF-8#Compared_to_UTF-16
Real world usage is *dominated* by ASCII chars. Unless you have a very specific use case, then, UTF8 will occupy *less* room than UTF16, even if it contains a lot of foreign characters.

Furthermore, UTF-8 is pretty much the "standard". If you keep UTF-16, you will probably end up regularly transcoding to UTF-8 to interface with char* functions.

Arguably, the "only" (IMO) usecase for UTF-16, is interfacing with windows' UCS-2 API. But even then, there'll still be some overhead, to make sure you don't have any dual-encoded in your streams.

On 20/08/13 00:00, Walter Bright wrote:
> While not unique to D, I believe that ranges will become a killer feature -
> killer enough that languages that don't support pipeline programming will start
> looking like propeller driven airliners.

On that note -- I was chatting with a (very functional- and Lisp-oriented) friend about D and, when ranges were mentioned, he immediately connected it with Clojure's concept of "sequences": http://clojure.org/sequences

Does anyone know the history/relationship here between these and D's ranges? Was it a direct influence from D, or convergent evolution -- and can anyone comment on the relative merits of the D vs. Clojure approaches?

On Tue, Aug 20, 2013 at 08:58:54AM +0200, Jacob Carlborg wrote:
> On 2013-08-19 23:17, H. S. Teoh wrote:
> 
> >Yeah, in this day and age, not having native Unicode support is simply unacceptable. The world has simply moved past the era of ASCII (and the associated gratuitously incompatible locale encodings). Neither is the lack of built-in strings (*cough*C++*cough*).
> 
> Oh, what I wish that was true. We're still struggling with encoding problems at work due to browsers and third party services and tools not being able to handle Unicode.
[...]

Well, I was referring to languages and systems invented today. Obviously there is still a large amount of legacy code that can't handle Unicode yet, but any new language or new system invented today has no excuse to not support Unicode.


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley

On Monday, 19 August 2013 at 21:19:05 UTC, H. S. Teoh wrote:
>
> scope guards. If I were granted a wish for how to lessen the pain of
> coding in C, one of the first things I'd ask for is scope.

A little OT at this point, but C Survival Kit might have you sufficiently covered:
https://github.com/chadjoan/C-Survival-Kit/blob/master/survival_kit/feature_emulation/scope.h
(Been considering pulling this in at work, too.)

-Wyatt