• bearophile <bearophileHUGS lycos.com> Oct 17 2010
• Clark Gaebel <cg.wowus.cg gmail.com> Oct 17 2010
• Walter Bright <newshound2 digitalmars.com> Oct 17 2010
• so <so so.do> Oct 18 2010
• "Nick Sabalausky" <a a.a> Oct 18 2010
• bearophile <bearophileHUGS lycos.com> Oct 18 2010
• Paulo Pinto <pjmlp progtools.org> Oct 19 2010
• div0 <div0 sourceforge.net> Oct 19 2010
• type<erasure> <xx xx.xx> Oct 19 2010
• retard <re tard.com.invalid> Oct 19 2010
• retard <re tard.com.invalid> Oct 19 2010

bearophile <bearophileHUGS lycos.com> writes:

(Catching some older posts, I was busy)

Walter:

 In any case, inline assembler in D is a substantial productivity booster for
me 
 for anything that needs assembler. The inline assembler is also quite
ignorable, 
 if you don't like it.


I like the inline assembly feature of D. But language features aren't
ignorable, in real world you often meed or have to modify or fix code written
by other people. This means that a programmer that doesn't know assembly may be
forced to fix bugs in modules that contain functions with asm. So every
language feature is not free, it has a cost.

Bye,
bearophile

Clark Gaebel <cg.wowus.cg gmail.com> writes:

Assembly is vital for almost all CPU-bound applications. Making it
inline just makes people's lives easier.

On 10/17/10 20:23, bearophile wrote:
 (Catching some older posts, I was busy)
 
 Walter:
 
 In any case, inline assembler in D is a substantial productivity booster for
me 
 for anything that needs assembler. The inline assembler is also quite
ignorable, 
 if you don't like it.


 I like the inline assembly feature of D. But language features aren't
ignorable, in real world you often meed or have to modify or fix code written
by other people. This means that a programmer that doesn't know assembly may be
forced to fix bugs in modules that contain functions with asm. So every
language feature is not free, it has a cost.
 
 Bye,
 bearophile


-- 
Regards,
  -- Clark

Walter Bright <newshound2 digitalmars.com> writes:

bearophile wrote:
 Walter:
 
 In any case, inline assembler in D is a substantial productivity booster
 for me for anything that needs assembler. The inline assembler is also
 quite ignorable, if you don't like it.


 I like the inline assembly feature of D. But language features aren't
 ignorable, in real world you often meed or have to modify or fix code written
 by other people. This means that a programmer that doesn't know assembly may
 be forced to fix bugs in modules that contain functions with asm. So every
 language feature is not free, it has a cost.



It's cost is a lot lower than writing the assembler in a separate asm file.

so <so so.do> writes:

Sorry maybe that is just me but that is not really an argument, if you  
want to build a rocket, you would hire capable people.

On Mon, 18 Oct 2010 03:23:21 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 (Catching some older posts, I was busy)

 Walter:

 In any case, inline assembler in D is a substantial productivity  
 booster for me
 for anything that needs assembler. The inline assembler is also quite  
 ignorable,
 if you don't like it.


 I like the inline assembly feature of D. But language features aren't  
 ignorable, in real world you often meed or have to modify or fix code  
 written by other people. This means that a programmer that doesn't know  
 assembly may be forced to fix bugs in modules that contain functions  
 with asm. So every language feature is not free, it has a cost.

 Bye,
 bearophile



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

"Nick Sabalausky" <a a.a> writes:

"so" <so so.do> wrote in message news:op.vkrh77fb7dtt59 so-pc...
 Sorry maybe that is just me but that is not really an argument, if you 
 want to build a rocket, you would hire capable people.


It's amazing how many software houses/departments don't do that. But of 
course, if they don't it's their own damn problem.

bearophile <bearophileHUGS lycos.com> writes:

Nick Sabalausky:

 It's amazing how many software houses/departments don't do that. But of 
 course, if they don't it's their own damn problem.


They want low-salary programmers, so they will avoid languages that may lead to
higher salaries. This means uncommon languages (where programmers are more
rare) or languages that may need the ability to read (or even write) "harder
code" (like inline assembly).

Bye,
bearophile

Paulo Pinto <pjmlp progtools.org> writes:

Am 18.10.2010 22:49, schrieb bearophile:
 Nick Sabalausky:

 It's amazing how many software houses/departments don't do that. But of
 course, if they don't it's their own damn problem.


 They want low-salary programmers, so they will avoid languages that may lead
to higher salaries. This means uncommon languages (where programmers are more
rare) or languages that may need the ability to read (or even write) "harder
code" (like inline assembly).

 Bye,
 bearophile


This is one of the reasons why Java has become such a huge language
in the IT world.

div0 <div0 sourceforge.net> writes:

On 19/10/2010 21:24, Paulo Pinto wrote:
 Am 18.10.2010 22:49, schrieb bearophile:
 Nick Sabalausky:

 It's amazing how many software houses/departments don't do that. But of
 course, if they don't it's their own damn problem.


 They want low-salary programmers, so they will avoid languages that
 may lead to higher salaries. This means uncommon languages (where
 programmers are more rare) or languages that may need the ability to
 read (or even write) "harder code" (like inline assembly).

 Bye,
 bearophile


 This is one of the reasons why Java has become such a huge language
 in the IT world.


yeah but to be fair, I work in a fully C++ shop and only 3 (maybe 4) of 
us out of 18 will *ever* write template code.

even for really trival stuff.

In my xp, most c++ programmers just don't/can't get templates and I very 
much doubt that awkward syntax is the root cause.

if you are one of those people why whould you chose a language with 
templates? they are off no dam use to you.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

type<erasure> <xx xx.xx> writes:

retard Wrote:

 Tue, 19 Oct 2010 21:30:44 +0100, div0 wrote:
 
 On 19/10/2010 21:24, Paulo Pinto wrote:
 Am 18.10.2010 22:49, schrieb bearophile:
 Nick Sabalausky:

 It's amazing how many software houses/departments don't do that. But
 of course, if they don't it's their own damn problem.


 They want low-salary programmers, so they will avoid languages that
 may lead to higher salaries. This means uncommon languages (where
 programmers are more rare) or languages that may need the ability to
 read (or even write) "harder code" (like inline assembly).

 Bye,
 bearophile


 This is one of the reasons why Java has become such a huge language in
 the IT world.


 yeah but to be fair, I work in a fully C++ shop and only 3 (maybe 4) of
 us out of 18 will *ever* write template code.
 
 even for really trival stuff.
 
 In my xp, most c++ programmers just don't/can't get templates and I very
 much doubt that awkward syntax is the root cause.
 
 if you are one of those people why whould you chose a language with
 templates? they are off no dam use to you.


 Templates are used for at least two different purposes - to provide 1) 
 (generic) parametric polymorphism and 2) (generative) metaprogramming 
 code. Often the parametric version is enough (e.g. simple uses of 
 collections).


Complex C++/D collections are no simple generics. They have custom allocators
and so forth. Study your home work, kid.

 
 The first case is "optimized" in many modern language. For instance in 
 Scala polymorphic collections are rather simple to use:


Ha, you don't know anything of Java VM now do you? Type erasure removes all
efficiency and makes your stupid code run at least twice slower than real
generics. On top of that comes VM start up time and other garbage collection
costs. Your solution is screwed when put against real native C++/D meta
programming.

[snip ugly Scala & C++]

 Typical use cases don't require type annotations anywhere. The only 
 problem with high level languages is that they may in some cases put more 
 pressure to the optimizations in the compiler.


We want overly complex compilers with 10+ seconds run time? Hell no.

 What's funny is that the Scala developer here "implicitly" used terribly 
 complex templates behind the scenes. And it's as simple as writing in 
 some toy language.


Scala is just academic toy.

 Overall, even the novice developers are so expensive that you can often 
 replace the lost effiency with bigger hardware, which is cheaper than the 
 extra development time would have been. This is many times the situation 
 *now*, it might change when the large cloud servers run out of resources.


Slow code costs more in cloud services even today. You want cheap ? You write
in native code.

retard <re tard.com.invalid> writes:

Tue, 19 Oct 2010 21:30:44 +0100, div0 wrote:

 On 19/10/2010 21:24, Paulo Pinto wrote:
 Am 18.10.2010 22:49, schrieb bearophile:
 Nick Sabalausky:

 It's amazing how many software houses/departments don't do that. But
 of course, if they don't it's their own damn problem.


 They want low-salary programmers, so they will avoid languages that
 may lead to higher salaries. This means uncommon languages (where
 programmers are more rare) or languages that may need the ability to
 read (or even write) "harder code" (like inline assembly).

 Bye,
 bearophile


 This is one of the reasons why Java has become such a huge language in
 the IT world.


 yeah but to be fair, I work in a fully C++ shop and only 3 (maybe 4) of
 us out of 18 will *ever* write template code.
 
 even for really trival stuff.
 
 In my xp, most c++ programmers just don't/can't get templates and I very
 much doubt that awkward syntax is the root cause.
 
 if you are one of those people why whould you chose a language with
 templates? they are off no dam use to you.


Templates are used for at least two different purposes - to provide 1) 
(generic) parametric polymorphism and 2) (generative) metaprogramming 
code. Often the parametric version is enough (e.g. simple uses of 
collections).

The first case is "optimized" in many modern language. For instance in 
Scala polymorphic collections are rather simple to use:

// using namespace std;

val l = List(1,2,3)
// list<int> l(1,2,3);

println("The contents are: ")
// cout << "The contents are: ";

println(l.mkString(" "))
//  for (list<int>::iterator it = l.begin(); it != l.end(); it++)
//    cout << *it << " ";
//  cout << endl;

println("Squared: ")
// cout << "Squared: ";

println(l.map(2 *).mkString(" "))
//  for (list<int>::iterator it = l.begin(); it != l.end(); it++)
//    cout << (*it)*(*it) << " ";
//  cout << endl;

Typical use cases don't require type annotations anywhere. The only 
problem with high level languages is that they may in some cases put more 
pressure to the optimizations in the compiler.

What's funny is that the Scala developer here "implicitly" used terribly 
complex templates behind the scenes. And it's as simple as writing in 
some toy language.

Overall, even the novice developers are so expensive that you can often 
replace the lost effiency with bigger hardware, which is cheaper than the 
extra development time would have been. This is many times the situation 
*now*, it might change when the large cloud servers run out of resources.

retard <re tard.com.invalid> writes:

Tue, 19 Oct 2010 22:55:31 +0000, retard wrote:

 println(l.map(2 *).mkString(" "))


Made a mistake here, the correct code should be:

println(l.map(a => a*a).mkString(" "))