On Tue, Aug 20, 2013 at 11:19:45PM +0200, Andrej Mitrovic wrote:
> On 8/20/13, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> >> http://forum.dlang.org/thread/ga46ok$2s77$1@digitalmars.com
> > [...]
> >
> > Wow. That must've been an awesome discussion. I can literally feel it oozing with excitement. :) We should put this link up on the wiki somewhere, maybe under "landmark historical documents" or something.
> 
> There's also this:
> 
> http://forum.dlang.org/thread/gacvj5$28ec$1@digitalmars.com

Also, I've found evidence that transient ranges *were* discussed before:

	http://forum.dlang.org/post/MPG.2334cabf1233057c9896e4@news.digitalmars.com

:-)

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


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

On 8/20/13, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> Sadly, the link to Andrei's presumably DDoc-generated page is no longer working.  :-(

First place too look is archive.org, here you go:

http://web.archive.org/web/20081022094123/http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html

On Tuesday, August 20, 2013 14:43:09 H. S. Teoh wrote:
> And now I know who to blame^W I mean, praise, for the names of .front and .back:

Well, those _are_ the names that the STL uses for the same thing on containers. As such, they're likely the first names that I would have come up with.

- Jonathan M Davis

On 8/20/13, H. S. Teoh <hsteoh@quickfur.ath.cx> 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

I don't know about you, but I'd be a little scared if I had to call popToe(). :P

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

I think you might enjoy https://github.com/conformal/xombrero/

snapshots here: https://opensource.conformal.com/snapshots/xombrero/ although they're a month or so old and I had to edit the URL to get there... They clearly don't want any noobs haha

I just built from source and it works very nicely, very minimalist.

On Wed, Aug 21, 2013 at 01:33:34AM +0200, John Colvin wrote:
> 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:
[...]
> >>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 think you might enjoy https://github.com/conformal/xombrero/
> 
> snapshots here: https://opensource.conformal.com/snapshots/xombrero/ although they're a month or so old and I had to edit the URL to get there... They clearly don't want any noobs haha
> 
> I just built from source and it works very nicely, very minimalist.

Interesting, I'll have to take a look at this sometime when I have some free time. Thanks!

In any case, I hope the keyboard interface isn't just something tacked on, as it's not as simple as it may look to design a keyboard interface that's efficient on a webpage, where you need to balance between navigating logical structure to find links, and providing visual navigation keys (ala Opera <=12). This is one aspect where I find Elinks lacking -- in a multicolumn layout the keys for navigating links leave a lot to be desired.


T

-- 
What doesn't kill me makes me stranger.

On Tuesday, 20 August 2013 at 23:44:37 UTC, H. S. Teoh wrote:
> On Wed, Aug 21, 2013 at 01:33:34AM +0200, John Colvin wrote:
>> I think you might enjoy https://github.com/conformal/xombrero/
>> 
>> snapshots here: https://opensource.conformal.com/snapshots/xombrero/
>> although they're a month or so old and I had to edit the URL to get
>> there... They clearly don't want any noobs haha
>> 
>> I just built from source and it works very nicely, very minimalist.
>
> Interesting, I'll have to take a look at this sometime when I have some
> free time. Thanks!
>
> In any case, I hope the keyboard interface isn't just something tacked
> on, as it's not as simple as it may look to design a keyboard interface
> that's efficient on a webpage, where you need to balance between
> navigating logical structure to find links, and providing visual
> navigation keys (ala Opera <=12). This is one aspect where I find Elinks
> lacking -- in a multicolumn layout the keys for navigating links leave a
> lot to be desired.
>

Nope. Don't worry. xombrero (formerly named "xxxterm") is seriously keyboard driven. I happen to use it because I dont want the whole web bloat. It also offers quite interesting control through a simple keyboard interface. From what I have read so far from you you gonna love it.

Shuffling your reply.

On Tuesday, 20 August 2013 at 00:08:31 UTC, Ramon wrote:
> Huh? Of course contracts are *in* the functions/methods. Typically (and reasonably) you have some kind of "in" contract and an "out" contract, the former ensuring the function to work on agreed and reasonable entry grounds, the letter ensuring that the function exits in an "O.K." state. Plus, of course invariants.

He is referring to where the compiler generates the code. When compiling a library it is at that point the contracts part of the code or not. In reality the user of the library should decide when the contracts are included (normally a debug build of a program would link a release build of the library, thus contracts would not be checked).

> I'm afraid I can't follow your "ranges making generic algorithms possible" but I do agree that ranges are among the more important strengths of D, greatly contributing to useability and productivity.

I don't think anyone takes your criticism of D generics harshly, but many, like me, may feel confused on your issue with using templates for generics.

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.

You are correct, D documentation does not touch on how to use or structure code with interfaces or classes. While I couldn't take issue with having such documentation for D, this is a subject generally left to a text book or third party article (I would expect equal difficulty learning the subject from Java documentation).

Evidence for the statement, "ranges making generic algorithms possible" can be found in std.algorithms. This module provides many algorithms to perform against data and most (all?) make use of Ranges, keeping the algorithm generic from the data type being manipulated and even the container storing that data. The library also is mostly (100%?) templated.

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.

On Tuesday, 20 August 2013 at 20:24:21 UTC, Ramon wrote:
> @Timon Gehr
>
>> Here I'd tend to disagree. Code duplication is the compiler's job.
> I get your point but I disagree.

No I disagree :)

There has been several months, or more, of research going into reusable code. Languages include things like functions, modules, and even classes to help produce code which can be shared across many applications. Some languages research polymorphic data to provide generics. To suggest that a language isn't needed to handle code duplication because an IDE can duplicate it for you is absurd.

I don't frown on copy-paste code because "it's the thing to do" or because it causes more typing. copy-paste is bad because your logic is now duplicated and requires twice (on a good day) the updates. To have the IDE do this still has the core problem. One could create a syntax for the IDE to expand the code before compilation allowing for a single location of logic... but now you've just invented a non-standard macro language that could have just been dealt with in the compiler.

On 8/21/13, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:
> I don't frown on copy-paste code because "it's the thing to do" or because it causes more typing. copy-paste is bad because your logic is now duplicated and requires twice (on a good day) the updates.

Speaking of which someone should try and make a D de-duplication project (perhaps using Dscanner[1]), which would print out all the duplicated code segments in a D codebase. I think it would be a neat thing to have.

[1] : https://github.com/Hackerpilot/Dscanner