QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: JanDashFor the record, everybody is giving you pretty good advice. Time to decide, jump in the pool, and start swimming. Bon voyage.---------JanAnd the last mile is always the hardest!I find around the 2/3 mark the most difficult. By the time you're on the last mile, the end is in site!

In the big scheme of things, String Theory is a probably a lot more relevant than being able to produce lines of "elegant" C++ code..Some of you guys might be out of a job in the future as improvements to the OOP languages diminish the role of a skilled programmer!If only you'd spent five poverty stricken years, living off mars bars, wearing the same underpants for days on end in the quest for knowledge and academic fulfillment..Not sure Newton or Einstein would have bothered, but if want a job at IB, learn C++!RenTec's an interesting one - they don't want people with financial markets experience - though I suspect C++ is required in addition to String Theory (or Wavelets or Astronomy or Chern-Simons, or whatever they use..)

QuoteOriginally posted by: TraderJoeQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: JanDashFor the record, everybody is giving you pretty good advice. Time to decide, jump in the pool, and start swimming. Bon voyage.---------JanAnd the last mile is always the hardest!I find around the 2/3 mark the most difficult. By the time you're on the last mile, the end is in site!Depends how things are measured. But the agony is the same!

> Not sure Newton or Einstein would have bothered, but if want a job at IB, learn C++!Einstein worked in a Bank for a short time but that's before C++ existed (TJ, no bithcin' now )N, you were warrned, stay off the Singletons !

QuoteOriginally posted by: Cuchulainn> Not sure Newton or Einstein would have bothered, but if want a job at IB, learn C++!Einstein worked in a Bank for a short time but that's before C++ existed (TJ, no bithcin' now )He also worked in a Patent Office. He needed a relatively quiet place to develop his ideas whilst paying the rent.

I don't see advances in computer languages making skilled programmers less important. On the contrary, the trend seems to be in the other direction. Also, the stereotype of computational physics being somehow less mathematically rigorous or demanding than the analytic stuff doesn't make any sense from where I sit. Trying to writing down difference equations for say the general relativistic collapse of a neutron star or figuring out how to model radiation hydrodynamics (which often involves calculating scattering cross sections using quantum field theory and then integrating the Boltzman equation across available angles) isn't mathematically trivial. And then you have to worry about testing and debugging those ten thousand lines of code for a subtle bug that turns out to be due to the way that you've calculated the proton-neutrino inelastic scattering rate which is messed up because of a sign error in the equation of state (been there done, done that).

Sorry. I meant the proton-neutrino *elastic* scattering cross-section. Big difference.

QuoteOriginally posted by: twofishAlso, the stereotype of computational physics being somehow less mathematically rigorous or demanding than the analytic stuff doesn't make any sense from where I sit. Trying to writing down difference equations for say the general relativistic collapse of a neutron star or figuring out how to model radiation hydrodynamics (which often involves calculating scattering cross sections using quantum field theory and then integrating the Boltzman equation across available angles) isn't mathematically trivial. .I agree with you. For example, I did FEM for 5 years, both the foundations and applications to semiconductors and radiation problems in ray tubes and I needed almost everthing I learn in Undergrad school, Hlibert and Banach, Operator theory, Numerical analysis, Real and Complex analysis ..The useful thing about CFD engineering is that it teaches you to be practical and solve problems. Someone working on the Riemann Zeta function does not have this mindset per se.And last, you have to code for CFD using paper tape, punchcards or whatever. When you get out, you are ready for the big world.It's great producing a closed formula (that for the gurus like Scholes, Navier and Stokes). The rest of us must be content with following in their footsteps.My advice: Do maths AND program like hell in UNI! (unless you are Russel Crowe or N)I made the decision that I was an engineer and not an academic some time ago. You have to choose.2 cents

Not true. You can be an academic and a consultant.

QuoteOriginally posted by: twofishI don't see advances in computer languages making skilled programmers less important. On the contrary, the trend seems to be in the other direction. Isn't it the trend that programming languages over time are more closely reflecting the way we think about a problem, rather than trying to mold a problem into something familiar to the computer? To quote Eckel(p5 Using C++) "the goal is to have a one-to-one correspondence between entities in the physical problem and objects in the program". So eventually we reach a situation where skilled programmer = skilled problem solver = skilled mathematician. The guy with the String Theory PhD will be able to picking up "programming" in a week, raising the bar for what us humans are able to make the computer do. Today's skilled programmer will have to adapt or is eliminated from the picture..Put differently, 1)coming up with an algorithm is one thing, 2)getting the computer to perform the algorithm is another, and I'm wondering if 2) becomes a trivial matter, allowing all problem solvers (String Theorists included) to focus more effort on 1). The guy that is currently very skilled at 2) adds less value. Those that are skilled in 1) and 2) will of course stay in the picture.

::Isn't it the trend that programming languages over time are more closely reflecting the way we think about a problem, rather than trying to mold a problem into something familiar to the computer? We've already reached the point where the way that the programs are structured are not very closely connected with the underlying hardware. The trouble is that there are usually dozens of ways of breaking up a problem, and in the case of OOP, the main difficulty is less coding an algorithm, but rather structuring the code so that people will be able to extend, fix, combine with other modules after six or seven years. One problem with academic code is that it tends to be written by a small number of people and code maintainability, extensibility usually isn't taken into consideration. Just like there is no particular reason to think that a brilliant string theorist would make a good teacher of string theory or be able to write a coherent text book on string theory, there's no particular reason to assume that a brilliant theorist could write clear code that other people (including other string theorists) can extend and maintain. The main point of writing clear elegant code is not to try to explain yourself to the computer (since the compiler will take care of that) but rather to explain what you are trying to do clearly to the people who are going to have to debug, maintain, extend what you have written with a minimum of effort.

We've already reached the point where the way that the programs are structured are not very closely connected with the underlying hardware.Yes, at one level I agree.However a vast % of code is For.. loops which map directly to the hardware, and is very much of the form1: Get data2: Screw with it3: If it's nice stop else goto 14: Find some other bit of data5: screw with it in a similar way, but using different code6: find some way of nailing the two bits of data together7: give upThat's what 99% of general purpose CPUs think the world should work like.Things like threads and arrays are actually again direct mappings of processor concepts.Nearly all code on (say) matrices is actually written as For loops as well. Yeah I know we have higher level concepts, but look at the code people actually write.Pentium style CPUs can't do lazy evaluation without considerable poking, and as for parallel operations, dream on.The trouble is that there are usually dozens of ways of breaking up a problem, and in the case of OOP, the main difficulty is less coding an algorithm, but rather structuring the code so that people will be able to extend, fix, combine with other modules after six or seven years. One problem with academic code is that it tends to be written by a small number of people and code maintainability, extensibility usually isn't taken into consideration.The main point of writing clear elegant code is not to try to explain yourself to the computer (since the compiler will take care of that) but rather to explain what you are trying to do clearly to the people who are going to have to debug, maintain, extend what you have written with a minimum of effort.And of course "the people" in this context includes you 6 months from now.