August 20, 2013
On Tue, Aug 20, 2013 at 11:19:27AM +0200, Chris wrote:
> 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.

Was it a design goal? If so, kudos to Walter. :) Because one of my criteria for a better programming language when I decided that I was fed up with C++ and needed something better, was that it must not have undue reliance on an IDE or some other external tool to be usable. Thus, Java was disqualified (too much boilerplate that can't be adequately handled without an IDE -- of course, there were other factors, but this was a big one). It must be usable with just a text editor and a compiler. D fit that criterion rather nicely. :)


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.
August 20, 2013
On Tuesday, 20 August 2013 at 14:35:19 UTC, H. S. Teoh wrote:
> On Tue, Aug 20, 2013 at 11:19:27AM +0200, Chris wrote:
>> 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.
>
> Was it a design goal? If so, kudos to Walter. :) Because one of my
> criteria for a better programming language when I decided that I was fed
> up with C++ and needed something better, was that it must not have undue
> reliance on an IDE or some other external tool to be usable. Thus, Java
> was disqualified (too much boilerplate that can't be adequately handled
> without an IDE -- of course, there were other factors, but this was a
> big one). It must be usable with just a text editor and a compiler. D
> fit that criterion rather nicely. :)
>
>
> T

I don't know if it's still on the website here somewhere. But I remember reading (2 years or so ago) that D shouldn't require a big IDE but should be manageable using a text editor and a compiler. And it is true. So far, I haven't used an IDE for my D programming.
August 20, 2013
Yes and no.
While UTF-8 almost always is the most memory efficient representation of anything beyond ASCII it does have a property that can be troublesome a times, the difference between length and size of a string, i.e. the number of "characters" vs. the number of bytes used.

---

As for another issue I'm getting more and more disappointed: generics.

To put (my mind) bluntly, D does *not* support generics but rather went into the same ugly trap C++ went into, albeit D handles the situation way more elegantly.

Forgive me seeming harsh here but I just wrote it in the D gui thread: Any really great solution needs a solid philosophy and very profound thinking and consistency - and here D failed bluntly (in my minds eye).

With all due respect: Templates are an editors job, not a compilers.
Yes, templates offer some gadgets beyond simple replacement but basically they are just a comfort thingy, relieving the programmer from typing.

That, however, was *not* the point about generics. They are about implementing algorithms independent of data types (as far as possible).

Now, I'm looking around at mixins and interfaces in order to somehow makeshift some kind of a halfway reasonable generics mechanism. Yuck!

Well, maybe it's my fault. Maybe I was foolish to hope for something like Eiffel but more pragmatically useful and useable, more C style and way better documented. What I seem to have found with D is a *very nice* and *way better* and considerably more useful kind of C++.

Why aren't real generics there? I mean it's not that high tech or hard to implement (leaving aside macho bla bla like "It'd break the ranges system").

why not something like

generic min(T:comparable) { // works only with comparable types/classes
  // min magic
}

This could then at *run time* work with anything that met the spec for "comparable" which basically came down to anything that offers "equ" and "gt" (and "not").

On a sidenote: It seems we are somehow trapped in between two worlds, the theoreticians and the pragmatics. Walter and his colleagues have created an astonishingly beautiful beast coming from pure pragmatic engineering, while e.g. Prof. Meyer has created a brilliant system that just happens to be factually unuseable for the majority of developers (and be it only because hardly anyone will spend some 1.000$ to get started with Eiffel).
It's as if one side a purely as engineers while the other side just didn't care sh*t about their stuff being useable and useful.

My sincere apologies if I happened to offend anyone; that was definitely not my intention.
August 20, 2013
On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:
> Yes and no.
> While UTF-8 almost always is the most memory efficient representation of anything beyond ASCII it does have a property that can be troublesome a times, the difference between length and size of a string, i.e. the number of "characters" vs. the number of bytes used.
>
> ---
>
> As for another issue I'm getting more and more disappointed: generics.
>
> To put (my mind) bluntly, D does *not* support generics but rather went into the same ugly trap C++ went into, albeit D handles the situation way more elegantly.
>
> Forgive me seeming harsh here but I just wrote it in the D gui thread: Any really great solution needs a solid philosophy and very profound thinking and consistency - and here D failed bluntly (in my minds eye).
>
> With all due respect: Templates are an editors job, not a compilers.
> Yes, templates offer some gadgets beyond simple replacement but basically they are just a comfort thingy, relieving the programmer from typing.
>
> That, however, was *not* the point about generics. They are about implementing algorithms independent of data types (as far as possible).
>
> Now, I'm looking around at mixins and interfaces in order to somehow makeshift some kind of a halfway reasonable generics mechanism. Yuck!
>
> Well, maybe it's my fault. Maybe I was foolish to hope for something like Eiffel but more pragmatically useful and useable, more C style and way better documented. What I seem to have found with D is a *very nice* and *way better* and considerably more useful kind of C++.
>
> Why aren't real generics there? I mean it's not that high tech or hard to implement (leaving aside macho bla bla like "It'd break the ranges system").
>
> why not something like
>
> generic min(T:comparable) { // works only with comparable types/classes
>   // min magic
> }
>
> This could then at *run time* work with anything that met the spec for "comparable" which basically came down to anything that offers "equ" and "gt" (and "not").

Interfaces offer runtime resolution:

interface Comparable
{

}
void doStuff(Comparable c)
{
}
will work with anything that meets the specs for comparable.

For compile time resolution you can do this

August 20, 2013
On Tuesday, 20 August 2013 at 16:49:35 UTC, QAston wrote:
> On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:
>> Yes and no.
>> While UTF-8 almost always is the most memory efficient representation of anything beyond ASCII it does have a property that can be troublesome a times, the difference between length and size of a string, i.e. the number of "characters" vs. the number of bytes used.
>>
>> ---
>>
>> As for another issue I'm getting more and more disappointed: generics.
>>
>> To put (my mind) bluntly, D does *not* support generics but rather went into the same ugly trap C++ went into, albeit D handles the situation way more elegantly.
>>
>> Forgive me seeming harsh here but I just wrote it in the D gui thread: Any really great solution needs a solid philosophy and very profound thinking and consistency - and here D failed bluntly (in my minds eye).
>>
>> With all due respect: Templates are an editors job, not a compilers.
>> Yes, templates offer some gadgets beyond simple replacement but basically they are just a comfort thingy, relieving the programmer from typing.
>>
>> That, however, was *not* the point about generics. They are about implementing algorithms independent of data types (as far as possible).
>>
>> Now, I'm looking around at mixins and interfaces in order to somehow makeshift some kind of a halfway reasonable generics mechanism. Yuck!
>>
>> Well, maybe it's my fault. Maybe I was foolish to hope for something like Eiffel but more pragmatically useful and useable, more C style and way better documented. What I seem to have found with D is a *very nice* and *way better* and considerably more useful kind of C++.
>>
>> Why aren't real generics there? I mean it's not that high tech or hard to implement (leaving aside macho bla bla like "It'd break the ranges system").
>>
>> why not something like
>>
>> generic min(T:comparable) { // works only with comparable types/classes
>>  // min magic
>> }
>>
>> This could then at *run time* work with anything that met the spec for "comparable" which basically came down to anything that offers "equ" and "gt" (and "not").
>
> Interfaces offer runtime resolution:
>
> interface Comparable
> {
>
> }
> void doStuff(Comparable c)
> {
> }
> will work with anything that meets the specs for comparable.
>
> For compile time resolution you can do this
sorry, I missclicked and then unintentionally posted this unfinished by "Send" keyboard shortcut :(
August 20, 2013
On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:
> ...

You are completely right - templates are not generics. They are, ironically, much more generic and are to solve quite a simple problem - "copy-paste", in variety of forms.

If you think it is better to have an IDE to generate boilerplate instead of compiler, I can assure you, finding supporters in this community will be quite hard.

Insisting on the idea that implementing generic data types using run-time polymorphism costs is the True Way won't help either.

Honestly, I will never use any language that implies polymorphic design for stuff like container. Not of my free will at least. And every time I remember that boxing stuff in Java I have nightmares.

You want polymorphic approach - you have tools to implement it. Interfaces, classes, suit yourself. But, please, don't try to fix what is not broken.
August 20, 2013
On Tuesday, 20 August 2013 at 16:49:35 UTC, QAston wrote:
> Interfaces offer runtime resolution:
>
> interface Comparable
> {
>
> }
> void doStuff(Comparable c)
> {
> }
> will work with anything that meets the specs for comparable.
>
> For compile time resolution you can do this

Thanks QAston for your constructive and helpful suggestion. Actually this is more or less the approach that I'm following (researching for the time being).

Actually I assume that Prof. Meyer was at that point at some time, too. He just happened, so it seems, to have figured out a way to do polymorphism right and painfree. Pragmatically this (your suggestion) pretty closely matches how one approaches it in Eiffel (but don't tell Prof. Meyer! He'll probably vehemently elaborate on theory *g).

Whatever, that's basically what I wanted. Although I have to lament somewhat that D's doc (as far as I know) doesn't point that out clearly.

Thanks.
August 20, 2013
On 8/20/2013 3:52 AM, Dicebot wrote:
> 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.

Sounds reasonable. Thanks for following up on this.
August 20, 2013
On 8/20/2013 7:21 AM, Joseph Rushton Wakeling wrote:
> 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?

This style of programming has been around at least since the Unix "pipes and filters" model. It also appears as C#'s LINQ programming style.

However, LINQ and Clojure were not direct influences on D's ranges.
August 20, 2013
On 8/20/2013 7:30 AM, H. S. Teoh wrote:
> 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.

Even back in 1999 when I started with D, it was obvious that it had to be Unicode front to back.