|
Considering that the large majority of people programming today don't deal with infinitesimals, differential equations, video/audio compression (or encryption), floating point matrix operations...all of it the stuff of simulators and videogames...it doesn't surprise me.
Maybe you could get away with building a kernel and a compiler if you knew just algebra and had a hankering for Chomsky.
|
|
|
|
|
Even without the actual math, there's definitely common concepts that apply, so I would say if you have the mindset that can handle calculus, then you might find yourself having an easier time than someone who's never done any of it.
YMMV and it depends on your career path.
|
|
|
|
|
Greetings,
When I started out, I was going to be an engineer (Civil or EE - wasn't sure). Took Fortran (yes that long ago) as my first programming language. 4th Semester Calculus was my downfall with 49% as my final grade. I then switch to MIS and finished my degree in that. Additional math courses were non-existent except for Statistics. I managed a 91% average in those 3 courses. The Calculus courses were interesting and I used them at one clients location. However as a rule, wasn't needed. Critical Thinking? yes! Logic? Yes! Calculus? Not really...
Conceptualize multi-dimensional array? Yes! Slide Rule? Fun but not really needed...
Math does help but Calculus doesn't seem to be necessary,
Cegarman
document code? If it's not intuitive, you're in the wrong field 
Welcome to my Chaos and Confusion!
|
|
|
|
|
cegarman wrote: Math does help but Calculus doesn't seem to be necessary,
Right. My main point was that if you have the mindset that can cope with Calculus, you might have an easier time coming up with new ideas than someone who hasn't been exposed to Calculus at all.
That being said, I've been coding professionally for almost 30 years now, and in all that time I don't think I've ever written any math code that amount to anything more complex than calculating an average.
|
|
|
|
|
|
Allow me to quote Fred Brooks, in The Mythical Man-Month (1972)
He wrote: ... when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.
If you haven't already, get yourself a copy. Even 50 years later, that book is full of relevant stuff.
Also, remember that impregnating nine women will not produce a baby in one month. (Software is not quite the same as babies, but sometimes I wonder...)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
As I recall the discussion to which you refer is re/ projects in full progress and significantly advanced. The articles to which I refer are projects which are fully designed though yet to be implemented. Assuming the design of a software project is complete well documented and accepted it is not obvious to me why 100,000 programmers can not be hired to implement one of each of the 100,000 methods of the project and bingo presto voila the project is complete in no time at all and ready for integration test.
"We can't solve today's problems with the mentality that created them." Albert Einstein,
|
|
|
|
|
Let's say that is, in theory, possible.
The amount of time it would take to design and plan ahead would probably make it more efficient to hire less programmers and do less planning.
A railroad or building will have many knowns (because every railroad and building is essentially the same, if you're not doing crazy stuff) while software has a whole lot of unknowns.
So every method, method name, number and order of arguments, probably class names, etc. will have to be thought out in advance.
That's basically saying a few people will write the software up front and then we'll hire 100.000 programmers to fill in a few of the details.
So then, let's say you got to the point where 100.000 programmers can write 100.000 methods simultaneously (after probably years or planning and designing).
Those methods are probably going to call one another, but that's not possible because those methods are still being written!
But let's say you get around that by using a dynamic language like JavaScript or Python.
Now you can't test them because each of the 100.000 programmers will have to get the spelling, casing, order of arguments, etc. correct right from the get go without being able to see, verify or test if the other programmer has, indeed, followed the design to the letter (here you can see why designing to that level would be ridiculous).
But let's say these programmers even got that right and they're going to commit their code...
Imagine the merge conflicts! 
Unless, of course, each method has a seperate file, but then that would have to be designed to and those files would somehow need to come together.
All in all, it's not very practical and would take so much time and effort and be so error prone that it's, for all practical reasons, not possible.
|
|
|
|
|
Sander Rossel wrote: order of arguments
Like one of my pet peeves about .net:
public ArgumentException (string? message, string? paramName);
public ArgumentNullException (string? paramName, string? message);
public ArgumentOutOfRangeException (string? paramName, string? message);
In my opinion, ArgumentException has the parameters in the correct order.
|
|
|
|
|
It looked strange to me at first, but I think I get it.
With the ArgumentException it's not clear what is wrong with the argument, so you must specify a message for further details.
In that case the paramName is secundary because it could also be hard coded in the message or the error could relate to multiple parameters.
With the Null and OutOfRange exceptions the error is clear even without a message and a default message would suffice, so you'd rarely specify a message.
What's more important is what parameter the error refers to.
Hence the "switch" in parameter order.
|
|
|
|
|
Okay, so lets say that there is an average of 100 lines of code per method. So 100,000 methods means the project has 10,000,000 lines of code in it. At the accepted rate of 1 defect per 1,000 lines of code, one would expect roughly 10,000 defects to be present in the code base. That is one hell of an integration test to complete.
Physical projects, building things, has safety cushions built into the engineering plans. Software does not have the same cushion to fall back on. You can make a girder with 10% additional material to make up for defects in the material or stress estimates. You can not add 10% additional code to a software module to make up for defects in the code or algorithm. You only add more defects.
It seems that software development leans towards smaller, highly integrated teams with smaller goals and continuous development, integration and testing. (IMHO)
|
|
|
|
|
BernardIE5317 wrote: it is not obvious to me why 100,000 programmers can not be hired to implement one of each of the 100,000 methods of the project
Because software engineering is not a task like making toast or painting fences. (With no offense to makers of toast and painters of fences.)
Methods aren't worked on in isolation. While a 100K engineers could write a 100K methods in a few minutes, they can't design a 100K methods in a few minutes.
/ravi
|
|
|
|
|
Peter_in_2780 wrote: Software is not quite the same as babies
The difference is that software ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) s you back.
Software Zen: delete this;
|
|
|
|
|
And babies piss or poops on you...   
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: babies piss or poops on you...
You telling me software doesn't?
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Peter_in_2780 wrote: If you haven't already, get yourself a copy. Even 50 years later, that book is full of relevant stuff.
Indeed. A true software classic. Plan to throw one away; you will, anyway.
|
|
|
|
|
Greg Utas quoted Fred Brooks: Plan to throw one away; you will, anyway.
In a similar vein, the common saying
Think, Think, Think! really means
discard your first thought, consider the second, and act on the third.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I read that before I got my first defacto project management position (senior dev, but we didn't have a PM per se) and it stuck with me.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
lot of things were planned and prepared for some time.
At some point it's just integration.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
BernardIE5317 wrote: builder puts up 57-story skyscraper in 19 days
Give them a change request to add an additional basement floor to that skyscraper.
Yet, that's what we sometimes do in software, isn't it? Causing the recent BSOD outage.
|
|
|
|
|
In short, no.
What was built is not what you would call a full hospital. It's more a stripped-down "hospital" with well understood modules that could be mass-produced and assembled like Lego.
The same with a railroad, where everything is a known, small, and easily assembled.
The skyscraper was the same way. A simple skyscraper, with nearly every floor the same, easily mass-produced, brought to the site and stacked. Is it up to the standards that we would use? No.
Seriously, have you seen some of the software that comes out of China? China doesn't build software like they build those buildings.
|
|
|
|
|
Dave Kreskowiak wrote: China doesn't build software like they build those buildings.
Maybe they need construction cheerleaders?
|
|
|
|
|
Espressif (a fabless semiconductor company out of China) makes decent software for their MCU products. The ESP-IDF for the most part is well thought out, and easier to code against than many other embedded software frameworks.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
All these examples show building speed, not design speed. No one said how long it took to design the skyscraper, the railroad or the hospital. In our field, writing a program is making a design not a product; the build phase is up to a compiler/linker and those have tremendous speed and are incredibly cheap. Let's not compare apples and oranges.
Mircea
|
|
|
|
|
You beat me to it. If there was a blueprint that was 100% thorough, already done and thought out, etc. then in theory that could happen. But, software dev is never like that. People want change and customization when they hire custom dev work... otherwise why hire devs. So, in reality that theory never holds up.
Jeremy Falcon
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
