On 20/08/13 19:47, Walter Bright wrote:
> 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.

Since Clojure is more recent than D, and AFAICT its sequences API seems to have arrived in later versions of the language, I wondered if the influence had been in the opposite direction.

When were ranges first introduced in D?

On 8/20/2013 11:17 AM, Joseph Rushton Wakeling wrote:
> On 20/08/13 19:47, Walter Bright wrote:
>> 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.
>
> Since Clojure is more recent than D, and AFAICT its sequences API seems to have
> arrived in later versions of the language, I wondered if the influence had been
> in the opposite direction.
>
> When were ranges first introduced in D?
>

Eh, I'd have to go back through the github history :-(

The idea goes way back. Matthew Wilson and I were thinking about how to do C++ STL-like iterators, which were based on a pointer abstraction. I thought it was natural for D to do it as an array abstraction. There are some posts about it in the n.g. somewhere. The idea languished until Andrei joined us and figured out how it should work, and ranges were born.

On 8/20/2013 8:31 AM, Chris wrote:
> 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.

The idea was when a colleague of mine said that Java IDEs were great because with "one button click" one could insert "a hundred lines of boilerplate". That struck me as the IDE making up for a severe expressive deficit in the language, and that D shouldn't have such expressive deficits.

However, something like intellisense would be quite nice.

On 08/20/2013 08:17 PM, Joseph Rushton Wakeling wrote:
>
> Since Clojure is more recent than D, and AFAICT its sequences API seems
> to have arrived in later versions of the language, I wondered if the
> influence had been in the opposite direction.

Unlikely. Stream processing has a long tradition in the lisp community.
D sacrifices some of its elegance, presumably for more predictable performance.
(Though some of it could be compensated for by having a usable function in std.range that forgets the concrete range type and makes all ranges of the same element type interchangeable. inputRangeObject exists but it is not usable, and also not efficient.)

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

Programming like the 70's, yo!  :)

--
Paulo

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.

If trully you are using UTF-16 (which is what D uses), then no. UTF16 is *also* a variable width encoding. If you need random access, you should use UTF-32 (dstring). *THAT* uses a lot memory, and should only be used as an "operating" format, before storing back to UTF-8/16.

"non-variable" UTF-16 is called UCS-2 (I think). In any case, it's not what D uses.

UCS-2 being a subset of UTF-16, you can always use wstrings, and "assume" in is UCS-2, but:
* Most algorithms are UTF-16 aware, so *will* decode and walk your UCS-2 stream the slow way.
* Nothing will prevent you from accidently inserting codepoints from outside UCS-2 valid plane.

I don't recommend doint that.
Instead, you can find in std.encoding the UCSChar and UCSString data types. I haven't used these much, but it's what you should use if you are planning to store your strings in a random access wide representation.

But we digress from the original point. I'm glad you are enjoying your time with D :)

One of the things I love about D is how the *language* makes stupid constructs outright illegal (for example  "for( ... );" notice that semi-colon? yeah...)

I work full-time using C++, and about once a week, I track down a bug, and when I find it often turns out to be something stupid that D would not have allowed.

On Tue, Aug 20, 2013 at 08:57:35PM +0200, pjmp wrote:
> 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:
[...]
> >>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
> 
> Programming like the 70's, yo!  :)
[...]

LOL... to be honest, my PC "desktop" is more like a glorified terminal shell than anything else, in spite of the fact that I'm running under X11. My window manager is ratpoison, which is completely keyboard-based (hence the name), maximizes all windows by default (no tiling / overlapping), and has no window decorations. I don't even use the mouse except when using the browser or selecting text for cut/paste. (And if I had my way, I'd write a keyboard-only graphical browser that didn't depend on the mouse. I'd use Elinks instead, except that viewing images in a text terminal is rather a hassle, and there *is* a place for graphics when you need to present non-textual information -- I just don't think it's necessary when I'm dealing mostly with text anyway.)

I experimented with various ratpoison setups, and found that the most comfortable way was to increase my terminal font size so that it's approximately 80 columns wide (70's style ftw :-P), and however tall it is to fill the screen. I found that I'm most productive this way -- thanks to Vim's split-screen features and bash's backgrounding features, I find that I can do most of my work in a single terminal or two, and another background window for the browser. Since I don't even need to move my right hand to/from the mouse, I can get things done *fast* without needing a 6GHz CPU with 16GB of RAM -- a Pentium would suffice if I hadn't needed to work with CPU-intensive processes like povray renders or brute-force state space search algorithms. :)

OTOH, I find that my productivity drops dramatically when I'm confronted with a GUI. I honestly cannot stand working on Windows because of this. *Everything* depends on the mouse and traversing endless layers of nested menus just to do something simple, and almost nothing is scriptable unless specifically designed for it (which usually suffers from many limitations in how you can use it between different applications). Give me the Unix command-line any day, thank you very much.

So yes, I'm truly a relic from the 70's. ;-)


T

-- 
This sentence is false.

On 08/20/2013 06:40 PM, 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.
> ...

Yup. It is a limited, but quite well-integrated macro system.

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

Agreed. Well, it is fixable. The main issue is that templates manage to hide the problem well enough. Also, why stop there? The lambda cube has more dimensions, and those cannot be approximated that well by templates. :)

> With all due respect: Templates are an editors job, not a compilers.

Here I'd tend to disagree. Code duplication is the compiler's job.

> Yes, templates offer some gadgets beyond simple replacement but
> basically they are just a comfort thingy, relieving the programmer from
> typing.
> ...

Well, but by a similar line of though I might claim that a polymorphic type system is just a comfort thingy, relieving the programmer from manually boxing and unboxing values and performing type equality/constraint checking in his head.

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

This is one use case for templates and they allow more performance optimizations since they can actually treat some types specially.

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

It wouldn't break the ranges system.
The official justification for lack of a more expressive type system is language complexity.

> why not something like
>
> generic min(T:comparable) { // works only with comparable types/classes
>    // min magic
> }
> ...

Implicit parameters would be a more general way to deal with the 'comparable' constraint, but it's not entirely trivial to dream up a pretty scheme fitting into D.

Also, how do you implement the type comparison constraint? Requiring the whole interface to be implemented within an struct/class-type's scope implies that somewhat ugly wrapper types need to be created.

Also, you really want shortcut syntax for functions, structs etc. that does not clash with template syntax, so probably you'd use a separate kind of brackets:

T min[T:comparable](T a, T b) { return a<b?a:b; }

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

The D term is opCmp.

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

One thing that should be noted about Eiffel is that its type system is unsound by design.

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

You are usually free to express your opinions on here without anyone taking issue if you justify your statements and/or are open to discussion.

On Tuesday, 20 August 2013 at 18:48:57 UTC, Walter Bright wrote:
> On 8/20/2013 8:31 AM, Chris wrote:
>> 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.
>
> The idea was when a colleague of mine said that Java IDEs were great because with "one button click" one could insert "a hundred lines of boilerplate". That struck me as the IDE making up for a severe expressive deficit in the language, and that D shouldn't have such expressive deficits.

And this is a big big plus. In Java you cannot just write a tiny little main-function or in fact any function just to test something. You have to write an epic first. These little things do matter.

>
> However, something like intellisense would be quite nice.

Yes, I agree. But with D it's a nice-to-have not a must-have.

On Tue, Aug 20, 2013 at 08:53:02PM +0200, Timon Gehr wrote:
> On 08/20/2013 08:17 PM, Joseph Rushton Wakeling wrote:
> >
> >Since Clojure is more recent than D, and AFAICT its sequences API seems to have arrived in later versions of the language, I wondered if the influence had been in the opposite direction.
> 
> Unlikely. Stream processing has a long tradition in the lisp community.
> D sacrifices some of its elegance, presumably for more predictable
> performance.
> (Though some of it could be compensated for by having a usable
> function in std.range that forgets the concrete range type and makes
> all ranges of the same element type interchangeable.
> inputRangeObject exists but it is not usable, and also not
> efficient.)

Hmm.  Maybe something like this?

	interface GenericInputRange(E)
	{
		@property bool empty();
		@property E front();
		void popFront();
	}

	GenericInputRange!E genericInputRange(E,R)(R range)
		if (is(ElementType!R == E))
	{
		class GenericInputRangeImpl : GenericInputRange!E {
			R impl;
			this(R range) { impl = range; }
			override @property bool empty() { return impl.empty; }
			override @property E front() { return impl.front; }
			override void popFront() { impl.popFront(); }
		}
		return new GenericInputRangeImpl(range);
	}

	// insert adaptations for forward ranges, et al, here.

I think this might actually be more useful than the current std.range.inputRangeObject, since this lets you interchange ranges of different underlying types as long as their element types are the same.

Using an interface rather than a base class also lets user code adapt their own classes to work with the generic range interface.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry