www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - blog: Overlooked Essentials for Optimizing Code

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/
Sep 10 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


It turns out that dmd's runtime library function had a crummy implementation of
long division in it.<


In that case I have spent few hours narrowing the problem to a very small
benchmark. Then I have left to you to spot and fix the precise cause of the low
performance. And today I know x86 assembly a bit better :-)



 I know a person who has done it (looked at the JIT output) with Java using a
debugger,


I have done this often, many of my bug reports for LLVM compare the asm
produced by LLVM with the asm produced by the Sun JavaVM:
http://weblogs.java.net/blog/2008/03/30/deep-dive-assembly-code-java
See for example:
http://llvm.org/bugs/show_bug.cgi?id=5501

Bye,
bearophile
Sep 10 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 Walter Bright:
 

 It turns out that dmd's runtime library function had a crummy
 implementation of long division in it.<


 
 In that case I have spent few hours narrowing the problem to a very small
 benchmark. Then I have left to you to spot and fix the precise cause of the
 low performance. And today I know x86 assembly a bit better :-)


Please forgive me for ragging on about this, but you had originally concluded 
that it was the code generator's fault. My point is that drawing such a 
conclusion would lead one to spend many hours fruitlessly looking in the wrong 
place for a solution, and that looking at the assembler would quickly point one 
in the right direction to getting it fixed.

I wrote about this issue because I see it all the time, and by experienced 
programmers.



 I know a person who has done it (looked at the JIT output) with Java using
 a debugger,


 I have done this often, many of my bug reports for LLVM compare the asm
 produced by LLVM with the asm produced by the Sun JavaVM: 
 http://weblogs.java.net/blog/2008/03/30/deep-dive-assembly-code-java See for
 example: http://llvm.org/bugs/show_bug.cgi?id=5501


Very nice, you should post that on reddit!
Sep 10 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Please forgive me for ragging on about this, but you had originally concluded 
 that it was the code generator's fault.


I was wrong, of course. For me a compiler was a black box, I didn't understand
the difference between code generation and calling a built-in div function.
Thank you for listening to me, for fixing that performance problem, and for all
the answers you have given in the last years :-)

Bye,
bearophile
Sep 10 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 Walter Bright:

 Please forgive me for ragging on about this, but you had originally concluded 
 that it was the code generator's fault.


 
 I was wrong, of course.


I have a lot of respect for you for saying that.
Sep 10 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i6dsuc$2suf$1 digitalmars.com...

 http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/


"1. Using a profiler
2. Looking at the assembly code being executed"

Somehow I knew you were going to say that ;)
Sep 10 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 "1. Using a profiler
 2. Looking at the assembly code being executed"
 
 Somehow I knew you were going to say that ;)


What's interesting is how controversial this is. I've heard every reason in the 
book (and some very inventive ones) justifying not using a profiler or looking 
at the assembler.
Sep 10 2010
next sibling parent "JimBob" <jim bob.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i6e7tm$jj1$1 digitalmars.com...

 Nick Sabalausky wrote:

 "1. Using a profiler
 2. Looking at the assembly code being executed"

 Somehow I knew you were going to say that ;)


 What's interesting is how controversial this is. I've heard every reason 
 in the book (and some very inventive ones) justifying not using a profiler 
 or looking at the assembler.


You also need to understand things that can cause problems with asm. For 
example the Borland compiler used to and probably still does often copy 
doubles by using 2 32 bit moves. This means any time they are loaded into 
the fpu soon after a copy you'll get a store to load forwarding stall, which 
can be around 30 cycles penalty. As float/doubles are passed via the stack, 
this meant quite a performance hit for code that used doubles over code that 
used single precision or extended. (Extended was coppied via the FPU so it 
want a problem).
Sep 11 2010
prev sibling parent reply BCS <none anon.com> writes:
Hello Walter,


 Nick Sabalausky wrote:
 

 "1. Using a profiler
 2. Looking at the assembly code being executed"
 Somehow I knew you were going to say that ;)
 


 What's interesting is how controversial this is. I've heard every
 reason in the book (and some very inventive ones) justifying not using
 a profiler or looking at the assembler.
 


what would it take to add a built in ASM dump to DMD? Putting that in would 
remove the need for an external tool and might even allow more useful output 
like adding source line numbers as comments.

-- 
... <IXOYE><
Sep 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
BCS wrote:

 what would it take to add a built in ASM dump to DMD? Putting that in 
 would remove the need for an external tool and might even allow more 
 useful output like adding source line numbers as comments.



Compile with -g and obj2asm will add source lines as comments.
Sep 11 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:


 BCS wrote:

 what would it take to add a built in ASM dump to DMD? Putting that in
 would remove the need for an external tool and might even allow more
 useful output like adding source line numbers as comments.


 
 
 Compile with -g and obj2asm will add source lines as comments.


Is this also supported on linux? I can't get it to work.
Sep 11 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Lutger wrote:

 Walter Bright wrote:
 

 BCS wrote:

 what would it take to add a built in ASM dump to DMD? Putting that in
 would remove the need for an external tool and might even allow more
 useful output like adding source line numbers as comments.


 Compile with -g and obj2asm will add source lines as comments.


 
 Is this also supported on linux? I can't get it to work.


Unfortunately, no.
Sep 11 2010
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:


 Lutger wrote:

 Walter Bright wrote:
 

 BCS wrote:

 what would it take to add a built in ASM dump to DMD? Putting that in
 would remove the need for an external tool and might even allow more
 useful output like adding source line numbers as comments.


 Compile with -g and obj2asm will add source lines as comments.


 
 Is this also supported on linux? I can't get it to work.


 
 Unfortunately, no.


Ok, objdump looks promising instead. It can do something with the source:

objdump -d -l -S -Mintel stuff.o
Sep 11 2010
prev sibling parent BCS <none anon.com> writes:
Hello Walter,


 Lutger wrote:
 

 Walter Bright wrote:
 

 BCS wrote:
 

 what would it take to add a built in ASM dump to DMD? Putting that
 in would remove the need for an external tool and might even allow
 more useful output like adding source line numbers as comments.
 


 Compile with -g and obj2asm will add source lines as comments.
 


 Is this also supported on linux? I can't get it to work.
 


 Unfortunately, no.
 


Back to my origonal point, which was only a for example...

-- 
... <IXOYE><
Sep 11 2010
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Walter Bright Wrote:


 http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/


I don't like profilers, they slow the execution of my code by like a bagillian
times. Actually this article got me to try it again and is the first time I
noticed a difference.

You've always promoted the built in profiler in D so I tried it and nothing
changed (at least that would be what I thought), I'd never used a profiler
before so I didn't know how it should work.

Is there information on what the output of trace.log and trace.def mean? And I
guess I can run the demaingler against  this output, any tools already handle
this?

.def is listing functions for me, why? The log format seems to be

Section
    number      function      number number number
    ...
End/Begin Section

Is this like a standard profiler output format?
Sep 10 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Jesse Phillips schrieb:


 Is there information on what the output of trace.log and trace.def mean? And I
guess I can run the demaingler against  this output, any tools already handle
this?


Documentation of the profilers output would be helpful indeed.

That last table in trace.log is self-documenting and already contains 
the most important information: what function is executed how often, how 
much time does that take and how much of that time is used within that 
function itself ("Func Time") opposed to the time taken by functions 
called from that function ("Tree Time" - "Func Time")

Don't know about the rest of trace.log though - maybe it's "the fan in 
and fan out, which is essentially the call graph. From it, you can tell 
why and from where foo() is being called 1000 times when you only 
thought it should be called 3 times." (which a good profiler will tell 
you according to Walter on reddit[1])?

Also: The output would be much more readable if it was demangled.

A tool that parses trace.log and generates a nice (html?) representation 
of the data would be really cool :-)

Cheers,
- Daniel

[1] 
http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/c0z4yxu
Sep 11 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:i6fa0l$j7b$2 digitalmars.com...

 Jesse Phillips schrieb:


 Is there information on what the output of trace.log and trace.def mean? 
 And I guess I can run the demaingler against  this output, any tools 
 already handle this?


 Documentation of the profilers output would be helpful indeed.

 That last table in trace.log is self-documenting and already contains the 
 most important information: what function is executed how often, how much 
 time does that take and how much of that time is used within that function 
 itself ("Func Time") opposed to the time taken by functions called from 
 that function ("Tree Time" - "Func Time")

 Don't know about the rest of trace.log though - maybe it's "the fan in and 
 fan out, which is essentially the call graph. From it, you can tell why 
 and from where foo() is being called 1000 times when you only thought it 
 should be called 3 times." (which a good profiler will tell you according 
 to Walter on reddit[1])?

 Also: The output would be much more readable if it was demangled.

 A tool that parses trace.log and generates a nice (html?) representation 
 of the data would be really cool :-)


An interactively-inspectible one would be really great. (More work though, 
obviously.)
Sep 11 2010
parent Daniel Gibson <metalcaedes gmail.com> writes:
Nick Sabalausky schrieb:

 "Daniel Gibson" <metalcaedes gmail.com> wrote in message 
 news:i6fa0l$j7b$2 digitalmars.com...

 Jesse Phillips schrieb:


 Is there information on what the output of trace.log and trace.def mean? 
 And I guess I can run the demaingler against  this output, any tools 
 already handle this?


 Documentation of the profilers output would be helpful indeed.

 That last table in trace.log is self-documenting and already contains the 
 most important information: what function is executed how often, how much 
 time does that take and how much of that time is used within that function 
 itself ("Func Time") opposed to the time taken by functions called from 
 that function ("Tree Time" - "Func Time")

 Don't know about the rest of trace.log though - maybe it's "the fan in and 
 fan out, which is essentially the call graph. From it, you can tell why 
 and from where foo() is being called 1000 times when you only thought it 
 should be called 3 times." (which a good profiler will tell you according 
 to Walter on reddit[1])?

 Also: The output would be much more readable if it was demangled.

 A tool that parses trace.log and generates a nice (html?) representation 
 of the data would be really cool :-)


 
 An interactively-inspectible one would be really great. (More work though, 
 obviously.)
 


Via integration into an IDE maybe? That'd be cool - run the profiler and 
afterwards click on the function names in the representation to get to 
the functions and to the points they're called (from the fan in/out 
data) - maybe with annotations in/next to the source or something like that.

If any IDE dev reads this: Proper integration of the profiler would be a 
killer feature :-)
(But honestly I'd be thankful for any IDE with proper auto completion 
and maybe refactoring that works on Linux - the eclipse plugins don't 
seem to work for me, codeblocks neither..)
Sep 11 2010
prev sibling next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
DMD built in profiler don't work yet with multithreaded apps. Is there a plan
to change that or.. ?
Sep 10 2010
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Bane (branimir.milosavljevic gmail.com)'s article

 DMD built in profiler don't work yet with multithreaded apps. Is there a plan
to change that or.. ?


Yes.  It's on my "to do" list, but other things have had priority.
Sep 10 2010
parent reply Bane <branimir.milosavljevic gmail.com> writes:
Sean Kelly Wrote:


 == Quote from Bane (branimir.milosavljevic gmail.com)'s article

 DMD built in profiler don't work yet with multithreaded apps. Is there a plan
to change that or.. ?


 
 Yes.  It's on my "to do" list, but other things have had priority.


Thanks for reply. Can I help with something? I don't have mush experience with
that, though.
Sep 11 2010
parent reply Sean Kelly <sean invisibleduck.org> writes:
Bane Wrote:


 Sean Kelly Wrote:
 

 == Quote from Bane (branimir.milosavljevic gmail.com)'s article

 DMD built in profiler don't work yet with multithreaded apps. Is there a plan
to change that or.. ?


 
 Yes.  It's on my "to do" list, but other things have had priority.


 
 Thanks for reply. Can I help with something? I don't have mush experience with
that, though.


I tried a quick adaption a while back and failed... the code uses globals
directly within functions sometimes and not others, etc.  It's really going to
take a substantial rewrite to get things right.  The basic idea is that each
thread will keep its own data and merge it into a collective dataset on
termination.
Sep 11 2010
parent reply Bane <branimir.milosavljevic gmail.com> writes:
Sean Kelly Wrote:


 Bane Wrote:
 

 Sean Kelly Wrote:
 

 == Quote from Bane (branimir.milosavljevic gmail.com)'s article

 DMD built in profiler don't work yet with multithreaded apps. Is there a plan
to change that or.. ?


 
 Yes.  It's on my "to do" list, but other things have had priority.


 
 Thanks for reply. Can I help with something? I don't have mush experience with
that, though.


 
 I tried a quick adaption a while back and failed... the code uses globals
directly within functions sometimes and not others, etc.  It's really going to
take a substantial rewrite to get things right.  The basic idea is that each
thread will keep its own data and merge it into a collective dataset on
termination.


I'll dig the dmd code to see whats going on, but my love for c is bit rusty...
Thanx.
Sep 11 2010
parent Sean Kelly <sean invisibleduck.org> writes:
Bane Wrote:


 Sean Kelly Wrote:
 

 Bane Wrote:
 

 Sean Kelly Wrote:
 

 == Quote from Bane (branimir.milosavljevic gmail.com)'s article

 DMD built in profiler don't work yet with multithreaded apps. Is there a plan
to change that or.. ?


 
 Yes.  It's on my "to do" list, but other things have had priority.


 
 Thanks for reply. Can I help with something? I don't have mush experience with
that, though.


 
 I tried a quick adaption a while back and failed... the code uses globals
directly within functions sometimes and not others, etc.  It's really going to
take a substantial rewrite to get things right.  The basic idea is that each
thread will keep its own data and merge it into a collective dataset on
termination.


 
 I'll dig the dmd code to see whats going on, but my love for c is bit rusty...
Thanx.


The code is in druntime.  src/rt/trace.d, I believe.
Sep 11 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 10/09/2010 19:20, Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/


Generally, an interesting article. However, there are a few points I 
would like to counter:

"Nope, it isn't avoiding premature optimization. It isn't replacing 
bubble sort with quicksort (i.e. algorithmic improvements). It's not 
what language used, nor is it how good the compiler is. It isn't writing 
i<<2 instead of i*4.

It is:

    1. Using a profiler
    2. Looking at the assembly code being executed
"

There is a bit confusion here. The first things (use algorithmic 
improvements, a better language or compiler, "i << 2" code, etc.) are 
not of the same nature as the other things (1 & 2 - Using a profiler and 
looking at the assembly )
The first are techniques for optimizing particular code, and the second 
ones are strategies for figuring out *which* code is best to try to 
optimize. It does not make sense to try to oppose the two, because the 
second one actually requires the first one to be useful. I mean, no code 
has ever improved in performance *strictly just* by using a profiler or 
looking at the assembly code being executed. :)


But more importantly 1 and 2, (especially 1: "using a profiler") are 
crucial elements of "avoiding premature optimization". I mean, I learnt 
"avoid premature optimization" as being "don't optimize code until you 
*know* that code is a bottleneck", and in something like 80% of the 
books/articles/college-courses that taught about premature optimization, 
they also explicitly mentioned that running a profiler was by far the 
best way to determine which code is the bottleneck, and that the 
alternative of guessing is bad, because it is often wrong.



"Though that is undeniably true, there are two caveats that don't get 
taught in schools. First and most importantly, choosing the best 
algorithm for a part of the program that has no participation to the 
performance profile has a negative effect on optimization because it 
wastes your time that could be better invested in making actual 
progress, and diverts attention from the parts that matter."

I don't think its true that it "doesn't get taught in schools", at least 
in CS university degrees. In my degree this was explained in detail at 
least 2 core curricula courses, and a few more times in other non-core 
(optional/specialization) courses. Also, (like I mentioned above) the 
majority of other learning material (articles, books) that talk about 
optimization do mention the importance of profiling.

"Second, algorithms' performance always varies with the statistics of 
the data they operate on. Even bubble sort, the butt of all jokes, is 
still the best on almost-sorted data that has only a few unordered 
items. So worrying about using good algorithms without measuring where 
they matter is a waste of time - your's and computer's."

Also, the notion that an intrinsic part of algorithm design is to 
understand what kind of data you are going to work was also mentioned in 
one of the core curricula courses in my degree (although with less 
detail than with case 1, above).

I don't mean to offend anyone, but if you CS degree (at least for the 
last decade or so), doesn't teach about points 1 and 2 above as part of 
core curricula, then it's a pretty crappy CS degree. The same is 
probably also true for other related degrees (*-engineering, maths), at 
least with regards to point 1.

-- 
Bruno Medeiros - Software Engineer
Oct 20 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s

 Also, the notion that an intrinsic part of algorithm design is to
 understand what kind of data you are going to work was also mentioned in
 one of the core curricula courses in my degree (although with less
 detail than with case 1, above).
 I don't mean to offend anyone, but if you CS degree (at least for the
 last decade or so), doesn't teach about points 1 and 2 above as part of
 core curricula, then it's a pretty crappy CS degree. The same is
 probably also true for other related degrees (*-engineering, maths), at
 least with regards to point 1.


You have a point to some degree, but I've noticed two related themes from my
experience with my Ph.D. research and with the D community.  Both of these are
things Walter seems to understand and exploit exceptionally well.

1.  There's a big difference between "it was covered" and "most people actually
understood it".  Of course the first is a necessary condition for the second,
but
it's not a sufficient condition.  Of course any CS/software engineering program
worth its salt will recommend using a profiler, but the question is, does it
sink
in for most students or was it mentioned in maybe one lecture on a Friday
morning
when half the class was hung over and the other half was still sleeping?

2.  "It's been done before" is not a good reason not to do something if you're
going to up-level it.  If something's been done before at a proof-of-concept
level, it's often rewarding to tweak/improve it to the point where it's
practical.
 If it's practical, it's often rewarding to try to tweak/improve it so it's
usable
by mere mortals and is well integrated into whatever other stuff might be
related.
 If it's usable by mere mortals, it's often rewarding to figure out what
improvements need to be made to break barriers to widespread adoption.
Oct 20 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/10/2010 16:17, dsimcha wrote:

 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s

 Also, the notion that an intrinsic part of algorithm design is to
 understand what kind of data you are going to work was also mentioned in
 one of the core curricula courses in my degree (although with less
 detail than with case 1, above).
 I don't mean to offend anyone, but if you CS degree (at least for the
 last decade or so), doesn't teach about points 1 and 2 above as part of
 core curricula, then it's a pretty crappy CS degree. The same is
 probably also true for other related degrees (*-engineering, maths), at
 least with regards to point 1.


 You have a point to some degree, but I've noticed two related themes from my
 experience with my Ph.D. research and with the D community.  Both of these are
 things Walter seems to understand and exploit exceptionally well.

 1.  There's a big difference between "it was covered" and "most people actually
 understood it".  Of course the first is a necessary condition for the second,
but
 it's not a sufficient condition.  Of course any CS/software engineering program
 worth its salt will recommend using a profiler, but the question is, does it
sink
 in for most students or was it mentioned in maybe one lecture on a Friday
morning
 when half the class was hung over and the other half was still sleeping?


If a student is not paying attention, didn't go to class, or didn't 
study a topic, that's the student's fault and there is little that the 
university can (or even should) try to do change that. But that's 
besides the point. I wasn't arguing that a lot of students or 
professionals understand the issue around premature optimization and 
profilers. I was just arguing against "[it] doesn't get taught in 
schools". I do agree however, that a topic can be covered with varying 
degrees of detail and importance.

As for the premature-optimization/profiling, it was well covered in my 
degree. I clearly remember it being mentioned in the very first 
"Introduction to Programming" course (based on "Structure and 
Interpretation of Computer Programs", the MIT one), where the Paretto 
principle as applied to programs was explained (aka the 90/10 law). And 
the topic was again studied during the "Software Engineering" course, as 
part of the key larger topic of how best to manage/optimize the time of 
the programmers and team members in a real-world project. It was also 
mentioned (in the context of the Agile series) that even if you know for 
sure that the code you are writing is indeed part of the 10% bottleneck, 
you likely should not optimize it yet, as changing requirements may make 
that code not used anymore, or no longer part of the bottleneck.

As for the issue of the importance of analyzing the inputs of the 
algorithms, well, that one was also mentioned, but definitely not 
covered that well. It was mentioned in the context of hashing keys, but 
mostly only in passing, a lot of the nuances of the topic where not 
discussed. It was only recently that I learned more about this, as I 
watched the MIT OCW lectures of the "Introduction to Algorithms" course, 
as well as reading part of the respective book.
For example the issue of deterministic hashing vs. probabilistic 
hashing: if you have a deterministic hashing function which indeed does 
distribute your input keys well on the average case, that may actually 
not be good enough! Because if people have access to how your hashing 
function works, an adversary can force the worst case to happen! (random 
hashing is the solution to that) I guess that with the rise of the 
Internet, scenarios where this matters are more common.


 2.  "It's been done before" is not a good reason not to do something if you're
 going to up-level it.  If something's been done before at a proof-of-concept
 level, it's often rewarding to tweak/improve it to the point where it's
practical.
   If it's practical, it's often rewarding to try to tweak/improve it so it's
usable
 by mere mortals and is well integrated into whatever other stuff might be
related.
   If it's usable by mere mortals, it's often rewarding to figure out what
 improvements need to be made to break barriers to widespread adoption.


??
I have not idea what you mean by this...

-- 
Bruno Medeiros - Software Engineer
Oct 22 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote:


 I don't mean to offend anyone, but if you [sic] CS degree (at least
 for the last decade or so), doesn't teach about points 1 and 2 above as
 part of core curricula, then it's a pretty crappy CS degree. The same is
 probably also true for other related degrees (*-engineering, maths), at
 least with regards to point 1.


This reminds me of


 That is funny. Now and then you and Andrei talk so confidently about Go,

 couple of lines in those languages.


Walter also talks so confidently about CS degrees, without having earned 
one. The experiences probably stem from his caltech times with the smelly 
bearded hippie unix guys who wrote bubble sorts in some deprecated 
assembler dialect.

This is becoming a real problem. I gave an example of Scala fairly 
recently. I've given examples of code in other languages earlier. So has 
bearophile. I can't ever assume that you guys study these basics. The 
discussion stays at this level. It takes enormous amount of effort to 
teach simple concepts. How many knows now what a monad is? It was 
discussed again recently.
Oct 20 2010
next sibling parent reply so <so so.do> writes:
Every language has at least one niche (that it why they keep coming  
right?), but the pain is that there are tons of them. You are not  
expecting someone know all of them to the fullest right? If he tells you  
now that he knows all of it, next time you would say "There is this other  
language got one awesome feature called donuts! You don't know it, you  
suck!". Many people here do this pretty often.

He has every right to talk about languages IMO. You know he wrote  
compilers to hardest languages out there to implement. If he is wrong, it  
us up to you to prove him wrong, though not many times i have seen on this  
board that someone actually did it.

Sorry but it is ugly to see all these Walter bashings(not pointing you).
And he says/does nothing about it, it is hard not to respect his integrity.

On Wed, 20 Oct 2010 18:59:40 +0300, retard <re tard.com.invalid> wrote:


 Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote:


 I don't mean to offend anyone, but if you [sic] CS degree (at least
 for the last decade or so), doesn't teach about points 1 and 2 above as
 part of core curricula, then it's a pretty crappy CS degree. The same is
 probably also true for other related degrees (*-engineering, maths), at
 least with regards to point 1.


 This reminds me of


 That is funny. Now and then you and Andrei talk so confidently about Go,

 couple of lines in those languages.


 Walter also talks so confidently about CS degrees, without having earned
 one. The experiences probably stem from his caltech times with the smelly
 bearded hippie unix guys who wrote bubble sorts in some deprecated
 assembler dialect.

 This is becoming a real problem. I gave an example of Scala fairly
 recently. I've given examples of code in other languages earlier. So has
 bearophile. I can't ever assume that you guys study these basics. The
 discussion stays at this level. It takes enormous amount of effort to
 teach simple concepts. How many knows now what a monad is? It was
 discussed again recently.



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 20 2010
parent reply retard <re tard.com.invalid> writes:
Wed, 20 Oct 2010 19:25:04 +0300, so wrote:


 Every language has at least one niche (that it why they keep coming
 right?), but the pain is that there are tons of them. You are not
 expecting someone know all of them to the fullest right? If he tells you
 now that he knows all of it, next time you would say "There is this
 other language got one awesome feature called donuts! You don't know it,
 you suck!".


No, I don't expect that and I do believe in the law of diminishing 
returns. But some languages are part of the basic skillset of every 
modern developer. E.g. one mainstream statically typed app/systems 

(Bash/Python/Ruby/Perl/PHP/Javascript/Lua/...), one "pure" language (Lisp/
Scheme/ML/Haskell/Prolog/...). Am I wrong, you only need to know how to 
program in C/C++/Java/D and make/microemacs/.bat scripts?


 He has every right to talk about languages IMO. You know he wrote
 compilers to hardest languages out there to implement. If he is wrong,
 it us up to you to prove him wrong, though not many times i have seen on
 this board that someone actually did it.


I see your point, but

1) I didn't criticize his statements about languages in my post (Max 
Samukha mentioned it, I only pointed out the pattern)

2) I find it hard to believe he is qualified to criticize university 
degrees world wide. For instance Bruno probably comes from Europe (which 
is not a homogenic single country). Second, the quality of degrees and 
courses varies -- without active participation it's impossible to give 
accurate, objective statements about the educational system. In every 
place I've worked in the senior workers always mention how the young 
generations don't learn any useful stuff these days (polluting chainsaws 
instead of axes etc.). This is universal, it also happens outside 
software engineering. The rants of old men and women.


 
 Sorry but it is ugly to see all these Walter bashings(not pointing you).
 And he says/does nothing about it, it is hard not to respect his
 integrity.


I'm not bashing him. It shows amazing dedication to the subject when one 
changes the field after graduating. This isn't even a rarity because many 
of the modern subfields of computer engineering/science simply didn't 
exist back then. It's just that I expect developers / computer scientists 
to improve their knowledge base constantly. There are no signs of the 
field not evolving anymore.

Some things can be extrapolated from the evolution so far:

- compilers will catch more errors and produce faster code
- in popular languages the abstraction become higher and higher
- more languages will appear
- in 10 or 20 or 30 years most systems are multicore

Now, how can you know whether language X (e.g. Haskell) will be suitable 
in the future environment? How do you know which languages are worth 
studying if you don't get the basics of programming language theory? How 
can we expect one to *design* relevant new languages without these skills?


 
 On Wed, 20 Oct 2010 18:59:40 +0300, retard <re tard.com.invalid> wrote:
 

 Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote:


 I don't mean to offend anyone, but if you [sic] CS degree (at least
 for the last decade or so), doesn't teach about points 1 and 2 above
 as part of core curricula, then it's a pretty crappy CS degree. The
 same is probably also true for other related degrees (*-engineering,
 maths), at least with regards to point 1.


 This reminds me of


 That is funny. Now and then you and Andrei talk so confidently about

 than a couple of lines in those languages.


 Walter also talks so confidently about CS degrees, without having
 earned one. The experiences probably stem from his caltech times with
 the smelly bearded hippie unix guys who wrote bubble sorts in some
 deprecated assembler dialect.

 This is becoming a real problem. I gave an example of Scala fairly
 recently. I've given examples of code in other languages earlier. So
 has bearophile. I can't ever assume that you guys study these basics.
 The discussion stays at this level. It takes enormous amount of effort
 to teach simple concepts. How many knows now what a monad is? It was
 discussed again recently.
Oct 20 2010
parent so <so so.do> writes:
 No, I don't expect that and I do believe in the law of diminishing
 returns. But some languages are part of the basic skillset of every
 modern developer. E.g. one mainstream statically typed app/systems

 language
 (Bash/Python/Ruby/Perl/PHP/Javascript/Lua/...), one "pure" language  
 (Lisp/
 Scheme/ML/Haskell/Prolog/...). Am I wrong, you only need to know how to
 program in C/C++/Java/D and make/microemacs/.bat scripts?


Of course, at least some degree of knowledge in these 3 areas is a big  
plus.


 2) I find it hard to believe he is qualified to criticize university
 degrees world wide. For instance Bruno probably comes from Europe (which
 is not a homogenic single country). Second, the quality of degrees and
 courses varies -- without active participation it's impossible to give
 accurate, objective statements about the educational system. In every
 place I've worked in the senior workers always mention how the young
 generations don't learn any useful stuff these days (polluting chainsaws
 instead of axes etc.). This is universal, it also happens outside
 software engineering. The rants of old men and women.


You are giving too much value to universities/schools, just 3-5 years and  
they take much more than they give.
Graduating is not the end, it is a start.
Well... this is my experience. :)


 Some things can be extrapolated from the evolution so far:

 - compilers will catch more errors and produce faster code
 - in popular languages the abstraction become higher and higher
 - more languages will appear
 - in 10 or 20 or 30 years most systems are multicore

 Now, how can you know whether language X (e.g. Haskell) will be suitable
 in the future environment? How do you know which languages are worth
 studying if you don't get the basics of programming language theory? How
 can we expect one to *design* relevant new languages without these  
 skills?


I got no idea what is going to happen one year later in this retard (not  
you :P ) world really.
In this world you can hit jackpot with :

- a search engine.
- a web page you can post videos where you can get racist comments for  
anything you post.
- a web page you can post links, add names to your "friend" list.
- a web page you can post links/chat faster/cuter.

And people would think these are grand ideas.
A world, where using internet/coding make you nerd/antisocial but  
using/connecting these 4 make you social.

.... anyways!

A language should be there to solve problems i got right now, it might be  
obsolete the next day, who knows.

*cheers

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 20 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/20/10 10:59 CDT, retard wrote:

 Wed, 20 Oct 2010 14:59:21 +0100, Bruno Medeiros wrote:


 I don't mean to offend anyone, but if you [sic] CS degree (at least
 for the last decade or so), doesn't teach about points 1 and 2 above as
 part of core curricula, then it's a pretty crappy CS degree. The same is
 probably also true for other related degrees (*-engineering, maths), at
 least with regards to point 1.


 This reminds me of


 That is funny. Now and then you and Andrei talk so confidently about Go,

 couple of lines in those languages.


 Walter also talks so confidently about CS degrees, without having earned
 one. The experiences probably stem from his caltech times with the smelly
 bearded hippie unix guys who wrote bubble sorts in some deprecated
 assembler dialect.

 This is becoming a real problem. I gave an example of Scala fairly
 recently. I've given examples of code in other languages earlier. So has
 bearophile. I can't ever assume that you guys study these basics. The
 discussion stays at this level. It takes enormous amount of effort to
 teach simple concepts. How many knows now what a monad is? It was
 discussed again recently.


I think you are making a good point, and that the best way to realize 
its potential is to contribute more concrete ideas and artifacts that 
can be integrated within D to the extent possible. It's one thing to 
discuss monads, it's another to demonstrate how threading a monad 
through a pure D function achieves something that couldn't have been 
achieved otherwise.

Andrei
Oct 20 2010
prev sibling next sibling parent so <so so.do> writes:
Actually if you reread his example on DMD runtime code, you'll see it  
happened!

On Wed, 20 Oct 2010 16:59:21 +0300, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:


 I mean, no code has ever improved in performance *strictly just* by  
 using a profiler or looking at the assembly code being executed. :)
Oct 20 2010
prev sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 20/10/10 2:59 PM, Bruno Medeiros wrote:

 I don't mean to offend anyone, but if you CS degree (at least for the
 last decade or so), doesn't teach about points 1 and 2 above as part of
 core curricula, then it's a pretty crappy CS degree. The same is
 probably also true for other related degrees (*-engineering, maths), at
 least with regards to point 1.


I don't really think of CS that way. To me, CS is to practical 
programming as pure math is to accounting, i.e. I don't think CS should 
be teaching about profiling because that's what software engineering is 
for. They are two different worlds in my opinion. If you wanted to get a 
practical programming education and you took CS then I think you took 
the wrong degree.
Oct 21 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:


 I don't really think of CS that way. To me, CS is to practical 
 programming as pure math is to accounting, i.e. I don't think CS should 
 be teaching about profiling because that's what software engineering is 
 for. They are two different worlds in my opinion. If you wanted to get a 
 practical programming education and you took CS then I think you took 
 the wrong degree.


I think CS must teach about profiling too, because even them will need to run
efficient code.

If you are right, then 95% of the people are today going to CS (in an
university where I keep myself around) are going to the wrong university. On
the other hand informatics engineering is quite different and it teaches many
things that are not fit, it's a very long course, very hard, so it's not the
right place for most students. So if you are right then there's a need for a
third intermediate degree, where most students will want to go, that teaches
both lot of good CS and real-world "software engineering" :-)

Bye,
bearophile
Oct 21 2010
prev sibling next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
On 10/21/2010 02:02, Peter Alexander wrote:

 I don't really think of CS that way. To me, CS is to practical
 programming as pure math is to accounting, i.e. I don't think CS should
 be teaching about profiling because that's what software engineering is
 for. They are two different worlds in my opinion. If you wanted to get a
 practical programming education and you took CS then I think you took
 the wrong degree.


There are fundamental skills that you will need if you spend any amount
of time programming, whether you are a CS student, a computational
scientist, or an actual programmer.  Profiling is one of these skills.


-- 
Rainer Deyke - rainerd eldwood.com
Oct 21 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/10/2010 09:02, Peter Alexander wrote:

 On 20/10/10 2:59 PM, Bruno Medeiros wrote:

 I don't mean to offend anyone, but if you CS degree (at least for the
 last decade or so), doesn't teach about points 1 and 2 above as part of
 core curricula, then it's a pretty crappy CS degree. The same is
 probably also true for other related degrees (*-engineering, maths), at
 least with regards to point 1.


 I don't really think of CS that way. To me, CS is to practical
 programming as pure math is to accounting, i.e. I don't think CS should
 be teaching about profiling because that's what software engineering is
 for. They are two different worlds in my opinion. If you wanted to get a
 practical programming education and you took CS then I think you took
 the wrong degree.


Well, you think wrongly. :)
If you look at the top universities worldwide, the majority of them have 
only one "computer programming" undergraduate degree. Sometimes it is 
called "Computer Science" (typical in the US), other times it is called 
"Computer Engineering", "Informatics Engineering", "Software 
Engineering", "Informatics Science" or something like that (typical in 
Europe), but despite the different names they are essentially the same: 
courses designed to _teach and educate future software engineers_. A 
good software engineer will need a lot of the basis of CS and maths. 
Also those courses are nonetheless perfectly fine for someone who wishes 
to study CS on an academical level (ie, research). It does not make 
sense to have a separate undergraduate degree (other than the CS degree 
or the Math degree), and in some cases it also does not make sense to 
have a separate graduate degree (MSc.).


-- 
Bruno Medeiros - Software Engineer
Oct 22 2010
parent reply "Diego Cano Lagneaux" <d.cano.lagneaux gmail.com> writes:
 Well, you think wrongly. :)
 If you look at the top universities worldwide, the majority of them ha=


ve  =


 only one "computer programming" undergraduate degree. Sometimes it is =


 =


 called "Computer Science" (typical in the US), other times it is calle=


d  =


 "Computer Engineering", "Informatics Engineering", "Software  =



 Engineering", "Informatics Science" or something like that (typical in=


  =


 Europe), but despite the different names they are essentially the same=


:  =


 courses designed to _teach and educate future software engineers_.


I must nuance: as an European* "Informatics (and Applied Maths**)  =

engineer", I can say this degree is not 'Software engineer' but indeed  =

'whole computer engineer' as we studied both software and hardware, to t=
he  =

point of building a complete (simulated) processor.
Furthermore, I can't recall they told us about profiling tools, but it w=
as  =

10 years ago and I skiped a few classes, so it means nothing.

* I studied in France, which has the weirdest way of educating engineers=
:  =

2 years in a 'pr=C3=A9pa' or 'preparation school for the Engineering Sch=
ools  =

entry exams', then 2 years of actual degree, and finally a postgraduate =
 =

year *before graduating*. I say this to note that, although we were taug=
ht  =

a lot of engineering ways, and we covered a wide range of topics, and it=
  =

is oficially a 5 years degree, we did not have a lot of actual software =
 =

courses time so some of it could be a bit shallow. However, my Uni was  =

considered at the time the 2nd best of its field in France at the time, =
 =

and France is renowned for its engineers in Europe.

** Don't ask, it was the name of the degree. And it had indeed a lot of =
 =

math (~30%).
-- =

Usando el nov=C3=ADsimo cliente de correo de Opera: http://www.opera.com=
/mail/
Oct 22 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 22/10/2010 15:56, Diego Cano Lagneaux wrote:

 Well, you think wrongly. :)
 If you look at the top universities worldwide, the majority of them
 have only one "computer programming" undergraduate degree. Sometimes
 it is called "Computer Science" (typical in the US), other times it is
 called "Computer Engineering", "Informatics Engineering", "Software
 Engineering", "Informatics Science" or something like that (typical in
 Europe), but despite the different names they are essentially the
 same: courses designed to _teach and educate future software engineers_.


 I must nuance: as an European* "Informatics (and Applied Maths**)
 engineer", I can say this degree is not 'Software engineer' but indeed
 'whole computer engineer' as we studied both software and hardware, to
 the point of building a complete (simulated) processor.
 Furthermore, I can't recall they told us about profiling tools, but it
 was 10 years ago and I skiped a few classes, so it means nothing.


Which degree did 'Software engineers' take then?

-- 
Bruno Medeiros - Software Engineer
Oct 25 2010
next sibling parent reply "Diego Cano Lagneaux" <d.cano.lagneaux gmail.com> writes:
En Mon, 25 Oct 2010 13:22:02 +0200, Bruno Medeiros  =

<brunodomedeiros+spam com.gmail> escribi=C3=B3:


 On 22/10/2010 15:56, Diego Cano Lagneaux wrote:

 Well, you think wrongly. :)
 If you look at the top universities worldwide, the majority of them
 have only one "computer programming" undergraduate degree. Sometimes=







 it is called "Computer Science" (typical in the US), other times it =






is

 called "Computer Engineering", "Informatics Engineering", "Software
 Engineering", "Informatics Science" or something like that (typical =






in

 Europe), but despite the different names they are essentially the
 same: courses designed to _teach and educate future software  =







 engineers_.


 I must nuance: as an European* "Informatics (and Applied Maths**)
 engineer", I can say this degree is not 'Software engineer' but indee=




d

 'whole computer engineer' as we studied both software and hardware, t=




o

 the point of building a complete (simulated) processor.
 Furthermore, I can't recall they told us about profiling tools, but i=




t

 was 10 years ago and I skiped a few classes, so it means nothing.


 Which degree did 'Software engineers' take then?


Well, depends of what you mean by "Software engineer". They could take a=
 3  =

years 'informatics' degree, which is not an engineering degree (even if =
 =

it's called 'technical engineering in Spain) but is perfect for coders, =
or  =

take the full 'informatics engineering' and just specialize later (or  =

forget everything they don't need), for a more general and advanced degr=
ee.
In most Europe, Engineering is always a 5 years (masters) degree, orient=
ed  =

to big project developers who'll (supposedly) lead teams. I've heard it'=
s  =

different in the Anglosaxon systems.
Oct 25 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 25/10/2010 23:09, Diego Cano Lagneaux wrote:

 En Mon, 25 Oct 2010 13:22:02 +0200, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> escribió:


 On 22/10/2010 15:56, Diego Cano Lagneaux wrote:

 Well, you think wrongly. :)
 If you look at the top universities worldwide, the majority of them
 have only one "computer programming" undergraduate degree. Sometimes
 it is called "Computer Science" (typical in the US), other times it is
 called "Computer Engineering", "Informatics Engineering", "Software
 Engineering", "Informatics Science" or something like that (typical in
 Europe), but despite the different names they are essentially the
 same: courses designed to _teach and educate future software
 engineers_.


 I must nuance: as an European* "Informatics (and Applied Maths**)
 engineer", I can say this degree is not 'Software engineer' but indeed
 'whole computer engineer' as we studied both software and hardware, to
 the point of building a complete (simulated) processor.
 Furthermore, I can't recall they told us about profiling tools, but it
 was 10 years ago and I skiped a few classes, so it means nothing.


 Which degree did 'Software engineers' take then?


 Well, depends of what you mean by "Software engineer". They could take a
 3 years 'informatics' degree, which is not an engineering degree (even
 if it's called 'technical engineering in Spain) but is perfect for
 coders, or take the full 'informatics engineering' and just specialize
 later (or forget everything they don't need), for a more general and
 advanced degree.


Yeah, I meant the longer, more comprehensive degree (which like you said 
is usually 5 years long in continental Europe).

But yeah, you are right, these courses are not just for software 
engineers, but also other related areas (computer/hardware engineering, 
IT/systems administration, MIS). That was the case in my university, one 
would specialize in one of these areas in the last 2 years (of the 5 
year degree program).



 In most Europe, Engineering is always a 5 years (masters) degree,
 oriented to big project developers who'll (supposedly) lead teams. I've
 heard it's different in the Anglosaxon systems.


Whoa! :o
Shit, I'm going to go on a big tangent here, but I'm very surprised to 
again hear that notion that the 5 year CS/Engineering degrees in Europe 
are for "big project developers who'll (supposedly) lead teams.".
In my university (which, btw, is widely regarded as the best 
technical/engineering school in Portugal), that idea was often mentioned 
by some of the "senior" students in my degree. The details of their 
opinions varied, but generally some of them seemed to think that our 
graduates would soon become project managers and/or software architects 
in the workforce, whereas most of the programming and grunt work would 
be left to the "trolhas": the lowly developers who took the subprime 3 
year "practical" courses in other universities/polytechnics. ("Trolha" 
is Portuguese slang for a bricklayer, or also any guy who does 
construction work... see the metaphor here?)

Obviously I found this whole idea to be complete nonsense. Not that I 
didn't agree that the CS/E graduates from our degree were much better 
(on average) than the graduates from those 3 or 4 year CS/E courses, but 
rather the stupid notion that it would be perfectly fine (and ideal) for 
a software team to have one or two good software engineers as project 
leaders/managers/architects, and the rest to be "code monkeys"... These 
seniors students were completely blind to the importance of having the 
majority of your developers be good, smart developers (even if junior ones).
One or two of such seniors even went so far as to comment that 
programming itself was a lowly task, for "trolhas" only... we the 
Engineers might program in the first 2-3 years after entering the 
workplace, but we would gradually move to a architure/design role in 
enterprise and soon would not need program anymore... [end of quote, and 
you could feel in these comments how much this guy really disliked 
programming... ]
Man, my eyes went cartoonishly wide open when I read this. How 
incredibly deluded this guy was... :S

But the whole surprising thing is, I wasn't expecting this kind of 
attitude in other countries, I thought this was somewhat isolated in 
Portugal... a mix of personal delusion (derived from the fact that 
actually these guys sucked at programming, or anything else useful), 
combined with a still lingering non-meritocratic class arrogance in 
Portuguese society. Nobility may be long gone, but there are a lot of 
people in Portugal who like to put themselves about other people, and 
having a degree (especially with title-conferring degrees, which 
engineering degrees are btw) is a very common excuse for people trying 
to make themselves look superior, (even if their degree was crappy, or 
they sucked at it).


-- 
Bruno Medeiros - Software Engineer
Nov 01 2010
next sibling parent reply "Diego Cano Lagneaux" <d.cano.lagneaux gmail.com> writes:
 In most Europe, Engineering is always a 5 years (masters) degree,
 oriented to big project developers who'll (supposedly) lead teams. I've
 heard it's different in the Anglosaxon systems.


 Whoa! :o
 Shit, I'm going to go on a big tangent here, but I'm very surprised to  
 again hear that notion that the 5 year CS/Engineering degrees in Europe  
 are for "big project developers who'll (supposedly) lead teams.".
 In my university (which, btw, is widely regarded as the best  
 technical/engineering school in Portugal), that idea was often mentioned  
 by some of the "senior" students in my degree. The details of their  
 opinions varied, but generally some of them seemed to think that our  
 graduates would soon become project managers and/or software architects  
 in the workforce, whereas most of the programming and grunt work would  
 be left to the "trolhas": the lowly developers who took the subprime 3  
 year "practical" courses in other universities/polytechnics. ("Trolha"  
 is Portuguese slang for a bricklayer, or also any guy who does  
 construction work... see the metaphor here?)

 Obviously I found this whole idea to be complete nonsense. Not that I  
 didn't agree that the CS/E graduates from our degree were much better  
 (on average) than the graduates from those 3 or 4 year CS/E courses, but  
 rather the stupid notion that it would be perfectly fine (and ideal) for  
 a software team to have one or two good software engineers as project  
 leaders/managers/architects, and the rest to be "code monkeys"... These  
 seniors students were completely blind to the importance of having the  
 majority of your developers be good, smart developers (even if junior  
 ones).
 One or two of such seniors even went so far as to comment that  
 programming itself was a lowly task, for "trolhas" only... we the  
 Engineers might program in the first 2-3 years after entering the  
 workplace, but we would gradually move to a architure/design role in  
 enterprise and soon would not need program anymore... [end of quote, and  
 you could feel in these comments how much this guy really disliked  
 programming... ]
 Man, my eyes went cartoonishly wide open when I read this. How  
 incredibly deluded this guy was... :S

 But the whole surprising thing is, I wasn't expecting this kind of  
 attitude in other countries, I thought this was somewhat isolated in  
 Portugal... a mix of personal delusion (derived from the fact that  
 actually these guys sucked at programming, or anything else useful),  
 combined with a still lingering non-meritocratic class arrogance in  
 Portuguese society. Nobility may be long gone, but there are a lot of  
 people in Portugal who like to put themselves about other people, and  
 having a degree (especially with title-conferring degrees, which  
 engineering degrees are btw) is a very common excuse for people trying  
 to make themselves look superior, (even if their degree was crappy, or  
 they sucked at it).


Well, I am not sure you got what I meant. What I said is not that  
engineers will never code or won't have to after a couple years. The idea  
is more that engineers will be able to have people with different skills  
to manage, or to work closely with, so they'll have to know many fields to  
understand the whole thing. And I was not talking specifically about  
computers, but about all kinds of engineering. Engineering is about  
understanding and developping projects as a whole, which doesn't exclude  
working also on the details.
Of course, many engineers may end doing different things, which is another  
advantage of the generalist approach. I'm actually doing websites now!
Nov 01 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 01/11/2010 22:58, Diego Cano Lagneaux wrote:

 In most Europe, Engineering is always a 5 years (masters) degree,
 oriented to big project developers who'll (supposedly) lead teams. I've
 heard it's different in the Anglosaxon systems.


 Whoa! :o
 Shit, I'm going to go on a big tangent here, but I'm very surprised to
 again hear that notion that the 5 year CS/Engineering degrees in
 Europe are for "big project developers who'll (supposedly) lead teams.".
 In my university (which, btw, is widely regarded as the best
 technical/engineering school in Portugal), that idea was often
 mentioned by some of the "senior" students in my degree. The details
 of their opinions varied, but generally some of them seemed to think
 that our graduates would soon become project managers and/or software
 architects in the workforce, whereas most of the programming and grunt
 work would be left to the "trolhas": the lowly developers who took the
 subprime 3 year "practical" courses in other
 universities/polytechnics. ("Trolha" is Portuguese slang for a
 bricklayer, or also any guy who does construction work... see the
 metaphor here?)

 Obviously I found this whole idea to be complete nonsense. Not that I
 didn't agree that the CS/E graduates from our degree were much better
 (on average) than the graduates from those 3 or 4 year CS/E courses,
 but rather the stupid notion that it would be perfectly fine (and
 ideal) for a software team to have one or two good software engineers
 as project leaders/managers/architects, and the rest to be "code
 monkeys"... These seniors students were completely blind to the
 importance of having the majority of your developers be good, smart
 developers (even if junior ones).
 One or two of such seniors even went so far as to comment that
 programming itself was a lowly task, for "trolhas" only... we the
 Engineers might program in the first 2-3 years after entering the
 workplace, but we would gradually move to a architure/design role in
 enterprise and soon would not need program anymore... [end of quote,
 and you could feel in these comments how much this guy really disliked
 programming... ]
 Man, my eyes went cartoonishly wide open when I read this. How
 incredibly deluded this guy was... :S

 But the whole surprising thing is, I wasn't expecting this kind of
 attitude in other countries, I thought this was somewhat isolated in
 Portugal... a mix of personal delusion (derived from the fact that
 actually these guys sucked at programming, or anything else useful),
 combined with a still lingering non-meritocratic class arrogance in
 Portuguese society. Nobility may be long gone, but there are a lot of
 people in Portugal who like to put themselves about other people, and
 having a degree (especially with title-conferring degrees, which
 engineering degrees are btw) is a very common excuse for people trying
 to make themselves look superior, (even if their degree was crappy, or
 they sucked at it).


 Well, I am not sure you got what I meant. What I said is not that
 engineers will never code or won't have to after a couple years. The
 idea is more that engineers will be able to have people with different
 skills to manage, or to work closely with, so they'll have to know many
 fields to understand the whole thing. And I was not talking specifically
 about computers, but about all kinds of engineering. Engineering is
 about understanding and developping projects as a whole, which doesn't
 exclude working also on the details.
 Of course, many engineers may end doing different things, which is
 another advantage of the generalist approach. I'm actually doing
 websites now!


Yeah, I wasn't accusing you of sharing that viewpoint, at least not in 
the same way that those students I mentioned in my post.

But you do agree that in the case of Software Engineers at least, you 
will lead a big project only after you have several years of experience 
(more or less depending on how big the project is), and even so, only if 
you are skilled enough? But more importantly, you don't need to lead 
over anyone to be a Software Engineer, even a good one.
In other words, it's not very analogous to say, civil engineering.


-- 
Bruno Medeiros - Software Engineer
Nov 09 2010
parent reply "Diego Cano Lagneaux" <d.cano.lagneaux gmail.com> writes:
 [ ... ]


 Well, I am not sure you got what I meant. What I said is not that
 engineers will never code or won't have to after a couple years. The
 idea is more that engineers will be able to have people with different
 skills to manage, or to work closely with, so they'll have to know many
 fields to understand the whole thing. And I was not talking specifically
 about computers, but about all kinds of engineering. Engineering is
 about understanding and developping projects as a whole, which doesn't
 exclude working also on the details.
 Of course, many engineers may end doing different things, which is
 another advantage of the generalist approach. I'm actually doing
 websites now!


 Yeah, I wasn't accusing you of sharing that viewpoint, at least not in  
 the same way that those students I mentioned in my post.

 But you do agree that in the case of Software Engineers at least, you  
 will lead a big project only after you have several years of experience  
 (more or less depending on how big the project is), and even so, only if  
 you are skilled enough? But more importantly, you don't need to lead  
 over anyone to be a Software Engineer, even a good one.
 In other words, it's not very analogous to say, civil engineering.


Well, I think a simple look at the real world is enough to agree that you  
need several years of experience and good skills. Moreover, my personal  
experience is that it's easier to get a job (and therefore the much needed  
working experience) when you have a 3-year degree than a 5-year one, at  
least in Spain: I've been told at many job interviews that I was  
'overqualified' (I didn't care about that, just wanted to work, but they  
did)
However, I still think all engineerings* are conceptually the same: you  
need all qualifications for large projects (which doesn't exclude smaller  
ones) in your field; given enough time, you have to be able to do  
everything. Of course, for anything larger than quite small, you'll need a  
team. It's just that Civil Engineering usually deals with large projects,  
and most Software projects are smaller.
I insist: this is conceptually. Real world is most Computer Engineers  
never get to do engineering work, and almost all spend their first years  
not being engineers.

*To me, engineering is the process of creating mechanisms, from  
planification to physical result.
Nov 11 2010
parent reply ruben niemann <replies here.zzz> writes:
Diego Cano Lagneaux Wrote:


 Well, I think a simple look at the real world is enough to agree that you  
 need several years of experience and good skills. Moreover, my personal  
 experience is that it's easier to get a job (and therefore the much needed  
 working experience) when you have a 3-year degree than a 5-year one, at  
 least in Spain: I've been told at many job interviews that I was  
 'overqualified' (I didn't care about that, just wanted to work, but they  
 did)


Same happened to me. I've MSc in computer engineering from a technical
university. I began my PhD studies (pattern recognition and computer vision),
but put those on hold after the first year because it seemed there isn't much
non-academic work on that field and because of other more urgent issues. Four
years after getting my MSc I'm still writing user interface html / css /
javascript / php in a small enterprise. Hoping to see D or some strongly typed
language in use soon. I'm one of the techies running the infrastructure, I
should have studied marketing / management if I wanted to go up in the
organization and earn more.


 *To me, engineering is the process of creating mechanisms, from  
 planification to physical result.


That's my view of the engineering, too.
Nov 11 2010
parent reply lurker <lurk lurking.net> writes:
ruben niemann Wrote:


 Diego Cano Lagneaux Wrote:
 

 Well, I think a simple look at the real world is enough to agree that you  
 need several years of experience and good skills. Moreover, my personal  
 experience is that it's easier to get a job (and therefore the much needed  
 working experience) when you have a 3-year degree than a 5-year one, at  
 least in Spain: I've been told at many job interviews that I was  
 'overqualified' (I didn't care about that, just wanted to work, but they  
 did)


 
 Same happened to me. I've MSc in computer engineering from a technical
university. I began my PhD studies (pattern recognition and computer vision),
but put those on hold after the first year because it seemed there isn't much
non-academic work on that field and because of other more urgent issues. Four
years after getting my MSc I'm still writing user interface html / css /
javascript / php in a small enterprise. Hoping to see D or some strongly typed
language in use soon. I'm one of the techies running the infrastructure, I
should have studied marketing / management if I wanted to go up in the
organization and earn more.


It's usually your own fault if you don't get promotions. My career started with
WAP/XHTML/CSS, J2EE, Tapestry, Struts, then Stripes, Spring, Hibernate, jQuery,
and few others. Due to my lack of small talk social skills, I was frist moved
from client interface and trendy things to the backend coding and testing,
later began doing sysadmin work at the same company. My working area is in the
basement floor near a tightly locked and cooled hall full of servers. It's
pretty cold here, I rarely see people (too lazy to climb upstairs to fetch a
cup of coffee so I brought my own espresso coffee maker here) and when I do,
they're angry because some <foobar> doesn't work again.
Nov 11 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/11/2010 11:50, lurker wrote:

 ruben niemann Wrote:


 Diego Cano Lagneaux Wrote:


 Well, I think a simple look at the real world is enough to agree that you
 need several years of experience and good skills. Moreover, my personal
 experience is that it's easier to get a job (and therefore the much needed
 working experience) when you have a 3-year degree than a 5-year one, at
 least in Spain: I've been told at many job interviews that I was
 'overqualified' (I didn't care about that, just wanted to work, but they
 did)


 Same happened to me. I've MSc in computer engineering from a technical
university. I began my PhD studies (pattern recognition and computer vision),
but put those on hold after the first year because it seemed there isn't much
non-academic work on that field and because of other more urgent issues. Four
years after getting my MSc I'm still writing user interface html / css /
javascript / php in a small enterprise. Hoping to see D or some strongly typed
language in use soon. I'm one of the techies running the infrastructure, I
should have studied marketing / management if I wanted to go up in the
organization and earn more.


 It's usually your own fault if you don't get promotions. My career started
with WAP/XHTML/CSS, J2EE, Tapestry, Struts, then Stripes, Spring, Hibernate,
jQuery, and few others. Due to my lack of small talk social skills, I was frist
moved from client interface and trendy things to the backend coding and
testing, later began doing sysadmin work at the same company. My working area
is in the basement floor near a tightly locked and cooled hall full of servers.
It's pretty cold here, I rarely see people (too lazy to climb upstairs to fetch
a cup of coffee so I brought my own espresso coffee maker here) and when I do,
they're angry because some<foobar>  doesn't work again.


So "lurker" is actually also your job description? :P

-- 
Bruno Medeiros - Software Engineer
Nov 17 2010
prev sibling parent Roman Ivanov <isroman.DEL ETE.km.ru> writes:
On 11/1/2010 11:44 AM, Bruno Medeiros wrote:

 But the whole surprising thing is, I wasn't expecting this kind of
 attitude in other countries, I thought this was somewhat isolated in
 Portugal... 


Nope, unfortunately it's pretty universal. I know very well what you're
speaking about, even though I've never been to Portugal.
Nov 02 2010
prev sibling parent reply BCS <anon anon.com> writes:
Hello Bruno,


 Which degree did 'Software engineers' take then?
 


You know, that's one thing that kinda irks me: Why is it called 'Software 
engineers' when I've never seen engineering taught in a CS course (not to 
be confused with real "computer engineering" courses that are a lot more 
like EE than CS). The most direct example of this I know of is in "The
Pragmatic 
Programmer": Item 18 is "estimate to avoid surprises" and then goes on to 
describe how to do that. Well, if programming were taught as an engineering 
discipline, that would be a pointless (if not insulting) comment because 
what it is advocating is so fundamental to engineering that it goes without 
saying.
Oct 30 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 31/10/2010 05:35, BCS wrote:

 Hello Bruno,


 Which degree did 'Software engineers' take then?


 You know, that's one thing that kinda irks me: Why is it called
 'Software engineers' when I've never seen engineering taught in a CS
 course (not to be confused with real "computer engineering" courses that
 are a lot more like EE than CS).


What are you referring to when you say "called 'Software engineers'" ? 
The people who write software, or the college degrees/programs? I didn't 
quite get it.


The most direct example of this I know
 of is in "The Pragmatic Programmer": Item 18 is "estimate to avoid
 surprises" and then goes on to describe how to do that. Well, if
 programming were taught as an engineering discipline, that would be a
 pointless (if not insulting) comment because what it is advocating is so
 fundamental to engineering that it goes without saying.


What do you mean "if programming were taught as an engineering discipline" ?

-- 
Bruno Medeiros - Software Engineer
Nov 01 2010
parent reply BCS <anon anon.com> writes:
Hello Bruno,


 On 31/10/2010 05:35, BCS wrote:
 

 Hello Bruno,
 

 Which degree did 'Software engineers' take then?
 


 You know, that's one thing that kinda irks me: Why is it called
 'Software engineers' when I've never seen engineering taught in a CS
 course (not to be confused with real "computer engineering" courses
 that are a lot more like EE than CS).
 


 What are you referring to when you say "called 'Software engineers'" ?
 The people who write software, or the college degrees/programs? I
 didn't quite get it.
 


I've never seen the details of a software engineering program so I can't 
say much on that, but my current job title is software engineer and I know 
*I'm* not doing engineering.


 The most direct example of this I know
 of is in "The Pragmatic Programmer": Item 18 is "estimate to avoid
 surprises" and then goes on to describe how to do that. Well, if
 programming were taught as an engineering discipline, that would be a
 pointless (if not insulting) comment because what it is advocating is
 so
 fundamental to engineering that it goes without saying.


 What do you mean "if programming were taught as an engineering
 discipline" ?


I'm saying that programming is *not* taught or practiced as an engineering 
discipline (Ok, maybe the DOD, DOE and NASA do). Furthermore, I'm presenting 
the fact that "item 18" needs stating as evidence supported to support my 
assertion and supporting that with the assertion that any practitioner of 
an engineering discipline wouldn't need to be told about "item 18".

To be totally clear, I'm not saying that software development should be done 
as an engineering process, but that the standard practices (and job title) 
of today shouldn't claim to be engineering.
Nov 01 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 02/11/2010 04:25, BCS wrote:

 Hello Bruno,


 On 31/10/2010 05:35, BCS wrote:


 Hello Bruno,


 Which degree did 'Software engineers' take then?


 You know, that's one thing that kinda irks me: Why is it called
 'Software engineers' when I've never seen engineering taught in a CS
 course (not to be confused with real "computer engineering" courses
 that are a lot more like EE than CS).


 What are you referring to when you say "called 'Software engineers'" ?
 The people who write software, or the college degrees/programs? I
 didn't quite get it.


 I've never seen the details of a software engineering program so I can't
 say much on that, but my current job title is software engineer and I
 know *I'm* not doing engineering.


I don't think you understood my question. You said "Why is it called 
'Software engineers'", and I was asking what you meant by "it". Were you 
referring to the people, or to the degrees?


 The most direct example of this I know
 of is in "The Pragmatic Programmer": Item 18 is "estimate to avoid
 surprises" and then goes on to describe how to do that. Well, if
 programming were taught as an engineering discipline, that would be a
 pointless (if not insulting) comment because what it is advocating is
 so
 fundamental to engineering that it goes without saying.


 What do you mean "if programming were taught as an engineering
 discipline" ?


 I'm saying that programming is *not* taught or practiced as an
 engineering discipline (Ok, maybe the DOD, DOE and NASA do).
 Furthermore, I'm presenting the fact that "item 18" needs stating as
 evidence supported to support my assertion and supporting that with the
 assertion that any practitioner of an engineering discipline wouldn't
 need to be told about "item 18".


Ehh? "needs stating as evidence supported to support my assertion and 
supporting that with the assertion that" ??


 To be totally clear, I'm not saying that software development should be
 done as an engineering process, but that the standard practices (and job
 title) of today shouldn't claim to be engineering.


What is engineering to you then?


-- 
Bruno Medeiros - Software Engineer
Nov 09 2010