General discussion

Locked

I Just Want to Program! Don't Make Me Learn Math!

By DanLM ·
http://www.oreillynet.com/onlamp/blog/2007/05/i_just_want_to_program_dont_ma.html

Now, I have just read this article on the Orielly web site. And I have to say, I disagree. And for several reasons.

As my post to the article states, in the business world Math is a requirement. Everything from knowing various accounting principles(its math) to being able to understand the equations of some statistical requirement(insurance). Continuing this further, when working for a workers compensation state agency. We calculated the amount we would pay on any medical procedures based on a percentage of Medicare with this figure being worked off the last years percentage if I remember correctly.

In my experience, if you could not understand various equations. You could not fulfill the requirements of the task. This does not take into account where a person may come out of school and go into various other programming backgrounds(science, graphical).

I don't understand how math should not be a requirement. A schools job is to broadly prepare you for as many possible work environment as possible. If they do not provide a math background to your education, they severely limit your possibilities in what backgrounds you may want to choose.

Edited to add: If you read any of georges columns, you will notice he does statistics constantly on the various hardware/software that he tests. I don't know how reliant it is anymore, but I use to read application dumps when being on call at 3am. Not being able to convert hex to decimal and vice versa would have been an issue. I have also seen db admins use math to find the position of a record within a database when their was integrity problems. How can a Computer science major not have a math background>

Dan

This conversation is currently closed to new comments.

473 total posts (Page 5 of 48)   Prev   03 | 04 | 05 | 06 | 07   Next
Thread display: Collapse - | Expand +

All Comments

Collapse -

resource allocation

by Absolutely In reply to That's an interesting sup ...

Writing an app well means considering the resources available to it, and using them wisely. Fluency in mathematics will help, even if it isn't Absolutely Necessary.

Collapse -

Analysis In Software Development is not based on Mathematics

by Wayne M. In reply to Higher level math makes y ...

There are at least two types of analysis performed in software development, requirements analysis and program analysis. Neither is based on the type of analysis done in mathematics.

Requirements analysis is based on language, oral and written. It involves understanding of various shades of meaning, identifying and resolving apparent and real contradictions, determining rules and exceptions, and dealing with almost infinite variations. This type of analysis is better learned in a Literature course analyzing written works than in a mathematics course deriving equations and proofs.

Program analysis is even less clear cut. Here we use subjective concepts like cohesion, coupling, readability, testability, complexity, and bigness. For every problem there is almost an infinite amount of solutions and an even higher amount of dead ends. We try to eliminate the dead ends and argue endless over the nuances of "better" solutions. Where is the mathematics in determining which classes to create? Whether to use comments? To use a stored procedure or application code? I would love to have a proof to give the right answer, in practice I have to be satisfied with an answer that is accepted without physical violence or bloodshed.

In a branch of mathematics, one works in a closed world based on a set defined beliefs (axioms). Except for the extremely small few who create a new branch, mathematics involves the study and application of that branch's axioms. Software development works in the world of human people and underlying, universal truths do not exist. It is a world of many right answers, each true and each false in a different way.

I respect mathematics and I respect software development, and I understand they are largely independent.

Collapse -

Au contraire

by deepsand In reply to Analysis In Software Deve ...

In my nearly 50 years of experience in this regards, I have found that it is not uncommon for mathematics to be used for analyzing both the problem and its possible solutions, not to mention the implementation of a chosen solution.

Collapse -

Mathematical models can be very useful

by Tony Hopkinson In reply to [i]Au contraire[/i]

Their real value is they by their nature they remove a lot of extraneous detail, so you don't get someone whining about a spelling mistake, of choice of font, and missing the fact that they omitted a bit of the spec.

Nor do you suddenly find it's been sold to ten customers, even though it's not even close to being finished.

There are still a whole raft of questions that have to be answered before you can build the model though which is the point I think Wayne is trying to make.

Collapse -

Please Expand On Your Comment

by Wayne M. In reply to [i]Au contraire[/i]

Could you perhaps provides some examples of where you found it beneficial to apply mathematics? I think this might provide a baseline for discussion. Thanks.

Collapse -

An example that immediately comes to mind is an inventory control system ..

by deepsand In reply to Please Expand On Your Com ...

for the forms used by an insurance company.

A very large number of the forms were used by different departments, for different purposes, with their usage levels being driven by activites, not directly involving the use of said forms, in multiple departments. Furthermore, the re-order lead times required varied both by the printing source as well as by the re-order quantities; likewise, so did the ability to take partial delivery of a given printing order.

Statistics were invaluable in measuring the historical usages, as were determined from warehouse records of shipments received & requisitions filled, and current samplings of departmental activities records with regards to those activities which drove demand. both directly & indirectly, for each form.

The intricate relationships between those inputs which in any manner affected the demand for a form or forms were best described by partial differential equations. From these I was able to model the expected demand for a given form based on real time levels of activities, and set re-order points that were self-adjusting so as to accomodate both the anticipated demands and the variable & quantity dependent lead times.

Collapse -

Deep

by Tony Hopkinson In reply to Please Expand On Your Com ...

I can see why it would work, just wondering whether there was a real benefit from the extra effort?
Must say I'd have hacked at that one from expected demand, course that assumes a few other sytems in play.

Collapse -

The problem was that "expected demand" was highly variable, ...

by deepsand In reply to Deep

dependent on the future levels of various activities involving marketing of both new & existing products, both to existing policyholders, active & lapsed, (internal marketing), via direct mail (DM), and new ones (external marketing), via DM, TV, radio & newsprint; internal marketing tp active policyholders for the purposes of having them increase their coverage amounts and/or add optional benefits riders; internal marketing for the purposes of improving conversion and/or renewal rates; and, internal marketing to lapsed policyholders soliciting reinstatement.

Given that the response, conversion, renewal & reinstatement rates varied greatly by product, demographics & marketing channel, and that future marketing efforts were highly dependent externalities, forecasting forms demands for more than a few months into the future was problematic.

That I was called upon to design a new system was owing to the fact that the existing one used fixed re-order points that were really little mores than SWAGs, and no longer worked; too many forms were either being used up more quickly than they could be replaced, or gathering dust in the warehouses.

Collapse -

Never faced that particular problem

by Tony Hopkinson In reply to The problem was that "exp ...

The issues I had were more data quality, recording planned usage, that was originally non existent.
Minimising inventory was always important of course, but came second to the mill being stopped and 350 blokes playing cards on full money, waiting for a part.

Collapse -

Neither had I before then; and hopefully, never again.

by deepsand In reply to Never faced that particul ...

That project was truly a *****-and-a-half, which it what made it so memorable & easily called to mind when Wayne asked his question.

I suppose that, like myself before said project, most think of inventory control as being quite straight forward & simple, a function wholly lacking in cachet, one which should offer no challenge to other than the true neophyte. Man, was I wrong!

Back to Software Forum
473 total posts (Page 5 of 48)   Prev   03 | 04 | 05 | 06 | 07   Next

Related Discussions

Related Forums