Search
```On 5/11/12, Walter Bright <newshound2@digitalmars.com> wrote:
> If she wrote:
>     x + 3 = 5
> on the board and asked people to "solve for x", they would fail completely.

Well that's funny, here in europe we've learned to use 'x' since junior school so that's more intuitive for us. :)
```
```On 5/11/12 5:43 PM, Timon Gehr wrote:
> On 05/11/2012 10:29 PM, Jonathan M Davis wrote:
>> On Friday, May 11, 2012 21:02:46 Alex Rønne Petersen wrote:
>>> On 11-05-2012 20:34, Mehrdad wrote:
>>>> On Friday, 11 May 2012 at 18:25:17 UTC, Jonathan M Davis wrote:
>>>>>> Actually, that is a WAT even for somebody coming from C/C++.
>>>>>
>>>>> Really? That's pretty much exactly what I would have expected, and it
>>>>> would
>>>>> really suck if it returned a bool. It's like what you get with find on
>>>>> std::map, only it's a pointer instead of an iterator.
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> Again, try to see it from the perspective of a Python user, not a
>>>> C++ user.
>>>
>>> Speaking of which, 'in' on arrays.........
>>>
>>> *hint hint*
>>
>> Except that it would break the generally expected algoritmic
>> complexity of in,
>> so it'll never happen ( O(n) for arrays, whereas the worst case that
>> would be
>> acceptable would be O(lg n) - e.g. what a binary tree could achieve).
>>
>> - Jonathan M Davis
>
> The main use case I see is replacing tedious
>
> if(foo == 'a' || foo == 'b' || foo == 'c' || foo == 'd') { ... }
>
> with
>
> if(foo in "abcd") { .... }
>
> And here the counter-argument cannot apply, because the operation is in
> O(1).

Yes, "in" for statically-sized arrays does make sense because the complexity if bound at compilation time.

Andrei
```
```On 5/12/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> I always use this idiom:
>
> 	if ("abcd".canFind(foo)) { ... }
>

As do I. Generally when I end up repeating myself all the time I write a helper function.. or if it's something more complicated than that - a template.

Anyway hasn't this thread gone completely off tracks? Maybe Carlos (pspemu author) should try and elaborate exactly which issues he's faced, if he's reading this thread. You can't improve language/tools unless you know what's wrong with them. More real-world feedback about D would be great methinks.
```
```On 12/05/12 01:01, Andrej Mitrovic wrote:
> Well that's funny, here in europe we've learned to use 'x' since
> junior school so that's more intuitive for us. :)

Dangerous to speak for a whole group, I've met plenty of Europeans terrified of mathematical notation.

Some people -- maybe even most people -- automatically freeze up when confronted with a notation that they associate with difficult stuff, or stuff that was too hard (or humiliating) for them at some point in the past.  Maths-phobia is very common in a lot of people who are able to solve the exact same problems if they're not presented in "maths-y" clothing.  By contrast look at how some mathematically gifted people freeze up in social situations!

I saw a violin-playing friend in school freeze up once when she was asked to sightread a short piece with chords in it.  She was adamant that she wasn't skilled enough to play chords properly.  Yet a few seconds' calm examination of the notes on the page would have revealed that all she had to do was draw the bow across a pair of open strings, which is something that just about every violinist, even a beginner, does every day without even thinking about it.  She couldn't see it, because "Oh my God!! Chords!!" got in the way of even trying to consider the problem.
```
```On 5/11/2012 1:20 PM, Jonathan M Davis wrote:
> That's definitely an example of something that depends on your background.
> std.algorithm.any does _exactly_ what it would do in a functional language.
> How intuitive an API is depends a lot on how much the person writing the API
> thinks like you.

That is amusing. I've been writing a bunch of range/algorithm code myself lately, and I find it's a struggle because it is simply not how I think about code. I think in terms of C style loops, and solutions just pop out of my fingers on the keyboard. With ranges, I have to forcibly think in a different way, it's a lot like transitioning from walking to using a snowboard.
```
```On 5/11/2012 12:02 PM, Mehrdad wrote:
> On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
>> On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
>>> template hasMember(T, string name)
>>> { enum hasMember = __traits(hasMember, T, name); }
> [...]
> It's more like, I can imagine someone asking these:
>
> 1. Why the heck do I see "hasMember" twice?
> 2. What does this have to do with enums?
> 3. Where is anything getting "returned"???
> 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING,
> like a template struct, template function, etc...

I tend to agree. I think this is better (I've never gotten around to implementing it):

enum hasMember(T, string name) = __traits(hasMember, T, name);

I.e. analogously to struct templates.
```
```On 05/11/2012 02:45 PM, Timon Gehr wrote:
> On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
>> I use 'in' all the time, and I never even think about it returning a
>> pointer. I just do:
>>
>> if(foo in bar)
>>
>> And it just works. So I don't see a particularly big problem here.
>>
>>
>
> Try this:
>
> bool fun(){ return foo in bar; }

Isn't that an inconsistency in the language then? Are pointer values implicitly convertible to bool or not?

Ali
--
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
```
```On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:
> I know that haskell has such a function, and there were a number of complaints previously that we _didn't_ have an any function which does exactly what std.algorithm.any now does. It's a very functional approach to use predicates like that and I get the impression that it's common in other functional languages based on other's comments. The only one off the top of my head that I _know_ has such a function though is haskell.

Again, I know enough FP to know what predicates are, and of
course, this is common in functional languages.

Even Scheme has a 'there-exists?' function just for this purpose.

I wasn't saying having "such a function" is weird -- I was just
asking if you know of any languages in which the NAME is "any()",
since I would've imagined it to be something more intuitive like
"exists()" or "contains" or "has" or whatever.
(I was giving C# as an example, because C# uses "Any()" to mean,
"are there any elements in this list?", NOT with the meaning D
uses.)
```
```On Friday, 11 May 2012 at 23:47:18 UTC, Walter Bright wrote:
>
> I tend to agree. I think this is better (I've never gotten around to implementing it):
>
>   enum hasMember(T, string name) = __traits(hasMember, T, name);
>
> I.e. analogously to struct templates.

Mmmm... I like the idea/syntax, but not the word "enum". It certainly has nothing to do with enums, so I think it'd be even more confusing in that regard. :)
```
```On 05/11/2012 07:39 PM, Paulo Pinto wrote:
>
> The author of a D based PSP emulator just rewrote
> the emulator in C#, after being disappointed with D.
>
> https://github.com/soywiz/cspspemu
>
> The reasons are listed here,
>
> https://github.com/soywiz/cspspemu#created-after-4-tries
>
> --
> Paulo

Well, those are not reasons for me.

> The lack of a good IDE,

Properties of a 'good IDE', as I see it:

some essential properties:
- starts up instantaneously
- uses the screen space efficiently
- supports editing text efficiently
- accepts keyboard input as given by the user.
- reasonable support for auto-indentation
- supports searching the code for some text efficiently
- keeps all code _readable_, especially the one that has been written recently
- pattern recognition based code completion

- ... by default!

some 'nice to have' properties:
- code analysis based code completion
- navigate-to-declaration
- for those languages that require it: automatic generation of boilerplate.
- integrated debugger
- useful refactoring tools
- visualization of compilation errors (but please don't nag me)
- actual support for detecting semantic errors as they happen (extremely difficult to do properly)
- any other argument that is commonly used to advertise IDEs

- ... _responsive_ on halfway recent hardware!

some anti-features:
- splash screen
- cannot run code if there is no 'project/solution file'
- sometimes messes up those files
- build fails - restart IDE - build works
- fancy GUI
- requires pointing device
- accidental hit of obscure keyboard combination ...
=> permanent, extremely annoying configuration change
=> no way to tell what happened
=> no undo operation
- termination of the debugged program kills the output console

As long as IDEs fail to satisfy every single point in the 'essential' category and strive to have all of the stated anti-features, they don't have much value for me anyway.

> the complicated structure of the D language,

Cannot really comment on that, I think getting work done in D is simple, and with DMD, just slightly harder than that.

> the horrible compilation times,

wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of horrible? Otherwise he might have hit a bug there.

> caused that it taked too much time for everything, and made it
> impossible to refactoring the code without days or weeks of work.

I'd have to know what kind of refactorings he carried out to be able to comment on this.
```