31–40 of 74 posts
Many modern web apps where many programmers are employed are simply IO glue (request in, database in/out, web page response out) and don't involve many algorithms other than sorting and using hashtables and trees.
A seductive idea, but ultimately of stunningly limited use in software engineering. By far the most costly defects in software creation are due to incorrect requirements or poor systems design. Knowing with mathematical certainty that your software component does exactly what you have specified it to do helps little when what it does is still the wrong thing. And that doesn't even touch on the fact that crafting comp…
I'm sure this can be modelled mathematically, but I'm not convinced this would help.
Earlier quoted context omitted.
Routing is heavily based in graph theory, as far as I know, and so is actually fairly mathematical. Memory management can also require a good bit of math. A perfect example would be taking an existing algorithm and optimizing it to use fewer memory accesses. We covered this sort of optimization in my recent algorithms class (for some algorithms) and it figuring out how to do required a good bit of math. Really, the i…
Modern IP networking relies extensively on graph theory. The Spanning Tree Protocol is a prime example of this.
Simple answer - the vast majority programmers rarely see more than rudimentary math on most projects, unless those projects are specifically math orientated (actual sciences, for example). The rest of us working on our sites, platforms, apps and what-have-you usually only see anything resembling math when dealing with things like UI and Interaction models, or typically soft-math areas like rating systems and segmenta…
Many modern web apps where many programmers are employed are simply IO glue (request in, database in/out, web page response out) and don't involve many algorithms other than sorting and using hashtables and trees.
A seductive idea, but ultimately of stunningly limited use in software engineering. By far the most costly defects in software creation are due to incorrect requirements or poor systems design. Knowing with mathematical certainty that your software component does exactly what you have specified it to do helps little when what it does is still the wrong thing. And that doesn't even touch on the fact that crafting comp…
Agree, bur if you don't know how that relatest to math, then you will not discover how math fixes "poor system design" and, as a side effect "incorrect requirements"
We work in an environment where heresay [sic] and taste drive change instead of studies and models. We are stumbling in the dark. Another way to look at it is that we’re making progress, but with lots of false starts, like most progress. Hearsay and taste are what happen when people are working with imperfect information. Probably not even Knuth has perfect information about all the studies and models that might be r…
Haskell's advantages lie in being pure. It can't be 'friendlier,' because friendly languages let you hack things up (and are impure) as opposed to the planning required to lay down some Haskell.
It is often an egocentric excuse to not lean new tools... As if programming was about making he programmer comfortable, as opposed to producing the best result possible.
I've written complex systems. Games. Graphics modelling tools. Network game engines. I've seen a lot of code.
I've never seen anything that complex written in a functional language.
Why?
My hunch is that models are powerful, but brittle: they don't stand up against constantly changing requirements. A great quote I read the other day was "If it compiles, it works". Great. Now change the requirements. The "beauty" of imperative languages is that they continue to compile and continue to provide some value of "work" even while they are morphing from one requirement set to the next. Functional languages are cast-iron. Imperative languages are steel.
UPDATE: I should also be clear: I think in models all the time. I just don't have to get it down perfectly on paper for the code to compile. I used to hear, back in the day, C++ programmers opining that we should all use C++ because object-oriented programming is superior. Regardless of whether or not OO is superior, they completely failed to comprehend how one could do object-oriented programming in assembly language, or that we'd been doing it the whole time.
So its entirely possible that there's something I dont get about functional programming that means I don't understand what I'm missing. But its also possible that I understand the theory better than you and so I don't see the distinction you are making because there isn't one. To discern which is true, however, I'm going to need concrete examples, not opinion pieces.
A seductive idea, but ultimately of stunningly limited use in software engineering. By far the most costly defects in software creation are due to incorrect requirements or poor systems design. Knowing with mathematical certainty that your software component does exactly what you have specified it to do helps little when what it does is still the wrong thing. And that doesn't even touch on the fact that crafting comp…
"poor system design" Agree, bur if you don't know how that relatest to math, then you will not discover how math fixes "poor system design" and, as a side effect "incorrect requirements"
I completely agree. Programming became a lot less fun once I entered industry and realised most decisions are driven by fashion and office politics. It's not so bad when it's you and a couple of friends hacking all night on a project because you likely have closely aligned interests. Being an employee, however, means you're a slave to other people's ideals.
I suppose this is why most of us are interested in startups.
You may also be interested in this post by Zed Shaw: http://zedshaw.com/essays/programmer_stats.html
~~~
Surely the first person to write an algorithm wasn't Babbage or Lovelace, but more likely to have been the middle-eastern mathematician the word was named after? http://en.wikipedia.org/wiki/Mu%E1%B8%A5ammad_ibn_M%C5%ABs%C...