Re: Why I'm Excited about D
On Monday, 13 April 2015 at 05:46:32 UTC, Dicebot wrote: [...] That said, I think the main reason why this notion didn't work well for D when @property was introduces is because of extremely vague range semantics. I find it important that you have mentioned exactly `front` and `popFront` as examples for unclear parens placement - problem with those is that there isn't. `front` may or may not be trivial getter depending on (sometimes arbitrary) decision by range implementor, there is no uniformity between those. Which makes impossible to enforce consistent calling style and makes drop everything approach much more tempting. At work we use a tool that uses a kind of attribute no side effects. I would love it if the D could do just that - the compiler is already able to check if a function has side effects or not (if it has none it can warns about simple function call statements), than only functions with no side effects should be callable without parantheses. That would be straight and a clear visible for the reader of some code. And than the attribute @property could be used to allow even a function WITH side effects to be called without parantheses - the developer has to ensure that what ever is done in such a function does something sensible (e.g. calculate something at first call and then only works as getter afterwards), but the reader of the code is warned: the attribute @proberty was used, so he better take a look what this function really does. Maybe also a new attribute @nonprop could be introduced, to force that a function must be called with parantheses even if it has no side effects, but I'm not sure where this would be useful.
Re: Why I'm Excited about D
On Monday, 13 April 2015 at 05:46:32 UTC, Dicebot wrote: On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu wrote: On 4/12/15 10:43 AM, Dicebot wrote: It is much better in languages that do support dedicated properties because language rules can be used to express the same notion without resorting to any conventions. Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei This is totally reasonable way to put it but in practice there are enough differences to keep it maintainable. With dedicated getters decision (and reviewer attention) is focused on definition of getter and done there once and for all. Some tough decisions are inevitable but it is at least possible to ensure that all such decisions are deliberate. In D such decision is done at call site which makes it very hard to review as changes are distributed everywhere. Though DScanner can possibly help here and I am really looking forward trying to it in our code control. That said, I think the main reason why this notion didn't work well for D when @property was introduces is because of extremely vague range semantics. I find it important that you have mentioned exactly `front` and `popFront` as examples for unclear parens placement - problem with those is that there isn't. `front` may or may not be trivial getter depending on (sometimes arbitrary) decision by range implementor, there is no uniformity between those. Which makes impossible to enforce consistent calling style and makes drop everything approach much more tempting. Very good point. I've been bitten by range semantic many times, especially map, which is lazy and does the work on front call, rather than popFront as I would have expected. Thinking about it, this is probably the right thing to do, but the range interface makes it non obvious and confusing.
Re: Why I'm Excited about D
On Monday, 13 April 2015 at 16:43:00 UTC, deadalnix wrote: Thinking about it, this is probably the right thing to do, but the range interface makes it non obvious and confusing. Some time ago there was a long thread about formalising the interface for ranges, i.e. a clear and precise definition of what each method should do. Was a consensus reached and documented?
Re: Why I'm Excited about D
On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu wrote: On 4/12/15 10:43 AM, Dicebot wrote: It is much better in languages that do support dedicated properties because language rules can be used to express the same notion without resorting to any conventions. Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei This is totally reasonable way to put it but in practice there are enough differences to keep it maintainable. With dedicated getters decision (and reviewer attention) is focused on definition of getter and done there once and for all. Some tough decisions are inevitable but it is at least possible to ensure that all such decisions are deliberate. In D such decision is done at call site which makes it very hard to review as changes are distributed everywhere. Though DScanner can possibly help here and I am really looking forward trying to it in our code control. That said, I think the main reason why this notion didn't work well for D when @property was introduces is because of extremely vague range semantics. I find it important that you have mentioned exactly `front` and `popFront` as examples for unclear parens placement - problem with those is that there isn't. `front` may or may not be trivial getter depending on (sometimes arbitrary) decision by range implementor, there is no uniformity between those. Which makes impossible to enforce consistent calling style and makes drop everything approach much more tempting.
Re: Why I'm Excited about D
On Sunday, 12 April 2015 at 18:42:01 UTC, Andrei Alexandrescu wrote: On 4/12/15 10:43 AM, Dicebot wrote: It is much better in languages that do support dedicated properties because language rules can be used to express the same notion without resorting to any conventions. Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei I'd be surprised if there is any language that prevents you from causing side-effects in getters(beside functional languages that prevent you from causing side-effects anywhere) or non-setting-related side-effects in setters. These kind of limitations prevent many useful patterns, like calculating-and-caching a value the first time a getter is called, or updating a visual component on the screen when it's setters are called. I don't think relying-purely-on-conventions-with-no-language-support and the-language-strictly-forbids-stuff are the only choices. With a grain (syntactic) salt a language can promote the right way by turning the wrong way into code smell. If you see a getter function declared as getter(be it with C#'s getter declaration syntax or with D's doesn't-actually-do-anything @property attribute or whatever used in that language) that causes side-effects other than the ones pragmatically needed for getting the value, you can immediately see that something is wrong. But if you look at such a function at the call site you can't guess that it's doing that stuff. In C#, if you can't rely on other developers to only use the getter-setter syntax for actual getters and setters, then that is probably the least of your worries... In D, you don't need to not rely on other developers to do that, because EVERY method without arguments and EVERY function with a single argument are getters, and there is nothing you can do about it(unless you use the seems-to-be-abandoned -property flag). BTW - the exact definition of getters and setters may vary(can querying a webservice be considered a getter?), but under no sane definition is writeln a getter!
Re: Why I'm Excited about D
On Thursday, 9 April 2015 at 07:00:56 UTC, Andrei Alexandrescu wrote: On 4/8/15 11:45 PM, Dicebot wrote: It took almost an hour to bisect all changed to trace the failure to this specifc line and realize that `parser.node` wasn't just trivial getter but method which actually advanced internal iterator to next node while returning current one. Thanks. The matter seems like a C++ false friend. -- Andrei Actually, C++ had the very same issue, just the other way around. Stuff like length() was still called like method even if trivial and I remember resorting to naming convention to avoid wasting time on following all symbol references. It was roughly the same rule - no side effects or costly computations in methods named `getXXX`, simply attached to naming convention as opposed to calling convention. And it was even more unpleasant than current D state of affairs. I had much more pleasant experience of maintaining code in plain C where separation between data and code is more forced by language simplicity. It is much better in languages that do support dedicated properties because language rules can be used to express the same notion without resorting to any conventions. And properly naming things is unreasonably time consuming so this by convention approach hardly works anyway. The way I see situation in D is that it had an opportunity to actually get things better than in C/C++ with @property but that was killed in favor of seemingly nice syntax. Which feels completely disproportional approach to me because saving one pair of () per line of code is hardly comparable to being able to better reason about the code without resorting to IDE. Everyone who has pointed out that naming in original snippet sucks is completely right. However, this is not really helping - bad names will inevitably slip through here and there. Which naturally makes me annoyed about language features that make the issue worse instead of largely diminishing it. Mandatory () are probably not that important on their own - but thet at least add something to to the language, while alternative is simply syntax sugar with no practical value.
Re: Why I'm Excited about D
On 4/12/15 10:43 AM, Dicebot wrote: It is much better in languages that do support dedicated properties because language rules can be used to express the same notion without resorting to any conventions. Wouldn't e.g. C# allow arbitrary code in getters and setters? And if so, wouldn't C# code need to resort to conventions to avoid surprising behavior? -- Andrei
Re: Why I'm Excited about D
On Thursday, 9 April 2015 at 01:28:05 UTC, Andrei Alexandrescu wrote: On 4/8/15 4:15 PM, Idan Arye wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions. It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei This is not about being struck by lightning. This is about being struck by the next developer who has to read your code.
Re: Why I'm Excited about D
On 4/8/15 11:45 PM, Dicebot wrote: It took almost an hour to bisect all changed to trace the failure to this specifc line and realize that `parser.node` wasn't just trivial getter but method which actually advanced internal iterator to next node while returning current one. Thanks. The matter seems like a C++ false friend. -- Andrei
Re: Why I'm Excited about D
On 4/9/2015 9:12 AM, Araq wrote: Because trivial accessors are everywhere in Java one usually has to assume it has no side-effects. I fail to see the relevance of the missing () in your example; () doesn't scream side-effect in C++/Java/C#/C. The real issue here is that 'node' or 'getNode' is simply poorly named suggesting it has no side-effects. 'nextNode' for instance doesn't have this problem. I agree, it seems the method is poorly named as a simple noun that implies a static computation, rather than as a verb that implies some sort of action.
Re: Why I'm Excited about D
On Thursday, 9 April 2015 at 16:12:17 UTC, Araq wrote: side-effect in C++/Java/C#/C. The real issue here is that 'node' or 'getNode' is simply poorly named suggesting it has no side-effects. 'nextNode' for instance doesn't have this problem. next is a common name for next-pointers. You need to pick a verb that cannot be mistaken for an adjective. E.g. moveToNextNode. Anyway, being explicit is important for maintainability. Some language designers are very much against even overloading for this reason. There's a convenience-maintenance trade off between weakly typed implicit languages and statically/strictly/strongly typed explicit code (suitable for large vocabulary, large source base, long running). Here's the semiotics I tend to go by: - Dot-notation indicates an accessor/interface provided by the object, e.g. penetrating an encapsulation. - A parametric accessor (() is empty) indicates work being done using reference semantics. - Free form functions indicates value-semantics with results derived from values/objects. Consistent mapping from syntax to semantics makes for more readable and, more importantly, more easily maintainable code.
Re: Why I'm Excited about D
So, to be more specific, here is one of cases where it actually
caused trouble in practice. Someone has originally written code
that looked roughly like this:
while (something)
{
// ...
auto str = format(%s, parser.node);
}
Long time later I have been adding trace logs to that module
and this has become akin to
while (something)
{
log(parser.node);
// ...
auto str = format(%s, parser.node);
}
Which resulted in broken application. It took almost an hour to
bisect all changed to trace the failure to this specifc line
and realize that `parser.node` wasn't just trivial getter but
method which actually advanced internal iterator to next node
while returning current one.
In Java many people would have done this instead:
while (something)
{
log(parser.getNode());
// ...
String str = format(%s, parser.getNode());
}
Because trivial accessors are everywhere in Java one usually has
to assume it has no side-effects. I fail to see the relevance of
the missing () in your example; () doesn't scream side-effect in
C++/Java/C#/C. The real issue here is that 'node' or 'getNode' is
simply poorly named suggesting it has no side-effects. 'nextNode'
for instance doesn't have this problem.
Re: Why I'm Excited about D
On 4/9/15 10:31 AM, Idan Arye wrote: On Thursday, 9 April 2015 at 01:28:05 UTC, Andrei Alexandrescu wrote: On 4/8/15 4:15 PM, Idan Arye wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions. It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei This is not about being struck by lightning. This is about being struck by the next developer who has to read your code. Apparently they didn't either. -- Andrei
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu
wrote:
On 4/8/15 10:04 AM, Dicebot wrote:
On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei
Alexandrescu wrote:
Considering I am far from the only person having problems
with it in our team and such style is extremely common
because of being
easy - this can easily be one of most damaging language
features in D in
terms of wasted developer time.
Again trying with ad populum. Not buying it.
I don't even slightly care about your opinion here. It is just
another
annoying custom style rule I have to deal with. Casual
necessity for
actually getting work done with D.
I guess I deserve this for making my point as a jerk. I
shouldn't engage in brief bickering when I don't have time. My
point was: you'd need some detail to back up your claim about
those wasted hours because I also work on a large D project at
work with others and that hasn't been an issue, like, ever. We
ended up just not adding the pesky ()s simply because sitting
down and deciding which deserves and which doesn't was a waste
of time. E.g. front and empty shouldn't, but popFront should.
Really no reason for it.
So, to be more specific, here is one of cases where it actually
caused trouble in practice. Someone has originally written code
that looked roughly like this:
while (something)
{
// ...
auto str = format(%s, parser.node);
}
Long time later I have been adding trace logs to that module and
this has become akin to
while (something)
{
log(parser.node);
// ...
auto str = format(%s, parser.node);
}
Which resulted in broken application. It took almost an hour to
bisect all changed to trace the failure to this specifc line and
realize that `parser.node` wasn't just trivial getter but method
which actually advanced internal iterator to next node while
returning current one.
Yes, this does seem to bother only some people and others
actually enjoy omitting parens everywhere. But it comes up often
enough to cause actual damage which makes aesthetical point much
less convincing. I don't have any good statistics for how often
it strikes or what kind of workflow is more likely to clash with
such style - all I know that such cases happen, and happen often
enough to not be dismissed as purely accidental.
Considering that following more permissive coding style does not
actually give you any benefits than saving at most one pair of ()
per line, choice feels obvious. We don't currently have any
strict style rules about this but general direction seems to be
mandatory () for last call in a call chain with an exception
for side-effect free trivial getters.
tl; dr: I can commonly be wrong in identifying the problem,
evalutating its importance or proposing solutions but it feels
offending when you suggest I don't actually have a problem at
all. Those are not the droids you are looking for style ;)
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu wrote: On 4/7/15 11:42 AM, Martin Nowak wrote: What's still missing is a faster AST interpreter for CTFE though. A JIT would be nice. -- Andrei Maxine understood the point, see http://dconf.org/2013/talks/chevalier_boisvert.pdf p. 61 ff, an AST interpreter is something you can write over a long weekend, a JIT is rather unlikely to happen any time soon. Even a bytecode interpreter might hardly be worth the effort.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 08:35:52 UTC, ixid wrote:
On Tuesday, 7 April 2015 at 19:46:07 UTC, Ary Borenszweig wrote:
On 4/7/15 3:34 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig
wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like writeln being used with UFCS, it's an
abuse.
My point is that every language has WATs :-)
Why is it 'an abuse'? Do you special case any other functions
or is names.parallel unacceptable as well? Are longer chains
ending in writeln acceptable or do you insist in putting the
whole chain inside a parens writeln?
name.reverse.writeln
or
writeln(name.reverse)
or surely that would break your dislike of single UFCS
arguments so you should stick to:
writeln(reverse(name))
Which is proper yoda speak.
At the very least, put () after the writelne:
name.reverse.writeln();
Using the property getter style for a function used solely for
it's side-effects kind of conceals what you are trying to do
here...
At any rate, since UFCS allows you to choose the order your code
will be read in, you should try give as much information as soon
as possible:
`writeln(name.reverse);` - the first word is `writeln`, so I know
it's a statement that's going to write something to stdout.
`name.reverse.writeln();` - the first word is `name`, so I know
it has something to do with the name.
Decide which one to use based on the first impression you want
people to get from that statement.
Re: Why I'm Excited about D
On 2015-04-07 19:53, deadalnix wrote: https://www.destroyallsoftware.com/talks/wat That is mostly for JavaScript. -- /Jacob Carlborg
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 05:03:03 UTC, Andrei Alexandrescu wrote: On 4/7/15 7:33 PM, deadalnix wrote: On Wednesday, 8 April 2015 at 01:30:02 UTC, Andrei Alexandrescu wrote: Not really when you think about it. CPU instruction is a bytecode like another, with provided hardware interpreter for it. Classical interpretation via tree walking does not use a bytecode. -- Andrei Yes, but this is pretty much what is done right now, so that wouldn't be an improvement. You went ouroboros. This means your point has been destroyed so thoroughly, you lost the thread of the dialog. Own the destruction and move on. -- Andrei You are the one making about winning.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 19:46:07 UTC, Ary Borenszweig wrote:
On 4/7/15 3:34 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig
wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like writeln being used with UFCS, it's an abuse.
My point is that every language has WATs :-)
Why is it 'an abuse'? Do you special case any other functions or
is names.parallel unacceptable as well? Are longer chains ending
in writeln acceptable or do you insist in putting the whole chain
inside a parens writeln?
name.reverse.writeln
or
writeln(name.reverse)
or surely that would break your dislike of single UFCS arguments
so you should stick to:
writeln(reverse(name))
Which is proper yoda speak.
Re: Why I'm Excited about D
On 2015-04-07 19:46, Ary Borenszweig wrote: It's true that Ruby is slow, but only because their priority is correctness. I don't think it's so much about the correctness, it's rather the complicated features it supports, like metaprogramming. eval and bindings are causing problems, also promoting Fixnum to Bignum when it doesn't fit is a problem. I also read somewhere that since you can replace any method in Ruby, all calls to a method needs to check if the method has been replaced. Here's a blog that talks about the problems of optimizing Ruby [1] [1] http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby.html -- /Jacob Carlborg
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 18:34:01 UTC, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
UFCS doesn't give you yoda speak. It's more consistent to use it
for single as well as multiple function chains and it's cleaner.
Some users' distaste for UFCS cramps D's developing its own
consistent idiomatic approach. Do you have any argument for your
dislike that isn't just personal preference? You're fine with
names.parallel but for some reason balk at name.writeln?
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote: I think foo.writeln; is acceptable. You just need to get a bit used to it. The whole dot-notation for pipelining is semantically flawed en relies on knowing what names stand for rather than more universal symbols with known interpretations. It has been (ab)used quite a bit in OO-libraries for other languages, for chaining, which can be rather confusing when you use many libraries. Dedicated pipeline operators look much better (input-process-output). Add dataflow with multiple paths and high level optimization, then you have something.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:59:27 UTC, Dicebot wrote: Just to be clear - I wouldn't allow range.copy(stdout) in my projects either, requiring any consumer to be written as dedicated expression. Worth noting that std.range.put's documentation also says use the freestanding syntax. (This is surely to avoid ambiguity with member puts on output ranges, but still.)
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei Alexandrescu wrote: Considering I am far from the only person having problems with it in our team and such style is extremely common because of being easy - this can easily be one of most damaging language features in D in terms of wasted developer time. Again trying with ad populum. Not buying it. I don't even slightly care about your opinion here. It is just another annoying custom style rule I have to deal with. Casual necessity for actually getting work done with D. And if not buying it is all you can say about actual experience report (however opinionated it is) this tells quite a lot about how justified _your_ preference is.
Re: Why I'm Excited about D
On 4/8/2015 9:58 AM, Adam D. Ruppe wrote: On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei Alexandrescu wrote: File defines it. Last time this came up on reddit, I explained that *this* was exactly why I think string.writeln is mistaken. writeln does NOT operate on its string, it doesn't tell the string to do something, it doesn't transform the string. It tells a *File* to do something. writeln is an OutputRange. It takes its input from the pipeline and places it in a container (the screen).
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 17:17:21 UTC, Walter Bright wrote: On 4/8/2015 9:58 AM, Adam D. Ruppe wrote: On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei Alexandrescu wrote: File defines it. Last time this came up on reddit, I explained that *this* was exactly why I think string.writeln is mistaken. writeln does NOT operate on its string, it doesn't tell the string to do something, it doesn't transform the string. It tells a *File* to do something. writeln is an OutputRange. It takes its input from the pipeline and places it in a container (the screen). But it is actually a method of stdout file, which was what Adam has pointed out. Hiding it behind free function and abusing that fact for UFCS is just mixing semantics and, well, abuse.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 17:17:21 UTC, Walter Bright wrote: writeln is an OutputRange. No, it isn't. It isn't even remotely close to one - an OutputRange is a type, writeln is a function. isOutputRange doesn't even return false for it, it outright fails to compile! File isn't an output range either btw. An output range is defined by the presence of a put method, which File doesn't have. b.d(4): Error: static assert (isOutputRange!(File, char)) is false Even putting aside the formal definition of output range, output is NOT part of the pipeline! Pipelines can be composed and they keep pumping data through them. writeln does not transform its input nor does it forward it to the next item in the pipe. It just eats it. That's totally different than everything else in the sequence. And that's not even bringing in writeln's sister function, writefln, whose first argument isn't what is to be printed at all! (it can show something to print but passing arbitrary strings to writef as the first argument is a major program bug, you should never do it)
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 08:35:52 UTC, ixid wrote:
On Tuesday, 7 April 2015 at 19:46:07 UTC, Ary Borenszweig wrote:
On 4/7/15 3:34 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig
wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like writeln being used with UFCS, it's an
abuse.
My point is that every language has WATs :-)
Why is it 'an abuse'? Do you special case any other functions
or is names.parallel unacceptable as well? Are longer chains
ending in writeln acceptable or do you insist in putting the
whole chain inside a parens writeln?
There are two main use cases for UFCS:
1) akin to extension methods in C#. It only ever makes sense to
use UFCS syntax for cases where you would consider actually
having method like this in used data type.
2) more readable syntax for functional style processing pipeline
There is no way anyone would ever add method called writeln to
user data type and it is clearly not pipeline function. This is
plain and disgusting abuse of the syntax, I am fully with
deadalnix here.
For parallel it may be feasible if data set is actually intended
for parallelization by design but I would personally consider
that fishy too.
Omitting parens from function calls with side effects is another
horrible sin but that is more of a personal taste thing.
Re: Why I'm Excited about D
deadalnix:
foreach (name; names.parallel) {
name.writeln;
}
no.please
I think foo.writeln; is acceptable. You just need to get a bit
used to it.
Bye,
bearophile
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote:
deadalnix:
foreach (name; names.parallel) {
name.writeln;
}
no.please
I think foo.writeln; is acceptable. You just need to get a
bit used to it.
Bye,
bearophile
No.
Re: Why I'm Excited about D
On 4/8/15 4:59 AM, Jacob Carlborg wrote: On 2015-04-07 19:46, Ary Borenszweig wrote: It's true that Ruby is slow, but only because their priority is correctness. I don't think it's so much about the correctness, it's rather the complicated features it supports, like metaprogramming. eval and bindings are causing problems, also promoting Fixnum to Bignum when it doesn't fit is a problem. The autopromotion of Fixnum to Bignum is interesting. It always leads to correct code, although it's slow. Without this feature you start to realize how week are other languages. For example, take the simple problem of parsing a number out of a string. In Ruby it's: 123.to_i #= 123 But this also works: 12398123091823091823091823091823091820318203123.to_i #= 12398123091823091823091823091823091820318203123 In typed language one would be forced to make a decision for the return type of to_i. Maybe if it doesn't fit in an Int32 or Int64 raise an exception or signal an error somehow. In Ruby you just forget about these little problems, it will always work and give the correct result. That's one of the reasons I think it's bad to say that Ruby is not a correct language.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 14:57:15 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote: I think foo.writeln; is acceptable. You just need to get a bit used to it. The whole dot-notation for pipelining is semantically flawed en relies on knowing what names stand for rather than more universal symbols with known interpretations. It has been (ab)used quite a bit in OO-libraries for other languages, for chaining, which can be rather confusing when you use many libraries. Dedicated pipeline operators look much better (input-process-output). Add dataflow with multiple paths and high level optimization, then you have something. I kind of agree with this one. Range based pipeline has established rather late as core D idiom but in general it is distinct enough to warrant own syntax.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 18:34:01 UTC, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
I love UFCS. I'd definitely write names.parallel myself.
Atila
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote: ... I also work on a large D project at work ... Which compiler do you use?
Re: Why I'm Excited about D
On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Yes.
Re: Why I'm Excited about D
On 4/8/15 7:00 AM, Dicebot wrote:
On Wednesday, 8 April 2015 at 13:52:22 UTC, bearophile wrote:
deadalnix:
foreach (name; names.parallel) {
name.writeln;
}
no.please
I think foo.writeln; is acceptable. You just need to get a bit used
to it.
Bye,
bearophile
No.
Ja, ja, ja. -- Andrei
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Yes. And, by the way, this is not a just personal taste thing. This stupid style has costed me many wasted debugging ours during project maintenance. Considering I am far from the only person having problems with it in our team and such style is extremely common because of being easy - this can easily be one of most damaging language features in D in terms of wasted developer time.
Re: Why I'm Excited about D
On 4/8/15 6:42 AM, Dicebot wrote: There is no way anyone would ever add method called writeln to user data type File defines it. and it is clearly not pipeline function. Oh but it is. This is plain and disgusting abuse of the syntax, I am fully with deadalnix here. No. Andrei
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu No. -- Andrei Yes. FILE_NOT_FOUND
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei Alexandrescu wrote: File defines it. Last time this came up on reddit, I explained that *this* was exactly why I think string.writeln is mistaken. writeln does NOT operate on its string, it doesn't tell the string to do something, it doesn't transform the string. It tells a *File* to do something.
Re: Why I'm Excited about D
On 4/8/15 9:53 AM, Dicebot wrote: On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Yes. And, by the way, this is not a just personal taste thing. It is. This stupid style has costed me many wasted debugging ours during project maintenance. Not buying it. Considering I am far from the only person having problems with it in our team and such style is extremely common because of being easy - this can easily be one of most damaging language features in D in terms of wasted developer time. Again trying with ad populum. Not buying it. Andrei
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:51:53 UTC, Andrei Alexandrescu wrote: and it is clearly not pipeline function. Oh but it is. Oh really? And what does it transform the input data to? Just to be clear - I wouldn't allow range.copy(stdout) in my projects either, requiring any consumer to be written as dedicated expression.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 17:41:01 UTC, ixid wrote: Even putting aside the formal definition of output range, output is NOT part of the pipeline! Pipelines can be composed and they keep pumping data through them. writeln does not transform its input nor does it forward it to the next item in the pipe. It just eats it. nor does it forward it to the next item in the pipe This is something I think writeln should do and have suggested before. It would be useful for debugging pipelines to be able to drop in writeln in the middle of the pipeline and pass on the data unchanged. http://dlang.org/library/std/range/tee.html ?
Re: Why I'm Excited about D
Even putting aside the formal definition of output range, output is NOT part of the pipeline! Pipelines can be composed and they keep pumping data through them. writeln does not transform its input nor does it forward it to the next item in the pipe. It just eats it. nor does it forward it to the next item in the pipe This is something I think writeln should do and have suggested before. It would be useful for debugging pipelines to be able to drop in writeln in the middle of the pipeline and pass on the data unchanged.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 17:41:01 UTC, ixid wrote: It would be useful for debugging pipelines to be able to drop in writeln in the middle of the pipeline and pass on the data unchanged. That might be useful for debugging but I'd also be annoyed if someone used that in production code too because then your pipeline would have global side effects!
Re: Why I'm Excited about D
On 4/8/15 10:04 AM, Dicebot wrote: On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei Alexandrescu wrote: Considering I am far from the only person having problems with it in our team and such style is extremely common because of being easy - this can easily be one of most damaging language features in D in terms of wasted developer time. Again trying with ad populum. Not buying it. I don't even slightly care about your opinion here. It is just another annoying custom style rule I have to deal with. Casual necessity for actually getting work done with D. I guess I deserve this for making my point as a jerk. I shouldn't engage in brief bickering when I don't have time. My point was: you'd need some detail to back up your claim about those wasted hours because I also work on a large D project at work with others and that hasn't been an issue, like, ever. We ended up just not adding the pesky ()s simply because sitting down and deciding which deserves and which doesn't was a waste of time. E.g. front and empty shouldn't, but popFront should. Really no reason for it. And if not buying it is all you can say about actual experience report (however opinionated it is) this tells quite a lot about how justified _your_ preference is. Yah, I do think it's a matter of preference. Andrei
Re: Why I'm Excited about D
On 4/8/2015 10:33 AM, Adam D. Ruppe wrote: On Wednesday, 8 April 2015 at 17:17:21 UTC, Walter Bright wrote: writeln is an OutputRange. No, it isn't. It isn't even remotely close to one - an OutputRange is a type, I meant an instance of a type, as in: i is an int meaning i has type int. writeln is a function. isOutputRange doesn't even return false for it, it outright fails to compile! I understand that a true OutputRange would require one to write: arg.copy(writeln); and that a common idiom is to write it so the copy() can be implicit. I haven't made up my mind as to the right style here. File isn't an output range either btw. An output range is defined by the presence of a put method, which File doesn't have. b.d(4): Error: static assert (isOutputRange!(File, char)) is false Even putting aside the formal definition of output range, output is NOT part of the pipeline! Pipelines can be composed and they keep pumping data through them. An output range is the caboose of a pipeline (to mix metaphors). writeln does not transform its input nor does it forward it to the next item in the pipe. It just eats it. It places its input into a container. That's totally different than everything else in the sequence. And that's not even bringing in writeln's sister function, writefln, whose first argument isn't what is to be printed at all! It's true that a lot of Phobos code was designed pre-ranges, and the parameters aren't set up ideally for it. I've been doing some work to fix that.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu wrote: On 4/8/15 11:50 AM, Dmitri Makarov wrote: On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote: ... I also work on a large D project at work ... Which compiler do you use? dmd -- Andrei Is this for both production and development?
Re: Why I'm Excited about D
On 4/8/15 1:21 PM, deadalnix wrote: Also, I've noted the general trend lately were you seems value more winning the debate than actually coming to some conclusion. I'm not sure what's up with that, but nothing good can come out of this on the long run. Hmmm... Could you please give a few examples. You seem to be disproportionately sore over this specious claim of yours: What is a JIT if not an interpreter with hardware support ? which I found worth spending time to refute (in hindsight, not really worth the drama). For that distraction I'm sorry. If you want to chat about improving my manners, let's talk over a coffee. I guess I'll have a little list as well :o). Andrei
Re: Why I'm Excited about D
On Wed, 08 Apr 2015 23:14:23 +, ketmar wrote: On Wed, 08 Apr 2015 22:28:58 +, weaselcat wrote: On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu wrote: On 4/8/15 11:50 AM, Dmitri Makarov wrote: On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote: ... I also work on a large D project at work ... Which compiler do you use? dmd -- Andrei Is this for both production and development? i'm using DMD for production code too. most of the time code waits for i/o (being that disk, network or user interaction). ah, even my 2d game engine is ok with -release. to be honest, -release doesn't make much difference, as i'm already using `.ptr` to avoid range checking where it isn't appropriate. signature.asc Description: PGP signature
Re: Why I'm Excited about D
On 4/8/15 4:15 PM, Idan Arye wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions. It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei
Re: Why I'm Excited about D
On 4/8/15 3:28 PM, weaselcat wrote: On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu wrote: On 4/8/15 11:50 AM, Dmitri Makarov wrote: On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote: ... I also work on a large D project at work ... Which compiler do you use? dmd -- Andrei Is this for both production and development? Both. -- Andrei
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu
wrote:
On 4/8/15 2:24 AM, Idan Arye wrote:
At the very least, put () after the writelne:
No. -- Andrei
Why not? The property syntax's purpose is to create... well...
properties. Give you the illusion that you are reading and
writing member fields when you are actually calling functions.
`names.reverse` is OK, because you can imagine that `names` has a
member field called `reverse` that holds it reversed(this is not
really true because `names.reverse` is mutating the original
array, but the point is that we are not calling `reverse` for
it's side - we are only interested in it's return value).
`names.reverse.writeln;` - not so much. We are not treating
`writeln` as a property - we don't really care what it returns -
we treat it as a method, and therefore it should use the method
call syntax.
In matter of fact - if `writeln` was a member field - the very
same thing the combination of UFCS and property syntax is trying
to emulate - this code wouldn't compile:
struct Foo {
string writeln;
}
struct Bar {
Foo reverse;
}
void main() {
Bar names;
names.reverse.writeln;
}
source/app.d(10): Error: dotvar has no effect in expression
(names.reverse.writeln)
Re: Why I'm Excited about D
On Wed, 08 Apr 2015 22:28:58 +, weaselcat wrote: On Wednesday, 8 April 2015 at 22:19:11 UTC, Andrei Alexandrescu wrote: On 4/8/15 11:50 AM, Dmitri Makarov wrote: On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote: ... I also work on a large D project at work ... Which compiler do you use? dmd -- Andrei Is this for both production and development? i'm using DMD for production code too. most of the time code waits for i/o (being that disk, network or user interaction). ah, even my 2d game engine is ok with -release. signature.asc Description: PGP signature
Re: Why I'm Excited about D
On 4/8/15 11:50 AM, Dmitri Makarov wrote: On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu wrote: ... I also work on a large D project at work ... Which compiler do you use? dmd -- Andrei
Re: Why I'm Excited about D
Also, I've noted the general trend lately were you seems value more winning the debate than actually coming to some conclusion. I'm not sure what's up with that, but nothing good can come out of this on the long run.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei Alexandrescu wrote: On 4/8/15 9:53 AM, Dicebot wrote: On Wednesday, 8 April 2015 at 16:49:27 UTC, Dicebot wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Yes. And, by the way, this is not a just personal taste thing. It is. He is coming with actual feedback from people using D. This is not opinion, this is fact (considering he can be trusted, but then request more precise data instead of stating it is opinion). Considering I am far from the only person having problems with it in our team and such style is extremely common because of being easy - this can easily be one of most damaging language features in D in terms of wasted developer time. Again trying with ad populum. Not buying it. It is not ad populum, it is actual feedback from people using D having wasted time.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 17:43:27 UTC, Dicebot wrote: On Wednesday, 8 April 2015 at 17:41:01 UTC, ixid wrote: Even putting aside the formal definition of output range, output is NOT part of the pipeline! Pipelines can be composed and they keep pumping data through them. writeln does not transform its input nor does it forward it to the next item in the pipe. It just eats it. nor does it forward it to the next item in the pipe This is something I think writeln should do and have suggested before. It would be useful for debugging pipelines to be able to drop in writeln in the middle of the pipeline and pass on the data unchanged. http://dlang.org/library/std/range/tee.html ? Thanks, I wasn't aware of that function. Will use that.
Re: Why I'm Excited about D
On Monday, 6 April 2015 at 23:51:17 UTC, Adam Hawkins wrote:
Hello everyone, this is my first post on the forum. I've been
investigating the language for the past few weeks. I was able
to complete my first useful program thanks to very helpful
people in #d on IRC . The experience made me very interested in
the language and improving the community around it.
I'm primarily Ruby developer (been so about the last 7-8 years)
doing web stuff with significant JavaScript work as well. I
wrote a blog post on why I'm excited about D. You can read it
here: http://hawkins.io/2015/04/excited-about-d/.
I've been reading the forums here so I can see that there is a
focus on improving the marketing for the language and growing
the community. I see most of the effort is geared towards C++
programmers, but have you considered looking at us dynamic
languages folk? I see a big upside for us. Moving from Ruby to
D (my case) gives me power performance. I still have OOP
techniques but I still have functional things like closures and
all that good stuff. Only trade off in the Ruby case is
metaprogramming. All in all I think there is a significant
value promise for those of us doing backend services for folks
like me.
Regardless, I figured it might be interesting to hear about
some experience coming to the language from a different
perspective. Cheers!
This is awesome :)
A few notes on the blog:
peaked my interest should be piqued my interest
You can have as many unittest blocks as you want in a file/module.
@property isn't really about parentheses-less calls (parentheses
are optional for all function calls), it's more for this sort of
thing:
struct S
{
private int a_;
enum flagMask = 1u 31;
@property void val(int v)
{
a_ = (a_ flagMask) (v ~flagMask);
}
@property int val()
{
return a_ ~flagMask;
}
@property void flag(bool b)
{
a_ = ((cast(uint)b) 31) (a_ ~mask);
}
@property bool flag()
{
return a_ flagMask;
}
}
unittest
{
S s;
s.flag = true;
s.val = 75;
assert(s.flag);
assert(s.val == 75);
}
Note that the assignments are calling the property functions.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 01:12:20 UTC, bachmeier wrote: The thing I liked, coming from languages like R and Ruby, was that I could write D code in the most convenient, least efficient manner possible and still get good enough performance that it wouldn't matter. I find D to be easier to write than any scripting language. When I write D I always have to remind myself that I can just write, without concern for efficiency. And in the few cases that performance is critical I know I can do as well as C. This! This is really the thing I like about D overall! I used to prototype in python and either rewrite part of it in C (process involving lots of latent rage for missing common features) or give up on performance (which, honestly, was most of the time a good answer). In D I feel like I don't have this tradeoff. I start prototyping in D putting auto everywhere and not anotating anything and when the prototype works I just start cleaning the code, annotating it, etc The fact that where I used two languages I can now use only one is what convinced me (even if, to be fair, the prototyping part is way much easier in python... But that may be due to the gab of experience).
Re: Why I'm Excited about D
On Mon, 06 Apr 2015 23:51:16 +, Adam Hawkins wrote: I've been reading the forums here so I can see that there is a focus on improving the marketing for the language and growing the community. I see most of the effort is geared towards C++ programmers, but have you considered looking at us dynamic languages folk? it seems that there are not so many people that comes from some dynamic language. i believe that most of us using c/c++ (c#/java/etc.), so while we know bits and pieces about dynamic land, we generally not using it for something serious (unless we are forced to do so ;-). Regardless, I figured it might be interesting to hear about some experience coming to the language from a different perspective. sure. you're welcome, it's always good to have more opinions, both positive (yay!) and negative (heh... so what we can do with that?). signature.asc Description: PGP signature
Re: Why I'm Excited about D
On 2015-04-07 01:51, Adam Hawkins wrote: Only trade off in the Ruby case is metaprogramming. You can do metaprogramming in D, it's just a bit different compared to Ruby. -- /Jacob Carlborg
Re: Why I'm Excited about D
On 2015-04-07 02:29, Adam D. Ruppe wrote: On Tuesday, 7 April 2015 at 00:15:51 UTC, w0rp wrote: [...]and runtime templates. The last two haven't been written yet. Really? Runtime templates aren't even hard to implement vibe.d has a template system. It's based on Jade, which seems to be based on Haml. -- /Jacob Carlborg
Re: Why I'm Excited about D
import std.stdio, std.parallelism;
auto names = [ Adam Hawkins, Peter Esselius ];
foreach(name; taskPool.parallel(names)) {
writeln(name);
}
There is a convenience function in std.parallelism that allows
you to write the following instead for your foreach loop:
foreach (name; names.parallel) {
writeln(name);
}
Also, @system, @trusted, @safe don't really have much to do
with optimization or access levels, but safety. Theoretically,
if all of your code is @safe, then it is impossible for your
program to corrupt memory.
Also, have you considered posting this article to Hacker
News/Reddit?
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
Re: Why I'm Excited about D
On 2015-04-07 10:33, John Colvin wrote: (parentheses are optional for all function calls), Optional for all function calls taking no arguments. Note that in Ruby parentheses are optional for function calls taking arguments as well. -- /Jacob Carlborg
Re: Why I'm Excited about D
On 04/07/2015 08:28 AM, Jacob Carlborg wrote: vibe.d has a template system. It's based on Jade, which seems to be based on Haml. There is also a runtime template system, http://code.dlang.org/packages/mustache-d. See https://github.com/D-Programming-GDC/gdcproject for an example.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 01:28:03 UTC, Rikki Cattermole wrote: I'm watching your progress closely. I think we are ready to get D properly on micro controllers and you are really testing, exploring it even. Johannes made some very important additions for regarding this. It might already be possible for me to write a complete startup file entirely in D, because of these additions. I would be very surprised in the next year or so, if you don't make atleast one breakthrough! I'm looking forward to the first one; it's just around the corner: The file startup.d. :) -I'll be sure to create a thread about it, when it's complete (it's at something like 98% already). One thing I'd like to add to why I like D, is that it feels limitless. I don't feel like I'm restricted by the language or the compiler; in other words, I feel a lot of 'freedom'.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 11:16:56 UTC, Jacob Carlborg wrote: On 2015-04-07 10:33, John Colvin wrote: (parentheses are optional for all function calls), Optional for all function calls taking no arguments. Note that in Ruby parentheses are optional for function calls taking arguments as well. Sorry, yes my mistake
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 08:33:58 UTC, John Colvin wrote:
@property isn't really about parentheses-less calls
(parentheses are optional for all function calls), it's more
for this sort of thing:
[snip]
@property void val(int v)
{
a_ = (a_ flagMask) (v ~flagMask);
}
This is *really* cool and very useful on microcontrollers and is
superior to C's bit-fields.
Imagine that your microcontroller has 24 GPIO pins.
Such pins are usually grouped in 'ports', for instance Port A and
Port B.
Each port could for instance support up to 32 pins: PA0 ... PA31
and PB0 ... PB31.
But there's a problem here: Our microcontroller has only 24 pins,
and our microcontroller vendor chose to make the following pins
available to us:
PA1 ... PA5, PA7, PA13, PA17, PA18 .. PA19, PA23 ... PA28
PB0 ... PB3, PB8 ... PB12
Every developer will think this is annoying. We want to write a
byte to a port, but it has to be converted first.
If just incrementing a value, one could do as follows:
PortB = (PortB | 0x00f0) + 1;
... oposite for decrementing:
PortB = (PortB 0xff0f) - 1;
But the @property can make all this transparent, so our sources
become very easy to overview and understand.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 14:20:58 UTC, Jens Bauer wrote:
On Tuesday, 7 April 2015 at 08:33:58 UTC, John Colvin wrote:
@property isn't really about parentheses-less calls
(parentheses are optional for all function calls), it's more
for this sort of thing:
[snip]
@property void val(int v)
{
a_ = (a_ flagMask) (v ~flagMask);
}
This is *really* cool and very useful on microcontrollers and
is superior to C's bit-fields.
Imagine that your microcontroller has 24 GPIO pins.
Such pins are usually grouped in 'ports', for instance Port A
and Port B.
Each port could for instance support up to 32 pins: PA0 ...
PA31 and PB0 ... PB31.
But there's a problem here: Our microcontroller has only 24
pins, and our microcontroller vendor chose to make the
following pins available to us:
PA1 ... PA5, PA7, PA13, PA17, PA18 .. PA19, PA23 ... PA28
PB0 ... PB3, PB8 ... PB12
Every developer will think this is annoying. We want to write a
byte to a port, but it has to be converted first.
If just incrementing a value, one could do as follows:
PortB = (PortB | 0x00f0) + 1;
... oposite for decrementing:
PortB = (PortB 0xff0f) - 1;
But the @property can make all this transparent, so our sources
become very easy to overview and understand.
and, for convenience there is
http://dlang.org/phobos/std_bitmanip.html#.bitfields
Re: Why I'm Excited about D
On 4/6/15 4:51 PM, Adam Hawkins wrote: Hello everyone, this is my first post on the forum. I've been investigating the language for the past few weeks. I was able to complete my first useful program thanks to very helpful people in #d on IRC . The experience made me very interested in the language and improving the community around it. [snip] http://www.reddit.com/r/programming/comments/31rdp1/excited_about_d/ https://twitter.com/D_Programming/status/585472101349462020 https://www.facebook.com/dlang.org/posts/1046466315367049 Share away! Andrei
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 16:39:39 UTC, Jens Bauer wrote: :C - :D Even better (includes the meaning of '=' in place of 'when'): =C - =D
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 16:29:40 UTC, Walter Bright wrote: I noticed a bug in one of the examples: assert(Adam Hawkins == myName()); should be: assert(Adam Hawkins == myName()); -It already is. :) By the way; the reason to switch from C to D can be put *very* simple: :C - :D ... or if you prefer the longer version: :-C - :-D
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 06:28:49 UTC, Jacob Carlborg wrote: vibe.d has a template system. It's based on Jade, which seems to be based on Haml. Aye, though it is compile time rather than runtime which hurts the edit/run cycle - you have to recompile, redeploy (maybe), and restart just to see a quick text change. In my web projects. I used compile time stuff sometimes too, but the runtime loading ultimately won out for the ease of editing by me and by the frontend team - they can edit html too without needing to worry about rerunning a compiler.
Re: Why I'm Excited about D
On 4/6/2015 4:51 PM, Adam Hawkins wrote: Hello everyone, this is my first post on the forum. I've been investigating the language for the past few weeks. I was able to complete my first useful program thanks to very helpful people in #d on IRC . The experience made me very interested in the language and improving the community around it. I'm primarily Ruby developer (been so about the last 7-8 years) doing web stuff with significant JavaScript work as well. I wrote a blog post on why I'm excited about D. You can read it here: http://hawkins.io/2015/04/excited-about-d/. I've been reading the forums here so I can see that there is a focus on improving the marketing for the language and growing the community. I see most of the effort is geared towards C++ programmers, but have you considered looking at us dynamic languages folk? I see a big upside for us. Moving from Ruby to D (my case) gives me power performance. I still have OOP techniques but I still have functional things like closures and all that good stuff. Only trade off in the Ruby case is metaprogramming. All in all I think there is a significant value promise for those of us doing backend services for folks like me. Regardless, I figured it might be interesting to hear about some experience coming to the language from a different perspective. Cheers! This is a nice article, thanks! I noticed a bug in one of the examples: assert(Adam Hawkins == myName()); should be: assert(Adam Hawkins == myName());
Re: Why I'm Excited about D
On 2015-04-07 18:06, Adam D. Ruppe wrote: Aye, though it is compile time rather than runtime which hurts the edit/run cycle - you have to recompile, redeploy (maybe), and restart just to see a quick text change. Oh, right, that was what he meant with runtime :) -- /Jacob Carlborg
Re: Why I'm Excited about D
On 4/7/2015 9:28 AM, Walter Bright wrote: I noticed a bug in one of the examples: assert(Adam Hawkins == myName()); er, the example is: assert(Adam Hawkins = myName()); should be: assert(Adam Hawkins == myName());
Re: Why I'm Excited about D
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 17:46:45 UTC, Ary Borenszweig wrote: It's true that Ruby is slow, but only because their priority is correctness. https://www.destroyallsoftware.com/talks/wat
Re: Why I'm Excited about D
On 4/6/15 8:51 PM, Adam Hawkins wrote: Hello everyone, this is my first post on the forum. I've been investigating the language for the past few weeks. I was able to complete my first useful program thanks to very helpful people in #d on IRC . The experience made me very interested in the language and improving the community around it. I'm primarily Ruby developer (been so about the last 7-8 years) doing web stuff with significant JavaScript work as well. I wrote a blog post on why I'm excited about D. You can read it here: http://hawkins.io/2015/04/excited-about-d/. I've been reading the forums here so I can see that there is a focus on improving the marketing for the language and growing the community. I see most of the effort is geared towards C++ programmers, but have you considered looking at us dynamic languages folk? I see a big upside for us. Moving from Ruby to D (my case) gives me power performance. I still have OOP techniques but I still have functional things like closures and all that good stuff. Only trade off in the Ruby case is metaprogramming. All in all I think there is a significant value promise for those of us doing backend services for folks like me. Regardless, I figured it might be interesting to hear about some experience coming to the language from a different perspective. Cheers! Ruby was never intended to be correct - I think Ruby is the most correct language I've seen around. ~~~ a = [] a a p a #= [[...]] p a == a[0] #= true ~~~ This is just an example. Using Ruby and reading its source code I found so many things that they get right, like border-cases, that I'm surprised you say that. It's true that Ruby is slow, but only because their priority is correctness.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
Re: Why I'm Excited about D
On Tue, 07 Apr 2015 14:20:57 +, Jens Bauer wrote: If just incrementing a value, one could do as follows: PortB = (PortB | 0x00f0) + 1; ... oposite for decrementing: PortB = (PortB 0xff0f) - 1; But the @property can make all this transparent, so our sources become very easy to overview and understand. and gcc can optimise function calls away (especially with `@attribute(forceinline)`), so it effectively compiles to the same code. signature.asc Description: PGP signature
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 18:21:44 UTC, H. S. Teoh wrote: Actually, I find the current use of = vs. == in programming languages rather counterintuitive, even though I myself have become accustomed to it as you have. If I were ever to invent my own programming language, I'd use = for equality and := for assignment. (I wouldn't include ==, though; I think it's an eyesore.) Simula uses =, =, =, for value comparison. For references comparison: ==, =/=. Value assignment is done with := and :- is used for reference assignment. I am not sure if I like the visual confusion of references and values in languages like C# and D, but I am also not happy about having to type *this in C++... With reference operators you bypass all the dereferencing clutter.
Re: Why I'm Excited about D
On Tue, Apr 07, 2015 at 11:04:35AM -0700, Walter Bright via Digitalmars-d wrote: On 4/7/2015 10:33 AM, bachmeier wrote: You're such a good programmer that you can't write code with a bug in it even if you try. We're all susceptible to making certain types of errors. Over time, we learn to compensate for those errors, and don't make them any more. I can't remember the last time I made the = == mistake. It's probably why that error in the article glared out at me. If you really want to mess with my head, design a language with = and == reversed. Actually, I find the current use of = vs. == in programming languages rather counterintuitive, even though I myself have become accustomed to it as you have. If I were ever to invent my own programming language, I'd use = for equality and := for assignment. (I wouldn't include ==, though; I think it's an eyesore.) T -- It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca
Re: Why I'm Excited about D
On 04/07/2015 06:06 PM, Adam D. Ruppe wrote: In my web projects. I used compile time stuff sometimes too, but the runtime loading ultimately won out for the ease of editing by me and by the frontend team - they can edit html too without needing to worry about rerunning a compiler. That's why I spent quite some time reducing that cycle and worked on a dub watch command. https://github.com/D-Programming-Language/dub/pull/388 https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html https://github.com/D-Programming-Language/dub/pull/446 What's still missing is a faster AST interpreter for CTFE though.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 17:03:55 UTC, Walter Bright wrote: On 4/7/2015 9:28 AM, Walter Bright wrote: I noticed a bug in one of the examples: assert(Adam Hawkins == myName()); er, the example is: assert(Adam Hawkins = myName()); should be: assert(Adam Hawkins == myName()); You're such a good programmer that you can't write code with a bug in it even if you try.
Re: Why I'm Excited about D
On 4/7/2015 10:33 AM, bachmeier wrote: You're such a good programmer that you can't write code with a bug in it even if you try. We're all susceptible to making certain types of errors. Over time, we learn to compensate for those errors, and don't make them any more. I can't remember the last time I made the = == mistake. It's probably why that error in the article glared out at me. If you really want to mess with my head, design a language with = and == reversed.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Re: Why I'm Excited about D
On 4/7/15 3:34 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like writeln being used with UFCS, it's an abuse.
My point is that every language has WATs :-)
Re: Why I'm Excited about D
even if, to be fair, the prototyping part is way much easier in python... But that may be due to the gab of experience). what - beyond a richer choice of libraries (and documentation, including examples) would make D comparable to python in terms of prototyping ease?
Re: Why I'm Excited about D
On Tue, Apr 07, 2015 at 04:46:07PM -0300, Ary Borenszweig via Digitalmars-d
wrote:
On 4/7/15 3:34 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like writeln being used with UFCS, it's an abuse.
My point is that every language has WATs :-)
My current favorite WAT in D is:
import std.stdio;
void fun(string text) {
import std.conv;
writeln(text);
}
void main() {
fun(Hello world);
}
This program outputs a blank line. :-)
T
--
A mathematician is a device for turning coffee into theorems. -- P. Erdos
Re: Why I'm Excited about D
On 4/7/15 3:27 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 22:24:21 UTC, Andrei Alexandrescu wrote:
My current favorite WAT in D is:
import std.stdio;
void fun(string text) {
import std.conv;
writeln(text);
}
void main() {
fun(Hello world);
}
This program outputs a blank line. :-)
Yeah, I think it's urgent we fix that. -- Andrei
My favorite next:
void function() f;
static assert(is(f == function)); // OK
void delegate() dg;
static assert(is(f == delegate)); // Nope...
(I assume you meant dg here.)
This doesn't strike me as big, but it is weird.
Note that even phobos can get confused with that one in some cases.
Are there bugzillas for these two matters?
Andrei
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 22:24:21 UTC, Andrei Alexandrescu
wrote:
My current favorite WAT in D is:
import std.stdio;
void fun(string text) {
import std.conv;
writeln(text);
}
void main() {
fun(Hello world);
}
This program outputs a blank line. :-)
Yeah, I think it's urgent we fix that. -- Andrei
My favorite next:
void function() f;
static assert(is(f == function)); // OK
void delegate() dg;
static assert(is(f == delegate)); // Nope...
Note that even phobos can get confused with that one in some
cases.
Re: Why I'm Excited about D
On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu wrote: On 4/7/15 11:42 AM, Martin Nowak wrote: What's still missing is a faster AST interpreter for CTFE though. A JIT would be nice. -- Andrei I'm not so sure CTFE would ever get out of the warmup debt JITs incur, ctfe bits usually don't live very long.
Re: Why I'm Excited about D
On 4/7/15 3:29 PM, Adam D. Ruppe wrote: On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu wrote: On 4/7/15 11:42 AM, Martin Nowak wrote: What's still missing is a faster AST interpreter for CTFE though. A JIT would be nice. -- Andrei I'm not so sure CTFE would ever get out of the warmup debt JITs incur, ctfe bits usually don't live very long. A JIT would pay off where it matters - intensive use of CTFE leading to long compilations. -- Andrei
Re: Why I'm Excited about D
On 4/7/15 11:42 AM, Martin Nowak wrote: What's still missing is a faster AST interpreter for CTFE though. A JIT would be nice. -- Andrei
Re: Why I'm Excited about D
On 4/7/15 1:11 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Apr 07, 2015 at 04:46:07PM -0300, Ary Borenszweig via Digitalmars-d
wrote:
On 4/7/15 3:34 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 18:01:53 UTC, Ary Borenszweig wrote:
On 4/7/15 2:16 PM, deadalnix wrote:
On Tuesday, 7 April 2015 at 08:58:57 UTC, ixid wrote:
Or to be more consistent with UFCS:
foreach (name; names.parallel) {
name.writeln;
}
no.please
wat
unreadable.is.ufcs.using.over
Yes, I don't like writeln being used with UFCS, it's an abuse.
My point is that every language has WATs :-)
My current favorite WAT in D is:
import std.stdio;
void fun(string text) {
import std.conv;
writeln(text);
}
void main() {
fun(Hello world);
}
This program outputs a blank line. :-)
Yeah, I think it's urgent we fix that. -- Andrei
Re: Why I'm Excited about D
On 4/7/2015 3:30 PM, Andrei Alexandrescu wrote: A JIT would pay off where it matters - intensive use of CTFE leading to long compilations. -- Andrei A decent interpreter would fix most of CTFE's performance problems, no need to go as far as a JIT.
Re: Why I'm Excited about D
On 4/7/15 4:54 PM, deadalnix wrote: On Tuesday, 7 April 2015 at 22:59:00 UTC, Walter Bright wrote: On 4/7/2015 3:30 PM, Andrei Alexandrescu wrote: A JIT would pay off where it matters - intensive use of CTFE leading to long compilations. -- Andrei A decent interpreter would fix most of CTFE's performance problems, no need to go as far as a JIT. What is a JIT if not an interpreter with hardware support ? Nah. It's a fundamentally different approach to the same problem. -- Andrei
