Bill Baxter
(16/38)
Jun 30 2008
The list is definitely a farce. I think most everyone stopped paying
Derek Parnell
(8/11)
Jul 01 2008
ROTFLMAO!!!
-
novice2
(2/5)
Jul 01 2008
http://www.vumo.ru/humour/chan.php
John Reimer
(82/133)
Jun 30 2008
Hi Sean,
superdan
(2/24)
Jul 03 2008
google for "relaxed memory consistency model" or "memory barriers". geez...
-
Oskar Linde
(12/36)
Jul 04 2008
I presume the discussion regards symmetric multiprocessing (SMP).
-
Sean Kelly
(10/44)
Jul 04 2008
Things get a bit weird once pipelining and out-of-order execution come
-
superdan
(4/40)
Jul 04 2008
yeah the problem is it's hard to define what "prior" means.
-
Me Here
(22/74)
Jul 04 2008
Since in the scenario I describe, Each thread or cpu is dealing with a s...
-
Sean Kelly
(31/103)
Jul 04 2008
Multithreading with a single-CPU machine is always fairly safe and predi...
-
Me Here
(9/126)
Jul 04 2008
Sean, I'm sorry, but *please* re-read everything I've posted o this subj...
-
superdan
(5/84)
Jul 04 2008
goodness this is so wrong i don't know where to start from. like trying ...
-
BLS
(3/4)
Jul 04 2008
atm it seems to me that Gregor R. is really a nice, gentle guy.
-
Me Here
(16/22)
Jul 04 2008
Hey tweety-pie. How about you get back to sucking your mother's nipple. ...
Knud Soerensen
(21/21)
Jul 06 2008
I created the wishlist to reduce the
-
Koroskin Denis
(11/32)
Jul 06 2008
gs
-
Manfred_Nowak
(7/8)
Jul 07 2008
I believe, that voting without supervision is a no-no in general and
-
Knud Soerensen
(7/17)
Jul 07 2008
I believe, that newsgroup posting without supervision is a no-no in
Hi
This is the monthly status for the unofficial d wish list:
http://all-technology.com/eigenpolls/dwishlist/
Right now the wish list looks like this:
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't seem
among the list of the next things planned as improvements/changes for the
D/DMD. I don't know what this means. Are people asking for unimportant things?
Are the D designers smarter? Are the two groups ignoring each other?
When I think about such matters I remember a quote, usually attributed to Henry
Ford: "If I'd asked people what they wanted, they would have said a faster
horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
Bye,
bearophile
Well, I don't think stack tracing is something that's going to be
replaced by functional programming... could be, I guess. Never say never.
-[Unknown]
bearophile wrote:
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't seem
among the list of the next things planned as improvements/changes for the
D/DMD. I don't know what this means. Are people asking for unimportant things?
Are the D designers smarter? Are the two groups ignoring each other?
When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what they wanted, they would have said a
faster horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
Bye,
bearophile
== Quote from bearophile (bearophileHUGS lycos.co)'s article
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't seem
among the list of the next things
planned as improvements/changes for the D/DMD. I don't know what this means.
Are people asking for
unimportant things? Are the D designers smarter? Are the two groups ignoring
each other?
For better or worse, I don't personally feel that the D designers listen to the
D community
at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's
just that my goals
with D simply diverged beginning with 2.0.
When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what
they wanted, they would have said a faster horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
It's an interesting question, and one I've been mulling over for a few years
now. My
understanding is that C++ was created as a very community-driven effort right
from the
start while D was designed based very much on what Walter thought would be good
in a
language. As a result, C++ ended up bogged down with a lot of legacy C baggage
that the
community insisted was necessary for them to adopt C++, while D could change
tracks on
the designer's whim and no one could say otherwise. Generally, I think the D
approach works
far better so long as the designer's goals match the interests of the
community, but it's a
pretty risky path to follow since the designer is basically betting the farm on
the hope that the
community will agree with his vision. In the past I've been pretty free with
my opinions about
language features and I do this because I don't want to feel that I didn't try
to make myself
heard if I ever give up on D. At least then I can feel that I did my best to
communicate to the
designers what's important to me as a user of the language.
Sean
Sean Kelly Wrote:
== Quote from bearophile (bearophileHUGS lycos.co)'s article
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't seem
among the list of the next things
planned as improvements/changes for the D/DMD. I don't know what this means.
Are people asking for
unimportant things? Are the D designers smarter? Are the two groups ignoring
each other?
For better or worse, I don't personally feel that the D designers listen to
the D community
at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's
just that my goals
with D simply diverged beginning with 2.0.
wut the heck is ur problem sean, u were the only sane guy left at tango. now u
r coming with badmouthing n shit. recently u were like "walter is trying 2 lure
people to d2. if that happens, i'm out." where the fuck did that conspiracy
theory come from. walter never did anything to put his integrity into question.
now wuts with this walter doesn't listen shit. whining baby. i'm sayin': walter
does listen and does do great shit, the only problem is that most of us don't
know what we're talking about and can't remember what we want from 1 moment 2
the next. look at that list. it's a pile of shit with the most
prefuckingposterous requests in the fucking history of fucking programming
languages. look at vectorization. who the fuck came with that sick idea. hell,
std.algorithm does that shit better and nicer and didn't need language changes.
the list is a joke. it's not even maintained, d has had tuples for months now.
somehow we want progress, n new shit n all but no we want it in d1 backward
compatible and with only two extra pieces of shit that vary from 1 person 2 the
next and from 1 minute 2 the next. shit.
if walter were 2 implement all the shitty "features" in the motherfucking list
the language would become a fucking pile of dung the size of fucking china.
what the fuck. walter is cranking great shit like it's goin' outta style and we
throw a fit because we didn't think of it first. we only thought of shitty
misfeatures like short syntax for new. now what was that mofo's problem. shit.
When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what
they wanted, they would have said a faster horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
It's an interesting question, and one I've been mulling over for a few years
now. My
understanding is that C++ was created as a very community-driven effort right
from the
start while D was designed based very much on what Walter thought would be
good in a
language. As a result, C++ ended up bogged down with a lot of legacy C
baggage that the
community insisted was necessary for them to adopt C++, while D could change
tracks on
the designer's whim and no one could say otherwise. Generally, I think the D
approach works
far better so long as the designer's goals match the interests of the
community, but it's a
pretty risky path to follow since the designer is basically betting the farm
on the hope that the
community will agree with his vision. In the past I've been pretty free with
my opinions about
language features and I do this because I don't want to feel that I didn't try
to make myself
heard if I ever give up on D. At least then I can feel that I did my best to
communicate to the
designers what's important to me as a user of the language.
u r wrong. bjarne has had control of language long time b4 it became
successful. it's his vision 4 better or worse. u r looking at the success years
of c++ when committees and crap came all over. don't panic when d will be
successful with muggles there will be a committee over it like a cheap suit.
so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real suggestions. now seriously.
speak up. what is it that u as a member of the community wanna say and walter
doesn't listen.
== Quote from superdan (super dan.org)'s article
Sean Kelly Wrote:
== Quote from bearophile (bearophileHUGS lycos.co)'s article
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't seem
among the list of the next things
planned as improvements/changes for the D/DMD. I don't know what this means.
Are people asking for
unimportant things? Are the D designers smarter? Are the two groups ignoring
each other?
For better or worse, I don't personally feel that the D designers listen to
the D community
at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's
just that my goals
with D simply diverged beginning with 2.0.
wut the heck is ur problem sean, u were the only sane guy left at tango. now u
r coming with badmouthing n shit.
recently u were like "walter is trying 2 lure people to d2. if that happens,
i'm out." where the fuck did that conspiracy
theory come from. walter never did anything to put his integrity into question.
I was bothered by the fact that some issues that many people consider bugs in D
1.0 are only
being fixed in D 2.0, and I ignored my better judgement and shot my mouth off.
It was a
mistake.
now wuts with this walter doesn't listen shit. whining baby. i'm sayin':
walter does listen and does do great shit, the
only problem is that most of us don't know what we're talking about and can't
remember what we want from 1 moment 2
the next.
No offense, but um... speak for yourself. There are quite a few people here
who are very
talented and whose comments are not only consistent, but very well considered
and quite
well reasoned. But Walter has said himself that he has difficulty working with
people in
other than a face to face setting and it shows. Back when Andrei was still
posting here
someone asked what one should do to have a proposal considered or at least
garner a
response and the process was laid out very clearly. Since then, quite a few
people have
followed that process exactly and I can't remember any of the proposals getting
a comment
from either Walter or Andrei. If a tree falls in the forest and there's no one
around to hear
it, does it make a sound? And if a proposal is posted and it doesn't get a
single response,
has anyone read it? I know it's difficult to keep up with the posts in this NG
and impossible
to actually act on all of them, but even a "thanks" goes an incredibly long way
in terms of
making people feel like their comments matter.
look at that list. it's a pile of shit with the most prefuckingposterous
requests in the fucking history of fucking
programming languages. look at vectorization. who the fuck came with that sick
idea. hell, std.algorithm does that shit
better and nicer and didn't need language changes.
std.algorithm does vectorization? I had no idea. Don's BLADE (?) package does
though
and it's totally awesome and also didn't require language changes, so the point
is still
valid.
When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what
they wanted, they would have said a faster horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
It's an interesting question, and one I've been mulling over for a few years
now. My
understanding is that C++ was created as a very community-driven effort right
from the
start while D was designed based very much on what Walter thought would be
good in a
language. As a result, C++ ended up bogged down with a lot of legacy C
baggage that the
community insisted was necessary for them to adopt C++, while D could change
tracks on
the designer's whim and no one could say otherwise. Generally, I think the D
approach works
far better so long as the designer's goals match the interests of the
community, but it's a
pretty risky path to follow since the designer is basically betting the farm
on the hope that the
community will agree with his vision. In the past I've been pretty free with
my opinions about
language features and I do this because I don't want to feel that I didn't try
to make myself
heard if I ever give up on D. At least then I can feel that I did my best to
communicate to the
designers what's important to me as a user of the language.
u r wrong. bjarne has had control of language long time b4 it became
successful. it's his vision 4 better or worse. u r
looking at the success years of c++ when committees and crap came all over.
don't panic when d will be successful with
muggles there will be a committee over it like a cheap suit.
I suggest reading "The Design and Evolution of C++" if you haven't already.
It's pretty clear that
Bjarne validated much of C++ by asking influential C users about its features.
so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of the
community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it. As for my
suggestions, feel free
to use the search feature in the digitalmars.com website, because many are here
in this forum
or D.announce. But you do have a point in that I have become quite weary of
the D drama in
general. I simply don't have the enthusiasm I used to, and that's entirely my
own fault. This
has been the longest I've ever worked on a personal programming project (at a
guess, 4-5
years on Tango/Ares?) and I feel I've accomplished what I set out to do here,
and that should
be enough. I'll be better in the future about posting when I've had a bad day.
My apologies.
Sean
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of the
community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
At the very least, it's a public relations disaster from the point of
view of the language designers. They are assuming that with more time
and education, the legitimate complaints about first const system will
be forgotten, and the const system will be embraced by the community.
But there is a very big risk here -- what if it is NOT eventually
accepted? What if the community concensus remains that const is just too
complicated, without enough benefit? And the language designers remain
steadfastly devoted to const? That's a catastrophic scenario, and
unfortunately not unlikely.
The fact that someone as senior in the community as yourself is
expressing profound dissatisfaction indicates that the risk is very real.
Don wrote:
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox
like u r interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of
the community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
I think there was a lot of hope on the part of the community that a
const system designed from scratch with 20/20 hind-sight could avoid
some of the practical problems with the C++ const system. But it seems
the answer to that was "no". The system we've got now seems to solve
some *theoretical* problems with the C++ const system at the cost of
making practical usage slightly more cumbersome.
But I don't hope for a more usable const any more. I'd just like to see
a reduction in the number of flavors of D code. If we all moved to D2,
I think we could pretty much just ignore invariant until it actually has
some practical benefit. What's left of D2 const is pretty much like
what many are used to with C++. Yeh, so you have to write some methods
multiple times for different constnesses, etc... you get used to it. I
think I could get used to D2 const anyway.
At the very least, it's a public relations disaster from the point of
view of the language designers. They are assuming that with more time
and education, the legitimate complaints about first const system will
be forgotten, and the const system will be embraced by the community.
But there is a very big risk here -- what if it is NOT eventually
accepted? What if the community concensus remains that const is just too
complicated, without enough benefit? And the language designers remain
steadfastly devoted to const? That's a catastrophic scenario, and
unfortunately not unlikely.
The fact that someone as senior in the community as yourself is
expressing profound dissatisfaction indicates that the risk is very real.
It would be sad to see the D2 const swerve shake off all the old D
supporters off the D train. But on the other hand, new folks do seem to
keep popping up who would rather use D2 than D1.
--bb
Bill Baxter wrote:
Don wrote:
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox
like u r interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of
the community wanna say and walter doesn't listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
I think there was a lot of hope on the part of the community that a const
system designed from scratch with 20/20 hind-sight could avoid some of the
practical problems with the C++ const system. But it seems the answer to
that was "no". The system we've got now seems to solve some theoretical
problems with the C++ const system at the cost of making practical usage
slightly more cumbersome.
But I don't hope for a more usable const any more. I'd just like to see a
reduction in the number of flavors of D code. If we all moved to D2, I think
we could pretty much just ignore invariant until it actually has some
practical benefit. What's left of D2 const is pretty much like what many are
used to with C++. Yeh, so you have to write some methods multiple times for
different constnesses, etc... you get used to it. I think I could get used
to D2 const anyway.
At the very least, it's a public relations disaster from the point of
view of the language designers. They are assuming that with more time
and education, the legitimate complaints about first const system will
be forgotten, and the const system will be embraced by the community.
But there is a very big risk here -- what if it is NOT eventually
accepted? What if the community concensus remains that const is just too
complicated, without enough benefit? And the language designers remain
steadfastly devoted to const? That's a catastrophic scenario, and
unfortunately not unlikely.
The fact that someone as senior in the community as yourself is
expressing profound dissatisfaction indicates that the risk is very real.
It would be sad to see the D2 const swerve shake off all the old D supporters
off the D train. But on the other hand, new folks do seem to keep popping up
who would rather use D2 than D1.
--bb
The problem with D2, is that it is optimising (prematurly) for the lazy, at the
expense of the dilligent.
The functional utopia of transparent threading through purity only succeeds in
dealing with the most trivial forms of shared access--and grossly inefficiently
at that.
Side-effects are par for the course in software. Whether its printing/reading
to/from the screen; or reading or writing from/to a file, or port or socket or
DB. These things cannot be avoided in any *useful program*, and "purity" goes
out the window as soon as you do any one of them. Once you accept that fact,
and realise that shared access to memory is the least of the thread users
problems, all the hyperbole about purity and referential transparency goes
right out the window.
Besides which, all that (unnecessary and unavoidable) replication of data goes
entirely against the grain of the original D ethos, and completely inhibits
efficient algorithms for dealing with thread-shared data.. For example: The
most efficient way to use multiple cores or processors to manipulate large
arrays, is to run multiple, indentical threads *each processesing its own,
unique partition of the gross data. D2's ponchant for replicating whole data
structures every time you look at the thing, completely inhibots this, tried,
tested and proven technique for making use of shared data and threading.
By way of proof. If you have a vanilla, threaded, Perl installed, run this:
use strict;
use Tim e:HiRes qw[ sleep ];
use threads;
use threads::shared;
$|++;
sub thread{
my( $ref, $pos ) = _;
while( sleep 0.1 ) {
substr( $$ref, $pos, 1 ) =~ tr[A-Z][B-ZA];
}
my $s :shared = join( '', 'A' .. 'Z' ) x 3;
my threads = map{ threads->create( \&thread, \$s, $_ ) } 0 .. 77;
sleep 1;
printf "\r$s\t" while sleep 0.05;
For those that do not have Perl, what those that do will see, it the
inline-scrolling (html marque-style) line of text with three copies of the
alphabet rotating left.
Now, that's trivial I here you all cry, but get this. Each character on that
line is being manipualted by a different thread. Try replicating that using D2
(or Haskell which seems to be the inspiration for the current trend in D2
direction).
Now imagine all the concurrent processing problems that can be efficiently
dealt with using the "add & multiply" concurrent processing techniqur. From
image processing--whether jpgs, x-ray, radar, mri or crt scans; weather
prediction; finite element analysis for construction, automotive, boat design,
etc. etc. etc; audio and video compression; cryptographical analysis; neuclear
weapon analysis; space flight calculation; Genome analysis; weapons
trajectories; .... The list is endless.
In each of these fields, partitioning a single large dataset and running
separate, indentical threads on each section is fundemental to efficient
processing of these algorithms. and replicating entire datastructures each time
any single element of them is mutated is grossly, insanely, *stupidly*
inefficient. Total madness. Rather than getting 80-90% time-based gains from
each extra processor, you ruduce that to 35-40%, with the rest spent thrashing
the memory allocator/GC to death *needlessly replicating mutated data*!
Walter: Please, please, please. Take a break. A holiday (far away from Andrie)
and apply your own, rational, non-hyped thought processes to this problem.
(Stay off the purity cool-aid for a few days). Do a little research into the
types of problems and algorithms that truely lend themselves to being
multi-threaded and analyse the effects of all that damn, unwanted and
uncontrollable replication.
Web servers and other IO-bound processes are *not* the target of
multithreading. Take a close look at the sort of algorithms that the
IBM/SONY/etc. Cube processor is targetted at. (It's the core behind the latest
greatest teraflops super-computers), and there is a really good reason for
that. Running simple, compact, highly localised algorithms on vast quantities
of simlar data is the bread and butter of efficient concurrency. All that
replication to achieve "transparent referential integrity" doesn't mean a damn
thing for this type of algorithm. It simply slows everything to a crawl. If
these super computer kept destroying there local L1 & L2 caches by replicating
data every time it mutated, those teraflops systems would be "total flop"
sysems.
For dogs sakes. get a grip, smell the coffee, kick the purity habit and send
Andrie packing back to the "design by commitee" that produces STL..
With respect, but concrete, contrary knowledge,
b.
--
Me Here Wrote:
Web servers and other IO-bound processes are *not* the target of
multithreading.
How do functional programming styles apply better to I/O-bound systems?
I couldn't imagine writing a query processor using monads for all I/O.
Functional programming works well for a subset of applications which
require concurrency. The question is: is this subset large enough to justify
designing a language's concurrency support around this paradigm? Is it
large enough to justify forcing additional language constructs (const) for
applications that don't use this paradigm to handle their concurrency? For
non-concurrent applications?
Of course, there are other arguments for a const system (static checking
of interfaces, etc.) But what other major new statically-typed languages
(besides D) have such a system? Java mostly threw it out (there's final
fields & what not). C-pound threw out even more of it. I ahve the same
feelings towards const-as-interface as I do towards checked exceptions:
sounds great on paper, but ends up wasting the developer's time.
(apologies for the web interface; work)
On Tue, 01 Jul 2008 21:58:31 +0400, Robert Fraser
<fraserofthenight gmail.com> wrote:
Me Here Wrote:
Web servers and other IO-bound processes are *not* the target of
multithreading.
How do functional programming styles apply better to I/O-bound systems?
I couldn't imagine writing a query processor using monads for all I/O.
Functional programming works well for a subset of applications which
require concurrency. The question is: is this subset large enough to
justify
designing a language's concurrency support around this paradigm? Is it
large enough to justify forcing additional language constructs (const)
for
applications that don't use this paradigm to handle their concurrency?
For
non-concurrent applications?
Of course, there are other arguments for a const system (static checking
of interfaces, etc.) But what other major new statically-typed languages
(besides D) have such a system? Java mostly threw it out (there's final
fields & what not). C-pound threw out even more of it. I ahve the same
feelings towards const-as-interface as I do towards checked exceptions:
sounds great on paper, but ends up wasting the developer's time.
(apologies for the web interface; work)
No reason for apologies, it's hardly anyone would notice if you didn't
stress that!
And even so!
On Tue, 1 Jul 2008, Robert Fraser wrote:
Me Here Wrote:
Web servers and other IO-bound processes are *not* the target of
multithreading.
How do functional programming styles apply better to I/O-bound systems?
I couldn't imagine writing a query processor using monads for all I/O.
Functional programming works well for a subset of applications which
require concurrency. The question is: is this subset large enough to justify
designing a language's concurrency support around this paradigm? Is it
large enough to justify forcing additional language constructs (const) for
applications that don't use this paradigm to handle their concurrency? For
non-concurrent applications?
Functional or not isn't a whole program decision (at least within D and
it's future as it seems to be unfolding). Within most, if not all,
applications, there are reasonable subsets that are, or could be,
functional style. Many are already, without language support to help
enforce the style or take advantage of the benefits.
Of course, there are other arguments for a const system (static checking
of interfaces, etc.) But what other major new statically-typed languages
(besides D) have such a system? Java mostly threw it out (there's final
fields & what not). C-pound threw out even more of it. I have the same
feelings towards const-as-interface as I do towards checked exceptions:
sounds great on paper, but ends up wasting the developer's time.
(apologies for the web interface; work)
Everyone has their opinion, and aren't we glad for that privilege. The
nice part is that const is optional. There's only a very few places where
that leaks out, the obvious example being the phobos definition of
'string' and that's avoidable. The current implementation of phobos is
far from perfect (don't start that thread, please) in it's use of const,
but that's part of being an alpha version. As it evolves, applications
and libraries should be able to choose to ignore const completely. Any
part of phobos or the compiler that gets in the way of NOT using const,
should be examined quite carefully.
Personally, if/when I end up using D for anything serious, I will be using
const, as I like the guarantees that it allows me to have. I _do_ like
contracts and languages such as Java annoy me every time I'm forced to
work with it in part due to the lack of them.
Later,
Brad
Brad Roberts Wrote:
Functional or not isn't a whole program decision (at least within D and
it's future as it seems to be unfolding). Within most, if not all,
applications, there are reasonable subsets that are, or could be,
functional style. Many are already, without language support to help
enforce the style or take advantage of the benefits.
The "benefits" of automatic parallelization can only be seen on a macro
scale. For trivial functions, even if there's an array scan involved, it will
most
likely be more overhead than good. Most imperative systems will need to
be redesigned if they want to take advantage of these things... not that
that's a bad thing. But once again, the question is: do the benefits
outweigh the costs?
Everyone has their opinion, and aren't we glad for that privilege. The
nice part is that const is optional. There's only a very few places where
that leaks out, the obvious example being the phobos definition of
'string' and that's avoidable. The current implementation of phobos is
far from perfect (don't start that thread, please) in it's use of const,
but that's part of being an alpha version. As it evolves, applications
and libraries should be able to choose to ignore const completely. Any
part of phobos or the compiler that gets in the way of NOT using const,
should be examined quite carefully.
That's true... if you're one developer working on an application. But that's
not true if you're writing a library -- some of people won't use your library
if it doesn't support const. But, yes, in the end it's just a matter of opinion
on what the right language design is.
Robert Fraser wrote:
Me Here Wrote:
Web servers and other IO-bound processes are not the target of
multithreading.
How do functional programming styles apply better to I/O-bound systems?
I couldn't imagine writing a query processor using monads for all I/O.
No. You missed my (badly worded) point. I perhaps should have said:
Of course, webservers and other IO-bound processes...
I was referring back to my earlier point that "Side-effects are par for the
course in software.". And the fact that many, maybe even a majority of strong
applications for threading aren't IO-bound, which makes it /seem/ as if
functional techniques lend themselves to the transparent threading of
compute-bound processing.
But, as I then pointed out, the problem with the way D2 handles the mutation of
arrays (strings and others), is that it flies in the face of those bread&butter
concurrency algorithms that manipulate large datasets (images and the like)
with add&multiply algorithms, by setting multiple threads to operate on
different segments of the same datastructure. These would be completely
hamstrung by the unnecessary and uncontrolled replication.
The best way to handle concurrent access to shared resources, is to avoid
concurrent access. For IO and other external shared resources, you serialise
access to them through queuing or message passing to a single thread that acts
on the behalf of others.
For memory, you avoid concurrent access by partitioning the dataset. Ie, you
pass each thread a constrained alias to just that part of the dataset you wish
it to operate upon. Each thread can then operate upon its partition at full
speed, without locking, and without restrictions upon the operations it can
perform. Replicating entire arrays everytime something mutates an element
within it, is a complete nonsense. It basically throws away the very advantage
of having shared memory in the first place. And shared memory is the very
reason detre of threading.
I love functional techniques. Perl's map, grep, reduce and kin are one of its
greatest assets, but using purity to attempt to simplify threading fails
dismally. It creates work and impacts performance for *everyone not using
threads*, and those using them whenever they *don't need the protection*, in
order to "simplify" things for those that are using threads and know they would
otherwise need to take precautions.
It's like drawing solid white lines across major roads before every side
turning and on-ramp, to force the main flow to check if someone wants to turn
on to the major road, so that those turning onto the major road don't have to
check if anything is coming. The priorities are backwards.
This isn't a rail against functional techniques or languages. Its an informed
reality check to weight the many costs against the few benefits, and to
consider the rarity of the occasions when those few benefits will actually
occur.
I'll say it again. D was my great white hope for compiled language performance
and integrity checking, rational semantics and threading. But this issue, and
to some degree, the whole templating thing, seem to have side-tracked the
development process and the original clean vision of D and (IMO) are leading it
off in directions that are utopic in vision, but imprqactical in reality.
b.
--
Me Here wrote:
For memory, you avoid concurrent access by partitioning the dataset. Ie, you
pass each thread a constrained alias to just that part of the dataset you wish
it to operate upon. Each thread can then operate upon its partition at full
speed, without locking, and without restrictions upon the operations it can
perform. Replicating entire arrays everytime something mutates an element
within it, is a complete nonsense. It basically throws away the very advantage
of having shared memory in the first place. And shared memory is the very
reason detre of threading.
There's nothing about D 2.0 which would prevent you from doing this. D
2.0 is still a systems programming language which will let you do
whatever you want with your data.
Walter Bright wrote:
Me Here wrote:
Replicating entire arrays everytime something mutates an
element within it, is a complete nonsense. It basically throws away the
very advantage of having shared memory in the first place. And shared
memory is the very reason detre of threading.
There's nothing about D 2.0 which would prevent you from doing this. D 2.0 is
still a systems programming language which will let you do whatever you want
with your data.
So, in D2, if a pass an slices of an array to several threads and they mutate
those slices, when the threads end, the main thread can see (and further
manipulate) the results of their work by simply iterating the original array?
b.
--
Reply to Me,
Walter Bright wrote:
Me Here wrote:
Replicating entire arrays everytime something mutates an
element within it, is a complete nonsense. It basically throws away
the very advantage of having shared memory in the first place. And
shared memory is the very reason detre of threading.
There's nothing about D 2.0 which would prevent you from doing this.
D 2.0 is still a systems programming language which will let you do
whatever you want with your data.
So, in D2, if a pass an slices of an array to several threads and they
mutate those slices, when the threads end, the main thread can see
(and further manipulate) the results of their work by simply iterating
the original array?
b.
unless, the threads extend the slice. :(
Me Here wrote:
Walter Bright wrote:
There's nothing about D 2.0 which would prevent you from doing this. D 2.0 is
still a systems programming language which will let you do whatever you want
with your data.
So, in D2, if a pass an slices of an array to several threads and they mutate
those slices, when the threads end, the main thread can see (and further
manipulate) the results of their work by simply iterating the original array?
Yes, but the onus will be on you (the programmer) to prevent data races
and do proper synchronization. You have to be very wary of cache
effects when writing data in one thread and expecting to see it in another.
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races and
do proper synchronization.
In the scenario described, the main thread initialises the array of data. Then,
non-overlapping slices of that are portioned out to N worker threads. Only one
thread ever modifies any given segment. When the worker threads are complete,
the 'results' are left in the original array available in its entirety only to
the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location (previously)
modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very well
documented by the OS writer or hardware manufacturers, then here's your chance
to get slashdotted (and diggited and redited etc. all concurrently) as the
discoveerer of a fatel processor flaw.
b.
--
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races
and
do proper synchronization.
In the scenario described, the main thread initialises the array of
data. Then,
non-overlapping slices of that are portioned out to N worker threads.
Only one
thread ever modifies any given segment. When the worker threads are
complete,
the 'results' are left in the original array available in its entirety
only to
the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location
(previously)
modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very
well
documented by the OS writer or hardware manufacturers, then here's your
chance
to get slashdotted (and diggited and redited etc. all concurrently) as
the
discoveerer of a fatel processor flaw.
I don't think that's exactly what he means. If I understand things
correctly, if one thread is going to read something, that something
might be put in cache /before/ the other thread writes its data there.
So yes, it is previously written, at the time the read 'should' take
place.
-- Simen
Walter: Please, please, please. Take a break. A holiday (far away from Andrie)
and apply your own, rational, non-hyped thought processes to this problem.
(Stay off the purity cool-aid for a few days). Do a little research into the
types of problems and algorithms that truely lend themselves to being
multi-threaded and analyse the effects of all that damn, unwanted and
uncontrollable replication.
... And take a break from http://www.reddit.com/r/programming/
Reddit does NOT reflect the current research status nor does it reflect
the opinion of the majarority of programmers and it offers no outlook
into the future! Reddit is a self supporting system of some LISP /
Functional Programming Zealots. People there are going Bonkers if
someone posts a pong clone in Haskell/Lisp/RoR or what ever.
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message
news:g4cp3p$rkc$1 digitalmars.com...
It would be sad to see the D2 const swerve shake off all the old D
supporters off the D train. But on the other hand, new folks do seem to
keep popping up who would rather use D2 than D1.
I kind of wonder if half of them are simply tricked by the DM site into
thinking that D2 is actually out and usable. It tends to guide you to D2.
"Bill Baxter" wrote
What's left of D2 const is pretty much like what many are used to with
C++. Yeh, so you have to write some methods multiple times for different
constnesses, etc... you get used to it.
Slightly OT, the "scoped const" proposal I made a while back would help
solve this:
http://d.puremagic.com/issues/show_bug.cgi?id=1961
The main complaint from Andrei and Walter seems to be that any new features
or solutions that involve const will make it "too complicated." If you want
to know my response to that, read my latest comment:
http://d.puremagic.com/issues/show_bug.cgi?id=1961#c11
IMHO, I think Walter and Andrei hide behind the "can't do that because it
will make people like const less" defense much too often, especially when it
is a purely political defense (one that cannot ever be disproven unless the
proposal in question is implemented).
-Steve
Bill Baxter Wrote:
Don wrote:
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox
like u r interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of
the community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
I think there was a lot of hope on the part of the community that a
const system designed from scratch with 20/20 hind-sight could avoid
some of the practical problems with the C++ const system. But it seems
the answer to that was "no". The system we've got now seems to solve
some *theoretical* problems with the C++ const system at the cost of
making practical usage slightly more cumbersome.
But I don't hope for a more usable const any more. I'd just like to see
a reduction in the number of flavors of D code. If we all moved to D2,
I think we could pretty much just ignore invariant until it actually has
some practical benefit. What's left of D2 const is pretty much like
what many are used to with C++. Yeh, so you have to write some methods
multiple times for different constnesses, etc... you get used to it. I
think I could get used to D2 const anyway.
good point. i'm thinkin' it is useful today actually for the sakes of string
alone. string is a blessed godsend. without string sure as fuck there's no hope
to write ten fucking lines of scripting code or 100 lines of serious code 4
that matter. d1 strings are fucked. and the more app grows the more fucked they
are coz nobody in hell knows who aliased them just to fuck with them later.
> At the very least, it's a public relations disaster from the point of
> view of the language designers. They are assuming that with more time
> and education, the legitimate complaints about first const system will
> be forgotten, and the const system will be embraced by the community.
> But there is a very big risk here -- what if it is NOT eventually
> accepted? What if the community concensus remains that const is just too
> complicated, without enough benefit? And the language designers remain
> steadfastly devoted to const? That's a catastrophic scenario, and
> unfortunately not unlikely.
>
> The fact that someone as senior in the community as yourself is
> expressing profound dissatisfaction indicates that the risk is very real.
It would be sad to see the D2 const swerve shake off all the old D
supporters off the D train. But on the other hand, new folks do seem to
keep popping up who would rather use D2 than D1.
i lurked here on & off 4 quite a while since the d1 days (who the fuck made me
unlurk? shit) but i used d2 as soon as it appeared. but then i use os betas and
shit. d1 is cute but due for retirement. nobody will switch 2 d1 from 1other
real language. there's just not enough shit in d1 to compel. but d2 really
fucks all other language's girlfriends. has tons of amazing shit already and is
ready 2 bag threads. now when that happens every1 will want to use d2 or copy
it.
Don Wrote:
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of the
community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
At the very least, it's a public relations disaster from the point of
view of the language designers. They are assuming that with more time
and education, the legitimate complaints about first const system will
be forgotten, and the const system will be embraced by the community.
But there is a very big risk here -- what if it is NOT eventually
accepted? What if the community concensus remains that const is just too
complicated, without enough benefit? And the language designers remain
steadfastly devoted to const? That's a catastrophic scenario, and
unfortunately not unlikely.
The fact that someone as senior in the community as yourself is
expressing profound dissatisfaction indicates that the risk is very real.
here's 1 problem as i c it. is d catering 2 current community exclusively? dun
think so. then u want to attract other ppl from the outside world. 2 those the
history of const means shit. they want a good system. c++ refugees will sure
want 1. java refugees will see it as an advantage.
p.s. also thanks don 4 all great work u've done 4 d.
superdan wrote:
Don Wrote:
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of the
community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
At the very least, it's a public relations disaster from the point of
view of the language designers. They are assuming that with more time
and education, the legitimate complaints about first const system will
be forgotten, and the const system will be embraced by the community.
But there is a very big risk here -- what if it is NOT eventually
accepted? What if the community concensus remains that const is just too
complicated, without enough benefit? And the language designers remain
steadfastly devoted to const? That's a catastrophic scenario, and
unfortunately not unlikely.
The fact that someone as senior in the community as yourself is
expressing profound dissatisfaction indicates that the risk is very real.
here's 1 problem as i c it. is d catering 2 current community exclusively? dun
think so. then u want to attract other ppl from the outside world. 2 those the
history of const means shit. they want a good system. c++ refugees will sure
want 1. java refugees will see it as an advantage.
p.s. also thanks don 4 all great work u've done 4 d.
If I had a Euro for each time you used bad language, I'd be at least a
few hundred Euros richer.
This is not a forum for 10 year olds discussing their zits. If I can use
a fucking spell-checker, so can you. remember, readers of this NG are
from all over the world, and it would be the proper and polite thing to
do to at least use proper English to make it easier for them to
understand what you said. Besides, if you want to be taken seriously,
using that kind of language does not help your cause. Grow up, this is
not ICQ.
--Yigal
Yigal Chripun Wrote:
superdan wrote:
Don Wrote:
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of the
community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
At the very least, it's a public relations disaster from the point of
view of the language designers. They are assuming that with more time
and education, the legitimate complaints about first const system will
be forgotten, and the const system will be embraced by the community.
But there is a very big risk here -- what if it is NOT eventually
accepted? What if the community concensus remains that const is just too
complicated, without enough benefit? And the language designers remain
steadfastly devoted to const? That's a catastrophic scenario, and
unfortunately not unlikely.
The fact that someone as senior in the community as yourself is
expressing profound dissatisfaction indicates that the risk is very real.
here's 1 problem as i c it. is d catering 2 current community exclusively? dun
think so. then u want to attract other ppl from the outside world. 2 those the
history of const means shit. they want a good system. c++ refugees will sure
want 1. java refugees will see it as an advantage.
p.s. also thanks don 4 all great work u've done 4 d.
If I had a Euro for each time you used bad language, I'd be at least a
few hundred Euros richer.
and if i had 1 zimbabwe hyperinflated dollar for every time dee girl handed ur
sorry ass on a silver plate, i'd be richer still.
u r the second best example of what's bad in this group. u obviously have no
idea what u r talking about. u misuse terms left & right. u can't understand
the consequences of ur own rules and ideas (4 the lack of a better word).
probably ur source of inspiration is fucking wikipedia. u can't tell an alias,
delegate, and stack frame from as many holes in the ground. yet u keep on
coming confident & cocky & shit and teach people shit around here. good think
dee girl showed u clear & good what a fraud u r. go read some shit will ya.
geez.
This is not a forum for 10 year olds discussing their zits. If I can use
a fucking spell-checker, so can you. remember, readers of this NG are
from all over the world, and it would be the proper and polite thing to
do to at least use proper English to make it easier for them to
understand what you said.
relax. i do use a spell checker. just had to add a couple words.
Besides, if you want to be taken seriously,
using that kind of language does not help your cause. Grow up, this is
not ICQ.
in all likelihood i'm older than u but anyhow, since when was age a
discriminating factor. thought it's the shit u know or u don't, but since u
don't know none, u go with the age thing. got it.
u don't like me killfile me. won't change my id.
Reply to superdan,
The way you wright is hard to read. If you keep doing it people will just
quit reading you. I tend to do thing by setting a filter to automatically
mark people a read. Some people set the filter to delete. Regardless, if
you keep it up, you might as well talk to a wall for all the good it will do.
It is barely worth my time to tell you this. It is not worth my time to further
debate it.
BCS Wrote:
Reply to superdan,
The way you wright is hard to read. If you keep doing it people will just
quit reading you. I tend to do thing by setting a filter to automatically
mark people a read. Some people set the filter to delete. Regardless, if
you keep it up, you might as well talk to a wall for all the good it will do.
u almost had me... pardon. you almost had me until i saw "wright". shit man.
that fucks your entire argument right there. ok i can write without leet and
shit but if something is fucked up its ass i will say it is fucked up its ass.
and if u ever use wright instead of write i swear i will beat u with the heel
of my shoe. okay?
superdan Wrote:
BCS Wrote:
Reply to superdan,
The way you wright is hard to read. If you keep doing it people will just
quit reading you. I tend to do thing by setting a filter to automatically
mark people a read. Some people set the filter to delete. Regardless, if
you keep it up, you might as well talk to a wall for all the good it will do.
u almost had me... pardon. you almost had me until i saw "wright". shit man.
that fucks your entire argument right there. ok i can write without leet and
shit but if something is fucked up its ass i will say it is fucked up its ass.
and if u ever use wright instead of write i swear i will beat u with the heel
of my shoe. okay?
i meant "you" not "u". shit. but at least i'm tryin'.
superdan Wrote:
in all likelihood i'm older than u but anyhow, since when was age a
discriminating factor. thought it's the shit u know or u don't, but since u
don't know none, u go with the age thing. got it.
u don't like me killfile me. won't change my id.
He was trying to help you out by explaining that unless you're on an MMO
or instant messenger, typing that way conveys certain assumptions. Your
posts seem moderately intelligent in content, but it's difficult for many
people here to take them seriously (i.e. as anything more than trolling) if
you type that way. If your intent is to troll, then ignore/flame this post,
but if your intent is to actually have a discussion consider reducing your
use of swear words, using correct mechanics (i.e. punctuation and
capitalization) and not using shortened forms of words. Otherwise, no one
will see your posts as anything more than flamebait/junk, and the topics
you wish to discuss will get lost.
Also, if your intent is to troll, search the archives for "Ty Tower," he was
(a little) better at it.
Robert Fraser Wrote:
superdan Wrote:
in all likelihood i'm older than u but anyhow, since when was age a
discriminating factor. thought it's the shit u know or u don't, but since u
don't know none, u go with the age thing. got it.
u don't like me killfile me. won't change my id.
He was trying to help you out by explaining that unless you're on an MMO
or instant messenger, typing that way conveys certain assumptions. Your
posts seem moderately intelligent in content, but it's difficult for many
people here to take them seriously (i.e. as anything more than trolling) if
you type that way. If your intent is to troll, then ignore/flame this post,
but if your intent is to actually have a discussion consider reducing your
use of swear words, using correct mechanics (i.e. punctuation and
capitalization) and not using shortened forms of words. Otherwise, no one
will see your posts as anything more than flamebait/junk, and the topics
you wish to discuss will get lost.
ok will conform. what can i do? but if i can't fuckshit now and then i'm
fucked. can't fuckshit at work. can't fuckshit at home. now i can't fuckshit on
the internet? what's this world coming to?
one more thing. could you please nicely with sugar on top explain what i did to
that bcs fella? thought i was trying to be nice to him.
Also, if your intent is to troll, search the archives for "Ty Tower," he was
(a little) better at it.
never got his train of logic, if it ever left the station. that dood is due for
some serious detox.
superdan <super dan.org> wrote:
Robert Fraser Wrote:
superdan Wrote:
in all likelihood i'm older than u but anyhow, since when was age a
discriminating factor. thought it's the shit u know or u don't, but
since u don't know none, u go with the age thing. got it.
u don't like me killfile me. won't change my id.
He was trying to help you out by explaining that unless you're on an MMO
or instant messenger, typing that way conveys certain assumptions. Your
posts seem moderately intelligent in content, but it's difficult for
many
people here to take them seriously (i.e. as anything more than
trolling) if
you type that way. If your intent is to troll, then ignore/flame this
post,
but if your intent is to actually have a discussion consider reducing
your
use of swear words, using correct mechanics (i.e. punctuation and
capitalization) and not using shortened forms of words. Otherwise, no
one
will see your posts as anything more than flamebait/junk, and the topics
you wish to discuss will get lost.
ok will conform. what can i do? but if i can't fuckshit now and then i'm
fucked. can't fuckshit at work. can't fuckshit at home. now i can't
fuckshit on the internet? what's this world coming to?
Feel free to "fuckshit" all you want. Just don't expect people to take
you seriously when you do.
one more thing. could you please nicely with sugar on top explain what i
did to that bcs fella? thought i was trying to be nice to him.
"if u ever use wright instead of write i swear i will beat u with the
heel of my shoe". I can't quite see how that's being nice. Of course, it
might have been meant as a joke, but irony is easily lost in written media.
Also, if your intent is to troll, search the archives for "Ty Tower,"
he was
(a little) better at it.
never got his train of logic, if it ever left the station. that dood is
due for some serious detox.
-- Simen
On Wed, Jul 2, 2008 at 3:16 PM, Simen Kjaeraas <simen.kjaras gmail.com> wrote:
Feel free to "fuckshit" all you want. Just don't expect people to take
you seriously when you do.
[...]
-- Simen
http://enigma.dune.net/~eric/Do-not-feed-the-troll.PNG
Reply to Simen,
one more thing. could you please nicely with sugar on top explain
what i did to that bcs fella? thought i was trying to be nice to
him.
"if u ever use wright instead of write i swear i will beat u with the
heel of my shoe". I can't quite see how that's being nice. Of course,
it might have been meant as a joke, but irony is easily lost in
written media.
While I agree that that is an odd way of being nice, it's not that I was
offended by what he said, I just decided that it isn't worth my time to read
his post.
Don wrote:
Sean Kelly wrote:
so wut is that stuff u want in d. u haven't even tried d2 so it loox
like u r interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of
the community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it.
By D2, I imagine you just mean "the const system"?
No. Pretty much all of D2 actually, if I wanted to pick nits. But the
const system is what I have the greatest distaste for from a functional
perspective.
(Most of the other things in D2 seem to have been very popular; if D2-
without-const was released, I reckon most of the community would start
using it).
I'd certainly be more open to giving it a shot, particularly since I
could then use it with few if any modifications to my code.
It seems to me that the view of the community is "We though we wanted
const. But now that we've seen what const involves, we don't want it.".
Personally, after spending some time with D I didn't miss const in the
least. But perhaps more importantly, I trusted that if D ever got a
const system it would be something that matched the simplicity and
elegance of the rest of the language. Unfortunately, I don't feel that
this is the case with the current design.
At the very least, it's a public relations disaster from the point of
view of the language designers. They are assuming that with more time
and education, the legitimate complaints about first const system will
be forgotten, and the const system will be embraced by the community.
But there is a very big risk here -- what if it is NOT eventually
accepted? What if the community concensus remains that const is just too
complicated, without enough benefit? And the language designers remain
steadfastly devoted to const? That's a catastrophic scenario, and
unfortunately not unlikely.
I honestly can't say whether I'll ever "come around" and decide I like
D2, but so far this seems unlikely. But what does this mean in the
long-term? None of the alternatives I've considered seem terribly
appealing.
Sean
Don wrote:
What if the community concensus remains that const is just too
complicated, without enough benefit?
A simpler const system (such as what C++ has) has little benefit, and
all the other const proposals were much more complex.
"Walter Bright" <newshound1 digitalmars.com> wrote in message
news:g6188e$smu$1 digitalmars.com...
Don wrote:
What if the community concensus remains that const is just too
complicated, without enough benefit?
A simpler const system (such as what C++ has) has little benefit, and all
the other const proposals were much more complex.
I think what he's getting at here is that the community concensus might just
be that const-correctness, at least C-style const-correctness (from which
the D2 system is derived), is not good, not that we want a simpler system.
Why bother, nothing's going to change.
Walter Bright Wrote:
Don wrote:
What if the community concensus remains that const is just too
complicated, without enough benefit?
A simpler const system (such as what C++ has) has little benefit, and
all the other const proposals were much more complex.
I'm interested enough in the new const system to try it out, but my projects
are dependent on Tango.
I do have a few concerns about the const system, but nothing big enough to keep
me from trying it.
By far, my biggest complaint is that the const system makes only one of the
following two methods compile. It forces programmers to settle for using
global variables to bypass const restrictions. It also touches upon why the
purity is required when doing multithreading. I can't fully embrace const
until it stops encouraging global variables and the gap between purity and
const is reduced/eliminated.
=============
logFile log;
class foo{
void bar() invariant{
log.write("Hello World");
}
}
=============
class Foo{
logFile log;
void bar() invariant{
log.write("Hello World");
}
}
=============
Jason House wrote:
By far, my biggest complaint is that the const system makes only one
of the following two methods compile. It forces programmers to
settle for using global variables to bypass const restrictions. It
also touches upon why the purity is required when doing
multithreading. I can't fully embrace const until it stops
encouraging global variables and the gap between purity and const is
reduced/eliminated.
=============
logFile log; class foo{ void bar() invariant{
log.write("Hello World"); } } ============= class Foo{ logFile log;
void bar() invariant{ log.write("Hello World"); } } =============
But the bar() function is not invariant, nor can it be pure if it writes
things to global state. I am not sure why bar() needs to be pure, but it
*cannot* be pure if it changes either global state or the state of one
of its arguments.
Walter Bright Wrote:
Jason House wrote:
By far, my biggest complaint is that the const system makes only one
of the following two methods compile. It forces programmers to
settle for using global variables to bypass const restrictions. It
also touches upon why the purity is required when doing
multithreading. I can't fully embrace const until it stops
encouraging global variables and the gap between purity and const is
reduced/eliminated.
=============
logFile log; class foo{ void bar() invariant{
log.write("Hello World"); } } ============= class Foo{ logFile log;
void bar() invariant{ log.write("Hello World"); } } =============
But the bar() function is not invariant,
That depends on which version of bar you're talking about. The first bar
conforms to the current D standard for invariance. Everything in class foo
remains untouched in the first example, and so bar is invariant.
nor can it be pure if it writes
things to global state. I am not sure why bar() needs to be pure, but it
*cannot* be pure if it changes either global state or the state of one
of its arguments.
That's exactly right. So what purpose is declaring bar as invariant serving?
It's not supporting functional-style multithreading, but wasn't that the point
for the const system? Since transitive const is already viral, it makes little
sense to me that it shouldn't extend to static/global state. That removes the
temptation of programmers to use static/global state to circumvent the const
system. If that's problematic, then IMHO, something must be re-thought because
it means people's use of D's const system will not support the functional-style
multithreading because people are using it the wrong way.
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
By far, my biggest complaint is that the const system makes only
one of the following two methods compile. It forces programmers
to settle for using global variables to bypass const
restrictions. It also touches upon why the purity is required
when doing multithreading. I can't fully embrace const until it
stops encouraging global variables and the gap between purity and
const is reduced/eliminated.
=============
logFile log; class foo{ void bar() invariant{
log.write("Hello World"); } } ============= class Foo{ logFile
log; void bar() invariant{ log.write("Hello World"); } }
=============
But the bar() function is not invariant,
That depends on which version of bar you're talking about. The first
bar conforms to the current D standard for invariance. Everything in
class foo remains untouched in the first example, and so bar is
invariant.
True, but it is not pure. Pure functions cannot change global state.
nor can it be pure if it writes things to global state. I am not
sure why bar() needs to be pure, but it *cannot* be pure if it
changes either global state or the state of one of its arguments.
That's exactly right. So what purpose is declaring bar as invariant
serving?
I don't know why it needed to be marked as invariant (I didn't write it
<g>).
It's not supporting functional-style multithreading, but
wasn't that the point for the const system?
It is one of the points of the const system. But the idea is not to just
declare things invariant and magically they will work in functional
style. The idea is that if you want to make something functional, the
language will provide support for it if only in the form of telling you
when something will not work in functional style. That appears to be the
case with bar() - it cannot work in functional style.
Since transitive const
is already viral, it makes little sense to me that it shouldn't
extend to static/global state. That removes the temptation of
programmers to use static/global state to circumvent the const
system. If that's problematic, then IMHO, something must be
re-thought because it means people's use of D's const system will not
support the functional-style multithreading because people are using
it the wrong way.
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global state
from within a function that is not supposed to do that. Invariant does
not imply pure.
These concepts are not simple, but there is no way to support shared
state in multithreaded programming without understanding those concepts.
C++ the language has no concept of these things, and people get into
endless trouble with it when misunderstanding things and screwing it up.
The C++ language itself is of NO help at all. With D, the idea is to
enable the language to help by moving things from convention to law.
Completely ignoring the issues, like C++ does, is no solution.
Walter Bright wrote:
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
By far, my biggest complaint is that the const system makes only
one of the following two methods compile. It forces programmers
to settle for using global variables to bypass const
restrictions. It also touches upon why the purity is required
when doing multithreading. I can't fully embrace const until it
stops encouraging global variables and the gap between purity and
const is reduced/eliminated.
=============
logFile log; class foo{ void bar() invariant{
log.write("Hello World"); } } ============= class Foo{ logFile
log; void bar() invariant{ log.write("Hello World"); } }
=============
But the bar() function is not invariant,
That depends on which version of bar you're talking about. The first
bar conforms to the current D standard for invariance. Everything in
class foo remains untouched in the first example, and so bar is
invariant.
True, but it is not pure. Pure functions cannot change global state.
The current definition of pure goes even farther than that. Because
arguments to pure functions must be invariant (as far as I know), pure
functions may not accept parameters that could be changed by another thread.
These concepts are not simple, but there is no way to support shared
state in multithreaded programming without understanding those concepts.
C++ the language has no concept of these things, and people get into
endless trouble with it when misunderstanding things and screwing it up.
The C++ language itself is of NO help at all. With D, the idea is to
enable the language to help by moving things from convention to law.
Completely ignoring the issues, like C++ does, is no solution.
So will D have some way to require that references passed between
threads must be either invariant or represent a transferral of
ownership? I think that's the crux of the issue. Using invariance for
non-shared data is typically more for simplifying error recovery than
anything else.
Sean
Sean Kelly wrote:
Walter Bright wrote:
True, but it is not pure. Pure functions cannot change global state.
The current definition of pure goes even farther than that. Because
arguments to pure functions must be invariant (as far as I know), pure
functions may not accept parameters that could be changed by another
thread.
That's right. One way to think about it (*) is that for pure functions,
if you take a bit copy of its arguments on the stack, save them, and
some arbitrary time in the future call the function again with those
same bits, you must get back exactly the same result.
So will D have some way to require that references passed between
threads must be either invariant or represent a transferral of
ownership? I think that's the crux of the issue. Using invariance for
non-shared data is typically more for simplifying error recovery than
anything else.
Consider (*). Pure functions do not "own" data, as they cannot have state.
Walter Bright wrote:
Sean Kelly wrote:
Walter Bright wrote:
True, but it is not pure. Pure functions cannot change global state.
The current definition of pure goes even farther than that. Because
arguments to pure functions must be invariant (as far as I know), pure
functions may not accept parameters that could be changed by another
thread.
That's right. One way to think about it (*) is that for pure functions,
if you take a bit copy of its arguments on the stack, save them, and
some arbitrary time in the future call the function again with those
same bits, you must get back exactly the same result.
So will D have some way to require that references passed between
threads must be either invariant or represent a transferral of
ownership? I think that's the crux of the issue. Using invariance
for non-shared data is typically more for simplifying error recovery
than anything else.
Consider (*). Pure functions do not "own" data, as they cannot have state.
I personally feel that requiring that parameters be const is sufficient
for memoizing results. Requiring invariance assumes a programming model
that I simply don't endorse. But I'll grant that it's certainly the
safer approach.
Sean
Sean Kelly wrote:
I personally feel that requiring that parameters be const is sufficient
for memoizing results. Requiring invariance assumes a programming model
that I simply don't endorse. But I'll grant that it's certainly the
safer approach.
What such a an approach would rely on would be the *convention* that
nobody would change the referenced const data from one invocation of the
function to the next. This contradicts the whole premise, and is no
better than C++.
Walter Bright wrote:
Sean Kelly wrote:
I personally feel that requiring that parameters be const is
sufficient for memoizing results. Requiring invariance assumes a
programming model that I simply don't endorse. But I'll grant that
it's certainly the safer approach.
What such a an approach would rely on would be the *convention* that
nobody would change the referenced const data from one invocation of the
function to the next. This contradicts the whole premise, and is no
better than C++.
Oops, you're right. I was thinking simply of the data changing while
the function was executing. I suppose requiring invariance of
parameters does make sense.
Sean
Sean Kelly Wrote:
Walter Bright wrote:
Sean Kelly wrote:
I personally feel that requiring that parameters be const is
sufficient for memoizing results. Requiring invariance assumes a
programming model that I simply don't endorse. But I'll grant that
it's certainly the safer approach.
What such a an approach would rely on would be the *convention* that
nobody would change the referenced const data from one invocation of the
function to the next. This contradicts the whole premise, and is no
better than C++.
Oops, you're right. I was thinking simply of the data changing while
the function was executing. I suppose requiring invariance of
parameters does make sense.
Sean
that's one interesting about d's const system. looks like there's extra shit
that you wouldn't need, but as soon as you take any out you're fucked. i'm not
sure it's enough yet, from what i can tell invariant object construction is a
grandmotherfuck. but sure there's no fat in the system right now.
reminds me of the kon tiki expedition i saw when i was a kid. this guy thor
heyerdahl reproduced an ancient expedition in a boat made of bamboo or
something. he made it like in antiquity, but there was an extra rope at the
front that he found unnecessary. so he was like, fuck that rope, don't put it
in. sure as shit, in a few weeks' time the bamboo boat was bending and sinking
exactly where the rope would have held it properly in place. for some reason
that particular story stayed with me ever since.
const is the rope that keeps invariant shit and mutable shit together. without
const there'd be like two worlds separated by a ridge. that system would be
fucked. without invariant the system would be like an eunuch: sees a lot of
good stuff goin' on but can't do shit about it because it's powerless. (that's
c++ by the way.) with const there's two worlds that can communicate.
On 2008-07-23 02:40:55 +0200, Sean Kelly <sean invisibleduck.org> said:
Walter Bright wrote:
Sean Kelly wrote:
I personally feel that requiring that parameters be const is sufficient
for memoizing results. Requiring invariance assumes a programming
model that I simply don't endorse. But I'll grant that it's certainly
the safer approach.
What such a an approach would rely on would be the *convention* that
nobody would change the referenced const data from one invocation of
the function to the next. This contradicts the whole premise, and is no
better than C++.
Oops, you're right. I was thinking simply of the data changing while
the function was executing. I suppose requiring invariance of
parameters does make sense.
Sean
I think that the const/invariant separation makes much sense, and the
whole framework is sound:
const: this constant *now* and should not be changed by you (but might
be changed by others)
invariant: this won't be changed by anybody (always constant), you can
cache it, do whatever you want to it, expect it to remain the same also
in the future
From another post of Walter:
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
I thin the invariant should not necessarily allow that.
Let's call invariantW the invariant that can be placed in readonly memory.
I introduce a weaker form of invariant that I call invariantF.
For invariant F the bits that a function can see are constant (as with
invariantW), but the bits might not be actually there in the hardware
from the beginning.
This allows lazy evaluation, and single value dataflow variables.
Lazy evaluation means that part of the structure is calculated "on
demand" by a pure function, at the logical level the result of it is
known from the beginning and constant, but the bits are not there yet,
in case of race conditions the bits can be calculated twice, but the
result would still be the same, so it is just an efficiency problem
that does not change any result.
In dataflow variables the result is calculated by someone else, and if
you request it you wait until it is there. Also in this case the value
should be unique, actually one might allow the result to be set more
than once, but only if it is set to always the same value (or a
compatible partial value).
These two things add lot of power to functional programming, leaving
all the nice properties of it intact.
A function should not be able to know if the bits are already there,
for it they are always already there, but from the efficiency point of
view it can make a huge difference, the difference between streaming a
file and loading it at once for example.
Clearly invariantF is weaker than invariantW, and you loose some
optimization possibilities, like putting everything in ROM, but the
functional core gains a lot of power.
I think that the two concepts are really close enough so that only one
should be adopted (I don't want an almost_invariant keyword), and I
think that D should really adopt invariantF concept because that way
the functional core gets a lot more useful, I want to use pure lazy
datastructures with a compiler that optimizes them.
Fawzi
Fawzi Mohamed wrote:
On 2008-07-23 02:40:55 +0200, Sean Kelly <sean invisibleduck.org> said:
Walter Bright wrote:
Sean Kelly wrote:
I personally feel that requiring that parameters be const is
sufficient for memoizing results. Requiring invariance assumes a
programming model that I simply don't endorse. But I'll grant that
it's certainly the safer approach.
What such a an approach would rely on would be the *convention* that
nobody would change the referenced const data from one invocation of
the function to the next. This contradicts the whole premise, and is
no better than C++.
Oops, you're right. I was thinking simply of the data changing while
the function was executing. I suppose requiring invariance of
parameters does make sense.
I think that the const/invariant separation makes much sense, and the
whole framework is sound:
const: this constant *now* and should not be changed by you (but might
be changed by others)
invariant: this won't be changed by anybody (always constant), you can
cache it, do whatever you want to it, expect it to remain the same also
in the future
I think the theory is completely sound, I'm just not convinced it's
worth the cost in terms of its impact on D programs.
From another post of Walter:
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
I thin the invariant should not necessarily allow that.
I think the salient point is that invariant data /can/ be placed in ROM,
not that it has to. In fact, only some invariant data can be placed in
ROM--that data which is known at compile-time. const data in D 1.0
works this way.
Sean
On 2008-07-23 18:14:53 +0200, Sean Kelly <sean invisibleduck.org> said:
Fawzi Mohamed wrote:
From another post of Walter:
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
I thin the invariant should not necessarily allow that.
I think the salient point is that invariant data /can/ be placed in
ROM, not that it has to. In fact, only some invariant data can be
placed in ROM--that data which is known at compile-time. const data in
D 1.0 works this way.
It depends on what the purpose of invariant is.
If the purpose of invariant is to enable good support for functional
style, and avoid concurrency problems then I think that an invariant
that guarantees that 4 is never automatically enforced would be better
(that or the infamous mutable/unpaintable keyword, or (but more
difficult to do well at the first attempt, instead of letting this be a
library implementable feature) language given thunks).
The thing is that as there are lazy functions (and those are present in
D) there are also lazy datastructures.
Lazy datastructures can have pieces that are not yet computed, so they
cannot be invariantW.
A simple example is a linked list (it could be also a tree, or other
structures), if it is lazy it can be produced "as needed" and if the
root is not needed consumes little memory.
These are powerful features of functional languages that would not be
part of D functional core.
Fawzi
Walter Bright Wrote:
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
By far, my biggest complaint is that the const system makes only
one of the following two methods compile. It forces programmers
to settle for using global variables to bypass const
restrictions. It also touches upon why the purity is required
when doing multithreading. I can't fully embrace const until it
stops encouraging global variables and the gap between purity and
const is reduced/eliminated.
=============
logFile log; class foo{ void bar() invariant{
log.write("Hello World"); } } ============= class Foo{ logFile
log; void bar() invariant{ log.write("Hello World"); } }
=============
But the bar() function is not invariant,
That depends on which version of bar you're talking about. The first
bar conforms to the current D standard for invariance. Everything in
class foo remains untouched in the first example, and so bar is
invariant.
True, but it is not pure. Pure functions cannot change global state.
nor can it be pure if it writes things to global state. I am not
sure why bar() needs to be pure, but it *cannot* be pure if it
changes either global state or the state of one of its arguments.
That's exactly right. So what purpose is declaring bar as invariant
serving?
I don't know why it needed to be marked as invariant (I didn't write it
<g>).
It's not supporting functional-style multithreading, but
wasn't that the point for the const system?
It is one of the points of the const system. But the idea is not to just
declare things invariant and magically they will work in functional
style. The idea is that if you want to make something functional, the
language will provide support for it if only in the form of telling you
when something will not work in functional style. That appears to be the
case with bar() - it cannot work in functional style.
Can you answer this more thoroughly? It's really important to this dialog.
What *other* purposes does the const system serve besides opening the door to
functional programming? I understand that the const system must remain simple
to be usable.
Since transitive const
is already viral, it makes little sense to me that it shouldn't
extend to static/global state. That removes the temptation of
programmers to use static/global state to circumvent the const
system. If that's problematic, then IMHO, something must be
re-thought because it means people's use of D's const system will not
support the functional-style multithreading because people are using
it the wrong way.
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global state
from within a function that is not supposed to do that. Invariant does
not imply pure.
That's actually a very key part to my whole point. There is very little
difference between pure and invariant functions. Why do we need a concept for
both? Under the assumption that we're adding const to support functional
programming, I don't understand the motivation for this difference.
I look at this from the following basic principles:
1. As functional programming / implicit multithreading
requires pure functions
2. Pure functions require invariant state (object and global state)
3. Imperative programming requires mutable data
4. const (as defined in D) is required to bridge the gap between
mutable state and invariant state
In C++, we have const data requiring const functions, and in D we have const
(invariant) data requiring const (invariant) functions. The different being
that const (invariant) in D is transitive, yielding something that's closer to
truly constant state. Unfortunately, what D provides isn't enough.
Pure functions requires that any shared data is invariant. That means both
transitive invariance like D currently has plus invariant global state. The
net effect is that D currently contains two concepts - invariant functions and
pure functions. Based on principles 1&2, I can't justify the extra complexity.
What I keep wondering is why don't invariant functions operate like pure
functions? Changing transitive const to include any global state accessed
through a function seems quite natural to me.
Additionally, const functions as currently written in D are not always const.
The classic C++ example is a tree data structure where a programmer does
this.parent.child.property = 1; An analgous D example would be
global_root.child.property = 1;
If the change I hope to see comes about, this loophole will be closed.
These concepts are not simple, but there is no way to support shared
state in multithreaded programming without understanding those concepts.
C++ the language has no concept of these things, and people get into
endless trouble with it when misunderstanding things and screwing it up.
The C++ language itself is of NO help at all. With D, the idea is to
enable the language to help by moving things from convention to law.
Completely ignoring the issues, like C++ does, is no solution.
I believe that I understand, and hope my more verbose post above will help
convince you of that. I believe (nievely?) that I have value to add if only I
can convince you. I truly do think what I've outlined is a problem with the D
const system.
Jason House wrote:
Walter Bright Wrote:
It is one of the points of the const system. But the idea is not to
just declare things invariant and magically they will work in
functional style. The idea is that if you want to make something
functional, the language will provide support for it if only in the
form of telling you when something will not work in functional
style. That appears to be the case with bar() - it cannot work in
functional style.
Can you answer this more thoroughly? It's really important to this
dialog. What *other* purposes does the const system serve besides
opening the door to functional programming? I understand that the
const system must remain simple to be usable.
1. It makes function APIs self-documenting.
2. Invariance allows one to pass large data structures around by
reference yet treat them as if one passed them by value. Strings are the
canonical example of that.
3. Const allows one function to service both mutable and invariant
arguments.
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
5. Invariant data does not have to be synchronized to be multithread
accessible.
6. Invariant data improves the ability of automated tools to make
inferences about what is happening. Optimization is an example of such.
The missing ingredient here is what the 'pure' modifier for
functions provides. That is the ability to diagnose attempts to
alter global state from within a function that is not supposed to
do that. Invariant does not imply pure.
That's actually a very key part to my whole point. There is very
little difference between pure and invariant functions. Why do we
need a concept for both? Under the assumption that we're adding
const to support functional programming, I don't understand the
motivation for this difference.
See points 1..5.
Pure functions requires that any shared data is invariant.
Yes, but invariant data does not require purity.
The net effect is that D currently contains two
concepts - invariant functions and pure functions.
Yes.
Based on principles 1&2, I can't justify the extra complexity.
I can with points 1..5.
I believe that I understand, and hope my more verbose post above will
help convince you of that. I believe (nievely?) that I have value to
add if only I can convince you. I truly do think what I've outlined
is a problem with the D const system.
I hope this post will convince you otherwise. If not, I can try again <g>.
Walter Bright Wrote:
Jason House wrote:
Walter Bright Wrote:
It is one of the points of the const system. But the idea is not to
just declare things invariant and magically they will work in
functional style. The idea is that if you want to make something
functional, the language will provide support for it if only in the
form of telling you when something will not work in functional
style. That appears to be the case with bar() - it cannot work in
functional style.
Can you answer this more thoroughly? It's really important to this
dialog. What *other* purposes does the const system serve besides
opening the door to functional programming? I understand that the
const system must remain simple to be usable.
1. It makes function APIs self-documenting.
2. Invariance allows one to pass large data structures around by
reference yet treat them as if one passed them by value. Strings are the
canonical example of that.
3. Const allows one function to service both mutable and invariant
arguments.
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
5. Invariant data does not have to be synchronized to be multithread
accessible.
6. Invariant data improves the ability of automated tools to make
inferences about what is happening. Optimization is an example of such.
yeah. tell brad or andrei or whoever came up with that stuff that i'll buy them
a beer for point 2, i'll wash their feet for 3, and i'll buy them dinner at
ritz for 5. fuckin' a.
Walter Bright Wrote:
Jason House wrote:
What *other* purposes does the const system serve besides
opening the door to functional programming? I understand that the
const system must remain simple to be usable.
1. It makes function APIs self-documenting.
2. Invariance allows one to pass large data structures around by
reference yet treat them as if one passed them by value. Strings are the
canonical example of that.
3. Const allows one function to service both mutable and invariant
arguments.
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
5. Invariant data does not have to be synchronized to be multithread
accessible.
6. Invariant data improves the ability of automated tools to make
inferences about what is happening. Optimization is an example of such.
using properties or member functions, then I'd agree with it. Of course, that
non-const data that isn't effected by transitive const? It seems to me that
simple cases could work, but it quickly breaks down when trying to generalize.
For example, I could write a log utility that writes messages to standard out.
To write to any output, I'd need to store where to write log output to. Maybe
I could circumvent the const system and create a global object that looks up
where to write stuff. That'd let me pass around my logger as an invariant
object but then it'd be making an extra function call every time something gets
logged. That's a horrible design. Advanced compiler tricks may eliminate the
overhead, but it doesn't mean it'd save headache for the programmer.
Pure functions requires that any shared data is invariant.
Yes, but invariant data does not require purity.
I translate that as "I didn't implement it that way". Also, we need to
distinguish between raw access to invariant data and use of (invariant)
I hope this post will convince you otherwise. If not, I can try again <g>.
And I can try again too :)
Jason House Wrote:
Walter Bright Wrote:
Jason House wrote:
What *other* purposes does the const system serve besides
opening the door to functional programming? I understand that the
const system must remain simple to be usable.
1. It makes function APIs self-documenting.
2. Invariance allows one to pass large data structures around by
reference yet treat them as if one passed them by value. Strings are the
canonical example of that.
3. Const allows one function to service both mutable and invariant
arguments.
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
5. Invariant data does not have to be synchronized to be multithread
accessible.
6. Invariant data improves the ability of automated tools to make
inferences about what is happening. Optimization is an example of such.
using properties or member functions, then I'd agree with it. Of course, that
"data" and you say "function" and you'll pretty much have understood where the
problem in your reasoning was.
misunderstanding of data vs. function behavior with regard to immutability.
don't confuse data with functions. invariant data -> can't modify it even with
the sas. that means no synchronization on data necessary. invariant function ->
applies to invariant object and may or may not require synchronization. but
sure as shit invariant data does not need synchronization.
non-const data that isn't effected by transitive const? It seems to me that
simple cases could work, but it quickly breaks down when trying to generalize.
For example, I could write a log utility that writes messages to standard out.
To write to any output, I'd need to store where to write log output to. Maybe
I could circumvent the const system and create a global object that looks up
where to write stuff. That'd let me pass around my logger as an invariant
object but then it'd be making an extra function call every time something gets
logged. That's a horrible design. Advanced compiler tricks may eliminate the
overhead, but it doesn't mean it'd save headache for the programmer.
this is backwards. the logger object is not const. the shit it logs is const as
the logger has no business changing it.
Pure functions requires that any shared data is invariant.
Yes, but invariant data does not require purity.
I translate that as "I didn't implement it that way". Also, we need to
distinguish between raw access to invariant data and use of (invariant)
which was wrong, and your translation doesn't make it any better.
superdan Wrote:
Jason House Wrote:
Walter Bright Wrote:
5. Invariant data does not have to be synchronized to be multithread
accessible.
using properties or member functions, then I'd agree with it. Of course, that
"data" and you say "function" and you'll pretty much have understood where the
problem in your reasoning was.
misunderstanding of data vs. function behavior with regard to immutability.
don't confuse data with functions. invariant data -> can't modify it even with
the sas. that means no synchronization on data necessary. invariant function ->
applies to invariant object and may or may not require synchronization. but
sure as shit invariant data does not need synchronization.
All of my posts on this topic are about invariant functions rather than
invariant data. Walter's response focused more on invariant data, and I'm
intentionally trying to draw the distinction in what we're talking about.
I want to shift the discussion away from discussing purely invariant data and
instead discuss the functions to access the data. Proper object oriented
programming requires using functions, so any proper analysis of a const system
must include analyzing how functions are handled.
On 2008-07-23 17:30:48 +0200, Jason House <jason.james.house gmail.com> said:
superdan Wrote:
Jason House Wrote:
Walter Bright Wrote:
5. Invariant data does not have to be synchronized to be multithread
accessible.
access without using properties or member functions, then I'd agree
with it. Of course, that qualification eliminates most of the benefit
you'll pretty much have understood where the problem in your reasoning
was.
misunderstanding of data vs. function behavior with regard to
immutability.
don't confuse data with functions. invariant data -> can't modify it
even with the sas. that means no synchronization on data necessary.
invariant function -> applies to invariant object and may or may not
require synchronization. but sure as shit invariant data does not need
synchronization.
All of my posts on this topic are about invariant functions rather than
invariant data. Walter's response focused more on invariant data, and
I'm intentionally trying to draw the distinction in what we're talking
about.
I want to shift the discussion away from discussing purely invariant
data and instead discuss the functions to access the data. Proper
object oriented programming requires using functions, so any proper
analysis of a const system must include analyzing how functions are
handled.
the functions connected to invariant data are pure functions, invariant
functions are just functions with an invariant argument (this), see
Steven's reply to you in the other thread.
Fawzi Mohamed wrote:
On 2008-07-23 17:30:48 +0200, Jason House <jason.james.house gmail.com>
said:
superdan Wrote:
Jason House Wrote:
Walter Bright Wrote:
5. Invariant data does not have to be synchronized to be multithread
accessible.
data access without using properties or member functions, then I'd
agree with it. Of course, that qualification eliminates most of the
"function" and you'll pretty much have understood where the problem
in your reasoning was.
misunderstanding of data vs. function behavior with regard to
immutability.
don't confuse data with functions. invariant data -> can't modify it
even with the sas. that means no synchronization on data necessary.
invariant function -> applies to invariant object and may or may not
require synchronization. but sure as shit invariant data does not
need synchronization.
All of my posts on this topic are about invariant functions rather
than invariant data. Walter's response focused more on invariant
data, and I'm intentionally trying to draw the distinction in what
we're talking about.
I want to shift the discussion away from discussing purely invariant
data and instead discuss the functions to access the data. Proper
object oriented programming requires using functions, so any proper
analysis of a const system must include analyzing how functions are
handled.
the functions connected to invariant data are pure functions, invariant
functions are just functions with an invariant argument (this), see
Steven's reply to you in the other thread.
But when does that happen? Seems to me that it can only happen if the
class it is part of contains only invariant data. Which seems really
obscure. Any _member_ which is invariant is presumably declared
invariant anyway. Can anyone come up with a use case?
Don wrote:
Fawzi Mohamed wrote:
On 2008-07-23 17:30:48 +0200, Jason House
<jason.james.house gmail.com> said:
superdan Wrote:
Jason House Wrote:
Walter Bright Wrote:
5. Invariant data does not have to be synchronized to be multithread
accessible.
direct data access without using properties or member functions,
then I'd agree with it. Of course, that qualification eliminates
say "function" and you'll pretty much have understood where the
problem in your reasoning was.
misunderstanding of data vs. function behavior with regard to
immutability.
don't confuse data with functions. invariant data -> can't modify it
even with the sas. that means no synchronization on data necessary.
invariant function -> applies to invariant object and may or may not
require synchronization. but sure as shit invariant data does not
need synchronization.
All of my posts on this topic are about invariant functions rather
than invariant data. Walter's response focused more on invariant
data, and I'm intentionally trying to draw the distinction in what
we're talking about.
I want to shift the discussion away from discussing purely invariant
data and instead discuss the functions to access the data. Proper
object oriented programming requires using functions, so any proper
analysis of a const system must include analyzing how functions are
handled.
the functions connected to invariant data are pure functions,
invariant functions are just functions with an invariant argument
(this), see Steven's reply to you in the other thread.
But when does that happen? Seems to me that it can only happen if the
class it is part of contains only invariant data. Which seems really
obscure. Any _member_ which is invariant is presumably declared
invariant anyway. Can anyone come up with a use case?
I think the only point of an 'invariant' or even a 'const' label for
member functions is just that--a way to indicate to the compiler that
the hidden context pointer is invariant or const.
Sean
Sean Kelly wrote:
I think the only point of an 'invariant' or even a 'const' label for
member functions is just that--a way to indicate to the compiler that
the hidden context pointer is invariant or const.
Yes. That is all it is. It says nothing about the purity of the function.
superdan wrote:
Jason House Wrote:
Walter Bright Wrote:
Jason House wrote:
What *other* purposes does the const system serve besides
opening the door to functional programming? I understand that the
const system must remain simple to be usable.
1. It makes function APIs self-documenting.
2. Invariance allows one to pass large data structures around by
reference yet treat them as if one passed them by value. Strings are the
canonical example of that.
3. Const allows one function to service both mutable and invariant
arguments.
4. Invariant data can be placed in hardware protected readonly memory,
such as ROM.
5. Invariant data does not have to be synchronized to be multithread
accessible.
6. Invariant data improves the ability of automated tools to make
inferences about what is happening. Optimization is an example of such.
using properties or member functions, then I'd agree with it. Of course, that
"data" and you say "function" and you'll pretty much have understood where the
problem in your reasoning was.
misunderstanding of data vs. function behavior with regard to immutability.
don't confuse data with functions. invariant data -> can't modify it even with
the sas. that means no synchronization on data necessary. invariant function ->
applies to invariant object and may or may not require synchronization. but
sure as shit invariant data does not need synchronization.
To be fair, invariant data created at runtime does need synchronization
before passing it to another thread. But once the thread has it then no
more synchronization is necessary to access it. This is one aspect of
invariant that I think has been largely overlooked thus far, perhaps
partially because most people still have single core machines and/or are
using x86 machines, which have a pretty strict memory model.
Sean
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
What *other* purposes does the const system serve besides opening
the door to functional programming? I understand that the const
system must remain simple to be usable.
1. It makes function APIs self-documenting. 2. Invariance allows
one to pass large data structures around by reference yet treat
them as if one passed them by value. Strings are the canonical
example of that. 3. Const allows one function to service both
mutable and invariant arguments. 4. Invariant data can be placed in
hardware protected readonly memory, such as ROM. 5. Invariant data
does not have to be synchronized to be multithread accessible. 6.
Invariant data improves the ability of automated tools to make
inferences about what is happening. Optimization is an example of
such.
they can manipulate global state.
Not so. The only invariant functions in D are member functions which
cannot change the state referenced by 'this'. They can certainly change
other state. Pure functions, on the other hand, may not manipulate
global state.
access without using properties or member functions, then I'd agree
with it. Of course, that qualification eliminates most of the
I think you are confusing invariance with purity. They are distinct
concepts with distinct rules and uses.
manipulate non-const data that isn't effected by transitive const?
It seems to me that simple cases could work, but it quickly breaks
down when trying to generalize. For example, I could write a log
utility that writes messages to standard out. To write to any
output, I'd need to store where to write log output to. Maybe I
could circumvent the const system and create a global object that
looks up where to write stuff. That'd let me pass around my logger
as an invariant object but then it'd be making an extra function call
every time something gets logged. That's a horrible design.
Advanced compiler tricks may eliminate the overhead, but it doesn't
mean it'd save headache for the programmer.
It still sounds like you're mixing up purity with invariance.
Pure functions requires that any shared data is invariant.
Yes, but invariant data does not require purity.
I translate that as "I didn't implement it that way".
It shouldn't be translated that way, because invariance and purity are
fairly common comp sci constructs, and I believe that D uses them in
conformance with that (although the term 'invariance' isn't used).
Also, we need
to distinguish between raw access to invariant data and use of
No, once again, I think you are confusing invariance with purity. An
invariant function means that it cannot modify anything through its
'this'. It can modify anything else.
I hope this post will convince you otherwise. If not, I can try
again <g>.
And I can try again too :)
First we need to agree on what purity and invariance are.
Walter Bright wrote:
Jason House wrote:
Walter Bright Wrote:
5. Invariant data
does not have to be synchronized to be multithread accessible. 6.
Invariant data improves the ability of automated tools to make
inferences about what is happening. Optimization is an example of
such.
they can manipulate global state.
Not so. The only invariant functions in D are member functions which
cannot change the state referenced by 'this'. They can certainly change
other state. Pure functions, on the other hand, may not manipulate
global state.
Maybe an example will help:
int a;
int b;
struct bar{
void write(int x) invariant
out{ assert(a==b); }
body{
a = x;
b = x;
}
}
The state of bar is never modified, but bar should not be used without
synchronization. The function's contract can be violated due to a race
requires qualification.
Jason House <jason.james.house gmail.com> wrote:
Maybe an example will help:
int a;
int b;
struct bar{
void write(int x) invariant
out{ assert(a==b); }
body{
a = x;
b = x;
}
}
The state of bar is never modified, but bar should not be used without
synchronization. The function's contract can be violated due to a race
condition. This may be an artificial example, but I hope it shows that
requires qualification.
You are expecting invariant member functions to not do things they can
and should do. Perhaps this would be better shown with one of the
proposed syntaxes for const/invariant member functions:
struct bar
{
invariant(this)
{
void write(int x) {...}
}
}
This is essentially what your example above does, and is expected to do.
If it were to behave the way you seem to expect it to, it would look
like this:
struct bar
{
void write(int x) pure // int does not need to be marked invariant,
// as it is passed by value.
{
}
}
This write method would of course be unable to do anything, as it
returns void, and cannot change its parameters.
The fact that invariant member functions require synchronization needs
no debate, we all know that, and most of us expect it to be like that.
The reason is that one might (for any good or bad reason) have an
invariant 'bar' somewhere, and need to call its 'write' method. Seeing
as this does not change the contents of 'bar', it should be a const or
invariant function. If you want it to behave differently for const and
invariant, there needs to be a separate function for the invariant
case.
The invariant object may have been created at run-time, and one might
want to write it to file, and include information about its being
const, mutable or invariant. This would be impossible if any and all
member functions of an invariant object be required to be pure.
Even if the const system was added to D only for functional
programming, we might need to interface to those invariant objects
in some way, and this is where invariant/const member functions
come in.
So, to sum it up:
Invarant/const member functions exist so that one might do things
with invariant/const objects, without using static functions. In
nearly all cases, a const member function is what you want, but
there might be some obscure reason to have an invariant member
function, and I don't think D should deny you that.
--
Simen
Simen Kjaeraas Wrote:
You are expecting invariant member functions to not do things they can
and should do.
can be accessed without synchronization. I was providing a simple counter
example.
On Thu, 24 Jul 2008 17:14:01 +0400, Jason House
<jason.james.house gmail.com> wrote:
Simen Kjaeraas Wrote:
You are expecting invariant member functions to not do things they can
and should do.
objects can be accessed without synchronization. I was providing a
simple counter example.
Yes, presicely:
invariant objects can be accessed without synchronization.
By contrast, your example wasn't accessing invariant objects but rather
executed invariant function. Don't compare soft with green. The data that
was accessed wasn't invariant, it was mutable. However, if global x and y
were invariant, that function would be thread-safe and woudn't require
synchronization.
Jason House <jason.james.house gmail.com> wrote:
Simen Kjaeraas Wrote:
You are expecting invariant member functions to not do things they can
and should do.
objects can be accessed without synchronization. I was providing a
simple counter example.
Yes, but you still seem not to understand what an invariant function is,
and why it should exist. An invariant object (read: invariant data)
/can/ be accessed without syncing. An invariant method cannot. Invariant
functions are not and should not be pure functions. The two are
different kinds of beasts. One is functional programming, the other is
not.
--
Simen
"Jason House" wrote
Simen Kjaeraas Wrote:
You are expecting invariant member functions to not do things they can
and should do.
objects can be accessed without synchronization. I was providing a simple
counter example.
Your counter-example fails to show that. You can access invariant objects
without synchronization, you cannot necessarily call invariant functions
without synchronization. In your example, you are accessing a and b, which
are not invariant, which means you will have to synchronize on something.
If there was data you were accessing in the struct itself, then you would
not need to synchronize to access that data. If you are accessing both
struct data and global data, you only need to synchronize on the global data
access. And you will need to synchronize on something outside the struct,
as other classes might be able to access global data.
Let me show you exactly how the compiler views your code:
int a;
int b;
struct bar{
}
void bar.write(invariant bar *this, int x)
out{ assert(a==b); }
body{
a = x;
b = x;
}
-Steve
Jason House wrote:
Simen Kjaeraas Wrote:
You are expecting invariant member functions to not do things they
can and should do.
objects can be accessed without synchronization. I was providing a
simple counter example.
The counter example was changing global state, not the invariant object.
invariant object's state.
Walter Bright Wrote:
Jason House wrote:
Simen Kjaeraas Wrote:
You are expecting invariant member functions to not do things they
can and should do.
objects can be accessed without synchronization. I was providing a
simple counter example.
The counter example was changing global state, not the invariant object.
invariant object's state.
5. Invariant data does not have to be synchronized to be multithread accessible.
Invariant data:
This would be various forms of invariant(T) with different T’s. It’s
possible that T is just fundamental types such as int and float, but I think
that’s unlikely. Given other goals such as using reference types as value
types, this has to include classes and structs. I’d also assume from this that
common uses of the various types would have to be included. This would mean
classic OOP styles such as data encapsulation.
Does not have to be synchronized:
I interpret this as “never requires synchronization” while others have
interpreted it as “might not need synchronization”. I can’t believe the latter
because of how much Walter has said in the past about the inherent dangers of
multi-threading and an inability to trust programmers to conform to best
practices.
Multithread accessible:
If this doesn't mean "safely accessible by multiple simultaneous threads
without incorrect or undesired outcomes", then there's no point is claiming
anything about multi-threading.
What is meant by "accessible"? For strings, this clearly means reading the
characters within the string, but when expanded to all types of invariant data,
the meaning is less clear to me. As discussed above, invariant data needs to
cover the case of data encapsulation. Proper encapsulation means that _no_
data members are exposed for direct access and that all access must be through
member functions. If object are to be multithread accessible, then the access
functions must be included.
includes the statement that “All compilable calls to member functions of
invariant objects can be done without synchronization”. It’s become pretty
clear that most people disagree with that conclusion.
access without using properties or member functions, then I'd agree with it.”
I didn’t think that was such an outlandish statement or possible requirement
that Walter left out. I said it before, and I’ll say it again: “Of course,
It’s amazing how such basic stuff can completely spiral out of control with
people claiming that I don’t know what I’m talking about and assuming all kinds
of inaccurate stuff. It’s not like I wasn’t aware that extending Walter’s
statement to include “invariant (member) functions” was possibly contentious.
would be sufficient to end the problems with this bit of the conversation and
move on to more productive conversation.
I don’t have the time to write long and verbose posts like this one to explain
the tiniest bits of stuff that I’m talking about. Beyond being annoying, huge
posts about the littlest details will prevent anyone from reading the post or
simply losing sight of the forest through the trees. I’m done talking about
this topic!
Jason House Wrote:
Walter Bright Wrote:
Jason House wrote:
Simen Kjaeraas Wrote:
You are expecting invariant member functions to not do things they
can and should do.
objects can be accessed without synchronization. I was providing a
simple counter example.
The counter example was changing global state, not the invariant object.
invariant object's state.
5. Invariant data does not have to be synchronized to be multithread
accessible.
Invariant data:
This would be various forms of invariant(T) with different T’s. It’s
possible that T is just fundamental types such as int and float, but I think
that’s unlikely. Given other goals such as using reference types as value
types, this has to include classes and structs. I’d also assume from this that
common uses of the various types would have to be included. This would mean
classic OOP styles such as data encapsulation.
Does not have to be synchronized:
I interpret this as “never requires synchronization” while others have
interpreted it as “might not need synchronization”. I can’t believe the latter
because of how much Walter has said in the past about the inherent dangers of
multi-threading and an inability to trust programmers to conform to best
practices.
Multithread accessible:
If this doesn't mean "safely accessible by multiple simultaneous threads
without incorrect or undesired outcomes", then there's no point is claiming
anything about multi-threading.
What is meant by "accessible"? For strings, this clearly means reading the
characters within the string, but when expanded to all types of invariant data,
the meaning is less clear to me. As discussed above, invariant data needs to
cover the case of data encapsulation. Proper encapsulation means that _no_
data members are exposed for direct access and that all access must be through
member functions. If object are to be multithread accessible, then the access
functions must be included.
implicitly includes the statement that “All compilable calls to member
functions of invariant objects can be done without synchronization”. It’s
become pretty clear that most people disagree with that conclusion.
access without using properties or member functions, then I'd agree with it.”
I didn’t think that was such an outlandish statement or possible requirement
that Walter left out. I said it before, and I’ll say it again: “Of course,
It’s amazing how such basic stuff can completely spiral out of control with
people claiming that I don’t know what I’m talking about and assuming all kinds
of inaccurate stuff. It’s not like I wasn’t aware that extending Walter’s
statement to include “invariant (member) functions” was possibly contentious.
would be sufficient to end the problems with this bit of the conversation and
move on to more productive conversation.
I don’t have the time to write long and verbose posts like this one to explain
the tiniest bits of stuff that I’m talking about. Beyond being annoying, huge
posts about the littlest details will prevent anyone from reading the post or
simply losing sight of the forest through the trees. I’m done talking about
this topic!
dood.
so glad you're done. here's a hint. instead of easing us all in excruciating
detail into your multiple misunderstandings and term fudging, why not shut the
piehole and open the ears a lil more.
superdan Wrote:
dood.
so glad you're done. here's a hint. instead of easing us all in excruciating
detail into your multiple misunderstandings and term fudging, why not shut the
piehole and open the ears a lil more.
Personally, I find many of your posts insensitive and offensive. I'd like to
believe that I've remained polite to people, even when I disagree with them.
Maybe I failed at it, but I tried to read what people were saying and
understand where they were coming from. I was probably taking things too
personally because I found myself getting upset over the responses that people
were making. If that came out in my last post, I apologize for that.
Jason House Wrote:
superdan Wrote:
dood.
so glad you're done. here's a hint. instead of easing us all in excruciating
detail into your multiple misunderstandings and term fudging, why not shut the
piehole and open the ears a lil more.
Personally, I find many of your posts insensitive and offensive. I'd like to
believe that I've remained polite to people, even when I disagree with them.
don't mind me. the sky is blue, yadda yadda yadda, and i'm a motherfucker. what
else is new.
Maybe I failed at it, but I tried to read what people were saying and
understand where they were coming from. I was probably taking things too
personally because I found myself getting upset over the responses that people
were making. If that came out in my last post, I apologize for that.
don't be all beta and sh... stuff. guess the discussion got to a violent
agreement. what everybody i guess agrees on is that when data truly never
changes you can always share it without care. just data. not objects with
interfaces and shit. that read-only sharing is cool is as old news as my being
an asshole. the cool thing is that d's invariant guarantees that statically.
Jason House wrote:
they can manipulate global state.
Not so. The only invariant functions in D are member functions which
cannot change the state referenced by 'this'. They can certainly change
other state. Pure functions, on the other hand, may not manipulate
global state.
Maybe an example will help:
int a;
int b;
struct bar{
void write(int x) invariant
out{ assert(a==b); }
body{
a = x;
b = x;
}
}
The state of bar is never modified, but bar should not be used without
synchronization. The function's contract can be violated due to a race
requires qualification.
You're imputing meaning to an "invariant function" that isn't there. An
invariant function is a function that does not change the state of the
object it is a member of. It can change other state.
Walter Bright wrote:
You're imputing meaning to an "invariant function" that isn't there. An
invariant function is a function that does not change the state of the
object it is a member of. It can change other state.
At the risk of exhuming and beating a dead horse, this was why I liked
the proposal for using invariant(this) and const(this) for member
function definitions. More verbose, but also IMHO quite a bit clearer.
Walter Bright wrote:
First we need to agree on what purity and invariance are.
Probably invariant functions too since I find myself using that term a lot.
Invariant data: Data/bits that will never change. This can include data
stored in ROM and other readonly memory.
Pure functions: Function calls without side effects such that they can be
safely run in a multithreaded environment without synchronization. Many
talk about input arguments to pure functions as being invarinat (thread
local storage or unique references and scoped access could be used to lift
that restriction, but I hope that's a different discussion)
Invariant functions:
1. (Current D definition) functions using invariant keyword
e.g. int bar(int x) invariant{}
2. (As I've been meaning it) Member functions of invariant data
e.g. invariant T obj; obj.memberFunction();
On 2008-07-24 03:33:41 +0200, Jason House <jason.james.house gmail.com> said:
Walter Bright wrote:
First we need to agree on what purity and invariance are.
Probably invariant functions too since I find myself using that term a lot.
yes but it has become clear that the way you use the term, and how
everybody else does is different, so it might be good to change your
definition, so that other understand you better.
Invariant data: Data/bits that will never change. This can include data
stored in ROM and other readonly memory.
yes
Pure functions: Function calls without side effects such that they can be
safely run in a multithreaded environment without synchronization. Many
talk about input arguments to pure functions as being invarinat (thread
local storage or unique references and scoped access could be used to lift
that restriction, but I hope that's a different discussion)
different discussion
Invariant functions:
1. (Current D definition) functions using invariant keyword
e.g. int bar(int x) invariant{}
you agree that it makes sense to have functions that have some
arguments that are invariant?
Which syntax would you use to describe member functions whose this
argument is invariant?
2. (As I've been meaning it) Member functions of invariant data
e.g. invariant T obj; obj.memberFunction();
member function of invariant data need to have the this argument that
is either const or invariant.
There are two kinds of them those that can have all sorts of side
effects (but obviously not modify the object), and those that have no
side effects (which we, as most other people call pure), the result of
these functions shares all the nice properties of invariant data (i.e.
you can basically treat a.x the same if x is a member variable or a
pure method with no other arguments returning a value of the same type).
Fawzi
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global state
from within a function that is not supposed to do that. Invariant does
not imply pure.
That's actually a very key part to my whole point. There is very little
difference between pure and invariant functions. Why do we need a concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this' pointer is
marked as invariant.
Remember that:
class C
{
invariant void f() {}
}
Is somewhat equivalent to:
class C
{
}
void f(invariant C this) {}
Note that f is not invariant, but 'this' is.
However, for pure functions, pure describes the function, not the data.
Invariant describes the data. In fact, a pure member function would have to
be marked as:
pure invariant void f();
Or else the compiler would complain that you were trying to call a pure
function with non-invariant data.
As for how useful would an invariant (but not pure) function be? Consider
something like:
class C
{
int x;
invariant void printTo(stream s) { s.print(x); }
}
Without invariant member functions, you could not have a function like
printTo for an invariant class instance. A pure function would not be able
to print, because the stream argument would also have to be invariant, and
most likely, stream.print would not be a pure function.
Note that I'm too lazy right now to look up actual stream objects in Phobos
or Tango and their syntax, so just imagine that what I wrote compiles :)
-Steve
Steven Schveighoffer <schveiguy yahoo.com> wrote:
In fact, a pure member function would have tobe marked as:
pure invariant void f();
While I agree a pure member function would also need to be invariant,
it seems superfluous to have to write that in the function signature.
It /has/ to be, so why should I need to specify it?
As for how useful would an invariant (but not pure) function be?
Consider
something like:
class C
{
int x;
invariant void printTo(stream s) { s.print(x); }
}
Could this not just as easily have been done with a const
function, as invariant is implicitly castable to const?
-- Simen
On Wed, 23 Jul 2008 22:01:34 +0400, Simen Kjaeraas
<simen.kjaras gmail.com> wrote:
Steven Schveighoffer <schveiguy yahoo.com> wrote:
In fact, a pure member function would have tobe marked as:
pure invariant void f();
While I agree a pure member function would also need to be invariant,
it seems superfluous to have to write that in the function signature.
It /has/ to be, so why should I need to specify it?
As for how useful would an invariant (but not pure) function be?
Consider
something like:
class C
{
int x;
invariant void printTo(stream s) { s.print(x); }
}
Could this not just as easily have been done with a const
function, as invariant is implicitly castable to const?
-- Simen
There might be a benefit, as it enforces stronger guaranties.
Suppose that our class is large storage container and stream.print is a
time-consuming process that may take signaficant amount of time. If an
object is invariant then then there is a guarantee than its data won't be
changed in another thread during function execution (at the very least).
And given that, there is no need to synchronize data, otherwise it should
be rewritten as synchronized:
class C
{
Data data;
synchronized const void printTo(stream s) { s.print(data); }
invariant void printTo(stream s) { s.print(data); } //
invariance
}
On Wed, 23 Jul 2008 04:35:16 +0400, Walter Bright
<newshound1 digitalmars.com> wrote:
5. Invariant data does not have to be synchronized to be multithread
accessible.
"Simen Kjaeraas" wrote
Steven Schveighoffer wrote:
In fact, a pure member function would have tobe marked as:
pure invariant void f();
While I agree a pure member function would also need to be invariant,
it seems superfluous to have to write that in the function signature.
It /has/ to be, so why should I need to specify it?
I was showing that invariant and pure affect separate pieces of the
function, and so I showed the syntax this way to make a point. Most likely,
a pure member function implies that 'this' is invariant, as there is no
reason to have it otherwise.
As for how useful would an invariant (but not pure) function be?
Consider
something like:
class C
{
int x;
invariant void printTo(stream s) { s.print(x); }
}
Could this not just as easily have been done with a const
function, as invariant is implicitly castable to const?
Yes, and as Koroskin says, there is a benefit to having invariant vs. const
in that you do not need to synchronize. How important this will be in
practice, I don't know. But for those crazies trying to squeeze every last
ounce of performance from an app, it will be a possible optimization point
:)
I'll probably never use invariant in anything but pure functions (if I ever
use those). However, the point is, in order to be consistent with other
functions, which can have parameters declared as invariant, you must be able
to declare the 'this' pointer as invariant. To not do this leaves a hole
the same size as if you couldn't have tail-const class references. Oh
wait...
-Steve
Steven Schveighoffer Wrote:
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global state
from within a function that is not supposed to do that. Invariant does
not imply pure.
That's actually a very key part to my whole point. There is very little
difference between pure and invariant functions. Why do we need a concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this' pointer is
marked as invariant.
It's not that I misunderstand but that I question. Given the goals of the
const system, invariant functions, as defined, don't make a lot of sense. They
make some sense, but not a lot of sense :)
Without invariant member functions, you could not have a function like
printTo for an invariant class instance. A pure function would not be able
to print, because the stream argument would also have to be invariant, and
most likely, stream.print would not be a pure function.
It's true that what I'm talking about implies that such a thing could not
occur. In C++ const (and the current D const), that type of construct is
possible. It really comes down to if const exists for multithreading or if it
exists for faking pass by value.
I know Walter has tried to eliminate loopholes with the pass by value semantics
with the transitive const. For example, transitive const protects tree
manipulations such as parent.child.property = 1; from violating const, but it
doesn't stop global_root.child.property = 1;.
Such loopholes are not good when compilers are trying to optimize. I also
can't really get past how the const system allows people to bypass "mutable
members" through the use of global variables.
"Jason House" wrote
Steven Schveighoffer Wrote:
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global
state
from within a function that is not supposed to do that. Invariant does
not imply pure.
That's actually a very key part to my whole point. There is very
little
difference between pure and invariant functions. Why do we need a
concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this' pointer
is
marked as invariant.
It's not that I misunderstand but that I question. Given the goals of the
const system, invariant functions, as defined, don't make a lot of sense.
They make some sense, but not a lot of sense :)
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
While I agree that having invariant functions is probably not going to be
extremely useful, to not allow invariant methods is to make an inconsistency
in the type system. If I can declare a variable is invariant, then I should
be able to pass that variable to a function as invariant. If there is a
special case that you can't pass it to it's own member function, then it is
not only inconsistent, but probably makes the compiler more complex for no
good reason. If you don't like invariant functions, don't use them. I
probably won't.
-Steve
Steven Schveighoffer Wrote:
"Jason House" wrote
Steven Schveighoffer Wrote:
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global
state
from within a function that is not supposed to do that. Invariant does
not imply pure.
That's actually a very key part to my whole point. There is very
little
difference between pure and invariant functions. Why do we need a
concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this' pointer
is
marked as invariant.
It's not that I misunderstand but that I question. Given the goals of the
const system, invariant functions, as defined, don't make a lot of sense.
They make some sense, but not a lot of sense :)
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
Will the fields of somestruct be accessed directly? If so, there's no change
in functionality. If not, will the invariant functions of somestruct be used
to modify global state? If not, there's not change in functionality... I
don't think what I'm suggesting changes a lot of code.
I agree that having invariant functions is probably not going to be
extremely useful
Are we including invariant functions as an assumed feature that people need?
Walter was recently considering eliminating one use of synchronized statements
because there was no real use for it.
to not allow invariant methods is to make an inconsistency
in the type system. If I can declare a variable is invariant, then I should
be able to pass that variable to a function as invariant.
I'm missing something here... Why couldn't you pass an invariant object as an
invariant parameter into a function?
If there is a
special case that you can't pass it to it's own member function, then it is
not only inconsistent, but probably makes the compiler more complex for no
good reason.
I've lost your line of reasoning, can you explain more?
If you don't like invariant functions, don't use them. I
probably won't.
That all depends on how the libraries you use are written. Hopefully they
won't forget to add the pure keyword where it matters ;)
"Jason House" wrote
Steven Schveighoffer Wrote:
"Jason House" wrote
Steven Schveighoffer Wrote:
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for
functions
provides. That is the ability to diagnose attempts to alter global
state
from within a function that is not supposed to do that. Invariant
does
not imply pure.
That's actually a very key part to my whole point. There is very
little
difference between pure and invariant functions. Why do we need a
concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this'
pointer
is
marked as invariant.
It's not that I misunderstand but that I question. Given the goals of
the
const system, invariant functions, as defined, don't make a lot of
sense.
They make some sense, but not a lot of sense :)
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
Will the fields of somestruct be accessed directly? If so, there's no
change in functionality. If not, will the invariant functions of
somestruct be used to modify global state? If not, there's not change in
functionality... I don't think what I'm suggesting changes a lot of code.
You are suggesting that invariant functions simply be illegal, and pure
functions not. I am saying that you are leaving a hole in the type system
by doing that. It is analogous to saying, if a function has any invariant
parameters, those functions should be marked pure, and all parameters should
be marked invariant. I can see many places where some parameters could be
invariant and some not. Pure functions (as Walter envisions them) require
ALL invariant parameters.
I agree that having invariant functions is probably not going to be
extremely useful
Are we including invariant functions as an assumed feature that people
need? Walter was recently considering eliminating one use of synchronized
statements because there was no real use for it.
I'm saying if I can make any parameter invariant, I should be able to make
the 'this' parameter invariant. Regardless of whether the function is pure
or not. This is all an invariant function is. To not do this makes the
type system inconsistent in that you can apply invariant to all types except
the parameter named 'this' on a member function. Why separate that out,
especially when it's already implemented?
to not allow invariant methods is to make an inconsistency
in the type system. If I can declare a variable is invariant, then I
should
be able to pass that variable to a function as invariant.
I'm missing something here... Why couldn't you pass an invariant object
as an invariant parameter into a function?
This is what you are trying to prevent (passing of an invariant object as an
invariant parameter). You are singling out the parameter named 'this' to
prevent it on.
If there is a
special case that you can't pass it to it's own member function, then it
is
not only inconsistent, but probably makes the compiler more complex for
no
good reason.
I've lost your line of reasoning, can you explain more?
Maybe my above comments have done so, but here is a 'proof' of sorts.
Let's say invariant functions are not allowed, but you can declare invariant
parameters.
I can declare the equivalent to an invariant function like so:
class C
{
static f(invariant(C) c) {...}
}
...
auto c = cast(invariant(C)) new C;
// instead of c.f()
C.f(c);
So with your removal of invariant functions, I can still have semantically
equivalent invariant functions, but it's just more of a pain in the ass to
use them. Why do you need to add this difficulty?
-Steve
Steven Schveighoffer Wrote:
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
Will the fields of somestruct be accessed directly? If so, there's no
change in functionality. If not, will the invariant functions of
somestruct be used to modify global state? If not, there's not change in
functionality... I don't think what I'm suggesting changes a lot of code.
You are suggesting that invariant functions simply be illegal, and pure
functions not. I am saying that you are leaving a hole in the type system
by doing that. It is analogous to saying, if a function has any invariant
parameters, those functions should be marked pure, and all parameters should
be marked invariant. I can see many places where some parameters could be
invariant and some not. Pure functions (as Walter envisions them) require
ALL invariant parameters.
No, I'm not. I'm only suggesting that functions that are invariant and const
functions are redefined to be like pure functions... Merging concepts
together. There's no reason for an invariant argument to a function require
the function itself to be invariant/pure.
Jason House wrote:
No, I'm not. I'm only suggesting that functions that are invariant
and const functions are redefined to be like pure functions...
Merging concepts together. There's no reason for an invariant
argument to a function require the function itself to be
invariant/pure.
If invariance and purity were merged, then the whole system of invariant
strings, which works great, would have to be scrapped. I don't see a
gain that approaches that downside.
Walter Bright Wrote:
Jason House wrote:
No, I'm not. I'm only suggesting that functions that are invariant
and const functions are redefined to be like pure functions...
Merging concepts together. There's no reason for an invariant
argument to a function require the function itself to be
invariant/pure.
If invariance and purity were merged, then the whole system of invariant
strings, which works great, would have to be scrapped. I don't see a
gain that approaches that downside.
Why is that? The only thing I can think of is the dup function.
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
No, I'm not. I'm only suggesting that functions that are invariant
and const functions are redefined to be like pure functions...
Merging concepts together. There's no reason for an invariant
argument to a function require the function itself to be
invariant/pure.
If invariance and purity were merged, then the whole system of invariant
strings, which works great, would have to be scrapped. I don't see a
gain that approaches that downside.
Why is that?
Because any function that takes a string argument (strings are
invariant) would then have to be a pure function. You couldn't even write:
writefln("hello world");
because I/O functions cannot be pure.
Walter Bright wrote:
Jason House wrote:
Walter Bright Wrote:
Jason House wrote:
No, I'm not. I'm only suggesting that functions that are invariant
and const functions are redefined to be like pure functions...
Merging concepts together. There's no reason for an invariant
argument to a function require the function itself to be
invariant/pure.
If invariance and purity were merged, then the whole system of invariant
strings, which works great, would have to be scrapped. I don't see a
gain that approaches that downside.
Why is that?
Because any function that takes a string argument (strings are
invariant) would then have to be a pure function. You couldn't even write:
writefln("hello world");
because I/O functions cannot be pure.
I must have really messed up something that I said somewhere along the line
because you're the second person to think that! writefln is neither
invariant nor pure and would not be modified by this discussion.
Jason House wrote:
I must have really messed up something that I said somewhere along the line
because you're the second person to think that! writefln is neither
invariant nor pure and would not be modified by this discussion.
My understanding was that you were suggesting that any function with any
invariant arguments should also be pure. My apologies if that was a
misunderstanding.
"Jason House" wrote
Steven Schveighoffer Wrote:
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
Will the fields of somestruct be accessed directly? If so, there's no
change in functionality. If not, will the invariant functions of
somestruct be used to modify global state? If not, there's not change
in
functionality... I don't think what I'm suggesting changes a lot of
code.
You are suggesting that invariant functions simply be illegal, and pure
functions not. I am saying that you are leaving a hole in the type
system
by doing that. It is analogous to saying, if a function has any
invariant
parameters, those functions should be marked pure, and all parameters
should
be marked invariant. I can see many places where some parameters could
be
invariant and some not. Pure functions (as Walter envisions them)
require
ALL invariant parameters.
No, I'm not. I'm only suggesting that functions that are invariant and
const functions are redefined to be like pure functions... Merging
concepts together. There's no reason for an invariant argument to a
function require the function itself to be invariant/pure.
An invariant function is defined as one that has an invariant argument (the
'this' pointer). There are no other special requirements for invariant
functions. So I think you still don't understand the concept.
invariant functions === invariant data.
-Steve
Steven Schveighoffer wrote:
"Jason House" wrote
Steven Schveighoffer Wrote:
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global
state
from within a function that is not supposed to do that. Invariant does
not imply pure.
That's actually a very key part to my whole point. There is very
little
difference between pure and invariant functions. Why do we need a
concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this' pointer
is
marked as invariant.
It's not that I misunderstand but that I question. Given the goals of the
const system, invariant functions, as defined, don't make a lot of sense.
They make some sense, but not a lot of sense :)
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
I think it is quite different. The member function is defined inside the
class.
Think what it means for the 'this' parameter to be invariant. Unlike
const, it's not conditional. An invariant instance can only call
invariant and const member functions; it can never call mutable member
functions. Likewise, a non-invariant instance can never call invariant
member functions.
Seems to me, that you've actually defined 2 classes. There could, for
example, be completely different vtables for invariant vs mutable instances.
interface ConstFoo
{
.. constmemberfunctions
}
class MutableFoo: ConstFoo
{
}
class InvariantFoo: ConstFoo
{
}
Any instance of Foo is either an instance of MutableFoo, or of InvariantFoo.
I'm not sure why you wouldn't just make two classes, and apply invariant
at the class definition level.
On 2008-07-24 05:01:37 -0400, Don <nospam nospam.com.au> said:
I think it is quite different. The member function is defined inside the class.
Think what it means for the 'this' parameter to be invariant. Unlike
const, it's not conditional. An invariant instance can only call
invariant and const member functions; it can never call mutable member
functions. Likewise, a non-invariant instance can never call invariant
member functions.
Seems to me, that you've actually defined 2 classes. There could, for
example, be completely different vtables for invariant vs mutable
instances.
interface ConstFoo
{
.. constmemberfunctions
}
class MutableFoo: ConstFoo
{
}
class InvariantFoo: ConstFoo
{
}
Any instance of Foo is either an instance of MutableFoo, or of InvariantFoo.
I'm not sure why you wouldn't just make two classes, and apply
invariant at the class definition level.
Indeed, and that's pretty much how it is done in Objective-C, and it
works very well there, except that in Objective-C you generally find
this pattern:
abstract class Foo {}
abstract class MutableFoo : Foo {}
class PrivateFooImpl : Foo {}
class PrivateMutableFooImpl : MutableFoo {}
where abstract classes here represent the base class of a class
cluster[1], providing mainly an interface to build upon.
The downside is that this scheme only works with classes. You can't
have invariant primitive types this way, and since a D string is a
primitive type, you still have a need for invariant in D. Basically I
like all this const/invariant stuff, but I feel the model in
Objective-C works better for classes.
[1]:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_9.html
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
"Don" wrote
Steven Schveighoffer wrote:
"Jason House" wrote
Steven Schveighoffer Wrote:
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global
state
from within a function that is not supposed to do that. Invariant
does
not imply pure.
That's actually a very key part to my whole point. There is very
little
difference between pure and invariant functions. Why do we need a
concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this' pointer
is
marked as invariant.
It's not that I misunderstand but that I question. Given the goals of
the const system, invariant functions, as defined, don't make a lot of
sense. They make some sense, but not a lot of sense :)
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
I think it is quite different. The member function is defined inside the
class.
Think what it means for the 'this' parameter to be invariant. Unlike
const, it's not conditional. An invariant instance can only call invariant
and const member functions; it can never call mutable member functions.
Likewise, a non-invariant instance can never call invariant member
functions.
Seems to me, that you've actually defined 2 classes. There could, for
example, be completely different vtables for invariant vs mutable
instances.
With invariant functions, what you are defining is a contract for that
member function. The contract states that the object passed to the function
as the 'this' pointer must be invariant. Let's not forget that member
functions are simply functions which require you to pass the object. The
only 'special' part of it is the way you write the function call.
There is no reason you need to define multiple classes. You are just
defining more functions that take a different argument type as the 'this'
pointer. I don't see why it's so confusing to define those functions in the
same class as the mutable functions.
Personally, I probably will only ever write const functions, because I don't
see myself using invariant classes very much. But it could be a source of
optimization. For example, if there is member data used in the function
that could be changing, even a const function must synchronize the data. If
the function is invariant, the coder does not have to synchronize, and saves
the cost of that.
-Steve
Steven Schveighoffer wrote:
"Don" wrote
Steven Schveighoffer wrote:
"Jason House" wrote
Steven Schveighoffer Wrote:
"Jason House" wrote
Walter Bright Wrote:
The missing ingredient here is what the 'pure' modifier for functions
provides. That is the ability to diagnose attempts to alter global
state
from within a function that is not supposed to do that. Invariant
does
not imply pure.
That's actually a very key part to my whole point. There is very
little
difference between pure and invariant functions. Why do we need a
concept
for both? Under the assumption that we're adding const to support
functional programming, I don't understand the motivation for this
difference.
You are misunderstanding what an 'invariant' member function is. The
function itself is not invariant. It's a function whose 'this' pointer
is
marked as invariant.
It's not that I misunderstand but that I question. Given the goals of
the const system, invariant functions, as defined, don't make a lot of
sense. They make some sense, but not a lot of sense :)
They don't make any less sense than declaring invariant variables. Or
declaring invariant parameters.
Can you see use in the following function signature:
void f(invariant(somestruct) *x) {...}
If so, an invariant member function is no different.
I think it is quite different. The member function is defined inside the
class.
Think what it means for the 'this' parameter to be invariant. Unlike
const, it's not conditional. An invariant instance can only call invariant
and const member functions; it can never call mutable member functions.
Likewise, a non-invariant instance can never call invariant member
functions.
Seems to me, that you've actually defined 2 classes. There could, for
example, be completely different vtables for invariant vs mutable
instances.
With invariant functions, what you are defining is a contract for that
member function. The contract states that the object passed to the function
as the 'this' pointer must be invariant. Let's not forget that member
functions are simply functions which require you to pass the object. The
only 'special' part of it is the way you write the function call.
There's another difference. The person writing a member function is
always the same person who wrote the class. They've made a conscious
design decision that this class can be used as an invariant class (Not
all classes can be used in this way, in fact most cannot).
There is no reason you need to define multiple classes. You are just
defining more functions that take a different argument type as the 'this'
pointer. I don't see why it's so confusing to define those functions in the
same class as the mutable functions.
My gut feel is that mixing mutable and invariant functions in the one
class would be an indication of poor design. Which is why I'd be very
interested in use cases.
"Don" wrote
Steven Schveighoffer wrote:
With invariant functions, what you are defining is a contract for that
member function. The contract states that the object passed to the
function as the 'this' pointer must be invariant. Let's not forget that
member functions are simply functions which require you to pass the
object. The only 'special' part of it is the way you write the function
call.
There's another difference. The person writing a member function is always
the same person who wrote the class. They've made a conscious design
decision that this class can be used as an invariant class (Not all
classes can be used in this way, in fact most cannot).
Any class that has const functions can be used as an invariant.
There is no reason you need to define multiple classes. You are just
defining more functions that take a different argument type as the 'this'
pointer. I don't see why it's so confusing to define those functions in
the same class as the mutable functions.
My gut feel is that mixing mutable and invariant functions in the one
class would be an indication of poor design. Which is why I'd be very
interested in use cases.
What about building an invariant lookup table dynamically? First you use
the mutable methods to build the table, then you mark it as invariant so you
no longer have to synchronize.
I can see someone using such a table in another part of the code in a
mutable state, so why repeat all the code for that lookup object?
You could put the common parts of code in unsynchronized const private
functions, and then the synchronization in the public const API.
-Steve
On 2008-07-24 10:21:20 -0400, "Steven Schveighoffer"
<schveiguy yahoo.com> said:
There is no reason you need to define multiple classes. You are just
defining more functions that take a different argument type as the 'this'
pointer. I don't see why it's so confusing to define those functions in the
same class as the mutable functions.
You probably never absolutely need two classes, but sometime it would
help to have a different implementation, and thus different members,
for a mutable and an invariant version of a class.
For instance, a mutable collection could have additional storage for
keeping track of the last inserted object, a more complex data
structure to list some late-bound parts, or perhaps an undo history.
All of this is usless to the invariant version, but if both are the
same class you can't escape the additional logic and storage space of
the mutable one. Thus, the need to make two classes.
--
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Don wrote:
I'm not sure why you wouldn't just make two classes, and apply invariant
at the class definition level.
As I understand it, the difference is that you can only call invariant
functions on an invariant object. So, if you have a reference to the
class, and the reference is marked invariant, then all of the
non-invariant functions can't be called.
Why would you have an invariant object, you say? Well, a basic example
is where you create an object, initialize it, then cast it to invariant.
(Presumably, you can guarantee, that it is invariant from the moment
of the cast until the program dies.)
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
Don wrote:
What if the community concensus remains that const is just too
complicated, without enough benefit?
A simpler const system (such as what C++ has) has little benefit, and
all the other const proposals were much more complex.
That doesn't mean I have to like what we ended up with :-)
I think part of the problem is that I simply don't agree with the mixed
functional / imperative approach that appears to be the overarching
direction of D. And while I do quite a bit of concurrent programming,
it's not in a way that will reap any benefit from this design. In fact, the
language features added to support it are more of an annoyance than
they are an aid. This may very well mean that D is simply not the
language for me in the long term. However, with C and C++ as the
only real alternatives for systems programming, there aren't many
other options available.
Sean
Sean Kelly:
I simply don't agree with the mixed functional / imperative approach
that appears to be the overarching direction of D.
[...]
This may very well mean that D is simply not the language for me
in the long term. However, with C and C++ as the only real
alternatives for systems programming, there aren't many other
options available.
I know this is a scary/huge question, but may ask you what kind of computer
language is your dream/ideal language?
(I think all good programmers/technicians have to keep looking for better
languages/tools for all their professional life).
Bye,
bearophile
== Quote from bearophile (bearophileHUGS lycos.com)'s article
Sean Kelly:
I simply don't agree with the mixed functional / imperative approach
that appears to be the overarching direction of D.
[...]
This may very well mean that D is simply not the language for me
in the long term. However, with C and C++ as the only real
alternatives for systems programming, there aren't many other
options available.
I know this is a scary/huge question, but may ask you what kind of computer
language is your
dream/ideal language?
(I think all good programmers/technicians have to keep looking for better
languages/tools for all their
professional life).
Depends on the problem being solved. Right now however, Erlang backed by
D is the best I've found for general purpose server / distributed programming.
That gives me a control language with a good parallel programming model as
well as systems / mutable state language for optimization points, shared data,
and systems programming bits. So perhaps roughly similar to D2 from a 1000'
viewpoint, but as always, the devil's in the details.
Sean
Sean Kelly wrote:
Depends on the problem being solved. Right now however, Erlang backed by
D is the best I've found for general purpose server / distributed programming.
That gives me a control language with a good parallel programming model as
well as systems / mutable state language for optimization points, shared data,
and systems programming bits. So perhaps roughly similar to D2 from a 1000'
viewpoint, but as always, the devil's in the details.
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Walter Bright wrote:
Sean Kelly wrote:
Depends on the problem being solved. Right now however, Erlang backed by
D is the best I've found for general purpose server / distributed
programming.
That gives me a control language with a good parallel programming
model as
well as systems / mutable state language for optimization points,
shared data,
and systems programming bits. So perhaps roughly similar to D2 from a
1000'
viewpoint, but as always, the devil's in the details.
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Sean Kelly on Erlang:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=72496
"""
I agree that it's important for mutability to be available if
necessary. But Erlang integrates reasonably well with C,
so I don't consider this an issue really. In fact, I prefer this
approach to the "all in one" approach that D 2.0 seems to
be aiming for, as I prefer that there be a semantic separation
between my functional and imperative code. I feel that this
is a good way of preventing "bleed through" of concepts
that would complicate and confuse code. It also neatly
avoids a motivator for producing monolithic code, and
the consequent risk that the mutable-state portion may
fail and corrupt the entire process.
But this is really a matter of preference. I'm sure many
people disagree, and others simply don't work on the
type of applications Erlang was designed to target. I
just happen to be in the niche that Erlang was specifically
intended for. I only wish I'd heard about it 15 years ago
instead of spending all that time mucking about with C++.
"""
--bb
Walter Bright wrote:
Sean Kelly wrote:
Depends on the problem being solved. Right now however, Erlang backed by
D is the best I've found for general purpose server / distributed
programming.
That gives me a control language with a good parallel programming
model as
well as systems / mutable state language for optimization points,
shared data,
and systems programming bits. So perhaps roughly similar to D2 from a
1000'
viewpoint, but as always, the devil's in the details.
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it tend
to be a mess.
Regarding the D mixed functional / imperative approach, another issue I
have with it is that it's exactly the reverse of the Erlang / C model.
While Erlang / C is functional for control structures and imperative for
optimization points, D looks like it will be imperative for control and
functional for optimization. Plus, I really like the concurrency model
in Erlang.
Sean
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it tend
to be a mess.
I agree that diverse paradigm support can lead to a mess. On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
I disagree that using multiple languages for one project is a good idea,
unless one language is hosted by the other (like emacs/elisp). Trying to
get two languages produced by different vendors to consistently work
together across platforms and differing upgrade schedules can be a
prescription for a lot of extra work. Is learning two different
languages really easier than learning two different paradigms in the
same language?
Regarding the D mixed functional / imperative approach, another issue I
have with it is that it's exactly the reverse of the Erlang / C model.
While Erlang / C is functional for control structures and imperative for
optimization points, D looks like it will be imperative for control and
functional for optimization. Plus, I really like the concurrency model
in Erlang.
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem is,
it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
And so on. Feature creep is the result of inexorable and unrelenting
pressure for them.
Walter Bright:
I agree that diverse paradigm support can lead to a mess. On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
Yet, it's becoming standard, in most places I look now people are starting to
use different languages for different purposes. It's all the "the right tool
for the right job" thing.
Especially in the dynamic language camp people mix Python with many other kinds
of languages.
In some situations such mixing isn't too much difficult, for example if your
languages are written in the lower level one and both run on the same VM.
Bye,
bearophile
Walter Bright wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it
tend to be a mess.
I agree that diverse paradigm support can lead to a mess. On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
I disagree that using multiple languages for one project is a good idea,
unless one language is hosted by the other (like emacs/elisp). Trying to
get two languages produced by different vendors to consistently work
together across platforms and differing upgrade schedules can be a
prescription for a lot of extra work. Is learning two different
languages really easier than learning two different paradigms in the
same language?
Regarding the D mixed functional / imperative approach, another issue
I have with it is that it's exactly the reverse of the Erlang / C
model. While Erlang / C is functional for control structures and
imperative for optimization points, D looks like it will be imperative
for control and functional for optimization. Plus, I really like the
concurrency model in Erlang.
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem is,
it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
And so on. Feature creep is the result of inexorable and unrelenting
pressure for them.
The word example is wrong in that, in your example, bill doesn't need
similar to eclipse: both sue and bill can use eclipse but since bill
works with c/c++ he can get a pre-packaged version with CDT which is
much smaller than the entire eclipse project, and sue can get her
eclipse pre-packaged with JDT since she works with Java. This is why
Eclipse is so popular and supported by many large companies like oracle,
IBM, etc.. The same goes to the popular browser Firefox and its
extensions. No need to bundle everything like Microsoft word does, it's
much better to have a system to allow users to integrate features they
require beyond the lean & mean core.
here's my educated guess: Sean uses erlang + D to get the same benefits.
he can have the feature sets of both languages with their own lean &
mean syntaxes that are geared toward their respective feature sets.
while if he had used one language with both feature sets, than the
syntax of that language would be much more complicated in order to
support all the features.
C++ as an example: its syntax is horrible due to the fact that it can do
so much. if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
or something like that. if I want to do procedural code I'll prefer C
syntax instead, but I definitely do not want to have a compromise of
both syntaxes in one language (we all know that a programing language is
an agreed upon compromise) that will not allow me to express my OOP code
in a concise OOP way and also will not allow me to express my procedural
code in a concise procedural way.
an everything-including-the-kitchen-sink language cannot provide concise
syntax for any of the paradigms it supports.
Yigal Chripun Wrote:
Walter Bright wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it
tend to be a mess.
I agree that diverse paradigm support can lead to a mess. On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
I disagree that using multiple languages for one project is a good idea,
unless one language is hosted by the other (like emacs/elisp). Trying to
get two languages produced by different vendors to consistently work
together across platforms and differing upgrade schedules can be a
prescription for a lot of extra work. Is learning two different
languages really easier than learning two different paradigms in the
same language?
Regarding the D mixed functional / imperative approach, another issue
I have with it is that it's exactly the reverse of the Erlang / C
model. While Erlang / C is functional for control structures and
imperative for optimization points, D looks like it will be imperative
for control and functional for optimization. Plus, I really like the
concurrency model in Erlang.
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem is,
it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
And so on. Feature creep is the result of inexorable and unrelenting
pressure for them.
The word example is wrong in that, in your example, bill doesn't need
similar to eclipse: both sue and bill can use eclipse but since bill
works with c/c++ he can get a pre-packaged version with CDT which is
much smaller than the entire eclipse project, and sue can get her
eclipse pre-packaged with JDT since she works with Java. This is why
Eclipse is so popular and supported by many large companies like oracle,
IBM, etc.. The same goes to the popular browser Firefox and its
extensions. No need to bundle everything like Microsoft word does, it's
much better to have a system to allow users to integrate features they
require beyond the lean & mean core.
good point, i was thinking of firefox and thunderbird too. then i realized the
reality is, both ff and tb ended up integrating the most popular extensions in
their core. why? because there is pressure, hence walter's point.
here's my educated guess: Sean uses erlang + D to get the same benefits.
he can have the feature sets of both languages with their own lean &
mean syntaxes that are geared toward their respective feature sets.
while if he had used one language with both feature sets, than the
syntax of that language would be much more complicated in order to
support all the features.
C++ as an example: its syntax is horrible due to the fact that it can do
so much.
no. its syntax is horrible because it has a shitty design. bjarne has made the
tactical mistake of ignoring theoretical syntax matters and also compiler
construction costs, in favor of what greedily looked most usable at the moment
for the feature being designed. he is known for shooing away all those who
opposed additions on grounds of syntactic and implementation difficulties. he
pushed the fucking angle brackets over the dead body of pennello and the
fucking export and two-phase lookup shit over everybody's dead body. what does
that have to do with c++ being multiparadigm? nothing? correct!
congratulations, you won a plasma tv set.
bjarne was strong on strategy and extremely weak in tactics. that can be
clearly seen today as frozen into the language. walter is ok in both. his only
problem is that he looks too much at c++, both up and down. when in doubt he
does what c++ does, for example why the hell is this a pointer? makes no sense.
well it is in c++. and so on. thank god const is not the same. in fact i could
see a more definite break with c++'s shitty parts once walter got those new
aides bartosz and andrei and i forgot the rest.
if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
or something like that. if I want to do procedural code I'll prefer C
syntax instead, but I definitely do not want to have a compromise of
both syntaxes in one language (we all know that a programing language is
an agreed upon compromise) that will not allow me to express my OOP code
in a concise OOP way and also will not allow me to express my procedural
code in a concise procedural way.
an everything-including-the-kitchen-sink language cannot provide concise
syntax for any of the paradigms it supports.
good language design is not about the kitchen sink as much as harmoniously
accommodating multiple styles. nobody has shown that that can't be done.
superdan wrote:
good point, i was thinking of firefox and thunderbird too. then i
realized the reality is, both ff and tb ended up integrating the most
popular extensions in their core. why? because there is pressure,
hence walter's point.
The devil's in the details - Firefox integrated extensions as features
of the browser itself only when the extension "fixed" problems in the
core itself and/or the feature is general enough that it should have
been designed as part of the core. the Tab implementation for example
benefited from integrating functionally from extensions and the session
feature was added since it is general and useful for all FF users.
let's look again to eclipse to see this difference:
eclipse 3.4 added a new update manager with lots of new features. this
makes sense as part of the SDK of eclipse itself since all users of
eclipse will benefit from this. on the other hand, JDT will not ever be
needed by a c++ programmer (unless he decides to move to Java). same
goes for CDT, PDT, etc..
some features should be added to the core, and some will not ever be
general to be part of the core.
another example, the delicious extension will always be only useful for
delicious subscribers and should never be part of Firefox itself.
here's my educated guess: Sean uses erlang + D to get the same
benefits. he can have the feature sets of both languages with their
own lean & mean syntaxes that are geared toward their respective
feature sets. while if he had used one language with both feature
sets, than the syntax of that language would be much more
complicated in order to support all the features. C++ as an
example: its syntax is horrible due to the fact that it can do so
much.
no. its syntax is horrible because it has a shitty design. bjarne has
made the tactical mistake of ignoring theoretical syntax matters and
also compiler construction costs, in favor of what greedily looked
most usable at the moment for the feature being designed. he is known
for shooing away all those who opposed additions on grounds of
syntactic and implementation difficulties. he pushed the fucking
angle brackets over the dead body of pennello and the fucking export
and two-phase lookup shit over everybody's dead body. what does that
have to do with c++ being multiparadigm? nothing? correct!
congratulations, you won a plasma tv set.
Even with that in mind, that's not enough.
think of this this way:
what's the best way to design GUI?
probably to draw it in a visual designer and not using some API.
what's the best way to write a database query? probably SQL is the most
concise way to express that. etc, etc..
there's a whole paradigm of Language Oriented Programming that you
should look at. (MPS by jetbrains is a good example of that, I think)
the point is - when you restrict yourself to a specific domain you can
design the best way to express in that domain that may conflict with
other domains in a general language ( you probably wouldn't want to draw
all your "code" with a visual designer, while that's the best way to
express gui..)
bjarne was strong on strategy and extremely weak in tactics. that can
be clearly seen today as frozen into the language. walter is ok in
both. his only problem is that he looks too much at c++, both up and
down. when in doubt he does what c++ does, for example why the hell
is this a pointer? makes no sense. well it is in c++. and so on.
thank god const is not the same. in fact i could see a more definite
break with c++'s shitty parts once walter got those new aides bartosz
and andrei and i forgot the rest.
I totally agree with that point about C++. Walter always looks at C++
when unsure, and that isn't good IMHO. D is a new language that should
draw on the good stuff from all designs and languages instead of just
looking at C++. I disagree about const those. it is a departure from C++
but not a big enough departure.
if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk or
something like that. if I want to do procedural code I'll prefer C
syntax instead, but I definitely do not want to have a compromise
of both syntaxes in one language (we all know that a programing
language is an agreed upon compromise) that will not allow me to
express my OOP code in a concise OOP way and also will not allow me
to express my procedural code in a concise procedural way.
an everything-including-the-kitchen-sink language cannot provide
concise syntax for any of the paradigms it supports.
good language design is not about the kitchen sink as much as
harmoniously accommodating multiple styles. nobody has shown that
that can't be done.
Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?
Yigal Chripun wrote:
superdan wrote:
good language design is not about the kitchen sink as much as
harmoniously accommodating multiple styles. nobody has shown that
that can't be done.
Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?
Java is a statically typed, dynamic language. So it can be done, though
I'm sure people have varying opinions about the benefits of this
approach :-)
Sean
Sean Kelly Wrote:
Yigal Chripun wrote:
superdan wrote:
good language design is not about the kitchen sink as much as
harmoniously accommodating multiple styles. nobody has shown that
that can't be done.
Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?
Java is a statically typed, dynamic language. So it can be done, though
I'm sure people have varying opinions about the benefits of this
approach :-)
yeah i was about to write something to that effect too. forth also comes to
mind.
once d gets proper compile-time reflection, dynamic semantics will be a fart in
the standard library. just look at std.variant, particularly how it implements
the "length" shit. it screams "give me static reflection and i'll move the
earth".
Sean Kelly wrote:
Yigal Chripun wrote:
superdan wrote:
good language design is not about the kitchen sink as much as
harmoniously accommodating multiple styles. nobody has shown that
that can't be done.
Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?
Java is a statically typed, dynamic language. So it can be done, though
I'm sure people have varying opinions about the benefits of this
approach :-)
Sean
I meant statically typed vs. dynamically typed. and you cannot have
both. I do not understand what you mean with your Java example.
== Quote from Yigal Chripun (yigal100 gmail.com)'s article
Sean Kelly wrote:
Yigal Chripun wrote:
superdan wrote:
good language design is not about the kitchen sink as much as
harmoniously accommodating multiple styles. nobody has shown that
that can't be done.
Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?
Java is a statically typed, dynamic language. So it can be done, though
I'm sure people have varying opinions about the benefits of this
approach :-)
I meant statically typed vs. dynamically typed. and you cannot have
both. I do not understand what you mean with your Java example.
I suppose I should have been more clear. Java is statically typed but
dynamically bound. Pretty uncommon for a pure OO language.
Sean
Sean Kelly wrote:
I suppose I should have been more clear. Java is statically typed but
dynamically bound. Pretty uncommon for a pure OO language.
Sean
There must be some misunderstanding here. Java is not dynamically bound,
in the normal, general sense. The normal sense referring to the binding
of *variables* of course.
Were you meaning that the binding of *classes* was dynamic? That is true
of course, but one wouldn't call Java dynamically-bound because of that.
--
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
On 2008-07-23 16:09:02 -0500, Yigal Chripun <yigal100 gmail.com> said:
Sean Kelly wrote:
Yigal Chripun wrote:
superdan wrote:
good language design is not about the kitchen sink as much as
harmoniously accommodating multiple styles. nobody has shown that
that can't be done.
Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?
Java is a statically typed, dynamic language. So it can be done, though
I'm sure people have varying opinions about the benefits of this
approach :-)
Sean
I meant statically typed vs. dynamically typed. and you cannot have
both. I do not understand what you mean with your Java example.
Actually, Objective-C is pretty close to having both. Variables are
statically typed for types inherited from C (primitives, essentially),
and can optionally be statically typed for object pointers (e.g.
NSString *), but you can also use "id" to represent any object. Even
beyond declarations, there are things like "isa swizzling" that can
change the observable type of an object or class at runtime.
Yigal Chripun Wrote:
superdan wrote:
good point, i was thinking of firefox and thunderbird too. then i
realized the reality is, both ff and tb ended up integrating the most
popular extensions in their core. why? because there is pressure,
hence walter's point.
The devil's in the details - Firefox integrated extensions as features
of the browser itself only when the extension "fixed" problems in the
core itself and/or the feature is general enough that it should have
been designed as part of the core. the Tab implementation for example
benefited from integrating functionally from extensions and the session
feature was added since it is general and useful for all FF users.
let's look again to eclipse to see this difference:
eclipse 3.4 added a new update manager with lots of new features. this
makes sense as part of the SDK of eclipse itself since all users of
eclipse will benefit from this. on the other hand, JDT will not ever be
needed by a c++ programmer (unless he decides to move to Java). same
goes for CDT, PDT, etc..
some features should be added to the core, and some will not ever be
general to be part of the core.
another example, the delicious extension will always be only useful for
delicious subscribers and should never be part of Firefox itself.
here's my educated guess: Sean uses erlang + D to get the same
benefits. he can have the feature sets of both languages with their
own lean & mean syntaxes that are geared toward their respective
feature sets. while if he had used one language with both feature
sets, than the syntax of that language would be much more
complicated in order to support all the features. C++ as an
example: its syntax is horrible due to the fact that it can do so
much.
no. its syntax is horrible because it has a shitty design. bjarne has
made the tactical mistake of ignoring theoretical syntax matters and
also compiler construction costs, in favor of what greedily looked
most usable at the moment for the feature being designed. he is known
for shooing away all those who opposed additions on grounds of
syntactic and implementation difficulties. he pushed the fucking
angle brackets over the dead body of pennello and the fucking export
and two-phase lookup shit over everybody's dead body. what does that
have to do with c++ being multiparadigm? nothing? correct!
congratulations, you won a plasma tv set.
Even with that in mind, that's not enough.
think of this this way:
what's the best way to design GUI?
probably to draw it in a visual designer and not using some API.
what's the best way to write a database query? probably SQL is the most
concise way to express that. etc, etc..
there's a whole paradigm of Language Oriented Programming that you
should look at. (MPS by jetbrains is a good example of that, I think)
the point is - when you restrict yourself to a specific domain you can
design the best way to express in that domain that may conflict with
other domains in a general language ( you probably wouldn't want to draw
all your "code" with a visual designer, while that's the best way to
express gui..)
bjarne was strong on strategy and extremely weak in tactics. that can
be clearly seen today as frozen into the language. walter is ok in
both. his only problem is that he looks too much at c++, both up and
down. when in doubt he does what c++ does, for example why the hell
is this a pointer? makes no sense. well it is in c++. and so on.
thank god const is not the same. in fact i could see a more definite
break with c++'s shitty parts once walter got those new aides bartosz
and andrei and i forgot the rest.
I totally agree with that point about C++. Walter always looks at C++
when unsure, and that isn't good IMHO. D is a new language that should
draw on the good stuff from all designs and languages instead of just
looking at C++. I disagree about const those. it is a departure from C++
but not a big enough departure.
if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk or
something like that. if I want to do procedural code I'll prefer C
syntax instead, but I definitely do not want to have a compromise
of both syntaxes in one language (we all know that a programing
language is an agreed upon compromise) that will not allow me to
express my OOP code in a concise OOP way and also will not allow me
to express my procedural code in a concise procedural way.
an everything-including-the-kitchen-sink language cannot provide
concise syntax for any of the paradigms it supports.
good language design is not about the kitchen sink as much as
harmoniously accommodating multiple styles. nobody has shown that
that can't be done.
Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?
obviously if you forgo some shit it's easier to pay attention to other shit and
do it better. that goes without sayin' and pretty much anyone who's ever done
business at any level knows it, let alone programmers. but forgoing that shit
also means there's a loss in expressiveness. all i'm sayin' is that there are
many local maxima in this multidimensional shit that language design is, and
the easily reachable ones have already been reached (e.g. "all shit is just
objects" or "all shit is just functions" or "all shit is just oatmeal and
toenails"). but these are local maxima that only greedily optimize on a couple
of directions. nobody knows where the global optimum is, but sure as shit it's
not on one axis. feel me?
is d closing in to that optimum? no idea. is it closer to the optimum than some
other languages? fuck yeah. is its gradient positive? looks to me like it is,
if only walter doesn't acquire alzheimer or shit.
superdan wrote:
is d closing in to that optimum? no idea. is it closer to the optimum
than some other languages? fuck yeah. is its gradient positive? looks
to me like it is, if only walter doesn't acquire alzheimer or shit.
I hope to have a few good years left in me before I get alzheimer's <g>.
Yigal Chripun wrote:
The word example is wrong in that, in your example, bill doesn't need
similar to eclipse: both sue and bill can use eclipse but since bill
works with c/c++ he can get a pre-packaged version with CDT which is
much smaller than the entire eclipse project, and sue can get her
eclipse pre-packaged with JDT since she works with Java. This is why
Eclipse is so popular and supported by many large companies like oracle,
IBM, etc.. The same goes to the popular browser Firefox and its
extensions. No need to bundle everything like Microsoft word does, it's
much better to have a system to allow users to integrate features they
require beyond the lean & mean core.
What you're saying is provide a lean & mean core with a pluggable
architecture that can be extended by 3rd parties. I think you're quite
right that that is a better system than all-in-one.
D has a lot of support for "pluggable architecture", such as template
metaprogramming and string mixins. Lisp is famous for being a very
pluggable language.
Unfortunately, I don't see any way to be able to "plug in" the needed
support for functional coding, there just isn't enough basic capability
in the language. We're trying to fix that.
C++ as an example: its syntax is horrible due to the fact that it can do
so much.
I don't agree with that being the reason its syntax is horrible. The
reason is more related to efforts to preserve backwards syntax
compatibility, and because some expert advice was ignored in the case of
using < > for templates.
if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
or something like that. if I want to do procedural code I'll prefer C
syntax instead, but I definitely do not want to have a compromise of
both syntaxes in one language (we all know that a programing language is
an agreed upon compromise) that will not allow me to express my OOP code
in a concise OOP way and also will not allow me to express my procedural
code in a concise procedural way.
an everything-including-the-kitchen-sink language cannot provide concise
syntax for any of the paradigms it supports.
You're right, it can't, but it can provide good enough syntax that
overweights the large disadvantages of trying to get two very different
languages to work together.
Walter,
Thanks for replying, please see my notes in the body of the text
Walter Bright wrote:
Yigal Chripun wrote:
The word example is wrong in that, in your example, bill doesn't need
similar to eclipse: both sue and bill can use eclipse but since bill
works with c/c++ he can get a pre-packaged version with CDT which is
much smaller than the entire eclipse project, and sue can get her
eclipse pre-packaged with JDT since she works with Java. This is why
Eclipse is so popular and supported by many large companies like oracle,
IBM, etc.. The same goes to the popular browser Firefox and its
extensions. No need to bundle everything like Microsoft word does, it's
much better to have a system to allow users to integrate features they
require beyond the lean & mean core.
What you're saying is provide a lean & mean core with a pluggable
architecture that can be extended by 3rd parties. I think you're quite
right that that is a better system than all-in-one.
D has a lot of support for "pluggable architecture", such as template
metaprogramming and string mixins. Lisp is famous for being a very
pluggable language.
Unfortunately, I don't see any way to be able to "plug in" the needed
support for functional coding, there just isn't enough basic capability
in the language. We're trying to fix that.
Walter, please take a look at the design used by Nemerle.
The language designers of Nemerle achieved a _very_ pluggable
architecture via Macros (probably identical to your idea of AST macros).
their system allows to implement whole subsets of the language
*including the syntax* as plugins which in D are now part of the
language. They have DBC, concurrency, etc implemented like that. they
have a plan to make an AOP plugin as well.
look at:
http://nemerle.org/Macros
http://nemerle.org/Syntax_extensions
http://nemerle.org/doc/Nemerle.Compiler.html
etc..
C++ as an example: its syntax is horrible due to the fact that it can do
so much.
I don't agree with that being the reason its syntax is horrible. The
reason is more related to efforts to preserve backwards syntax
compatibility, and because some expert advice was ignored in the case of
using < > for templates.
if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk
or something like that. if I want to do procedural code I'll prefer C
syntax instead, but I definitely do not want to have a compromise of
both syntaxes in one language (we all know that a programing language is
an agreed upon compromise) that will not allow me to express my OOP code
in a concise OOP way and also will not allow me to express my procedural
code in a concise procedural way.
an everything-including-the-kitchen-sink language cannot provide concise
syntax for any of the paradigms it supports.
You're right, it can't, but it can provide good enough syntax that
overweights the large disadvantages of trying to get two very different
languages to work together.
It depends on what kind of languages you try to integrate, C and python
probably will have issues since they use very different run-times.
But, compare that with Java and [J]Ruby both running on the same JVM in
one process. you can use classes from both languages together with no
trouble at all. you get all the benefits of combining the strengths of
both without any drawbacks.
in the same way you can instantiate Java classes inside Scala since,
again, both run in the same JVM.
Yigal Chripun:
Walter, please take a look at the design used by Nemerle.
The language designers of Nemerle achieved a _very_ pluggable
architecture via Macros (probably identical to your idea of AST macros).
OMeta is better, it's a tiny metalanguage, that can be implemented in various
languages (already done: javascript, scheme, Python, Cola, and maybe more):
http://www.cs.ucla.edu/~awarth/ometa/
This is a (partial, but already usable) Python implementation, PyMeta:
http://washort.twistedmatrix.com/
I am sure that OMeta will shake the world of computer science.
Bye,
bearophile
Yigal Chripun wrote:
Walter, please take a look at the design used by Nemerle.
The language designers of Nemerle achieved a _very_ pluggable
architecture via Macros (probably identical to your idea of AST macros).
their system allows to implement whole subsets of the language
*including the syntax* as plugins which in D are now part of the
language. They have DBC, concurrency, etc implemented like that. they
have a plan to make an AOP plugin as well.
look at:
http://nemerle.org/Macros
http://nemerle.org/Syntax_extensions
http://nemerle.org/doc/Nemerle.Compiler.html
etc..
I've heard about nemerle now and then, but have never looked at it. One
of the problems with a user definable syntax is the code may become
unreadable. I still find it hard to see how one could implement a const
type system, for example, as a language extension. It's a lot more than
just syntax.
Walter Bright wrote:
Yigal Chripun wrote:
Walter, please take a look at the design used by Nemerle.
The language designers of Nemerle achieved a _very_ pluggable
architecture via Macros (probably identical to your idea of AST macros).
their system allows to implement whole subsets of the language
*including the syntax* as plugins which in D are now part of the
language. They have DBC, concurrency, etc implemented like that. they
have a plan to make an AOP plugin as well.
look at:
http://nemerle.org/Macros
http://nemerle.org/Syntax_extensions
http://nemerle.org/doc/Nemerle.Compiler.html
etc..
I've heard about nemerle now and then, but have never looked at it. One
of the problems with a user definable syntax is the code may become
unreadable. I still find it hard to see how one could implement a const
type system, for example, as a language extension. It's a lot more than
just syntax.
IMHO, syntax extensions with a few restrictions on what syntax can be
added to the language is very powerful. but even without the syntax
sugar, those macros of nemerle are very powerful and a lot more
expressive than templates. the main gripe I have with templates is that
they require a different syntax. in nemerle you just use the same code
you write at run time to create compile time constructs/ plugins to the
language. you do not need to copy OOP features such as interfaces into
compile time "concepts" as C++0x does.
It's possible to implement D const in nemerle beacuse they provide
Compiler APIs that let the programmer plug their macros at different
stages of compilation. This is the important thing here, more than the
syntax. You have a way to talk with the compiler from your code. This is
why DBC is implemented as a set of macros with syntax extensions and
allows to implement AOP in the same way.
The GC in D has an API that allows your code to control GC via APIs. In
the same way, Compiler APIs allow you in compile-time code to control
and alter the compilation process.
Yigal Chripun Wrote:
Walter,
Thanks for replying, please see my notes in the body of the text
Walter Bright wrote:
Yigal Chripun wrote:
The word example is wrong in that, in your example, bill doesn't need
similar to eclipse: both sue and bill can use eclipse but since bill
works with c/c++ he can get a pre-packaged version with CDT which is
much smaller than the entire eclipse project, and sue can get her
eclipse pre-packaged with JDT since she works with Java. This is why
Eclipse is so popular and supported by many large companies like oracle,
IBM, etc.. The same goes to the popular browser Firefox and its
extensions. No need to bundle everything like Microsoft word does, it's
much better to have a system to allow users to integrate features they
require beyond the lean & mean core.
What you're saying is provide a lean & mean core with a pluggable
architecture that can be extended by 3rd parties. I think you're quite
right that that is a better system than all-in-one.
D has a lot of support for "pluggable architecture", such as template
metaprogramming and string mixins. Lisp is famous for being a very
pluggable language.
Unfortunately, I don't see any way to be able to "plug in" the needed
support for functional coding, there just isn't enough basic capability
in the language. We're trying to fix that.
Walter, please take a look at the design used by Nemerle.
The language designers of Nemerle achieved a _very_ pluggable
architecture via Macros (probably identical to your idea of AST macros).
their system allows to implement whole subsets of the language
*including the syntax* as plugins which in D are now part of the
language. They have DBC, concurrency, etc implemented like that. they
have a plan to make an AOP plugin as well.
look at:
http://nemerle.org/Macros
http://nemerle.org/Syntax_extensions
http://nemerle.org/doc/Nemerle.Compiler.html
etc..
nemerle is a stillborn, you can quote me on that. since 1970 languages tried to
make configurable syntax palatable. never works. ever heard of imp72? that's
telling. probably the nemerle folks also didn't know. and they will pay for it.
why is it the case that configurable syntax never works? no idea. if i had to
venture an opinion i'd say configurable syntax does not come natural to humans.
natural language has fixed syntax.
superdan wrote:
nemerle is a stillborn, you can quote me on that. since 1970
languages tried to make configurable syntax palatable. never works.
ever heard of imp72? that's telling. probably the nemerle folks also
didn't know. and they will pay for it.
why is it the case that configurable syntax never works? no idea. if
i had to venture an opinion i'd say configurable syntax does not come
natural to humans. natural language has fixed syntax.
nemerle does not provide configurable syntax but rather a core language
that you can add extensions to (with some restrictions, I think).
It takes a long time for people to switch languages, since it also
requires changing a mindset. thus, it takes generations of programmers
till new concepts become generally used. languages developed in the 60's
delegates & events/D delegates/Java is in the process of adding them as
well.
last point: the comparison with natural languages is wrong - a human
need to know only one language to communicate since natural languages
are much more powerful. they allow concepts like irony, metaphors, etc,
which are not possible in a formal language.
I haven't seen a compiler that understands irony yet, but if you plan to
develop one than do share, this would be interesting to try out.
Reply to superdan,
why is it the case that configurable syntax never works? no idea. if i
had to venture an opinion i'd say configurable syntax does not come
natural to humans. natural language has fixed syntax.
Sort of. Take a walk from the Burbs to the Ghetto and tell me that natural
language has fixed syntax. Different people use the same language with
different
(but to them fixed) syntax. OTOH people often have a hard time understanding
people who use different syntax.
Walter Bright wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it
tend to be a mess.
I agree that diverse paradigm support can lead to a mess. On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
I agree. In fact, I'd bet that imperative applications will dwindle
over time because such code inherently resists parallelization. But I
very much believe that there is an ongoing need for systems languages,
and I can't envision a functional systems language. Such languages must
allow mutable state.
I disagree that using multiple languages for one project is a good idea,
unless one language is hosted by the other (like emacs/elisp). Trying to
get two languages produced by different vendors to consistently work
together across platforms and differing upgrade schedules can be a
prescription for a lot of extra work. Is learning two different
languages really easier than learning two different paradigms in the
same language?
It comes back to that semantic barrier I mentioned in my other post.
With everything in a single language, I think in team programming it
will be inevitable that imperative code will "bleed" into areas that are
intended to be functional, purely as a result of the personal styles of
the programmers involved.
As for learning multiple languages... web development already involves a
ton of different protocols, technologies, and languages, so I think
there's precedent that this isn't a huge obstacle for most teams. I
would personally rather have a set of specialized tools than one tool
which can do everything but isn't really ideal for anything.
Regarding the D mixed functional / imperative approach, another issue
I have with it is that it's exactly the reverse of the Erlang / C
model. While Erlang / C is functional for control structures and
imperative for optimization points, D looks like it will be imperative
for control and functional for optimization. Plus, I really like the
concurrency model in Erlang.
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem is,
it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
And so on. Feature creep is the result of inexorable and unrelenting
pressure for them.
I'd say that the word processor should be modular and that the requested
features should be sold as plug-ins. Then customer A gets his lean mean
word processor with exactly the features he wants, and the same for
customers B and C. This obviously isn't possible with a language
however, so I'm inclined to say that this is a false analogy.
Sean
Sean Kelly:
But I very much believe that there is an ongoing need for systems
languages, and I can't envision a functional systems language. Such
languages must allow mutable state.
There are many functional languages that allow to mutate state.
I'm sure the functional lang crowd will suggest you many functional languages
that may be fitting for your requirements if you ask in the rigth places (like
the Lambda the Ultimate blog).
Personally I may suggest this (with a lisp-like syntax, but it's not lisp), but
I have not used it yet:
http://www.bitc-lang.org/
Bye,
bearophile
bearophile wrote:
Sean Kelly:
But I very much believe that there is an ongoing need for systems
languages, and I can't envision a functional systems language. Such
languages must allow mutable state.
There are many functional languages that allow to mutate state.
I'm sure the functional lang crowd will suggest you many functional languages
that may be fitting for your requirements if you ask in the rigth places (like
the Lambda the Ultimate blog).
Personally I may suggest this (with a lisp-like syntax, but it's not lisp),
but I have not used it yet:
http://www.bitc-lang.org/
Interesting. Can't say I'm crazy about the lisp-like syntax if I had to
use it for systems programming, but it certainly does what you claimed.
And I know that even Erlang allows mutable state--it doesn't try to
obscure IO in a functionally invariant wrapper, for example--but I've
always felt that the functional syntax naturally lent itself to a
particular style of programming which assumes invariance.
That said, I do agree that integrating multiple languages for a single
application is often undesirable because the interaction points between
the languages are often complex and irritating to use. This is the
obvious selling point for the .NET CLI approach, and is actually why I
think they created it in the first place. Regarding Erlang's
interaction with C / D in particular however, because Erlang is
effectively actor-based, the interaction is fairly similar to all
interprocess communication in Erlang. I think this lends to creating
subsystems in C / D rather than tiny optimization points, but the
approach is fairly workable overall. However, I will admit that I'd
occasionally like to have in-process "plugin" functions to avoid the
overhead of communicating with a separate process, so I do think one
could argue that the D2 approach is a good one. It's just not an
argument I've fully accepted quite yet.
Sean
Sean Kelly Wrote:
Walter Bright wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it
tend to be a mess.
I agree that diverse paradigm support can lead to a mess. On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
I agree. In fact, I'd bet that imperative applications will dwindle
over time because such code inherently resists parallelization.
this is a logical fallacy. you haven't shown that all or most code will need
paralellization. you'd need to show that for your point to stand.
But I
very much believe that there is an ongoing need for systems languages,
and I can't envision a functional systems language. Such languages must
allow mutable state.
...on today's architectures. if hardware transactional memory makes it things
will change quite a bit.
I disagree that using multiple languages for one project is a good idea,
unless one language is hosted by the other (like emacs/elisp). Trying to
get two languages produced by different vendors to consistently work
together across platforms and differing upgrade schedules can be a
prescription for a lot of extra work. Is learning two different
languages really easier than learning two different paradigms in the
same language?
It comes back to that semantic barrier I mentioned in my other post.
With everything in a single language, I think in team programming it
will be inevitable that imperative code will "bleed" into areas that are
intended to be functional, purely as a result of the personal styles of
the programmers involved.
yeah and that will be documented in pure vs. impure functions and in invariant
vs. const/mutable data. this is great. d is not a convention-based language
like c++.
As for learning multiple languages... web development already involves a
ton of different protocols, technologies, and languages, so I think
there's precedent that this isn't a huge obstacle for most teams. I
would personally rather have a set of specialized tools than one tool
which can do everything but isn't really ideal for anything.
that again is a logical fallacy. i like messing with cars. i have an amazing
18V drill that i use for a ton of stuff - screws, bolts, holes, adjustments,
rust removal, you name it. does that mean i'm only trying to use that tool for
everything? sure not. but that doesn't make it less loveable.
Regarding the D mixed functional / imperative approach, another issue
I have with it is that it's exactly the reverse of the Erlang / C
model. While Erlang / C is functional for control structures and
imperative for optimization points, D looks like it will be imperative
for control and functional for optimization. Plus, I really like the
concurrency model in Erlang.
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem is,
it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
And so on. Feature creep is the result of inexorable and unrelenting
pressure for them.
I'd say that the word processor should be modular and that the requested
features should be sold as plug-ins. Then customer A gets his lean mean
word processor with exactly the features he wants, and the same for
customers B and C. This obviously isn't possible with a language
however, so I'm inclined to say that this is a false analogy.
i agree. let's drop this word parallel.
superdan wrote:
Sean Kelly Wrote:
Walter Bright wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it
tend to be a mess.
I agree that diverse paradigm support can lead to a mess. On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
I agree. In fact, I'd bet that imperative applications will dwindle
over time because such code inherently resists parallelization.
this is a logical fallacy. you haven't shown that all or most code will need
paralellization. you'd need to show that for your point to stand.
I wasn't making a logical argument, but rather stating an opinion. The
current trend indicates that we're hit a wall with performance scaling
in a single CPU, and yet the demand for increased software performance
continues. I know that some tasks are difficult to execute in parallel,
but if increased performance is desired then something has to give.
Also, many client-facing applications are already somewhat parallel
because they are event-driven. Games can throw AI in one or more
threads, etc. They don't have to, but it's the best way to exploit
current trends in hardware performance scaling.
But I
very much believe that there is an ongoing need for systems languages,
and I can't envision a functional systems language. Such languages must
allow mutable state.
...on today's architectures. if hardware transactional memory makes it things
will change quite a bit.
Hardware transactional memory is awesome. I'm not too fond of purely
software transactional memory though. The overhead tends to be too
great in most instances
I disagree that using multiple languages for one project is a good idea,
unless one language is hosted by the other (like emacs/elisp). Trying to
get two languages produced by different vendors to consistently work
together across platforms and differing upgrade schedules can be a
prescription for a lot of extra work. Is learning two different
languages really easier than learning two different paradigms in the
same language?
It comes back to that semantic barrier I mentioned in my other post.
With everything in a single language, I think in team programming it
will be inevitable that imperative code will "bleed" into areas that are
intended to be functional, purely as a result of the personal styles of
the programmers involved.
yeah and that will be documented in pure vs. impure functions and in invariant
vs. const/mutable data. this is great. d is not a convention-based language
like c++.
Yeah, but to cross these barriers casting is typically required. And I
hate casting :-) But you're still right.
As for learning multiple languages... web development already involves a
ton of different protocols, technologies, and languages, so I think
there's precedent that this isn't a huge obstacle for most teams. I
would personally rather have a set of specialized tools than one tool
which can do everything but isn't really ideal for anything.
that again is a logical fallacy. i like messing with cars. i have an amazing
18V drill that i use for a ton of stuff - screws, bolts, holes, adjustments,
rust removal, you name it. does that mean i'm only trying to use that tool for
everything? sure not. but that doesn't make it less loveable.
I'd argue that you're still using the drill for things it was intended
to do. After all, a drill is just a portable electric engine, really.
Regarding the D mixed functional / imperative approach, another issue
I have with it is that it's exactly the reverse of the Erlang / C
model. While Erlang / C is functional for control structures and
imperative for optimization points, D looks like it will be imperative
for control and functional for optimization. Plus, I really like the
concurrency model in Erlang.
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem is,
it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
And so on. Feature creep is the result of inexorable and unrelenting
pressure for them.
I'd say that the word processor should be modular and that the requested
features should be sold as plug-ins. Then customer A gets his lean mean
word processor with exactly the features he wants, and the same for
customers B and C. This obviously isn't possible with a language
however, so I'm inclined to say that this is a false analogy.
i agree. let's drop this word parallel.
Works for me.
Sean
Sean Kelly Wrote:
As for learning multiple languages... web development already involves a
ton of different protocols, technologies, and languages, so I think
there's precedent that this isn't a huge obstacle for most teams. I
would personally rather have a set of specialized tools than one tool
which can do everything but isn't really ideal for anything.
that again is a logical fallacy. i like messing with cars. i have an amazing
18V drill that i use for a ton of stuff - screws, bolts, holes, adjustments,
rust removal, you name it. does that mean i'm only trying to use that tool for
everything? sure not. but that doesn't make it less loveable.
I'd argue that you're still using the drill for things it was intended
to do. After all, a drill is just a portable electric engine, really.
which completes my point superbly. (what a wanker word.) is a screwdriver more
specialized than a drill? most likely. is a drill still better? mine is :) then
it's not all a zero sum game. there are tools that are not specialized and
mightily useful.
i know this has a counter-point to which i could bring a counter-counter-point
and so on til we have to wear diapers again. to prevent all that let me say
this: human ingenuity makes the difference between solutions to problems that
seem a zero-sum game. i remember from the days i was designing chips: we had to
design an adc and everybody knew the relative tradeoffs of making various
transistor combo designs. yet one day this guy comes and fuck me but his idea
was just better than everything else in all aspects! even my boss said "such
ideas are in very short supply". to bring this back to d. i couldn't design an
const/invariant system to save my life from the same cannibals who ate bjarne.
the space looked like a zero sum shit to me. so when i saw what walter came up
with, i was rightly surprised. same goes about some shit in phobos2. it's not
just yet another library. it's a fucking cool one because it's better in a new
and surprising way.
superdan wrote:
i couldn't design an const/invariant system to save my life
from the same cannibals who ate bjarne. the space looked like a zero
sum shit to me. so when i saw what walter came up with, i was rightly
surprised. same goes about some shit in phobos2. it's not just yet
another library. it's a fucking cool one because it's better in a new
and surprising way.
I cannot claim credit for it. The const/invariant design was the result
of literally hundreds of hours of work (and maybe a hundred gallons of
coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as
feedback from the community on why our earlier efforts got it wrong.
The transitivity requirement originated with Andrei, if I recall correctly.
Walter Bright wrote:
superdan wrote:
i couldn't design an const/invariant system to save my life
from the same cannibals who ate bjarne. the space looked like a zero
sum shit to me. so when i saw what walter came up with, i was rightly
surprised. same goes about some shit in phobos2. it's not just yet
another library. it's a fucking cool one because it's better in a new
and surprising way.
I cannot claim credit for it. The const/invariant design was the result
of literally hundreds of hours of work (and maybe a hundred gallons of
coffee) by Andrei, Bartosz, Brad, David, Eric and myself, as well as
feedback from the community on why our earlier efforts got it wrong.
The transitivity requirement originated with Andrei, if I recall correctly.
The transitivity requirement pretty much single-handedly eliminates all
of my issues with C++ const. Kudos to Andrei for suggesting it.
Sean
On Tue, 22 Jul 2008, Walter Bright wrote:
superdan wrote:
i couldn't design an const/invariant system to save my life
from the same cannibals who ate bjarne. the space looked like a zero
sum shit to me. so when i saw what walter came up with, i was rightly
surprised. same goes about some shit in phobos2. it's not just yet
another library. it's a fucking cool one because it's better in a new
and surprising way.
I cannot claim credit for it. The const/invariant design was the result of
literally hundreds of hours of work (and maybe a hundred gallons of coffee) by
Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the
community on why our earlier efforts got it wrong.
The transitivity requirement originated with Andrei, if I recall correctly.
Quite possibly it was both of us, but I know I brought it up in
discussions with you prior to joining the group discussions. It's my
primary angst with c++ const.
Later,
Brad
On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com> wrote:
On Tue, 22 Jul 2008, Walter Bright wrote:
superdan wrote:
i couldn't design an const/invariant system to save my life
from the same cannibals who ate bjarne. the space looked like a zero
sum shit to me. so when i saw what walter came up with, i was rightly
surprised. same goes about some shit in phobos2. it's not just yet
another library. it's a fucking cool one because it's better in a new
and surprising way.
I cannot claim credit for it. The const/invariant design was the result of
literally hundreds of hours of work (and maybe a hundred gallons of coffee) by
Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the
community on why our earlier efforts got it wrong.
The transitivity requirement originated with Andrei, if I recall correctly.
Quite possibly it was both of us, but I know I brought it up in
discussions with you prior to joining the group discussions. It's my
primary angst with c++ const.
By that do you mean something that's caused you actual trouble in C++
projects? Or just something that keeps you awake at night worrying
about the trouble it could cause? My feeling is that C++ const does a
decent job in practice of preventing programmers from doing stupid
things. On the other hand, if you're trying to go out of your way to
be stupid... that's another matter. But for the most part, while it
may be easy to circumvent const, it's not so easy to circumvent it
accidentally. Useless for making compiler optimizations, yes, but
fine for documenting the intent of code.
--bb
Bill Baxter wrote:
On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com> wrote:
On Tue, 22 Jul 2008, Walter Bright wrote:
superdan wrote:
i couldn't design an const/invariant system to save my life
from the same cannibals who ate bjarne. the space looked like a zero
sum shit to me. so when i saw what walter came up with, i was rightly
surprised. same goes about some shit in phobos2. it's not just yet
another library. it's a fucking cool one because it's better in a new
and surprising way.
I cannot claim credit for it. The const/invariant design was the result of
literally hundreds of hours of work (and maybe a hundred gallons of coffee) by
Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the
community on why our earlier efforts got it wrong.
The transitivity requirement originated with Andrei, if I recall correctly.
Quite possibly it was both of us, but I know I brought it up in
discussions with you prior to joining the group discussions. It's my
primary angst with c++ const.
By that do you mean something that's caused you actual trouble in C++
projects? Or just something that keeps you awake at night worrying
about the trouble it could cause? My feeling is that C++ const does a
decent job in practice of preventing programmers from doing stupid
things. On the other hand, if you're trying to go out of your way to
be stupid... that's another matter. But for the most part, while it
may be easy to circumvent const, it's not so easy to circumvent it
accidentally. Useless for making compiler optimizations, yes, but
fine for documenting the intent of code.
I think one salient difference between C++ and D related to this is that
objects are reference-based in D and thus would be mutable by default
given the C++ const rules. One could argue that the compiler could
apply the const-ness of the containing object to object members, but
good sense would dictate that const-ness should apply identically to all
reference-based members rather than making object members a special
case. And at that point you've got transitive const :-)
Sean
Bill Baxter wrote:
By that do you mean something that's caused you actual trouble in C++
projects? Or just something that keeps you awake at night worrying
about the trouble it could cause? My feeling is that C++ const does a
decent job in practice of preventing programmers from doing stupid
things. On the other hand, if you're trying to go out of your way to
be stupid... that's another matter. But for the most part, while it
may be easy to circumvent const, it's not so easy to circumvent it
accidentally. Useless for making compiler optimizations, yes, but
fine for documenting the intent of code.
It isn't that unusual for C++ programmers to rely on having a const
pointer to mutable data (I know this because they tell me that their
design breaks with D). C++ has no self-documenting method to distinguish
transitive const from non-transitive const, yet both are used in real code.
C++ const has also turned out to be of no value for writing
multithreaded code. C++ const was fine for the 90's, but those days are
over. C++0x has not addressed this issue, as the C++ community has not
yet recognized the problem (many individual top C++ programmers do
recognize it, but I've gotten the impression they see it as unimportant
or hope it will just go away). I expect that it will become glaringly
obvious over the next few years. The coming multicore revolution is
going to cause big problems and the proposed C++0x threading model isn't
going to fix it.
On Wed, 23 Jul 2008, Bill Baxter wrote:
On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com> wrote:
On Tue, 22 Jul 2008, Walter Bright wrote:
superdan wrote:
i couldn't design an const/invariant system to save my life
from the same cannibals who ate bjarne. the space looked like a zero
sum shit to me. so when i saw what walter came up with, i was rightly
surprised. same goes about some shit in phobos2. it's not just yet
another library. it's a fucking cool one because it's better in a new
and surprising way.
I cannot claim credit for it. The const/invariant design was the result of
literally hundreds of hours of work (and maybe a hundred gallons of coffee) by
Andrei, Bartosz, Brad, David, Eric and myself, as well as feedback from the
community on why our earlier efforts got it wrong.
The transitivity requirement originated with Andrei, if I recall correctly.
Quite possibly it was both of us, but I know I brought it up in
discussions with you prior to joining the group discussions. It's my
primary angst with c++ const.
By that do you mean something that's caused you actual trouble in C++
projects? Or just something that keeps you awake at night worrying
about the trouble it could cause? My feeling is that C++ const does a
decent job in practice of preventing programmers from doing stupid
things. On the other hand, if you're trying to go out of your way to
be stupid... that's another matter. But for the most part, while it
may be easy to circumvent const, it's not so easy to circumvent it
accidentally. Useless for making compiler optimizations, yes, but
fine for documenting the intent of code.
--bb
I mean has caused real trouble. I don't tend to make a lot of arguments
based on theory. Primarily they're made from hard earned practice. C++
does not make it possible (possibly too strong a statement, substitute
easy if you can think of a loophole) to take an existing object that is
poorly implemented for const-correctness and make that a contained object
in another class that wants to behave const correctly. It's way way too
easy to make a mistake and have constness end without seeing it.
Transitivity is what most more junior developers _expect_ from c++'s const
system and it's not what they get.
Secondarily, I _strongly_ value the benefit of const at the interface
layer. That's even more important to me than the other half of constness.
I love D's use of contracts and const (as well as in, out, and inout)
playes a big role there.
Yes, it's a matter of mismatched exepctations, and it is possible to use
const correctly in c++, but to do so requires (like so much of c++)
considerable care.
To clarify, I've spent much of my 20 year career as both a maintenance
programmer and as a new code developer (roughly 50/50). I tend to
volunteer for the cleanup projects because no one else is willing to do
it. A lot of that time has been in multi-million line code bases that
have been evolved extremely rapidly and haphazardly. Yes it's the fault
of the code as much as the language, but a language that gave better
guarantees would have prevented problems and made ongoing maintenance
easier by having a trustable const system.
Make sense?
Later,
Brad
Brad Roberts wrote:
On Tue, 22 Jul 2008, Walter Bright wrote:
The transitivity requirement originated with Andrei, if I recall correctly.
Quite possibly it was both of us, but I know I brought it up in
discussions with you prior to joining the group discussions. It's my
primary angst with c++ const.
That's entirely possible, and I apologize for the gaps in my memory.
"Walter Bright" wrote
Brad Roberts wrote:
On Tue, 22 Jul 2008, Walter Bright wrote:
The transitivity requirement originated with Andrei, if I recall
correctly.
Quite possibly it was both of us, but I know I brought it up in
discussions with you prior to joining the group discussions. It's my
primary angst with c++ const.
That's entirely possible, and I apologize for the gaps in my memory.
There's that alzheimers coming on :)
-Steve
Content-Disposition: inline
On Wed, Jul 23, 2008 at 9:35 AM, Brad Roberts <braddr puremagic.com> wrote:
On Wed, 23 Jul 2008, Bill Baxter wrote:
On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr puremagic.com>
wrote:
On Tue, 22 Jul 2008, Walter Bright wrote:
By that do you mean something that's caused you actual trouble in C++
projects? Or just something that keeps you awake at night worrying
about the trouble it could cause? My feeling is that C++ const does a
decent job in practice of preventing programmers from doing stupid
things. On the other hand, if you're trying to go out of your way to
be stupid... that's another matter. But for the most part, while it
may be easy to circumvent const, it's not so easy to circumvent it
accidentally. Useless for making compiler optimizations, yes, but
fine for documenting the intent of code.
--bb
I mean has caused real trouble. I don't tend to make a lot of arguments
based on theory. Primarily they're made from hard earned practice. C++
does not make it possible (possibly too strong a statement, substitute
easy if you can think of a loophole) to take an existing object that is
poorly implemented for const-correctness and make that a contained object
in another class that wants to behave const correctly. It's way way too
easy to make a mistake and have constness end without seeing it.
Transitivity is what most more junior developers _expect_ from c++'s const
system and it's not what they get.
Secondarily, I _strongly_ value the benefit of const at the interface
layer. That's even more important to me than the other half of constness.
I love D's use of contracts and const (as well as in, out, and inout)
playes a big role there.
Yes, it's a matter of mismatched exepctations, and it is possible to use
const correctly in c++, but to do so requires (like so much of c++)
considerable care.
To clarify, I've spent much of my 20 year career as both a maintenance
programmer and as a new code developer (roughly 50/50). I tend to
volunteer for the cleanup projects because no one else is willing to do
it. A lot of that time has been in multi-million line code bases that
have been evolved extremely rapidly and haphazardly. Yes it's the fault
of the code as much as the language, but a language that gave better
guarantees would have prevented problems and made ongoing maintenance
easier by having a trustable const system.
Make sense?
Yep. Thanks for sharing your experience. I'm a researcher, so while I've
been at this for coding thing for 20 years too, I don't tend to play around
with a lot of million-line code bases written by million-monkey junior
programmers. I did do a short stint for a big, well-known software company
once, and got my taste of million-monkey code, though. Scary stuff. They
wanted me to modify some crufty parser to do some new tricks when there were
absolutely no unit tests or example programs or even documentation to show
me what it was supposed to be doing in the first place. I'm amazed now that
they didn't tell me to "figure out this mess and document it first, writes
some unit tests, then add feature X" but instead they just wanted me to jump
right in and throw more gasoline into the fire. Yikes.
--bb
Bill Baxter wrote:
Yep. Thanks for sharing your experience. I'm a researcher, so while
I've been at this for coding thing for 20 years too, I don't tend to
play around with a lot of million-line code bases written by
million-monkey junior programmers. I did do a short stint for a big,
well-known software company once, and got my taste of million-monkey
code, though. Scary stuff. They wanted me to modify some crufty parser
to do some new tricks when there were absolutely no unit tests or
example programs or even documentation to show me what it was supposed
to be doing in the first place. I'm amazed now that they didn't tell me
to "figure out this mess and document it first, writes some unit tests,
then add feature X" but instead they just wanted me to jump right in and
throw more gasoline into the fire. Yikes.
Microsoft once asked me why I didn't update the MFC library that comes
with DMC++. I said the problem was that MFC is a large complex system
with not a single test case for it (at least one that is available to
me). The existing one was tested heavily by others, and I know it works.
If I recompile a new version, I have NO idea whether it compiled
correctly or not. It took about a year to squeeze all the bugs out of
the existing one.
STLport is different, because that comes with a test suite. I can
recompile it, run the test suite, and I know it works.
Walter Bright wrote:
Bill Baxter wrote:
Yep. Thanks for sharing your experience. I'm a researcher, so while
I've been at this for coding thing for 20 years too, I don't tend to
play around with a lot of million-line code bases written by
million-monkey junior programmers. I did do a short stint for a big,
well-known software company once, and got my taste of million-monkey
code, though. Scary stuff. They wanted me to modify some crufty
parser to do some new tricks when there were absolutely no unit tests
or example programs or even documentation to show me what it was
supposed to be doing in the first place. I'm amazed now that they
didn't tell me to "figure out this mess and document it first, writes
some unit tests, then add feature X" but instead they just wanted me
to jump right in and throw more gasoline into the fire. Yikes.
Microsoft once asked me why I didn't update the MFC library that comes
with DMC++. I said the problem was that MFC is a large complex system
with not a single test case for it (at least one that is available to
me). The existing one was tested heavily by others, and I know it works.
If I recompile a new version, I have NO idea whether it compiled
correctly or not. It took about a year to squeeze all the bugs out of
the existing one.
STLport is different, because that comes with a test suite. I can
recompile it, run the test suite, and I know it works.
To be fair, you know the features that the test cover work :-) But the
point remains. With this in mind, why does contract checking still not
support inheritance as described in the spec? Contracts are one feature
that originally drew me to D and it's a shame that they're only half
implemented.
Sean
Sean Kelly wrote:
To be fair, you know the features that the test cover work :-) But the
point remains. With this in mind, why does contract checking still not
support inheritance as described in the spec? Contracts are one feature
that originally drew me to D and it's a shame that they're only half
implemented.
Because the contracts haven't drawn the interest that the other features
of D did that also needed work.
Walter Bright wrote:
Sean Kelly wrote:
To be fair, you know the features that the test cover work :-) But
the point remains. With this in mind, why does contract checking
still not support inheritance as described in the spec? Contracts are
one feature that originally drew me to D and it's a shame that they're
only half implemented.
Because the contracts haven't drawn the interest that the other features
of D did that also needed work.
Seems I'm always in the minority :-)
Sean
On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:
Walter Bright wrote:
Sean Kelly wrote:
To be fair, you know the features that the test cover work :-) But the
point remains. With this in mind, why does contract checking still not
support inheritance as described in the spec? Contracts are one
feature that originally drew me to D and it's a shame that they're only
half implemented.
Because the contracts haven't drawn the interest that the other
features of D did that also needed work.
Seems I'm always in the minority :-)
Sean
For what is worth, I also like contracts :)
Fawzi
Fawzi Mohamed <fmohamed mac.com> wrote:
On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:
Walter Bright wrote:
Sean Kelly wrote:
To be fair, you know the features that the test cover work :-) But
the point remains. With this in mind, why does contract checking
still not support inheritance as described in the spec? Contracts
are one feature that originally drew me to D and it's a shame that
they're only half implemented.
Because the contracts haven't drawn the interest that the other
features of D did that also needed work.
Seems I'm always in the minority :-)
Sean
For what is worth, I also like contracts :)
Fawzi
Thirded.
-- Simen
Simen Kjaeraas wrote:
Fawzi Mohamed <fmohamed mac.com> wrote:
On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:
Walter Bright wrote:
Sean Kelly wrote:
To be fair, you know the features that the test cover work :-) But
the point remains. With this in mind, why does contract checking
still not support inheritance as described in the spec? Contracts
are one feature that originally drew me to D and it's a shame that
they're only half implemented.
Because the contracts haven't drawn the interest that the other
features of D did that also needed work.
Seems I'm always in the minority :-)
Sean
For what is worth, I also like contracts :)
Fawzi
Thirded.
-- Simen
Fourthed.
--
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Lars Ivar Igesund Wrote:
Simen Kjaeraas wrote:
Fawzi Mohamed <fmohamed mac.com> wrote:
On 2008-07-24 07:43:55 +0200, Sean Kelly <sean invisibleduck.org> said:
Walter Bright wrote:
Sean Kelly wrote:
To be fair, you know the features that the test cover work :-) But
the point remains. With this in mind, why does contract checking
still not support inheritance as described in the spec? Contracts
are one feature that originally drew me to D and it's a shame that
they're only half implemented.
Because the contracts haven't drawn the interest that the other
features of D did that also needed work.
Seems I'm always in the minority :-)
Sean
For what is worth, I also like contracts :)
Fawzi
Thirded.
-- Simen
Fourthed.
contracts are like gym memberships. most people agree they're good. many
actively want them. few actually use them.
i wasted a couple of hours of my miserable life reading "design by contract,
explained". what a heap of shit that book is. the moron defines a stack. not
even generic. a stack holding int. by the time he was done adding contracts to
it, the poor stack looked like an old hooker after a gangbang.
that being said, shit walter. didn't they teach you in school you either do
shit well or not at all. either dump contracts or make them specifiable in
interfaces. if that were the case by holy guacamole i'd use them. interfaces
with contracts are about the only sensible, palatable use of contracts. why?
because the only interesting shit happens when contract is separated from body.
you specify some shit in a contract then force someone *else* to abide from it.
contracts with body are a bit like writing a promise to yourself. (save for
inheritance but i bored myself talking already.)
On Thu, 24 Jul 2008 06:59:05 -0700, superdan <super dan.org> wrote:
Lars Ivar Igesund Wrote:
Simen Kjaeraas wrote:
Fawzi Mohamed <fmohamed mac.com> wrote:
Sean Kelly <sean invisibleduck.org> said:
Sean Kelly wrote:
...why does contract checking
still not support inheritance as described in the spec?
Walter Bright wrote:
Because the contracts haven't drawn the interest that the other
features of D did that also needed work.
Fawzi> For what is worth, I also like contracts :)
Simen> Thirded.
Lars Ivar> Fourthed.
contracts are like gym memberships. most people agree they're good. many
actively want them. few actually use them.
But we few rely on them utterly. And inheritance makes them much easier to
use:
if the author of an interface or base class has been careful to write good
contracts,
subclasses don't HAVE to write contracts, and they gain their benefits
anyway.
(Pretty much what you were saying, Superdan, ne?)
I do sympathize with Atlas^H^H^H^H^HWalter carrying the weight of an
entire new
language on his shoulders, and he has to pick and choose what issues are
important.
But in my opinion, this is one.
The biggest mistake most programmers make with contracts -- or simple
asserts, for
that matter -- is not to use them.
-- Dai
Sean Kelly and others:
For what is worth, I also like contracts :)
I too like them. At the moment in D I expecially like class contracts used as
invariants. So I'd like to see the compiler manage contracts in a smarter way.
Bye,
bearophile
On Thu, 24 Jul 2008 11:30:35 +0100, bearophile <bearophileHUGS lycos.com>
wrote:
Sean Kelly and others:
For what is worth, I also like contracts :)
I too like them. At the moment in D I expecially like class contracts
used as invariants. So I'd like to see the compiler manage contracts in
a smarter way.
Bye,
bearophile
I don't normally approve of me tooing. It wastes bandwidth. But on the off
chance it
has any persuasive power at all. Me too.
I use them extensively at work where I'm forced to use C++. They are
documented using
Doxygen and are used heavily to write the first set of unit tests. When
fixing up legacy
code one of the first things I look for are the pre-conditions the
post-conditions and
the invariants. These get documented. Then they get tested. This
immediately picks up a lot
of otherwise subtle and evil bugs. And the whole code base moves forward.
They also help to expose when you have functions doing too much. If the
post conditions
become ridiculously complicated then its a fair bet the code has two and
would benefit from
some re-factoring. Maybe not a silver bullet but one of the more important
tools in the arsenal.
The pairing of contracts and unit tests was one of the first things that
interested me in D.
They deserve more attention. After all writing code is easy. Its writing
clean correct code
that takes more effort.
Regards,
Bruce.
superdan wrote:
yeah and that will be documented in pure vs. impure functions and in
invariant vs. const/mutable data. this is great. d is not a
convention-based language like c++.
That is a point worth emphasizing. There are two phases to learning C++:
1. learn the language
2. learn the myriad of conventions that have built up over the years to
ward off all the trouble (Scott Meyer's "Effective C++" series is an
example)
D tries to codify a lot of those conventions into the language, so the
language can actually help you get it right. The const/invariant/pure is
a huge step in that direction. My understanding is that much of peoples'
difficulties with D's const system are the compiler catching attempts to
subvert the const system. These are possible in C++ because const is a
convention, but on the other hand people have terrible problems getting
their multithreaded code to work properly in C++.
Just look at all Herb Sutter's and Scott Meyer's articles on
multithreaded C++ programming where code that looks like it should work
and does compile and work most of the time, but is fundamentally broken.
Language enforcement and guarantees are desperately needed.
i like messing with cars. i have an
amazing 18V drill that i use for a ton of stuff - screws, bolts,
holes, adjustments, rust removal, you name it. does that mean i'm
only trying to use that tool for everything? sure not. but that
doesn't make it less loveable.
Me, I've never discovered a problem with my car that couldn't be solved
with a hammer and a torch.
Reply to Walter,
Me, I've never discovered a problem with my car that couldn't be
solved with a hammer and a torch.
if you have good insurance, you never will /j
OTOH:
Duct tape and WD-40: if it moves and it shouldn't, use the duct tape, if
it should move and doesn't, use the WD-40.
BCS wrote:
Reply to Walter,
Me, I've never discovered a problem with my car that couldn't be
solved with a hammer and a torch.
if you have good insurance, you never will /j
OTOH: Duct tape and WD-40: if it moves and it shouldn't, use the duct
tape, if it should move and doesn't, use the WD-40.
Strangely enough, duct tape is great except in instances where heat is
involved... such as with heating ducts. Makes one wonder where the name
came from :-)
Sean
Reply to Sean,
BCS wrote:
Reply to Walter,
Me, I've never discovered a problem with my car that couldn't be
solved with a hammer and a torch.
if you have good insurance, you never will /j
OTOH: Duct tape and WD-40: if it moves and it shouldn't, use the duct
tape, if it should move and doesn't, use the WD-40.
Strangely enough, duct tape is great except in instances where heat is
involved... such as with heating ducts. Makes one wonder where the
name came from :-)
Sean
IIRC duct cloth
Sean Kelly wrote:
<snip>
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem
having it is a deal breaker for me." Customer Sue says: "I'd buy the
that." And so on. Feature creep is the result of inexorable and
unrelenting pressure for them.
I'd say that the word processor should be modular and that the requested
features should be sold as plug-ins. Then customer A gets his lean mean
word processor with exactly the features he wants, and the same for
customers B and C. This obviously isn't possible with a language
however, so I'm inclined to say that this is a false analogy.
Sean
I agree with most everything you wrote.
specifically, "I would personally rather have a set of specialized tools
than one tool which can do everything but isn't really ideal for
anything." makes a lot of sense to me.
however, I just want to point out that modular languages are possible.
depending on what level of modularity you want.
1) common run-time for several languages like .net and JVM.
2) language oriented programming where you define a DSL for your problem
domain and use that to solve the problem. so your project is constructed
from several DSLs definitions and code written in those DSLs.
look for MPS by Jetbrains for an implementation of such a system.
3) the language itself can be modular - you can either allow the
programmer to define functions as new operators in the language (Scala
does that). so downs for instance could use such a feature to implement
his functional code without all the mixin/templates magic required by D.
Or even more powerful: language extensions via AST macros, *including*
syntax extensions defined by the user.
see: http://nemerle.org/Syntax_extensions for a language that allows the
programmer to add new syntax to the language (thus a modular language)
Walter Bright Wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it tend
to be a mess.
I agree that diverse paradigm support can lead to a mess.
that's like agreeing that ice cream consumption can lead to auto theft. what a
heap of bullshit that is.
correlation is not causation. if we go by any reasonable train of thought, we'd
see that c++ being multiparadigm is an advantage not an issue. people have
written articles and books about how cool that is. they haven't written
articles and books about what is sinking c++: the fucking syntax (bjarne is ok
at a high level but he can't design syntax to save his life from a tribe of
fucking horny and hungry gay cannibals); the shittiest exception model in the
history of humankind (statically specified but dynamically-checked... worst of
all worlds... what the fuck were they thinking about? shit); useless namespaces
(what a useless pile of pigshit that whole feature is... and they can't even
blame it to C... it was designed from scratch!); the template subsystem that is
too much heat and smoke for the light; and a fucking million minor wounds,
starting with "class" vs. "struct" shit and ending with copying at the drop of
a hat.
On the other
hand, to be a mainstream language I think one must support diverse
paradigms because programmers are diverse. Additionally, nobody really
knows yet which horse is the right one to back for multicore
programming, but functional certainly is a favorite.
absolutely.
I disagree that using multiple languages for one project is a good idea,
unless one language is hosted by the other (like emacs/elisp). Trying to
get two languages produced by different vendors to consistently work
together across platforms and differing upgrade schedules can be a
prescription for a lot of extra work. Is learning two different
languages really easier than learning two different paradigms in the
same language?
looks like you haven't used unix much. a large project, even when developed by
competent programmers acting on their free will, will inevitably use at least a
few dsls (make, shell) in addition to one or more mainstream languages. why?
because it's the best way. a n00b shouts foul when seeing a 5000 lines makefile
or shell config or whatever. but they forget that manages a project that's a
thousand times larger.
Regarding the D mixed functional / imperative approach, another issue I
have with it is that it's exactly the reverse of the Erlang / C model.
While Erlang / C is functional for control structures and imperative for
optimization points, D looks like it will be imperative for control and
functional for optimization. Plus, I really like the concurrency model
in Erlang.
A side note: Everyone complains about feature bloat in Microsoft Word.
What the world needs is a lean, mean word processor. But the problem is,
it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
And so on. Feature creep is the result of inexorable and unrelenting
pressure for them.
as can be seen on this newsgroup.
superdan wrote:
Walter Bright Wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it tend
to be a mess.
I agree that diverse paradigm support can lead to a mess.
that's like agreeing that ice cream consumption can lead to auto theft. what a
heap of bullshit that is.
correlation is not causation. if we go by any reasonable train of thought,
we'd see that c++ being multiparadigm is an advantage not an issue. people have
written articles and books about how cool that is. they haven't written
articles and books about what is sinking c++: the fucking syntax (bjarne is ok
at a high level but he can't design syntax to save his life from a tribe of
fucking horny and hungry gay cannibals); the shittiest exception model in the
history of humankind (statically specified but dynamically-checked... worst of
all worlds... what the fuck were they thinking about? shit); useless namespaces
(what a useless pile of pigshit that whole feature is... and they can't even
blame it to C... it was designed from scratch!); the template subsystem that is
too much heat and smoke for the light; and a fucking million minor wounds,
starting with "class" vs. "struct" shit and ending with copying at the drop of
a hat.
Fair enough. D supports all the same paradigms as C++ and yet I
wouldn't say that it tends to produce unmaintainable code, so I agree
that a lot of it does really come down to syntax. But it can still be
difficult to maintain a consistent API when part of the team wants to
use structs and free functions, another part wants an object hierarchy,
and yet another wants templates. Tango has run into this a bit because
of the varying programming styles of the people involved as well as
feedback from users (some want objects, some don't, etc). The result is
still far better and more maintainable than C++, but I think some of the
same issues exist.
Sean
Sean Kelly Wrote:
superdan wrote:
Walter Bright Wrote:
Sean Kelly wrote:
Walter Bright wrote:
But, you said you didn't wish to mix functional and imperative
programming? I don't understand.
Not in the same language. One reason being the impact it will have on
managing projects in D. C++, for example, supports a sufficiently
diverse set of programming methodologies that large projects in it tend
to be a mess.
I agree that diverse paradigm support can lead to a mess.
that's like agreeing that ice cream consumption can lead to auto theft. what a
heap of bullshit that is.
correlation is not causation. if we go by any reasonable train of thought,
we'd see that c++ being multiparadigm is an advantage not an issue. people have
written articles and books about how cool that is. they haven't written
articles and books about what is sinking c++: the fucking syntax (bjarne is ok
at a high level but he can't design syntax to save his life from a tribe of
fucking horny and hungry gay cannibals); the shittiest exception model in the
history of humankind (statically specified but dynamically-checked... worst of
all worlds... what the fuck were they thinking about? shit); useless namespaces
(what a useless pile of pigshit that whole feature is... and they can't even
blame it to C... it was designed from scratch!); the template subsystem that is
too much heat and smoke for the light; and a fucking million minor wounds,
starting with "class" vs. "struct" shit and ending with copying at the drop of
a hat.
Fair enough. D supports all the same paradigms as C++ and yet I
wouldn't say that it tends to produce unmaintainable code, so I agree
that a lot of it does really come down to syntax. But it can still be
difficult to maintain a consistent API when part of the team wants to
use structs and free functions, another part wants an object hierarchy,
and yet another wants templates. Tango has run into this a bit because
of the varying programming styles of the people involved as well as
feedback from users (some want objects, some don't, etc). The result is
still far better and more maintainable than C++, but I think some of the
same issues exist.
agreed. lo and behold, there is agreement on the net. i must've died and made
it to heaven.
superdan wrote:
Walter Bright Wrote:
I agree that diverse paradigm support can lead to a mess.
that's like agreeing that ice cream consumption can lead to auto
theft. what a heap of bullshit that is.
Sometimes having too many different ways of doing the same thing is a
curse rather than a help. See my blog post on that at
http://dobbscodetalk.com/index.php?option=com_myblog&show=Language-Features-for-Management.html&Itemid=29
correlation is not causation. if we go by any reasonable train of
thought, we'd see that c++ being multiparadigm is an advantage not an
issue. people have written articles and books about how cool that is.
Oh, I agree, but it is also *can* be a problem. Like my Bronco, half the
bolts in it are metric and the other half are standard. There doesn't
even appear to be a discernible pattern as to which is which, I have to
keep two tool sets at hand when working on it.
they haven't written articles and books about what is sinking c++:
the fucking syntax (bjarne is ok at a high level but he can't design
syntax to save his life from a tribe of fucking horny and hungry gay
cannibals); the shittiest exception model in the history of humankind
(statically specified but dynamically-checked... worst of all
worlds... what the fuck were they thinking about? shit);
I was around for the debates when exceptions were designed for C++. The
reason for the mucked up design is that people at the time didn't know
any better. That's not an aspersion on the C++ designers, but the fact
was there wasn't much of any existing body of experience to draw upon.
Nobody knew then what the right way to do it was.
It's like the Wright Bros inventing wing warping. History has shown that
wing warping is a crappy solution (ailerons work much better), but
ailerons were a future invention, and the Wrights *did* find a solution
to the problem of lateral control in a time when nobody else had a clue.
There is no excuse, however, for the template < > syntax because it was
well known at the time what the problems with it would be, and those
predicted problems have plagued C++ ever since.
looks like you haven't used unix much. a large project, even when
developed by competent programmers acting on their free will, will
inevitably use at least a few dsls (make, shell) in addition to one
or more mainstream languages. why? because it's the best way. a n00b
shouts foul when seeing a 5000 lines makefile or shell config or
whatever. but they forget that manages a project that's a thousand
times larger.
The 5000 line makefile isn't bound into the resulting app, either.
A side note: Everyone complains about feature bloat in Microsoft
Word. What the world needs is a lean, mean word processor. But the
problem is, customer Bill says: "That's great, but I need feature
I do is based on that." And so on. Feature creep is the result of
inexorable and unrelenting pressure for them.
as can be seen on this newsgroup.
Everyone has a different idea of what features should be put in D. There
are proposals every day.
Walter Bright wrote:
superdan wrote:
Walter Bright Wrote:
I agree that diverse paradigm support can lead to a mess.
that's like agreeing that ice cream consumption can lead to auto
theft. what a heap of bullshit that is.
Sometimes having too many different ways of doing the same thing is a
curse rather than a help. See my blog post on that at
http://dobbscodetalk.com/index.php?option=com_myblog&show=Language-Features-for-Manag
ment.html&Itemid=29
Indeed. And that's one thing I like about Java, although Java is an
extreme case of such (as many people would agree, and even bash it
because of that).
--
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sean Kelly wrote:
I think part of the problem is that I simply don't agree with the mixed
functional / imperative approach that appears to be the overarching
direction of D.
No other language has tried such an approach before, and so we have yet
to know unequivocably if it is right or not. But I'm very optimistic
about it.
And while I do quite a bit of concurrent programming,
it's not in a way that will reap any benefit from this design. In fact, the
language features added to support it are more of an annoyance than
they are an aid. This may very well mean that D is simply not the
language for me in the long term. However, with C and C++ as the
only real alternatives for systems programming, there aren't many
other options available.
There are several different paradigms for concurrent programming. D
won't be forcing one paradigm on anyone, it's sort of like oop vs free
functions. They both work, and you can mix & match them as desired.
Walter Bright wrote:
Sean Kelly wrote:
I think part of the problem is that I simply don't agree with the mixed
functional / imperative approach that appears to be the overarching
direction of D.
No other language has tried such an approach before, and so we have yet
to know unequivocably if it is right or not. But I'm very optimistic
about it.
I'm hopeful, just not optimistic :-)
And while I do quite a bit of concurrent programming,
it's not in a way that will reap any benefit from this design. In
fact, the
language features added to support it are more of an annoyance than
they are an aid. This may very well mean that D is simply not the
language for me in the long term. However, with C and C++ as the
only real alternatives for systems programming, there aren't many
other options available.
There are several different paradigms for concurrent programming. D
won't be forcing one paradigm on anyone, it's sort of like oop vs free
functions. They both work, and you can mix & match them as desired.
See my other post regarding managing projects in C++.
Sean
On 2008-07-22 08:06:12 +0200, Sean Kelly <sean invisibleduck.org> said:
Walter Bright wrote:
Sean Kelly wrote:
I think part of the problem is that I simply don't agree with the mixed
functional / imperative approach that appears to be the overarching
direction of D.
No other language has tried such an approach before, and so we have yet
to know unequivocably if it is right or not. But I'm very optimistic
about it.
I'm hopeful, just not optimistic :-)
There are other attempts at multi-paradigm programming languages, it is
true that these are not system programming languages.
Mozart/Oz http://www.mozart-oz.org/
is an interesting attempt, and the book by Van Roy and Haridi that uses
it (Concepts, Techniques, and Models of Computer Programming)
http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695
is
a very interesting read.
And while I do quite a bit of concurrent programming,
it's not in a way that will reap any benefit from this design. In fact, the
language features added to support it are more of an annoyance than
they are an aid. This may very well mean that D is simply not the
language for me in the long term. However, with C and C++ as the
only real alternatives for systems programming, there aren't many
other options available.
I tried to work in a mixed language approach (python/C) and my
productivity went down, I even missed fortran!
I think that when you have a fixed interface or a clear problem then it
might be ok, but if you are developing in place where it is not so
obvious where to cut things, and you switch implementation, and the
"reference" implementation in the high level language is so unbearably
slow that you cannot really use it even as test in the complex case, it
becomes messy, and you loose a lot of time.
I have only slightly brushed erlang, I didn't make any large scale
projects with it, but I suspect the issues are similar.
So I like very much the idea of a multi-paradigm language, if done
well, and I like the idea of having a functional kernel in the language.
Functional languages have to work harder to bring back some of the
expression power, and the result is that they work very well when
combining simpler building blocks, and are a real boon at high level,
but I do not belive in "automatic" parallelization through it.
Parallelization comes from the use of parallel constructs, and there are
There are several different paradigms for concurrent programming. D
won't be forcing one paradigm on anyone, it's sort of like oop vs free
functions. They both work, and you can mix & match them as desired.
See my other post regarding managing projects in C++.
Yes having multiple paradigms can be a mess especially if the
programming language is not clean and does not try to be as compact as
possible and also know when to give up a little performance this is non
obvious, but, I think, possible (I did large projects in C++, and I
think the problem was not mutiparadigm per se, but how it is presented
also due to legacy issues, and the unwillingness to make some clear
choices).
Also many of the things one might want can be very well implemented in
libraries, and should be done like that.
I have enough discipline to choose the right approach, I definitely
want a language that support this, and it is one of the reasons I came
to D, I think that with some work, it might support all that I want,
which is templates, multithreading, so that I can set up my generic
work distributing schemes, MPI if available, and Erlang actor model
(which I think will become more and more important, and should be used
when possible).
Fawzi
rm
Parallelization comes from the use of parallel constructs, and there are
just a bit of sentece that stayed there...
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
Sean Kelly wrote:
And while I do quite a bit of concurrent programming,
it's not in a way that will reap any benefit from this design. In fact, the
language features added to support it are more of an annoyance than
they are an aid. This may very well mean that D is simply not the
language for me in the long term. However, with C and C++ as the
only real alternatives for systems programming, there aren't many
other options available.
There are several different paradigms for concurrent programming. D
won't be forcing one paradigm on anyone, it's sort of like oop vs free
functions. They both work, and you can mix & match them as desired.
I for one like the idea of a multiparadigm language. First of all, mixing
languages is usually at least somewhat of a pain, so the desire to avoid this
is
understandable.
At its lowest level(assembly language) all programming is basically imperative.
A
fundamental rule in designing just about any system is to avoid abstraction
inversion, or the re-implementing of low-level concepts on top of high-level
concepts. See http://en.wikipedia.org/wiki/Abstraction_inversion. This pretty
much means, IMHO, that any properly designed programming language must have
decent
support for basic imperative programming.
This leaves functional programming and OOP. I think we can all agree that some
concepts (such as GUIs) are more naturally expressed in OOP and others (such as
mathematical functions) are more naturally expressed in a functional paradigm.
Therefore, a complete language should support both, and a complete programmer
should be familiar with both.
dsimcha wrote:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
Sean Kelly wrote:
And while I do quite a bit of concurrent programming,
it's not in a way that will reap any benefit from this design. In fact, the
language features added to support it are more of an annoyance than
they are an aid. This may very well mean that D is simply not the
language for me in the long term. However, with C and C++ as the
only real alternatives for systems programming, there aren't many
other options available.
There are several different paradigms for concurrent programming. D
won't be forcing one paradigm on anyone, it's sort of like oop vs free
functions. They both work, and you can mix & match them as desired.
I for one like the idea of a multiparadigm language. First of all, mixing
languages is usually at least somewhat of a pain, so the desire to avoid this
is
understandable.
Agreed. For a while I was thinking I would do my work in Python for the
high level with D for the low level. But debugging mixed-language
projects like that is a pain. With Python basically you kill
performance any time you stick in a loop over a large number of
elements. So the granularity at which you start wanting to delegate to
the fast language becomes very high. To me it seemed easier to just do
things all in D in the end, and thereby never have to worry whether a
loop was going to kill my performance.
This leaves functional programming and OOP. I think we can all agree that some
concepts (such as GUIs) are more naturally expressed in OOP and others (such as
mathematical functions) are more naturally expressed in a functional paradigm.
Well the IMGUI people might argue with you there.
https://mollyrocket.com/forums/viewtopic.php?t=134&sid=fbeef82ffb9f71fe6637a7f499903841
Therefore, a complete language should support both, and a complete programmer
should be familiar with both.
But I agree with you anyway. Lisp advocates, on the other hand, would
probably say here that you can do OOP in Lisp (and they'd probably add
that it is 10x better than the OOP in C++ for some reason or other, and
that they had the problem solved in the 70's before anyone even had a
word for it.)
--bb
Sean Kelly wrote:
I think part of the problem is that I simply don't agree with the mixed
functional / imperative approach that appears to be the overarching
direction of D.
Walter Bright replied:
No other language has tried such an approach before, and so we have yet
to know unequivocably if it is right or not. But I'm very optimistic
about it.
Ever heard of Objective Caml?
Not to be mean, but I guess it was there (and mixing functional, oop and
imperative) first. Basically, I'd said functional programming in OCaml is
*very* elegant and powerful, their use of functional instructions is a bit
clumsy, and their oop is mostly unusable (mainly because they constantly
"patch" their programming languages with new features, basically, each time
there's a PhD student trying to work on functionnal programming .. )
Try to have a look at their way of mixing all this, if you haven't done that
yet.. ?
maelp wrote:
Sean Kelly wrote:
I think part of the problem is that I simply don't agree with the mixed
functional / imperative approach that appears to be the overarching
direction of D.
Walter Bright replied:
No other language has tried such an approach before, and so we have yet
to know unequivocably if it is right or not. But I'm very optimistic
about it.
Ever heard of Objective Caml?
Not to be mean, but I guess it was there (and mixing functional, oop and
imperative) first. Basically, I'd said functional programming in OCaml is
*very* elegant and powerful, their use of functional instructions is a bit
clumsy, and their oop is mostly unusable (mainly because they constantly
"patch" their programming languages with new features, basically, each time
there's a PhD student trying to work on functionnal programming .. )
Try to have a look at their way of mixing all this, if you haven't done that
yet.. ?
That's not the same approach at all. It's more like the opposite
approach -- grafting a procedural sublanguage on top of a functional
language rather than what D is doing, putting a functional subset atop a
procedural base.
I believe Walter's premise is that most of the time people are more
comfortable working in a procedural/oo style. But for certain tasks a
functional approach is better. I agree. I tried to use OCaml. It
sounds great on paper, and I had heard Chris Hecker singing its praises
once, but like you said "their oop is mostly unusable". I figured it
might eventually make sense and not seem so clumsy if I spent enough
time with it, but then there was D sitting there saying "halloo! no
troubles with my oo or procedural style here! You can get going right
away with no steep learning curve!" So I went with D in the end. But I
seriously had decided at one point that I was going to make OCaml my C++
replacer. And then I sat down to see how I would write a simple model
viewer or something and was just stuck for days trying to figure out how
to begin to get anything up on the screen. And the library situation
didn't seem to be particularly good either, at least for Windows IIRC.
So basically, I think D's approach is quite different from OCaml's, and
more likely to succeed.
--bb
maelp wrote:
Sean Kelly wrote:
I think part of the problem is that I simply don't agree with the
mixed functional / imperative approach that appears to be the
overarching direction of D.
Walter Bright replied:
No other language has tried such an approach before, and so we have
yet to know unequivocably if it is right or not. But I'm very
optimistic about it.
Ever heard of Objective Caml?
Yes, but I know nothing about it.
Not to be mean, but I guess it was there (and mixing functional, oop
and imperative) first. Basically, I'd said functional programming in
OCaml is *very* elegant and powerful, their use of functional
instructions is a bit clumsy, and their oop is mostly unusable
(mainly because they constantly "patch" their programming languages
with new features, basically, each time there's a PhD student trying
to work on functionnal programming .. )
Try to have a look at their way of mixing all this, if you haven't
done that yet.. ?
maelp Wrote:
their use of functional instructions is a bit clumsy
I meant of course, "use of imperative instructions"
== Quote from bearophile (bearophileHUGS lycos.co)'s article
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't seem
among the list of the next things
planned as improvements/changes for the D/DMD. I don't know what this means.
Are people asking for
unimportant things? Are the D designers smarter? Are the two groups ignoring
each other?
For better or worse, I don't personally feel that the D designers listen to
the D community
at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's
just that my goals
with D simply diverged beginning with 2.0.
wut the heck is ur problem sean, u were the only sane guy left at tango. now u
r coming with badmouthing n shit.
recently u were like "walter is trying 2 lure people to d2. if that happens,
i'm out." where the fuck did that conspiracy
theory come from. walter never did anything to put his integrity into question.
I was bothered by the fact that some issues that many people consider bugs in
D 1.0 are only
being fixed in D 2.0, and I ignored my better judgement and shot my mouth off.
It was a
mistake.
u r a good man sean and this proves it again.
now wuts with this walter doesn't listen shit. whining baby. i'm sayin':
walter does listen and does do great shit, the
only problem is that most of us don't know what we're talking about and can't
remember what we want from 1 moment 2
the next.
No offense, but um... speak for yourself. There are quite a few people here
who are very
talented and whose comments are not only consistent, but very well considered
and quite
well reasoned.
of course my statement needs qualification. u, steve, janice, bill, bearophile,
dee and few others know their shit. and best of all they know what they don't
know. but for majority of the rest, i'll take a fucking break. look at the
reply from "me here". absofuckinglutely typical: overconfident, boastful, knows
what's best for the fucking humankind better than fucking superman and fucking
spiderman combined with batman thrown in as a freebie. the dood knows a little
shit which only makes matters worse because that makes him think he knows
everything. as far as that dood is concerned he has taken care of threading. in
his world everything is trivially parallelizable. fuck. if half of what dood
says is true, the fellas racking their brains at
http://view.eecs.berkeley.edu/wiki/Main_Page and all over the fucking universe
could go home. and that dood could go collect his fucking turing award.
as an aside. he says functional is lame. but then i mean look at fucking
haskell. it is designed to only have one user, and that with a thick manual by
his side, to participate in obfuscated programming contests. yet wherever i
turn nowadays, everybody and their fucking bellydancer with transparent
stilettos is using haskell. why? well because threading shit has hit the fan
and haskell is a handkerchief. and don't get me started on fucking erlang. look
at its strings. lists with fucking 16 bytes per character. not even utf
compatible. fuck. those guys thought there's not much use for strings in a
fucking telephone relay haven't they. yet, fuck me but amazon uses fucking
erlang. now d is poised better coz it is imperative and functional so u use
what is best for each part of the app. of course that dood royally misses all
that point.
But Walter has said himself that he has difficulty working with people in
other than a face to face setting and it shows. Back when Andrei was still
posting here
someone asked what one should do to have a proposal considered or at least
garner a
response and the process was laid out very clearly. Since then, quite a few
people have
followed that process exactly and I can't remember any of the proposals
getting a comment
from either Walter or Andrei.
now what the fuck is that dood's problem. somebody tell him swallow his fucking
russian pride and haul his ass over here. but then what's he gonna do. argue
shit with "me here" and other "doods here". contrary 2 u i think this is a
problem, not a good thing: every single mofo here has 1 opinion and feels
entitled to a response. but if walter takes time to explain every mofo why
they're wrong, that's a fucking full time job right there. there is no
filtering of value. and i dunno what the fuck is with this group. the less they
know the more they think they know and the more entitled they come. like coz
they're stupid they paid a tax to use d or shit.
If a tree falls in the forest and there's no one around to hear
it, does it make a sound? And if a proposal is posted and it doesn't get a
single response,
has anyone read it? I know it's difficult to keep up with the posts in this
NG and impossible
to actually act on all of them, but even a "thanks" goes an incredibly long
way in terms of
making people feel like their comments matter.
wonder if "thanks 4 nothing, mofo" would qualify. coz that's closer 2 truth for
most so-called proposals.
look at that list. it's a pile of shit with the most prefuckingposterous
requests in the fucking history of fucking
programming languages. look at vectorization. who the fuck came with that sick
idea. hell, std.algorithm does that shit
better and nicer and didn't need language changes.
std.algorithm does vectorization? I had no idea. Don's BLADE (?) package
does though
and it's totally awesome and also didn't require language changes, so the
point is still
valid.
When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what
they wanted, they would have said a faster horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
It's an interesting question, and one I've been mulling over for a few years
now. My
understanding is that C++ was created as a very community-driven effort right
from the
start while D was designed based very much on what Walter thought would be
good in a
language. As a result, C++ ended up bogged down with a lot of legacy C
baggage that the
community insisted was necessary for them to adopt C++, while D could change
tracks on
the designer's whim and no one could say otherwise. Generally, I think the D
approach works
far better so long as the designer's goals match the interests of the
community, but it's a
pretty risky path to follow since the designer is basically betting the farm
on the hope that the
community will agree with his vision. In the past I've been pretty free with
my opinions about
language features and I do this because I don't want to feel that I didn't try
to make myself
heard if I ever give up on D. At least then I can feel that I did my best to
communicate to the
designers what's important to me as a user of the language.
u r wrong. bjarne has had control of language long time b4 it became
successful. it's his vision 4 better or worse. u r
looking at the success years of c++ when committees and crap came all over.
don't panic when d will be successful with
muggles there will be a committee over it like a cheap suit.
I suggest reading "The Design and Evolution of C++" if you haven't already.
It's pretty clear that
Bjarne validated much of C++ by asking influential C users about its features.
yeah read it. good book. the bulk was bjarne's. the diff from d is that c++ got
famous faster because every1 was ripe for it. nowadays market's tighter.
so wut is that stuff u want in d. u haven't even tried d2 so it loox like u r
interested more in bitchin' than in making real
suggestions. now seriously. speak up. what is it that u as a member of the
community wanna say and walter doesn't
listen.
I've tried D2. I've read the spec as well. I simply don't like it. As for
my suggestions, feel free
to use the search feature in the digitalmars.com website, because many are
here in this forum
or D.announce. But you do have a point in that I have become quite weary of
the D drama in
general. I simply don't have the enthusiasm I used to, and that's entirely my
own fault. This
has been the longest I've ever worked on a personal programming project (at a
guess, 4-5
years on Tango/Ares?) and I feel I've accomplished what I set out to do here,
and that should
be enough. I'll be better in the future about posting when I've had a bad
day. My apologies.
better days will come that's 4 sure. thanx 4 sharing.
superdan Wrote:
of course my statement needs qualification. u, steve, janice, bill,
bearophile, dee and few others know their shit.
meant to add don here 2, sorry. probably in the first slot 2.
Reply to Sean,
Back when Andrei was still posting here
someone asked what one should do to have a proposal considered or at
least garner a
response
<div class=joke>
I remember a thread that, in jest, suggested that the best way to get a
proposal
into consideration involved... Beer.
</div>
on a slightly different topic:
If Brad can't get enought people for 2 days of talks for the '08 confrence,
maybe we should just go with a single day of talks and then 2 days of
"chatting".
If I can afford to, I'd love to hang around for that.
superdan wrote:
Sean Kelly Wrote:
== Quote from bearophile (bearophileHUGS lycos.co)'s article
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't seem
among the list of the next things
planned as improvements/changes for the D/DMD. I don't know what this means.
Are people asking for
unimportant things? Are the D designers smarter? Are the two groups ignoring
each other?
For better or worse, I don't personally feel that the D designers listen to
the D community
at all. Certainly not since D 2.0 was started at any rate. Or perhaps it's
just that my goals
with D simply diverged beginning with 2.0.
wut the heck is ur problem sean, u were the only sane guy left at tango. now u
r coming with badmouthing n shit. recently u were like "walter is trying 2 lure
people to d2. if that happens, i'm out." where the fuck did that conspiracy
theory come from. walter never did anything to put his integrity into question.
now wuts with this walter doesn't listen shit. whining baby. i'm sayin':
walter does listen and does do great shit, the only problem is that most of us
don't know what we're talking about and can't remember what we want from 1
moment 2 the next. look at that list. it's a pile of shit with the most
prefuckingposterous requests in the fucking history of fucking programming
languages. look at vectorization. who the fuck came with that sick idea. hell,
std.algorithm does that shit better and nicer and didn't need language changes.
the list is a joke. it's not even maintained, d has had tuples for months now.
somehow we want progress, n new shit n all but no we want it in d1 backward
compatible and with only two extra pieces of shit that vary from 1 person 2 the
next and from 1 minute 2 the next. shit.
if walter were 2 implement all the shitty "features" in the motherfucking list
the language would become a fucking pile of dung the size of fucking china.
what the fuck. walter is cranking great shit like it's goin' outta style and we
throw a fit because we didn't think of it first. we only thought of shitty
misfeatures like short syntax for new. now what was that mofo's problem. shit.
The list is definitely a farce. I think most everyone stopped paying
attention to it long ago. I'm not sure why it still gets posted here.
A cron job somewhere?
When I think about such matters I remember a quote, usually attributed to
Henry Ford: "If I'd asked people what
they wanted, they would have said a faster horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
That's a great quote! I definitely think Walter believes he's working
on the car. But Henry Ford also said:
"Mark my words: A combination airplane and motorcar is coming. You may
smile. But it will come." (http://en.wikiquote.org/wiki/Henry_Ford)
That sounds to me like he was thinking "in our lifetime". Well it
hasn't come yet, at least not in a way that I think would have satisfied
Ford.
It may be that Walter's working on that flying car.
But I certainly don't claim to know which D will turn out to be -- the
very useful car, or the pie-in-the-sky-never-to-really-pan-out
combination airplane and motorcar.
--bb
On Tue, 01 Jul 2008 00:23:38 -0400, superdan wrote:
wut the heck is ur problem sean ... now wuts with this walter doesn't listen
shit.
whining baby.
ROTFLMAO!!!
And who ever said that the English language is dying!? It's evolving so
fast at times it's hard to keep up with.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Derek Parnell Wrote:
And who ever said that the English language is dying!? It's evolving so
fast at times it's hard to keep up with.
http://www.vumo.ru/humour/chan.php
Hello Sean,
== Quote from bearophile (bearophileHUGS lycos.co)'s article
4tuu4k002 sneakemail.com:
This is the monthly status for the unofficial d wish list:
...
It's curious to see that many or most of the top desired things don't
seem among the list of the next things
planned as improvements/changes for the D/DMD. I don't know what this
means. Are people asking for unimportant things? Are the D designers
smarter? Are the two groups ignoring each other?
For better or worse, I don't personally feel that the D designers
listen to the D community
at all. Certainly not since D 2.0 was started at any rate. Or
perhaps it's just that my goals
with D simply diverged beginning with 2.0.
When I think about such matters I remember a quote, usually
attributed to Henry Ford: "If I'd asked people what
they wanted, they would have said a faster horse."
So maybe D programmers want faster horses, while D developers are
inventing/providing cars :-) I don't know.
It's an interesting question, and one I've been mulling over for a few
years now. My
understanding is that C++ was created as a very community-driven
effort right from the
start while D was designed based very much on what Walter thought
would be good in a
language. As a result, C++ ended up bogged down with a lot of legacy
C baggage that the
community insisted was necessary for them to adopt C++, while D could
change tracks on
the designer's whim and no one could say otherwise. Generally, I
think the D approach works
far better so long as the designer's goals match the interests of the
community, but it's a
pretty risky path to follow since the designer is basically betting
the farm on the hope that the
community will agree with his vision. In the past I've been pretty
free with my opinions about
language features and I do this because I don't want to feel that I
didn't try to make myself
heard if I ever give up on D. At least then I can feel that I did my
best to communicate to the
designers what's important to me as a user of the language.
Sean
Hi Sean,
I agree with much of what you say. I have a few thoughts too (Dare I? :D).
D design has actually moved into a tightly controlled group, apparently
motivated
by the authors desire to avoid the C++ committe process: there is no way
to say this is a wrong approach (yet, it's a reactive one), although there
is often an apparent lack of communication from the D designers to the
community
at large (However, some might argue that the core designers did try to
participate
here only to be "tarred and feathered" by the community). Whether this is
better or worse (compared to C++) for the growth of the language is yet to
be seen. I don't expect this anti-committee style to work any better in
the long run than a pro-committee roadmap. But I could be wrong. Whether
benevolent dictatorship, oligarchy, or design-by-committee, the problems
related to language growth and design probably lie outside any one methodology
(although there's likely a pinch of truth in the reasonings against certain
methods).
The problem doesn't lie in just the language design, but perhaps also in
the organization and management of develpment -- as others have suggested
repeatedly -- in additon to various judgement calls on what will most benefit
the language's advancement in popularity. Should time be invested in pure
language design or in updates to aging toolsets (eg let's ditch omf format
and improve the win32 linker!), or in commitments to bug fixes? Naturally
a community is going to be very desirous of quality working toolsets and
simple installation. Meanwhile, a designer is going to be strongly tempted
to "improve" language features. Does the community know best in this regard?
This however is not the only problem:
There a quasi effort from the designer(s) to show some magnanimity to
alternative
libraries (eg Tango) without any apparent commitment to what such support
means for the future of D. The silence is deafening and tends to demotivate
a community almost as fast as any pro-D article can pump up the language
perception to the non-community public. This is a foggy spot for D's future
before the eyes of the community. Is it really possible to promote a language
based on two libraries with no evidence of interest, disinterest, or concern?
This has been somewhat of a puzzle to me as I've watched the divergent efforts
of the two libraries progress with ever more apparent impossible
reconciliation.
Why does this problem appear to continue to be ignored? Do the designers
believe that "what will happen will happen", and therefore, "waiting and
silence" is the only and inevitable solution? If so, it would at least be
nice to have this stated plainly so all could understand the "why" of D's
direction.
Another problem is the original effort to make the language appear community
driven; whether it is or not really isn't as important as being clear about
intentions to the community. I think we would all agree that this language
is not so community driven as we originally thought. Or, perhaps, it is better
to say that it once was and now is not. Some significant elements are
community
driven: like gdc and Tango and various libraries. But these remain
inextricably
dependent on the D design timeline and bug fixes (as well as vexed by the
same). And, even at that, Tango remains the most consistant community effort,
while most other community efforts are prone to lag.
Tango remains a solid example of a community-contributed process. This library
was an attempt to turn D into a community project in direct response to a
general Phobos' apathy (in terms of bug fixes and design progression). One
way to look at this is to realize that Tango might not have been here if
it weren't for Phobos' failure. On the other hand, perhaps we should consider
what kind of library D would have engendered if Phobos had been more community
driven from the start? From what I can see of Tango, it has amply proved
itself: hosts of community contributions and testings with clear directions
from a committed and talented core development team made Tango what it is
today. I think Tango found the right balance of receptiveness vs controls
for project management. (Tip of the hat to Kris, Lars, and Sean for managing
to get it so far)
And then there's Walter... Walter's D language design and compiler are examples
of incredible contribution and effort via a different style... what appears
to be an incredibly single-handed, brute-force operative method (with dogged
determination!). If only such talents could merge to make a more
organizationally
sound process for D /and/ it's standard library.
But in the end, the design of the language just becomes yet another ideological
struggle of one's opinion over another's. It's inevitably, mutually political
and sacred with or without a committee and is made more so as ideas collide
from our varied experience and perceptions of what feels right. Walter's
success with D is in largely due to his appeal to what we sense is wrong
in other languages; he has managed to excite us via our dissatisfaction
over past experiences (eg. Java and C++)... and that's a powerful form of
influence. That is where the success of D has come whether or not we've
agreed with his control structure along the way. The lead D designer has
chosen his oligarchy to advance that design, and the community acts as the
samplers of it; we are the measurement of potential language feature popularity
and usability. And so the process continues with the next language that
comes around. Indeed, the miracle is that such contributions can somehow
merge at all and that people /remain/ loyal to it.
But then... perhaps it's not so surprising after all. ;)
-JJR
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races and
do proper synchronization.
In the scenario described, the main thread initialises the array of data. Then,
non-overlapping slices of that are tioned out to N worker threads. Only one
thread ever modifies any given segment. When the worker threads are complete,
the 'results' are left in the original array available in its entirety only to
the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location (previously)
modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very well
documented by the OS writer or hardware manufacturers, then here's your chance
to get slashdotted (and diggited and redited etc. all concurrently) as the
discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers". geez.
superdan wrote:
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races and
do proper synchronization.
In the scenario described, the main thread initialises the array of data. Then,
non-overlapping slices of that are tioned out to N worker threads. Only one
thread ever modifies any given segment. When the worker threads are complete,
the 'results' are left in the original array available in its entirety only to
the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location (previously)
modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very well
documented by the OS writer or hardware manufacturers, then here's your chance
to get slashdotted (and diggited and redited etc. all concurrently) as the
discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers". geez.
I presume the discussion regards symmetric multiprocessing (SMP).
Cache coherency is a very important element of any SMP design. It
basically means that caches should be fully transparent, i.e. the
behavior should not change by the addition or removal of caches.
So the above scenario should never occur. If thread A writes something
prior to thread B reading it, B should never get the old value.
"Memory barriers" have nothing to do with cache consistency. A memory
barrier only prevents a single CPU thread from reordering load/store
instructions across that specific barrier.
--
Oskar
== Quote from Oskar Linde (oskar.lindeREM OVEgmail.com)'s article
superdan wrote:
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races and
do proper synchronization.
In the scenario described, the main thread initialises the array of data. Then,
non-overlapping slices of that are tioned out to N worker threads. Only one
thread ever modifies any given segment. When the worker threads are complete,
the 'results' are left in the original array available in its entirety only to
the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location (previously)
modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very well
documented by the OS writer or hardware manufacturers, then here's your chance
to get slashdotted (and diggited and redited etc. all concurrently) as the
discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers". geez.
I presume the discussion regards symmetric multiprocessing (SMP).
Cache coherency is a very important element of any SMP design. It
basically means that caches should be fully transparent, i.e. the
behavior should not change by the addition or removal of caches.
So the above scenario should never occur. If thread A writes something
prior to thread B reading it, B should never get the old value.
"Memory barriers" have nothing to do with cache consistency. A memory
barrier only prevents a single CPU thread from reordering load/store
instructions across that specific barrier.
Things get a bit weird once pipelining and out-of-order execution come
into the picture. Most modern CPUs are still quite good at making things
work as you'd expect, but some, like the Alpha, have an amazingly weak
memory model in terms of what they are allowed to do if you don't reign
them in. Most amazing about the Alpha is that it will even reorder
dependent loads by default, so some really crazy things can happen with
SMP if you aren't extremely careful. Lock-free programming on the x86
is dead simple compared to some other architectures.
Sean
Oskar Linde Wrote:
superdan wrote:
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races and
do proper synchronization.
In the scenario described, the main thread initialises the array of data. Then,
non-overlapping slices of that are tioned out to N worker threads. Only one
thread ever modifies any given segment. When the worker threads are complete,
the 'results' are left in the original array available in its entirety only to
the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location (previously)
modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very well
documented by the OS writer or hardware manufacturers, then here's your chance
to get slashdotted (and diggited and redited etc. all concurrently) as the
discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers". geez.
I presume the discussion regards symmetric multiprocessing (SMP).
Cache coherency is a very important element of any SMP design. It
basically means that caches should be fully transparent, i.e. the
behavior should not change by the addition or removal of caches.
you are perfectly correct... as of ten years ago. you are right in that cache
coherency protocols ensure the memory model is respected regardless of adding
or eliminating caches. (i should know coz i implemented a couple for a
simulator.) the problem is that the memory model has been aggressively changed
recently towards providing less and less implied ordering and requiring
programs to write explicit synchronization directives.
So the above scenario should never occur. If thread A writes something
prior to thread B reading it, B should never get the old value.
yeah the problem is it's hard to define what "prior" means.
"Memory barriers" have nothing to do with cache consistency. A memory
barrier only prevents a single CPU thread from reordering load/store
instructions across that specific barrier.
memory barriers strengthen the relaxed memory model that was pushed
aggressively by the need for faster caches.
superdan wrote:
Oskar Linde Wrote:
superdan wrote:
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races
and >>> do proper synchronization.
In the scenario described, the main thread initialises the array of
data. Then, >> non-overlapping slices of that are tioned out to N worker
threads. Only one >> thread ever modifies any given segment. When the
worker threads are complete, >> the 'results' are left in the original
array available in its entirety only to >> the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location
(previously) >> modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very
well >> documented by the OS writer or hardware manufacturers, then here's
your chance >> to get slashdotted (and diggited and redited etc. all
concurrently) as the >> discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers". geez.
I presume the discussion regards symmetric multiprocessing (SMP).
Cache coherency is a very important element of any SMP design. It
basically means that caches should be fully transparent, i.e. the
behavior should not change by the addition or removal of caches.
you are perfectly correct... as of ten years ago. you are right in that cache
coherency protocols ensure the memory model is respected regardless of adding
or eliminating caches. (i should know coz i implemented a couple for a
simulator.) the problem is that the memory model has been aggressively
changed recently towards providing less and less implied ordering and
requiring programs to write explicit synchronization directives.
So the above scenario should never occur. If thread A writes something
prior to thread B reading it, B should never get the old value.
yeah the problem is it's hard to define what "prior" means.
"Memory barriers" have nothing to do with cache consistency. A memory
barrier only prevents a single CPU thread from reordering load/store
instructions across that specific barrier.
memory barriers strengthen the relaxed memory model that was pushed
aggressively by the need for faster caches.
Since in the scenario I describe, Each thread or cpu is dealing with a single
section of memory. And each section of memory is being dealt with by a single
thread or cpu, the is effectively no shared state whilst the threads run, Hence
no possibility of cache inconsistancy due to pipeline reordering. Ie.
main thread populates a[ 0 .. 1000 ];
for thread 1 .. 10
spawn( thread, \a[ ((thread-1 ) *100 ) .. ((thread-1 + 100) * 100 ] );
main thread waits for all threads to terminate;
main thread does something with a[];
In any case, cache consistancy issues due to pipeline reordering do not survive
context switches, so the issue is a non-issue for the purposes of the
discussion at hand. Ie. threading
Pipelines cover single digit or low double digit runs of non-branching
instructsion at most. A context switch consists of hundreds if not thousands of
instructions on all but the most highly tuned of real-time kernels. This is a
very localised issue, for the compiler writer, not the application programmer
to worry about.
I know Walter *is* a compiler writer, but this is a complete red-herring in the
context of this discussion.
b.
--
== Quote from Me Here (p9e883002 sneakemail.com)'s article
superdan wrote:
Oskar Linde Wrote:
superdan wrote:
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races
and >>> do proper synchronization.
In the scenario described, the main thread initialises the array of
data. Then, >> non-overlapping slices of that are tioned out to N worker
threads. Only one >> thread ever modifies any given segment. When the
worker threads are complete, >> the 'results' are left in the original
array available in its entirety only to >> the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location
(previously) >> modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very
well >> documented by the OS writer or hardware manufacturers, then here's
your chance >> to get slashdotted (and diggited and redited etc. all
concurrently) as the >> discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers". geez.
I presume the discussion regards symmetric multiprocessing (SMP).
Cache coherency is a very important element of any SMP design. It
basically means that caches should be fully transparent, i.e. the
behavior should not change by the addition or removal of caches.
you are perfectly correct... as of ten years ago. you are right in that cache
coherency protocols ensure the memory model is respected regardless of adding
or eliminating caches. (i should know coz i implemented a couple for a
simulator.) the problem is that the memory model has been aggressively
changed recently towards providing less and less implied ordering and
requiring programs to write explicit synchronization directives.
So the above scenario should never occur. If thread A writes something
prior to thread B reading it, B should never get the old value.
yeah the problem is it's hard to define what "prior" means.
"Memory barriers" have nothing to do with cache consistency. A memory
barrier only prevents a single CPU thread from reordering load/store
instructions across that specific barrier.
memory barriers strengthen the relaxed memory model that was pushed
aggressively by the need for faster caches.
Since in the scenario I describe, Each thread or cpu is dealing with a single
section of memory. And each section of memory is being dealt with by a single
thread or cpu, the is effectively no shared state whilst the threads run, Hence
no possibility of cache inconsistancy due to pipeline reordering. Ie.
main thread populates a[ 0 .. 1000 ];
for thread 1 .. 10
spawn( thread, \a[ ((thread-1 ) *100 ) .. ((thread-1 + 100) * 100 ] );
main thread waits for all threads to terminate;
main thread does something with a[];
In any case, cache consistancy issues due to pipeline reordering do not survive
context switches, so the issue is a non-issue for the purposes of the
discussion at hand. Ie. threading
Multithreading with a single-CPU machine is always fairly safe and predictable
because all threads share the same cache, etc. Even most popular multicore
machines today are relatively safe because in most instances the cores share
at least the L2+ caches, sidestepping many typical SMP issues. But multiple
CPUs in a machine introduce an entirely new set of issues and it's these that
concurrent programmers must consider. For example, here's one fun issue
that can occur with PC, which is what the IA-32 (ie. x86) was thought to
follow:
x = y = 0;
// thread A
x = 1;
// thread B
if( x == 1 )
y = 1;
// thread B
if( y == 1 )
assert( x == 1 ); // may fail
The issue with PC described above is that while each CPU observes the actions
of another CPU in a specific order, all CPUs are not guaranteed to observe the
actions of other CPUs simultaneously. So it's possible that thread B may
observe
thread A's store of 1 to x before thread B sees the same store.
Fortunately, Intel has recently gotten a lot more proactive about facilitating
SMP,
and during the C++0x memory model discussions it was verified that the above
behavior will in fact not occur on current Intel architectures. But there are
a lot
of weird little issues like this that can lead to surprising behavior, even on
an
architecture with a fairly strong memory model.
Pipelines cover single digit or low double digit runs of non-branching
instructsion at most. A context switch consists of hundreds if not thousands of
instructions on all but the most highly tuned of real-time kernels. This is a
very localised issue, for the compiler writer, not the application programmer
to worry about.
I know Walter *is* a compiler writer, but this is a complete red-herring in the
context of this discussion.
As above, once there is more than one CPU in a box then one may no longer
rely on context switching to provide a convenient "quiescent state," so I think
that you're providing false assurances here.
Sean
Sean Kelly wrote:
== Quote from Me Here (p9e883002 sneakemail.com)'s article
superdan wrote:
Oskar Linde Wrote:
superdan wrote:
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data
races and >>> do proper synchronization.
In the scenario described, the main thread initialises the array of
data. Then, >> non-overlapping slices of that are tioned out to N worker
threads. Only one >> thread ever modifies any given segment. When the
worker threads are complete, >> the 'results' are left in the original
array available in its entirety only to >> the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware
L1/L2 >> caching that would allow one thread to read a memory location
(previously) >> modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very
well >> documented by the OS writer or hardware manufacturers, then
here's your chance >> to get slashdotted (and diggited and redited etc.
all concurrently) as the >> discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers".
geez.
I presume the discussion regards symmetric multiprocessing (SMP).
Cache coherency is a very important element of any SMP design. It
basically means that caches should be fully transparent, i.e. the
behavior should not change by the addition or removal of caches.
you are perfectly correct... as of ten years ago. you are right in that
cache coherency protocols ensure the memory model is respected regardless
of adding or eliminating caches. (i should know coz i implemented a
couple for a simulator.) the problem is that the memory model has been
aggressively changed recently towards providing less and less implied
ordering and requiring programs to write explicit synchronization
directives.
So the above scenario should never occur. If thread A writes something
prior to thread B reading it, B should never get the old value.
yeah the problem is it's hard to define what "prior" means.
"Memory barriers" have nothing to do with cache consistency. A memory
barrier only prevents a single CPU thread from reordering load/store
instructions across that specific barrier.
memory barriers strengthen the relaxed memory model that was pushed
aggressively by the need for faster caches.
Since in the scenario I describe, Each thread or cpu is dealing with a
single section of memory. And each section of memory is being dealt with by
a single thread or cpu, the is effectively no shared state whilst the
threads run, Hence no possibility of cache inconsistancy due to pipeline
reordering. Ie. main thread populates a[ 0 .. 1000 ];
for thread 1 .. 10
spawn( thread, \a[ ((thread-1 ) *100 ) .. ((thread-1 + 100) * 100 ] );
main thread waits for all threads to terminate;
main thread does something with a[];
In any case, cache consistancy issues due to pipeline reordering do not
survive context switches, so the issue is a non-issue for the purposes of
the discussion at hand. Ie. threading
Multithreading with a single-CPU machine is always fairly safe and predictable
because all threads share the same cache, etc. Even most popular multicore
machines today are relatively safe because in most instances the cores share
at least the L2+ caches, sidestepping many typical SMP issues. But multiple
CPUs in a machine introduce an entirely new set of issues and it's these that
concurrent programmers must consider. For example, here's one fun issue
that can occur with PC, which is what the IA-32 (ie. x86) was thought to
follow:
x = y = 0;
// thread A
x = 1;
// thread B
if( x == 1 )
y = 1;
// thread B
if( y == 1 )
assert( x == 1 ); // may fail
The issue with PC described above is that while each CPU observes the actions
of another CPU in a specific order, all CPUs are not guaranteed to observe the
actions of other CPUs simultaneously. So it's possible that thread B may
observe thread A's store of 1 to x before thread B sees the same store.
Fortunately, Intel has recently gotten a lot more proactive about
facilitating SMP, and during the C++0x memory model discussions it was
verified that the above behavior will in fact not occur on current Intel
architectures. But there are a lot of weird little issues like this that can
lead to surprising behavior, even on an architecture with a fairly strong
memory model.
Pipelines cover single digit or low double digit runs of non-branching
instructsion at most. A context switch consists of hundreds if not
thousands of instructions on all but the most highly tuned of real-time
kernels. This is a very localised issue, for the compiler writer, not the
application programmer to worry about.
I know Walter is a compiler writer, but this is a complete red-herring in
the context of this discussion.
As above, once there is more than one CPU in a box then one may no longer
rely on context switching to provide a convenient "quiescent state," so I
think that you're providing false assurances here.
Sean
Sean, I'm sorry, but *please* re-read everything I've posted o this subject.
Your x is (can be) accessed by two threads/cores/cpus concurrently.
*In the scenraio I described, this is not possible.*
Please do not feed more red herrings into this already complicated discussion.
,oO( Does anyone around here know how to stick to a single subject at a time?
Or maybe I'm typing German or Japanese and don't realise it? )
b.
--
Me Here wrote:
[...]
,oO( Does anyone around here know how to stick to a single subject
at a time?
[...]
It is a general communicational human habit not to stay on any focus
after some time has expired. The capability to stay on focus can be
changed by (mis-)education and (mis-)presentation(!).
Its a matter of luck to find someone who has similar capabilities for
diving into a deep concentration into the matters of the subject _and_
to communicate his thoughts without disrupting yours.
-manfred
Me Here Wrote:
superdan wrote:
Oskar Linde Wrote:
superdan wrote:
Me Here Wrote:
Walter Bright wrote:
Yes, but the onus will be on you (the programmer) to prevent data races
and >>> do proper synchronization.
In the scenario described, the main thread initialises the array of
data. Then, >> non-overlapping slices of that are tioned out to N worker
threads. Only one >> thread ever modifies any given segment. When the
worker threads are complete, >> the 'results' are left in the original
array available in its entirety only to >> the main thread.
You have to be very wary of cache effects when
writing data in one thread and expecting to see it in another.
Are you saying that there is some combination of OS and/or hardware L1/L2
caching that would allow one thread to read a memory location
(previously) >> modified by another thread, and see 'old data'?
Cos if you are, its a deeply serious bug that if its not already very
well >> documented by the OS writer or hardware manufacturers, then here's
your chance >> to get slashdotted (and diggited and redited etc. all
concurrently) as the >> discoveerer of a fatel processor flaw.
google for "relaxed memory consistency model" or "memory barriers". geez.
I presume the discussion regards symmetric multiprocessing (SMP).
Cache coherency is a very important element of any SMP design. It
basically means that caches should be fully transparent, i.e. the
behavior should not change by the addition or removal of caches.
you are perfectly correct... as of ten years ago. you are right in that cache
coherency protocols ensure the memory model is respected regardless of adding
or eliminating caches. (i should know coz i implemented a couple for a
simulator.) the problem is that the memory model has been aggressively
changed recently towards providing less and less implied ordering and
requiring programs to write explicit synchronization directives.
So the above scenario should never occur. If thread A writes something
prior to thread B reading it, B should never get the old value.
yeah the problem is it's hard to define what "prior" means.
"Memory barriers" have nothing to do with cache consistency. A memory
barrier only prevents a single CPU thread from reordering load/store
instructions across that specific barrier.
memory barriers strengthen the relaxed memory model that was pushed
aggressively by the need for faster caches.
Since in the scenario I describe, Each thread or cpu is dealing with a single
section of memory. And each section of memory is being dealt with by a single
thread or cpu, the is effectively no shared state whilst the threads run, Hence
no possibility of cache inconsistancy due to pipeline reordering. Ie.
goodness this is so wrong i don't know where to start from. like trying to
figure out what's bad about a movie that's real real bad. you have no idea what
you're talking about do you. just throwing terms here and there and making
unstated assumptions that worked in 1980 on an atari.
first off there is word tearing. u can't change one character in a string
willy-nilly. the rest will need to be masked and you got a race condition right
there. but of course you had no idea.
main thread populates a[ 0 .. 1000 ];
for thread 1 .. 10
spawn( thread, \a[ ((thread-1 ) *100 ) .. ((thread-1 + 100) * 100 ] );
main thread waits for all threads to terminate;
main thread does something with a[];
In any case, cache consistancy issues due to pipeline reordering do not survive
context switches, so the issue is a non-issue for the purposes of the
discussion at hand. Ie. threading
Pipelines cover single digit or low double digit runs of non-branching
instructsion at most. A context switch consists of hundreds if not thousands of
instructions on all but the most highly tuned of real-time kernels. This is a
very localised issue, for the compiler writer, not the application programmer
to worry about.
this is just babble. you bring pipelines and thread switching because you have
no idea what the discussion is about and you try to relate it to the little
things 1985 vintage you have a vague idea about. in the name of brian: we got
more than one processor today. wake up and smell the shit.
I know Walter *is* a compiler writer, but this is a complete red-herring in the
context of this discussion.
i'll tell you what's a red herring: everything you say. your knowledge is
obsolete by decades. you have no idea what you are talking about yet you try to
defraud us by using cockiness. you even have the nerve to criticize walter and
andre. tell you what. walter's brown underwear and andreis dirty socks with
holes in'em know more shit than you. i'll leave it to sean to serve you your
arrogant ass on a silver plate.
superdan schrieb:
i'll tell you what's a red herring: everything you say. your knowledge is
obsolete by decades. you have no idea what you are talking about yet you try to
defraud us by using cockiness. you even have the nerve to criticize walter and
andre. tell you what. walter's brown underwear and andreis dirty socks with
holes in'em know more shit than you. i'll leave it to sean to serve you your
arrogant ass on a silver plate.
atm it seems to me that Gregor R. is really a nice, gentle guy.
:)
superdan wrote:
i'll tell you what's a red herring: everything you say. your knowledge is
obsolete by decades. you have no idea what you are talking about yet you try
to defraud us by using cockiness. you even have the nerve to criticize walter
and andre. tell you what. walter's brown underwear and andreis dirty socks
with holes in'em know more shit than you. i'll leave it to sean to serve you
your arrogant ass on a silver plate.
Hey tweety-pie. How about you get back to sucking your mother's nipple. It'll
give you something useful to do with that foul mouth and perhaps calm that
overexcited brain of yours. There is nothing, I repeat *NOTHING* being
implemented in today's commodity cpus, that wasn't pioneered (and perfected) in
CDC processors (and others) *TWO DECADES AGO*.
So, when you've suckled well and aren't so grouchy through humger, and have
been burped and well rested, and had your diaper changed. Perhaps then you can
go away and do a little research on what was being done on big iron 20 or more
years ago.
You almost certainly won't because kiddies like you don't have the attention
span for it. You'll probably just come back here and spout another unjustified
and unsupported load of twaddle.
C'est la vie. Bozo, cos I won't be reading it.
b.
--
I created the wishlist to reduce the
high level of repeated postings of similar ideas,
and the community could help Walter single out the good ideas
via voting.
When new users joined the newsgroup they
had the tendency to suggest thing that have already been
discussed several times.
Also good ideas by experts which didn't have time to post much
had a tendency to drown in the "noise".
Of cause the wish list have several short comings.
Like no way to post comments and a admin which is busy with other things
e.t.c.
I had the hope that someone with time would write a good replacement.
(Like the forum used on http://labs.powerset.com/. Does anyone know
which software they use ?).
Walter have suggested that bugzilla is used for enhancement requests,
this is a very good idea, but as far as I can see it is not currently
possible to vote on the requests, or generate a list with the most voted
on enhancement requests, as the wishlist does.
Of cause I added a request for this to the wishlist
http://all-technology.com/eigenpolls/dwishlist/index.php?it=176
On Mon, 07 Jul 2008 00:13:05 +0400, Knud Soerensen =
<4tuu4k002 sneakemail.com> wrote:
I created the wishlist to reduce the
high level of repeated postings of similar ideas,
and the community could help Walter single out the good ideas
via voting.
When new users joined the newsgroup they
had the tendency to suggest thing that have already been
discussed several times.
Also good ideas by experts which didn't have time to post much
had a tendency to drown in the "noise".
Of cause the wish list have several short comings.
Like no way to post comments and a admin which is busy with other thin=
gs
e.t.c.
I had the hope that someone with time would write a good replacement.
(Like the forum used on http://labs.powerset.com/. Does anyone know
which software they use ?).
Walter have suggested that bugzilla is used for enhancement requests,
this is a very good idea, but as far as I can see it is not currently
possible to vote on the requests, or generate a list with the most vot=
ed
on enhancement requests, as the wishlist does.
Of cause I added a request for this to the wishlist
http://all-technology.com/eigenpolls/dwishlist/index.php?it=3D176
How about resetting wish-list votes once in a while or dropping votes th=
at =
are older than, say, a year?
Other than that it is ok to have such poll.
But its current contents should certainly be revised, since it makes =
little sense to contribute to this list now that it doesn't reflect D =
status anymore.
Knud Soerensen wrote:
generate a list with the most voted on enhancement requests
I believe, that voting without supervision is a no-no in general and
especially voting for ones own profit; even more no-no when the voting
is anonymous. Voters put themselves into the shapes of beings of
unlimited powers, disburdened from the need to obey to restricted
resources.
-manfred
Manfred_Nowak wrote:
Knud Soerensen wrote:
generate a list with the most voted on enhancement requests
I believe, that voting without supervision is a no-no in general and
especially voting for ones own profit; even more no-no when the voting
is anonymous. Voters put themselves into the shapes of beings of
unlimited powers, disburdened from the need to obey to restricted
resources.
-manfred
I believe, that newsgroup posting without supervision is a no-no in
general and especially posting for ones own profit; even more no-no when
the posting is anonymous. Posters put themselves into the shapes of
beings of unlimited powers, disburdened from the need to obey to
restricted resources.
Are you using template based argumentation ?
"Unknown W. Brackets" <unknown simplemachines.org> 