A new blog post by the very good John Carmack, I like how well readable this
post is:
http://altdevblogaday.com/2011/12/24/static-code-analysis/
If you don't know who he is:
http://en.wikipedia.org/wiki/John_Carmack
Beside the main point of the article that is to use more static analysis tools,
On Saturday, 24 December 2011 at 12:42:41 UTC, bearophile wrote:
Printf format string errors were the second biggest issue in
A problem that people didn't want to reduce in D.
printf and writef are entirely different beasts.
On Sat, 24 Dec 2011 23:42:41 +1100, bearophile
wrote:
A new blog post by the very good John Carmack, I like how well readable
this post is:
http://altdevblogaday.com/2011/12/24/static-code-analysis/
... human minds and the logic of lint programs are two cognitive (or
pre-cognitive) syste
On 12/24/2011 06:42 AM, bearophile wrote:
A new blog post by the very good John Carmack, I like how well
readable this post is:
http://altdevblogaday.com/2011/12/24/static-code-analysis/
Nice! One nice snippet that I can't quote strongly enough:
"Automation is necessary. It is common to take
On 12/24/2011 09:11 AM, Derek wrote:
On Sat, 24 Dec 2011 23:42:41 +1100, bearophile
wrote:
In theory functional-style is a good to shrink the code, but in D
functional-style code is a jungle of (({}){()}) so it's hard to write
and hard to read.
As I mentioned once, the proposition of writing
On Saturday, 24 December 2011 at 15:33:04 UTC, Andrei
Alexandrescu wrote:
Anyhow, is there anything you have in mind that we have the
chance of improving at this point?
Thanks,
Andrei
For one, we should follow up on:
foo!(a => a * 2)(bar);
vs.
foo!((a) { return a * 2; })(bar);
On Sun, 25 Dec 2011 02:33:01 +1100, Andrei Alexandrescu
wrote:
We recently discussed this a bit in connection with the standard
library. It definitely could be written in a manner that is easier to
understand for the more casual reader, but that would mean reducing the
capabilities (e.g
On 2011-12-24 13:42, bearophile wrote:
There was a paper recently that noted that all of the various code quality metrics
correlated at least as strongly with code size as error rate, making code size
alone give essentially the same error predicting ability. Shrink your important
code.<
In
On 12/24/2011 6:35 AM, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 12:42:41 UTC, bearophile wrote:
Printf format string errors were the second biggest issue in
A problem that people didn't want to reduce in D.
printf and writef are entirely different beasts.
D's charter is not to
On 12/24/2011 11:30 AM, Walter Bright wrote:
On 12/24/2011 6:35 AM, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 12:42:41 UTC, bearophile wrote:
Printf format string errors were the second biggest issue in
A problem that people didn't want to reduce in D.
printf and writef are entir
On 12/24/11 9:45 AM, Jakob Ovrum wrote:
On Saturday, 24 December 2011 at 15:33:04 UTC, Andrei Alexandrescu wrote:
Anyhow, is there anything you have in mind that we have the chance of
improving at this point?
Thanks,
Andrei
For one, we should follow up on:
foo!(a => a * 2)(bar);
vs.
foo!
On 12/24/11 9:54 AM, Derek wrote:
I'm sure you are totally correct; I'm not really a C++ coder. And I'm
sure you also process the specialist/expert level of D knowledge to make
reading contemporary D code a non-issue.
Well I'm also a specialist in C++, actually more so than D as I have
longer
Andrei Alexandrescu:
> the notion that people need to maintain, enhance, and modify a
> large body of natural language text is quite foreign.
http://www.wikipedia.org/ ?
Bye,
bearophile
Derek Parnell:
> But isn't lint written by humans?
Right, but this doesn't mean a lot, because most programs don't work the same
way humans and human brains think.
>I'm under the impression that a //lint// program is an attempt to emulate a
>very pedantic (if not anal-retentive) person who in
On 12/24/2011 12:38 PM, bearophile wrote:
Andrei Alexandrescu:
the notion that people need to maintain, enhance, and modify a
large body of natural language text is quite foreign.
http://www.wikipedia.org/ ?
Wikipedia's text often shows an effect of maintenance similar to source code -
add
Andrei Alexandrescu:
>Anyhow, is there anything you have in mind that we have the chance of
>improving at this point?<
Two things that I think are able to improve the D code (beside a shorter lambda
syntax) are Python Lazy/eager array comps (I'd like to write a post about
this...).
If this is
On 12/24/11 2:55 PM, bearophile wrote:
If this is not possible then I think introducing amap and afilter
(that means array(map()) and array(filter())) in Phobos is able to
remove several parentheses from my current D code.
I've never gotten why you wouldn't define amap and afilter for your own
On Saturday, 24 December 2011 at 12:42:41 UTC, bearophile wrote:
In theory functional-style is a good to shrink the code, but in
D functional-style code is a jungle of (({}){()}) so it's hard
to write and hard to read.
I think code would have a lot fewer bugs if we forced all
identifiers
to
On Sun, 25 Dec 2011 07:19:47 +1100, Andrei Alexandrescu
wrote:
On 12/24/11 9:54 AM, Derek wrote:
I'm sure you are totally correct; I'm not really a C++ coder. And I'm
sure you also process the specialist/expert level of D knowledge to make
reading contemporary D code a non-issue.
Well I'm
Adam D. Ruppe:
> I think code would have a lot fewer bugs if we forced all
> identifiers
> to be one character long. Then it'd be a lot shorter.
I was talking about the abundance of (({}){()}) and not about identifiers
length.
When they think about code conciseness (that is quite correlated wit
Andrei Alexandrescu:
> I've never gotten why you wouldn't define amap and afilter for your own
> code, thus avoiding parentheses.
In D1 I did write a non-standard library to be used with Phobos. In D2 I'd like
to avoid writing a dlibs2 that is used only by me. There are some functions
that are
On Saturday, 24 December 2011 at 23:12:27 UTC, bearophile wrote:
I was talking about the abundance of (({}){()}) and not about
identifiers length.
It's the same fallacy. I can't read Carmack's mind, but
I'm sure he's talking about shortening code the same way
I would mean it if I said it - simp
On 12/25/2011 12:27 AM, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:12:27 UTC, bearophile wrote:
I was talking about the abundance of (({}){()}) and not about
identifiers length.
It's the same fallacy.
Not really. Functional style code tends to be conceptually simpler.
Having c
Adam D. Ruppe:
> It's the same fallacy. I can't read Carmack's mind, but
> I'm sure he's talking about shortening code the same way
> I would mean it if I said it - simpler concepts, fewer cases,
> less repetition.
In a medium sized program there are many different ways to reduce redundancy
and
On Sun, 25 Dec 2011 01:51:57 +0200, bearophile
wrote:
But a problem is that such D code is full of braces and parentheses that
make such code hard to read and write (I agree with Andrei that D is not
very designed for such kind of code, but the fact doesn't change).
Absolutely agree brac
On Saturday, 24 December 2011 at 23:44:11 UTC, Timon Gehr wrote:
Functional style code tends to be conceptually simpler.
I find bugs creep into things with lots of parameters
or conditions. For instance:
if((flag && request.isSomething()) || request.isSomethingElse())
{}
If you have a lot o
On Saturday, 24 December 2011 at 23:51:57 UTC, bearophile wrote:
Using certain abstractions sometimes helps to write one idea
only once in a program. Etc.
This is the biggest one, and applies to all kinds of code.
I like to write little functions with meaningful names.
bool isOdd(int i) {
i
The two biggest things that I believe D would benefit from, in terms of
readability, are UFCS and C#-style lambdas (which were already discussed).
Something like
'array(find("test", select!("a.name")(filter!("a.num > 3")(Elements'
Could be rewritten much cleaner as
Elements.filter!"a.num > 3
On 12/24/2011 05:44 PM, Timon Gehr wrote:
On 12/25/2011 12:27 AM, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:12:27 UTC, bearophile wrote:
I was talking about the abundance of (({}){()}) and not about
identifiers length.
It's the same fallacy.
Not really. Functional style code
On 12/24/2011 07:20 PM, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:51:57 UTC, bearophile wrote:
Using certain abstractions sometimes helps to write one idea only once
in a program. Etc.
This is the biggest one, and applies to all kinds of code.
I like to write little functions wi
On 12/24/2011 10:37 PM, Kapps wrote:
> The two biggest things that I believe D would benefit from, in terms of
> readability, are UFCS and C#-style lambdas (which were already discussed).
>
> Something like
> 'array(find("test", select!("a.name")(filter!("a.num > 3")(Elements'
> Could be rewri
Universal Function Call Syntax. C# calls them extension methods.
Basically, the ability to call a method directly on a class (in the form
of A.MyMethod) without it being declared in the class. Usually just a
static/global method that gets rewritten. Instead of MyMethod(A), you
can use A.MyMetho
On 12/25/2011 02:57 AM, Kapps wrote:
> Universal Function Call Syntax. C# calls them extension methods.
> Basically, the ability to call a method directly on a class (in the form
> of A.MyMethod) without it being declared in the class. Usually just a
> static/global method that gets rewritten. Inst
On Saturday, 24 December 2011 at 20:19:48 UTC, Andrei
Alexandrescu wrote:
Analogies of programming language with human language are
flawed and take nowhere interesting. The only text that gets
close to the level of precision and non-ambiguity needed is
legal text; reading any amount of legal te
On 25.12.2011 00:44, Timon Gehr wrote:
Not really. Functional style code tends to be conceptually simpler.
Having code that is more readable can help. Getting rid of (({return
{return}}){return()}) makes the code more readable, whereas excessively
shortening identifiers does the opposite.
See h
On 2011-12-25 02:20, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:51:57 UTC, bearophile wrote:
Using certain abstractions sometimes helps to write one idea only once
in a program. Etc.
This is the biggest one, and applies to all kinds of code.
I like to write little functions with
On 2011-12-25 05:44, Andrei Alexandrescu wrote:
On 12/24/2011 07:20 PM, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:51:57 UTC, bearophile wrote:
Using certain abstractions sometimes helps to write one idea only once
in a program. Etc.
This is the biggest one, and applies to all k
On 12/25/2011 02:44 PM, simendsjo wrote:
On 25.12.2011 00:44, Timon Gehr wrote:
Not really. Functional style code tends to be conceptually simpler.
Having code that is more readable can help. Getting rid of (({return
{return}}){return()}) makes the code more readable, whereas excessively
shorte
On Sunday, 25 December 2011 at 04:44:57 UTC, Andrei Alexandrescu
wrote:
I see every letter beyond this as a liability:
Yeah, though like Jacob said, the implementation doesn't
matter as much as the idea of giving it a name.
But, if you're curious about why I wrote it long form, it's
just a qui
On 12/25/2011 11:53 PM, Timon Gehr wrote:
On 12/25/2011 02:44 PM, simendsjo wrote:
On 25.12.2011 00:44, Timon Gehr wrote:
Not really. Functional style code tends to be conceptually simpler.
Having code that is more readable can help. Getting rid of (({return
{return}}){return()}) makes the cod
Timon Gehr:
> > http://pastebin.com/C6vf9DQQ
If possible I suggest to remove all the BigInt from the module, and put the
bigint import into the main():
void main() {
import std.bigint;
auto h = hamming!BigInt();
writeln(take(20, h));
writeln(h()[1_691]);
writeln(h()[1_000_00
On 12/26/2011 12:30 AM, bearophile wrote:
Timon Gehr:
http://pastebin.com/C6vf9DQQ
If possible I suggest to remove all the BigInt from the module, and put the
bigint import into the main():
void main() {
import std.bigint;
auto h = hamming!BigInt();
writeln(take(20, h));
On 12/25/11 5:13 PM, Adam D. Ruppe wrote:
On Sunday, 25 December 2011 at 04:44:57 UTC, Andrei Alexandrescu wrote:
I see every letter beyond this as a liability:
Yeah, though like Jacob said, the implementation doesn't
matter as much as the idea of giving it a name.
But, if you're curious abou
On Saturday, December 24, 2011 21:37:12 Kapps wrote:
> The two biggest things that I believe D would benefit from, in terms of
> readability, are UFCS and C#-style lambdas (which were already discussed).
>
> Something like
> 'array(find("test", select!("a.name")(filter!("a.num > 3")(Elements'
On Monday, 26 December 2011 at 02:31:52 UTC, Adam D. Ruppe wrote:
I like an individual line of code to be dumb as a rock anyway.
I'm reminded of a discussion I had on another forum, where someone
suggested this might be because I started with assembly language.
It might be that those first few
On Monday, 26 December 2011 at 00:40:47 UTC, Andrei Alexandrescu
wrote:
I understand. Personally, I am unable to bring myself to fathom
why writing this has any advantage:
if(condition) return false just avoids a negation in the
condition.
It's easier to miss a "!" entirely than to miss a "ret
Le 25/12/2011 05:27, Andrei Alexandrescu a écrit :
Got the GC book this morning, already read 2.5 chapters :o).
Andrei
You'll find that you can do a lot when GC is aware of immutability (in
functionnal languages, most things tends to be immutable).
In the actual state of druntime, the GC
On 12/25/11 8:56 PM, deadalnix wrote:
Le 25/12/2011 05:27, Andrei Alexandrescu a écrit :
Got the GC book this morning, already read 2.5 chapters :o).
Andrei
You'll find that you can do a lot when GC is aware of immutability (in
functionnal languages, most things tends to be immutable).
In
On 24.12.2011 16:33, Andrei Alexandrescu wrote:
On 12/24/2011 09:11 AM, Derek wrote:
On Sat, 24 Dec 2011 23:42:41 +1100, bearophile
wrote:
In theory functional-style is a good to shrink the code, but in D
functional-style code is a jungle of (({}){()}) so it's hard to write
and hard to read.
On 2011-12-26 03:31, Adam D. Ruppe wrote:
On Monday, 26 December 2011 at 00:40:47 UTC, Andrei Alexandrescu wrote:
I understand. Personally, I am unable to bring myself to fathom why
writing this has any advantage:
if(condition) return false just avoids a negation in the
condition.
It's easier
Le 26/12/2011 05:23, Andrei Alexandrescu a écrit :
On 12/25/11 8:56 PM, deadalnix wrote:
Le 25/12/2011 05:27, Andrei Alexandrescu a écrit :
Got the GC book this morning, already read 2.5 chapters :o).
Andrei
You'll find that you can do a lot when GC is aware of immutability (in
functionnal
On 2011-12-26 05:23, Andrei Alexandrescu wrote:
On 12/25/11 8:56 PM, deadalnix wrote:
Le 25/12/2011 05:27, Andrei Alexandrescu a écrit :
Got the GC book this morning, already read 2.5 chapters :o).
Andrei
You'll find that you can do a lot when GC is aware of immutability (in
functionnal la
On 12/26/11 6:53 AM, Jacob Carlborg wrote:
What about the parallel/concurrent collector that has been linked a
couple of times in this newsgroup. Would that be possible and a good
idea to implement?
A parallel collector would be, of course, a valuable addition.
Andrei
On 2011-12-26 15:52, Andrei Alexandrescu wrote:
On 12/26/11 6:53 AM, Jacob Carlborg wrote:
What about the parallel/concurrent collector that has been linked a
couple of times in this newsgroup. Would that be possible and a good
idea to implement?
A parallel collector would be, of course, a val
Le 26/12/2011 05:23, Andrei Alexandrescu a écrit :
I've gone through a larger portion of the book and one thing has become
very clear to me: we must improve the precision of the collector. This
would be a gating feature towards taking the GC pretty much anywhere.
Do you know what is the impact
On Monday, 26 December 2011 at 00:40:47 UTC, Andrei Alexandrescu
wrote:
I might be biased, but I ask for it to be corrected if I see it
during a code review at work, and if someones writes such
during an interview, it doesn't gain them any points.
To conclude our chat here too, I do think you
On 12/26/11 10:29 AM, deadalnix wrote:
Le 26/12/2011 05:23, Andrei Alexandrescu a écrit :
I've gone through a larger portion of the book and one thing has become
very clear to me: we must improve the precision of the collector. This
would be a gating feature towards taking the GC pretty much any
On 12/26/2011 3:47 AM, Jacob Carlborg wrote:
It's like when you see code like this (Ruby):
unless !foo
end
Double negation. Code like the snippet above can be really annoying.
In general, variables and conditions should never be labeled with negation:
bool notFeature;
On Mon, 26 Dec 2011 07:43:46 -0800, Jacob Carlborg wrote:
On 2011-12-26 15:52, Andrei Alexandrescu wrote:
On 12/26/11 6:53 AM, Jacob Carlborg wrote:
What about the parallel/concurrent collector that has been linked a
couple of times in this newsgroup. Would that be possible and a good
idea to
Robert Jacques:
> The C4 pause-less GC, while very cool, is its own operating system.
> It doesn't run on-top of Windows, Linux, Mac, etc.
I think that eventually Linux will have to include some of those ideas, to
allow language designers or virtual machine designers, to implement better
garba
On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
On 12/26/11 10:29 AM, deadalnix wrote:
Do you know what is the impact of 64bits on false positive proportion
when the GC isn't precise ?
No.
I would think it would dramatically reduce it.
On 12/26/11 6:36 PM, Walter Bright wrote:
On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
On 12/26/11 10:29 AM, deadalnix wrote:
Do you know what is the impact of 64bits on false positive proportion
when the GC isn't precise ?
No.
I would think it would dramatically reduce it.
At the sa
Walter Bright wrote:
> bool notFeature;
Counterexample:
| bool sense;
I do not believe, that a majority of developers evaluates `nonsense' as
being equal to `!sense'.
-manfred
Le 27/12/2011 02:07, Andrei Alexandrescu a écrit :
On 12/26/11 6:36 PM, Walter Bright wrote:
On 12/26/2011 9:03 AM, Andrei Alexandrescu wrote:
On 12/26/11 10:29 AM, deadalnix wrote:
Do you know what is the impact of 64bits on false positive proportion
when the GC isn't precise ?
No.
I woul
On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
As a first step, we must make all allocations except stack type-aware,
and leave only the stack to be imprecise.
Couldn't the GC'ing the stack be handled in a similar style to how the
Windows x64 ABI functions with respect to exception handl
On 2011-12-26 21:55, Walter Bright wrote:
On 12/26/2011 3:47 AM, Jacob Carlborg wrote:
It's like when you see code like this (Ruby):
unless !foo
end
Double negation. Code like the snippet above can be really annoying.
In general, variables and conditions should never be labeled with negatio
On 2011-12-27 00:23, Robert Jacques wrote:
On Mon, 26 Dec 2011 07:43:46 -0800, Jacob Carlborg wrote:
On 2011-12-26 15:52, Andrei Alexandrescu wrote:
On 12/26/11 6:53 AM, Jacob Carlborg wrote:
What about the parallel/concurrent collector that has been linked a
couple of times in this newsgroup
On Tue, 27 Dec 2011 10:35:02 -0800, Sean Cavanaugh
wrote:
On 12/25/2011 10:23 PM, Andrei Alexandrescu wrote:
As a first step, we must make all allocations except stack type-aware,
and leave only the stack to be imprecise.
Couldn't the GC'ing the stack be handled in a similar style to how
On 24/12/2011 12:42, bearophile wrote:
A new blog post by the very good John Carmack, I like how well readable this
post is:
http://altdevblogaday.com/2011/12/24/static-code-analysis/
Nice article! I particularly liked this comment:
"The classic hacker disdain for “bondage and discipline lang
On 24/12/2011 23:27, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:12:27 UTC, bearophile wrote:
I was talking about the abundance of (({}){()}) and not about
identifiers length.
It's the same fallacy. I can't read Carmack's mind, but
I'm sure he's talking about shortening code the s
Bruno Medeiros:
> the needs of large, long-lived, multi-programmer
> projects are just different than the quick work you do for yourself."
> that throws a jab at a lot of the obsession with dynamic languages that
> goes on out there.
> It's something I've echoed in the past, especially when peop
On 2/9/2012 12:09 PM, Bruno Medeiros wrote:
Nice article! I particularly liked this comment:
"The classic hacker disdain for “bondage and discipline languages” is short
sighted – the needs of large, long-lived, multi-programmer projects are just
different than the quick work you do for yourself."
Le 10/02/2012 05:37, Walter Bright a écrit :
On 2/9/2012 12:09 PM, Bruno Medeiros wrote:
Nice article! I particularly liked this comment:
"The classic hacker disdain for “bondage and discipline languages” is
short
sighted – the needs of large, long-lived, multi-programmer projects
are just
diffe
On 2/10/2012 3:10 AM, deadalnix wrote:
Typeless is great when sketching some piece of code, but you'll way more problem
at the end.
I've heard people say that typeless is just as good, because you load them up
with unit tests that verify the types. To me, this doesn't seem like any
advantage.
On Fri, Feb 10, 2012 at 10:19:11AM -0800, Walter Bright wrote:
> On 2/10/2012 3:10 AM, deadalnix wrote:
> >Typeless is great when sketching some piece of code, but you'll way more
> >problem
> >at the end.
>
> I've heard people say that typeless is just as good, because you
> load them up with un
On 10/02/2012 18:19, Walter Bright wrote:
On 2/10/2012 3:10 AM, deadalnix wrote:
Typeless is great when sketching some piece of code, but you'll way
more problem
at the end.
I've heard people say that typeless is just as good, because you load
them up with unit tests that verify the types. To
On Fri, Feb 10, 2012 at 11:19 AM, Walter Bright
wrote:
> On 2/10/2012 3:10 AM, deadalnix wrote:
>
>> Typeless is great when sketching some piece of code, but you'll way more
>> problem
>> at the end.
>>
>
> I've heard people say that typeless is just as good, because you load them
> up with unit t
On 09/02/2012 22:34, bearophile wrote:
Comparing languages with small code snippets doesn't tell you all you want to
know about how a language scales for very large programs, of course, so they
aren't enough. But such small snippets are very useful any way because large
programs are mostly mad
On Friday, February 10, 2012 12:08:19 Brad Anderson wrote:
> I actually read an article recently from someone who had written large
> applications in dynamic languages and had come to the conclusion that the
> productivity gains you have with the dynamic typing are pretty much lost to
> the additio
On 2012-02-10 20:08, Brad Anderson wrote:
On Fri, Feb 10, 2012 at 11:19 AM, Walter Bright
mailto:newshou...@digitalmars.com>> wrote:
On 2/10/2012 3:10 AM, deadalnix wrote:
Typeless is great when sketching some piece of code, but you'll
way more problem
at the end.
Jonathan M Davis:
> I just can't stand the idea that whether an if statement is true or not could
> change the type of a variable (e.g. it's set to a string in one branch and an
> int in the other).
You have found something that sometimes I like to do in Python, that I can't do
in D, a reduced
I find that dynamic typing is useful sometimes and static typing other
times. Certainly dynamic (duck) typing is useful for scripts and
similar, and static typing is certainly better for writing code that
is especially picky about its values. I liken it to the way I write
code in PHP, the front-end
82 matches
Mail list logo
