On 20/08/13 22:43, Andrei Alexandrescu wrote:
> It's a common omission to equate D's ranges with pipes/filters. That misses the
> range categorization, which is inspired from C++ iterators.
>
> A relatively accurate characterization of D ranges is a unification of C++
> iterators with pipes/filters.

I'm not sure I quite follow this point.  The Clojure sequence API has all the stuff you'd expect from the range interface -- empty?, first (front), next (popFront), nnext (popFrontN), last (back), drop-last (popBack), ...

Is the point here that in Clojure these are all implemented as pipes/filters on top of singly-linked lists, whereas in D range interfaces are a "first-class" part of the language that is agnostic about the underlying data structures?

On 20/08/13 23:43, H. S. Teoh wrote:
> And now I know who to blame^W I mean, praise, for the names of .front
> and .back:
>
> 	http://forum.dlang.org/post/gaf59c$on7$1@digitalmars.com
>
> In any case, I'm impressed by the sheer volume of bikeshedding going on
> in that thread! It almost puts to shame our rainbow-free discussions
> these days. :-P

Fantastic to get this insight into D's history. :-)

On Wednesday, 21 August 2013 at 05:41:40 UTC, Jesse Phillips
wrote:
> Personally I'm not familiar with Eiffel or some of the more eccentric polymorphic functions. I know my templates, Java/C# generics and object base polymorphic behavior.

Finally someone says it honestly, frankly and straight out.
Thank you for that. I mean it.

And I understand you perfectly well. Having quired a considerable
amount of knowledge and experience with a language one , of
course, tends to develop a certain relationship and a habit to
understand every (programming related) problem as "How could tat
be done in 'my' language?"

This goes further than we sometimes (like to) see. The
"Polymorphism is bad/troublesome" credo, for instance, has
basically nothing to do with polymorphism and pretty everything
with C++'s attempt at it.

We may like it or not but language designers, being human beings,
have beliefs, intentions and goals when creating a language. And
it's no secret; after all this mix (of beliefs, goals, etc.) is a
major driving force to energize the tedious process. D's creators
spell it out quite frankly and it comes down to something like
"To create the language C and C++ should have been".

Please note that I do not judge that as good, bad or whatever
and, in fact, I do agree that this is actually a constructive and
valid approach.

There are even people around who created (usually script)
languages with games in mind.

Ada didn't need such a kind of belief/goal mix; it was put right
in front of them by the usa dod. One, probably *the* major issue
was reliability, correctness and, if any feasible, verifyability.

And this mind- and goalset very much shapes the outcome. That is
why in Ada ':=' is used as assignment operator while in C, C++
and D '=' is used.

And then there is Eiffel, which is very interesting if for one
issue alone: It's creator wanted to create "The whole process
from design down to code right". And, unlike what many think,
Prof Meyer/Eiffel *does* care about practical aspects.

I myself was turned off by Ada's and Eiffel's (and Pascal's and
its derivates) use of ':=' for assigment (which on a german
keyboard is even more unpleasant than on a querty version).
Until I read real world statistics (which well matched my own
experience) that showed how error prone the '=' way is.

The killer argument, however, (in my case) was delivered by Prof.
Meyer in a statement along the line "It doesn't matter how fast
your code is if it breaks"

Reading through this forum, however, "performance" and not doing
anything that might negatively influence performce is what Mother
Mary is to Christians, very very holy.

Again, this mindset is perfectly valid and OK. But one should at
least be really and seriously conscious of it.

Polymorphism, for instance, *can* be done and done well, up to
the point of being a treasure trove and a realiable and efficient
was to do things.
It will, however, never even being seriously considered by a
C/C++ mindset considering it evil and whatnot.

To be frank, I will try to find a way to use D (which I still
consider a great language!) in a rather ignorant and Eiffel-like
way, as well as this can be done (Yes, I will even use ':=' and
have it auto-replaced before compiling).

For two simple reasons: Probably I'm to "rotten" to happily use
anything else than a modern C family Language (D) but I'm not
willing to simply forget what important lessons I learned while
wandering through other parts of the programming world.
The second reason is that D (for my personal taste) is too C/C++
in the sense of a "Well, paint something here, glue something on
top there". I read again and again how elegant and well readable
D is. Sorry, no, it isn't, or, to be more correct, it is only if
seen from someone who has been exposed to (and/or possibly likes)
C/C++ cryptic (~non natural for a human) looks.

Funnily one thing I particularly love with D, the "scopes", is
something I know - less well done than in D - from Eiffel and
which is credo of mine since long: Forget the f*cking "try"!.
Either be honestly careless )"Hey, it's just an unimportant
script kind a thingy") or - very reasonably - assume that pretty
everything can go wrong. "try" somehow (stupidly, I feel) implies
that there is "innocent" code and "potentially dangerous" code.
BS! On a modern system with zillions sloc written by thousands of
varying levels of professionality *nothing* can be assumed to be
innocent.

> In D it tends to be idiomatic to specify what you will use and not why structure you expect. So instead of:
>
>     void foo(IComparable[] data)...
>
> We write:
>
>     void foo(Range)(Range data) if(isComparable!(ElementType!Range))...
>
> Where isComparable would need to be defined and ElementType can be found in std.range.
>
> So D's generics may be lacking, the ability to write generic algorithms is still there.

As long as I can have "generics" and not merely a very smart
fill-in template system - or, even better, both - I'm content
enough.

BTW: One of the reasons I'm discussing (probably to an extent
that many feel going to far) is because I know myself. It is
*now* (with some spare time and not yet deeply involved actually
using D) or never. Once I'm in everyday use mode I'll do what
pretty everyone does, namely, code by using what is there and
available; whatever I'll miss I will somehow work around, peeling
apples with spoons ...

On Wed, Aug 21, 2013 at 02:39:34PM +0200, Joseph Rushton Wakeling wrote:
> On 20/08/13 22:43, Andrei Alexandrescu wrote:
> >It's a common omission to equate D's ranges with pipes/filters. That misses the range categorization, which is inspired from C++ iterators.
> >
> >A relatively accurate characterization of D ranges is a unification of C++ iterators with pipes/filters.
> 
> I'm not sure I quite follow this point.  The Clojure sequence API
> has all the stuff you'd expect from the range interface -- empty?,
> first (front), next (popFront), nnext (popFrontN), last (back),
> drop-last (popBack), ...
> 
> Is the point here that in Clojure these are all implemented as pipes/filters on top of singly-linked lists, whereas in D range interfaces are a "first-class" part of the language that is agnostic about the underlying data structures?

His point is that C++ iterators have input/forward/bidirectional classifications, whereas the sequences in functional languages typically don't. D's ranges therefore is a sort of integration of sequences in functional languages with C++'s input/forward/bidirectional hierarchical iteration scheme.


T

-- 
Amateurs built the Ark; professionals built the Titanic.

On Wednesday, 21 August 2013 at 13:54:59 UTC, Ramon wrote:
>> So D's generics may be lacking, the ability to write generic algorithms is still there.
>
> As long as I can have "generics" and not merely a very smart
> fill-in template system - or, even better, both - I'm content
> enough.

This is the statement which throws me. Templates are generic, there is this feature called "generics" which is an implementation to provide generic functions/classes (D does not have). But the concept of making things generic is perfectly achievable with templates.

Since I don't know Eiffel I don't know the exact approach to generics you're interested in, but D provides Templates to handle generics.

D also provides Interfaces and Inheritance for polymorphism, which may be what is of interest to you, but those aren't generics.

I hope D does what you want well enough, but which how you talk of generics I just don't know what you mean. And I don't write this as an attack, only to try and explain my confusion. (maybe others can correct my understanding).

On Tuesday, 20 August 2013 at 19:41:13 UTC, H. S. Teoh wrote:
> 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

Haha, I'm the same, except with XMonad. I use tmux to separate projects, and I have xmobar running so I can watch CPU and RAM explode when I run DMD =D

I've tried using Java, but it just doesn't work in this config. Eclipse happens to suck in my WM and javac is terrible to use on the CLI for big projects (and I refuse to use Ant...). I stick to simple languages that don't need an IDE: D, Go, C, Python, Javascript, Rust, and sometimes Haskell.

I would say I'm a relic from the 70's, but I wasn't born until the 80s...

On Tuesday, 20 August 2013 at 19:41:13 UTC, H. S. Teoh wrote:
>
> I'd use Elinks instead, except that viewing images
> in a text terminal is rather a hassle

I don't really want to meddle too much in domestic matters involving a guy and his lawfully wedded config (:P), but have you tried w3m?  When I had images enabled before, it just sort of...rendered them.  Like over top of the xterm.  It was pretty cool; I think it even flowed text around them properly.

-Wyatt

On Wednesday, 21 August 2013 at 14:38:41 UTC, Jesse Phillips wrote:
> On Wednesday, 21 August 2013 at 13:54:59 UTC, Ramon wrote:
>>> So D's generics may be lacking, the ability to write generic algorithms is still there.
>>
>> As long as I can have "generics" and not merely a very smart
>> fill-in template system - or, even better, both - I'm content
>> enough.
>
> This is the statement which throws me. Templates are generic, there is this feature called "generics" which is an implementation to provide generic functions/classes (D does not have). But the concept of making things generic is perfectly achievable with templates.
>
> Since I don't know Eiffel I don't know the exact approach to generics you're interested in, but D provides Templates to handle generics.
>
> D also provides Interfaces and Inheritance for polymorphism, which may be what is of interest to you, but those aren't generics.
>
> I hope D does what you want well enough, but which how you talk of generics I just don't know what you mean. And I don't write this as an attack, only to try and explain my confusion. (maybe others can correct my understanding).

Last thing first: Yes, it seems that I can achieve a quite comfortable compromise with D.

As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language design from the beginning. In D ways and mechanisms are provided to achieve what quite usually is the goal of generics, namely generic algorithms in way, i.e. by having to write code for an algorithm just once. That might seem to be a minor difference, in particular when looking from a "Huh? I can get it done, so what's the fuss all about, eh?" perspective.
Of course, there the C and successors worlds proponents are right, this incurs a price (which templates do, too ...) and, yes, in the end, somewhere someone or something must sort the types out anyway (because of the way CPUs work).

Actually, this point shows quite nicely what I consider the *real* issue behind it. In C/C++/D it's all about performance and other technical criteria. That is one valid was to look at things, no doubts. But there are others, too.
In Eiffel (and to a degree others) it's not about technical issues and details about about design and humans. It's simply a very different approach putting less weight on performance (which is not lousy, anyway) and more on reliability, proper design etc.

Would I use Eiffel for an RTOS on a 16bit CPU? No way. Would I use C++ for a critical application, say a medical ventilator? No way!

Actually, D, no matter how much one might fight me for saying that, goes a considerable distance to languages like Ada or Eiffel. The main difference is that the D people are maniac on performance (and staying C/C++-like enough) and implement those important mechanisms (so it seems to me) for very much different reasons than Ichbiah (Ada) or Meyer (Eiffel) and much as "extensions to C/C++/D" where Meyer et al. arrived from a very different point of interest.

Another example is data types, concretely integers. Ada offers a nice way do precisely nail down precision/storage. If I want to store days_of_month I can have an integer type holding ints between 1 and 31 (which, due to the way they implemented it can be a PITA). Eiffel gives me something quite similar (in a more elegant way) and additionally a "dumb" INTEGER (32 or 64 bit) and than a gazillion subtypes like "INTEGER_16". That's great because in a quick and dirty script a plain integer (max size of CPU) is good enough and keeps life simple. If I need days_of_month I can very easily have that as int type.

Which (what is another important paradigm/philosophy issue) also touches the question "Is it all about data or about code?". A question that might seem very philosophical (and with C kind programmers tending to answer "code, of course!") but can get quickly get very pragmatic and stinking ugly when you find yourself f*cked by having to open a (e.g.) Microsoft spreadsheet created with thecurrent software version and you only have an older version ...

Again, D (and even C++) *already has understood* those problems and created e.g. generics (such going a major step toward Eiffel and Co). They just implemented it "C style" with yet another cludge grafted on the maniacally protected C heritage and philosophy. Which, seen from another point of view can be an advantage (e.g. to C++ programmers wanting to feel home right away).

Looking at it from a long term perspective ( I think) both sides will give in somewhat. Eiffel will be less ivory tower and "D++" or "E" (or possibly "F") will be less machine room minded, taking in a whole lot of Eiffel (and others) stuff, yet not forgetting embedded systems and the like.
Such a step would, btw, not be a first. It has already happened to a large degree and here in D for another "world", namely functional mechanisms and fatures.

On 2013-08-21 15:54, Ramon wrote:

> Reading through this forum, however, "performance" and not doing
> anything that might negatively influence performce is what Mother
> Mary is to Christians, very very holy.

In many areas D chooses safety or convenience before performance, compared with say C/C++. Examples:

* All variables are default initialized
* Garbage collector
* All instance methods are virtual by default

-- 
/Jacob Carlborg

On Wednesday, 21 August 2013 at 16:35:17 UTC, Jacob Carlborg wrote:
> On 2013-08-21 15:54, Ramon wrote:
>
>> Reading through this forum, however, "performance" and not doing
>> anything that might negatively influence performce is what Mother
>> Mary is to Christians, very very holy.
>
> In many areas D chooses safety or convenience before performance, compared with say C/C++. Examples:
>
> * All variables are default initialized
> * Garbage collector
> * All instance methods are virtual by default

You are right and I appreciate that progress (IMO). It does not exclude, however, a strong, sometimes possibly unbalanced, focus on performance, nor does it make the many cases vanish where performance considerations are brought up as major or even priority factor for or against diverse considerations, ideas or concepts.

I am *not* against keeping an eye on performance, by no means. Looking at Moore's law, however, and at the kind of computing power available nowadays even in smartphones, not to talk about 8 and 12 core PCs, I feel that the importance of performance is way overestimated (possibly following a formertimes justified tradition).

We need not look further than on our very desk. Basically all major OSes as well as all major software is riddled with bugs, problems, and considerable lack of security. - And - basically all major OSes and to a large degree software is written in - ? - languages of the C family. Coincidence?

Although it must be noted in fairness that D would indeed and very considerably enhance that sad situation. D has - and should be appreciated for that - made major steps towards reliability and a world with less software bugs. I can't prove that, I don't have statistics for that but I'm very confident of D allowing for more secure and reliable software being written.