Re: forum.dlang.org is now using DCaptcha
On 12/2/14, 6:41 PM, Vladimir Panteleev wrote:
Enter DCaptcha
I think this could work with just two or three variants of a question.
Always ask what's the return value of the function.
1. int foo() { return 8 % 3; }
I don't think non-programmers know what that '%' symbol is, but
programmers of any language would recognize this.
2. int foo() { int x = 8; x++; x++; return x; }
I don't think non-programmers would guess ++ is increment, but
programmers most probably know it.
3. bool foo() { return 42 != 30 };
I don't think non-programmers know what != is.
Re: On the meaning of string.length
On 11/19/14, 11:33 AM, Adam D. Ruppe wrote: I answered a random C# stackoverflow question about why string.length returns the value it does with some rationale defending code units instead of characters - basically, I typed up a defense of D's string-as-array behavior. In Ruby `length` returns the number of unicode characters and `bytesize` returns the number of bytes. I prefer this use of the names.
Re: Coloring terminal output.
On 7/13/14, 5:11 PM, yamadapc wrote: Hello all :) I've made a simple port of ruby's colorize library for D. I'd greatly appreciate any feedback. Windows isn't supported, yet. Links: http://code.dlang.org/packages/colorize https://github.com/yamadapc/d-colorize https://github.com/fazibear/colorize It's nice, but it could be more efficient. You usually use colors as a one-time shot to then output something to the terminal. For example in Ruby it would be: puts hello.colorize.red.on_blue In Ruby it's implemented using regular expressions, very ugly and not very performant. In D you implemented it as returning another string that contains the format, which allocates a new string that is short lived. In Crystal we make colorize return a struct that wraps the original value but contains the color information. Then when that struct is converted to a string it appends the color codes to the output. In Crystal there's to_s (similar to toString()) but also to_s(io), which subclasses must override to append something to the given IO. That way memory allocations are reduced drastically without needing to create intermediate strings. Here's the source code and some specs if you feel like copying this idea: https://github.com/manastech/crystal/blob/master/src/colorize.cr https://github.com/manastech/crystal/blob/master/spec/std/colorize_spec.cr
Re: Coloring terminal output.
On 7/27/14, 11:16 AM, Ary Borenszweig wrote: On 7/13/14, 5:11 PM, yamadapc wrote: Hello all :) I've made a simple port of ruby's colorize library for D. I'd greatly appreciate any feedback. Windows isn't supported, yet. Links: http://code.dlang.org/packages/colorize https://github.com/yamadapc/d-colorize https://github.com/fazibear/colorize It's nice, but it could be more efficient. You usually use colors as a one-time shot to then output something to the terminal. For example in Ruby it would be: puts hello.colorize.red.on_blue In Ruby it's implemented using regular expressions, very ugly and not very performant. In D you implemented it as returning another string that contains the format, which allocates a new string that is short lived. In Crystal we make colorize return a struct that wraps the original value but contains the color information. Then when that struct is converted to a string it appends the color codes to the output. In Crystal there's to_s (similar to toString()) but also to_s(io), which subclasses must override to append something to the given IO. That way memory allocations are reduced drastically without needing to create intermediate strings. Here's the source code and some specs if you feel like copying this idea: https://github.com/manastech/crystal/blob/master/src/colorize.cr https://github.com/manastech/crystal/blob/master/spec/std/colorize_spec.cr Also, usually the color is known by the user and not something that is put in a variable and later read. So having convenience methods that don't do a big case over the color or an enum value is again more performant. Something like: hello.colorize.red instead of: hello.colorize(fg.red) which is shorter, more readable *and* more efficient. You could generate those methods at compile time based on all the colors (which is something we do in Crystal too).
Re: Coloring terminal output.
On 7/27/14, 11:31 AM, Ary Borenszweig wrote: On 7/27/14, 11:16 AM, Ary Borenszweig wrote: On 7/13/14, 5:11 PM, yamadapc wrote: Hello all :) I've made a simple port of ruby's colorize library for D. I'd greatly appreciate any feedback. Windows isn't supported, yet. Links: http://code.dlang.org/packages/colorize https://github.com/yamadapc/d-colorize https://github.com/fazibear/colorize It's nice, but it could be more efficient. You usually use colors as a one-time shot to then output something to the terminal. For example in Ruby it would be: puts hello.colorize.red.on_blue In Ruby it's implemented using regular expressions, very ugly and not very performant. In D you implemented it as returning another string that contains the format, which allocates a new string that is short lived. In Crystal we make colorize return a struct that wraps the original value but contains the color information. Then when that struct is converted to a string it appends the color codes to the output. In Crystal there's to_s (similar to toString()) but also to_s(io), which subclasses must override to append something to the given IO. That way memory allocations are reduced drastically without needing to create intermediate strings. Here's the source code and some specs if you feel like copying this idea: https://github.com/manastech/crystal/blob/master/src/colorize.cr https://github.com/manastech/crystal/blob/master/spec/std/colorize_spec.cr Also, usually the color is known by the user and not something that is put in a variable and later read. So having convenience methods that don't do a big case over the color or an enum value is again more performant. Something like: hello.colorize.red instead of: hello.colorize(fg.red) which is shorter, more readable *and* more efficient. You could generate those methods at compile time based on all the colors (which is something we do in Crystal too). Finally, don't restrict colorize to a string. You could colorize any object: # works, without converting [1, 2, 3] to a string puts [1, 2, 3].colorize.red
Offtopic: AMA (Was: Interview at Lang.NEXT)
On 6/4/14, 3:19 AM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/ Andrei This is offtopic, but why are people obsessed with writing English acronyms? I always have to lookup the meaning and then I'm polluting my head with acronyms. Is there any difference in time/convenience between writing Interviewee here. Ask me anything Between Interviewee. AMA? :-(
Re: Offtopic: AMA (Was: Interview at Lang.NEXT)
On 6/6/14, 5:25 PM, Tourist wrote: On Friday, 6 June 2014 at 19:27:35 UTC, Ary Borenszweig wrote: On 6/4/14, 3:19 AM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/ Andrei This is offtopic, but why are people obsessed with writing English acronyms? I always have to lookup the meaning and then I'm polluting my head with acronyms. Is there any difference in time/convenience between writing Interviewee here. Ask me anything Between Interviewee. AMA? :-( AMA is kinda reddit thing. http://www.reddit.com/r/IAmA/comments/1nl9at/i_am_a_member_of_facebooks_hhvm_team_a_c_and_d/ Interesting, I didn't know that. Thanks!
Re: Interview at Lang.NEXT
On 6/4/14, 1:27 PM, Meta wrote: On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/ Andrei When that person made the statement about expressing his mental model in a simpler way that is still somewhat fast, and then optimizing/adding annotations/etc. after he gets it working, I kept expecting you to mention RDMD and D's ability to be used for scripting, and purity/nothrow/@safe/@nogc inference. This is an advantage D has over Rust and C++. With Rust especially, there is no way to avoid dealing with its pointer semantics, as they permeate the language. With D, you can write in a C or even Python-like way (while not having to worry about ownership, memory, etc. as the GC handles it for you), but you can then optimize and add annotations to your code to get a lot more performance and safety once your initial implementation is working. You still have to worry about types, though.
Re: Interview at Lang.NEXT
On 6/4/14, 2:50 PM, Meta wrote: On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote: You still have to worry about types, though. Yes, but you can often get away without explicitly writing types in D, and there's always std.variant.Variant when you don't want to bother with them. Even in function signatures?
Re: Interview at Lang.NEXT
On 6/4/14, 2:59 PM, Meta wrote:
On Wednesday, 4 June 2014 at 17:57:40 UTC, Ary Borenszweig wrote:
Even in function signatures?
alias var = std.variant.Variant;
auto DoStuff(var x, var y)
{
//Do stuff with x and y
}
Cool! It also looks nice too.
Re: Interview at Lang.NEXT
On 6/4/14, 3:33 PM, Craig Dillabaugh wrote: On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote: On 6/4/14, 1:27 PM, Meta wrote: On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/27911b/conversation_with_andrei_alexandrescu_all_things/ Andrei When that person made the statement about expressing his mental model in a simpler way that is still somewhat fast, and then optimizing/adding annotations/etc. after he gets it working, I kept expecting you to mention RDMD and D's ability to be used for scripting, and purity/nothrow/@safe/@nogc inference. This is an advantage D has over Rust and C++. With Rust especially, there is no way to avoid dealing with its pointer semantics, as they permeate the language. With D, you can write in a C or even Python-like way (while not having to worry about ownership, memory, etc. as the GC handles it for you), but you can then optimize and add annotations to your code to get a lot more performance and safety once your initial implementation is working. You still have to worry about types, though. But using function templates and the like you can still get fairly 'Python-like' code in D. I find dealing with types to be one of the areas that requires the 'least' amount of mental effort in software development. I don't understand why people see 'untyped' languages as simpler for the most part. I was actually talking about having to specify types everywhere, like in function signatures, the fields of classes and structs, etc. You can still have a language that feels dynamic but is statically typed. The compiler catches type-related bugs for you, and you can prototype something very fast. Then you can add type annotations (if you want). I wouldn't say this language is 'untyped'. One such language is Julia.
Re: Interview at Lang.NEXT
On 6/4/14, 6:11 PM, Craig Dillabaugh wrote: On Wednesday, 4 June 2014 at 20:10:51 UTC, Ary Borenszweig wrote: On 6/4/14, 3:33 PM, Craig Dillabaugh wrote: On Wednesday, 4 June 2014 at 17:31:56 UTC, Ary Borenszweig wrote: On 6/4/14, 1:27 PM, Meta wrote: On Wednesday, 4 June 2014 at 06:19:05 UTC, Andrei Alexandrescu wrote: clip But using function templates and the like you can still get fairly 'Python-like' code in D. I find dealing with types to be one of the areas that requires the 'least' amount of mental effort in software development. I don't understand why people see 'untyped' languages as simpler for the most part. I was actually talking about having to specify types everywhere, like in function signatures, the fields of classes and structs, etc. You can still have a language that feels dynamic but is statically typed. The compiler catches type-related bugs for you, and you can prototype something very fast. Then you can add type annotations (if you want). I wouldn't say this language is 'untyped'. One such language is Julia. OK, but my point was that specifying the type (at least for me) takes an insignificant amount of time (and is very useful months down the road when I am looking at the code, trying to figure out what it is supposed to do). When declaring a variable, in almost every case, figuring out the proper type, and writing that type takes a fraction of a second. The problem comes when you need to refactor your code and swap one type for another. You have to change all ocurrences of that type in that situation for another.
