4 ms·
A ton of problems in software engineering, I am convinced (and isn't wild generalization one of the marks of our field! I at least want to own my own hypocrisy
by adw 8y ago
A ton of problems in software engineering, I am convinced (and isn't wild generalization one of the marks of our field! I at least want to own my own hypocrisy here) are communication problems. Nearly all the interesting ones, anyway.
And one of them is axioms no-one ever communicates. I've worked with programmers with at least three markedly different axiomatic bases, for want of some less pretentious – and less exaggerated-for-rhetorical-effect – way of putting this:
* `Electrical engineers`. "Computers are imperative because computers are just circuits". Functions, objects, mathematical abstractions in general are fundamentally leaky and to be regarded with deep suspicion. Paradigmatic languages: C, asm.
* `Pure mathematicians`. Computers are abstract machines for manipulating symbols. Programming is set theory; hardware is an implementation detail. State is just an artifact of insufficient precognition. Paradigmatic languages: ML, Haskell.
* `Approximators`. These folk rarely come from computer science backgrounds; instead they tend to come from "technical computing", meaning sciences, engineering, economics, statistics and the like. They're also on the rise, because this is the group of people who "get" machine learning. Computers are fancy and very fast slide rules; their job is to run approximate numerical methods very fast. The only true types are `float` and `bool`; programming is translating linear algebra into algorithms which estimate the correct results stably with bounded error, ideally by calling the right bits of LAPACK. Paradigmatic language: historically, Fortran; these days, whatever array language is embedded in the libraries they're using, surrounded by Python or (if statistician) R.
The point is; these are three markedly different worldviews and none of them are any more fundamentally wrong than the others – they're all useful and wildly incomplete. So unless you can get agreement – or at least empathy – within your team, you're going to spend a lot of time talking past each other.
- a-nikolaev 8y agoYeah, interestingly, I have this impression that Python is a modern-day Fortran. (Largely for the reasons you describe in the third category of programmers.)
- nostrademons 8y agoOn some level that's literally true: when you run NumPy or SciPy code, most of your basic array manipulations are done by BLAS, which are a set of very tightly optimized linear algebra routines originally written in Fortran.
- adw 8y agoA very large part of the answer to "why do people use Python?" is "why did physicists adopt Python en masse in the early 2000s?" and a large part of the answer to _that_ is "f2py exists"...
- bigger_cheese 8y agoAt least among my colleagues (process engineering) the language is basically an afterthought. Your slide rule analogy is right on. For a lot of the people I work with code is just a way of representing mathematics. So you end up with "Fortran written in every language" Here is a snippet of code (this is written in C but I guarantee most of my colleagues would write this the same regardless of it it were fortran, python, Matlab what ever). for (i=m1;i < m2; i++) { //f(p)^2 = (u^T)(Q^T)(D^2)Qu and F(dF/dp) = (u^T)(Q^T)(D^2)Q(du/dp) g =h; h = (v[i+1]-v[i])/(x[i+1]-x[i]); g = h - g - r1[i-1]*r[i-1]-r2[i-2]*r[i-2]; ... } Here's some SQL SELECT t2.Line, t2.Slope, t1.X, t1.Y, t1.Y - (t2.Slope * t1.X) as Intercept /* B = Y -Mx */
- hathawsh 8y agoThat's a very interesting categorization. I would generally place myself in the 'electrical engineers' category. I usually code in Python, Javascript, or Java, but I see those languages as essentially C or machine code with productivity enhancements like garbage collection, objects, closures, and lots of interoperable libraries. OTOH, I would also place myself somewhat in the 'mathematician' category because I see imperative code as functional code where each instruction is a function that takes the current machine state and some parameters and computes a new machine state. The new machine state is an input for the next instruction. When you see it that way, instruction pipelines in the CPU become very easy to comprehend: the CPU calculates one or more possible future machine states while waiting for a response from DRAM, then selects the correct state based on the response. Seeing it that way also reveals the main issue with imperative programming: the each instruction accepts too many inputs! Functional programming helps constrain the inputs so that it's easier to reason about what the code does and how it can change.
- adw 8y agoIt's a pile of massive overgeneralizations, not least of which is that people don't fall neatly into these categories. But it's a useful framework for thinking about miscommunication, I've found.
- hathawsh 8y agoI agree. Next time I have a disagreement with another coder, I might ask them whether they see computers as primarily circuits, set theory implementations, or AI. (I might add "filing cabinet" as another category.) It would help me understand which assumptions I can probably make.
- shalabhc 8y agoSo where do Smalltalkers and Lispers go?
- _emacsomancer_ 8y agopresumably in the "mathematical" group
- minikomi 8y agoOutside in the car park playing hackey sack
- MrEldritch 8y agoStatistically insignificant.
- azeirah 8y agoMental health facility :(
- lispm 8y agoPart of the Lisp tradition was the 'knowledge engineer'. Identify the knowledge and processes necessary for problem solving and implement a machine for that: logic, rules, semantic networks, ... Bring the programming language near to the problem domain.
- Retric 8y agoWhen you try and ignore the hardware you find out things like random bit errors occur. Thus pure symbol manipulation is unequivocally false. Pretending a computer is somethings else can be a useful abstraction, but you can actually learn what’s going on.
- learc83 8y agoI like that categorization. One semester during college I was taking both a computer architecture class, and an automata/theory of computation class--I still remember when I realized that there were 2 fundamentally different ways of approaching computing. Studying the history of computing, you'll also come to a similar realization that there are 2 fundamental approaches. Personally, I've always loved both paradigms, and I've never been able to decide which one I prefer. I tend to move between the 2 depending on which one works better for the task at hand. That realization (along with the fundamentals required to understand both paradigms) was one of the most useful things I got out of my degree.