<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: The programmers of tomorrow</title>
	<atom:link href="http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/</link>
	<description>Programming, Algorithms, and Mathematics</description>
	<pubDate>Sat, 04 Jul 2009 15:57:42 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: jff</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-812</link>
		<dc:creator>jff</dc:creator>
		<pubDate>Sun, 02 Mar 2008 23:34:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-812</guid>
		<description>Dear Mark,

thanks for your comment. I have some comments and questions, too.

"I graduated 1972, EE. I observed that the best mathematicians made the worst programmers. Proof rendering skills seem to be quite different from software analysis and design skills, plus the attention to detail necessary to write clean code."

I believe that the standard proof skills are not the most convenient for programmers. In fact, my PhD thesis is on proof skills for computer scientists; I'm working in principles and foundations of (calculational) algorithmic problem solving. My work is essentially a contribution for what Tony Hoare started and Edsger Dijkstra (and others) continued: exploring the mathematical aspect of programming and deriving programs from their formal specification.

"Beyond that, testing skills necessary to ensure the design meets a proven algorithm or process is yet another skill to see beyond using expected data sets or inputs, to inputs that no one in their right mind would try."

Unless you test all the possible inputs against all possible outputs, you can't ensure that the algorithm meets its specification. Remember that testing can prove the presence of bugs, but never their absence!

"Thinking styles: There was a wonderful quote in the beginning of the Pascal manual that also espoused the concept that the tools you use shape the way you think about a thing."

Tools and languages change the way you think about problems. That is why some people prefer first-year students that never had any contact with programming.

"It has also been interesting to watch designs switch between centralized to decentralized and back, over the decades."

With computers going minuscule and ubiquitous, I don't believe that distributed designs will go back to centralized!

Joao</description>
		<content:encoded><![CDATA[<p>Dear Mark,</p>
<p>thanks for your comment. I have some comments and questions, too.</p>
<p>&#8220;I graduated 1972, EE. I observed that the best mathematicians made the worst programmers. Proof rendering skills seem to be quite different from software analysis and design skills, plus the attention to detail necessary to write clean code.&#8221;</p>
<p>I believe that the standard proof skills are not the most convenient for programmers. In fact, my PhD thesis is on proof skills for computer scientists; I&#8217;m working in principles and foundations of (calculational) algorithmic problem solving. My work is essentially a contribution for what Tony Hoare started and Edsger Dijkstra (and others) continued: exploring the mathematical aspect of programming and deriving programs from their formal specification.</p>
<p>&#8220;Beyond that, testing skills necessary to ensure the design meets a proven algorithm or process is yet another skill to see beyond using expected data sets or inputs, to inputs that no one in their right mind would try.&#8221;</p>
<p>Unless you test all the possible inputs against all possible outputs, you can&#8217;t ensure that the algorithm meets its specification. Remember that testing can prove the presence of bugs, but never their absence!</p>
<p>&#8220;Thinking styles: There was a wonderful quote in the beginning of the Pascal manual that also espoused the concept that the tools you use shape the way you think about a thing.&#8221;</p>
<p>Tools and languages change the way you think about problems. That is why some people prefer first-year students that never had any contact with programming.</p>
<p>&#8220;It has also been interesting to watch designs switch between centralized to decentralized and back, over the decades.&#8221;</p>
<p>With computers going minuscule and ubiquitous, I don&#8217;t believe that distributed designs will go back to centralized!</p>
<p>Joao</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark A. Baldridge</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-807</link>
		<dc:creator>Mark A. Baldridge</dc:creator>
		<pubDate>Fri, 29 Feb 2008 17:17:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-807</guid>
		<description>I graduated 1972, EE. I observed that the best mathematicians made the worst programmers.  (Tools were a lot less sophistocate then.)  Proof rendering skills seem to be quite different from software analysis and design skills, plus the attention to detail necessary to write clean code.  Beyond that, testing skills necessary to ensure the design meets a proven algorithm or process is yet another skill to see beyond using expected data sets or inputs, to inputs that no one in their right mind would try.  I seem to be able to break anything.  Perhaps that is related to being new to a lot of things that I try, and supply the "stupid inputs" to things.
Recent graduates, even into the 1980s, have little skill in isolating performance issues.  I attribute this to no comprehension of what the code is asking the machine to do.  An assembler, for assembly language on an IBM 360, exposed me to cycle counting for each machine instruction.  Later, reading decompilations of high level code in FORTRAN, COBOL, and C, provided further insights to what we ask the machine to do.  A CS curriculum should include at least one assembler-level course.
Then, a course in approaches to performance profiling could also expose CS students to the inner workings of code.  Even Order constant, n log n, n squared, algorithms can have significantly different performance profiles due to implementation.  My continuing series "Travels with Mark" on IBM's DeveloperWorks web site demonstrates one implementation of black box performance testing.  The first one introduces a tool for profiling a database environment and some statistics behind the techniques.  Subsequent articles explore the performance of different aspects of the database and application design decisions in coding techniques.
This is all a level of implementation that most folk do not get an opportunity to explore in the working world.  I have enjoyed doing it, and having the opportunity to write about and share it.
Thinking styles:  There was a wonderful quote in the beginning of the Pascal manual that also espoused the concept that the tools you use shape the way you think about a thing.
It has also been interesting to watch designs switch between centralized to decentralized and back, over the decades.  Very little changes except the facade.  Bottlenecks move around through various hardware and system limitations.  It is always fun to watch faces when you express an idea, "That is not going to work unless you can solve problem X."  
I cheated, however.  I later acquired an MBA with a strong technical component, which included several courses in statistics taught by a PhD statistician with a number of practical years of experience in industry.  I took courses in undergrad statistics, but did not get a feeling for statistics until graduate school.  I sense that the graduate TA, Teaching Assistants, really did not have a fundamental understanding of the statistics - simply an ability to apply the equations and tables.  In the 1990s, after explaining the concept of degrees of freedom to my son taking a statistics course supports that suspicion.  "Oh, that makes sense.  Why didn't he just say that!"</description>
		<content:encoded><![CDATA[<p>I graduated 1972, EE. I observed that the best mathematicians made the worst programmers.  (Tools were a lot less sophistocate then.)  Proof rendering skills seem to be quite different from software analysis and design skills, plus the attention to detail necessary to write clean code.  Beyond that, testing skills necessary to ensure the design meets a proven algorithm or process is yet another skill to see beyond using expected data sets or inputs, to inputs that no one in their right mind would try.  I seem to be able to break anything.  Perhaps that is related to being new to a lot of things that I try, and supply the &#8220;stupid inputs&#8221; to things.<br />
Recent graduates, even into the 1980s, have little skill in isolating performance issues.  I attribute this to no comprehension of what the code is asking the machine to do.  An assembler, for assembly language on an IBM 360, exposed me to cycle counting for each machine instruction.  Later, reading decompilations of high level code in FORTRAN, COBOL, and C, provided further insights to what we ask the machine to do.  A CS curriculum should include at least one assembler-level course.<br />
Then, a course in approaches to performance profiling could also expose CS students to the inner workings of code.  Even Order constant, n log n, n squared, algorithms can have significantly different performance profiles due to implementation.  My continuing series &#8220;Travels with Mark&#8221; on IBM&#8217;s DeveloperWorks web site demonstrates one implementation of black box performance testing.  The first one introduces a tool for profiling a database environment and some statistics behind the techniques.  Subsequent articles explore the performance of different aspects of the database and application design decisions in coding techniques.<br />
This is all a level of implementation that most folk do not get an opportunity to explore in the working world.  I have enjoyed doing it, and having the opportunity to write about and share it.<br />
Thinking styles:  There was a wonderful quote in the beginning of the Pascal manual that also espoused the concept that the tools you use shape the way you think about a thing.<br />
It has also been interesting to watch designs switch between centralized to decentralized and back, over the decades.  Very little changes except the facade.  Bottlenecks move around through various hardware and system limitations.  It is always fun to watch faces when you express an idea, &#8220;That is not going to work unless you can solve problem X.&#8221;<br />
I cheated, however.  I later acquired an MBA with a strong technical component, which included several courses in statistics taught by a PhD statistician with a number of practical years of experience in industry.  I took courses in undergrad statistics, but did not get a feeling for statistics until graduate school.  I sense that the graduate TA, Teaching Assistants, really did not have a fundamental understanding of the statistics - simply an ability to apply the equations and tables.  In the 1990s, after explaining the concept of degrees of freedom to my son taking a statistics course supports that suspicion.  &#8220;Oh, that makes sense.  Why didn&#8217;t he just say that!&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jff</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-785</link>
		<dc:creator>jff</dc:creator>
		<pubDate>Fri, 22 Feb 2008 14:17:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-785</guid>
		<description>Dear Miguel,

I think it really depends on what you like to do. What I recommend is that, besides learning new technologies, you learn good theoretical foundations.

I think it also helps to read books like "The Pragmatic Programmer: From Journeyman to Master" or "Code Complete" to get some practical tips.

Other than that, remember that programming is about solving problems. And the more you solve, the better you get!</description>
		<content:encoded><![CDATA[<p>Dear Miguel,</p>
<p>I think it really depends on what you like to do. What I recommend is that, besides learning new technologies, you learn good theoretical foundations.</p>
<p>I think it also helps to read books like &#8220;The Pragmatic Programmer: From Journeyman to Master&#8221; or &#8220;Code Complete&#8221; to get some practical tips.</p>
<p>Other than that, remember that programming is about solving problems. And the more you solve, the better you get!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Miguel Ortiz</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-782</link>
		<dc:creator>Miguel Ortiz</dc:creator>
		<pubDate>Fri, 22 Feb 2008 05:19:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-782</guid>
		<description>I totally agree with everyone here.  But I have a question that can give me a straight answer. Maybe you can help me out.  I programmed in VB and SQL Server, for a couple of years.  Im now going back after 6 years of no programming expirience and would like to know should I learn C.  Using Windows or Linux, I want to be marketable, what route should I take?</description>
		<content:encoded><![CDATA[<p>I totally agree with everyone here.  But I have a question that can give me a straight answer. Maybe you can help me out.  I programmed in VB and SQL Server, for a couple of years.  Im now going back after 6 years of no programming expirience and would like to know should I learn C.  Using Windows or Linux, I want to be marketable, what route should I take?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Los programadores del mañana</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-693</link>
		<dc:creator>Los programadores del mañana</dc:creator>
		<pubDate>Fri, 01 Feb 2008 23:55:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-693</guid>
		<description>[...] poco lei una entrada de blog de un joven portugues por mi google [...]</description>
		<content:encoded><![CDATA[<p>[...] poco lei una entrada de blog de un joven portugues por mi google [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jff</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-669</link>
		<dc:creator>jff</dc:creator>
		<pubDate>Fri, 25 Jan 2008 10:53:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-669</guid>
		<description>Dear Michael,

thank you for your comment. 

You say that you have "never had to use any of the “mathy” classes [you’ve] used in school".

Have you ever been taught how to derive an algorithm? How to prove its correctness? If your answer is yes, then I wonder why you don't want to be sure about the programs you write.

Anyway, I understand your point of view and let me tell you that I don't construct or prove all the code I write. But I don't write code that will run in critical systems, either :)

All the best,
Joao</description>
		<content:encoded><![CDATA[<p>Dear Michael,</p>
<p>thank you for your comment. </p>
<p>You say that you have &#8220;never had to use any of the “mathy” classes [you’ve] used in school&#8221;.</p>
<p>Have you ever been taught how to derive an algorithm? How to prove its correctness? If your answer is yes, then I wonder why you don&#8217;t want to be sure about the programs you write.</p>
<p>Anyway, I understand your point of view and let me tell you that I don&#8217;t construct or prove all the code I write. But I don&#8217;t write code that will run in critical systems, either <img src='http://www.joaoff.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>All the best,<br />
Joao</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jff</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-668</link>
		<dc:creator>jff</dc:creator>
		<pubDate>Fri, 25 Jan 2008 10:43:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-668</guid>
		<description>Dear The_Tzar,

Thanks for your comment.

I suspect the problem is general all over Europe (with some exceptions, of course). We're also trying to change things in Portugal. In fact, I'm participating in an experience for testing some "new" methods on Portuguese secondary schools. Basically, the idea is to contrast a calculational and goal-directed approach with the traditional way of teaching mathematics.

Joao</description>
		<content:encoded><![CDATA[<p>Dear The_Tzar,</p>
<p>Thanks for your comment.</p>
<p>I suspect the problem is general all over Europe (with some exceptions, of course). We&#8217;re also trying to change things in Portugal. In fact, I&#8217;m participating in an experience for testing some &#8220;new&#8221; methods on Portuguese secondary schools. Basically, the idea is to contrast a calculational and goal-directed approach with the traditional way of teaching mathematics.</p>
<p>Joao</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Bushe</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-666</link>
		<dc:creator>Michael Bushe</dc:creator>
		<pubDate>Fri, 25 Jan 2008 02:54:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-666</guid>
		<description>The industry and society needs some people skilled in math and willing to develop great algorithms, or great graphics libraries, etc.  The greatest need is for people to understand the major concerns of software: software design, performance, security, etc.  Exposure to data structures and multiple types of languages are essential, but I've never had to use any of the "mathy" classes I've used in school.  Yes, if you want to write software for financial quants, you'll need it, but let the students who want to study those subject take advantage of them.  For most developers, they'll be useless.  I'm with  Joel - there's more of an art to good software.</description>
		<content:encoded><![CDATA[<p>The industry and society needs some people skilled in math and willing to develop great algorithms, or great graphics libraries, etc.  The greatest need is for people to understand the major concerns of software: software design, performance, security, etc.  Exposure to data structures and multiple types of languages are essential, but I&#8217;ve never had to use any of the &#8220;mathy&#8221; classes I&#8217;ve used in school.  Yes, if you want to write software for financial quants, you&#8217;ll need it, but let the students who want to study those subject take advantage of them.  For most developers, they&#8217;ll be useless.  I&#8217;m with  Joel - there&#8217;s more of an art to good software.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: the_Tzar</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-661</link>
		<dc:creator>the_Tzar</dc:creator>
		<pubDate>Thu, 24 Jan 2008 06:49:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-661</guid>
		<description>Add the Netherlands to your list. Recent investigation here showed that over half of the students here lack basic skills on math and language.
Schools focussed too much on getting the ones that fell behind back on the boat, that it missed out supporting and stimulating the ones with talent.
Schools are also being paid for getting students through their exams, but not so much on doing so with quality of these exams.
Also managers have taken over the schools. Teachers are not free to do their profession but have to commit to measurable, but not meaningfull, criteria.
Students even protested that they wanted more math!
Good thing though is that things are finally going to change. Hopefully these changes will get funds so they won't fail.</description>
		<content:encoded><![CDATA[<p>Add the Netherlands to your list. Recent investigation here showed that over half of the students here lack basic skills on math and language.<br />
Schools focussed too much on getting the ones that fell behind back on the boat, that it missed out supporting and stimulating the ones with talent.<br />
Schools are also being paid for getting students through their exams, but not so much on doing so with quality of these exams.<br />
Also managers have taken over the schools. Teachers are not free to do their profession but have to commit to measurable, but not meaningfull, criteria.<br />
Students even protested that they wanted more math!<br />
Good thing though is that things are finally going to change. Hopefully these changes will get funds so they won&#8217;t fail.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: woowwee</title>
		<link>http://www.joaoff.com/2008/01/22/the-programmers-of-tomorrow/#comment-657</link>
		<dc:creator>woowwee</dc:creator>
		<pubDate>Wed, 23 Jan 2008 22:00:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.joaoferreira.org/2008/01/22/the-programmers-of-tomorrow/#comment-657</guid>
		<description>god damn  this is the most intelligent BLOG article on the internet today...I totally concur 


Most CS people I know who call themselves programmers TODAY should be hit on the side of the head with a lead pipe</description>
		<content:encoded><![CDATA[<p>god damn  this is the most intelligent BLOG article on the internet today&#8230;I totally concur </p>
<p>Most CS people I know who call themselves programmers TODAY should be hit on the side of the head with a lead pipe</p>
]]></content:encoded>
	</item>
</channel>
</rss>
