On 2014-06-27 03:16, Nick Sabalausky wrote:
There's other times I've had to get by without debuggers too. Like, in
the earlier days of web dev, it was common to not have a debugger. Or
debugging JS problems that only manifested on Safari (I assume Safari
probably has JS diagnostics/debugging
On 2014-06-27 00:57, Sean Kelly wrote:
Yep. A lot of this is probably because as a server programmer
I've just gotten used to finding bugs this way as a matter of
necessity, but in many cases I actually prefer it to interactive
debugging. For example, build core.demangle with -debug=trace
and
On 27 June 2014 11:16, Nick Sabalausky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 6/26/2014 7:24 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 10:57:28PM +, Sean Kelly via Digitalmars-d
wrote:
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky
On Friday, 27 June 2014 at 02:11:50 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via
Digitalmars-d wrote:
[...]
Aye. Sometimes in embedded work, you're *lucky* if you can
even do
printf at all, let alone a debugger. I've had to debug with
On 6/26/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
Aye. Sometimes in embedded work, you're *lucky* if you can even do
printf at all, let alone a debugger. I've had to debug with as little
as one
On Fri, Jun 27, 2014 at 03:36:08PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 6/26/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
Aye. Sometimes in embedded work, you're *lucky* if you can
On Sunday, 15 June 2014 at 15:37:51 UTC, Caligo via Digitalmars-d
wrote:
I can't take a blog post seriously when it's poorly written and
full of
grammatical errors. If you are in an engineering field of any
kind, and
you can't construct a paragraph in your favorite natural
language, you're
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
That's why I inadvertently learned to love printf debugging. I
get to see the whole chart at one.
Yep. A lot of this is probably because as a server programmer
I've just gotten used to finding bugs this way as a matter of
On Thu, Jun 26, 2014 at 10:57:28PM +, Sean Kelly via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
That's why I inadvertently learned to love printf debugging. I get to
see the whole chart at one.
Yep. A lot of this is probably because as a
On 6/26/2014 7:24 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 26, 2014 at 10:57:28PM +, Sean Kelly via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
That's why I inadvertently learned to love printf debugging. I get to
see the whole chart
On Thu, Jun 26, 2014 at 09:16:27PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
Aye. Sometimes in embedded work, you're *lucky* if you can even do
printf at all, let alone a debugger. I've had to debug with as little
as one LED. It's...umm...interesting. And time consuming.
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
That's why I inadvertently learned to love printf debugging. I
get to see the whole chart at one. Granted, it's in a bit of
a The Matrix-style only comprehensible if you know what
you're looking at kind of way. Actual GUI graphs
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
That's why I inadvertently learned to love printf debugging. I
get to see the whole chart at one. Granted, it's in a bit of
a The Matrix-style only comprehensible if you know what
you're looking at kind of way. Actual GUI graphs
On Wednesday, 18 June 2014 at 19:08:17 UTC, c0de517e wrote:
Exactly. When I write that engineers have to understand how
market works it's not that I don't understand what's
technically good and bad, but that's not how things become
successful. And there's nothing wrong with the fact that soft
On Thursday, 19 June 2014 at 13:52:12 UTC, Kagamin wrote:
On Wednesday, 18 June 2014 at 19:08:17 UTC, c0de517e wrote:
Exactly. When I write that engineers have to understand how
market works it's not that I don't understand what's
technically good and bad, but that's not how things become
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
certainly be nice. But all the data's there at once, so no
need for constant fast-fowarding and rewindi...oh wait, that's
right, debuggers can't rewind either. ;)
Oh?
https://www.gnu.org/software/gdb/news/reversible.html
On Thursday, 19 June 2014 at 19:22:23 UTC, Wyatt wrote:
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky
wrote:
certainly be nice. But all the data's there at once, so no
need for constant fast-fowarding and rewindi...oh wait, that's
right, debuggers can't rewind either. ;)
Oh?
On Thu, Jun 19, 2014 at 07:22:22PM +, Wyatt via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
certainly be nice. But all the data's there at once, so no need for
constant fast-fowarding and rewindi...oh wait, that's right,
debuggers can't rewind
On Wednesday, 18 June 2014 at 03:28:48 UTC, Sean Cavanaugh wrote:
On 6/15/2014 4:34 PM, Joakim wrote:
He clarifies in the comments:
D is not 'high-performance' the same way as C and C++ are
not. Systems
is not the same as high-performance. Fortran always has been
more
'high-performance'
On Wednesday, 18 June 2014 at 05:48:14 UTC, Andrei Alexandrescu
wrote:
On 6/16/14, 9:24 PM, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on
c0de517e.
[snip]
Thanks for chiming in! -- Andrei
Hi Andrei! I had a little stab at your hugely influential book in
the
On 6/17/2014 3:20 PM, c0de517e wrote:
The issue I have with metaprogramming (and overloading and some other similar
ideas) is that it makes a statement dependent on a lot of context, this is
tricky in a large team as now just reading a change doesn't really tell much.
Our is an industry where we
On the other hand, we've already given up on a great deal of
knowing exactly what a statement does, even in C. How many of
us program in assembly anymore? How many of us can even make
sense of assembly code?
It is absolutely necessary to move to higher levels of
abstraction in order to
On Wednesday, 18 June 2014 at 06:28:16 UTC, c0de517e wrote:
So I'm curious, do you think certain concepts went too far,
that we should educate against some hypes and abuses, or you
think that it's just my very partial view of the world and if
looking at the C++ community at large, template
It is absolutely necessary to move to higher levels of
abstraction in order to handle the increasing complexity of
modern programs.
And this is 100% right, but people should be educated about
premature abstraction. Have you seen the horrors of
generalization?
Especially C++ neophytes get
On Wednesday, 18 June 2014 at 07:00:44 UTC, c0de517e wrote:
It is absolutely necessary to move to higher levels of
abstraction in order to handle the increasing complexity of
modern programs.
And this is 100% right, but people should be educated about
premature abstraction. Have you seen the
On 6/18/2014 1:05 AM, c0de517e wrote:
On Wednesday, 18 June 2014 at 03:28:48 UTC, Sean Cavanaugh wrote:
I had a nice sad 'ha ha' moment when I realized that msvc can't cope
with restrict on the pointers feeding into the simd intrinsics; you
have to cast it away. So much for that perf :)
On Wednesday, 18 June 2014 at 05:20:39 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Jun 18, 2014 at 02:18:47AM +, c0de517e via
Now you're talking polymorphism again, [...] and it's actually
not really metaprogramming, it's just
fancier typing.
Actually I was talking about templates:
On 6/17/2014 11:54 PM, c0de517e wrote:
The intention is to make people -aware- of certain issues, to then make better
motivated choices and not end up thinking stuff like this is cool
http://www.boost.org/doc/libs/1_55_0b1/libs/geometry/doc/html/geometry/design.html
(sorry, I've linked this a
Actually I was talking about templates:
R find(R,T)(R range, T element)
if (isInputRange!R is(ElementType!R : T))
{
while (!range.empty)
{
if (range.front == element)
break;
On Tuesday, 17 June 2014 at 04:24:54 UTC, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on
c0de517e.
Hi, I think the general idea of your post is 100% accurate, the
bigger risk for D is people not willing to move from C++. I work
in C++ full-time and it's an
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand what people think of D. I
can confirm this sentiment is fairly
deadalnix wrote in message news:qawhxkzqdgzjwylzr...@forum.dlang.org...
I call them architecture astronautes. To avoid that pitfall, I have a
adopted the following method :
- Do whatever you need to to get to the next step toward you goal.
- Make a pause and observe. Is there some
On 18/06/2014 8:21 p.m., Wanderer wrote:
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I think
it's important we understand what people think of
On Wednesday, 18 June 2014 at 08:27:57 UTC, Rikki Cattermole
wrote:
On 18/06/2014 8:21 p.m., Wanderer wrote:
3. Stable, efficient and well-documented runtime library,
including
collection classes, IO, date/time, concurrency, GUI, graphics,
sound etc.
I don't really think big standard
On Tuesday, 17 June 2014 at 03:16:16 UTC, Caligo via
Digitalmars-d wrote:
My rant wasn't about his lack of fluency in the English
language. You
only learn once what a sentence is, and the concept translates
over to
most other natural languages.
How would you translate an arbitrary sentence
On Wednesday, 18 June 2014 at 07:58:57 UTC, c0de517e wrote:
People think that implementing interfaces is for some reason
inherently slower than templates, the same they believe
function pointers are slower than functors. It's FALSE. The
ONLY reason why templates and functors can be faster is
On 06/17/14 22:15, Walter Bright via Digitalmars-d wrote:
On 6/17/2014 6:12 AM, Artur Skawina via Digitalmars-d wrote:
immediately realized that he now does not want to live w/o this
functionality)
I don't think I can take that kind of pressure!
I was responding to text editor sees only
On 18 June 2014 08:27, c0de517e via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Given that he lives in Italy, it's safe to assume that English is not his
first language. But rather than consider what he has to say or dispute his
arguments, you completely dismissed his point of view because
On Wed, Jun 18, 2014 at 07:58:56AM +, c0de517e via Digitalmars-d wrote:
Actually I was talking about templates:
R find(R,T)(R range, T element)
if (isInputRange!R is(ElementType!R : T))
{
while (!range.empty)
{
My opinion: if you want D to smoothly replace both C++ and
Java, simply do the following:
1. Sane language specification (which doesn't allow a slice of
a stack-allocated array to escape to other part of a program,
doesn't allow an object to contain garbage under ANY
circumstances etc).
2.
On Wed, Jun 18, 2014 at 07:00:43AM +, c0de517e via Digitalmars-d wrote:
It is absolutely necessary to move to higher levels of abstraction in
order to handle the increasing complexity of modern programs.
And this is 100% right, but people should be educated about premature
abstraction.
You're talking about compile-time codegen? Like D's ctRegex
perhaps?
import std.regex;
// Statically generates a regex engine that matches the given
// expression.
auto r = ctRegex!`(a+b(cd*)+)?z`;
Looks nifty. As I said it's not that I want to ban a given
On Wednesday, 18 June 2014 at 07:58:57 UTC, c0de517e wrote:
People think that implementing interfaces is for some reason
inherently slower than templates, the same they believe
function pointers are slower than functors. It's FALSE. The
ONLY reason why templates and functors can be faster is
On Wednesday, 18 June 2014 at 16:19:25 UTC, c0de517e wrote:
But as I wrote I doubt that people will think at a point that
yes, now D is 100% a better version of C++/Java/younameit,
let's switch. I don't think it's how things go, I think
successful languages find one thing a community really
Also I think all this discussion about template and generics
totally misses the point about meta-programming. It is not about
just code generation or replacing few type declarations, main
thing is compile-time reflection. The fact we use templates is
just a mere implementation details. What
On Wednesday, 18 June 2014 at 16:55:53 UTC, Dicebot wrote:
On Wednesday, 18 June 2014 at 16:19:25 UTC, c0de517e wrote:
But as I wrote I doubt that people will think at a point that
yes, now D is 100% a better version of C++/Java/younameit,
let's switch. I don't think it's how things go, I
On Wednesday, 18 June 2014 at 18:17:03 UTC, deadalnix wrote:
This is, but that's how it works nevertheless. You don't
succeed by arguing what the reality should be, but by accepting
what it is and act accordingly.
Being ashamed of it instead of glorifying such attitude is one
way to motivate
On Wednesday, 18 June 2014 at 18:18:28 UTC, Dicebot wrote:
On Wednesday, 18 June 2014 at 18:17:03 UTC, deadalnix wrote:
This is, but that's how it works nevertheless. You don't
succeed by arguing what the reality should be, but by
accepting what it is and act accordingly.
Being ashamed of it
I think this is actually a flawed mentality that causes a lot
of long-term problems to all programmers. By resisting to
switch to languages simply because those are good we
inevitably get to the point of switching because it is forced
by some corporation that has bucks to create an intrusive
On 6/18/2014 3:09 PM, c0de517e wrote:
On Wednesday, 18 June 2014 at 18:18:28 UTC, Dicebot wrote:
On Wednesday, 18 June 2014 at 18:17:03 UTC, deadalnix wrote:
This is, but that's how it works nevertheless. You don't succeed by
arguing what the reality should be, but by accepting what it is and
On Wednesday, 18 June 2014 at 16:55:53 UTC, Dicebot wrote:
On Wednesday, 18 June 2014 at 16:19:25 UTC, c0de517e wrote:
But as I wrote I doubt that people will think at a point that
yes, now D is 100% a better version of C++/Java/younameit,
let's switch. I don't think it's how things go, I
On Wednesday, 18 June 2014 at 19:09:08 UTC, c0de517e wrote:
On Wednesday, 18 June 2014 at 18:18:28 UTC, Dicebot wrote:
On Wednesday, 18 June 2014 at 18:17:03 UTC, deadalnix wrote:
This is, but that's how it works nevertheless. You don't
succeed by arguing what the reality should be, but by
You can casually mention how much of a wasted efforts and daily
inconvenience such attitude causes to your co-workers (in a
gentle non-intrusive way!). You can start acting _as if_
mentality is different instead of going the route of imaginary
pragmatism.
In practice acting intentionally
On Tuesday, 17 June 2014 at 22:24:06 UTC, c0de517e wrote:
Visualization would be a great tool, it's quite surprising if
you think about it that we can't in any mainstream debugger
just graph over time the state of objects, create UIs and so on.
I recently did write a tiny program that does
On 6/18/2014 5:39 PM, Joakim wrote:
Software pumps data in,
operates on it, and pumps new data out: why don't we have proper
visualization tools for those data flows? Only being able to freeze
program state and inspect it at repeated snapshots in time with a
debugger is so backwards:
That's
On Thursday, 19 June 2014 at 05:35:06 UTC, Nick Sabalausky wrote:
That's why I inadvertently learned to love printf debugging. I
get to see the whole chart at one. Granted, it's in a bit of
a The Matrix-style only comprehensible if you know what
you're looking at kind of way. Actual GUI graphs
On Tuesday, 17 June 2014 at 04:24:54 UTC, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on
c0de517e.
...
Thanks for coming here and clarifying your point of view despite
our zealous bashing :) Welcome!
On Tuesday, 17 June 2014 at 04:03:23 UTC, Mike Parker wrote:
On 6/17/2014 12:16 PM, Caligo via Digitalmars-d wrote:
My rant wasn't about his lack of fluency in the English
language. You
only learn once what a sentence is, and the concept translates
over to
most other natural languages. The
On Tuesday, 17 June 2014 at 03:08:48 UTC, Walter Bright wrote:
Assuming you are talking about C macros:
I was talking about macros in general. :-)
expert on the C preprocessor. Why would a freakin' macro
processor even have an ecological niche for a world leading
expert on it? The mind
On 6/16/2014 9:24 PM, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on c0de517e.
Welcome - nice of you to drop by!
On 17/06/14 06:44, H. S. Teoh via Digitalmars-d wrote:
String mixins? Auto-completion? I dunno, that sounds like a stretch to
me. How would an IDE handle autocompletion for things like like:
string generateCode() {
string code = int x=;
if
On Tuesday, 17 June 2014 at 08:23:08 UTC, Jacob Carlborg wrote:
That would require semantic analysis. Basically evaluate the
string mixin and to autocomplete on the resulted code.
But consider something like gofix/dfix where you have to
propagate changes back to the original prefix string.
On 6/17/2014 4:43 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 17 June 2014 at 08:23:08 UTC, Jacob Carlborg wrote:
That would require semantic analysis. Basically evaluate the string
mixin and to autocomplete on the resulted code.
But consider something like
On 6/16/2014 9:32 PM, H. S. Teoh via Digitalmars-d wrote:
Do string mixins have scoping of names?
Yes, of course, since they are D code.
And how would you syntax-highlight a string mixin that's assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees
Am 17.06.2014 11:30, schrieb Walter Bright:
And how would you syntax-highlight a string mixin that's assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D code.
the text editor sees just D-code-Strings - so no syntax-highlight except
that
On Tuesday, 17 June 2014 at 09:17:21 UTC, Nick Sabalausky wrote:
I think you're hitting on the fundamental limitations of
automated code-updating tools here: They can't be treated as
trusted black-boxes.
I don't think this is a fundamental limitation of tools, but a
consequence of language
On Tuesday, 17 June 2014 at 10:25:39 UTC, dennis luehring wrote:
Am 17.06.2014 11:30, schrieb Walter Bright:
And how would you syntax-highlight a string mixin that's
assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D
code.
the text
On Tuesday, 17 June 2014 at 10:25:39 UTC, dennis luehring wrote:
Am 17.06.2014 11:30, schrieb Walter Bright:
And how would you syntax-highlight a string mixin that's
assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D
code.
the text
On 06/17/14 11:30, Walter Bright via Digitalmars-d wrote:
On 6/16/2014 9:32 PM, H. S. Teoh via Digitalmars-d wrote:
And how would you syntax-highlight a string mixin that's assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D code.
On Tuesday, 17 June 2014 at 13:13:00 UTC, Artur Skawina via
Digitalmars-d wrote:
artur (who implemented both features last weekend; it started
out as a
fun let's-see-how-D-would-look-if-it-had-this-project, but
after making
them work and then converting a few small programs, almost
immediately
On Tuesday, 17 June 2014 at 13:24:11 UTC, Dicebot wrote:
On Tuesday, 17 June 2014 at 13:13:00 UTC, Artur Skawina via
Digitalmars-d wrote:
artur (who implemented both features last weekend; it started
out as a
fun let's-see-how-D-would-look-if-it-had-this-project, but
after making
them work and
On Tuesday, 17 June 2014 at 13:36:48 UTC, John Colvin wrote:
On Tuesday, 17 June 2014 at 13:24:11 UTC, Dicebot wrote:
On Tuesday, 17 June 2014 at 13:13:00 UTC, Artur Skawina via
Digitalmars-d wrote:
artur (who implemented both features last weekend; it started
out as a
fun
On Tuesday, 17 June 2014 at 13:36:48 UTC, John Colvin wrote:
also, foreach that works outside of function scope would be
awesome:
mixin template A(TL ...)
{
foreach(i, T; TL)
{
mixin(T v ~ i.to!string);
}
}
It is not also, it is primary use case of
On Tuesday, 17 June 2014 at 13:52:48 UTC, Dicebot wrote:
On Tuesday, 17 June 2014 at 13:36:48 UTC, John Colvin wrote:
also, foreach that works outside of function scope would be
awesome:
mixin template A(TL ...)
{
foreach(i, T; TL)
{
mixin(T v ~ i.to!string);
On Tuesday, 17 June 2014 at 14:00:44 UTC, John Colvin wrote:
I though the primary use of static foreach was to force the
compiler to attempt compile-time iteration even for
non-TemplateArgList arguments like arrays known at compile-time
If static foreach acts as code generator there is no
On 06/17/2014 04:00 PM, John Colvin wrote:
I though the primary use of static foreach was to force the
compiler to attempt compile-time iteration even for
non-TemplateArgList arguments like arrays known at compile-time
e.g.
static foreach(el; [1,2,3,4])
{
pragma(msg, el);
}
or
static
On 06/17/2014 03:36 PM, John Colvin wrote:
also, foreach that works outside of function scope would be awesome:
mixin template A(TL ...)
{
foreach(i, T; TL)
{
mixin(T v ~ i.to!string);
}
}
Also, identifier mixins might then somewhat clean up a lot of code. The
On Tue, Jun 17, 2014 at 11:16:22AM +, via Digitalmars-d wrote:
On Tuesday, 17 June 2014 at 09:17:21 UTC, Nick Sabalausky wrote:
I think you're hitting on the fundamental limitations of automated
code-updating tools here: They can't be treated as trusted
black-boxes.
I don't think this
On 06/17/2014 01:16 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 17 June 2014 at 09:17:21 UTC, Nick Sabalausky wrote:
I think you're hitting on the fundamental limitations of automated
code-updating tools here: They can't be treated as trusted black-boxes.
I
On Tuesday, 17 June 2014 at 16:34:23 UTC, Timon Gehr wrote:
On 06/17/2014 01:16 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Programming languages are in general still quite primitive
(not specific
to D), they still rely on convention rather than formalisms.
...
On Tuesday, 17 June 2014 at 16:08:18 UTC, H. S. Teoh via
Digitalmars-d wrote:
I think you are underestimating the complexity of programming.
No need to go ad hominem. I don't underestimate anything. What
makes you think so?
Automated
tools can only go so far -- ultimately, human intervention
On 06/17/2014 06:53 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 17 June 2014 at 16:34:23 UTC, Timon Gehr wrote:
On 06/17/2014 01:16 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Programming languages are in general still quite primitive
On Tue, Jun 17, 2014 at 04:50:07PM +, via Digitalmars-d wrote:
On Tuesday, 17 June 2014 at 16:08:18 UTC, H. S. Teoh via
Digitalmars-d wrote:
I think you are underestimating the complexity of programming.
No need to go ad hominem. I don't underestimate anything. What
makes you think so?
On Tuesday, 17 June 2014 at 17:03:34 UTC, Timon Gehr wrote:
If you are only talking about those languages, not at all.
Yes, I was only talking about the ones that are suitable for
creating commercial games given the topic of the thread.
(Languages that are based on Horn-clauses and the like
On Tuesday, 17 June 2014 at 17:19:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
The halting problem is equivalent to Kolgomorov complexity,
which in
turn relates to optimal compression, which has applications in
global
optimization problems in compiler technology. Sure, the way some
textbooks
On Tue, Jun 17, 2014 at 06:08:57PM +, via Digitalmars-d wrote:
On Tuesday, 17 June 2014 at 17:19:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
[...]
There's no need to get rid of string mixins just because of that 1%
of code that actually needs to use them. Nobody says that the
On Tuesday, 17 June 2014 at 18:24:22 UTC, H. S. Teoh via
Digitalmars-d wrote:
How would the compiler (or any tool!) detect the use (or
non-use) of
deprecated features here?
You compile it or detect AST-node presence.
If you want it to run in a browser, and the browser doesn't
support
On Tue, Jun 17, 2014 at 06:58:27PM +, via Digitalmars-d wrote:
On Tuesday, 17 June 2014 at 18:24:22 UTC, H. S. Teoh via Digitalmars-d
wrote:
How would the compiler (or any tool!) detect the use (or non-use) of
deprecated features here?
You compile it or detect AST-node presence.
You
On 6/17/2014 3:25 AM, dennis luehring wrote:
the text editor sees just D-code-Strings - so no syntax-highlight except that
for Strings
The syntax highlighter could highlight q{ ... } strings differently, if it chose
to, with little difficulty.
On 6/17/2014 6:12 AM, Artur Skawina via Digitalmars-d wrote:
rtur (who implemented both features last weekend; it started out as a
fun let's-see-how-D-would-look-if-it-had-this-project, but after making
them work and then converting a few small programs,
Taking action rather than debating - I
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand what people think of D. I
can confirm this sentiment is fairly
On Sunday, 15 June 2014 at 13:50:10 UTC, Peter Alexander wrote:
On Sunday, 15 June 2014 at 11:45:30 UTC, Dicebot wrote:
I like how he says that productivity is important and mentions
fear of meta-programming in the same article ;)
That's true, but meta programming is just a tool. Would be
On Sunday, 15 June 2014 at 11:45:30 UTC, Dicebot wrote:
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand what
Given that he lives in Italy, it's safe to assume that English
is not his first language. But rather than consider what he has
to say or dispute his arguments, you completely dismissed his
point of view because his level of writing doesn't meet your
standards. Furthermore, you unjustly called
On Tuesday, 17 June 2014 at 19:24:54 UTC, H. S. Teoh via
Digitalmars-d wrote:
You can also compile a string mixin to detect if it uses
deprecated features, no?
Not if it depends on configuration.
Also, detecting AST node presence is unreliable. What if it's
needed for
compatibility with
On Sunday, 15 June 2014 at 18:50:14 UTC, Meta wrote:
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand what
The issue I have with metaprogramming (and overloading and some
other similar ideas) is that it makes a statement dependent on
a lot of context, this is tricky in a large team as now just
reading a change doesn't really tell much. Our is an industry
where we still exercise a lot of control, we
On Sunday, 15 June 2014 at 19:53:54 UTC, Walter Bright wrote:
On 6/15/2014 12:27 PM, Nick Sabalausky wrote:
It really gets me that the same industry which created
Frostbite 3, Unreal
Engine 4, GTA5, Steam (obviously all enormous investments),
mostly done *in* C++
which makes them that much
Anyway to make D attractive to game development?
1. VisualD needs to be on par with Visual Assist
2. D needs to figure out what the hell it is doing with
GC/RC/Memory
3. Target all common platforms
4. Allow for C++ and D to call each other without requiring a C
interop layer.(not going to
On Tuesday, 17 June 2014 at 22:58:58 UTC, Araq wrote:
The issue I have with metaprogramming (and overloading and
some other similar ideas) is that it makes a statement
dependent on a lot of context, this is tricky in a large team
as now just reading a change doesn't really tell much. Our is
1 - 100 of 217 matches
Mail list logo
