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
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
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
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#
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#
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
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
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
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
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
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
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
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
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
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
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
On 2015-04-07 19:53, deadalnix wrote:
https://www.destroyallsoftware.com/talks/wat
That is mostly for JavaScript.
--
/Jacob Carlborg
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
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:
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
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) {
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
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
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
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
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
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
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
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
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.
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
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
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) {
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?
On 4/8/15 2:24 AM, Idan Arye wrote:
At the very least, put () after the writelne:
No. -- Andrei
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.
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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:
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
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
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
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
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
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.
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,
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
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
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
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
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
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
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;
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
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.
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
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
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);
}
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)
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
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
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
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
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
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
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());
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
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
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
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
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
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
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
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
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());
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
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
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
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?
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
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);
}
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);
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
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
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
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
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.
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
1 - 100 of 122 matches
Mail list logo
