Check it out: D is listed rather favorably on the chart..
http://redmonk.com/dberkholz/2013/07/23/are-we-getting-better-at-designing-programming-languages/

On Tue, Jul 23, 2013 at 06:24:14PM +0200, Jonathan A Dunlap wrote:
> Check it out: D is listed rather favorably on the chart.. http://redmonk.com/dberkholz/2013/07/23/are-we-getting-better-at-designing-programming-languages/

I'm skeptical about using LOC/commit as a metric for measuring expressiveness. First of all, does it take comments into account? 'cos if it does, then it's basically a useless metric. It's also too easily influenced by developer practices: smaller, more frequent commits vs. larger, less frequent commits. And it's biased by quality of code: just because a piece of code is buggy and has many 1-line fixes applied to it, says nothing about the expressiveness of the language itself.


T

-- 
There are two ways to write error-free programs; only the third one works.

On Tuesday, 23 July 2013 at 16:24:15 UTC, Jonathan A Dunlap wrote:
> Check it out: D is listed rather favorably on the chart..
> http://redmonk.com/dberkholz/2013/07/23/are-we-getting-better-at-designing-programming-languages/

From my understanding of the article, lower on the graph means more 'expressive' and higher means less 'expressive'? Correct me if i am wrong.

On 07/23/2013 09:47 AM, H. S. Teoh wrote:

> On Tue, Jul 23, 2013 at 06:24:14PM +0200, Jonathan A Dunlap wrote:
>> Check it out: D is listed rather favorably on the chart..
>> http://redmonk.com/dberkholz/2013/07/23/are-we-getting-better-at-designing-programming-languages/
>
> I'm skeptical about using LOC/commit as a metric for measuring
> expressiveness.

Agreed. How many lines of code is the following?

import std.algorithm;
import std.range;
import std.traits;
import std.conv;

auto evensJoined(R)(R r)
    if (isNumeric!(ElementType!R))
in {
    assert(r.length > 3);

} out {
    // I don't know...

} body {
    return r
        .filter!(a => !(a % 2))
        .map!(a => a.to!string)
        .joiner(",");
}

unittest
{
    assert(evensJoined([ 0, 1, 2, 3, 4 ]).array == "0,2,4");
}

void main()
{}

My answer is 1 line of code.

Also, comparing C, C++, and D, the three languages that I know well, I am shocked that C does not get at least twice as many lines as the others. My hunch is that that C code is buggy code.

First of all, C does not have exceptions so every single thing must be done as two lines:

    err = do_something();
    goto_finally_if_error(err);

    err = do_something_else();
    goto_finally_if_error(err);

Additionally, C does not have constructors and destructors so every object and variable must be properly and explicitly initialized and cleaned up.

Further, since the return value must be reserved for the error code, the results must be returned as an out-parameter:

// (Sorry, I haven't compiled this C code)
int foo(int arg, int * ret_result)
{
    int err = 0;
    int * p = NULL;
    MyType * m = NULL;

    // Function precondition checks
    if (arg < 42) {
        goto finally;
    }

    goto_finally_if_null(ret_result);
    *ret_result = 0;

    p = calloc(/* ... */);
    goto_finally_if_null(p);

    err = make_MyType(arg, p, &m);
    goto_finally_if_error(err);
    goto_finally_if_null(m);

    // use m...

    *ret_result = m.some_member;

finally:

    free(p);
    destroy_MyType(&m);
    return err;
}

Yeah, I think the article is looking at suboptimal C code...

Ali

On Tuesday, 23 July 2013 at 16:24:15 UTC, Jonathan A Dunlap wrote:
> Check it out: D is listed rather favorably on the chart..
> http://redmonk.com/dberkholz/2013/07/23/are-we-getting-better-at-designing-programming-languages/

Conversation from the last time Redmonk's Expressiveness index came up: http://forum.dlang.org/post/spgnwpchvtbfqhalpjhn@forum.dlang.org

On 24/07/13 04:02, Tofu Ninja wrote:
> On Tuesday, 23 July 2013 at 16:24:15 UTC, Jonathan A Dunlap wrote:
>> Check it out: D is listed rather favorably on the chart..
>> http://redmonk.com/dberkholz/2013/07/23/are-we-getting-better-at-designing-programming-languages/
>>
>
>  From my understanding of the article, lower on the graph means more
> 'expressive' and higher means less 'expressive'? Correct me if i am wrong.

You're right. And the consequence is that D didn't do very well at all on the chart.  Whether the metric used to measure "expressiveness" is valid is another question?  My personal view would be that it's a highly dubious metric.

Peter

On Tuesday, 23 July 2013 at 18:14:10 UTC, Ali Çehreli wrote:
> First of all, C does not have exceptions so every single thing must be done as two lines:
>
>     err = do_something();
>     goto_finally_if_error(err);

Huh, never seen such pattern in C. I just return error code.

On Fri, Jul 26, 2013 at 06:36:21AM +0200, Kagamin wrote:
> On Tuesday, 23 July 2013 at 18:14:10 UTC, Ali Çehreli wrote:
> >First of all, C does not have exceptions so every single thing must be done as two lines:
> >
> >    err = do_something();
> >    goto_finally_if_error(err);
> 
> Huh, never seen such pattern in C. I just return error code.

I think what he meant is code like this:

	#define OK 0
	#define ERR -1

	void myfunc(int x, int y, int z) {
		void *buf = malloc(100);
		int err;

		if ((err = fun1(x,y,z)) != OK)
			goto EXIT;

		if ((err = fun2(x,y,z)) != OK)
			goto EXIT;

		if ((err = fun3(x,y,z)) != OK)
			goto EXIT;

		if ((err = fun4(x,y,z)) != OK)
			goto EXIT;

		/* Finally finished! */
		err = OK;

	EXIT:
		/* Do cleanup */
		free(buf);

		return err;
	}

I have to write code like this every day at work, and it's a royal pain in the neck.


T

-- 
The best way to destroy a cause is to defend it poorly.

On Friday, 26 July 2013 at 05:12:55 UTC, H. S. Teoh wrote:
> On Fri, Jul 26, 2013 at 06:36:21AM +0200, Kagamin wrote:
>> On Tuesday, 23 July 2013 at 18:14:10 UTC, Ali Çehreli wrote:
>> >First of all, C does not have exceptions so every single thing
>> >must be done as two lines:
>> >
>> >    err = do_something();
>> >    goto_finally_if_error(err);
>> 
>> Huh, never seen such pattern in C. I just return error code.
>
> I think what he meant is code like this:
>
> [SNIP]
>
> I have to write code like this every day at work, and it's a royal pain
> in the neck.
>
> T

Ditto.

I think it is a pretty common pattern for legacy C programs. Thank god for RAII.

I think the next step in languages it the mutli-level abstraction. Right now we have the base level core programming and the preprocessing/template/generic level above that. There is no reason why language can't/shouldn't keep going. The ability to control and help the compiler do it's job better is the next frontier.

Analogous to how C++ allowed for abstraction of data, template allow for abstraction of functionality, we then need to abstract "templates"(or rather meta programming).

Unfortunately each level is less useful and more complex to implement but I think it will open new doors once done(similar to how oop changes the face of programing).

For example, why are there built in types? There is no inherit reason this is so except this allows compilers to achieve certain performance results... but having a higher level of abstraction of meta programming should allow us to bridge the internals of the compiler more effectively.

I don't see anything like this happening so depending on your scale, I don't think we are getting better, but just chasing our tails... how many more languages do we need that just change the syntax of C++? Why do people think syntax matters? Semantics is what is important but there seems to be little focus on it. Of course, we must express semantics through syntax so for practical purposes it mattes to some degree.... But not nearly as much as the number of programming languages suggest.