On 2013-10-04 21:15, Nick Sabalausky wrote:

> Yea, exactly.
>
> I'm amazed that even "low-end" budget machines are so
> ridiculously powerful these days. Pretty damn cool.

But applications are still just as slow as they have always been.

-- 
/Jacob Carlborg

On 05.10.2013 12:58, Jacob Carlborg wrote:
> On 2013-10-04 21:15, Nick Sabalausky wrote:
>
>> Yea, exactly.
>>
>> I'm amazed that even "low-end" budget machines are so
>> ridiculously powerful these days. Pretty damn cool.
>
> But applications are still just as slow as they have always been.
>

That is a consequence of putting VM upon VM layer in current systems,
coupled with the fact that most current developers code without any
regard for performance, be it in memory usage or execution speed.

--
Paulo

On Saturday, 5 October 2013 at 10:58:54 UTC, Jacob Carlborg wrote:
> On 2013-10-04 21:15, Nick Sabalausky wrote:
>
>> Yea, exactly.
>>
>> I'm amazed that even "low-end" budget machines are so
>> ridiculously powerful these days. Pretty damn cool.
>
> But applications are still just as slow as they have always been.

They are not the same applications.

On 05/10/13 01:55, deadalnix wrote:
> D has some really serious flaw when it come to functionnal style.

Really?  That's a shame. :-(

>   - Function aren't first class.
>   - Delegates break type system.
>   - Immutable object have identity issue that wouldn't show up in a functional
> language. It is unsure what the semantic around them is (and if identity must be
> preserved, then functional style is badly impaired).
>   - Many qualifier do start to not make any sense when using functions as
> arguments (inout for instance).
>   - Expect for type qualifier, it is impossible to express return qualification
> depending on the input(s qualification (and see point above, that do not work
> when using first class functions/delegates).
>
> On implementation side, heap allocated values aren't optimized to go on the
> stack, ever. And the GC is unable to take advantage of immutability. Note that
> because everything is immutable in functional programming, both are mandatory if
> you don't want to trash your performances.

How much of this is actually a language problem (I imagine the first-class functions and delegate issues are) and how much is to do with implementation?

On Sunday, 6 October 2013 at 16:02:24 UTC, Joseph Rushton Wakeling wrote:
> On 05/10/13 01:55, deadalnix wrote:
>> D has some really serious flaw when it come to functionnal style.
>
> Really?  That's a shame. :-(
>
>>  - Function aren't first class.
>>  - Delegates break type system.
>>  - Immutable object have identity issue that wouldn't show up in a functional
>> language. It is unsure what the semantic around them is (and if identity must be
>> preserved, then functional style is badly impaired).
>>  - Many qualifier do start to not make any sense when using functions as
>> arguments (inout for instance).
>>  - Expect for type qualifier, it is impossible to express return qualification
>> depending on the input(s qualification (and see point above, that do not work
>> when using first class functions/delegates).
>>
>> On implementation side, heap allocated values aren't optimized to go on the
>> stack, ever. And the GC is unable to take advantage of immutability. Note that
>> because everything is immutable in functional programming, both are mandatory if
>> you don't want to trash your performances.
>
> How much of this is actually a language problem (I imagine the first-class functions and delegate issues are) and how much is to do with implementation?

What comes before "On implementation side" is language problem. What comes after is implementation problem.

On 05/10/2013 11:58, Jacob Carlborg wrote:
> On 2013-10-04 21:15, Nick Sabalausky wrote:
>
>> Yea, exactly.
>>
>> I'm amazed that even "low-end" budget machines are so
>> ridiculously powerful these days. Pretty damn cool.
>
> But applications are still just as slow as they have always been.
>

Yes, unfortunately that much is still true, for a lot of applications.

It's not that my desktop runs every application super fast, there is still a lot of slowness and slugishness, but they are caused by badly designed code or other problems. Some of them might not even be affect by a hardware spec change at all (like code that does long-running or IO-blocking operations in UI-thread, etc.)

(Firefox + Flash/Youtube... arghh)

-- 
Bruno Medeiros - Software Engineer

On 2013-10-08 12:34, Bruno Medeiros wrote:

> Yes, unfortunately that much is still true, for a lot of applications.
>
> It's not that my desktop runs every application super fast, there is
> still a lot of slowness and slugishness, but they are caused by badly
> designed code or other problems. Some of them might not even be affect
> by a hardware spec change at all (like code that does long-running or
> IO-blocking operations in UI-thread, etc.)
>
> (Firefox + Flash/Youtube... arghh)

Yeah, Flash on Mac OS X is even worse then on other platform. Just disable Flash and rely on HTML5.

-- 
/Jacob Carlborg