www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why I chose D over Ada and Eiffel

reply "Ramon" <spam thanks.no> writes:
Frontup warning: Some of what I'll write is opinionated, not so 
much in the sense of being pro or anti (whatever) but rather 
based on experience and needs.

25+ years ago I started with C. I loved it. But then I had a 
hacker attitude, considering "raw and tough" the only choice for 
a real man *g.

It took me more than 10 years to recognize (or allow myself to 
realize) that something was quite unsatisfying about C and that, 
as much as I understood the necessity of OO and strongly desired 
io employ it,  C++ was not a solution but rather pretty much all 
disadvantages of C repeated and then a major nightmare added or, 
excuse my french, a major pain in the a**.

Even worse, software development had grown from an obsessive 
hobby (I was an electronics engineer floating more and more 
toward software) to a profession and suddenly ugly real world 
factors like efficiency and productivity entered the equation.
While tools like CodeBuilder (a C++ "Delphi") seemed to promise a 
better life they didn't deliver that much; not because they were 
bad tool but because of C++.

- big jump -

By coincidence (or fate?) I found myself confronted with a 
project demanding extreme reliability and reusability 
requirements. As much as I tried, C++ just couldn't cut it. One 
major reason might be interesting (or well known) to some of you: 
You basically can't rely in third party C++ code. Not meaning to 
talk bad about anyone but it's my bloody experience. Maybe it's 
because C++ makes it so hard to actually develop and engineer 
software (rather than hacking), maybe because C++ attracts guys 
like my earlier self (the cool C/C++ hacker), whatever the reason 
may be, that's what I experienced.

One obious (or seemingly obvious) solution was Ada. Well, no, it 
wasn't. Maybe, even probably, if I had to develop low level stuff 
for embedded stuff but not for a large application. And, that was 
a killer for me, Ada does not really support easily resizable 
arrays. To make things worse, while there nowadays is Gnat, a 
nice modern IDE, there is a major lack of libraries.

Falling over the famous Ariane 5 article I looked at Eiffel. I 
have to confess that I almost feel in love. Eiffel felt just 
right and Prof. Meyers books convinced me again and again - 
Yesss, that's the way I'd like to work and develop software.
Unfortunately, though, Prof Meyer and ISE (the Eiffel company) 
made some errors, too, and in a major way.
For a starter that whole Eiffel world is pretty much a large 
beautiful castle ... inmidst a desert. Theoretically there are 
different compilers, factually, however, ISE's Eiffelstudio is 
the only one; the others are either brutally outdated or 
non-conforming or weird niche thingies or eternally in alpha, or 
a mixture of those. And Eiffelstudio costs north of 5.000 us$. 
Sure there is a GPL version but that is available only for GPL'ed 
programs.
Next issue: Eiffels documentation is plain lousy. Yes, there are 
some 5 or so books but those are either purely theoretical or 
very outdated or both. Yes there is lots of documentation online 
but most of it basically is luring sales driven "Look how easy it 
is with Eiffel" stuff. And there is a doxygen like API doc which 
is pretty worthless for learning how to practically use the 
language.
Furthermore, while Eiffel comes with a lot on board there still 
is much missing; just as an example there are no SSL sockets 
which nowadays is a killer.

--- jump ---

So, I desperately looked for something that would offer at least 
some major goodies lik DBC and would otherwise at least not stand 
in the way of proper software engineering.

Well, that single feature, Design By Contract, led me toward D.

- practically useable modern Arrays? Check.
   And ranges, too. And very smartly thought up and designed. 
Great.
- Strings? Check
   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).
- DBC? Check
   And once more the creators of D don't simply address one issue 
but do it elegantly and, even better, sonsistently by throwing in 
a nice use cases solution, too. Great!
- some kind of reasonable support for modern concurrency? Check
   And again, not something thrown in that the creators of D 
religously consider right (like in Eiffel where Meyer basically 
force feeds his personal religious belief, although the 
"seperate" solution is elegant). Great!
- Some of the major GUI(s)? Check.
   Well, I couldn't care less about Java (Is t possible to repeat 
all C problems creating yet another "C++" and invent a whole new 
slew of burdensome and weird sh*t? Sure, look at java!) but there 
seems to be a GTK binding.
- "defer mechanism"? Check.
    I'm pondering about some smart defer mechanism since years. Et 
voilà, D offers the "scope" mechanism. Brilliant, just f*cking 
brilliant and well made, too!
- Genericity? Check
   Genericity is a must, it's one of those things I'm just not 
willing to even discuss making compromises. Frankly, I like 
Eiffel's solution better but hey, D's solution is getting pretty 
close to what I consider excellent.

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.


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.
(Probably there are some more not so great points but coming from 
a strong C background, D looks 95% "natural"; sure there are 
major differences but the creators of D have very nicely managed 
to offer an extremely comfortable approach for anyone with solid 
C experience. Probably it's more troublesome for newbies but 
that's something they should write down.).

Summary: 9 out of 10 points (using int; using double I'd make it 
9.5 *g)

Sorry, this is a long and big post. But then, so too is my way 
that led me here; long, big, troublesome. And I thought that my 
(probably not everyday) set of needs and experiences might be 
interesting or useful for some others, too.
And, of course, I confess it, I just feel like throwing a very 
big "THANK YOU" at D's creators and makers. Thank you!
Aug 19 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 19, 2013 at 10:18:04PM +0200, Ramon wrote:
[...]
 25+ years ago I started with C. I loved it. But then I had a hacker
 attitude, considering "raw and tough" the only choice for a real man
 *g.

That was me about 20 years ago too. :)
 It took me more than 10 years to recognize (or allow myself to
 realize) that something was quite unsatisfying about C and that, as
 much as I understood the necessity of OO and strongly desired io
 employ it,  C++ was not a solution but rather pretty much all
 disadvantages of C repeated and then a major nightmare added or,
 excuse my french, a major pain in the a**.

Honestly, while OO definitely has many things to offer, I think its proponents have a tendency to push things a little too far. There are things for which OO isn't appropriate, but in languages like Java, you have to shoehorn *everything* into the OO mold, no matter what. This leads to ridiculous verbosity like: // Everything has to be a class, even if there's absolutely // nothing about main() that acts like a class! class MyLousyJavaProgram { // Are you serious? All this boilerplate just to declare // the main program?! public static void main(String[] args) throws IOException { // What, this long incantation just to print // "Hello, world!"?? System.err.println("Hello world!"); } } The signal-to-noise ratio in this code is about 1 : 6 (1 line of code that actually does the real work, 6 lines of boilerplate). Compare the equivalent D program: import std.stdio; void main() { writeln("Hello world!"); } Even C isn't as bad as the Java in this case. But I digress. Coming back to the point, C++ tries to do OO but fails miserably because it insisted on backward-compatibility with C. This was a smart move in the short term, since it helped C++ adoption from the hordes of C coders at the time, but in the long run, this has hurt C++ so much by making it impossible to fix some of the fundamental design mistakes that leads to C++ being the ugly monstrosity it is today. [...]
 By coincidence (or fate?) I found myself confronted with a project
 demanding extreme reliability and reusability requirements. As much
 as I tried, C++ just couldn't cut it. One major reason might be
 interesting (or well known) to some of you: You basically can't rely
 in third party C++ code. Not meaning to talk bad about anyone but
 it's my bloody experience. Maybe it's because C++ makes it so hard
 to actually develop and engineer software (rather than hacking),
 maybe because C++ attracts guys like my earlier self (the cool C/C++
 hacker), whatever the reason may be, that's what I experienced.

Y'know, out on the street the word is that C is outdated and dangerous and hard to maintain, and that C++ is better. But my experience -- and yours -- seems to show otherwise. You're not the first one that found C++ lacking. At my day job, we actually migrated a largish system from C++ back into C because the C++ codebase was overengineered and suffered from a lot of the flaws of C++ that only become evident once you move beyond textbook examples. (C++ actually looks rather nice in textbooks, I have to admit, but real-life code is sadly a whole 'nother story.) [...]
 So, I desperately looked for something that would offer at least
 some major goodies lik DBC and would otherwise at least not stand in
 the way of proper software engineering.
 
 Well, that single feature, Design By Contract, led me toward D.
 
 - practically useable modern Arrays? Check.
   And ranges, too. And very smartly thought up and designed. Great.

Time will tell, but I believe ranges may be one of the most significant innovations of D. It makes writing generic algorithms possible, and even pleasant, and inches us closer to the ideal of perfect code reuse than ever before.
 - Strings? Check
   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).

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*).
 - DBC? Check
   And once more the creators of D don't simply address one issue but
 do it elegantly and, even better, sonsistently by throwing in a nice
 use cases solution, too. Great!

Hmm. I hate to burst your bubble, but I do have to warn you that DbC in D isn't as perfect as it could be. The *language* has a pretty good design of it, to be sure, but the current implementation leaves some things to be desired. Such as the fact that contracts are run inside the function rather than on the caller's end, which leads to trouble when you're writing libraries to be used by 3rd party code -- if the library is closed-source, there's no way to enforce the contracts in the API. [...]
 - Some of the major GUI(s)? Check.
   Well, I couldn't care less about Java (Is t possible to repeat all
 C problems creating yet another "C++" and invent a whole new slew of
 burdensome and weird sh*t? Sure, look at java!) but there seems to
 be a GTK binding.

This is one area that people complain about from time to time, though. But I'm no GUI programmer so I can't say too much about this.
 - "defer mechanism"? Check.
    I'm pondering about some smart defer mechanism since years. Et
 voilà, D offers the "scope" mechanism. Brilliant, just f*cking
 brilliant and well made, too!

The irony is that the rest of D is so well designed that scope guards are hardly ever used in practice. :) At my work I have to deal with C (and occasionally C++) code, and you cannot imagine how much I miss D's 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.
 - Genericity? Check
   Genericity is a must, it's one of those things I'm just not
 willing to even discuss making compromises. Frankly, I like Eiffel's
 solution better but hey, D's solution is getting pretty close to
 what I consider excellent.

The lack of genericity is what kept me away from things like Java. Sure, Java added their so-called generics after the fact, but it still leaves much to be desired. Java's generics lack the power of C++ templates, and that's a big minus for me (even though C++ templates are, frankly, an utter mess, which gave templates the unfortunate reputation of being hard to understand, when in fact, if they were done right like in D, they're actually very natural to work with and extremely powerful). Couple D's templates with other D innovations like signature constraints and CTFE (compile-time function evaluation), and you have a system that could trump C++ templates any day with one hand. This is one of the areas where D really shines. You can write truly reusable code that isn't straitjacketed or otherwise crippled. Throw in UFCS (uniform function call syntax) into the mix, and you have something where you can write functional-style code in D and still have the efficiency of native compilation. :) Admittedly, this area of D is still somewhat rough in some parts, but what's there is already pretty impressive, and I believe will only get better as we iron out those wrinkles. [...]
 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.

It would be great if you could contribute to the docs. Documentation is one area where D doesn't quite shine -- which is a pity, because we have such a great language in our hands yet people's first impression of it may not be that great when they see the sorry state of our docs. Pull requests to improve docs are greatly welcomed here. :) T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Aug 19 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/19/2013 2:17 PM, H. S. Teoh wrote:
 Time will tell, but I believe ranges may be one of the most significant
 innovations of D. It makes writing generic algorithms possible, and even
 pleasant, and inches us closer to the ideal of perfect code reuse than
 ever before.

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. We still have a ways to go yet - Phobos support for ranges is not ubiquitous - but ranges are the future.
Aug 19 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/19/2013 3:10 PM, John Colvin wrote:
 On Monday, 19 August 2013 at 22:00:17 UTC, Walter Bright wrote:
 We still have a ways to go yet - Phobos support for ranges is not ubiquitous -
 but ranges are the future.

Is there an official "everything that sensibly can provide a range, should do" policy for phobos? If so, there's quite a bit of low-hanging fruit.

There is as far as I'm concerned. Note the holding back of std.serialization until it has full support for ranges.
Aug 19 2013
parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
Aug 20 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Aug 20 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 20 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 20 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 20 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/20/13 11:32 AM, Walter Bright wrote:
 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.

http://forum.dlang.org/thread/ga46ok$2s77$1 digitalmars.com Andrei
Aug 20 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/20/2013 1:49 PM, Andrei Alexandrescu wrote:
 On 8/20/13 11:32 AM, Walter Bright wrote:
 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.

http://forum.dlang.org/thread/ga46ok$2s77$1 digitalmars.com

Awesome, thanks for digging that up!
Aug 20 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/20/13 2:03 PM, H. S. Teoh wrote:
 On Tue, Aug 20, 2013 at 01:49:41PM -0700, Andrei Alexandrescu wrote:
 On 8/20/13 11:32 AM, Walter Bright wrote:

 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.

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.

I was incredibly excited - so much, in fact, that I decided to share all that following a year-long absence. Andrei
Aug 20 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.)
Aug 20 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/20/13 10:47 AM, Walter Bright wrote:
 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.

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. Andrei
Aug 20 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/20/2013 01:43 PM, Andrei Alexandrescu wrote:

 the range categorization, which is inspired from C++ iterators.

All of that is explained in your "On Iteration" article: http://www.informit.com/articles/article.aspx?p=1407357 Ali
Aug 20 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/21/13 5:39 AM, 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), ...

No random access. I didn't know about drop-last though - does it work in O(1)?
 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?

More accurately was the point that Clojure's sequence API is (to the best of my understanding) only dealing with forward access, whereas D distinguishes between one-pass, forward, bidirectional, and random, and designs algorithms around these notions. Andrei
Aug 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
Aug 19 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 20 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Aug 20 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/20/2013 10:24 PM, Ramon wrote:
  Timon Gehr
...

 As for generics: Maybe I'm not the brightest guy around but I have
 suceeded in noticing that there seems to be tendency in D's community to
 not react warmly to critical remarks regarding generics ...

Why would it be relevant for arguing a point whether reactions are warm or not?
Aug 20 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/21/13 3:53 AM, Andrej Mitrovic wrote:
 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

Awesome idea. One would run the deduper over a codebase and e.g. show the top 10 longest repeated subsequences. Those could be refactored into functions etc. The deduper would be insensitive to alpha renaming, e.g. "int a = 10;" and "int b = 10;" would be identical. Andrei
Aug 21 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/21/2013 10:12 AM, Andrei Alexandrescu wrote:
 On 8/21/13 3:53 AM, Andrej Mitrovic wrote:
 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

Awesome idea. One would run the deduper over a codebase and e.g. show the top 10 longest repeated subsequences. Those could be refactored into functions etc. The deduper would be insensitive to alpha renaming, e.g. "int a = 10;" and "int b = 10;" would be identical.

I've often thought of writing a pass for dmd that would coalesce functions that are semantically identical (even though they may operate on different types).
Aug 21 2013
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:
 semantically identical

This would be equivalent to finding plagiarisms and result in a semantical compression of a software base---and seems to be computational intractable unless severely restricted. -manfred
Aug 22 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/22/2013 7:52 PM, Manfred Nowak wrote:
 Walter Bright wrote:
 semantically identical

This would be equivalent to finding plagiarisms and result in a semantical compression of a software base---and seems to be computational intractable unless severely restricted.

I don't think it would be that hard. The structure of the ASTs would need to match, and the types would have to match depending on the operation - for example, a + gives the same result for signed and unsigned types, whereas < does not.
Aug 22 2013
parent Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:
 The structure of the ASTs would need to match

You may be right: http://www.cs.brown.edu/publications/jgaa/accepted/99/Eppstein99.3.3.pdf -manfred
Aug 22 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/21/2013 07:12 PM, Andrei Alexandrescu wrote:
 The deduper would be insensitive to alpha renaming, e.g. "int a = 10;"
 and "int b = 10;" would be identical.

This is not alpha renaming, it is just renaming. :o) Eg. "{int a = 10; foo(a);}" and "{int b = 10; foo(b);}" would be identical.
Aug 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Aug 21 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/21/2013 07:17 PM, deadalnix wrote:
 You want no bugs ? Go for Haskell.

If you want no bugs, go for formal correctness proof.
 But you'll get no convenience

Yes you do. A lot.
 or performance.

Let's say "easily predictable performance".
 The good thing if that if it does compile, you are pretty
 sure that it does the right thing.

Aug 21 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/21/2013 9:50 AM, Ramon wrote:
 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).

While a 5% performance boost is not relevant for consumer apps, it can make an enormous difference for server side apps. For example, if you've got a $100m server farm, 5% means you save $5m, and server farms can be much, much bigger than that.
Aug 25 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/25/2013 3:13 PM, Ramon wrote:
 You are, of course, perfectly right and my professional background would
testify
 you to be correct.

It's also clear to me that unless D achieves performance parity with C++, D is not going to be considered for a lot of applications. The good news is that I believe that D is technically capable of beating C++ on performance.
Aug 25 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/25/13 3:00 PM, Walter Bright wrote:
 On 8/21/2013 9:50 AM, Ramon wrote:
 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).

While a 5% performance boost is not relevant for consumer apps, it can make an enormous difference for server side apps. For example, if you've got a $100m server farm, 5% means you save $5m, and server farms can be much, much bigger than that.

More than server acquisition costs, it's the electricity. Andrei
Aug 25 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-05 20:12, H. S. Teoh wrote:

 Hmm. I built xombrero from git, and it seems to be unable to connect to
 anything. There are no error messages, no nothing -- it just displays
 the loading icon animation and sits there looking cute but doing
 absolutely nothing. AFAICT, it didn't even send any packets out to the
 network. What gives? Am I missing some library, or did I screw up some
 configuration...?

The most secure web browser :) -- /Jacob Carlborg
Sep 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 05, 2013 at 08:37:36PM +0200, Jacob Carlborg wrote:
 On 2013-09-05 20:12, H. S. Teoh wrote:
 
Hmm. I built xombrero from git, and it seems to be unable to connect
to anything. There are no error messages, no nothing -- it just
displays the loading icon animation and sits there looking cute but
doing absolutely nothing. AFAICT, it didn't even send any packets out
to the network. What gives? Am I missing some library, or did I screw
up some configuration...?

The most secure web browser :)

lol... T -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Sep 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 05, 2013 at 08:57:51PM +0200, John Colvin wrote:
 On Thursday, 5 September 2013 at 18:13:42 UTC, H. S. Teoh wrote:
On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:


I've been testing xombrero for a few days now and I really like it.
It's fast and it's up to most of the ordinary web browsing tasks.
Thanks for the tip. It crashed once, though, when trying to open a
PDF file. Apart from that, it's a good UI for just browsing.

Hmm. I built xombrero from git, and it seems to be unable to connect to anything. There are no error messages, no nothing -- it just displays the loading icon animation and sits there looking cute but doing absolutely nothing. AFAICT, it didn't even send any packets out to the network. What gives? Am I missing some library, or did I screw up some configuration...? T

Not sure what you might be lacking to make it work. I built from git and it just worked. What does ldd show for the executable?

linux-vdso.so.1 (0x00007fffd7dff000) libwebkitgtk-3.0.so.0 => /usr/lib/libwebkitgtk-3.0.so.0 (0x00007f6dc089e000) libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007f6dc01cc000) libjavascriptcoregtk-3.0.so.0 => /usr/lib/libjavascriptcoregtk-3.0.so.0 (0x00007f6dbfa87000) libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007f6dbf801000) libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f6dbf5de000) libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f6dbf3d0000) libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f6dbf1b0000) libcairo-gobject.so.2 => /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007f6dbefa7000) libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f6dbed58000) libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f6dbea3f000) libsoup-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 (0x00007f6dbe77d000) libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f6dbe421000) libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f6dbe1d1000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f6dbded2000) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f6dbdc12000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f6dbda03000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6dbd7ff000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6dbd4c3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6dbd2a7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6dbcefb000) libenchant.so.1 => /usr/lib/x86_64-linux-gnu/libenchant.so.1 (0x00007f6dbccee000) libharfbuzz-icu.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz-icu.so.0 (0x00007f6dbcaeb000) libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f6dbc898000) libgailutil-3.so.0 => /usr/lib/x86_64-linux-gnu/libgailutil-3.so.0 (0x00007f6dbc68e000) libgeoclue.so.0 => /usr/lib/x86_64-linux-gnu/libgeoclue.so.0 (0x00007f6dbc477000) libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007f6dbc250000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f6dbc00a000) libgstapp-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstapp-1.0.so.0 (0x00007f6dbbdfe000) libgstaudio-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0 (0x00007f6dbbbb5000) libgstfft-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstfft-1.0.so.0 (0x00007f6dbb9aa000) libgstpbutils-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstpbutils-1.0.so.0 (0x00007f6dbb786000) libgstvideo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstvideo-1.0.so.0 (0x00007f6dbb545000) libgstbase-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 (0x00007f6dbb2f3000) libgstreamer-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 (0x00007f6dbaffe000) libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f6dbadfa000) libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f6dbabf7000) libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f6dba9bd000) libsecret-1.so.0 => /usr/lib/x86_64-linux-gnu/libsecret-1.so.0 (0x00007f6dba76d000) libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x00007f6dba52d000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f6dba1c6000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f6db9f68000) libEGL.so.1 => /usr/lib/x86_64-linux-gnu/libEGL.so.1 (0x00007f6db9d45000) libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f6db9b2f000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f6db9890000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f6db9654000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f6db942d000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f6db917c000) libicui18n.so.48 => /usr/lib/x86_64-linux-gnu/libicui18n.so.48 (0x00007f6db8daf000) libicuuc.so.48 => /usr/lib/x86_64-linux-gnu/libicuuc.so.48 (0x00007f6db8a40000) libicudata.so.48 => /usr/lib/x86_64-linux-gnu/libicudata.so.48 (0x00007f6db76d0000) libwebp.so.4 => /usr/lib/x86_64-linux-gnu/libwebp.so.4 (0x00007f6db747f000) libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f6db727c000) libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f6db7079000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f6db6e72000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f6db6c68000) libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007f6db6a02000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6db67e9000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6db65e1000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6db62de000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6db5fdf000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6db5dc9000) libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f6db5bb8000) libatk-bridge-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007f6db5987000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f6db5783000) libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f6db5579000) libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f6db536e000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f6db515b000) libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f6db4f52000) libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f6db4ca9000) libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f6db4aa6000) libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f6db489c000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6db467c000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6db445a000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6db4242000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f6db403a000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f6db3dfc000) libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f6db3b7c000) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f6db396b000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f6db374b000) /lib64/ld-linux-x86-64.so.2 (0x00007f6dc2716000) libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f6db3530000) libgsttag-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 (0x00007f6db32f9000) liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007f6db3072000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f6db2e4f000) libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f6db2c28000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f6db2a26000) libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f6db280e000) libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f6db2608000) libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f6db2402000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f6db21f6000) libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007f6db1fee000) libxcb-shape.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x00007f6db1dea000) libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f6db1bde000) libwayland-server.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-server.so.0 (0x00007f6db19cb000) libgbm.so.1 => /usr/lib/x86_64-linux-gnu/libgbm.so.1 (0x00007f6db17c5000) libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x00007f6db15b6000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f6db138b000) libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f6db1184000) libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f6db0f68000) libatspi.so.0 => /usr/lib/x86_64-linux-gnu/libatspi.so.0 (0x00007f6db0d36000) libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f6db0b2e000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6db092a000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6db0725000) libgpg-error.so.0 => /usr/lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f6db051f000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6db0518000) Not sure how this would help, it seems pretty normal for your average typical bloated GUI app... T -- Don't modify spaghetti code unless you can eat the consequences.
Sep 05 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 5 September 2013 at 19:17:54 UTC, H. S. Teoh wrote:
 On Thu, Sep 05, 2013 at 08:57:51PM +0200, John Colvin wrote:
 On Thursday, 5 September 2013 at 18:13:42 UTC, H. S. Teoh 
 wrote:
On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:


I've been testing xombrero for a few days now and I really 
like it.
It's fast and it's up to most of the ordinary web browsing 
tasks.
Thanks for the tip. It crashed once, though, when trying to 
open a
PDF file. Apart from that, it's a good UI for just browsing.

Hmm. I built xombrero from git, and it seems to be unable to connect to anything. There are no error messages, no nothing -- it just displays the loading icon animation and sits there looking cute but doing absolutely nothing. AFAICT, it didn't even send any packets out to the network. What gives? Am I missing some library, or did I screw up some configuration...? T

Not sure what you might be lacking to make it work. I built from git and it just worked. What does ldd show for the executable?

linux-vdso.so.1 (0x00007fffd7dff000) libwebkitgtk-3.0.so.0 => /usr/lib/libwebkitgtk-3.0.so.0 (0x00007f6dc089e000) libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007f6dc01cc000) libjavascriptcoregtk-3.0.so.0 => /usr/lib/libjavascriptcoregtk-3.0.so.0 (0x00007f6dbfa87000) libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007f6dbf801000) libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f6dbf5de000) libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f6dbf3d0000) libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f6dbf1b0000) libcairo-gobject.so.2 => /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007f6dbefa7000) libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f6dbed58000) libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f6dbea3f000) libsoup-2.4.so.1 => /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 (0x00007f6dbe77d000) libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f6dbe421000) libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f6dbe1d1000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f6dbded2000) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f6dbdc12000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f6dbda03000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6dbd7ff000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6dbd4c3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6dbd2a7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6dbcefb000) libenchant.so.1 => /usr/lib/x86_64-linux-gnu/libenchant.so.1 (0x00007f6dbccee000) libharfbuzz-icu.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz-icu.so.0 (0x00007f6dbcaeb000) libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f6dbc898000) libgailutil-3.so.0 => /usr/lib/x86_64-linux-gnu/libgailutil-3.so.0 (0x00007f6dbc68e000) libgeoclue.so.0 => /usr/lib/x86_64-linux-gnu/libgeoclue.so.0 (0x00007f6dbc477000) libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007f6dbc250000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f6dbc00a000) libgstapp-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstapp-1.0.so.0 (0x00007f6dbbdfe000) libgstaudio-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstaudio-1.0.so.0 (0x00007f6dbbbb5000) libgstfft-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstfft-1.0.so.0 (0x00007f6dbb9aa000) libgstpbutils-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstpbutils-1.0.so.0 (0x00007f6dbb786000) libgstvideo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstvideo-1.0.so.0 (0x00007f6dbb545000) libgstbase-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 (0x00007f6dbb2f3000) libgstreamer-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 (0x00007f6dbaffe000) libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f6dbadfa000) libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f6dbabf7000) libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f6dba9bd000) libsecret-1.so.0 => /usr/lib/x86_64-linux-gnu/libsecret-1.so.0 (0x00007f6dba76d000) libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x00007f6dba52d000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f6dba1c6000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f6db9f68000) libEGL.so.1 => /usr/lib/x86_64-linux-gnu/libEGL.so.1 (0x00007f6db9d45000) libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f6db9b2f000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f6db9890000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f6db9654000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f6db942d000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f6db917c000) libicui18n.so.48 => /usr/lib/x86_64-linux-gnu/libicui18n.so.48 (0x00007f6db8daf000) libicuuc.so.48 => /usr/lib/x86_64-linux-gnu/libicuuc.so.48 (0x00007f6db8a40000) libicudata.so.48 => /usr/lib/x86_64-linux-gnu/libicudata.so.48 (0x00007f6db76d0000) libwebp.so.4 => /usr/lib/x86_64-linux-gnu/libwebp.so.4 (0x00007f6db747f000) libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f6db727c000) libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f6db7079000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f6db6e72000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f6db6c68000) libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007f6db6a02000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6db67e9000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6db65e1000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6db62de000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6db5fdf000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6db5dc9000) libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f6db5bb8000) libatk-bridge-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007f6db5987000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f6db5783000) libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f6db5579000) libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f6db536e000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f6db515b000) libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f6db4f52000) libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f6db4ca9000) libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f6db4aa6000) libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f6db489c000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6db467c000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6db445a000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6db4242000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f6db403a000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f6db3dfc000) libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f6db3b7c000) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f6db396b000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f6db374b000) /lib64/ld-linux-x86-64.so.2 (0x00007f6dc2716000) libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f6db3530000) libgsttag-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 (0x00007f6db32f9000) liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007f6db3072000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f6db2e4f000) libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f6db2c28000) libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f6db2a26000) libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f6db280e000) libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f6db2608000) libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f6db2402000) libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f6db21f6000) libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007f6db1fee000) libxcb-shape.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x00007f6db1dea000) libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f6db1bde000) libwayland-server.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-server.so.0 (0x00007f6db19cb000) libgbm.so.1 => /usr/lib/x86_64-linux-gnu/libgbm.so.1 (0x00007f6db17c5000) libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x00007f6db15b6000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f6db138b000) libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f6db1184000) libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f6db0f68000) libatspi.so.0 => /usr/lib/x86_64-linux-gnu/libatspi.so.0 (0x00007f6db0d36000) libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f6db0b2e000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6db092a000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6db0725000) libgpg-error.so.0 => /usr/lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f6db051f000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f6db0518000) Not sure how this would help, it seems pretty normal for your average typical bloated GUI app... T

I was just wondering whether there was anything missing, looks fine though as I'm sure you can see too :) . Might be worth a bug report. Perhaps there are some log files to take a look at.
Sep 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
 On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
Or rather, I *will* be happy as can be once I find a suitable
replacement for a browser. Browsers are by far the most ridiculously
resource-consuming beasts ever, given that all they do is to display
some text and graphics and let you click on stuff.

T

Pretty much describes my feelings too, although I've made my peace with them beasts and like to use xombrero. Although webkit based (translate: bloat) it's relatively(!) modest and is keyboard controllable.

I'm installing it right now. Let's see if it lives up to its promise. ;-) If it does, I'm ditching opera 12 (the last tolerable version; the latest version, opera 15, has lost everything that made opera opera, and I've no desire to stay with opera) and switching over. I'll keep firefox handy for when bloated features are required, there should be plenty of RAM leftover if xombrero isn't as memory-hogging as opera can be. :-P
 I assume you know links2 and w3m, both textmode browsers which
 support tables, frames, and even images. links2 (or was it elinks?)
 even supported javascript for some time.
 You also might like that links by default is non-graphic and needs a
 commandline switch to go graphical.

I use elinks every now and then... I can't say I'm that impressed with its interface, to be honest. There are better ways of doing text mode browser UIs. Plus, most sites look trashy in elinks because they're all designed with bloated GUIs in mind. As for JS, nowadays I turn it off by default anyway, and only enable it when it's actually needed. Makes the web noticeably faster and, in many cases, more pleasant to use. (*cough*dlang.org*cough*) T -- Caffeine underflow. Brain dumped.
Aug 22 2013
prev sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 23 August 2013 at 03:47:00 UTC, H. S. Teoh wrote:
 On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
 On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
Or rather, I *will* be happy as can be once I find a suitable
replacement for a browser. Browsers are by far the most 
ridiculously
resource-consuming beasts ever, given that all they do is to 
display
some text and graphics and let you click on stuff.

T

Pretty much describes my feelings too, although I've made my peace with them beasts and like to use xombrero. Although webkit based (translate: bloat) it's relatively(!) modest and is keyboard controllable.

I'm installing it right now. Let's see if it lives up to its promise. ;-) If it does, I'm ditching opera 12 (the last tolerable version; the latest version, opera 15, has lost everything that made opera opera, and I've no desire to stay with opera) and switching over. I'll keep firefox handy for when bloated features are required, there should be plenty of RAM leftover if xombrero isn't as memory-hogging as opera can be. :-P
 I assume you know links2 and w3m, both textmode browsers which
 support tables, frames, and even images. links2 (or was it 
 elinks?)
 even supported javascript for some time.
 You also might like that links by default is non-graphic and 
 needs a
 commandline switch to go graphical.

I use elinks every now and then... I can't say I'm that impressed with its interface, to be honest. There are better ways of doing text mode browser UIs. Plus, most sites look trashy in elinks because they're all designed with bloated GUIs in mind. As for JS, nowadays I turn it off by default anyway, and only enable it when it's actually needed. Makes the web noticeably faster and, in many cases, more pleasant to use. (*cough*dlang.org*cough*) T

I've been testing xombrero for a few days now and I really like it. It's fast and it's up to most of the ordinary web browsing tasks. Thanks for the tip. It crashed once, though, when trying to open a PDF file. Apart from that, it's a good UI for just browsing.
Sep 05 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ramon:

 not having multiple inheritance is a major minus with me. D 
 seems to compensate quite nicely by supporting interfaces.

D is also supposed to gain multiple "alias this", currently only one is supported. Bye, bearophile
Aug 19 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 19 August 2013 at 22:00:17 UTC, Walter Bright wrote:
 On 8/19/2013 2:17 PM, H. S. Teoh wrote:
 Time will tell, but I believe ranges may be one of the most 
 significant
 innovations of D. It makes writing generic algorithms 
 possible, and even
 pleasant, and inches us closer to the ideal of perfect code 
 reuse than
 ever before.

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. We still have a ways to go yet - Phobos support for ranges is not ubiquitous - but ranges are the future.

Is there an official "everything that sensibly can provide a range, should do" policy for phobos? If so, there's quite a bit of low-hanging fruit.
Aug 19 2013
prev sibling next sibling parent reply "Ramon" <spam thanks.no> writes:
On Monday, 19 August 2013 at 21:19:05 UTC, H. S. Teoh wrote:
 Honestly, while OO definitely has many things to offer, I think 
 its
 proponents have a tendency to push things a little too far. 
 There are
 things for which OO isn't appropriate, ...

Nope, I don't belong to the OOP fanatics in the sense of "everything must be a class"; actually that's one of my critical remarks on Eiffel. But, no doubt, OOP is an absolute must have. I remember my (seen from today pathetic) desperate attempts to use C at least in a somewhat OO way (abusing structs).
 ... C++ tries to do OO but fails
 miserably because it insisted on backward-compatibility with C.

I'm not sure that I can agree on that. I'll elaborate somewhat on this issue for reasons that directly touch D. Actually C backward compatibility *could* have been implemented in D, too, if at quite some cost for the implementers; after all it's no coincidence that D feel pretty much "at home" for a C programmer - although the D people probably came to the conclusion that being similar enough was enough or even better than to go for full C compatibility (= capable to compile C code) and rightly so. I'm sure that basically every C programmer looking at another language doesn't look for another C but rather for something he can quickly master to a useable degree; otherwise he wouldn't be looking for another language in the first place. As far as I'm concerned D's superiority over C++ has another reason: D was conceived from a _pragmatic approach_. While it's a great thing to have scientists to design new paradigms and concepts it's, I'm convinced, a bad idea to have them actually go to the end; the perspectives, weighting of criteria and other issues usually happen to be a very different mix from what practical use would suggest. Just look at C. We didn't miss so much new concepts and paradigms (except maybe OO) but rather were swearing at quite pragmatic aspects like lots of housekeeping overhead for resizing an array and many other things and at stupid problems related to pointers (like array being automatically being passed as pointers). I remember quite well that when wanting proper error handling, some logging and maybe message strings in 2 languages one quickly ended up with most code not related to the algorithm or problem at hand but to those housekeeping chores and alike. In summary my impression is that C++ was created by scientists who somehow shoehorned a set of (what they considered) concepts and paradigms into a language that looked good in lectures - but they didn't care sh*t about compiler writers and actual users who had to solve actual problems. While many considered STL a breakthrough milestone for mankind I personally, Pardon me, always considered it a) a weird mess and b) a confession that C++ was f*cked up.
 Y'know, out on the street the word is that C is outdated and 
 dangerous
 and hard to maintain, and that C++ is better.  But my 
 experience -- and
 yours -- seems to show otherwise. You're not the first one that 
 found
 C++ lacking. At my day job, we actually migrated a largish 
 system from
 C++ back into C because the C++ codebase was overengineered and 
 suffered
 from a lot of the flaws of C++ that only become evident once 
 you move
 beyond textbook examples. (C++ actually looks rather nice in 
 textbooks,
 I have to admit, but real-life code is sadly a whole 'nother 
 story.)

See my point above and: I couldn't care less what's the current hype in Dr.Dobbs or Computer Language (anyone remembers that?) or for that matter the "word on the street". Actually I tought C at that time and I remember to comment students remarks concerning OO, C++ and the like along this line "C basically is a - pretty well done - attempt to create a cross platform assembler with quite some comfort". After all, this shouldn't be forgotten, C was created to use the wonderful new PDP11 (by brilliant men who had understood that a) there would be other architectures and systems to follow and b) one shouldn't have to learn 10 assemblers for 10 systems. C++'s proponents stating that C++ was meant to be an better C with OO on top never had any credibility considering the background and origin and raison d'etre of C as far as I'm concerned.
 - practically useable modern Arrays? Check.
   And ranges, too. And very smartly thought up and designed. 
 Great.

Time will tell, but I believe ranges may be one of the most significant innovations of D. It makes writing generic algorithms possible, and even pleasant, and inches us closer to the ideal of perfect code reuse than ever before.

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. As for generics I still need to learn more about D but from first impressions and comments I'm not sure that D has reached a final and polished state there; possibly there might be even a point where the D guys decide to chose a completely new approach in D3. One thing is clear (well, to me at least), doing generics simply like templates will turn out to be a major limitation and sometimes even more of a problem than a solution; one ugly issue coming to mind is having "filled in" code spread all over the place. Maybe I'm stubborn here but I do not agree with the usual approach of seing generics = templates = saving typing effort. Typing efforts are to be addressed by editors not by language designers. Generics are about implementing algorithms (that are not type dependent anyway). 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". But again, I'm too fresh at D and, for instance, have to first learn a whole lot more (like interface mechanisms) before coming to a well based assessment.
 - DBC? Check
   ...

Hmm. I hate to burst your bubble, but I do have to warn you that DbC in D isn't as perfect as it could be. The *language* has a pretty good design of it, to be sure, but the current implementation leaves some things to be desired. Such as the fact that contracts are run inside the function rather than on the caller's end, which leads to trouble when you're writing libraries to be used by 3rd party code -- if the library is closed-source, there's no way to enforce the contracts in the API.

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. The trouble with 3rd party libs, I don't see it. The lib provides contract terms along wih the API and that's it. I do agree though (*if* I got that right in the docs so far) that there shouldn't simply be a "debugging - DBC on" or "production - DBC off". There should also be some direct mechanism for the developer to have certain contracts active even in production mode.
 The irony is that the rest of D is so well designed that scope 
 guards
 are hardly ever used in practice. :) At my work I have to deal 
 with C
 (and occasionally C++) code, and you cannot imagine how much I 
 miss D's
 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.

Can't follow there. If, for instance, I open a file I want to make sure that it's properly closed. That's nothing to do with the language but with the world our code runs in, no?
 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.

It would be great if you could contribute to the docs. Documentation is one area where D doesn't quite shine -- which is a pity, because we have such a great language in our hands yet people's first impression of it may not be that great when they see the sorry state of our docs. Pull requests to improve docs are greatly welcomed here. :)

Well, while I'd be glad to contribute I'm afraid that's a dog biting his own tail problem. I need good doc to understand before I can explain to others ... I'm afraid I'll have to fall on the nerves of the creators for that.
Aug 19 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
 On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to have
less experienced programmers to work in "safe mode" only, which
anyway is good enough for pretty everything the average app needs,
and to limit "system mode" to seasoned programmers.

If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches system code* would have to go through an extra stage or something to that effect.

Are you sure about that? import std.stdio; void main() safe { writeln("abc"); } DMD says: /tmp/test.d(3): Error: safe function 'D main' cannot call system function 'std.stdio.writeln!(string).writeln' SafeD is a nice concept, I agree, but we have a ways to go before it's usable. T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Aug 22 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 22 August 2013 at 16:46:46 UTC, H. S. Teoh wrote:
 On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
 On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to 
have
less experienced programmers to work in "safe mode" only, 
which
anyway is good enough for pretty everything the average app 
needs,
and to limit "system mode" to seasoned programmers.

If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches system code* would have to go through an extra stage or something to that effect.

Are you sure about that? import std.stdio; void main() safe { writeln("abc"); } DMD says: /tmp/test.d(3): Error: safe function 'D main' cannot call system function 'std.stdio.writeln!(string).writeln' SafeD is a nice concept, I agree, but we have a ways to go before it's usable. T

Fair point. Why is that writeln can't be trusted?
Aug 22 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 22 August 2013 at 17:16:13 UTC, John Colvin wrote:
 On Thursday, 22 August 2013 at 16:46:46 UTC, H. S. Teoh wrote:
 On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
 On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
One (OK, not very creative) example that comes to mind is to 
have
less experienced programmers to work in "safe mode" only, 
which
anyway is good enough for pretty everything the average app 
needs,
and to limit "system mode" to seasoned programmers.

If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches system code* would have to go through an extra stage or something to that effect.

Are you sure about that? import std.stdio; void main() safe { writeln("abc"); } DMD says: /tmp/test.d(3): Error: safe function 'D main' cannot call system function 'std.stdio.writeln!(string).writeln' SafeD is a nice concept, I agree, but we have a ways to go before it's usable. T

Fair point. Why is that writeln can't be trusted?

In the case of a string, that is.
Aug 22 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 20/08/13 06:18, Ramon wrote:
 Falling over the famous Ariane 5 article I looked at Eiffel. I have to
 confess that I almost feel in love. Eiffel felt just right and Prof.
 Meyers books convinced me again and again - Yesss, that's the way I'd
 like to work and develop software.
 Unfortunately, though, Prof Meyer and ISE (the Eiffel company) made some
 errors, too, and in a major way.
 For a starter that whole Eiffel world is pretty much a large beautiful
 castle ... inmidst a desert. Theoretically there are different
 compilers, factually, however, ISE's Eiffelstudio is the only one; the
 others are either brutally outdated or non-conforming or weird niche
 thingies or eternally in alpha, or a mixture of those. And Eiffelstudio
 costs north of 5.000 us$. Sure there is a GPL version but that is
 available only for GPL'ed programs.
 Next issue: Eiffels documentation is plain lousy. Yes, there are some 5
 or so books but those are either purely theoretical or very outdated or
 both. Yes there is lots of documentation online but most of it basically
 is luring sales driven "Look how easy it is with Eiffel" stuff. And
 there is a doxygen like API doc which is pretty worthless for learning
 how to practically use the language.
 Furthermore, while Eiffel comes with a lot on board there still is much
 missing; just as an example there are no SSL sockets which nowadays is a
 killer.

I found similar issues with Eiffel plus I was turned off by the OOP only factor. Programming needs to be more flexible than that. BTW using Eiffel was where I first realized that contracts would never be as useful as I hoped. They're still useful and I still use them but they're not as expressive as I'd hoped for (neither are D's). In reality, they're just highly targeted unit tests. I think my disappointment stems from the fact I used to write Z specifications and I would liked to have contracts that were the equivalent. Peter
Aug 19 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Aug 20 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 20 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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.
Aug 20 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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
Aug 20 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 20 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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!
Aug 20 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Aug 20 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 20 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Aug 20 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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.
Aug 20 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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.
Aug 20 2013
prev sibling next sibling parent "QAston" <qaston gmail.com> writes:
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
Aug 20 2013
prev sibling next sibling parent "QAston" <qaston gmail.com> writes:
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

unfinished by "Send" keyboard shortcut :(
Aug 20 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 20 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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.
Aug 20 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Aug 20 2013
prev sibling next sibling parent "pjmp" <pjmp progtools.org> writes:
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
Aug 20 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Aug 20 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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.
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 20 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
First, thanks all for returning (or keeping up) a constructive 
discussion.

 monarch_dodra

My error, sorry. I was talking in the context of a western view, 
ignoring China, Japan, Koreas (and probably some more Asian 
countries/languages, too). Not meaning to propagate that as 
generally sound practice, I personally happen to work in a very 
western-centric world where, say, Russian (kyrillic alphabet) is 
already considered *very* exotic. In that context, however, 
16bits are plenty enough.


 H. S. Teoh

I remember myself to stubbornly refuse Windows and staying with 
Dos or Unix (cli). Well, work forced me to make compromises and 
since FreeBSD came up (and Solaris worked on X86) I made one step 
and another ... and are (by your standards) pretty rotten 
nowadays *g

I got your point and I agree. Yes, it's a major plus for D to be 
cli useable and not requiring a (probably bloated) IDE. OTOH, I'm 
quite liberal in that and never had qualms about using an IDE 
(or, in old days, E, brief and the like); after all, a computers 
raison d'etre is to make our lifes easier and to take on a 
gazillion of boring little tasks, no?
But it's, of course, strongly desirable to have "direct access" 
on the commandline, which IMO is valid for other areas, too. 
Actually it always was oe of my reasons to outright hate Windows 
for keeping me away from its guts.


 Timon Gehr

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

point of view (with very powerful and elaborate "duplication" facilities) you are right. I see that, however, as a (valuable) add-on. It doesn't change the fact that the technical part of code production is an editors job; just think code completion, intellisense and the like. Maybe it's just a perspective thing. I tend to feel that the editor is the interface between the system and myself. What is produced with it will then be the input to a compiler. Anyway, that's not important because thanks to D's facilities we can actually have it both ways ;) As for generics: Maybe I'm not the brightest guy around but I have suceeded in noticing that there seems to be tendency in D's community to not react warmly to critical remarks regarding generics ... Actually, I'm far away from hitting on D. Even if, suppose, its generics were lousy, there would still be lots of solid good reasons to like D and to consider it one of the best approaches wide and far. It might as well be my fault to be stubbornly fixed on "generics done right".
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 20, 2013 at 01:49:41PM -0700, Andrei Alexandrescu wrote:
 On 8/20/13 11:32 AM, Walter Bright wrote:

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.

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. T -- If a person can't communicate, the very least he could do is to shut up. -- Tom Lehrer, on people who bemoan their communication woes with their loved ones.
Aug 20 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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

Sadly, the link to Andrei's presumably DDoc-generated page is no longer working. :-( T -- Life would be easier if I had the source code. -- YHL
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 20 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Aug 20 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Aug 20 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Aug 20 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Aug 20 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Aug 20 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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.
Aug 20 2013
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
Aug 20 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:
 On Friday, 23 August 2013 at 03:47:00 UTC, H. S. Teoh wrote:
On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
Or rather, I *will* be happy as can be once I find a suitable
replacement for a browser. Browsers are by far the most
ridiculously resource-consuming beasts ever, given that all they do
is to display some text and graphics and let you click on stuff.

T

Pretty much describes my feelings too, although I've made my peace with them beasts and like to use xombrero. Although webkit based (translate: bloat) it's relatively(!) modest and is keyboard controllable.

I'm installing it right now. Let's see if it lives up to its promise. ;-)


 I've been testing xombrero for a few days now and I really like it.
 It's fast and it's up to most of the ordinary web browsing tasks.
 Thanks for the tip. It crashed once, though, when trying to open a
 PDF file. Apart from that, it's a good UI for just browsing.

Hmm. I built xombrero from git, and it seems to be unable to connect to anything. There are no error messages, no nothing -- it just displays the loading icon animation and sits there looking cute but doing absolutely nothing. AFAICT, it didn't even send any packets out to the network. What gives? Am I missing some library, or did I screw up some configuration...? T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Sep 05 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 5 September 2013 at 18:13:42 UTC, H. S. Teoh wrote:
 On Thu, Sep 05, 2013 at 11:11:14AM +0200, Chris wrote:
 On Friday, 23 August 2013 at 03:47:00 UTC, H. S. Teoh wrote:
On Fri, Aug 23, 2013 at 05:06:01AM +0200, Ramon wrote:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh 
wrote:
Or rather, I *will* be happy as can be once I find a 
suitable
replacement for a browser. Browsers are by far the most
ridiculously resource-consuming beasts ever, given that all 
they do
is to display some text and graphics and let you click on 
stuff.

T

Pretty much describes my feelings too, although I've made my peace with them beasts and like to use xombrero. Although webkit based (translate: bloat) it's relatively(!) modest and is keyboard controllable.

I'm installing it right now. Let's see if it lives up to its promise. ;-)


 I've been testing xombrero for a few days now and I really 
 like it.
 It's fast and it's up to most of the ordinary web browsing 
 tasks.
 Thanks for the tip. It crashed once, though, when trying to 
 open a
 PDF file. Apart from that, it's a good UI for just browsing.

Hmm. I built xombrero from git, and it seems to be unable to connect to anything. There are no error messages, no nothing -- it just displays the loading icon animation and sits there looking cute but doing absolutely nothing. AFAICT, it didn't even send any packets out to the network. What gives? Am I missing some library, or did I screw up some configuration...? T

Not sure what you might be lacking to make it work. I built from git and it just worked. What does ldd show for the executable?
Sep 05 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.


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.
Aug 20 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Aug 21 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Aug 21 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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. :-)
Aug 21 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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 ...
Aug 21 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Aug 21 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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).
Aug 21 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
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...
Aug 21 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Aug 21 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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.
Aug 21 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
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.
Aug 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 21 August 2013 at 16:50:38 UTC, Ramon wrote:
 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).

Moor's law is kaput, finish, niet, we don't know how to use the extra transistor.
 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?

A vast amount of software is written in javascript, java, C#, PHP and many "safe" languages, and still are crippled with bugs. Some codebase are trully scary. Look at gdb's source code or gtk's. You want no bugs ? Go for Haskell. But you'll get no convenience or performance. The good thing if that if it does compile, you are pretty sure that it does the right thing.
Aug 21 2013
prev sibling next sibling parent "Paulo Pinto" <pjmp progtools.org> writes:
On Wednesday, 21 August 2013 at 17:17:52 UTC, deadalnix wrote:
 On Wednesday, 21 August 2013 at 16:50:38 UTC, Ramon wrote:
 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).

Moor's law is kaput, finish, niet, we don't know how to use the extra transistor.
 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?

A vast amount of software is written in javascript, java, C#, PHP and many "safe" languages, and still are crippled with bugs. Some codebase are trully scary. Look at gdb's source code or gtk's. You want no bugs ? Go for Haskell. But you'll get no convenience or performance. The good thing if that if it does compile, you are pretty sure that it does the right thing.

While I agree with you, if C hadn't become mainstream the spectrum of bugs at the OS level would be much lower. Given the amount of errors caused by pointer arithmetic, buffer overflows and string manipulations. All of which are easily avoidable in systems programming languages from the early 80's. -- Paulo
Aug 21 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Wednesday, 21 August 2013 at 17:17:52 UTC, deadalnix wrote:
 On Wednesday, 21 August 2013 at 16:50:38 UTC, Ramon wrote:
 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).

Moor's law is kaput, finish, niet, we don't know how to use the extra transistor.

Even if that were true, we have gone quite some distance. Not even talking about Sparc T4 or 8-core X86, my smartphone is more powerful than what I had as computer 10 years or so ago.
 A vast amount of software is written in javascript, java, C#, 
 PHP and many "safe" languages, and still are crippled with bugs.

Do I get you right considering js, java, C# and PHP being "safe" languages?
 Some codebase are trully scary. Look at gdb's source code or 
 gtk's.

Written in C/C++ ...
 You want no bugs ? Go for Haskell. But you'll get no 
 convenience or performance. The good thing if that if it does 
 compile, you are pretty sure that it does the right thing.

Why should I? Isn't that what D promises, too (and probably is right)? On another perspective: Consider this question "Would you be willing to have all your software (incl. OS) running 10% or even 20% slower but without bugs, leaks, (unintended) backdoors and the like?" My guess: Upwards of 80% would happily chime "YES!".
Aug 21 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
 On Wednesday, 21 August 2013 at 17:17:52 UTC, deadalnix wrote:
 You want no bugs ? Go for Haskell. But you'll get no 
 convenience or performance. The good thing if that if it does 
 compile, you are pretty sure that it does the right thing.

Why should I? Isn't that what D promises, too (and probably is right)? On another perspective: Consider this question "Would you be willing to have all your software (incl. OS) running 10% or even 20% slower but without bugs, leaks, (unintended) backdoors and the like?" My guess: Upwards of 80% would happily chime "YES!".

Have you looked at Rust? It promises to solve a few of the memory-related problems mentioned: - no null pointer exceptions - deterministic free (with owned pointers) - optional garbage collection It also has generics, which are runtime generics if I'm not mistaken. It doesn't have inheritance in the traditional OO sense, so you may not like that. I really like that it's LLVM compiled, so performance and cross-compiling should be pretty much solved problems. There are still things that keep me here with D though: - templates instead of generics (little reason to take a performance hit) - CTFE - inheritance (though I hardly use classes, they're handy sometimes) - community - array operations (int[] a; int[]b; auto c = a * b;) - I don't think these are automagically SIMD'd, but there's always hope =D - similar to C++, so it's easy to find competent developers
Aug 21 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little 
wrote:
 It also has generics, which are runtime generics if I'm not 
 mistaken.

Both.
Aug 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Tyler Jameson Little:

 It also has generics, which are runtime generics if I'm not 
 mistaken.

 - templates instead of generics (little reason to take a 
 performance hit)

As far as I know Rust uses monomorphization just like C++ and D for generics. The difference in generics between D and Rust is that Rust has them strongly typed with type classes (this means inside a function templated on an argument, you can't do on that argument operations that are not specified in its static type class). But unlike the type classes of Haskell, the Rust ones are designed to have no run-time hit (but this makes them currently less powerful. Some persons are trying to improve this in Rust). Perhaps the original poster of this thread is looking for this. Bye, bearophile
Aug 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
 Moor's law is kaput, finish, niet, we don't know how to use 
 the extra transistor.

Even if that were true, we have gone quite some distance. Not even talking about Sparc T4 or 8-core X86, my smartphone is more powerful than what I had as computer 10 years or so ago.

Just read this this : ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come back informed.
 A vast amount of software is written in javascript, java, C#, 
 PHP and many "safe" languages, and still are crippled with 
 bugs.

Do I get you right considering js, java, C# and PHP being "safe" languages?

They are dramatically superior to C in term of safety.
 Some codebase are trully scary. Look at gdb's source code or 
 gtk's.

Written in C/C++ ...

Well look at phpBB's source code then. Horrible codebase isn't language specific.
 You want no bugs ? Go for Haskell. But you'll get no 
 convenience or performance. The good thing if that if it does 
 compile, you are pretty sure that it does the right thing.

Why should I? Isn't that what D promises, too (and probably is right)?

D promise a pragmatic balance between safety, performance, ease of use, productivity, etc . . .
 On another perspective: Consider this question "Would you be 
 willing to have all your software (incl. OS) running 10% or 
 even 20% slower but without bugs, leaks, (unintended) backdoors 
 and the like?"

 My guess: Upwards of 80% would happily chime "YES!".

Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ?
Aug 21 2013
prev sibling next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
 On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
 Moor's law is kaput, finish, niet, we don't know how to use 
 the extra transistor.

Even if that were true, we have gone quite some distance. Not even talking about Sparc T4 or 8-core X86, my smartphone is more powerful than what I had as computer 10 years or so ago.

Just read this this : ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come back informed.
 A vast amount of software is written in javascript, java, C#, 
 PHP and many "safe" languages, and still are crippled with 
 bugs.

Do I get you right considering js, java, C# and PHP being "safe" languages?

They are dramatically superior to C in term of safety.

Like Modula-2, Pascal dialects (mainly Turbo/Apple Pascal) and Ada are, but lost their place in developer's hearts. Now with D, Rust and even Go we can have another go at making system programming a better world. -- Paulo
Aug 21 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
 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).

There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach. Longer form: http://beza1e1.tuxen.de/articles/generics.html An interesting twist would be to use type erasure for reference types and instantiation for value types. Another idea could be to use instantiation selectively as an optimization and erasure in general.
 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.

In D you can use structs: struct days_of_month { int day; /* fill in operator overloading etc */ }
Aug 22 2013
prev sibling next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
 On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
 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).

There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach. Longer form: http://beza1e1.tuxen.de/articles/generics.html An interesting twist would be to use type erasure for reference types and instantiation for value types. Another idea could be to use instantiation selectively as an optimization and erasure in general.

Which is the way .NET does it. http://blogs.msdn.com/b/carlos/archive/2009/11/09/net-generics-and-code-bloat-or-its-lack-thereof.aspx
 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.

In D you can use structs: struct days_of_month { int day; /* fill in operator overloading etc */ }

Thanks for the Eiffel info.
Aug 22 2013
prev sibling next sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 21 August 2013 at 17:48:49 UTC, Andrei Alexandrescu 
wrote:
 No random access. I didn't know about drop-last though - does 
 it work in O(1)?

There is "nth" <http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/nth> but the O(n) cited there is rather disturbing.
 More accurately was the point that Clojure's sequence API is 
 (to the best of my understanding) only dealing with forward 
 access, whereas D distinguishes between one-pass, forward, 
 bidirectional, and random, and designs algorithms around these 
 notions.

I'll check up with my friend on the forward access side. What certainly seems to be true is that the API doesn't make the useful distinctions/classifications that D does.
Aug 22 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little 
wrote:
 - array operations (int[] a; int[]b; auto c = a * b;)
   - I don't think these are automagically SIMD'd, but there's 
 always hope =D

That isn't allowed. The memory for c must be pre-allocated, and the expression then becomes c[] = a[] * b[]; Is it SIMD'd? It depends. There is a whole load of hand-written assembler for simple-ish expressions on builtin types, on x86. x86_64 is only supported with 32bit integer types because I haven't finished writing the rest yet... However, I'm not inclined to do so at the moment as we need a complete overhaul of that system anyway as it's currently a monster*. It needs to be re-implemented as a template instantiated by the compiler, using core.simd. Unfortunately it's not a priority for anyone right now AFAIK. * hand-written asm loops. If fully fleshed out there would be: ((aligned + unaligned + legacy mmx) * (x86 + x64) + fallback loop) * number of supported expressions * number of different types of them. Then there's unrolling considerations. See druntime/src/rt/arrayInt.d
Aug 22 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
 On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
 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).

There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach. Longer form: http://beza1e1.tuxen.de/articles/generics.html An interesting twist would be to use type erasure for reference types and instantiation for value types. Another idea could be to use instantiation selectively as an optimization and erasure in general.
 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.

In D you can use structs: struct days_of_month { int day; /* fill in operator overloading etc */ }

Thank you. Well in an OO language the actual type(s) is/are known. So real genericity boils done to whether an object has the required functions or not. D has, obviously piously following the C++ way (which can be a good thing), chosen to go the template way, that is, to handle it compile time. Other languages have chosen to do it runtime which is no worse or better per se but happens to be more consistent with OO. Some here argued that, well, in the end, say, a simple int and a bank account, need different data types and operations because it matters to CPUs whether it does sth. with a DWORD or a char[]. And, so they argued, therefore you have to pay a runtime penalty for real generics. I don't think so. Sure, one evidently pays a penalty for OO in general (as opposed to simple scalars). But it's not the genericity that costs. Last but not least, there simply isn't a either/or issue. Once can perfectly well have both. And no, that doesn't necessarily bring a performance penalty with it. Another point of view that doesn't match precisely but may help to understand it is this: True OOP is basically about "It's the *data*!" while systems programming understandably is closer to "it's the *code*!" Where the former has data "carrying the operations with them" the latter has data as something that is fed in and processed and spit out by the machinery. And it's that what brings up the question "Well, but how would the CPU know what kind of data it's working on? That requires expensive extra steps". Again, for systems programming that's just fine. But the whole penalty assumption largely stems from looking at true OOP through the C/C++ model.
Aug 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 22 August 2013 at 12:37:50 UTC, Ramon wrote:
 Well in an OO language the actual type(s) is/are known. So real 
 genericity boils done to whether an object has the required 
 functions or not.

Polymorphism say no, you don't know the actual type, and this is the whole point of OOP : being able to interact with object of various type as long as they provide the needed interface to interact with.
 D has, obviously piously following the C++ way (which can be a 
 good thing), chosen to go the template way, that is, to handle 
 it compile time. Other languages have chosen to do it runtime 
 which is no worse or better per se but happens to be more 
 consistent with OO.

D recognize that OO isn't the only paradigm on earth. And generic won't work with non OO code.
 Some here argued that, well, in the end, say, a simple int and 
 a bank account, need different data types and operations 
 because it matters to CPUs whether it does sth. with a DWORD or 
 a char[]. And, so they argued, therefore you have to pay a 
 runtime penalty for real generics. I don't think so.
 Sure, one evidently pays a penalty for OO in general (as 
 opposed to simple scalars). But it's not the genericity that 
 costs.

Indirections, opaque calls, and heap allocation are probably the 3 first performance killers on modern architecture. OO embrace the 3 of them.
 True OOP is basically about "It's the *data*!" while systems 
 programming understandably is closer to "it's the *code*!"
 Where the former has data "carrying the operations with them" 
 the latter has data as something that is fed in and processed 
 and spit out by the machinery. And it's that what brings up the 
 question "Well, but how would the CPU know what kind of data 
 it's working on? That requires expensive extra steps".

No true OOP is about behavioral abstraction. See Liskov's substitution principle. Data is merely a tool and OOP promote its encapsulation. In other term, data is an implementation detail in OOP.
 Again, for systems programming that's just fine. But the whole 
 penalty assumption largely stems from looking at true OOP 
 through the C/C++ model.

The whole penalty assumptions come from how actual compilers and CPU works. If you have new idea to revolution both and change the deal, great, but I highly doubt so.
Aug 22 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
 Just read this this : 
 ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come 
 back informed.

Well, I can give you a link to some paper that says that the world will break down and stop next tuesday. Interested?
 A vast amount of software is written in javascript, java, C#, 
 PHP and many "safe" languages, and still are crippled with 
 bugs.

Do I get you right considering js, java, C# and PHP being "safe" languages?

They are dramatically superior to C in term of safety.

I know "bridges" in Siberia that are vastly superior to bridges in the Andes. Frankly, I'd prefer to use a european bridge. And one *can* be in the C/C++ family and have a vastly safer system. Look at D.
 Some codebase are trully scary. Look at gdb's source code or 
 gtk's.

Written in C/C++ ...

Well look at phpBB's source code then. Horrible codebase isn't language specific.

So? Is this a "who knows most programs with lousy coding?" contest? All I see there is that programmers, in particular hobby hackers will spot - and use - any chance to wildly shoot around unless they are mildly (or less mildly) guided by a sound and safe system. And I see (and confess for myself) that even seasoned programmers can very much profit from a system that makes it easier to do the right thing and harder to do the wrong thing.
 You want no bugs ? Go for Haskell. But you'll get no 
 convenience or performance. The good thing if that if it does 
 compile, you are pretty sure that it does the right thing.

Why should I? Isn't that what D promises, too (and probably is right)?

D promise a pragmatic balance between safety, performance, ease of use, productivity, etc . . .

Well, being a systems programming language D is condemned to keep quite some doors open. It seems (as far as I can that now) however to have done an excellent job in terms of safety (give or take some minor sins like '=' as assignment). One might put Java against D. But frankly, I do not consider Javas approach "Subdue them with pervert bureaucracy, hehe" approach as acceptable (and it creates a whole set of problems, too). Frankly, if I had to work on a highly safety critical and reliable project (say in the medical area) I would have a hard time to spot just 5 languages that I would consider. Ada comes to mind (but I don't like it) and Eiffel, which is great but that great pragmatically. I'm afraid I'd end up where I ended up in the first place: Eiffel vs. D. I'm probably not counted as a happy D protagonist around here but I'd happily state that D is way ahead of 99% of the known languages. And that expressly includes safety.
 On another perspective: Consider this question "Would you be 
 willing to have all your software (incl. OS) running 10% or 
 even 20% slower but without bugs, leaks, (unintended) 
 backdoors and the like?"

 My guess: Upwards of 80% would happily chime "YES!".

Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ?

I refuse to answer that because it's way out of reality.
Aug 22 2013
prev sibling next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
 On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
 On another perspective: Consider this question "Would you be 
 willing to have all your software (incl. OS) running 10% or 
 even 20% slower but without bugs, leaks, (unintended) 
 backdoors and the like?"

 My guess: Upwards of 80% would happily chime "YES!".

Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ?

I would, because my experience with Native Oberon and AOS (Blue Bottle), teached me that those real time capabilities are possible in a desktop OS written in a GC enabled systems programming language. As example, BlueBottle has a video player, just the decoder has some snippets written in Assembly. http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager?action=download&upname=AosScreenshot1.jpg -- Paulo
Aug 22 2013
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
 There are basically two ways to implement generics. Type 
 erasure (Java,Haskell) or template instantiation (C++,D). 
 Instantiation provides better performance, but sacrifices error 
 messages (fixable?), binary code size, and compilation 
 modularity (template implementation must be available for 
 instantiation). Type safety is not a problem in either approach.

See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D. That said, I like the D approach of putting a lot of power in the macro-like template system. I worry more about the reliance on GC in a systems programming language, as historically that's been a losing proposition. -- Brian
Aug 22 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote:
 See this brief discussion from Greg Morrisett on the topic, 
 with a finer subdivision of approaches

 http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt

 that confirms your bad news that monomorphization (C++/D 
 templates) and separate compilation won't play well together. 
 Nor do monomorphization and some advanced type system features 
 work together, but that's less of a worry for D.

Well, in that paper they make a bit too hard statement - such model implies certain limitations for separate compilations (either explicit instantiation or having access to sources) but does not destroy completely. No silver bullet here, every approach has its own pros and cons. As have been discussed recently, ancient object file / linker tool stack harms it much more when comes to practice.
Aug 22 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
 http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt


I have quickly looked over that paper and find it quite worthless for a couple of reasons (I will not elaborate on, except one: All these scientific elaborations are nice and all but we have real problems here in the real world. Frankly, someone having worked on "Cyclone" may be bright and all, but he definitely hasn't got som major points). While Eiffel and D look (and in quite some respects are) quite different, both have actually realized some important real world problems and have them addressed in not so different conceptual ways. One of the reasons D is considerably more safe than C is strikingly simple and one doesn't need any scientific research to spot it: D offers (a quite sane implementation of) strings and "resizeable arrays". Why is this related to safety? Because zillions of bugs have been created by programmers desperately using, bending and abusing what was available in C (and to a degree in C++). Give them reasonable strings and some reasonable way to handle dynamic arrays and you have prevented gazillions of bugs. Simple as that. Another pragmatic look at reality underlines my point: In todays world even major software projects are being worked on by people with an almost brutally large degree of variation in their skills. Even worse, each of them (at least sometimes) has to work with code written by others with a (sometimes very) sifferent level of skills. D has made a very major contribution to safety alone for the fact that it allows less skilled people to create less errors. And it has something else that might not seem that big a thing, that however, started a (imo) very important path: safe, trusted and system. In C/C++ pretty everybody can - and does - play with potentially dangerous mechanism (like pointers) pretty much everywhere. Those simple 3 "code classes" safe, trusted and system can help a great deal there. One (OK, not very creative) example that comes to mind is to have less experienced programmers to work in "safe mode" only, which anyway is good enough for pretty everything the average app needs, and to limit "system mode" to seasoned programmers. Furthermore this D mechanism offers something else of high value by introducing a simple and important question "How much power do I need?". I might sound streetwise rather than properly educated, I know, but I have experienced again and again that what really counts is results. And I'm sure that D, if understood and used properly, contributes quite much to a very important result: Less bugs and more reliable code.
Aug 22 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
 One (OK, not very creative) example that comes to mind is to 
 have less experienced programmers to work in "safe mode" only, 
 which anyway is good enough for pretty everything the average 
 app needs, and to limit "system mode" to seasoned programmers.

If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches system code* would have to go through an extra stage or something to that effect.
Aug 22 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 22 August 2013 at 15:50:50 UTC, John Colvin wrote:
 On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
 One (OK, not very creative) example that comes to mind is to 
 have less experienced programmers to work in "safe mode" only, 
 which anyway is good enough for pretty everything the average 
 app needs, and to limit "system mode" to seasoned programmers.

If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches system code* would have to go through an extra stage or something to that effect.

Yep. Considering that pretty every non-trivial/small utility software is layered anyway it comes even quite natural. But I (often involved in systems stuff) will also use it as a private warning system. Trying to get done whatever can get done using safe. Quite probably ("probably" because I lack experience with D) it will even reflect back on the design along the line of tinkering "does this *really* need to be here?".
Aug 22 2013
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Thursday, 22 August 2013 at 14:37:21 UTC, Dicebot wrote:
 On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote:
 See this brief discussion from Greg Morrisett on the topic, 
 with a finer subdivision of approaches

 http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt

 that confirms your bad news that monomorphization (C++/D 
 templates) and separate compilation won't play well together. 
 Nor do monomorphization and some advanced type system features 
 work together, but that's less of a worry for D.

Well, in that paper they make a bit too hard statement - such model implies certain limitations for separate compilations (either explicit instantiation or having access to sources) but does not destroy completely. No silver bullet here, every approach has its own pros and cons.

Yeah, I agree, there are probably some tricks to make some things better, but overall it's a good description of the problem. Like you say, each approach has tradeoffs. For a systems programming language, I think monomorphization is best. -- Brian
Aug 22 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 21 Aug 2013 18:50:35 +0200
"Ramon" <spam thanks.no> wrote:
 
 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).
 

Even if we assume Moore's law is as alive and well as ever, a related note is that software tends to expand to fill the available computational power. When I can get slowdown in a text-entry box on a 64-bit multi-core, I know that hardware and Moore's law, practically speaking, have very little effect on real performance. At this point, it's code that affects performance far more than anything else. When we hail the great performance of modern web-as-a-platform by the fact that it allows an i7 or some such to run Quake as well as a Pentium 1 or 2 did, then we know Moore's law effectively counts for squat - performance is no longer about hardware, it's about not writing inefficient software. Now I'm certainly not saying that we should try to wring every last drop of performance out of every place where it doesn't even matter (like C++ tends to do). But software developers' belief in Moore's law has caused many of them to inadvertently cancel out, or even reverse, the hardware speedups with code inefficiencies (which are *easily* compoundable, and can and *do* exceed the 3x slowdown you claimed in another post was unrealistic) - and, as JS-heavy web apps prove, they haven't even gotten considerably more reliable as a result (Not that JS is a good example of a reliability-oriented language - but a lot of people certainly seem to think it is).
Aug 22 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 22, 2013 at 03:28:34PM -0400, Nick Sabalausky wrote:
 On Wed, 21 Aug 2013 18:50:35 +0200
 "Ramon" <spam thanks.no> wrote:
 
 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).
 

Even if we assume Moore's law is as alive and well as ever, a related note is that software tends to expand to fill the available computational power. When I can get slowdown in a text-entry box on a 64-bit multi-core, I know that hardware and Moore's law, practically speaking, have very little effect on real performance. At this point, it's code that affects performance far more than anything else. When we hail the great performance of modern web-as-a-platform by the fact that it allows an i7 or some such to run Quake as well as a Pentium 1 or 2 did, then we know Moore's law effectively counts for squat - performance is no longer about hardware, it's about not writing inefficient software.

I've often heard the argument that inefficiencies in code is OK, because you can just "ask the customer to upgrade to better hardware", and "nobody runs a 386 anymore". Which, from a business POV, is a profitable outlook -- if you're the one producing the hardware, inefficient software is incentive for the customer to pay you more money to buy faster hardware to run the software. On the contrary, if your software runs *too* well, then customers have no motivation to buy new hardware. This sometimes goes to ludicrous extremes, where an O(n^2) algorithm is justified because "the customer can just upgrade to better hardware", or "next year's CPU will be able to handle this no problem". Until they realize that when n is large (e.g., the customer says "oh I'm running your software with about n=8000), doubling the CPU speed every year just ain't gonna cut it -- you'd be waiting a long many years before your software becomes usable again.
 Now I'm certainly not saying that we should try to wring every last
 drop of performance out of every place where it doesn't even matter
 (like C++ tends to do). But software developers' belief in Moore's law
 has caused many of them to inadvertently cancel out, or even reverse,
 the hardware speedups with code inefficiencies (which are *easily*
 compoundable, and can and *do* exceed the 3x slowdown you claimed in
 another post was unrealistic) - and, as JS-heavy web apps prove, they
 haven't even gotten considerably more reliable as a result (Not that
 JS is a good example of a reliability-oriented language - but a lot of
 people certainly seem to think it is).

Heh. JS? reliable? in the same sentence? Heh. On the flip side, though, it's true that the performance-conscious crowd among programmers have a tendency to premature optimization, producing unmaintainable code in the process. I used to be one of them, so I know. :) A profiler is absolutely essential to identify where the real bottlenecks are. But once identified, sometimes there's no way to make it better except by going low-level and writing it in a systems programming language. Like D. ;-) And sometimes, there *is* no single bottleneck that you can address; you just need the code to be closer to hardware *in general* in order to bridge that last 10% performance gap to reach your target. All those convenient little indirections and virtual method lookups do add up. T -- It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
Aug 22 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky 
wrote:
 On Wed, 21 Aug 2013 18:50:35 +0200
 "Ramon" <spam thanks.no> wrote:
 
 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).
 

Even if we assume Moore's law is as alive and well as ever, a related note is that software tends to expand to fill the available computational power. When I can get slowdown in a text-entry box on a 64-bit multi-core, I know that hardware and Moore's law, practically speaking, have very little effect on real performance. At this point, it's code that affects performance far more than anything else. When we hail the great performance of modern web-as-a-platform by the fact that it allows an i7 or some such to run Quake as well as a Pentium 1 or 2 did, then we know Moore's law effectively counts for squat - performance is no longer about hardware, it's about not writing inefficient software. Now I'm certainly not saying that we should try to wring every last drop of performance out of every place where it doesn't even matter (like C++ tends to do). But software developers' belief in Moore's law has caused many of them to inadvertently cancel out, or even reverse, the hardware speedups with code inefficiencies (which are *easily* compoundable, and can and *do* exceed the 3x slowdown you claimed in another post was unrealistic) - and, as JS-heavy web apps prove, they haven't even gotten considerably more reliable as a result (Not that JS is a good example of a reliability-oriented language - but a lot of people certainly seem to think it is).

I agree. However I feel we should differentiate: On one hand we have "Do not waste 3 bytes or 2 cycles!". I don't think that this a the, or at least not an adequate answer to doubts of Moore's laws eternal validity. On the other hand we have what is commonly referred to as "code bloat". *That's" the point where a diet seems promising and reasonable. And btw., there we are talking megabytes instead of 2 or 5 bytes. Now, while many look in the hobby-programmers corner for the culprits, I'm convinced the real culprits are graphics/gui and the merciless diktat of marketing. The latter because they *want* feature hungry customers and they don't give developers the time needed to *properly* implement, maintain, and repair those features. Often connected to the this is the graphical guys (connected because graphical is what sells; customers rarely pay for optimized algorithm implementations deep down in the code). Probably making myself new enemies I dare to say that gui, colourful and generally graphics is the area of lowest quality code. Simplyfying it somewhat and being blunt I'd state: Chances are that your server will hum along years without problems. If anything with a gui runs some hours without crashing and/or filling up stderr, you can consider yourself lucky. Not meaning to point fingers. But just these days I happened to fall over a new gui project. Guess what? They had a colourful presentation with lots of vanity, pipe dreams and, of course, colours. That matches quite well what I have experienced. Gui/graphical/colour stuff is probably the only area where people seriously do design with powerpoint. I guess that's how they tick. You can as well look at different developers. Guys developing for an embedded system are often hesitating to even use a RTOS. Your average non-gui, say server developer will use some libraries but he will ponder their advantages, size, dependencies and quality. Now enter the graphic world. John, creating some app, say, to collect, show, and sort photos will happily and very generously user whatever library sounds remotely usefull and doesn't run away fast enough. Results? An app on a microcontroller that, say, takes care of building management in some 10K. A server in some 100K. And the funny photo app with 12MB plus another 70MB libraries/dependencies. The embedded sytem will run forever and be forgotten, the server will be rebooted ever other year and the photo app will crash twice a day.
Aug 22 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 22, 2013 at 10:10:36PM +0200, Ramon wrote:
[...]
 Probably making myself new enemies I dare to say that gui, colourful
 and generally graphics is the area of lowest quality code.
 Simplyfying it somewhat and being blunt I'd state: Chances are that
 your server will hum along years without problems. If anything with
 a gui runs some hours without crashing and/or filling up stderr, you
 can consider yourself lucky.
 Not meaning to point fingers. But just these days I happened to fall
 over a new gui project. Guess what? They had a colourful
 presentation with lots of vanity, pipe dreams and, of course,
 colours. That matches quite well what I have experienced.
 Gui/graphical/colour stuff is probably the only area where people
 seriously do design with powerpoint. I guess that's how they tick.

This is also my experience. :) And I don't mean to diss anyone working with GUI code either, but it's true that in the commercial projects that I'm involved in, the GUI component is where the code has rather poor quality. So poor, in fact, that I dread having to look at it at all -- I try to fix the problem in the low-level modules if at all possible, rather than spend 5 days trying to follow the spaghetti code in the GUI module. (Or rather, lasagna code -- some time ago they ditched the old spaghetti-code source base, and rewrote the whole thing from ground up using a class hierarchy -- I suppose in the hope that the code would be cleaner that way. Well, the spaghetti is gone, but now the code that does the real work is buried so deeply under who knows how many layers of abstractions, most of which are not properly designed and very leaky, that a single method call can literally do *anything*. The only reliable way to know what it actually does is to set a breakpoint in the debugger, because it has been overloaded everywhere in the most non-obvious places and nobody knows where the call will actually end up.)
 You can as well look at different developers. Guys developing for an
 embedded system are often hesitating to even use a RTOS. Your
 average non-gui, say server developer will use some libraries but he
 will ponder their advantages, size, dependencies and quality. Now
 enter the graphic world. John, creating some app, say, to collect,
 show, and sort photos will happily and very generously user whatever
 library sounds remotely usefull and doesn't run away fast enough.
 
 Results? An app on a microcontroller that, say, takes care of
 building management in some 10K. A server in some 100K. And the
 funny photo app with 12MB plus another 70MB libraries/dependencies.
 The embedded sytem will run forever and be forgotten, the server
 will be rebooted ever other year and the photo app will crash twice
 a day.

LOL... totally sums up my sentiments w.r.t. GUI-dependent apps. :) I saw through this façade decades ago when Windows 3.1 first came out, and I've hated GUI-based OSes ever since. I stuck to DOS as long as I could through win95 and win98, and then I learned about Linux and I jumped ship and never looked back. But X11 isn't that much better... there are some pretty bloated X11 apps that crash twice a day, too. Sometimes twice an hour. After repeated experiences like that, I decided that CLI is still the most reliable, and far more expressive to begin with. CLI-based apps are generally far more stable, require far less resources, and are *scriptable* and composable, something that GUI apps could never do (or if they could, not very well). I concluded that the only time GUIs are appropriate is when (1) you're working with graphical data like image editing or visualization, and (2) games. I found that (1) is actually doable with CLI tools like imagemagick, and I rarely do (2) anyway. So I dumped my mouse-based window manager for ratpoison, and use my X11 as a glorified text terminal, and now I'm as happy as can be. :-P Or rather, I *will* be happy as can be once I find a suitable replacement for a browser. Browsers are by far the most ridiculously resource-consuming beasts ever, given that all they do is to display some text and graphics and let you click on stuff. On my office PC, the browser is often the one cause of long compile times when its memory-hungry resource grabbing clashes with the linker trying to link (guess what?) the GUI module of the project. RAM-hungry, IO-bound browser + linker linking gigantic bloated object files of GUI module = 30-minute coffee break while I watch the equally RAM-hungry X server paint the screen pixel-by-pixel as the hard drive thrashes itself to death. :-P This 30 minutes easily turns into 1 hour if I actually dare to run two browsers simultaneously (y'know, for debugging purposes -- what I would give to be rid of the responsibility of testing different browsers...). T -- Always remember that you are unique. Just like everybody else. -- despair.com
Aug 22 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
 Or rather, I *will* be happy as can be once I find a suitable
 replacement for a browser. Browsers are by far the most 
 ridiculously
 resource-consuming beasts ever, given that all they do is to 
 display
 some text and graphics and let you click on stuff.

 T

Pretty much describes my feelings too, although I've made my peace with them beasts and like to use xombrero. Although webkit based (translate: bloat) it's relatively(!) modest and is keyboard controllable. I assume you know links2 and w3m, both textmode browsers which support tables, frames, and even images. links2 (or was it elinks?) even supported javascript for some time. You also might like that links by default is non-graphic and needs a commandline switch to go graphical. R
Aug 22 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
On Thursday, 22 August 2013 at 10:34:58 UTC, John Colvin wrote:
 On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson 
 Little wrote:
 - array operations (int[] a; int[]b; auto c = a * b;)
  - I don't think these are automagically SIMD'd, but there's 
 always hope =D

That isn't allowed. The memory for c must be pre-allocated, and the expression then becomes c[] = a[] * b[];

Oops, that was what I meant.
 Is it SIMD'd?

 It depends. There is a whole load of hand-written assembler for 
 simple-ish expressions on builtin types, on x86. x86_64 is only 
 supported with 32bit integer types because I haven't finished 
 writing the rest yet...

 However, I'm not inclined to do so at the moment as we need a 
 complete overhaul of that system anyway as it's currently a 
 monster*.  It needs to be re-implemented as a template 
 instantiated by the compiler, using core.simd. Unfortunately 
 it's not a priority for anyone right now AFAIK.

That's fine. I was under the impression that it didn't SIMD at all, and that SIMD only works if explicitly stated. I assume this is something that can be done at runtime: int[] a = [1, 2, 3]; int[] b = [2, 2, 2]; auto c = a[] * b[]; // dynamically allocates on the stack; computes w/SIMD writeln(c); // prints [2, 4, 6] I haven't yet needed this, but it would be really nice... btw, it seems D does not have dynamic allocation. I know C99 does, so I know this is technically possible. Is this something we could get? If so, I'll start a thread about it.
 *
 hand-written asm loops. If fully fleshed out there would be:
   ((aligned + unaligned + legacy mmx) * (x86 + x64) + fallback 
 loop)
   * number of supported expressions * number of different types
 of them. Then there's unrolling considerations. See 
 druntime/src/rt/arrayInt.d

Aug 22 2013
prev sibling next sibling parent "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 22 August 2013 at 23:59:59 UTC, H. S. Teoh wrote:
 On Thu, Aug 22, 2013 at 10:10:36PM +0200, Ramon wrote:
 [...]
 Probably making myself new enemies I dare to say that gui, 
 colourful
 and generally graphics is the area of lowest quality code.


All areas are bad, given the way software projects are managed. The consulting projects I work on, are for Fortune 500 companies, always with at least three development sites and some extent of off-shoring work. GUI, embedded, server, database, it doesn't matter. All code is crap given the amount of time, money and developer quality assigned to the projects. Usually the top developers in the teams try to save the code, but there is only so much one can do, when the ratio between both classes of developers so big is as a way to make the projects profitable. So the few heroes that at the beginning of each project try to fix the situation, eventually give around the middle of the project. The customers don't care as long as the software works as intended.
 [...]
 LOL... totally sums up my sentiments w.r.t. GUI-dependent apps. 
 :)

 I saw through this façade decades ago when Windows 3.1 first 
 came out,
 and I've hated GUI-based OSes ever since. I stuck to DOS as 
 long as I
 could through win95 and win98, and then I learned about Linux 
 and I
 jumped ship and never looked back. But X11 isn't that much 
 better...
 there are some pretty bloated X11 apps that crash twice a day, 
 too.

Funny, I have a different experience. Before replacing my ZX Spectrum with a PC, I already knew Amiga and Atari ST systems. And IDEs on those environments as well. So I always favored GUI environments over CLI. For me, personally, the CLI is good when doing system administration, or programming related tasks that can benefit from the usual set of tricks with commands and pipes. For everything else nothing like keyboard+mouse and a nice GUI environment. Personal opinion, to each its own. -- Paulo
Aug 22 2013
prev sibling next sibling parent Gour <gour atmarama.net> writes:
On Mon, 19 Aug 2013 22:18:04 +0200
"Ramon" <spam thanks.no> wrote:

 Sorry, this is a long and big post. But then, so too is my way=20
 that led me here; long, big, troublesome. And I thought that my=20
 (probably not everyday) set of needs and experiences might be=20
 interesting or useful for some others, too.

Thank you very much for this post. I was considering to use D for quite some time for multi-platform gui project, but was not satisfied with the state of its GUI bindings (only gtkd although someone was working on wx bindings, but, afaik, nothing happened) as well as non-stability of the language itself. That led me to research and try some other languages, starting with OCaml, then explored .NET/Mono platform and languages like F# (even Cobra). On the other end of the spectrum I've tried some obscure ones like Nimrod and finally considered Ada as the most robust/safe option with decent options for GUI (GTK & Qt). Your post and another thread 'DQuick a GUI Library (prototype)' makes me optimistic that it would be possible to use D as the 'general programming language' sutiable for writing GUI apps as well. Sincerely, Gour --=20 A person who is not disturbed by the incessant flow of=20 desires =E2=80=94 that enter like rivers into the ocean, which is=20 ever being filled but is always still =E2=80=94 can alone achieve=20 peace, and not the man who strives to satisfy such desires. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Aug 23 2013
prev sibling next sibling parent "qznc" <qznc web.de> writes:
On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky 
wrote:
 On Wed, 21 Aug 2013 18:50:35 +0200
 "Ramon" <spam thanks.no> wrote:
 
 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).
 

Even if we assume Moore's law is as alive and well as ever, a related note is that software tends to expand to fill the available computational power. When I can get slowdown in a text-entry box on a 64-bit multi-core, I know that hardware and Moore's law, practically speaking, have very little effect on real performance. At this point, it's code that affects performance far more than anything else. When we hail the great performance of modern web-as-a-platform by the fact that it allows an i7 or some such to run Quake as well as a Pentium 1 or 2 did, then we know Moore's law effectively counts for squat - performance is no longer about hardware, it's about not writing inefficient software. Now I'm certainly not saying that we should try to wring every last drop of performance out of every place where it doesn't even matter (like C++ tends to do). But software developers' belief in Moore's law has caused many of them to inadvertently cancel out, or even reverse, the hardware speedups with code inefficiencies (which are *easily* compoundable, and can and *do* exceed the 3x slowdown you claimed in another post was unrealistic) - and, as JS-heavy web apps prove, they haven't even gotten considerably more reliable as a result (Not that JS is a good example of a reliability-oriented language - but a lot of people certainly seem to think it is).

Moore's law is fine. The problem is power nowadays. Either the devices is mobile, which means we should try to save battery, or performance is limited by cooling. MOre detail: http://beza1e1.tuxen.de/articles/power_wall.html
Aug 23 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 23 August 2013 at 05:28:22 UTC, Tyler Jameson Little 
wrote:
 I assume this is something that can be done at runtime:

     int[] a = [1, 2, 3];
     int[] b = [2, 2, 2];
     auto c = a[] * b[]; // dynamically allocates on the stack; 
 computes w/SIMD
     writeln(c); // prints [2, 4, 6]

This would be pretty trivial to implement but the question is whether it's a good idea: Heap allocation is out of the question as it's much too slow to be hidden behind what are supposed to be fast vector operations. Explicit runtime stack allocation could work, but it's not something we do much of in D. I know Maxime (https://github.com/maximecb/Higgs) uses alloca a bit, but if I remember correctly it wasn't all smooth going. What definitely should work, but currently doesn't, is this: int[3] a = [1, 2, 3]; int[3] b = [2, 2, 2]; auto c = a[] * b[]; // statically allocated on stack. as it can be totally taken care of statically by the type system. Actually I think it's just a straight up compiler bug, because this *does* work: int[3] a = [1, 2, 3]; int[3] b = [2, 2, 2]; int[3] c = a[] * b[]; // statically allocated on stack. It looks like it's rejecting the array op before it's worked out what to resolve auto to.
Aug 23 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:
[...]
 Probably making myself new enemies I dare to say that gui, 
 colourful and generally graphics is the area of lowest quality 
 code. Simplyfying it somewhat and being blunt I'd state: 
 Chances are that your server will hum along years without 
 problems. If anything with a gui runs some hours without 
 crashing and/or filling up stderr, you can consider yourself 
 lucky.
 Not meaning to point fingers. But just these days I happened to 
 fall over a new gui project. Guess what? They had a colourful 
 presentation with lots of vanity, pipe dreams and, of course, 
 colours. That matches quite well what I have experienced. 
 Gui/graphical/colour stuff is probably the only area where 
 people seriously do design with powerpoint. I guess that's how 
 they tick.

 You can as well look at different developers. Guys developing 
 for an embedded system are often hesitating to even use a RTOS. 
 Your average non-gui, say server developer will use some 
 libraries but he will ponder their advantages, size, 
 dependencies and quality. Now enter the graphic world. John, 
 creating some app, say, to collect, show, and sort photos will 
 happily and very generously user whatever library sounds 
 remotely usefull and doesn't run away fast enough.

 Results? An app on a microcontroller that, say, takes care of 
 building management in some 10K. A server in some 100K. And the 
 funny photo app with 12MB plus another 70MB 
 libraries/dependencies. The embedded sytem will run forever and 
 be forgotten, the server will be rebooted ever other year and 
 the photo app will crash twice a day.

Well, I'm a friend of GUIs simply because with a GUI everyone can use computers not just tech-savvies, and that's what computers are there for, aren't they? The problem are not the GUIs, I think, but the mentality. MVC hardly ever works in real life due to constraints in framework design or deadlines. Cocoa if used sensibly is great. But most of the time you don't have proper MVC because GUI frameworks "seduce" people to do sh*it like bool saveText() { text = textArea.getText(); // View!!! You're mad! savek(text); return Arghhhh!; } instead of bool saveText() { text = model.getText(); // Model! Good man youself! save(text); return fine; } It's the "bolt-on" mentality that ruins things, which is partly due to deadlines. As one guy once said to me (after I had complained about a quick and dirty implementation) "We have the choice between doing it right and doing it right NOW!" Ain't no more to say. Also, sadly enough, technologies that were never meant to be for GUIs are being used for GUI design. PHP and JS (shudder!!!!) Much as I try to keep up a proper MVC pattern, it's useless. Things will always be dirty, disgusting, work-arond-y, unsafe, buggy, you name it. And you just stop giving a sh*t. Ain't no use. And last but not least, a programmer can work for hours on end implementing a clever algorithm, using unit tests, component programming etc etc. Nobody will ever notice. If users see a button that when they press it the screen says "Hello User!", they are forever happy. What goes on under the hood is "boys and their toys".
Aug 23 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Friday, 23 August 2013 at 07:15:49 UTC, Gour wrote:
 On Mon, 19 Aug 2013 22:18:04 +0200
 "Ramon" <spam thanks.no> wrote:

 Sorry, this is a long and big post. But then, so too is my way 
 that led me here; long, big, troublesome. And I thought that 
 my (probably not everyday) set of needs and experiences might 
 be interesting or useful for some others, too.

Thank you very much for this post. I was considering to use D for quite some time for multi-platform gui project, but was not satisfied with the state of its GUI bindings (only gtkd although someone was working on wx bindings, but, afaik, nothing happened) as well as non-stability of the language itself. That led me to research and try some other languages, starting with OCaml, then explored .NET/Mono platform and languages like F# (even Cobra). On the other end of the spectrum I've tried some obscure ones like Nimrod and finally considered Ada as the most robust/safe option with decent options for GUI (GTK & Qt). Your post and another thread 'DQuick a GUI Library (prototype)' makes me optimistic that it would be possible to use D as the 'general programming language' sutiable for writing GUI apps as well.

Now, careful, Gour What I wrote was written with close to zero D experience and largely based on spec, gut feeling (W. Bright implements languages since 2+ decades and says straightout that he approached from a pragmatic view; which in my book counts as a bik +) and some logical verification. And it was said from someone who wants at least a large part of Eiffels goodness in a more C/C++ way and look and feel and practical useability. So, this might be pretty far away from what you consider reasonable, important, etc. Yes, I think that D lends itself very well to GUI programming and, more importantly (to me) it's one of the *very* few languages in which a useful, professional and soundly designed GUI lib could be implemented with adequate and reasonable efforts. A warning though (and one I tried to get written in red permanent marker like letters in my own head) when studying D somewhat more (along the D book): Don't underestimate D! One might be led to look at it as some kind of "easier C++ and better done"; it is not. Or, more correctly, It is way more than that and offers a lot of freedom paradigmwise. If GUI is very important to you it might also be useful to look at a small GUI (like lus'a IUP) and tinker along the lines of how this would, could, and should be done in D and at how it was actually done e.g. with the gtk binding. I hope you'll enjoy D as much as I'm beginning to do ;)
Aug 23 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Friday, 23 August 2013 at 10:34:08 UTC, Chris wrote:
 On Thursday, 22 August 2013 at 20:10:37 UTC, Ramon wrote:
 [...]
 Probably making myself new enemies I dare to say that gui, 
 colourful and generally graphics is the area of lowest quality 
 code. Simplyfying it somewhat and being blunt I'd state: 
 Chances are that your server will hum along years without 
 problems. If anything with a gui runs some hours without 
 crashing and/or filling up stderr, you can consider yourself 
 lucky.
 ...

Well, I'm a friend of GUIs simply because with a GUI everyone can use computers not just tech-savvies, and that's what computers are there for, aren't they? The problem are not the GUIs, I think, but the mentality. MVC hardly ever works in real life due to constraints in framework design or deadlines. Cocoa if used sensibly is great. But most of the time you don't have proper MVC because GUI frameworks "seduce" people to do sh*it like

Oh, I'm not at all anti-GUI "politically". I don't like anything graphical (incl. X, Photoshop and pretty everything with pixels and colours) for *pragmatic* reasons. Actually I *do* see the advantages of a GUI and value them. And I detest them for being sloppily designed along a set of criteria DTP guys or artist might consider great but missing simple, everyday needs. I detest them for usually being implemented in an unsound way and generously wasting Megabytes and resources and ... (*pushing brake*) Just look at a modern browser. It happily eats up around 200 - 300 MB Ram and a good part of the CPU's cycles. And that for 1 person. Now look at a server. It walks and works and dances with 1% to 10% of memory, a fraction of CPU cycles and serves hundreds of users. Look at a smartphone ...
 It's the "bolt-on" mentality that ruins things, which is partly 
 due to deadlines. As one guy once said to me (after I had 
 complained about a quick and dirty implementation) "We have the 
 choice between doing it right and doing it right NOW!" Ain't no 
 more to say.

Right you are. But then, this is also true for anyone else. Pretty every software (in a company) is created with tight deadlines and "design", priorities, and features dictated by Marketing and product management (read: marketing/sales). It's a sad state of affairs but quite probably the most efficient way to very considerably increase product and code quality within a very shiort time is to shot some marketing people.(No, Obelix, you may not kill some graphic artists "while we are at it")
 Also, sadly enough, technologies that were never meant to be 
 for GUIs are being used for GUI design. PHP and JS 
 (shudder!!!!) Much as I try to keep up a proper MVC pattern, 
 it's useless. Things will always be dirty, disgusting, 
 work-arond-y, unsafe, buggy, you name it. And you just stop 
 giving a sh*t. Ain't no use.

Hey, didn't they tell you? PHP and JS are freedom technologies, enabling everyone to .... - well, now they actually *do* it and we know what the Bible was about speaking of hell and unbearable pain. Where is Obelix? His attitude ("may I kill some?") might come in handy ...
 And last but not least, a programmer can work for hours on end 
 implementing a clever algorithm, using unit tests, component 
 programming etc etc. Nobody will ever notice. If users see a 
 button that when they press it the screen says "Hello User!", 
 they are forever happy. What goes on under the hood is "boys 
 and their toys".

Nope. Unless, of course, Joe and Mary "I'll gladly click on anything and btw. Mr. Bob is cool" are your reference. Listen: Your reference is quality, realiability, even elegance (an excellent indicator), maybe performance and yourself knowing you did it well. Don't give Joe and Mary any power they wouldn't know how to use anyway. And btw: Probably Joe and Mary won't know about or even understand your work. But they *will* notice that your stuff works reliably and well.
Aug 23 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Friday, 23 August 2013 at 14:14:47 UTC, Ramon wrote:
 Listen: Your reference is quality, realiability, even elegance 
 (an excellent indicator), maybe performance and yourself 
 knowing you did it well. Don't give Joe and Mary any power they 
 wouldn't know how to use anyway.
 And btw: Probably Joe and Mary won't know about or even 
 understand your work. But they *will* notice that your stuff 
 works reliably and well.

Yes, of course. But shiney little buttons impress people and often the GUI logic is neglected due to a "Click, it works! Let's move on to something else" mentality. A lot of apps out there don't have a proper MVC architecture (look wxPython or Tkinter apps). It's just so easy to be neglegent.
Aug 23 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Friday, 23 August 2013 at 14:30:06 UTC, Chris wrote:
 On Friday, 23 August 2013 at 14:14:47 UTC, Ramon wrote:
 Listen: Your reference is quality, realiability, even elegance 
 (an excellent indicator), maybe performance and yourself 
 knowing you did it well. Don't give Joe and Mary any power 
 they wouldn't know how to use anyway.
 And btw: Probably Joe and Mary won't know about or even 
 understand your work. But they *will* notice that your stuff 
 works reliably and well.

Yes, of course. But shiney little buttons impress people and often the GUI logic is neglected due to a "Click, it works! Let's move on to something else" mentality. A lot of apps out there don't have a proper MVC architecture (look wxPython or Tkinter apps). It's just so easy to be neglegent.

Absolutely, Chris, I get your point and I do not disagree. But, to be fair: We *all* are in some way or another guilty of that sin. Do we, for instance, all really see, value and appreciate the math behind behind many good things? Or do we, let's be honest, usually just say "Wow, D has cool dynamic arrays, that makes my life easier or Yowza, TLS 1.2 offers considerable security"? Frankly, most and that includes programmers, do not even make the effort to properly learn and understand the basics so as to, e.g. user the proper chain mode. I have an image that helps me. I see my "other" grandpa (actually a neighbour) having worked with wood, looking at his workpiece, refining it again a little until finally he looks at it and is content and everythings just fits nicely.
Aug 23 2013
prev sibling next sibling parent Gour <gour atmarama.net> writes:
On Fri, 23 Aug 2013 15:35:19 +0200
"Ramon" <spam thanks.no> wrote:

 If GUI is very important to you it might also be useful to look
 at a small GUI (like lus'a IUP) and tinker along the lines of how
 this would, could, and should be done in D and at how it was
 actually done e.g. with the gtk binding.

I explored that path - see e.g.: http://article.gmane.org/gmane.comp.lib.iup.user/368 so it's a no got for multi-platform app with required i18n support.
 I hope you'll enjoy D as much as I'm beginning to do ;)

Let's see... Sincerely, Gour -- For him who has conquered the mind, the mind is the best of friends; but for one who has failed to do so, his mind will remain the greatest enemy. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Aug 23 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ramon:

 One obious (or seemingly obvious) solution was Ada. Well, no, 
 it wasn't. Maybe, even probably, if I had to develop low level 
 stuff for embedded stuff but not for a large application. And, 
 that was a killer for me, Ada does not really support easily 
 resizable arrays. To make things worse, while there nowadays is 
 Gnat, a nice modern IDE, there is a major lack of libraries.

 Falling over the famous Ariane 5 article

The Ariane 5 failure shows that Ada programs are not perfect/infallible. But that's true for most languages :-) Despite Ada has several problems and flaws, it still has some advantages over D. This is one of the hundreds of RosettaCode tasks written in Ada: http://rosettacode.org/wiki/Universal_Turing_machine#Ada If you compare that Ada version with my laboriously written D entry (and you can perform a similar comparison with several other tasks in that site) you see how the D entry replaces tons of tests done statically by the Ada program with run-time tests, like: this(const ref TuringMachine tm_) { immutable errMsg = "Invalid input."; enforce(!tm_.runningStates.empty, errMsg); enforce(!tm_.haltStates.empty, errMsg); enforce(!tm_.symbols.empty, errMsg); enforce(tm_.rules.length, errMsg); enforce(tm_.runningStates.canFind(tm_.initialState), errMsg); enforce(tm_.symbols.canFind(tm_.blank), errMsg); const allStates = tm_.runningStates ~ tm_.haltStates; foreach (const s; tm_.rules.keys.to!(dchar[])().sort()) enforce(tm_.runningStates.canFind(s), errMsg); foreach (const aa; tm_.rules.byValue) foreach (/*const*/ s, const rule; aa) { enforce(tm_.symbols.canFind(s), errMsg); enforce(tm_.symbols.canFind(rule.toWrite), errMsg); enforce(allStates.canFind(rule.nextState), errMsg); } Despite those tests done by the Ada entry are semantically simple, they are numerous and good, and I have used a lot of energy to write the most statically safe D entry. Probably working even more you can make the D entry a bit more statically safe (eventually you could reach the level of Ada code) but the amount of work and code becomes excessive, and the resulting D code becomes unnatural, and rather not idiomatic. On this Ada is still a winner :-) Bye, bearophile
Aug 25 2013
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 29.08.2013 15:33, Gour pisze:
 On Sun, 25 Aug 2013 17:06:27 +0200
 "bearophile" <bearophileHUGS lycos.com> wrote:

 Probably working even more you can make the D entry a bit more
 statically safe (eventually you could reach the level of Ada code) but
 the amount of work and code becomes excessive, and the resulting D
 code becomes unnatural, and rather not idiomatic.

Still considering whether to focus on Ada or D for my project, I wonder if D can do stuff like (from wikipedia page): type Day_type is range 1 .. 31; type Month_type is range 1 .. 12; type Year_type is range 1800 .. 2100; type Hours is mod 24;

These are refinement types (I call them 'views') and I have half-written DIP for this. However, I doubt that it will be accepted. I would rather enable 'View pattern' by allowing contracts and invariants in release mode. They still could be prepended with debug directive to establish the old behaviour: struct S { debug invariant() { ... } } void fn() debug in { ... } debug out(result) { ... } body { ... }
Aug 29 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/29/2013 09:17 PM, bearophile wrote:
 Piotr Szturmaj:

 These are refinement types (I call them 'views') and I have
 half-written DIP for this. However, I doubt that it will be accepted.

I'll be quite interested by such DIP. Even if your DIP will be refused, it could still produce several useful consequences.

Why not build something rather general? struct Hour{ int hour; IsTrue[0 <= hour && hour <= 23] proof; } terminating correct pure nothrow safe{ // additional attributes // allow the compiler to erase proofs at run time in a modular fashion // to maintain efficiency. alias IsTrue[bool a] = Prop[a === true]; // (selection of intrinsic facts about built-in operators) IsTrue[a && b] conj[bool a,bool b](IsTrue[a] x, IsTrue[b] y); IsTrue[a] projA[bool a,bool b](IsTrue[a && b] ab); IsTrue[b] projB[bool a,bool b](IsTrue[a && b] ab); IsTrue[a <= c] letrans[int a,int b,int c] (IsTrue[a <= b] aleb, IsTrue[b <= c] blec); } struct WorkingHour{ int hour; IsTrue[0 <= hour && hour <= 12] proof; correct // meaning does not throw an error or segfault Hour toHour()out(r){assert(r.hour==hour);}body{// compile-time check return Hour(hour, // an explicit proof that the hour is actually in range conj(projA(proof), letrans(projB(proof), IsTrue[12 <= 23].init)) ); } alias toHour this; } (Maybe there is a better choice for the syntax.) The basic idea is to extend the type system slightly such that the compiler becomes able to type check proofs talking about program behaviour. A flow analysis ensures that proofs are properly updated. It would then become possible to build arbitrary refinement types: bool isPrime(int x){ return iota(3,x).all!(a=>!!(x%a)); } struct Prime{ int prime; IsTrue[isPrime(prime)] proof; } Prime seven = Prime(7,IsTrue[isPrime(7)].init); // proof by CTFE assert(isPrime(x)); auto foo = Prime(x,IsTrue[isPrime(x)].init); // proof by runtime check and flow analysis auto bar = Prime(y,IsTrue[isPrime(y)].init); // error, disabled this This could also be used without runtime overhead eg. inside a correctness proof for a prime sieve, though this necessitates a slightly larger apparatus than presented here.
Aug 29 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/30/2013 01:35 AM, Timon Gehr wrote:
 bool isPrime(int x){ return iota(3,x).all!(a=>!!(x%a)); }

bool isPrime(int x){ return 1<x && iota(3,x).all!(a=>!!(x%a)); }
Aug 30 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/30/2013 11:14 AM, deadalnix wrote:
 On Friday, 30 August 2013 at 08:10:24 UTC, Timon Gehr wrote:
 On 08/30/2013 01:35 AM, Timon Gehr wrote:
 bool isPrime(int x){ return iota(3,x).all!(a=>!!(x%a)); }

bool isPrime(int x){ return 1<x && iota(3,x).all!(a=>!!(x%a)); }

iota(3, to!int(sqrt(x)))

http://en.wikipedia.org/wiki/AKS_primality_test
Aug 30 2013
prev sibling next sibling parent "Paulo Pinto" <pjmp progtools.org> writes:
On Sunday, 25 August 2013 at 15:06:28 UTC, bearophile wrote:
 Ramon:

 One obious (or seemingly obvious) solution was Ada. Well, no, 
 it wasn't. Maybe, even probably, if I had to develop low level 
 stuff for embedded stuff but not for a large application. And, 
 that was a killer for me, Ada does not really support easily 
 resizable arrays. To make things worse, while there nowadays 
 is Gnat, a nice modern IDE, there is a major lack of libraries.

 Falling over the famous Ariane 5 article

The Ariane 5 failure shows that Ada programs are not perfect/infallible. But that's true for most languages :-)

Ariane 5 just showed what happens when engineers reuse code without proper testing. It could happen in any language. -- Paulo
Aug 25 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
Well, I had good reason not to mention Ariane5. Looking at that
particular problem, D would have helped, too and roughly in the
same way as Eiffel that is, by doing some debug runs with the
current (Ariane5) values; then dbc could have helped spot the
problem.

I did, btw, not at all intend to bash Ada. From what I can see,
Ada is well alive and has considerably more users than Eiffel
and, at least for the time being, D. Looking at the type of user,
usually not newbies but experienced software engineers, tells me
that Ada is alive and well for a reason.

As for language comparisons or shoot outs, I don't care that
much. I tend to look whether a language has a sound
implementation of some of the major concepts and paradigms,
whether it's consistent(ly implemented) and whether it has
dropped out of academia or rather had an evolutionary birth,
preferably with lots of experience behind it.

And yes, one point I keep in mind is what (in my minds eye) is
the point to be learned from Ariane5: Humans aren't good at micro
bookkeeping large numbers of details - computers are.
Aug 25 2013
prev sibling next sibling parent "Stephan Schiffels" <stephan_schiffels mac.com> writes:
Nice! I cannot anymore go through all the over 100 replies to 
this, sorry if someone else has suggested this:

You should write this article (tidied up a bit) in a blog or 
somewhere more public on the web! Here in this forum, things are 
not as public as they could be!
But thanks for sharing anyway!

Stephan


On Monday, 19 August 2013 at 20:18:06 UTC, Ramon wrote:

 Sorry, this is a long and big post. But then, so too is my way 
 that led me here; long, big, troublesome. And I thought that my 
 (probably not everyday) set of needs and experiences might be 
 interesting or useful for some others, too.
 And, of course, I confess it, I just feel like throwing a very 
 big "THANK YOU" at D's creators and makers. Thank you!

Aug 25 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Sunday, 25 August 2013 at 22:00:23 UTC, Walter Bright wrote:
 On 8/21/2013 9:50 AM, Ramon wrote:
 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).

While a 5% performance boost is not relevant for consumer apps, it can make an enormous difference for server side apps. For example, if you've got a $100m server farm, 5% means you save $5m, and server farms can be much, much bigger than that.

You are, of course, perfectly right and my professional background would testify you to be correct. But I didn't argue "performance is evil" - my point is "performance vs. realiability" and that it may quite well be a problem to favour performance too much. performance is desirable, no doubt. But reliability is a conditio sine qua non in some environments. To rephrase it: Thank you, Walter Bright, for giving us not only a performant language but one that also offers some very welcome mechanism to support reliability/safety.
Aug 25 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ramon:

 As for language comparisons or shoot outs, I don't care that
 much.

In your first post of this thread you have listed some things you like, some things you don't like, listed points (Arrays, Strings, DBC, modern concurrency, GUI, "defer mechanism", Genericity) you have even assigned points. So while you have not written a direct language comparison, you have analysed specific points. In my answer I've given example that shows why Ada has still something good to offer that's lacking in D. Language comparisons can be sterile, or they can be a chance to learn. Bye, bearophile
Aug 25 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 The good news is that I believe that D is technically capable 
 of beating C++ on performance.

Some suggestions for D to increase its performance: - The frequency of heap allocations (like for arrays and small class instances) of idiomatic D programs should decrease; - The support for simple SIMD-based programming should improve. In the last weeks I have written here some posts on this topic; - It should allow simple and almost-standard means to use GPUs; Bye, bearophile
Aug 25 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Sunday, 25 August 2013 at 22:27:30 UTC, Walter Bright wrote:
 It's also clear to me that unless D achieves performance parity 
 with C++, D is not going to be considered for a lot of 
 applications.

 The good news is that I believe that D is technically capable 
 of beating C++ on performance.

That is probably true for a large part of the existing and potential clientele. But while performance *is* important to me, my concern happens to not be performance to the max but rather the reliability aspects. Gladly, D delivers - and delivers quite well - in that regard, too. As for performance, maybe I'm plain old-school, i.e. falling back to asm (or C as a cross platform "asm") for those few really critical sections. From what I see around here, it seems that D still has quite some minor quirks. With all respect due (and well deserved) I consider it more important to get D really stable and well rounded. Actually, I think, D can afford some time to beat C++ in performance because thanks to it's asm capabilities, it's build in coverage stats and some other goodies, there always *is* some solution for performance. But then, maybe D's beauty in part lies in the fact that it offers a lot regarding safety/reliabilty - and - very nice performance, too ;)
Aug 25 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Sunday, 25 August 2013 at 23:00:21 UTC, bearophile wrote:
 Ramon:

 As for language comparisons or shoot outs, I don't care that
 much.

In your first post of this thread you have listed some things you like, some things you don't like, listed points (Arrays, Strings, DBC, modern concurrency, GUI, "defer mechanism", Genericity) you have even assigned points. So while you have not written a direct language comparison, you have analysed specific points. In my answer I've given example that shows why Ada has still something good to offer that's lacking in D. Language comparisons can be sterile, or they can be a chance to learn.

I think we have a misunderstanding here. I'm *not* against Ada and I think that, of course, comparing languages to a degree is a good thing and sometimes a necessity. I just don't think that slocs or "language A does it in x ms while language B needs y ms" does tell me a lot about a language. Referring to Walter Bright in part, I see that the major problem with server software usually is *not* performance but reliability and safety. Furthermore usually the game is influenced by quite different factors such as the concurreny model chosen. You might well end up having some Lua (interpreted!) server beating the sh*t out of apache (C/C++) simply because the former uses, say, libevent based AIO while the latter uses processes. *That* actually was a major criterion for me (I happen to work a lot in the server world): I wanted a language that offers a sound and elegant "multitask" implementation (à la Ada) as well as *easy* and comfortable access to AIO (which e.g. in Eiffel carries a considerable performance penalty by using the agent model). When I discovered vibe.d I smiled and thought "Of course! It comes almost naturally for a D guy to implement that". What a nice proof of D's capabilities.
Aug 25 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Sunday, 25 August 2013 at 23:26:19 UTC, Ramon wrote:
 But then, maybe D's beauty in part lies in the fact that it 
 offers a lot regarding safety/reliabilty - and - very nice 
 performance, too ;)

One of the theories as to why there are no bears to be found on the African continent is that they are omnivores - i.e. generalists - which in a hugely competitive environment such as Africa, there is no niche in which they will not be beat out by a more specifically adapted animal. My understanding of D is that is like a bear, trying to be good at everything. (Maybe that's why bearophile likes it so much!) But the environment for programming is sufficiently competitive that a language which is merely good at everything without being the best at something could be beaten out of the race simply by not having a niche. Therefore I see an emphasis on one thing to be a strategic advantage even if one's ultimate goal is to build something which is actually good at everything. It certainly seems to turn a lot of heads when D rivals the fastest languages in a performance comparison. Having caught their attention, D can introduce its other advantages. The two which seem most prominent to me are compile time (often 10% of C++'s) and overall expressiveness, but it seems like almost nothing has been completely ignored. I'm more or less a fanboy, so I'm sort of on-board for better or worse. Even so, I sometimes feel like this community is building some kind of Cyberdyne Systems Terminator in their garage or something.
Aug 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 26 August 2013 at 07:32:53 UTC, Zach the Mystic wrote:
 On Sunday, 25 August 2013 at 23:26:19 UTC, Ramon wrote:
 But then, maybe D's beauty in part lies in the fact that it 
 offers a lot regarding safety/reliabilty - and - very nice 
 performance, too ;)

One of the theories as to why there are no bears to be found on the African continent is that they are omnivores - i.e. generalists - which in a hugely competitive environment such as Africa, there is no niche in which they will not be beat out by a more specifically adapted animal. My understanding of D is that is like a bear, trying to be good at everything. (Maybe that's why bearophile likes it so much!)

Human come from Africa. You'll a significant amount of monkey as well.
Aug 26 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Monday, 26 August 2013 at 08:01:51 UTC, deadalnix wrote:
 On Monday, 26 August 2013 at 07:32:53 UTC, Zach the Mystic 
 wrote:
 On Sunday, 25 August 2013 at 23:26:19 UTC, Ramon wrote:
 But then, maybe D's beauty in part lies in the fact that it 
 offers a lot regarding safety/reliabilty - and - very nice 
 performance, too ;)

One of the theories as to why there are no bears to be found on the African continent is that they are omnivores - i.e. generalists - which in a hugely competitive environment such as Africa, there is no niche in which they will not be beat out by a more specifically adapted animal. My understanding of D is that is like a bear, trying to be good at everything. (Maybe that's why bearophile likes it so much!)

Human come from Africa. You'll a significant amount of monkey as well.

D *does* offer roughly the speed of C++ *and* does compile significantly faster *and* offers reasonable strings and dyn arrays *and* offers DbC *and* offers considerable levels of safety. I don't see where this "bear" gets beaten up by lions or other kings of an environment. Yes, it's not yet fully there and still has some quirks. But then, D is not yet a fully grown up bear with decades of a predatory experience. And I for one couldn't care less for 2% less in speed - which I'll more than make up in development time, anyway.
Aug 26 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/08/13 09:32, Zach the Mystic wrote:
 One of the theories as to why there are no bears to be found on the African
 continent is that they are omnivores - i.e. generalists - which in a hugely
 competitive environment such as Africa, there is no niche in which they will
not
 be beat out by a more specifically adapted animal. My understanding of D is
that
 is like a bear, trying to be good at everything. (Maybe that's why bearophile
 likes it so much!)

There were bears in North Africa at least, but they died out fairly recently due to human hunting and other bloodsports: https://en.wikipedia.org/wiki/Atlas_Bear
Aug 26 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/08/13 10:01, deadalnix wrote:
 Human come from Africa. You'll a significant amount of monkey as well.

With the caveat that I'm not an evolutionary biologist, palaeontologist or other appropriate expert, I'd be surprised if generalism vs. specificity was _the_ reason for the lack of sub-Saharan bear species. If you bear in mind (ha!) the evolutionary origin of bears in north America, basic geographical obstacles are likely the major factor in the lack of proliferation beyond the north of the continent. If you dumped a large enough population of bears into the African wild, they'd probably survive and maybe even displace other native species.
Aug 26 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 26 August 2013 at 07:32:53 UTC, Zach the Mystic wrote:
 One of the theories as to why there are no bears to be found on 
 the African continent is that they are omnivores - i.e. 
 generalists - which in a hugely competitive environment such as 
 Africa, there is no niche in which they will not be beat out by 
 a more specifically adapted animal. My understanding of D is 
 that is like a bear, trying to be good at everything. (Maybe 
 that's why bearophile likes it so much!)

 But the environment for programming is sufficiently competitive 
 that a language which is merely good at everything without 
 being the best at something could be beaten out of the race 
 simply by not having a niche. Therefore I see an emphasis on 
 one thing to be a strategic advantage even if one's ultimate 
 goal is to build something which is actually good at everything.

 It certainly seems to turn a lot of heads when D rivals the 
 fastest languages in a performance comparison. Having caught 
 their attention, D can introduce its other advantages. The two 
 which seem most prominent to me are compile time (often 10% of 
 C++'s) and overall expressiveness, but it seems like almost 
 nothing has been completely ignored.

 I'm more or less a fanboy, so I'm sort of on-board for better 
 or worse. Even so, I sometimes feel like this community is 
 building some kind of Cyberdyne Systems Terminator in their 
 garage or something.

I don't agree. I first used D exactly because it is an "all-rounder". For me built-in UTF support was as important a factor as native machine code (performance). The reasons why people would perfer C++ to D are probably habit and convenience. If you've used C++ for years why should you bother to learn D? After all, C++ is well established, well-documented, has loads of libraries, will get you a job more eaily etc. Language features and performance are sometimes over-estimated when it comes to analyzing why a language succeeded. There's convenience, marketing (propaganda) etc etc. Also I don't think that performance alone decides whether a language becomes popular or not. If it were soley down to performance we wouldn't have Java or Python or even Objective-C (which used to be criticized for being too slow). Ease of use, a clear and consistent structure and "write once run everywhere" are very important too. Especially now that developers have to face so many different platforms (Linux, Mac, Windows, Android, iOS) everythnig goes into the direction of "write once ..." That's one of the reasons why Android took off, I think, because developers said "Great, maybe this will put an end to the mobile platform jungle. We'll support Android, less headaches for us!". D has what it takes to make it. I don't think the language itself is the problem. And of course, you will always hear arguments like "But C++ is 1% faster" from people who want to hold on to what they have spent years learning. It's completely understandable, it's like the song "There's a whole in my bucket" (http://en.wikipedia.org/wiki/There%27s_a_Hole_in_My_Bucket). Any excuse.
Aug 26 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Zach the Mystic:

 One of the theories as to why there are no bears to be found on 
 the African continent is that they are omnivores - i.e. 
 generalists - which in a hugely competitive environment such as 
 Africa, there is no niche in which they will not be beat out by 
 a more specifically adapted animal.

I presume the actual causes of the lack of bears in Africa to be more historic and more complex. Generalists are not less fit than specialists, their relative fitness changes as conditions change. And in a place as large as Africa nearly everything happens :-) We could use Kickstarter to fund the introduction of a population of three hundreds sloth bears in Kenya ;-)
 (Maybe that's why bearophile likes it so much!)

I like their omnivorous nature, and indeed my interests are somewhat "omnivore". There is also a cute story: http://cunycomposers.wikispaces.com/file/view/Bisson,+Terry+--+Bears+Discover+Fire.pdf Bye, bearophile
Aug 26 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Monday, 26 August 2013 at 08:18:02 UTC, Joseph Rushton 
Wakeling wrote:
 There were bears in North Africa at least, but they died out 
 fairly recently due to human hunting and other bloodsports:
 https://en.wikipedia.org/wiki/Atlas_Bear

I'm kind of glad I didn't know this until now. Too much information can get in the way of a good metaphor, in my opinion!
Aug 26 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Monday, 26 August 2013 at 09:29:18 UTC, Chris wrote:
 I don't agree. I first used D exactly because it is an 
 "all-rounder". For me built-in UTF support was as important a 
 factor as native machine code (performance). The reasons why 
 people would perfer C++ to D are probably habit and 
 convenience. If you've used C++ for years why should you bother 
 to learn D? After all, C++ is well established, 
 well-documented, has loads of libraries, will get you a job 
 more eaily etc. Language features and performance are sometimes 
 over-estimated when it comes to analyzing why a language 
 succeeded. There's convenience, marketing (propaganda) etc etc.

 Also I don't think that performance alone decides whether a 
 language becomes popular or not. If it were soley down to 
 performance we wouldn't have Java or Python or even Objective-C 
 (which used to be criticized for being too slow). Ease of use, 
 a clear and consistent structure and "write once run 
 everywhere" are very important too. Especially now that 
 developers have to face so many different platforms (Linux, 
 Mac, Windows, Android, iOS) everythnig goes into the direction 
 of "write once ..." That's one of the reasons why Android took 
 off, I think, because developers said "Great, maybe this will 
 put an end to the mobile platform jungle. We'll support 
 Android, less headaches for us!".

I'm trying to analyze the problem from a strategic point of view. For this, I like to invoke the Serenity Prayer (please forgive any distasteful theology): "God, grant me the serenity to accept the things I cannot change, The courage to change the things I can, And wisdom to know the difference." So yeah, you can't control people's choices. The question is, of the things which *can* be done, is it better to focus on well-roundedness, or to press an advantage where one is already ahead of the pack? Which will lead to greater adoption of the language? One thing about performance in particular is that it's easy to measure and easy for the naive person to understand what it is. So there is perhaps a risk of being seduced into sacrificing other things which are more subtle, but equally important, in favor of winning at performance. Yet I think the key point is that that's not going to happen here. I personally have too much respect for the engineers working on this thing to think they would be that short-sighted. But if it's *possible* to grab a performance trophy while still keeping the other flocks well-fed, it seems like a clear strategic win.
Aug 26 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 26 August 2013 at 18:33:55 UTC, Zach the Mystic wrote:
 On Monday, 26 August 2013 at 09:29:18 UTC, Chris wrote:
 I don't agree. I first used D exactly because it is an 
 "all-rounder". For me built-in UTF support was as important a 
 factor as native machine code (performance). The reasons why 
 people would perfer C++ to D are probably habit and 
 convenience. If you've used C++ for years why should you 
 bother to learn D? After all, C++ is well established, 
 well-documented, has loads of libraries, will get you a job 
 more eaily etc. Language features and performance are 
 sometimes over-estimated when it comes to analyzing why a 
 language succeeded. There's convenience, marketing 
 (propaganda) etc etc.

 Also I don't think that performance alone decides whether a 
 language becomes popular or not. If it were soley down to 
 performance we wouldn't have Java or Python or even 
 Objective-C (which used to be criticized for being too slow). 
 Ease of use, a clear and consistent structure and "write once 
 run everywhere" are very important too. Especially now that 
 developers have to face so many different platforms (Linux, 
 Mac, Windows, Android, iOS) everythnig goes into the direction 
 of "write once ..." That's one of the reasons why Android took 
 off, I think, because developers said "Great, maybe this will 
 put an end to the mobile platform jungle. We'll support 
 Android, less headaches for us!".

I'm trying to analyze the problem from a strategic point of view. For this, I like to invoke the Serenity Prayer (please forgive any distasteful theology): "God, grant me the serenity to accept the things I cannot change, The courage to change the things I can, And wisdom to know the difference." So yeah, you can't control people's choices. The question is, of the things which *can* be done, is it better to focus on well-roundedness, or to press an advantage where one is already ahead of the pack? Which will lead to greater adoption of the language? One thing about performance in particular is that it's easy to measure and easy for the naive person to understand what it is. So there is perhaps a risk of being seduced into sacrificing other things which are more subtle, but equally important, in favor of winning at performance. Yet I think the key point is that that's not going to happen here. I personally have too much respect for the engineers working on this thing to think they would be that short-sighted. But if it's *possible* to grab a performance trophy while still keeping the other flocks well-fed, it seems like a clear strategic win.

Yes and no. I've actually given up pointing out language features or even performance to people. Believe it or not, but usually the first questions are things like "Does it have libraries? If it doesn't have a sound library I will not use it ..." And if someone is a die-hard D-hater s/he will always find something like "D doesn't support multi-sync-runtime-polymorphy on reversed backtracking array slicing, so it's useless! C# will have it soon!" I think being an all-rounder is a good approach, you can use it for small script-like projects and big projects with unit tests, component programming etc. So as people ask about features, you just keep ticking the boxes. But if you start to point out one feature in particular, you're going down the slippery road of bit-by-bit language comparison, which will lead you nowhere. I think it would help a lot if we had a "Made with D" list, especially if there are some killer apps or games and the like.
Aug 27 2013
prev sibling next sibling parent Gour <gour atmarama.net> writes:
On Sun, 25 Aug 2013 17:06:27 +0200
"bearophile" <bearophileHUGS lycos.com> wrote:

 Probably working even more you can make the D entry a bit more
 statically safe (eventually you could reach the level of Ada code) but
 the amount of work and code becomes excessive, and the resulting D
 code becomes unnatural, and rather not idiomatic.

Still considering whether to focus on Ada or D for my project, I wonder if D can do stuff like (from wikipedia page): type Day_type is range 1 .. 31; type Month_type is range 1 .. 12; type Year_type is range 1800 .. 2100; type Hours is mod 24; type Weekday is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday); type Date is record Day : Day_type; Month : Month_type; Year : Year_type; end record; subtype Working_Hours is Hours range 0 .. 12; subtype Working_Day is Weekday range Monday .. Friday; Work_Load: constant array(Working_Day) of Working_Hours := (Friday => 6, Monday => 4, others => 10); and ensure type-safety for such custom types? Sincerely, Gour -- You have a right to perform your prescribed duty, but you are not entitled to the fruits of action. Never consider yourself the cause of the results of your activities, and never be attached to not doing your duty. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Aug 29 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 29 August 2013 at 13:33:52 UTC, Gour wrote:
 On Sun, 25 Aug 2013 17:06:27 +0200
 "bearophile" <bearophileHUGS lycos.com> wrote:

 Probably working even more you can make the D entry a bit more
 statically safe (eventually you could reach the level of Ada 
 code) but
 the amount of work and code becomes excessive, and the 
 resulting D
 code becomes unnatural, and rather not idiomatic.

Still considering whether to focus on Ada or D for my project, I wonder if D can do stuff like (from wikipedia page): type Day_type is range 1 .. 31; type Month_type is range 1 .. 12; type Year_type is range 1800 .. 2100; type Hours is mod 24; type Weekday is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday); type Date is record Day : Day_type; Month : Month_type; Year : Year_type; end record; subtype Working_Hours is Hours range 0 .. 12; subtype Working_Day is Weekday range Monday .. Friday; Work_Load: constant array(Working_Day) of Working_Hours := (Friday => 6, Monday => 4, others => 10); and ensure type-safety for such custom types? Sincerely, Gour

just something I whipped up in a few mins: import std.typecons; import std.exception; struct Limited(T, T lower, T upper) { T _t; mixin Proxy!_t; //Limited acts as T (almost) invariant() { enforce(_t >= lower && _t <= upper); } this(T t) { _t = t; } } auto limited(T, T lower, T upper)(T init = T.init) { return Limited!(T, lower, upper)(init); } unittest { enum l = [-4,9]; auto a = limited!(int, l[0], l[1])(); foreach(i; l[0] .. l[1]+1) { a = i; } assertThrown({a = -5;}()); assertThrown({a = 10;}()); } This could be a lot more generic than it is. Redesigning Restricted to hold a pointer to a function that does the check would be one way.
Aug 29 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 29 August 2013 at 14:13:07 UTC, John Colvin wrote:
 This could be a lot more generic than it is. Redesigning 
 Restricted to hold a pointer to a function that does the check 
 would be one way.

Sorry, should read "Limited" not "Restricted" there
Aug 29 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/08/13 16:13, John Colvin wrote:
 struct Limited(T, T lower, T upper)
 {
      T _t;
      mixin Proxy!_t; //Limited acts as T (almost)
      invariant()
      {
          enforce(_t >= lower && _t <= upper);
      }
      this(T t)
      {
          _t = t;
      }
 }

Is the invariant() not going to be stripped out at compile time if you use -release ?
Aug 29 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Joseph Rushton Wakeling:

 Is the invariant() not going to be stripped out at compile time 
 if you use -release ?

Right. assert is enough there. Use enforce() only in special cases, when you need it. Better to minimize the usage of enforce() in library code that has to be called many times. Bye, bearophile
Aug 29 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 29 August 2013 at 14:34:37 UTC, Joseph Rushton 
Wakeling wrote:
 On 29/08/13 16:13, John Colvin wrote:
 struct Limited(T, T lower, T upper)
 {
     T _t;
     mixin Proxy!_t; //Limited acts as T (almost)
     invariant()
     {
         enforce(_t >= lower && _t <= upper);
     }
     this(T t)
     {
         _t = t;
     }
 }

Is the invariant() not going to be stripped out at compile time if you use -release ?

sadly, yes. We need a release version of them, just like we have enforce and assert. Unfortunately in this case it won't be a library solution and will need compiler support.
Aug 29 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 29 August 2013 at 14:37:10 UTC, bearophile wrote:
 Joseph Rushton Wakeling:

 Is the invariant() not going to be stripped out at compile 
 time if you use -release ?

Right. assert is enough there. Use enforce() only in special cases, when you need it. Better to minimize the usage of enforce() in library code that has to be called many times. Bye, bearophile

fair point. I had forgotten that invariant would be stripped out anyway.
Aug 29 2013
prev sibling next sibling parent Gour <gour atmarama.net> writes:
On Thu, 29 Aug 2013 16:13:06 +0200
"John Colvin" <john.loughran.colvin gmail.com> wrote:

 just something I whipped up in a few mins:

[...] Thanks. So, it's possible, but (maybe) it's not as elegant. Sincerely, Gour --=20 A person is said to be established in self-realization and is called a yog=C4=AB [or mystic] when he is fully satisfied by virtue of acquired knowledge and realization. Such a person is situated in transcendence and is self-controlled. He sees everything =E2=80=94 whether it be pebbles, stones or gold =E2=80=94 as the same. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Aug 29 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/08/13 16:41, John Colvin wrote:
 sadly, yes. We need a release version of them, just like we have enforce and
 assert. Unfortunately in this case it won't be a library solution and will need
 compiler support.

You missed my recent thread here, then, and the responses ... :-) I was going to add earlier: you could probably handle this with a rewrite of what Proxy does, but adding the constraint check inside the opDispatch code. Still, I think Gour has a point about Ada's attractiveness if those kinds of value safety checks are a first-class part of the language.
Aug 29 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 29 August 2013 at 14:50:58 UTC, Joseph Rushton 
Wakeling wrote:
 On 29/08/13 16:41, John Colvin wrote:
 sadly, yes. We need a release version of them, just like we 
 have enforce and
 assert. Unfortunately in this case it won't be a library 
 solution and will need
 compiler support.

You missed my recent thread here, then, and the responses ... :-) I was going to add earlier: you could probably handle this with a rewrite of what Proxy does, but adding the constraint check inside the opDispatch code. Still, I think Gour has a point about Ada's attractiveness if those kinds of value safety checks are a first-class part of the language.

opDispatch isn't enough, you need to add to all the operators too. Shouldn't be too hard. I think there's actually quite a lot more D can do in this regard, it's something I've been playing around with for a while. When I have some free time I might look in to it again.
Aug 29 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/08/13 17:03, John Colvin wrote:
 opDispatch isn't enough, you need to add to all the operators too. Shouldn't be
 too hard.

Ahh, you mean all the other op*'s? :-) I guess as you say not hard, I find it a shame that it seems quite finnicky and there is quite a lot of manual work involved.
 I think there's actually quite a lot more D can do in this regard, it's
 something I've been playing around with for a while. When I have some free time
 I might look in to it again.

That would be great to see, especially if it can be made properly generic -- that is, that the constraints can be arbitrary or even functional (e.g. ensuring initialization of a struct before it is used).
Aug 29 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 29 August 2013 at 14:50:18 UTC, Gour wrote:
 On Thu, 29 Aug 2013 16:13:06 +0200
 "John Colvin" <john.loughran.colvin gmail.com> wrote:

 just something I whipped up in a few mins:

[...] Thanks. So, it's possible, but (maybe) it's not as elegant.

Now, let's be fair. While the point you brought up is one that I, too, do very much like with Ada, it's not magic what Ada does. Agreed, Ada has it wrapped in nice syntactic sugar, but in the end such a subtype is just the basic type with range checking done bhind the curtain, while D does it publicly visible and in the open (and, yes, less nicely sugared). In the end it's about the concept, so the relevant question is not "Does D offer the same sugar and wardrobe?" but "does D offer a way to implement that (important) concept other than (C-like) hand inserting range checking code everywhere". The answer is "yes, it does". A by far bigger concern in my minds eye is D's somewhat unlucky DbC mechanism or, more precisely, the somewhat step-son treating by disabling DbC in realease code. I strongly feel that something like " DbC" (and noDbC) would be far more satisfying. A+ - R
Aug 29 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Piotr Szturmaj:

 These are refinement types (I call them 'views') and I have 
 half-written DIP for this. However, I doubt that it will be 
 accepted.

I'll be quite interested by such DIP. Even if your DIP will be refused, it could still produce several useful consequences. Bye, bearophile
Aug 29 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 30 August 2013 at 08:10:24 UTC, Timon Gehr wrote:
 On 08/30/2013 01:35 AM, Timon Gehr wrote:
 bool isPrime(int x){ return iota(3,x).all!(a=>!!(x%a)); }

bool isPrime(int x){ return 1<x && iota(3,x).all!(a=>!!(x%a)); }

iota(3, to!int(sqrt(x)))
Aug 30 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/08/13 18:17, Zach the Mystic wrote:
 I'm kind of glad I didn't know this until now. Too much information can get in
 the way of a good metaphor, in my opinion!

That one about the boiling frog is a bit dodgy as well ... :-)
Aug 30 2013