On 13.12.2010 12:42, Simen kjaeraas wrote:
> Stephan Soller <stephan.soller@helionweb.de> wrote:
>
>>> Absolutely not. Ruby reads like Yoda-speak, while D is almost plain
>>> English. Had foreach used 'in' instead of the semicolon, only
>>> punctuation and 'ln' would be off.
>>>
>>
>> Unfortunately I have to disagree here. If you have well written Ruby
>> code (like Ruby on Rails usually provides) it can usually be read like
>> plain English. That's the reason why I dropped writing documentation
>> comments for Ruby code: it's just redundant.
>
> I'm only commenting on the above code, not Ruby in general.
>

Sorry, I got that wrong then.

On 11.12.2010 10:29, "Jérôme M. Berger" wrote:
> Ary Borenszweig wrote:
>> http://vimeo.com/17420638
>>
>> A very interesting talk.
>>
>> I used to like D. To write code in a high level while at the same
>> time being very close to the machine, with class invariants, unit
>> tests and many other features seemed very appealing. But I always
>> felt there was something wrong.
>>
>> About a year ago I met Ruby. Now I find languages like Java, C#,
>> Python and D kind of ugly and uncomfortable. Why? Exactly because of
>> what it is said in that video.
>>
>> This is not to start a flame war or trolling, it's just to show you
>> why I changed my mind so much about D, and why I think (IMHO) you
>> should care about naming conventions (like bearophile says), more
>> powerful unittests (and not having unittests integrated into the
>> language but rather being able to build your own test frameworks
>> with ease) and stop caring about being C-syntax friendly. The world
>> doesn't need that many semicolons and parenthesis. :-)
>
> 	There is a major syntax issue with Ruby. This line:
>
> foo(a, b)
>
> does not mean the same thing as this line:
>
> foo (a, b)
>
> 	!!WT?
>
> 		Jerome

Well, this is only a major syntax issue if you write Ruby code like you write C code (with many parenthesis). Usually method calls in Ruby don't contain any parenthesis:

	foo a, b

Parenthesis are only used if a parameter is an expression:

	foo (a + 1), b

Because of that coding style the above example is an rare edge case. I tried it in IRB (interactive Ruby console) and your two method calls actually do the same. The second one however generates a warning ("don't put space before argument parentheses").

ps.: For "foo (a, b)" to really screw up "," has to be a method defined on "a". I don't think that's possible in Ruby.

Happy programming
Stephan Soller

On 11/12/10 12:26, Ary Borenszweig wrote:
> http://vimeo.com/17420638
>
> A very interesting talk.
>
> I used to like D....<cut/>

Just to be sure Ary, are you not the author behind "Descent", the
Eclipse Plugin for D?  Likely I am mistaken, but if not, this is
a bit of a wikileak for your former support of D?

Yes I am :-)

I stopped "supporting" D because it grew to be a very confusing and hard to master
monster, with all those const, invariant and "this is not avaialble in the
language, but writing this function and using it in a way it works but it's very
unintuitive, we can have it" (like the mixin(yield("why do I have to write/read so
much?")) or dont!shout_at_me("please")).

But... I know D is a very different and difficult to implement language, exactly because everything has to be compiled to machine code and it must be really efficient, so I still watch it, see it's progression and try to comment on things I like from other languages and how I would implement them in D (like the @mixin attribute I commented in another post).

Sorry if sometimes I sound rude or angry, I can't be any of those because D owes me nothing.

On 12/13/2010 09:08 AM, Ary Borenszweig wrote:
> Yes I am :-)

Since you were the Descent author, I wonder how you feel about Ruby's lack of static typing. In the video, the speaker bashes type safety as "having your balls fondled at the airport", that is, security theater that doesn't accomplish much.

But that misses many of the good features that come with it, especially in an IDE like Eclipse: code completion, find declaration, find references, rename refactoring, and compiler checked documentation.

Ruby is also one of the slowest languages around, and I'm sure some of that is due to the "freedom" it gives you, "freedom" being what the speaker calls no static typing and monkey patching.

Well, about a year ago I started programming in dynamic languages like python and Ruby. I did very little of python and a lot in Ruby. At first I thought "Hm, it must be really hard to program without autocompletion, static type verification, etc.". Soon I found out I was wrong.

First, in Ruby it's very easy to test the code. And you can do crazy things like what I mention in here ( http://weblogs.manas.com.ar/ary/2010/04/15/quick-way-to-test-many-values-in-ruby/ )

[[1, 1], [4, 2], [9, 3]].each do |input, output|
  test "sqrt #{input}"
    assert_equal output, sqrt(input)
  end
end

and the good thing is that if it fails for a specific input/output pair it is treated as a different test, so you can clearly see which input/output pair failed. I can see you can do the same in D with string mixins, probably putting all the code between do/end in a string... :-(

Second, I found out I have to type a lot less. And names are very consistent and intuitive in Ruby and specially in Ruby on Rails, so I don't need that autocompletion anymore, I can just type what my mind think is correct and it works. And I do use some autocompletion, I switched to use gedit first, then vim, and it seems to be enough to autocomplete things based on the words on the open documents.

And autocompletion might show you the list of methods of a class, but that's not useful if you don't know how to use those methods in combination. For that, you need to read the class' documentation about it's usage. And that, you can find it *a lot* in Ruby libraries. After all, what's important is how to use a class for what you want to do, not what methods it provides. This concept is so strong in Ruby that sometimes you just see things documented like "To use this, do 'basic_auth :user => x, :pass => b' without even caring about the signature of the method".

Third, go to declaration, I can do that in vim with ctrl+], using ctags.

Fourth, rename refactoring. That is the thing that is likely less to happen in a project. The most common refactoring are logical, not just names. And after refactoring by hand I just run the tests and fix whatever is there to fix. It completely changed my mind about how to develop software (previously I also did tests, but in Ruby I can test more things and much more easily... for instance, I can mock a static method or even a top level function, which I cannot do in D or Java... so in those languages I have to do dependency injection and change a lot the way I should be programming... making my code harder to understand and to follow. In Ruby I can program directly what I want and still test it, always).

What do you mean by "compiler checked documentation"?

And Ruby might be slow(er than X), but when you program a website or something where the database time or http request time is orders of magnitude higher, you don't care the language to be a little slower. In the end you can never blame the language for your app being slow, you might to do load balancing, optimize your queries, etc.

BUT. D is a systems programming language, so the above paragraph doesn't apply. But I still think some things in D could be improved.

On 12/13/10 9:11 AM, Jeff Nowakowski wrote:
> On 12/13/2010 09:08 AM, Ary Borenszweig wrote:
>> Yes I am :-)
>
> Since you were the Descent author, I wonder how you feel about Ruby's
> lack of static typing. In the video, the speaker bashes type safety as
> "having your balls fondled at the airport", that is, security theater
> that doesn't accomplish much.

By the way, I couldn't stop cringing at the distasteful, male-centric sexual jokes that the talk is peppered with. Wonder if there was any woman in the audience, and how she might have felt. And this is not a ghetto rant - it's the keynote of a major Ruby conference! (And I'm definitely not a prude.) Am I alone in thinking that this is not what our metier should evolve into?

Besides, the argument in favor of dynamic typing is one of the most disingenuous around. C is a language for consenting adults that gives you that kind of freedom. If we took the speaker's arguments to their logical conclusion, Ruby would be a language for people who don't care about correctness, despise efficiency, and have contempt for modularity.

> But that misses many of the good features that come with it, especially
> in an IDE like Eclipse: code completion, find declaration, find
> references, rename refactoring, and compiler checked documentation.
>
> Ruby is also one of the slowest languages around, and I'm sure some of
> that is due to the "freedom" it gives you, "freedom" being what the
> speaker calls no static typing and monkey patching.

Clearly focusing on one thing is easier when other concerns are reduced. D code has a lot more to worry about than Ruby code. That being said, I'm very glad about this discussion - we stand to learn from a variety of languages including Ruby.


Andrei

"Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:ie4ui8$174a$1@digitalmars.com...
> On 12/13/2010 12:23 AM, Adam D. Ruppe wrote:
>> Ary Borenszweig wrote:
>>> D should provide a yield keyword that basically
>>> rewrites the body of the method into the first code.
>>
>> Don't need to change the language for that.
>>
>> =========
>>
>> string yield(string what) {
>>    return `if(auto result = dg(`~what~`)) return result;`;
>> }
>>
>> class Foo
>> {
>>      uint array[2];
>>
>>      int opApply(int delegate(ref uint) dg) {
>>           mixin(yield("array[0]"));
>>           mixin(yield("array[1]"));
>>
>> return 0;
>>      }
>> }
>> =========
>>
>> Compiles and runs as expected, on today's D.
>
> Cool!!
>
> But it's kind of too much what you have to write. I like that you can do it without modifying the language, but sometimes it's better to have it directly in the language if it's you are going to use it often and it's useful. Remembering to put mixin() and enclosing the expression in a string is not very nice to the eyes.
>
> I really like string mixins as they are inserted as is into the code, so there's no overhead in the call. It would be really cool if you could mark a function as being a string mixin, and then to do:
>
> @mixin
> string yield(string what) {
>   return `if(auto result = dg(`~what~`)) return result;`;
> }
>
> class Foo
> {
>     uint array[2];
>
>     int opApply(int delegate(ref uint) dg) {
>          yield(array[0]);
>          yield(array[1]);
>
> return 0;
>     }
> }
>
> So that basically would work like this:
>
> - @mixin tells the compiler it's a string mixin because the function returns a string.

I've suggested that before, but it only got applied to template mixins which IMO isn't nearly as useful or desireable as doing the same for string mixins. I still really want to see it.

> - In the semantic analysis the compiler needs to invoke yield(array[0]). It can see that yield is marked as @mixin, so instead of applying semantic analysis to array[0] it just converts it back to a string (I remember there exists such thing in DMD's source code) and then passes it to yield.
>

The ability the get a string representation of the argument passd by the caller would definitely be a great thing to have. Although I think it would be better placed in __traits or the proposed magic "meta" namespace, etc. That way any function, @mixin or not, can use it or not use it whenever it wants, and it wouldn't add any potentially confusing semantic complexity.

On 12/13/2010 10:37 AM, Ary Borenszweig wrote:
>
> Fourth, rename refactoring. That is the thing that is likely less to happen in a
> project.

Actually, I do that quite a bit. I found that I renamed things a lot more when it became easy to do so. Before that I would tend to live with a name I didn't like any more.

> What do you mean by "compiler checked documentation"?

I mean the parameters to a method are documented, at least at the type level, and the compiler verifies it.

Anyways, thanks for sharing your experience. I'm not really sold, but maybe one day I'll give it a shot.

"Stephan Soller" <stephan.soller@helionweb.de> wrote in message news:ie4srq$138c$1@digitalmars.com...
> On 12.12.2010 18:01, Simen kjaeraas wrote:
>>
>> Absolutely not. Ruby reads like Yoda-speak, while D is almost plain English. Had foreach used 'in' instead of the semicolon, only punctuation and 'ln' would be off.
>>
>
> Unfortunately I have to disagree here. If you have well written Ruby code (like Ruby on Rails usually provides) it can usually be read like plain English. That's the reason why I dropped writing documentation comments for Ruby code: it's just redundant.
>

This common Ruby idiom is totally Yoda-speak to me:

    doSomething unless condition?

The order-of-execution is completely backwards. Plus the "unless" instead of "if" makes my mind pause to process an "inverted-context" because *now* seeing a "blah" really means "not", and a "!blah" no longer means "not".

Yea, "(action) unless (condition)" is fairly normal English, but code has different requirements than normal speech. And besides, it's also perfectly normal, easily-understandable English to say "unless (condition), (action)", or even a negated if: "if you don't have x, do y". In fact I'd argue the English "if you don't have X, do Y" is much easier to understand than "do B unless you have C".

With normal English, it's easy enough to hear "do this", and then appropriately modify it in your head when you hear it followed by "unless that". This is largely because instructions in normal English tend to be *much* simpler than instructions in code. With code, there's so many other instructions to consider that that extra little mental work of modifying something you already processed suddenly makes a difference. But if you see something start with the modifier (the condition, in this case) then your mind automatically knows it's still an incomplete thought and doesn't do a premature "commit". At least that's how my (twisted?) mind works.

Also, Ruby reading like English might be part of why I'm *not* quite won over by Ruby's syntax: I'm a native English speaker and I still think English makes no sense!