Re: Foreach Closures?
On 2012-04-13 06:50, Matt Peterson wrote: On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote: I'm pretty sure that the JSON output can _never_ be enough for what we want to do. I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing? When you say "there is a working compiler now", which on is you referring to. DMD, LDC, GDC, SDC or any other? As far as I know neither DMD, LDC or GDC is usable as a library. I have no experience of SDC and don't know in what state it is. But I guess we would have to do some investigation and figure out what the best to do this would be. BTW, there are already IDE's with some kind of frontends available. MonoD, VisualD, Descent (now old) and possibly others. -- /Jacob Carlborg
Re: Measuring the page generation of the forum
On Friday, 13 April 2012 at 02:25:19 UTC, Somedude wrote: Well, it's not really urgent. It's fast enough. Still, collecting statistics over time would have been nice, so that one could analyse the general behaviour of the GC, for instance, by getting an idea of the standard deviation and maximum response time over weeks of use. Such statistics wouldn't be very meaningful due to the highly varying server load, caused by a large number of other websites and services running on the same machine. But I have experienced a response of several seconds once, I don't know where this comes from (although it's most likely one of your reasons). Long page loads are caused by a combination of high server load + RAM cache misses + SQLite queries that require a lot of seeks. I'm quite sure this is the case. BTW, could you repost the source code address ? Thx. There is a link to the source code on the Help page. Oh, I just saw you wrote the max page generation was around 50 ms. When there are no cache misses, yes.
Re: Foreach Closures?
On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote: I'm pretty sure that the JSON output can _never_ be enough for what we want to do. I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing?
Re: Measuring the page generation of the forum
On Thursday, 12 April 2012 at 18:36:01 UTC, SomeDude wrote: Hi, I've noticed a couple of times (i.e very rarely, mind you), that the page generation of the forum had hiccups. Have other people experienced such hiccups ? If yes, I wonder if we saw the GC kicking in, or if it was SQLite's fault (or was it a network latency ?). Anyhow, the forum seems to me a good opportunity to measure the D runtime in action on the server side, and in particular the GC. A few questions : Is the server regularly restarted or is it running smoothly without having to be restarted at all ? Does it measure the time for the page generation ? Would it be interesting to see at the bottom of the page something like "Page generated in xxx ms", when I (or other people) come accross those hiccups, and to collect these data for statistics over a week/month ? I'm pretty sure it is the NG itself. Every news reader I've used has shown some form of "hiccup" If you try making a post under a heavy load you'll get a nice page telling you the load and what it needed to be.
Re: Measuring the page generation of the forum
Le 13/04/2012 03:40, Vladimir Panteleev a écrit : > On Thursday, 12 April 2012 at 18:36:01 UTC, SomeDude wrote: > There are some numbers in the reddit discussion: > > http://www.reddit.com/r/programming/comments/ppre5/the_new_d_online_forum_software_written_in_d/c3rfwte > Oh, I just saw you wrote the max page generation was around 50 ms.
Re: Measuring the page generation of the forum
Le 13/04/2012 04:43, James Miller a écrit : > I doubt that the GC is the source of any real problems. As a web > developer (in PHP no less :S) I can say with authority that most slow > downs are due to waiting on external services and data processing. Some > of the slowest parts of our site are due to heavy database usage where > we have to perform over 100 SQL queries to generate a page. Other > slowdowns are caused by the need to process the data. > > I understand that you want to see how the GC affects the server > performance, but it will be so small that it will be lost in the noise, > a blip in traffic because it's lunchtime and people are watching youtube > in your area will cause a bigger delay than the GC kicking in. > > -- > James Miller I agree, you're probably right.
Re: Measuring the page generation of the forum
* Somedude [2012-04-13 04:25:19 +0200]: > Well, it's not really urgent. It's fast enough. > Still, collecting statistics over time would have been nice, so that one > could analyse the general behaviour of the GC, for instance, by getting > an idea of the standard deviation and maximum response time over weeks > of use. I guess since it can handle much larger loads, the forum server > is not stressed enough to give very meaningful insight under heavy load. > But I have experienced a response of several seconds once, I don't know > where this comes from (although it's most likely one of your reasons). > So collecting real time data would have to be done for each component of > the chain (SQLite, cache, D generated page). Such data would be useful > for any web server anyway. I doubt that the GC is the source of any real problems. As a web developer (in PHP no less :S) I can say with authority that most slow downs are due to waiting on external services and data processing. Some of the slowest parts of our site are due to heavy database usage where we have to perform over 100 SQL queries to generate a page. Other slowdowns are caused by the need to process the data. I understand that you want to see how the GC affects the server performance, but it will be so small that it will be lost in the noise, a blip in traffic because it's lunchtime and people are watching youtube in your area will cause a bigger delay than the GC kicking in. -- James Miller
Re: Measuring the page generation of the forum
Le 13/04/2012 03:40, Vladimir Panteleev a écrit : > On Thursday, 12 April 2012 at 18:36:01 UTC, SomeDude wrote: >> Hi, >> >> I've noticed a couple of times (i.e very rarely, mind you), that the >> page generation of the forum had hiccups. >> Have other people experienced such hiccups ? >> If yes, I wonder if we saw the GC kicking in, or if it was SQLite's >> fault (or was it a network latency ?). > > Long page loads are caused by a combination of high server load + RAM > cache misses + SQLite queries that require a lot of seeks. I still > haven't found the time for the migration to a more powerful server. > Well, it's not really urgent. It's fast enough. Still, collecting statistics over time would have been nice, so that one could analyse the general behaviour of the GC, for instance, by getting an idea of the standard deviation and maximum response time over weeks of use. I guess since it can handle much larger loads, the forum server is not stressed enough to give very meaningful insight under heavy load. But I have experienced a response of several seconds once, I don't know where this comes from (although it's most likely one of your reasons). So collecting real time data would have to be done for each component of the chain (SQLite, cache, D generated page). Such data would be useful for any web server anyway. BTW, could you repost the source code address ? Thx. >> Is the server regularly restarted or is it running smoothly without >> having to be restarted at all ? > > It seems to run fine for weeks on end. Nice. > >> Does it measure the time for the page generation ? Would it be >> interesting to see at the bottom of the page something like "Page >> generated in xxx ms", when I (or other people) come accross those >> hiccups, and to collect these data for statistics over a week/month ? > > There are some numbers in the reddit discussion: > > http://www.reddit.com/r/programming/comments/ppre5/the_new_d_online_forum_software_written_in_d/c3rfwte > Nice, now I remember having read this post.
Re: Measuring the page generation of the forum
Le 13/04/2012 01:55, Nick Sabalausky a écrit : > "SomeDude" wrote in message > news:mjectyruiwxebfrke...@forum.dlang.org... >> On Thursday, 12 April 2012 at 18:36:01 UTC, SomeDude wrote: >> So noone thinks this could be a good idea ? > > I like it. (And the StopWatch in std.datetime would make it super easy. > StopWatch is freaking awesome.) But newgroup/forum posts don't always get > responses after only a few hours. And even a total lack of replies shouldn't > be mistaken for a "no" vote. So I wouldn't worry too much about that. > OK > Could you be more specific what you mean by "hiccup"? I assume you mean that > once in a while a page load will be slower than usual. If so, about how > long? > Yeah, once I was surprised, because it took several seconds I believe. > My wild random guesses, aside from your ideas, are that maybe your request > just happens to occur at the right time for the forum to decide to refresh > its cache (if it even works that way). Or maybe it could be related to the > newsgroup server (which the web forum is just a frontend for) being > temporarily down due to high load (which unfortunately has been happening a > lot lately). Vladimir would probably have a better idea what might be going > on than I would, though. > Ah, I forgot about the newsgroup server.
Re: Measuring the page generation of the forum
On Thursday, 12 April 2012 at 18:36:01 UTC, SomeDude wrote: Hi, I've noticed a couple of times (i.e very rarely, mind you), that the page generation of the forum had hiccups. Have other people experienced such hiccups ? If yes, I wonder if we saw the GC kicking in, or if it was SQLite's fault (or was it a network latency ?). Long page loads are caused by a combination of high server load + RAM cache misses + SQLite queries that require a lot of seeks. I still haven't found the time for the migration to a more powerful server. Is the server regularly restarted or is it running smoothly without having to be restarted at all ? It seems to run fine for weeks on end. Does it measure the time for the page generation ? Would it be interesting to see at the bottom of the page something like "Page generated in xxx ms", when I (or other people) come accross those hiccups, and to collect these data for statistics over a week/month ? There are some numbers in the reddit discussion: http://www.reddit.com/r/programming/comments/ppre5/the_new_d_online_forum_software_written_in_d/c3rfwte
Re: The Downfall of Imperative Programming
On 04/12/2012 11:02 AM, Paulo Pinto wrote: And yet IBM still is the number one champion in patents. Or just, because they play nice most of the time with open source they are excused? I don't know why you are talking about IBM. Maybe you should reread my post. I'm talking about Microsoft because you brought them up.
Re: Measuring the page generation of the forum
On Apr 12, 2012 4:29 PM, "SomeDude" wrote > > So noone thinks this could be a good idea ? I like it. I usually put a comment in the bottom of my pages but since the form is implemented in D it would nice to actually display it somewhere.
Re: Measuring the page generation of the forum
"SomeDude" wrote in message news:mjectyruiwxebfrke...@forum.dlang.org... > On Thursday, 12 April 2012 at 18:36:01 UTC, SomeDude wrote: >> Hi, >> >> I've noticed a couple of times (i.e very rarely, mind you), that the page >> generation of the forum had hiccups. >> Have other people experienced such hiccups ? >> If yes, I wonder if we saw the GC kicking in, or if it was SQLite's fault >> (or was it a network latency ?). >> >> Anyhow, the forum seems to me a good opportunity to measure the D runtime >> in action on the server side, and in particular the GC. >> A few questions : >> Is the server regularly restarted or is it running smoothly without >> having to be restarted at all ? >> Does it measure the time for the page generation ? Would it be >> interesting to see at the bottom of the page something like "Page >> generated in xxx ms", when I (or other people) come accross those >> hiccups, and to collect these data for statistics over a week/month ? > > So noone thinks this could be a good idea ? I like it. (And the StopWatch in std.datetime would make it super easy. StopWatch is freaking awesome.) But newgroup/forum posts don't always get responses after only a few hours. And even a total lack of replies shouldn't be mistaken for a "no" vote. So I wouldn't worry too much about that. Could you be more specific what you mean by "hiccup"? I assume you mean that once in a while a page load will be slower than usual. If so, about how long? My wild random guesses, aside from your ideas, are that maybe your request just happens to occur at the right time for the forum to decide to refresh its cache (if it even works that way). Or maybe it could be related to the newsgroup server (which the web forum is just a frontend for) being temporarily down due to high load (which unfortunately has been happening a lot lately). Vladimir would probably have a better idea what might be going on than I would, though.
Re: Measuring the page generation of the forum
On Thursday, 12 April 2012 at 18:36:01 UTC, SomeDude wrote: Hi, I've noticed a couple of times (i.e very rarely, mind you), that the page generation of the forum had hiccups. Have other people experienced such hiccups ? If yes, I wonder if we saw the GC kicking in, or if it was SQLite's fault (or was it a network latency ?). Anyhow, the forum seems to me a good opportunity to measure the D runtime in action on the server side, and in particular the GC. A few questions : Is the server regularly restarted or is it running smoothly without having to be restarted at all ? Does it measure the time for the page generation ? Would it be interesting to see at the bottom of the page something like "Page generated in xxx ms", when I (or other people) come accross those hiccups, and to collect these data for statistics over a week/month ? So noone thinks this could be a good idea ?
Re: foreach and filter
On Thursday, April 12, 2012 19:44:36 Timon Gehr wrote:
> On 04/11/2012 06:08 PM, Russel Winder wrote:
> > Doing something along the lines of:
> > const a = array ( filter! ... ) ;
> > foreach ( i ; a ) { ... }
> >
> > works fine. Question 1 though is why I can't use immutable here, why I
> > have to use const.
>
> 'array' is not pure for some reason. This should be fixed.
Probably a result of various array-related stuff which should be pure but isn't
(e.g. Appender and some of what's in object_.d), but I'd have to go dig
through the implementation to see. We have some pull requests though that
should improve that situation for 2.060, and a number of them _must_ be sorted
out for 2.060, because we're looking at making toString pure, and too many
string-related functions (particularly format, text, and to) can't be pure yet
for that to work.
- Jonathan M Davis
Re: foreach and filter
On 04/12/2012 08:08 PM, Steven Schveighoffer wrote:
On Thu, 12 Apr 2012 13:44:36 -0400, Timon Gehr wrote:
On 04/11/2012 06:08 PM, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable here, why I
have to use const.
'array' is not pure for some reason. This should be fixed.
It's implied pure if filter is pure. Templates are auto-pure if all the
functions they call are pure. array should not be specifically marked pure.
This may be what you meant (i.e. it's not being implied as pure), but I
want to be clear what it *should* be.
-Steve
Yes, that is what I meant.
Re: An idea to improve eponymous templates
On 04/12/2012 08:19 PM, Steven Schveighoffer wrote:
On Thu, 12 Apr 2012 14:04:44 -0400, Timon Gehr wrote:
The general idea is useful, but there are issues.
'this' is the wrong keyword for the job. A class or struct instance is
very different from a template instance and the proposed usage would
clash with existing and useful ones. (assuming that it would work for
symbol lookups in addition to declarations)
'template' or maybe 'scope' would be superior choices.
I think static is underused keyword, maybe it should have a dual meaning
here.
In all seriousness, I'm not sure template is right either.
It is better than 'this', because it is unambiguous. I didn't say it was
right. ;)
Scope sounds like a very bad choice to me.
Why? Templates are parameterized scopes.
Are there any eponymous examples where the name of the template is the
first token?
No, there isn't even a declaration that starts with the identifier it
defines.
If so that would clash with declaring a new template.
I would find this weird:
template X(T)
{
alias T template;
template t {
...
}
}
symbol
It looks like you are using template as an alias to T, but the second
'template' inside is using it for creating a new template.
Also, consider this:
template X(T)
{
class template {
static typeof(this) create() { return new typeof(this);}
}
}
I don't think you could realistically use any keyword instead of
typeof(this), I really think the best solution is what we have,
+1.
or use a new keyword.
We certainly don't have enough of those!
Another option is to do something like:
@eponymous template X(T) // changed from Y(T)
{
class Y { } // oops forgot to change this to X!
}
Error: template X did not declare eponymous symbol
At least changes would be loud errors.
-Steve
Well, there is always the possibility of just doing it like this:
template X(T) {
enum X = result; // single line in template body that needs to
change if there is a name change
static if(is(T==int)) enum result = foo;
else static if(is(T==real)) enum result = bar;
else static if(is(T==double)) enum result = baz;
else enum result = qux;
}
Unless someone can come up with a super-elegant way to resolve all the
issues raised, I don't actually think that the proposal adds enough value.
Measuring the page generation of the forum
Hi, I've noticed a couple of times (i.e very rarely, mind you), that the page generation of the forum had hiccups. Have other people experienced such hiccups ? If yes, I wonder if we saw the GC kicking in, or if it was SQLite's fault (or was it a network latency ?). Anyhow, the forum seems to me a good opportunity to measure the D runtime in action on the server side, and in particular the GC. A few questions : Is the server regularly restarted or is it running smoothly without having to be restarted at all ? Does it measure the time for the page generation ? Would it be interesting to see at the bottom of the page something like "Page generated in xxx ms", when I (or other people) come accross those hiccups, and to collect these data for statistics over a week/month ?
Re: An idea to improve eponymous templates
On Thu, Apr 12, 2012 at 08:04:44PM +0200, Timon Gehr wrote:
[...]
> The general idea is useful, but there are issues.
>
> 'this' is the wrong keyword for the job. A class or struct instance is
> very different from a template instance and the proposed usage would
> clash with existing and useful ones. (assuming that it would work for
> symbol lookups in addition to declarations) 'template' or maybe
> 'scope' would be superior choices.
What about "this template"? Clear, self-documenting, and unambiguous.
template X(T) {
alias const(T) this template;
}
T
--
One disk to rule them all, One disk to find them. One disk to bring them all
and in the darkness grind them. In the Land of Redmond where the shadows lie.
-- The Silicon Valley Tarot
Re: An idea to improve eponymous templates
On Thu, 12 Apr 2012 14:04:44 -0400, Timon Gehr wrote:
The general idea is useful, but there are issues.
'this' is the wrong keyword for the job. A class or struct instance is
very different from a template instance and the proposed usage would
clash with existing and useful ones. (assuming that it would work for
symbol lookups in addition to declarations)
'template' or maybe 'scope' would be superior choices.
I think static is underused keyword, maybe it should have a dual meaning
here.
In all seriousness, I'm not sure template is right either. Scope sounds
like a very bad choice to me.
Are there any eponymous examples where the name of the template is the
first token? If so that would clash with declaring a new template.
I would find this weird:
template X(T)
{
alias T template;
template t {
...
}
}
It looks like you are using template as an alias to T, but the second
'template' inside is using it for creating a new template.
Also, consider this:
template X(T)
{
class template {
static typeof(this) create() { return new typeof(this);}
}
}
I don't think you could realistically use any keyword instead of
typeof(this), I really think the best solution is what we have, or use a
new keyword.
Another option is to do something like:
@eponymous template X(T) // changed from Y(T)
{
class Y { } // oops forgot to change this to X!
}
Error: template X did not declare eponymous symbol
At least changes would be loud errors.
-Steve
Re: foreach and filter
On Thu, 12 Apr 2012 13:44:36 -0400, Timon Gehr wrote:
On 04/11/2012 06:08 PM, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable here, why I
have to use const.
'array' is not pure for some reason. This should be fixed.
It's implied pure if filter is pure. Templates are auto-pure if all the
functions they call are pure. array should not be specifically marked
pure.
This may be what you meant (i.e. it's not being implied as pure), but I
want to be clear what it *should* be.
-Steve
Re: An idea to improve eponymous templates
On 04/12/2012 04:21 AM, Reid Levenick wrote:
Firstly, I had no idea where suggestions should go, and I saw a few
others here and thus here I am.
I was writing some code that depended heavily on my own eponymous
templates, and decided to change the names of some of them to make them
more self-documenting. However, after changing the name, I encountered a
long stream of unintelligible errors (to me, I haven't been using D for
a long time) about template instances.
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some templates, as
well as reducing maintenance.
The general idea is useful, but there are issues.
'this' is the wrong keyword for the job. A class or struct instance is
very different from a template instance and the proposed usage would
clash with existing and useful ones. (assuming that it would work for
symbol lookups in addition to declarations)
'template' or maybe 'scope' would be superior choices.
Furthermore, what happens if such a 'this'-template is mixed in into
another template?
Re: foreach and filter
On 04/11/2012 06:08 PM, Russel Winder wrote:
Doing something along the lines of:
const a = array ( filter! ... ) ;
foreach ( i ; a ) { ... }
works fine. Question 1 though is why I can't use immutable here, why I
have to use const.
'array' is not pure for some reason. This should be fixed.
Question 2 is why I can't do:
const a = filter! ... ;
foreach ( i ; a ) { ... }
popFront cannot be const. (And Phobos is not very const correct
anyways). You can try
auto a = filter!foo(cast(const)data);
foreach( i ; a ) { ... }
(Assuming data is a built-in array slice)
Re: An idea to improve eponymous templates
+1 for This
"bearophile" wrote in message news:bcqvpvgjswwdgsfxs...@forum.dlang.org...
Reid Levenick:
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
Other "This" (with upper case)?
Bye,
bearophile
Re: An idea to improve eponymous templates
+1 for This
"bearophile" wrote in message news:bcqvpvgjswwdgsfxs...@forum.dlang.org...
Reid Levenick:
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
Other "This" (with upper case)?
Bye,
bearophile
Re: The Downfall of Imperative Programming
On Thu, Apr 12, 2012 at 05:02:36PM +0200, Paulo Pinto wrote: > On Thursday, 12 April 2012 at 13:36:41 UTC, Jeff Nowakowski wrote: [...] > >Microsoft has also in recent years been very aggressive with their > >patent portfolio, rattling their saber at Linux and suing Android > >distributors. > > And yet IBM still is the number one champion in patents. > > Or just, because they play nice most of the time with open source they > are excused? > > Patents are bad, regardless which company makes use of them. All big companies are guilty of patent squatting. I distrust all of them. The bottomline is, once a company grows big enough, it acquires all sorts of vested interests in making more money, and retaining its position to be able to do so. Patent squatting is especially popular among contemporary high-tech companies. They essentially have no choice because they have to answer to their stakeholders. Only startups and grassroots companies have the chance of being decent in this respect. T -- I think the conspiracy theorists are out to get us...
Re: Export ?
Am Wed, 11 Apr 2012 20:27:31 +0200 schrieb Paulo Pinto : > Am 11.04.2012 19:03, schrieb Johannes Pfau: > > Am Wed, 11 Apr 2012 11:56:00 +0200 > > schrieb deadalnix: > >> > >> It isn't a misfeature. The link explain why it is interesting : > >>- It improves load time of DSO. > >>- Allow more optimizations. > >>- Reduce DSO size by 5% to 20% for C++. Considering how long > >> mangling are in D, probably more for us. > >>- Reduce name collision (this one poorly apply to D, because the > >> module system handle that quite nicely). > >> > >> Additionally, it allow automatic finalization for non exported > >> methods in D. > >> > > > > This explains why symbol visibility is useful. But do we really need > > 'export'? Are there cases where public = export, private/package = > > 'not exported' wouldn't work? > > > > When do you actually need 'not-exported' and public? And would > > export private/export package be valid? > > > > > For example, a so/dll might be composed of several D packages. In > those packages you want the public symbols to be visible between > packages, but not visible to the applications that link to your > so/dll library. > OK, I understand. I still can't think of a concrete example where I would want that behavior, but I'll just trust you all that it's useful. > This is why many languages make a distinction between modules and > packages. Usually a module is composed of several packages. > > These type of modularity might seem complex, but actually is a good > way to modularize applications.
Re: The Downfall of Imperative Programming
On Thursday, 12 April 2012 at 13:36:41 UTC, Jeff Nowakowski wrote: On 04/10/2012 12:06 PM, Paulo Pinto wrote: A curious fact is that the FP fans have much to thank to Microsoft, as it is the company with more FP research on their paychecks. Many open source fans are not aware that a few of the main developers in the Ocaml and Haskell communities, work for Microsoft Research labs. I don't see any reason to thank Microsoft for this so much as to be wary of it. The same people that were getting paid to work on this stuff at universities in Europe, where software patents don't exist, are now getting paid to work at Microsoft, where patenting software is expected as part of the job. Microsoft has also in recent years been very aggressive with their patent portfolio, rattling their saber at Linux and suing Android distributors. And yet IBM still is the number one champion in patents. Or just, because they play nice most of the time with open source they are excused? Patents are bad, regardless which company makes use of them.
Re: The Downfall of Imperative Programming
Well, all these guys seem to disagree with you about using Haskell in real-world programming http://corp.galois.com/ http://www.eaton.com/Eaton/index.htm http://blog.tupil.com/ -- Paulo On Thursday, 12 April 2012 at 11:04:06 UTC, James Miller wrote: * Russel Winder [2012-04-10 21:02:03 +0100]: On Tue, 2012-04-10 at 21:22 +0200, Gour wrote: [...] > In any case, as it is often said, I got a feeling that > despite its > potential cleanliness, the real-world Haskell code was not > so readable. That probably comes down to familiarity and personal taste. > By deploying some coding discipline, we tend to believe that > D can serve > well as FP-language for the masses. :-) Hummm... the really core issue is whether the language supports tail call optimization. Functional programming languages demand it, C, C++, Java, Go, Python definitely don't have it, D... I used Haskell a bit a while back, and while I enjoyed using it, and was quite capable of writing in proper functional style, I found reasoning about the programs tedious and difficult. Due to the nature of "Everything is a function" (mostly), you end up with an incredible amount of functions for the simplest tasks. And some of the most common tasks in real-world programming, string processing and IO, are significantly more difficult in Haskell. Monads aren't a problem, the discussion of monads, by functional programmers is a problem. The moment some snobby functional programmer comes along and starts talking about category theory and some esoteric aspect of Type Algebra generalized of some field of Assholery, most people's brains turn off. It gets worse when you go: "How does this help read from a file" and they give you a long stare and start all over again, I just want to know how to read from a goddamn file! I wish I could love Haskell, and for pure computer science, it's fine, amazing even, but for real-world programming, it just doesn't cut it. The concepts are too difficult and not explained well enough, code rapidly becomes unreadable unless you maintain super-human discipline and broken code is difficult to fix. Case in point is darcs, which is a perfect application of real-word usage, and the GHC developers are complaining of it being unstable, bloated and impossible to fix, so they are moving to git (written in C no less). -- James Miller
Re: The Downfall of Imperative Programming
* bearophile [2012-04-12 15:14:37 +0200]: > James Miller: > > >I wish I could love Haskell, and for pure computer science, it's > >fine, amazing even, but for real-world programming, > >it just doesn't cut it. > > Haskell contains some ideas worth copying even in non-functional > languages (or in mixed languages as D). > > Enforced purity and immutability, lazy immutable lists, pattern > matching, tuples and their various unpacking syntax, list > comprehension, structural algebraic types, built-in currying and > partial application, and so on, are handy and allow to express > certain computing idioms in a succinct and clear way (and not every > part of a program needs the same runtime efficiency). Scala language > shows that you can put several of those things in a language that > supports mutability too. > > Bye, > bearophile I like Scala, didn't really get it when I first looked at it, but that was a while ago, and I have learned Haskell since then, so I might give it another look. As I said, Haskell is a fine language, and the features are very useful. My favorites are: partial function application, currying, list comprehension and lazy lists. There are others, but these are things that I miss the most from my time using Haskell -- James Miller
Re: An idea to improve eponymous templates
On Thu, Apr 12, 2012 at 07:31:11PM +1000, Daniel Murphy wrote:
> "Jacob Carlborg" wrote in message
> news:jm66st$2d3f$1...@digitalmars.com...
> > On 2012-04-12 11:21, Daniel Murphy wrote:
> >
> >> Doesn't it need to be explicitly marked as a 'mixin template' for
> >> it to be mixed in?
> >>
> >>
> >
> > No, I don't think that is forced.
> >
> > --
> > /Jacob Carlborg
>
> Hmm. I guess the 'template' keyword is always available.
[...]
What about nested templates?
Or perhaps we can combine the keywords:
template MyTemplate(T) {
static if (SomeCond!T)
alias T this template;
else
static assert(0);
}
Clear, self-documenting, and unambiguous. :-)
T
--
"You know, maybe we don't *need* enemies." "Yeah, best friends are about all I
can take." -- Calvin & Hobbes
Tuple unpacking at the called function
The slides of the "Information Rich Programming with F# 3.0" talk
of Lang.NEXT 2012:
http://ecn.channel9.msdn.com/events/LangNEXT2012/LangNextDonnaFSharp.pptx
In the slide 6 titled "Simplicity Functional data" they compare
some F# functions to similar C# ones.
It shows a bit of syntax that makes tuple usage more handy, more
readable and shorter. I have discussed it a bit here:
http://d.puremagic.com/issues/show_bug.cgi?id=6544
--
The F# code shown on that slide:
let rotations (x, y, z) =
[ (x, y, z);
(z, x, y);
(y, z, x) ]
--
C#:
ReadOnlyCollection> Rotations
(Tuple t)
{
new ReadOnlyCollection
(new Tuple[]
{ new Tuple(t.Item1,t.Item2,t.Item3);
new Tuple(t.Item3,t.Item1,t.Item2);
new Tuple(t.Item2,t.Item3,t.Item1); });
}
--
Similar D code:
import std.typecons;
auto rotations(T)(in Tuple!(T,T,T) t) pure nothrow {
return [tuple(t[0], t[1], t[2]),
tuple(t[2], t[0], t[1]),
tuple(t[1], t[2], t[0])];
}
void main() {
auto r = rotations(tuple(1, 2, 3));
}
--
Two Python2.6 versions:
def rotations((x, y, z)):
return [(x, y, z), (z, x, y), (y, z, x)]
rotations = lambda (x, y, z): [(x, y, z),
(z, x, y),
(y, z, x)]
print rotations((1, 2, 3))
--
In Haskell there is even an optional syntax to give names to both
the parts and the whole tuple:
twohead s@(x : xs) = x : s
main = print $ twohead [1,2,3]
That outputs:
[1,1,2,3]
--
While there is a good enough D syntax to support tuple unpacking
at the return point of a function, I don't know what syntax to
use in D for the naming of tuple parts in the function signature
(the same syntax is later usable for structs in switch-case).
Some possibilities:
This seems to works with all structs:
auto rotations(T)(Tuple!(T, T, T)(x, y, z)) {
Or:
auto rotations(T)(Tuple!(T, T, T) t(x, y, z)) {
Or the same syntax as the normal tuple unpacking syntax:
auto rotations(T)(auto (x, y, z)) {
auto rotations(T)((int x, int y, int z)) {
Or even:
auto rotations(T)(Tuple!(T x, T y, T z)) {
Please take a look at the issue 6544 for more info.
Bye,
bearophile
Re: The Downfall of Imperative Programming
Gour: What do you miss in D from Haskell? It's written a bit below in my post: lazy immutable lists, pattern matching, tuples and their various unpacking syntax, list comprehension, structural algebraic types, built-in currying and partial application I am about to write a post about one of those. Bye, bearophile
Re: The Downfall of Imperative Programming
On Thu, 12 Apr 2012 15:14:37 +0200 "bearophile" wrote: > Haskell contains some ideas worth copying even in non-functional > languages (or in mixed languages as D). What do you miss in D from Haskell? Sincerely, Gour -- To deliver the pious and to annihilate the miscreants, as well as to reestablish the principles of religion, I Myself appear, millennium after millennium. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: The Downfall of Imperative Programming
On Thu, 12 Apr 2012 23:04:16 +1200 James Miller wrote: > I wish I could love Haskell, and for pure computer science, it's fine, > amazing even, but for real-world programming, it just doesn't cut it. > The concepts are too difficult and not explained well enough, code > rapidly becomes unreadable unless you maintain super-human discipline > and broken code is difficult to fix. I'm glad I'm not the only one arriving at the same conclusion. Sincerely, Gour -- To deliver the pious and to annihilate the miscreants, as well as to reestablish the principles of religion, I Myself appear, millennium after millennium. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: The Downfall of Imperative Programming
On 04/10/2012 12:06 PM, Paulo Pinto wrote: A curious fact is that the FP fans have much to thank to Microsoft, as it is the company with more FP research on their paychecks. Many open source fans are not aware that a few of the main developers in the Ocaml and Haskell communities, work for Microsoft Research labs. I don't see any reason to thank Microsoft for this so much as to be wary of it. The same people that were getting paid to work on this stuff at universities in Europe, where software patents don't exist, are now getting paid to work at Microsoft, where patenting software is expected as part of the job. Microsoft has also in recent years been very aggressive with their patent portfolio, rattling their saber at Linux and suing Android distributors.
Re: The Downfall of Imperative Programming
James Miller: I wish I could love Haskell, and for pure computer science, it's fine, amazing even, but for real-world programming, it just doesn't cut it. Haskell contains some ideas worth copying even in non-functional languages (or in mixed languages as D). Enforced purity and immutability, lazy immutable lists, pattern matching, tuples and their various unpacking syntax, list comprehension, structural algebraic types, built-in currying and partial application, and so on, are handy and allow to express certain computing idioms in a succinct and clear way (and not every part of a program needs the same runtime efficiency). Scala language shows that you can put several of those things in a language that supports mutability too. Bye, bearophile
Re: Where is the runtime memory overhead from?
Nick Sabalausky wrote: > But I am curious what the memory overhead is from. My guess Your guess is wrong. process monitor from sysinternals reveals, that several windows system dll's are loaded under the process number belonging to that loop. -manfred
Re: The Downfall of Imperative Programming
* Russel Winder [2012-04-10 21:02:03 +0100]: > On Tue, 2012-04-10 at 21:22 +0200, Gour wrote: > [...] > > In any case, as it is often said, I got a feeling that despite its > > potential cleanliness, the real-world Haskell code was not so readable. > > That probably comes down to familiarity and personal taste. > > > By deploying some coding discipline, we tend to believe that D can serve > > well as FP-language for the masses. :-) > > Hummm... the really core issue is whether the language supports tail > call optimization. Functional programming languages demand it, C, C++, > Java, Go, Python definitely don't have it, D... > I used Haskell a bit a while back, and while I enjoyed using it, and was quite capable of writing in proper functional style, I found reasoning about the programs tedious and difficult. Due to the nature of "Everything is a function" (mostly), you end up with an incredible amount of functions for the simplest tasks. And some of the most common tasks in real-world programming, string processing and IO, are significantly more difficult in Haskell. Monads aren't a problem, the discussion of monads, by functional programmers is a problem. The moment some snobby functional programmer comes along and starts talking about category theory and some esoteric aspect of Type Algebra generalized of some field of Assholery, most people's brains turn off. It gets worse when you go: "How does this help read from a file" and they give you a long stare and start all over again, I just want to know how to read from a goddamn file! I wish I could love Haskell, and for pure computer science, it's fine, amazing even, but for real-world programming, it just doesn't cut it. The concepts are too difficult and not explained well enough, code rapidly becomes unreadable unless you maintain super-human discipline and broken code is difficult to fix. Case in point is darcs, which is a perfect application of real-word usage, and the GHC developers are complaining of it being unstable, bloated and impossible to fix, so they are moving to git (written in C no less). -- James Miller
Re: Where is the runtime memory overhead from?
"Nick Sabalausky" wrote in message news:jm63tu$27uq$1...@digitalmars.com... > > The reason I'm asking is[...] > Actually, that junk doesn't matter, I found a way to put it without getting that detailed and derailed. But I am curious what the memory overhead is from. My guess would be that it's just memory used by misc parts of the statically-linked phobos/druntime, but I don't actually know.
Re: What about x64 windows?
On 11/04/12 14:45, Davita wrote: Hi guys. Is there a going development on x64 compiler for windows? Or D won't support x64 at all? Thanks It is a known blocker issue. Nothing has been announced, but it will definitely happen. It is surely far less work than adding 64-bit code generation to an ancient 32-bit back-end (which took Walter less than one year).
Re: An idea to improve eponymous templates
On 12/04/12 04:21, Reid Levenick wrote:
Firstly, I had no idea where suggestions should go, and I saw a few
others here and thus here I am.
I was writing some code that depended heavily on my own eponymous
templates, and decided to change the names of some of them to make them
more self-documenting. However, after changing the name, I encountered a
long stream of unintelligible errors (to me, I haven't been using D for
a long time) about template instances.
So, my idea is that the 'this' keyword could be used in templates as a
shortcut for eponymous templates, allowing code like this
template anEponymousTemplate( size_t whatever ) {
enum this = whatever * 2;
}
template anotherOne( T ) {
static if( is( T == class ) ) {
alias long this;
} else {
alias int this;
}
}
Which would reduce cruft and make it easier to read some templates, as
well as reducing maintenance.
This has been suggested about 200 times...
As already mentioned, use of 'this' conflicts with 'alias this'.
I also think there are problems with local templates.
class S
{
void foo()
{
template XX(int n) {
alias this this; // !! first 'this' is S, second is XX
}
XX!(7) q;
}
}
Another suggestion that was made in the past was 'return'. I suspect
that doesn't work, either, because for example typeof(return) already
has a meaning.
Re: An idea to improve eponymous templates
"Jacob Carlborg" wrote in message news:jm66st$2d3f$1...@digitalmars.com... > On 2012-04-12 11:21, Daniel Murphy wrote: > >> Doesn't it need to be explicitly marked as a 'mixin template' for it to >> be >> mixed in? >> >> > > No, I don't think that is forced. > > -- > /Jacob Carlborg Hmm. I guess the 'template' keyword is always available.
Re: An idea to improve eponymous templates
No. Current implementation doesn't enforce it.
Kenji Hara
2012年4月12日18:21 Daniel Murphy :
> "kenji hara" wrote in message
> news:mailman.1646.1334209001.4860.digitalmar...@puremagic.com...
>> It conflicts with ”alias this” syntax.
>>
>> template Inherits(T)
>> {
>> T value;
>> alias T Inherits; // (1) Inherits!int == int
>> alias T this; // (2) declares "alias this"!
>> }
>> struct S {
>> mixin Inherits!int; // (1) invalid or (2) mixing alias this declaration?
>> }
>>
>> Kenji Hara
>>
>
> Doesn't it need to be explicitly marked as a 'mixin template' for it to be
> mixed in?
>
>
Re: An idea to improve eponymous templates
On 2012-04-12 11:21, Daniel Murphy wrote: Doesn't it need to be explicitly marked as a 'mixin template' for it to be mixed in? No, I don't think that is forced. -- /Jacob Carlborg
Re: An idea to improve eponymous templates
"kenji hara" wrote in message
news:mailman.1646.1334209001.4860.digitalmar...@puremagic.com...
> It conflicts with $B!I(Balias this$B!I(B syntax.
>
> template Inherits(T)
> {
> T value;
> alias T Inherits; // (1) Inherits!int == int
> alias T this; // (2) declares "alias this"!
> }
> struct S {
> mixin Inherits!int; // (1) invalid or (2) mixing alias this declaration?
> }
>
> Kenji Hara
>
Doesn't it need to be explicitly marked as a 'mixin template' for it to be
mixed in?
Where is the runtime memory overhead from?
Consider this program:
// blank.d
void main() {
while(true) {} // Poor man's sleep ;)
}
>dmd blank.d
On WinXP 32-bit DMD 2.058, if I run that, task manager tells me it's using
8816k of memory.
*Note: I'm not complaining.*
I just wanted to ask if anyone knows what that overhead is primarily from?
Just from druntime/phobos being statically linked? OS process overhead? Some
DLLs that are implicitly used? (But I assume DLLs aren't counted in that
memory usage figure...) Etc... I don't think it's from the raw exe file
itself being loaded into mem, because that's only 143k.
As a frame of reference, if I change "true" to "1" and compile with DMC
(instead of DMD), then it only uses 1265k ram. (The exe file is smaller too,
but *that* I'm sure is just because of phobos/druntime being statically
linked.)
The reason I'm asking is I'm making a few minor edits to my "Have Your
Efficiency, and Flexibility Too" article, and I'm tempted to breifly point
out that the 10% decrease in memory usage with the "handcrafted version" is
better than it sounds because most of that 10MB ram is just overhead. But
saying that D programs have 8-9MB runtime overhead probably sounds very bad,
so I'm not sure I want to do it if I can't provide a (breif) "Don't worry!
Because..."
(Although I may still just skip the whole mention altogether and just leave
it at "10% decrease in memory - and now on to the next section" and not even
worry about it. Whatever. In any case, I am at least curious.)
Re: dmd's linking order
And to tell ld to not depend on the order in which the libs are specifies, you can use --start-group and --end-group. From the ld man page: --start-group archives --end-group The archives should be a list of archive files. They may be either explicit file names, or -l options. The specified archives are searched repeatedly until no new undefined references are created. Thanks. I knew that possibility exists, I just did not remember the parameters. Thank you for documenting this here.
