Article about the expressiveness of languages with D included as
one of the contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
I tend to agree with the first comment to the article though :)
/Jonas
On Tuesday, 2 April 2013 at 07:59:17 UTC, Jonas Drewsen wrote:
Article about the expressiveness of languages with D included
as one of the contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
I tend to agree with the first comment to the article
On 4/2/2013 12:59 AM, Jonas Drewsen wrote:
Article about the expressiveness of languages with D included as one of the
contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
It's an interesting metric, but there are too many obvious confounding var
On 04/02/2013 09:59 AM, Jonas Drewsen wrote:
> Article about the expressiveness of languages with D included as one of the
> contestants.
Personal feeling here -- there's a difference between how expressive a language
can be (even, how expressive it can _easily_ be) versus how expressively
program
On 04/02/2013 11:15 AM, Walter Bright wrote:
> It's an interesting metric, but there are too many obvious confounding
> variables
> to assume that expressiveness has the first order effect.
Between your response and mine, I think we have a rather good illustration of
this for the English language
Jonas Drewsen:
Article about the expressiveness of languages with D included
as one of the contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
I think D is quite expressive:
http://forum.dlang.org/thread/zdhfpftodxnvbpwvk...@forum.dlang.org
By
On Tuesday, 2 April 2013 at 07:59:17 UTC, Jonas Drewsen wrote:
Article about the expressiveness of languages with D included
as one of the contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
I tend to agree with the first comment to the article
On 04/02/2013 03:24 PM, renoX wrote:
> Yep, the sorting seems quite random to me, AFAIK Vala is nothing special yet
> it
> is ranked very high in this article..
To be fair, the author does say that results for what he calls "third tier"
languages (like Vala) should be considered with a great deal
On 4/2/2013 2:53 AM, Joseph Rushton Wakeling wrote:
I also have a strong feeling that LOC per commit reflects too many different
factors to be really reliable as a comparison, e.g. it probably depends quite
strongly on the age/maturity of a project, the rate of development, and other
factors.
C
On Tuesday, 2 April 2013 at 17:33:13 UTC, Walter Bright wrote:
On 4/2/2013 2:53 AM, Joseph Rushton Wakeling wrote:
I also have a strong feeling that LOC per commit reflects too
many different
factors to be really reliable as a comparison, e.g. it
probably depends quite
strongly on the age/matur
On 4/2/13 6:04 AM, bearophile wrote:
Jonas Drewsen:
Article about the expressiveness of languages with D included as one
of the contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
I think D is quite expressive:
http://forum.dlang.org/thread/zd
On 4/2/2013 1:59 PM, Andrei Alexandrescu wrote:
On 4/2/13 6:04 AM, bearophile wrote:
Jonas Drewsen:
Article about the expressiveness of languages with D included as one
of the contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
I think D is
On Tuesday, 2 April 2013 at 17:33:13 UTC, Walter Bright wrote:
On 4/2/2013 2:53 AM, Joseph Rushton Wakeling wrote:
I also have a strong feeling that LOC per commit reflects too
many different
factors to be really reliable as a comparison, e.g. it
probably depends quite
strongly on the age/matur
On 4/2/2013 4:55 PM, Jesse Phillips wrote:
I usually find the build in unittests to cause more skew since those are counted
as LOC.
Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
I'm inordinately pleased with how well unittests have become embedded in our D
cultur
On Tue, Apr 02, 2013 at 05:01:32PM -0700, Walter Bright wrote:
> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> >I usually find the build in unittests to cause more skew since those
> >are counted as LOC.
>
> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the
> fix.
>
> I'm inor
On Tuesday, April 02, 2013 17:01:32 Walter Bright wrote:
> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> > I usually find the build in unittests to cause more skew since those are
> > counted as LOC.
>
> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
>
> I'm inordinate
On 4/2/13 10:13 PM, Jonathan M Davis wrote:
On Tuesday, April 02, 2013 17:01:32 Walter Bright wrote:
On 4/2/2013 4:55 PM, Jesse Phillips wrote:
I usually find the build in unittests to cause more skew since those are
counted as LOC.
Often, in pulls for D, the LOC of the unittests exceeds the
On Tuesday, April 02, 2013 22:44:15 Andrei Alexandrescu wrote:
> On 4/2/13 10:13 PM, Jonathan M Davis wrote:
> > On Tuesday, April 02, 2013 17:01:32 Walter Bright wrote:
> >> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
> >>> I usually find the build in unittests to cause more skew since those are
>
On 4/2/2013 8:03 PM, Jonathan M Davis wrote:
Too many of them just test a few cases to make sure that the most
obvious stuff works rather than making sure they test corner cases and whatnot.
Currently, the datetime unittest coverage is 95%. Some of the 0 cases suggest
low hanging fruit.
Desp
On 2013-04-03 04:13, Jonathan M Davis wrote:
Yes, though I've had complaints before about a pull being too much code where
the unit tests were considered part of the code, and the reviewer thought that
number of lines was too great to be worth adding, even if the number of lines
of normal code w
On 4/3/13, Jacob Carlborg wrote:
> The problem is having the unit tests in the same file. Yes, I know, most
> of you love it, I don't.
One thing I noticed is that having unittests in separate files can
catch issues with template mixins.
If you have any private or protected functions that are use
On 4/3/13, Andrej Mitrovic wrote:
> If you have any private or protected functions
I meant private or package.
> One thing I noticed is that having unittests in separate files can
> catch issues with template mixins.
I wonder if there's a way to mitigate that problem with a language
feature. Pe
On 2013-04-03 05:03, Jonathan M Davis wrote:
I very much doubt that you could do that unless you specifically formatted the
code to take up as few lines as possible and didn't count the unit tests or
documentation in that line count. Otherwise, you couldn't do anything even
close to what std.dat
On 2013-04-03 08:45, Andrej Mitrovic wrote:
One thing I noticed is that having unittests in separate files can
catch issues with template mixins.
If you have any private or protected functions that are used by a
mixin template, the mixin template will not compile once the user
tries to use it i
On Wednesday, 3 April 2013 at 02:44:15 UTC, Andrei Alexandrescu
wrote:
If we did datetime all over again, I'd give a budget of 2000
lines for all functionality. I bet the solution would be better.
I think you are massively underestimating the complexity and
subtleties of dates and time.
For
03-Apr-2013 19:55, Peter Alexander пишет:
On Wednesday, 3 April 2013 at 02:44:15 UTC, Andrei Alexandrescu wrote:
If we did datetime all over again, I'd give a budget of 2000 lines for
all functionality. I bet the solution would be better.
I think you are massively underestimating the complexit
On 4/3/13 11:55 AM, Peter Alexander wrote:
On Wednesday, 3 April 2013 at 02:44:15 UTC, Andrei Alexandrescu wrote:
If we did datetime all over again, I'd give a budget of 2000 lines for
all functionality. I bet the solution would be better.
I think you are massively underestimating the complexi
On 4/2/13 11:03 PM, Jonathan M Davis wrote:
I
find your focus on trying to keep unit tests to a minimum to be disturbing and
likely to lead to poorly tested code.
Well that's quite the assumption.
Andrei
On 4/3/13 2:53 AM, Jacob Carlborg wrote:
On 2013-04-03 05:03, Jonathan M Davis wrote:
I actually prefer to have repetitive unit tests and not using loops to
make it clear what they actually do. Here's an example from our code
base, in Ruby:
describe "Swedish" do
subject { build(:address) { |a| a
On Tuesday, April 02, 2013 20:41:23 Walter Bright wrote:
> On 4/2/2013 8:03 PM, Jonathan M Davis wrote:
> > Too many of them just test a few cases to make sure that the most
> > obvious stuff works rather than making sure they test corner cases and
> > whatnot.
> Currently, the datetime unittest co
On Wednesday, April 03, 2013 13:37:40 Andrei Alexandrescu wrote:
> On 4/2/13 11:03 PM, Jonathan M Davis wrote:
> > I
> > find your focus on trying to keep unit tests to a minimum to be disturbing
> > and likely to lead to poorly tested code.
>
> Well that's quite the assumption.
If you push for t
On Wednesday, 3 April 2013 at 17:08:57 UTC, Andrei Alexandrescu
wrote:
On 4/3/13 11:55 AM, Peter Alexander wrote:
On Wednesday, 3 April 2013 at 02:44:15 UTC, Andrei
Alexandrescu wrote:
If we did datetime all over again, I'd give a budget of 2000
lines for
all functionality. I bet the solution
On Wednesday, April 03, 2013 19:59:37 Brad Anderson wrote:
> Perhaps 34k is too large but 2k is laughable.
I really should strip out the unit tests and documentation to see what the
line count of actual code is, as something like 75% of that is unit tests and
documentation, and IIRC, std.datetim
On Tuesday, April 02, 2013 20:41:23 Walter Bright wrote:
> Currently, the datetime unittest coverage is 95%. Some of the 0 cases
> suggest low hanging fruit.
I should take another look at those. I thought that I had it at more like 98%
(with most or all of the missing lines being due to stuff lik
On Wednesday, April 03, 2013 08:53:09 Jacob Carlborg wrote:
> On 2013-04-03 05:03, Jonathan M Davis wrote:
> > I very much doubt that you could do that unless you specifically formatted
> > the code to take up as few lines as possible and didn't count the unit
> > tests or documentation in that lin
On 4/3/2013 11:08 AM, Jonathan M Davis wrote:
(with most or all of the missing lines being due to stuff like catching
Exception and asserting 0 in the catch block for making a function nothrow
when you know that the code being called will never throw)
Why not just mark them as nothrow? Let the
On 4/3/2013 11:08 AM, Jonathan M Davis wrote:
I'm very much in
favor of having 100% test coverage on every line that _can_ be tested (there
may be rare exceptions to that, but I don't think that std.datetime has any of
them).
I'd be shocked if running -cov for the first time *didn't* come up wi
On 4/3/13 1:59 PM, Brad Anderson wrote:
On Wednesday, 3 April 2013 at 17:08:57 UTC, Andrei Alexandrescu wrote:
On 4/3/13 11:55 AM, Peter Alexander wrote:
On Wednesday, 3 April 2013 at 02:44:15 UTC, Andrei Alexandrescu wrote:
If we did datetime all over again, I'd give a budget of 2000 lines fo
On 4/3/2013 10:58 AM, Jonathan M Davis wrote:
If you push for the lines of unit testing code to be kept to a minimum, I
don't see how you can possibly expect stuff to be thoroughly tested.
My idea of perfection would be 100% coverage with zero redundancy in the
unittests.
In my experience wit
On Wednesday, April 03, 2013 11:27:38 Walter Bright wrote:
> On 4/3/2013 11:08 AM, Jonathan M Davis wrote:
> > (with most or all of the missing lines being due to stuff like catching
> > Exception and asserting 0 in the catch block for making a function nothrow
> > when you know that the code being
On Wednesday, April 03, 2013 11:29:53 Walter Bright wrote:
> On 4/3/2013 11:08 AM, Jonathan M Davis wrote:
> > I'm very much in
> > favor of having 100% test coverage on every line that _can_ be tested
> > (there may be rare exceptions to that, but I don't think that
> > std.datetime has any of the
On 4/3/2013 9:49 AM, Dmitry Olshansky wrote:
+1
Stylistic nit:
When writing a one-liner post like this, please do not quote the entire
preceding post, especially if it is long. We have great forum software, and the
newsreaders as well are great at navigating the threads.
Not to pick on you
On Wednesday, April 03, 2013 11:36:54 Walter Bright wrote:
> On 4/3/2013 10:58 AM, Jonathan M Davis wrote:
> > If you push for the lines of unit testing code to be kept to a minimum, I
> > don't see how you can possibly expect stuff to be thoroughly tested.
>
> My idea of perfection would be 100%
On 4/3/2013 11:44 AM, Jonathan M Davis wrote:
Yes. My point was that 100% should be the goal, whereas I know a number of
developers who consider something like 70% to be sufficient - and these are
folks who actually believe in writing unit tests. Certainly, expecting to hit
100% with -cov on the
On 4/3/2013 11:44 AM, Jonathan M Davis wrote:
the catch is necessary in order to mark the function as nothrow, because
format _could_ throw. It's just that given the arguments, you know that it
never will.
Agreed.
On 2013-04-03 19:39, Andrei Alexandrescu wrote:
The way I see it, the first is terrible and the second asks for better
focus on a data-driven approach.
Stupid me, posting on Ruby.
--
/Jacob Carlborg
On 2013-04-03 20:08, Jonathan M Davis wrote:
In general, I agree, because I think that straight-forward tests that avoid
loops and the like are far less error-prone, and you need the tests to not be
buggy. I don't want to have to test my test code to make sure that it works
correctly.
However,
On 4/3/2013 11:56 AM, Jonathan M Davis wrote:
Certainly, I agree that having the minimal tests required to test everything
that needs testing should be the goal, but figuring out which tests are and
aren't really needed is a bit of art.
That's why we are engineers, and not mere code monkeys.
On Wednesday, April 03, 2013 11:58:20 Walter Bright wrote:
> On 4/3/2013 11:44 AM, Jonathan M Davis wrote:
> > Yes. My point was that 100% should be the goal, whereas I know a number of
> > developers who consider something like 70% to be sufficient - and these
> > are
> > folks who actually believ
On Wednesday, April 03, 2013 12:03:39 Walter Bright wrote:
> On 4/3/2013 11:56 AM, Jonathan M Davis wrote:
> > Certainly, I agree that having the minimal tests required to test
> > everything that needs testing should be the goal, but figuring out which
> > tests are and aren't really needed is a b
On 2013-04-03, 20:04, Jonathan M Davis wrote:
On Wednesday, April 03, 2013 19:59:37 Brad Anderson wrote:
Perhaps 34k is too large but 2k is laughable.
I really should strip out the unit tests and documentation to see what
the
line count of actual code is, as something like 75% of that is un
On 4/3/13 2:55 PM, Jacob Carlborg wrote:
On 2013-04-03 19:39, Andrei Alexandrescu wrote:
The way I see it, the first is terrible and the second asks for better
focus on a data-driven approach.
Stupid me, posting on Ruby.
I was referring to the repeatability of the code used in testing, whic
On Wednesday, 3 April 2013 at 19:28:56 UTC, Simen Kjaeraas wrote:
On 2013-04-03, 20:04, Jonathan M Davis wrote:
On Wednesday, April 03, 2013 19:59:37 Brad Anderson wrote:
Perhaps 34k is too large but 2k is laughable.
I really should strip out the unit tests and documentation to
see what the
On Wed, 03 Apr 2013 14:42:12 -0400, Walter Bright
wrote:
On 4/3/2013 9:49 AM, Dmitry Olshansky wrote:
+1
Stylistic nit:
When writing a one-liner post like this, please do not quote the entire
preceding post, especially if it is long. We have great forum software,
and the newsreaders a
On 4/3/13 11:24 PM, Steven Schveighoffer wrote:
On Wed, 03 Apr 2013 14:42:12 -0400, Walter Bright
wrote:
On 4/3/2013 9:49 AM, Dmitry Olshansky wrote:
+1
Stylistic nit:
When writing a one-liner post like this, please do not quote the
entire preceding post, especially if it is long. We have
On 2013-04-03 22:50, Andrei Alexandrescu wrote:
I was referring to the repeatability of the code used in testing, which
is language-independent.
I think the first one is far more readable then the one using the loop.
--
/Jacob Carlborg
On 2013-04-03 21:28, Simen Kjaeraas wrote:
Removed all comments, unittests, and empty lines from std.datetime. File
went from 34070 to 5843 lines.
Heheh, that's more reasonable. That's also why I don't like to have unit
tests inline.
--
/Jacob Carlborg
On 2013-04-04 03:47, Jesse Phillips wrote:
cloc doesn't support /+ comments... But using your number, cloc, and
some math
std.datetime contains mostly /+ and // comments. It only contains a
single /* comment.
--
/Jacob Carlborg
On Thursday, 4 April 2013 at 14:31:36 UTC, Jacob Carlborg wrote:
On 2013-04-04 03:47, Jesse Phillips wrote:
cloc doesn't support /+ comments... But using your number,
cloc, and
some math
std.datetime contains mostly /+ and // comments. It only
contains a single /* comment.
I realize that,
On 4/4/13 10:26 AM, Jacob Carlborg wrote:
On 2013-04-03 22:50, Andrei Alexandrescu wrote:
I was referring to the repeatability of the code used in testing, which
is language-independent.
I think the first one is far more readable then the one using the loop.
I understand. And I think you ar
On Thu, 04 Apr 2013 09:25:30 -0400, Andrei Alexandrescu
wrote:
On 4/3/13 11:24 PM, Steven Schveighoffer wrote:
On Wed, 03 Apr 2013 14:42:12 -0400, Walter Bright
wrote:
On 4/3/2013 9:49 AM, Dmitry Olshansky wrote:
+1
Stylistic nit:
When writing a one-liner post like this, please do not
On 4/2/13 4:59 PM, Andrei Alexandrescu wrote:
On 4/2/13 6:04 AM, bearophile wrote:
Jonas Drewsen:
Article about the expressiveness of languages with D included as one
of the contestants.
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
I think D is qu
Andrei Alexandrescu:
The suggestions included (such as enumerate()) are also very
worth
looking into.
I think the enumerate() was discussed mostly elsewhere.
Pinging bearophile on this again - do you want to adapt this
into a blog entry? It may be worth posting the link to reddit
as is, b
On Friday, 5 April 2013 at 01:55:06 UTC, bearophile wrote:
Andrei Alexandrescu:
Pinging bearophile on this again - do you want to adapt this
into a blog entry? It may be worth posting the link to reddit
as is, but one adaptation pass for a larger audience shouldn't
hurt.
Let us know!
Thank
On Tuesday, 2 April 2013 at 23:55:19 UTC, Jesse Phillips wrote:
On Tuesday, 2 April 2013 at 17:33:13 UTC, Walter Bright wrote:
On 4/2/2013 2:53 AM, Joseph Rushton Wakeling wrote:
I also have a strong feeling that LOC per commit reflects too
many different
factors to be really reliable as a comp
On Wednesday, 3 April 2013 at 18:42:14 UTC, Walter Bright wrote:
On 4/3/2013 9:49 AM, Dmitry Olshansky wrote:
+1
Stylistic nit:
When writing a one-liner post like this, please do not quote
the entire preceding post, especially if it is long. We have
great forum software, and the newsreaders
On Thursday, 4 April 2013 at 18:00:27 UTC, Steven Schveighoffer
wrote:
Mac mail fixed this problem for me. All previously received
text is folded out, no need to look at it.
So there is a lot of visual noise for nothing, and you like it ?
And what if one uses the web forum, like me ? Or Th
It won’t tell you how readable the resulting code is (Hello,
lambda functions) or how long it takes to write it (APL
anyone?), so it’s not a measure of maintainability or
productivity.
Did I get it right, that expressiveness means trading
maintainability for keystroke saving?
On 4/4/13 10:36 PM, Zach the Mystic wrote:
On Friday, 5 April 2013 at 01:55:06 UTC, bearophile wrote:
Andrei Alexandrescu:
Pinging bearophile on this again - do you want to adapt this into a
blog entry? It may be worth posting the link to reddit as is, but one
adaptation pass for a larger audie
On Fri, 05 Apr 2013 02:16:02 -0400, SomeDude
wrote:
On Thursday, 4 April 2013 at 18:00:27 UTC, Steven Schveighoffer wrote:
Mac mail fixed this problem for me. All previously received text is
folded out, no need to look at it.
So there is a lot of visual noise for nothing, and you lik
On 04/02/2013 10:44 PM, Andrei Alexandrescu wrote:
I think it leads to writing less repetitive unittests.
If we did datetime all over again, I'd give a budget of 2000 lines for
all functionality. I bet the solution would be better.
Andrei
My problem with datetime is that it is too monolith
On 04/02/2013 08:01 PM, Walter Bright wrote:
On 4/2/2013 4:55 PM, Jesse Phillips wrote:
I usually find the build in unittests to cause more skew since those
are counted
as LOC.
Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
I'm inordinately pleased with how well u
On Fri, 05 Apr 2013 13:13:29 -0400, Chad Joan wrote:
My problem with datetime is that it is too monolithic. I really wish it
was split into about 3 different modules. This is frustrating from a
user-perspective. The docs for that thing can easily make someone's
eyes gloss over.
What i
On Friday, April 05, 2013 13:13:29 Chad Joan wrote:
> On 04/02/2013 10:44 PM, Andrei Alexandrescu wrote:
> > I think it leads to writing less repetitive unittests.
> >
> > If we did datetime all over again, I'd give a budget of 2000 lines for
> > all functionality. I bet the solution would be bett
On 4/5/13 11:17 AM, Jonathan M Davis wrote:
On Friday, April 05, 2013 13:13:29 Chad Joan wrote:
On 04/02/2013 10:44 PM, Andrei Alexandrescu wrote:
I think it leads to writing less repetitive unittests.
If we did datetime all over again, I'd give a budget of 2000 lines for
all functionality. I
On Friday, April 05, 2013 14:36:07 Brad Roberts wrote:
> I believe it's really not a module issue at all, but a doc issue. The
> two are directly tied today, but I have _no_ problem with importing the
> module and using it as is. Yes, it's large in terms of lines in the
> file, but really, who's af
76 matches
Mail list logo
