digitalmars.D - Re: New slides about Go
- 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
(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
Oct 17 2010
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
Oct 17 2010
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.
Oct 17 2010
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/
Oct 18 2010
"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.
Oct 18 2010
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
Oct 18 2010
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.
Oct 19 2010
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
Oct 19 2010
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.
Oct 19 2010
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.
Oct 19 2010
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(" "))
Oct 19 2010