On 19/05/2012 02:33, Jesse Phillips wrote:
> On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:
>> So just starting up the IDE is more important than actually writing
>> code or fixing bugs?...
>
> I'd like to see you do those things without starting your IDE.

Oh yeah, I'd like to see you do those things using just one hand. Or with your eyes closed!...

...do you understand why I made that satire above?
Yes, my productivity would take a huge hit if I didn't have an IDE. Coding without an IDE for me is like coding with just one hand, or something like that. But why would I code without an IDE? I see no point in adding such restrictions to my development activity, I am not the kind of software developer that sees value in artificial limitations to show off your hacksmanship or mad coding skillz (hey, I'm editing inodes by hand...   ...WITH MAGNETS!!!)
If you are such a developer, if you like tricks and artificial challenges, then that's fine, let's just call it a difference in goals. But my main goal and interest in software development is to produce high quality software in the most efficient way.

-- 
Bruno Medeiros - Software Engineer

On 20/05/2012 15:19, Timon Gehr wrote:
> No, you misunderstand.
>
> - Time spent starting up the IDE is lost time that could be spent doing
> something productive instead. Hardware is fast. There is simply no
> excuse for poor start up times/poor responsiveness.

I am not misunderstanding. No one is saying there is no value in saving that start up time. But you listed that as *more* important than many other features that actually help a lot (and thus save time a lot) when you code, or debug programs.

Oh and there are excuses for poor start up times. I am not gonna explain them because it would get technical and long.



-- 
Bruno Medeiros - Software Engineer

On 30-05-2012 17:30, Bruno Medeiros wrote:
> On 20/05/2012 15:19, Timon Gehr wrote:
>> No, you misunderstand.
>>
>> - Time spent starting up the IDE is lost time that could be spent doing
>> something productive instead. Hardware is fast. There is simply no
>> excuse for poor start up times/poor responsiveness.
>
> I am not misunderstanding. No one is saying there is no value in saving
> that start up time. But you listed that as *more* important than many
> other features that actually help a lot (and thus save time a lot) when
> you code, or debug programs.
>
> Oh and there are excuses for poor start up times. I am not gonna explain
> them because it would get technical and long.
>
>
>

I'm just going to add that Visual Studio 11 can start up in less than a second. Visual Studio 2010 could take well towards 10 seconds (and sometimes more if you have many extensions). They solved the problem simply by lazy-loading almost everything they could. It turns out that the majority of stuff that most IDEs load on startup isn't going to be used during a session, so it's just wasted time.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

I just replied here with my motivations:
https://github.com/soywiz/pspemu/issues/1

"D is just fine to create an emulator. The problem was that I was doing emergent design, so I was refactoring a lot. And design flaws caused the refactorings to be massive. D didn't had a good IDE allowing refactoring by that moment (not sure about that now). That was the main reason for me to change the technology. Also there was minor flaws:
Compilation times were huge. I was using lot of compile-time code generation and at least at that time, that code was interpreted or not enought fast for me. Also I didn't get incremental compilation working, it failed everytime probably because that compilation-time stuff causing the compilation to take stuff like 1 entire minute. And that was unacceptable too for me. I needed to run it lots of times to doing research. Also I needed a needed to chaneg the emulator to perform dynamic recompilation instead of just interpreting. With C# I could do portable dynarec very easily. In the case of D I would have to creaet a emitter per supported platform (mostly x86, x64 and ARM).

And my decission to use C# was not because I didn't like D. In fact, I liked D a lot, that much that I started an emulator using it."

soywiz:

> D didn't had a good IDE allowing refactoring by that moment

That's mostly a tools/ecosystem problem, but perhaps the language design could help a little to perform the refactoring. How can a language help refactoring?


> Compilation times were huge. I was using lot of compile-time code generation and at least at that time, that code was interpreted or not enought fast for me.

This is a known problem, it can be solved, people are working on it, and I think eventually it will be partially solved.


> Also I needed a needed to chaneg the emulator to perform dynamic recompilation instead of just interpreting. With C# I could do portable dynarec very easily. In the case of D I would have to creaet a emitter per supported platform (mostly x86, x64 and ARM).

I think this is mostly a library problem.

Bye,
bearophile

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.

Ruby has a function like that as well. It works like the Haskell version if you pass a predicate. If you don't pass an argument it works like the one in C#.

--
/Jacob Carlborg

On Friday, 11 May 2012 at 23:51:47 UTC, Mehrdad wrote:
> 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.)

In .NET 3.5, and later, 'Any()' has an overload that takes a predicate so it behaves identical to 'any' in Haskell and D.

public static bool Any<TSource>(
	this IEnumerable<TSource> source,
	Func<TSource, bool> predicate
)

The Exists method is an older construct with a more limited application (List vs IEnumerable)

On Saturday, 12 May 2012 at 03:42:10 UTC, Ary Manzana wrote:
> On 5/12/12 3:40 AM, Mehrdad wrote:
>> On Friday, 11 May 2012 at 20:20:36 UTC, 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.
>>
>> Well, I know some FP (Scheme/newLISP) but they don't have an "any"
>> function. I don't know about F#, but my guess would be that it would do
>> the same thing as C# would (for obvious reasons).
>>
>> Are you thinking of a language in particular that has D's behavior? Or
>> is this just a guess?
>
> Ruby has any?:
>
> http://ruby-doc.org/core-1.9.3/Enumerable.html#method-i-any-3F
>
> And it's the best of the two worlds: given a block (a lambda) it works like D. Give no lambda and it just returns true if the enumerable has any elements.
>
> Ruby wins again. :-P

This is in fact the exact behaviour of .NET's Any (on IEnumerable). This is a library thing, not a language thing.