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,

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 ;)
 

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.
 




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?

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,
 C#, Haskell and other D competitors, without having written more 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 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,
 C#, Haskell and other D competitors, without having written more 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.

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:
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,
 C#, Haskell and other D competitors, without having written more 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.

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
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 next sibling parent 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 language (C/C++/D/C#/Java/Ada/Object Pascal/Scala), one scripting 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?
 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
 Go, C#, Haskell and other D competitors, without having written more
 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
prev sibling next sibling 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 (C/C++/D/C#/Java/Ada/Object Pascal/Scala), one scripting  
 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 next 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 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 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?
 

'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 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?

'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 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
prev sibling 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?

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 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 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 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 next sibling parent "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=

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

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

 "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
prev sibling next sibling parent "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 =



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



 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=


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


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


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

Which degree did 'Software engineers' take then?

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
prev sibling next sibling parent "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
prev sibling parent "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