www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GCC 4.6

reply bearophile <bearophileHUGS lycos.com> writes:
Some changes in the new version of GCC, 4.6:

New warnings (I want something similar in D too):

New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
added for C, C++, Objective-C and Objective-C++. These warnings diagnose
variables respective parameters which are only set in the code and never
otherwise used. Usually such variables are useless and often even the value
assigned to them is computed needlessly, sometimes expensively. The
-Wunused-but-set-variable warning is enabled by default by -Wall flag and
-Wunused-but-set-parameter by -Wall -Wextra flags.<

Link-Time Optimizations is now more powerful:
GCC itself, Mozilla Firefox and other large applications can be built with LTO
enabled.<

Static constructors and destructors from individual units are inlined into a
single function. This can significantly improve startup times of large C++
applications where static constructors are very common. <

Improved auto-detection of const and pure functions. Newly, noreturn functions
are auto-detected.<

Interesting:
The -Wsuggest-attribute=[const|pure|noreturn] flag is available that informs
users when adding attributes to headers might improve code generation.<

-Wsuggest-attribute=[pure|const|noreturn] Warn for cases where adding an attribute may be beneficial. The attributes currently supported are listed below. -Wsuggest-attribute=pure -Wsuggest-attribute=const -Wsuggest-attribute=noreturn Warn about functions which might be candidates for attributes pure, const or noreturn. The compiler only warns for functions visible in other compilation units or (in the case of pure and const) if it cannot prove that the function returns normally. A function returns normally if it doesn't contain an infinite loop nor returns abnormally by throwing, calling abort() or trapping. This analysis requires option -fipa-pure-const, which is enabled by default at -O and higher. Higher optimization levels improve the accuracy of the analysis. I will have to test this:
Virtual methods are considered for inlining when the caller is inlined and
devirtualization is then possible.<

Functions whose address was taken are now optimized out when all references to
them are dead.<

This is sometimes useful in smaller systems, I think:
A new switch -fstack-usage has been added. It makes the compiler output stack
usage information for the program, on a per-function basis, in an auxiliary
file.<

I don't undersatand why this is useful, why the compiler isn't able to infer this by itself:
A new function attribute leaf was introduced. This attribute allows better
inter-procedural optimization across calls to functions that return to the
current unit only via returning or exception handling. This is the case for
most library functions that have no callbacks.<

And I understand this even less:
The new function attribute callee_pop_aggregate allows to specify if the caller
or callee is responsible for popping the aggregate return pointer value from
the stack.<

This is curious, in nothrow functions throws become halts:
The new -fnothrow-opt flag changes the semantics of a throw() exception
specification to match the proposed semantics of the noexcept specification:
just call terminate if an exception tries to propagate out of a function with
such an exception specification. This dramatically reduces or eliminates the
code size overhead from adding the exception specification.<

This seems useful:
The -Wshadow option now warns if a local variable or type declaration shadows
another type in C++. Note that the compiler will not warn if a local variable
shadows a struct/class/enum, but will warn if it shadows an explicit typedef.<

When an identifier is not found in the current scope, G++ now offers
suggestions about which identifier might have been intended.<

Support for the Go programming language has been added to GCC. It is not
enabled by default when you build GCC; use the --enable-languages configure
option to build it.<

It seems GCC now supports the TBM (Trailing Bit Manipulation) instructions too: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01767.html Bye, bearophile
Mar 26 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/26/11 4:51 PM, bearophile wrote:
 Some changes in the new version of GCC, 4.6:

Heh, I was just following the reddit discussion, in which D vs. Go was due to appear: http://www.reddit.com/r/programming/comments/gbzvv/gcc_46_is_released/ Andrei
Mar 26 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 27, 11 05:51, bearophile wrote:
 I don't undersatand why this is useful, why the compiler isn't able to infer
this by itself:

A new function attribute leaf was introduced. This attribute allows better
inter-procedural optimization across calls to functions that return to the
current unit only via returning or exception handling. This is the case for
most library functions that have no callbacks.<



Most of these attributes are designed for control freaks that don't believe in the compiler's decision :). gcc's manual says,
 Calls to external functions with this attribute must return to the current
compilation unit only by return or by exception handling. In particular, leaf
functions are not allowed to call callback function passed to it from the
current compilation unit or directly call functions exported by the unit or
longjmp into the unit. Leaf function might still call functions from other
compilation units and thus they are not necessarily leaf in the sense that they
contain no function calls at all.
 The attribute is intended for library functions to improve dataflow analysis.
The compiler takes the hint that any data not escaping the current compilation
unit can not be used or modified by the leaf function. For example, the sin
function is a leaf function, but qsort is not.

 Note that leaf functions might invoke signals and signal handlers might be
defined in the current compilation unit and use static variables. The only
compliant way to write such a signal handler is to declare such variables
volatile.

 The attribute has no effect on functions defined within the current
compilation unit. This is to allow easy merging of multiple compilation units
into one, for example, by using the link time optimization. For this reason the
attribute is not allowed on types to annotate indirect calls.

;
 And I understand this even less:

The new function attribute callee_pop_aggregate allows to specify if the caller
or callee is responsible for popping the aggregate return pointer value from
the stack.<



Just calling convention stuff.
Mar 26 2011
parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:

 Just calling convention stuff.

Oh, right, now I understand that changelog comment :-) Bye, bearophile
Mar 26 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 26.03.2011, 22:51 Uhr, schrieb bearophile <bearophileHUGS lycos.com>:
 Some changes in the new version of GCC, 4.6:
 Link-Time Optimizations is now more powerful:

 GCC itself, Mozilla Firefox and other large applications can be built  
 with LTO enabled.<


LTO ftw!
Mar 26 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2011 2:51 PM, bearophile wrote:
 This seems useful:

 The -Wshadow option now warns if a local variable or type declaration
 shadows another type in C++. Note that the compiler will not warn if a
 local variable shadows a struct/class/enum, but will warn if it shadows an
 explicit typedef.<


D already does this.
 When an identifier is not found in the current scope, G++ now offers
 suggestions about which identifier might have been intended.


and this.
Mar 26 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 D already does this.
 and this.

But not this:
New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
added for C, C++, Objective-C and Objective-C++. These warnings diagnose
variables respective parameters which are only set in the code and never
otherwise used. Usually such variables are useless and often even the value
assigned to them is computed needlessly, sometimes expensively. The
-Wunused-but-set-variable warning is enabled by default by -Wall flag and
-Wunused-but-set-parameter by -Wall -Wextra flags.<

Bye, bearophile
Mar 26 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2011 6:28 PM, bearophile wrote:
 Walter:

 D already does this. and this.

But not this:
 New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
 added for C, C++, Objective-C and Objective-C++. These warnings diagnose
 variables respective parameters which are only set in the code and never
 otherwise used. Usually such variables are useless and often even the value
 assigned to them is computed needlessly, sometimes expensively. The
 -Wunused-but-set-variable warning is enabled by default by -Wall flag and
 -Wunused-but-set-parameter by -Wall -Wextra flags.<


This is quite deliberate. These kinds of errors tend to be very annoying when developing code. The optimizer removes those as "dead assignments", so no value is computed needlessly or expensively.
Mar 26 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
 added for C, C++, Objective-C and Objective-C++. These warnings diagnose
 variables respective parameters which are only set in the code and never
 otherwise used. Usually such variables are useless and often even the value
 assigned to them is computed needlessly, sometimes expensively. The
 -Wunused-but-set-variable warning is enabled by default by -Wall flag and
 -Wunused-but-set-parameter by -Wall -Wextra flags.<



 These kinds of errors tend to be very annoying when developing code.

With "errors" do you mean the warnings GCC 4.6 shows you when you add the "-Wunused-but-set-variable" to the switches? I have not tried GCC4.6 yet, but GCC 4.5 has a related warning, for unused variables. This warning is present in the C# compiler too, and it's also present in a C lint I use (and probably in the C++ Microsoft compiler too). This warning has caught some bugs in my C/C++ code. So I like it/them a lot.
 The optimizer removes those as "dead assignments", so no value is computed 
 needlessly or expensively.

The point of those warnings is NOT to improve code/compiler optimizations, but just to help programmers catch their bugs better. A nice paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson Engler, 2002: http://www.stanford.edu/~engler/p401-xie.pdf It shows that most programmers don't put deliberatively redundancies in their programs, like assigning a value to a variable and never reading it again (in all code paths). When this happens in programs, frequently that's a bug of the programmer. So catching unused variables, or variables set and then never read is a good way to catch programmers bugs. GCC designers, C# compiler designers, a known lint designers, that paper (and my personal experience in C) tell the same story. A way to automatically find unused variables is good in the compiler. I think it's not easy for you to confute them all :-) Bye, bearophile
Mar 26 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2011 7:10 PM, bearophile wrote:
 The optimizer removes those as "dead assignments", so no value is computed
 needlessly or expensively.

but just to help programmers catch their bugs better.

You quoted a claim saying it was also an optimization.
 A nice paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson
 Engler, 2002: http://www.stanford.edu/~engler/p401-xie.pdf

 It shows that most programmers don't put deliberatively redundancies in their
 programs, like assigning a value to a variable and never reading it again (in
 all code paths). When this happens in programs, frequently that's a bug of
 the programmer. So catching unused variables, or variables set and then never
 read is a good way to catch programmers bugs.

As I said, these kinds of error messages are very annoying when developing code, for example, when enabling and disabling various sections.
 GCC designers, C# compiler designers, a known lint designers, that paper (and
 my personal experience in C) tell the same story. A way to automatically find
 unused variables is good in the compiler. I think it's not easy for you to
 confute them all :-)

I get told I'm wrong on just about everything I do.
Mar 26 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 You quoted a claim saying it was also an optimization.

If GCC devs say so, then I presume they are right. But the main purpose of a warning is to warn the programmer, in this case to avoid some bugs.
 As I said, these kinds of error messages are very annoying when developing
code, 
 for example, when enabling and disabling various sections.

Warnings have a cost. Sometimes they are locally wrong, becoming noise, so in some situations people want to disable specific warnings locally (GCC 4.6 has added ways to do this). In some situations I agree that an error is better than a warning message, indeed D has turned some C warnings into errors. There are even two D warnings that I want to become errors: http://d.puremagic.com/issues/show_bug.cgi?id=3836 http://d.puremagic.com/issues/show_bug.cgi?id=4216 Elsewhere you have explained that different compilers have different warnings, this combined with the choice of many programmers to see warnings as errors produces incompatible programs, it means that changing the compiler becomes almost like changing language (a possible solution I see to this problem is to standardize most warnings in a language. So most warnings are shared between compilers of the same language). Regarding what you say here, I agree that when you develop a part of code you want a little more local freedom. Because you often have some scaffolding code, variables, etc, that you use to build the main code. This means that in code that's work in progress you sometimes have duplicated variables, redundancies, and several other things that are probably seen as problems by a more strict compiler. On the other hand, the amount of code you work in a moment is not large, so the amount of warnings your program generates is not large (assuming most other part of the code don't generate warnings or have silenced warnings), so I think such limited amount of warnings is going to be acceptable. Maybe there is a way to disable the warnings in just the parts of the program you are working now. But warnings sometimes are useful, so they may catch bugs you are adding in the new code you are adding/changing now. The most part of a largish program is not under change in any moment (even if many people are working on a program at the same time). And experience has shown me that unused variables in cold code (code you are not modifying right now) are sometimes associated with bugs or other troubles (this was also the main point of that paper by Yichen Xie). And removing them helps make the code shorter, more tidy. It's worse than leaving useless phrases in a text.
 I get told I'm wrong on just about everything I do.

In D language/compiler I have found many good decisions, most of them are good, that's why I am here :-) But there are things I don't agree with, and I try to explain why. Like that section 3 page 2 "Redundant assignments" on the Yichen Xie paper. In my code and code written by other people I have seen many times little errors like this, or several similar variations of it: class Foo { int x, y, z; Foo(int x_, int y_, int z_) { x = x_; y = y; z = z_; } ... } If the lint is able to spot redundant assignments, it shows a warning. A compiler may even turn redundant assignments into errors. D turns unassigned pure expressions into errors: void main() { int x = 10; int y = 20; x + y; } test.d(4): Error: + has no effect in expression (x + y) But currently this gives no errors, despite it's the same situation, so I'd like an error here too (this enhancement request is in Bugzilla already): pure int add(int a, int b) { return a + b; } void main() { int x = 10; int y = 20; add(x, y); } In the paper by Yichen Xie you see many other interesting cases, that come from real world code, it's quite interesting stuff. Bye, bearophile
Mar 27 2011
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Walter:
 You quoted a claim saying it was also an optimization.


Warnings have no effect on optimisations. And unused code are later removed via general dead code elimination anyway (how aggressive this is depends on the optimisation level).
Mar 27 2011
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
 test.d(4): Error: + has no effect in expression (x + y)
 But currently this gives no errors, despite it's the same situation, so I'd
like

 pure int add(int a, int b) { return a + b; }
 void main() {
     int x = 10;
     int y = 20;
     add(x, y);
 }

I think it would be better if it were targeting memory/(re)allocation-related functions. ie: { new int[4096]; // allocation has no effect, other than leaking memory. }
Mar 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Iain Buclaw:

 I think it would be better if it were targeting memory/(re)allocation-related
 functions.
 
 ie:
 {
   new int[4096];  // allocation has no effect, other than leaking memory.
 }

(The memory does not leak, the GC will deallocate it later). In Bugzilla I have proposed that if you call a pure function and you don't assign its return value, then you have a bug, like the similar present in D for unassigned expressions. If the druntime function to allocate a new array is a pure function, then my enhancement request catches your bug too :-) Bye, bearophile
Mar 27 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 27, 11 22:30, bearophile wrote:
 In Bugzilla I have proposed that if you call a pure function and you don't
assign its return value, then you have a bug, like the similar present in D for
unassigned expressions.

This should be restricted to *strongly* pure functions. Weakly pure functions may have its major effect sent out via the input arguments, so ignoring the return value could make sense. import std.stdio; pure double[] set(double[] x, int index, double e) { x[index] = e; return x; } void main () { auto j = new double[](3); j.set(0, 1.5).set(1, 2.5).set(2, 5.1); writeln(j); } BTW, which Bugzilla entry you are talking about?
Mar 27 2011
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Mar 27, 11 23:19, KennyTM~ wrote:
 On Mar 27, 11 22:30, bearophile wrote:
 In Bugzilla I have proposed that if you call a pure function and you
 don't assign its return value, then you have a bug, like the similar
 present in D for unassigned expressions.

This should be restricted to *strongly* pure functions. Weakly pure functions may have its major effect sent out via the input arguments, so ignoring the return value could make sense. import std.stdio; pure double[] set(double[] x, int index, double e) { x[index] = e; return x; } void main () { auto j = new double[](3); j.set(0, 1.5).set(1, 2.5).set(2, 5.1); writeln(j); } BTW, which Bugzilla entry you are talking about?

OK, I see it is 3882. http://d.puremagic.com/issues/show_bug.cgi?id=3882
Mar 27 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:

 This should be restricted to *strongly* pure functions.

Right, I have added the note. I have written the enhancement request 3882 before the introduction of the weakly pure ones. Bye, bearophile
Mar 27 2011
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Iain Buclaw:
 I think it would be better if it were targeting memory/(re)allocation-related
 functions.

 ie:
 {
   new int[4096];  // allocation has no effect, other than leaking memory.
 }


Assuming you are using the stock implementation that comes bundled with Druntime, and not some stub implementation or freestanding environment. :~)
Mar 27 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2011 7:30 AM, bearophile wrote:
 In Bugzilla I have proposed that if you call a pure function and you don't
 assign its return value, then you have a bug, like the similar present in D
 for unassigned expressions.

I think that's a reasonable proposal.
Mar 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 On 3/27/2011 7:30 AM, bearophile wrote:
 In Bugzilla I have proposed that if you call a pure function and you don't
 assign its return value, then you have a bug, like the similar present in D
 for unassigned expressions.

I think that's a reasonable proposal.

:-) Thank you. This is the enhancement request (about one year old): http://d.puremagic.com/issues/show_bug.cgi?id=3882 Bye, bearophile
Mar 27 2011
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Caligo (iteronvexor gmail.com)'s article
 I've been doing a lot of coding in D in the past few weeks, and one
 thing I've noticed is that performance is not great.  Surprisingly,
 DMD generated binaries perform worse than GDC's, but even GDC is
 lagging behind equivalent code written in C++ and compiled with G++.
 Are we to expect performance to improve as more work is done on GDC?

There's a lot going on behind the scenes, so that's hard to say that your code is 'genuinely equivalent'.
 Another thing that's bothering me is that there is currently only one
 active developer working on GDC.

:'(
Mar 28 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2011 9:09 AM, Caligo wrote:
 I've been doing a lot of coding in D in the past few weeks, and one
 thing I've noticed is that performance is not great.  Surprisingly,
 DMD generated binaries perform worse than GDC's, but even GDC is
 lagging behind equivalent code written in C++ and compiled with G++.
 Are we to expect performance to improve as more work is done on GDC?

There is no technical reason why performance should be worse. It's a matter of investing the time and effort into the code generation.
Mar 28 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 3/28/2011 9:09 AM, Caligo wrote:
 I've been doing a lot of coding in D in the past few weeks, and one
 thing I've noticed is that performance is not great.  Surprisingly,
 DMD generated binaries perform worse than GDC's, but even GDC is
 lagging behind equivalent code written in C++ and compiled with G++.
 Are we to expect performance to improve as more work is done on GDC?

investing the time and effort into the code generation.

Correct me if I'm wrong, but I think some important optimizations (like inlining) are performed in the front end. It's pretty obvious that DMD's inliner needs improvement, though I agree with Walter's decision to prioritize this below fixing major bugs, 64 support and (before that) finalizing the spec. Therefore, the performance of GDC is still a quality of implementation issue rather than a fundamental technical issue.
Mar 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2011 11:49 AM, dsimcha wrote:
 Correct me if I'm wrong, but I think some important optimizations (like
inlining)
 are performed in the front end.  It's pretty obvious that DMD's inliner needs
 improvement, though I agree with Walter's decision to prioritize this below
fixing
 major bugs, 64 support and (before that) finalizing the spec.  Therefore, the
 performance of GDC is still a quality of implementation issue rather than a
 fundamental technical issue.

By fundamental technical issue, I mean things like Python's numeric types which require runtime testing for every operation, and are very resistant to known techniques of optimization. D's perf problems have known causes that are not faults in the language, but are fixable in the compiler using known techniques. It's just a matter of priorities and manpower. In fact, D has many attributes that offer the potential for significantly better code generation than C/C++. They've just not been exploited yet.
Mar 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 By fundamental technical issue, I mean things like Python's numeric types
which 
 require runtime testing for every operation, and are very resistant to known 
 techniques of optimization.

Life is a bit more complex than that: - The Lua JIT has shown once and for all that dynamic typing is not as bad (performance-wise) as you think. I have floating-point heavy benchmarks that run faster in jitted Lua than in D compiled with DMD. - Python is a language, and there are many ways to run a language. You are able to interpret D code and to compile Python code. Since several years I am helping the develpment of ShedSkin, a Python->C++ compiler, that uses powerful type inferencing to infer all the static types of an implicitly static Python program. The results are sometimes faster than D programs compiled with DMD, because they are essentially pretty clean C++ programs compiled by G++. - Today GPUs are used more and more where the max performance is needed, and example: http://www.i-programmer.info/news/105-artificial-intelligence/2176-kinects-ai-breakthrough-explained.html And you are able to write and run such GPU kernels from Python code too. Bye, bearophile
Mar 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2011 1:12 PM, bearophile wrote:
 Walter:

 By fundamental technical issue, I mean things like Python's numeric types
 which require runtime testing for every operation, and are very resistant
 to known techniques of optimization.

Life is a bit more complex than that: - The Lua JIT has shown once and for all that dynamic typing is not as bad (performance-wise) as you think.

There's a lot of money and manpower behind Python. If this were true, why hasn't this technology been done for Python? Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in hybrid configurations with C and C++, so there is clearly some sort of deficit with Lua.
 I have
 floating-point heavy benchmarks that run faster in jitted Lua than in D
 compiled with DMD.

Come on. As has been discussed to death here, dmd's back end does not do floating point well, in particular, it does not make use of XMM instructions. Any code generator that does will perform better. And, Python does not have the dynamic typing issue with floats that it does with integers. Jitted floating point Python code *should* match performance with statically compiled floating point code.
Mar 28 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

There's a lot of money and manpower behind Python. If this were true, why
hasn't this technology been done for Python?<

It was done, more than one time. One good JIT was Psyco. And more recently PyPy is about to surpass Psyco in performance: http://codespeak.net/pypy/dist/pypy/doc/ But the Lua JIT is quite better than Psyco, its programmer is very intelligent (Psyco author too is an intelligent programmer, Armin Rigo). And more importantly, this whole discussion can't be reduced to just a static Vs dynamic typing. Lua and Python are different languages, Python is probably more dynamic than Lua, it is quite more powerful than Lua, and it's different. So creating a really efficient JIT for Python is much harder than doing it for Lua, and you can't compare them much. The result is that currently PyPy is generally about 8/10 times slower than D code, while Lua-Jit is about 2-3 times slower than D compiled well, and JavaScript running on the V8-CrankShaft JIT is about 3-4 times slower than D. And Mozilla hopes to someday beat V8, though a local static inferencer (probably to be seen in Firefox 5? See the "(TypeInference)" here, it's in development still: http://arewefastyet.com/?a=b&view=regress ).
 Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in hybrid
 configurations with C and C++, so there is clearly some sort of deficit with
Lua.

Lua is a quite simple language, there are some things you can't do well with it, so you need other languages. And even with a JIT Lua is often not as fast as good C code. I have never said that Lua+JIT is better than D, I am not much interested in Lua.
 And, Python does not have the dynamic typing issue with floats that it does
with
 integers. Jitted floating point Python code *should* match performance with
 statically compiled floating point code.

Regarding strictly *dynamic typing* Python floats are as dynamic as Python integers. You probably mean that Python floats are structs that wrap around CPU doubles, while Python3 integers are multi-precision ones (Python2 integers are hybrids). The fact they are multi-precision is orthogonal to dynamic typing: you are able to use multi-precision integers in D too (BigInt). Multi-precision integers are not intrinsically dynamically typed. Regarding multi-precision integers, CommonLisp, OcaML and Factor languages show that tagged integers (that become multi-precision when the stack-allocated fixed ones have an overflow) are not as slow as you think. I have written small programs in Factor (a modern and quite refined stack-based language), and if you don't go past the precision of the tagged integers, they don't slow down the code a lot. Their slowdown is comparable to the difference of runtime performance of array-heavy D code compiled with and with -release switch. Bye, bearophile
Mar 28 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/28/11 4:31 PM, bearophile wrote:
 Walter:

 There's a lot of money and manpower behind Python. If this were true, why
hasn't this technology been done for Python?<

It was done, more than one time. One good JIT was Psyco. And more recently PyPy is about to surpass Psyco in performance: http://codespeak.net/pypy/dist/pypy/doc/ But the Lua JIT is quite better than Psyco, its programmer is very intelligent (Psyco author too is an intelligent programmer, Armin Rigo). And more importantly, this whole discussion can't be reduced to just a static Vs dynamic typing.

To be brutally honest, I'd say that this discussion (and a few others) could be reduced to zero. We have a good list of things we know need to be done, all vying for top positions. We're gearing up for a GSoC 2011 program that will be, it seems, extremely rewarding but quite taxing for those of us who are overseeing the process. This is a good time to stay focused and productive. Discussions about some or another minutia or comparative merits and demerits of various approaches can quickly drown the good content. At best this newsgroup would contain a majority of GSoC proposals and related discussions, review discussions for the currently proposed modules, preliminary design discussions on emerging libraries, progress reports, and the such. Thanks, Andrei
Mar 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 To be brutally honest, I'd say that this discussion (and a few others) 
 could be reduced to zero.

I have suggested the Google Summer of Code for D even the past year, and I agree it's important for D future. But I think Walter has to know something about modern JITs & dynamic languages too. I have had bad experiences with Guido (Python author) that until no more than one or two years ago seemed to didn't even know what a trampoline stub is, and this has caused some problems. You have to take care of the knowledge of your Benevolent Dictator For Life, I want Walter to know lot of things. Bye, bearophile
Mar 28 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/28/11 5:47 PM, bearophile wrote:
 Andrei:

 To be brutally honest, I'd say that this discussion (and a few
 others) could be reduced to zero.

I have suggested the Google Summer of Code for D even the past year, and I agree it's important for D future. But I think Walter has to know something about modern JITs& dynamic languages too. I have had bad experiences with Guido (Python author) that until no more than one or two years ago seemed to didn't even know what a trampoline stub is, and this has caused some problems. You have to take care of the knowledge of your Benevolent Dictator For Life, I want Walter to know lot of things. Bye, bearophile

Teaching van Rossum or Bright is a bit assuming. I suggest a simpler path - apply the noble goal of knowing a lot of things to yourself, and use that expertise to contribute to the community. Thanks, Andrei
Mar 28 2011
parent reply jasonw <user webmails.org> writes:
Andrei Alexandrescu Wrote:

 On 3/28/11 5:47 PM, bearophile wrote:
 Andrei:

 To be brutally honest, I'd say that this discussion (and a few
 others) could be reduced to zero.

I have suggested the Google Summer of Code for D even the past year, and I agree it's important for D future. But I think Walter has to know something about modern JITs& dynamic languages too. I have had bad experiences with Guido (Python author) that until no more than one or two years ago seemed to didn't even know what a trampoline stub is, and this has caused some problems. You have to take care of the knowledge of your Benevolent Dictator For Life, I want Walter to know lot of things. Bye, bearophile

Teaching van Rossum or Bright is a bit assuming. I suggest a simpler path - apply the noble goal of knowing a lot of things to yourself, and use that expertise to contribute to the community.

I've managed to keep my mouth shut about non-technical issues until earlier today. But since I already started, I'd like to stay as constructive as possible and suggest finding some kind of unified guidelines for technical discussion. The reason for this is, I find bearophile's tone a bit annoying more often than I'd want. This isn't a personal attack, I just wish that there was a better way for him to interact with the community. Bearophile's actions have already been criticized several times in the past, but he doesn't seem to respond in any way. <tasteless>I can't keep wondering if he has Asperger syndrome</tasteless>. I just want to bring up some remarks about improving the quality of posts and raising the S/N ratio. Thanks. Basically what bearophile discusses is: - feature proposals (sometimes useful, more often not) - bug reports and fixes - optimization tips - benchmark results - user experience reports - links to research papers - links to discussion boards (most often reddit) - "education" - uninformed and totally uncalled-for remarks about personal motives and other personal things How we could improve the process is that 1) We stop making "guesses" about the motivations and timetables of community members. 2) I also hate these "time ago i suggested this feature, and bla bla bla, see bugzilla # XXX". Bugs are being constantly fixed and this kind of advertisement of your bug reports doesn't help in any way. If you're such a rocket scientist, write some patches instead. 3) We should spent some time learning english and communicating the main idea with less words. Seriously, if you've been hitting the "post this!!" button for years, you should consider improving your grammar every now and then. Reading posts, spanning multiple pages, written in incomprehensible "semi-engrish" is really boring. I mostly react with "tl;dr". 4) Stop posting so many feature requests. They are often contradictory and just annoy the key persons. And finally a reply to the bearophile's:
  You have to take care of
 the knowledge of your Benevolent Dictator For Life, I want Walter to
 know lot of things.


Listen kid, you're some biology student, right? You're just coding for fun. And more importantly, you haven't participated in any long term real world systems programming projects. This kind of work experience doesn't give you the competence to evaluate the knowledge and work of people with tens of years of programming experience under their belt. You might be terribly smart, but you're missing the point. Can you see what we are building here? A whole language ecosystem. Andrei has done great work by attracting competent CS persons in to the community. The development is changing. We need to find important persons, organizations, solve project management issues and all kinds of non-technical stuff now. Some kid posting yet another daily feature proposal isn't helping us at all. It's distracting and just plain noise. Can you see this from our POV? I really hope this forum is getting moderation once the community grows large enough.
Mar 28 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 3/28/2011 9:54 PM, jasonw wrote:
 Listen kid, you're some biology student, right? You're just coding for fun.
And more importantly, you haven't participated in any long term real world
systems programming projects. This kind of work experience doesn't give you the
competence to evaluate the knowledge and work of people with tens of years of
programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see what we
are building here? A whole language ecosystem. Andrei has done great work by
attracting competent CS persons in to the community.

While I think some good points were raised here, I find the implication that biologists and generally non-CS people can't do first rate programming mildly offensive. Formal education in CS helps especially when doing CS research, but it's not a requirement for being a "real" programmer. I'm a biomedical engineering student and primarily write research and hobby code, not industrial code. Walter's degree is in mechanical engineering and he's one of the best programmers I can think of. Heck, even Andrei didn't have a formal degree in CS until recently. (His undergrad, IIRC, is in electrical engineering.) That said, I think bearophile's posts are well-intentioned. The problem is that the signal-to-noise is terrible. What D needs now is bug fixing of what's already there and solid implementations of basic stuff like database APIs, better garbage collection, IDEs, etc. Bringing up the latest cool idea is fine if you've also got an implementation or it's exceptionally well thought out and solves a severe, pressing problem. The constant bombardment with ideas to solve minor or niche problems, with no implementation and no intention of creating an implementation, is more distracting than useful.
Mar 28 2011
next sibling parent jasonw <user webmails.org> writes:
dsimcha Wrote:

 On 3/28/2011 9:54 PM, jasonw wrote:
 Listen kid, you're some biology student, right? You're just coding for fun.
And more importantly, you haven't participated in any long term real world
systems programming projects. This kind of work experience doesn't give you the
competence to evaluate the knowledge and work of people with tens of years of
programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see what we
are building here? A whole language ecosystem. Andrei has done great work by
attracting competent CS persons in to the community.

While I think some good points were raised here, I find the implication that biologists and generally non-CS people can't do first rate programming mildly offensive. Formal education in CS helps especially when doing CS research, but it's not a requirement for being a "real" programmer. I'm a biomedical engineering student and primarily write research and hobby code, not industrial code. Walter's degree is in mechanical engineering and he's one of the best programmers I can think of. Heck, even Andrei didn't have a formal degree in CS until recently. (His undergrad, IIRC, is in electrical engineering.)

Didn't want to give that kind of impression. I think "computer engineering" graduates often have a much better view of the software industry than pure computer science graduates. Non-CS people can also be great developers, no doubt. I wanted to point out that bearophile tries to act like a main architect of the D language. I'm overall impressed how well he handles the theoretical side, but the price is that the ideas are always presented like from an ivory tower. Concrete compiler / library patches and better relevance to real "simple" everyday problems would help a lot more. I'll mention one concrete example: typestates. While I think this idea is interesting, I really can't trust bearophile if I want to know if it's a good feature to have and testing it would require studying some small unpopular language (Rust). I don't think the main branch of D is a suitable target for experimenting with this kind of features. If he wants to use them, he could fork D and come back with concrete results.
 
 That said, I think bearophile's posts are well-intentioned.  The problem 
 is that the signal-to-noise is terrible.  What D needs now is bug fixing 
 of what's already there and solid implementations of basic stuff like 
 database APIs, better garbage collection, IDEs, etc.  Bringing up the 
 latest cool idea is fine if you've also got an implementation or it's 
 exceptionally well thought out and solves a severe, pressing problem. 
 The constant bombardment with ideas to solve minor or niche problems, 
 with no implementation and no intention of creating an implementation, 
 is more distracting than useful.

I fully agree with this, but just wanted to bring this up because in my opinion he is wasting a lot of time trying to emphasize things which have been noted, but are on the bottom of the current priority list. I don't want to discourage him from posting, but he should also consider the reactions of the audience a bit.
Mar 28 2011
prev sibling parent reply Don <nospam nospam.com> writes:
dsimcha wrote:
 On 3/28/2011 9:54 PM, jasonw wrote:
 Listen kid, you're some biology student, right? You're just coding for 
 fun. And more importantly, you haven't participated in any long term 
 real world systems programming projects. This kind of work experience 
 doesn't give you the competence to evaluate the knowledge and work of 
 people with tens of years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see 
 what we are building here? A whole language ecosystem. Andrei has done 
 great work by attracting competent CS persons in to the community.

While I think some good points were raised here, I find the implication that biologists and generally non-CS people can't do first rate programming mildly offensive. Formal education in CS helps especially when doing CS research, but it's not a requirement for being a "real" programmer. I'm a biomedical engineering student and primarily write research and hobby code, not industrial code. Walter's degree is in mechanical engineering and he's one of the best programmers I can think of. Heck, even Andrei didn't have a formal degree in CS until recently. (His undergrad, IIRC, is in electrical engineering.)

I have a physics degree, and have worked in solar photovoltaics for fifteen years.
Mar 28 2011
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article
 dsimcha wrote:
 On 3/28/2011 9:54 PM, jasonw wrote:
 Listen kid, you're some biology student, right? You're just coding for
 fun. And more importantly, you haven't participated in any long term
 real world systems programming projects. This kind of work experience
 doesn't give you the competence to evaluate the knowledge and work of
 people with tens of years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see
 what we are building here? A whole language ecosystem. Andrei has done
 great work by attracting competent CS persons in to the community.

While I think some good points were raised here, I find the implication that biologists and generally non-CS people can't do first rate programming mildly offensive. Formal education in CS helps especially when doing CS research, but it's not a requirement for being a "real" programmer. I'm a biomedical engineering student and primarily write research and hobby code, not industrial code. Walter's degree is in mechanical engineering and he's one of the best programmers I can think of. Heck, even Andrei didn't have a formal degree in CS until recently. (His undergrad, IIRC, is in electrical engineering.)

fifteen years.

I'd have put you in my original post, too if I had known more detail about your background. Generally I think having non-CS people heavily involved in D's design helps immensely rather than hurting. CS people are great when you need something with strong theoretical underpinnings, but some things require a different, more real-world implementation and use case oriented mindset. I'm not saying CS people **can't** think this way, just that it's not the primary way they're **trained** to think. Having people with natural science and engineering backgrounds involved prevents D from becoming too ivory-tower. I also think it's a positive feedback loop: D refuses to compromise practicality to satisfy the Higher Principles of Computer Science, thus it attracts scientists and engineers who are more interested in practicality than the Higher Principles of Computer Science. Ironically, this branch started with a discussion about Bearophile's posts and despite his biology background I find most of them too ivory-tower.
Mar 29 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/29/11 4:37 PM, so wrote:
[snip]
 I find his posts among the most informative.

I don't meant to offend anyone here but I think it's worth making a point for your benefit and others'. If you are interested in programming language theory, probably there are better sources of information to use. Though I don't consider myself anywhere near an expert, my masters thesis was on programming language theory, which gives me some amount of perspective. "Cargo culture" would be a gross exaggeration, but much of the knowledge disseminated by bearophile is superficially absorbed literature that is served back semi-digested along with a hodge-podge of personal opinions of various degrees of correctness. The only reason I felt compelled to make this point is the (now obvious) risk in taking such posts as a good source of information. It is is dangerous to take non-critically the occasional enormity that sneaks in. That's why I suggested in the past and am suggesting it again - please don't feign expertise as some may actually fall for it. I have no doubt great personal improvement has been made in the past years, but the tone is still an octave above what it could be at its best. Thanks, Andrei
Mar 29 2011
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
On 3/29/2011 3:00 AM, Russel Winder wrote:
 Which leads to the real point as to why Python is becoming the leading
 language for scientific computing, it is a dynamic language for
 coordinating C/C++/Fortran computations and providing GUI front ends.
 Performance of Python is thus a side issue since grunt computation is
 done in languages which are closer to the machine -- with all the crap
 that entails.

The problem with this is when you're the poor bastard that has to write said C/C++/Fortran code, or when you want to pass complex object graphs between the languages.
Mar 29 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On Mar 29, 11 04:33, Walter Bright wrote:
 On 3/28/2011 1:12 PM, bearophile wrote:
 Walter:

 By fundamental technical issue, I mean things like Python's numeric
 types
 which require runtime testing for every operation, and are very
 resistant
 to known techniques of optimization.

Life is a bit more complex than that: - The Lua JIT has shown once and for all that dynamic typing is not as bad (performance-wise) as you think.

There's a lot of money and manpower behind Python. If this were true, why hasn't this technology been done for Python?

Psyco? (http://psyco.sourceforge.net/, though it seems to be stuck at 2.6) PyPy also supports JITting (http://codespeak.net/pypy/dist/pypy/doc/jit/index.html)
 Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in
 hybrid configurations with C and C++, so there is clearly some sort of
 deficit with Lua.

Mar 28 2011
prev sibling parent so <so so.so> writes:
On Wed, 30 Mar 2011 02:04:04 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 3/29/11 4:37 PM, so wrote:
 [snip]
 I find his posts among the most informative.

I don't meant to offend anyone here but I think it's worth making a point for your benefit and others'. If you are interested in programming language theory, probably there are better sources of information to use. Though I don't consider myself anywhere near an expert, my masters thesis was on programming language theory, which gives me some amount of perspective. "Cargo culture" would be a gross exaggeration, but much of the knowledge disseminated by bearophile is superficially absorbed literature that is served back semi-digested along with a hodge-podge of personal opinions of various degrees of correctness. The only reason I felt compelled to make this point is the (now obvious) risk in taking such posts as a good source of information. It is is dangerous to take non-critically the occasional enormity that sneaks in. That's why I suggested in the past and am suggesting it again - please don't feign expertise as some may actually fall for it. I have no doubt great personal improvement has been made in the past years, but the tone is still an octave above what it could be at its best. Thanks, Andrei

Probably i misused the word informative, what i meant was he occasionally brings up topics that i wasn't aware of and quite possibly i wouldn't even if i try to browse some PL related sites. They tend to be biased on certain languages and paradigms which leads to an hostility towards some ideas. I would be the last one on earth that would buy something because of a commercial, it is just a starting point.
Mar 29 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-26 22:03, Walter Bright wrote:
 I get told I'm wrong on just about everything I do.

No, you're wrong about that! ;) - Jonathan M Davis
Mar 26 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Mar 2011 21:54:27 -0400, jasonw <user webmails.org> wrote:

 <tasteless>I can't keep wondering if he has Asperger  
 syndrome</tasteless>.

I have no tolerance for this. I think the community shares this opinion. Please please, instead of tagging stuff like this, just remove it. Thanks -Steve
Mar 29 2011
prev sibling parent so <so so.so> writes:
 Listen kid, you're some biology student, right? You're just coding for  
 fun. And more importantly, you haven't participated in any long term  
 real world systems programming projects. This kind of work experience  
 doesn't give you the competence to evaluate the knowledge and work of  
 people with tens of years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see  
 what we are building here? A whole language ecosystem. Andrei has done  
 great work by attracting competent CS persons in to the community. The  
 development is changing. We need to find important persons,  
 organizations, solve project management issues and all kinds of  
 non-technical stuff now. Some kid posting yet another daily feature  
 proposal isn't helping us at all. It's distracting and just plain noise.  
 Can you see this from our POV? I really hope this forum is getting  
 moderation once the community grows large enough.

I find his posts among the most informative. As you also pointed out, he is doing a lot. Still, if one doesn't like it he can always ignore. On another note: I just hope this language never gets matured in the sense you are suggesting and the community improves it in every opportunity. To make this even more possible we need language features that ease (or make possible) the development of library solutions.
Mar 29 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
GCC 4.7 Stage 1 has begun.  Does anyone know if GDC is schedule for inclusion?
Mar 26 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
I've been doing a lot of coding in D in the past few weeks, and one
thing I've noticed is that performance is not great.  Surprisingly,
DMD generated binaries perform worse than GDC's, but even GDC is
lagging behind equivalent code written in C++ and compiled with G++.
Are we to expect performance to improve as more work is done on GDC?

Another thing that's bothering me is that there is currently only one
active developer working on GDC.
Mar 28 2011
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2011-03-28 at 17:31 -0400, bearophile wrote:
 Walter:
=20
There's a lot of money and manpower behind Python. If this were true,


It has been and is being. The problem is complicated by the GIL, so it is not a simple situation.
 It was done, more than one time. One good JIT was Psyco. And more
 recently PyPy is about to surpass Psyco in performance:
 http://codespeak.net/pypy/dist/pypy/doc/

And there was Unladen Swallow which was a Google funded project to add a JIT to CPython 2.6. It failed to meet it's goals. However the results will nonetheless filter into CPython 3.2 or 3.3.
 But the Lua JIT is quite better than Psyco, its programmer is very
 intelligent (Psyco author too is an intelligent programmer, Armin
 Rigo).

The Lua JIT can hardly be compared to something for Python since the underlying VMs are totally different -- as you point out below.. What can be said is that the Lua JIT works very well for Lua, whilst there is no production quality equivalent for Python as yet.=20
 And more importantly, this whole discussion can't be reduced to just a
 static Vs dynamic typing. Lua and Python are different languages,
 Python is probably more dynamic than Lua, it is quite more powerful
 than Lua, and it's different. So creating a really efficient JIT for
 Python is much harder than doing it for Lua, and you can't compare
 them much.

Indeed.
 The result is that currently PyPy is generally about 8/10 times slower
 than D code, while Lua-Jit is about 2-3 times slower than D compiled
 well, and JavaScript running on the V8-CrankShaft JIT is about 3-4
 times slower than D. And Mozilla hopes to someday beat V8, though a
 local static inferencer (probably to be seen in Firefox 5? See the
 "(TypeInference)" here, it's in development still:
 http://arewefastyet.com/?a=3Db&view=3Dregress ).

Sadly PyPy is still only implementing CPython 2.5 which is a significantly worse barrier than any speed issues.
 Lua is a quite simple language, there are some things you can't do
 well with it, so you need other languages. And even with a JIT Lua is
 often not as fast as good C code. I have never said that Lua+JIT is
 better than D, I am not much interested in Lua.

Which leads to the real point as to why Python is becoming the leading language for scientific computing, it is a dynamic language for coordinating C/C++/Fortran computations and providing GUI front ends. Performance of Python is thus a side issue since grunt computation is done in languages which are closer to the machine -- with all the crap that entails. I know, Python, and indeed Lua, are used for plugins to big C/C++ systems as well. Here is is to provide the dynamic partner to a static system. This exactly how Groovy works with Java. The nature of the modern world is a symbiosis of languages not trying to do everything with one. <...stuff on floating point representations elided...> --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Mar 29 2011
prev sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-03-29 at 05:41 +0800, KennyTM~ wrote:
[ . . . ]
 Psyco? (http://psyco.sourceforge.net/, though it seems to be stuck at 2.6=

If I remember correctly the author of Psyco explicitly stopped work on it exactly because he moved to doing the JIT for PyPy . . .=20
 PyPy also supports JITting=20
 (http://codespeak.net/pypy/dist/pypy/doc/jit/index.html)

. . . which has the problem of being Python 2.5 instead of Python 2.7 or 3.2 :-(( --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Mar 29 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/29/2011 07:47 AM, Don wrote:
 dsimcha wrote:
 On 3/28/2011 9:54 PM, jasonw wrote:
 Listen kid, you're some biology student, right? You're just coding for fun.
 And more importantly, you haven't participated in any long term real world
 systems programming projects. This kind of work experience doesn't give you
 the competence to evaluate the knowledge and work of people with tens of
 years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see what
 we are building here? A whole language ecosystem. Andrei has done great work
 by attracting competent CS persons in to the community.

While I think some good points were raised here, I find the implication that biologists and generally non-CS people can't do first rate programming mildly offensive. Formal education in CS helps especially when doing CS research, but it's not a requirement for being a "real" programmer. I'm a biomedical engineering student and primarily write research and hobby code, not industrial code. Walter's degree is in mechanical engineering and he's one of the best programmers I can think of. Heck, even Andrei didn't have a formal degree in CS until recently. (His undergrad, IIRC, is in electrical engineering.)

I have a physics degree, and have worked in solar photovoltaics for fifteen years.

I have a degree in "technical training" (dunno proper english term, if any), specialised in automation. Seems I'm the closer one to CS/programming here ;-) (while in a highly specialised area) But certainly one of the least competent in those fields :-( Learning every day, though. Denis -- _________________ vita es estrany spir.wikidot.com
Mar 29 2011