I personally think humans prefer imperative languages because they are closer to the metal, and hence more predictable in terms of performance.
I personally think humans prefer imperative languages because they are closer to the metal, and hence more predictable in terms of performance.
Consider, I often tell my kids that they need a cup if they want water. I just as often have to change that to "go get a cup, and I'll get you water."
Declarative seems to be natural at a desire level, but at an action level, imperative seems to be more common.
I believe this is flipped for topics and actions that are well internalized. When my kids are older, I can just say "cup". If cups aren't in the right drawer, I have to provide imperative to where to check, though.
And yes, all of this is anecdotal. YMMV. I'm highly interested if folks know of studies or counter examples.
Consider the imperative
cup_of_water get_water (cup_loc, water_loc) {
cup = get_cup(cup_loc);
return fill_cup(cup, water_loc);
}
or something like that, versus getWater :: CupLoc -> WaterLoc -> Cup Water
getWater cupLoc waterLoc = fillCup (getCup cupLoc) waterLoc
It's just a slightly different way of thinking about things.It is amazing how they can understand well before they can say words. Or read and write them. Sign language can be taught really early. Not sure what data that adds here.
But, I believe that imperative makes sense because so much in life is imperative. Especially directions we give each other.
For things that can be done symbolically, declarative can be a big boon. But it does seem to be the minority.
(Easy in an imperative system, painful in a functional one where you have to start passing monads around and caring how many times the cup is constructed rather than how many cups you end up with.)
All this gets me thinking back to the micros and how they booted straight into a BASIC interpreter.
In a sense while booting to a mouse (or touch) driven GUI helps with getting now common tasks done out of the box. That no mainstream OS ship with something that allows someone to sit down and instruct a computer similarly to how it was done back then seems to have turned modern personal computers into near appliances.
Not that it is impossible, but it is surprisingly difficult and not shocking that fewer do it. (Of course, I question myself on that claim. Fewer, but by what measure? And do I have proof?)
But they have since handed the whole project over to MIT.
Frankly Android could have been a computer in our pockets, and i get the feel Rubin wanted to take it in that direction.
But around the time of 3.x-4.0 there was pressure from elsewhere in Google to take in a more iOS direction. We see this with the introduction of music and video into the then named Android Marketplace (later renamed Google Play).
And then there was the whole push towards ChromeOS as the choice of businesses, complete with Citrix being a launch day demo.
Only in the last few years have Google done an about face regading Android. Both with Android apps coming to ChromeOS, and with various functionality being added to Android to make it more business friendly.
Not to mention c# is a beautiful language.
Dream on. MS will implement just enough for cloud devs to use Windows as their dev environment, with a clear push towards Azure as the cloud of choice.
To the point of android, though. I am getting my kids a Kano computer. Hoping that line will get them interested in the nuts and bolts, as it were. I need to be better and build things with them. :(
I grew up in that era, and I'm still nostalgic about it. On the other hand, a tablet PC plus Jupyter/Python comes pretty darn close to satisfying that need.
Microsoft screwed up badly when they decided you can't put a Metro style interface on a Win32 program and get touch support that way.
You either have to make it a Metro app (and ship it via their store), massively curtailing what you can do, or stay with the Win32 WIMP. And even when you tweak the size of various Win32 elements it is still a mess to operate via touch.
Edit: and using jupyter with a tablet strikes me as accessing a mainframe from a terminal (something a micro could act as with the right software).
This isn't my only computer, and indeed doing anything with code from a touch screen is marginal at best, but at least it's possible. On a bigger computer, of course I get a bigger screen and keyboard.
Admittedly, I had to look up what Metro and WIMP are. I'm not actually trying to create apps that others can use. My use of programming is largely for my own productivity and learning.
Just the point/click nature of jupyter?
I guess it's the REPL-on-steroids nature of Jupyter that I like. Also, having inline matplotlib graphs is pretty killer.
My favorite is grabbing logs with a shell block. Reshaping with elisp or Python, and then charting with gnuplot. All in one file with an iterative workflow.
get_a_cup |> Option.map(fill_with_water)That is, there is no intrinsic advantage to imperative, by my assertion. Just that it is something we are much more comfortable with from experience.
As for the state, I think in life everything has state. Kids are quickly learning which ones have states that they care about. It is not uncommon to see them learn that cups filled with water need to be held a certain way, otherwise they spill.
Now, like more formalisms, computing and programming is much more strict. But that is a matter of rigor, moreso than of form. That is, it is the same form, just not forgiving in syntax/content.
Though, seriously, if I am abusing terms here please let me know. Is not my intent.
I wonder which paradigm a total beginner would prefer? As a beginner they would not be influenced by "how the metal works" because they don't know or don't care. My guess is that beginners would prefer imperative languages as well, even though it has nothing to do with "the metal".
but ill have to still admit ignorance to a greater understanding of Rust.
Really?
It's the mother of all, and abusing it in ways that make it unpredictable is more than likely.
It has to be said that I'm a "right tool for the job" kind of man, and spend less time worrying about the perfect-ness of a language. Can't think of a better language to write crypto/network routing code with. Though a colleague did implement some mDNS craziness with java.
Don't shoot me. Heh.
So far the limitation of what's practical were/are the driver of industry.
And von neumann did solve a real problem they had back then. These days were facing a software engineering problem which is more high level, and most faculties are triaging the situation - but I can't really blame them. Many unis lack the funding for ground breaking experimental work - and the likes of Turing/von neumann/knuth/dijkstra et Al, only come once a generation.