10 ms·

I wasn't exposed to spreadsheets until a few years into college back around 1996 or 1997 maybe (I had been programming in C/C++ for 7 or 8 years by then). I wa

I wasn't exposed to spreadsheets until a few years into college back around 1996 or 1997 maybe (I had been programming in C/C++ for 7 or 8 years by then). I wasn't taught matrix math until pretty late in the curriculum, I want to say junior or senior year. Also I was lucky to have a semester of Scheme but they were transitioning to teaching Java around the time I graduated (I don't know if they ever switched back). And this was for a computer engineering degree at one of the best state universities for engineering in the US. Honestly I think it might be time to phase out teaching imperative and object-oriented programming. Most of the grief in my career has come from them. I don't care if they're where the jobs are. The mental cost of tracing through highly-imperative code, especially the new implicit style of languages and frameworks like Ruby and AngularJS (which have logic flows having no obvious connection to one another, or transition through async handlers connected by a convention which isn't immediately obvious to the developer) is so high that the underlying business logic is effectively obfuscated. I think we should get back to fundamentals. Maybe start with the shell and explain why separate address spaces connected by pipes are such a powerful abstraction, maybe touch on the Actor model, maybe show how spreadsheets and functional programming are equivalent, and how even written notation is superfluous. Really focus on declarative programming and code as media, and how that made the web approachable by nontechnical folks before it was turned into single page application spaghetti. There are so many examples from history of where better ways were found before the mainstream fell back into bad habits.

Retric 8y ago
Computers are still imperative, so all functional code is arguably syntactic sugar over that core causing a lot of leaky abstractions to show up all over the place. I think the problem with Object-oriented programming is it's taught to soon. Start with Imperative then Functional then toss object oriented into your senior year.
- Koshkin 8y ago
  > Computers are still imperative "Computer Science is no more about computers than astronomy is about telescopes." — (Mis)attributed to Edsger Dijkstra, 1970.
  - dmpk2k 8y ago
    Meanwhile, in the real world...
  - AllegedAlec 8y ago
    That explains why astronomers are so incredibly enthousiastic about telescopes, and spend immense amounts of time trying to create better ones to overcome the limits of what they can do now.
    - Koshkin 8y ago
      Sure, everyone is enthusiastic about their tools. Still, it is not telescopes that are the subject of the science of astronomy.
      - AllegedAlec 8y ago
        It's not the subject, no, but the limitations on telescopes are what places limits on how much astronomy can do, and by improving their telescopes, and by improving how they use their telescopes, they can find out more than what they could before.
        renox 8y ago
        Note that the detection of gravitational waves necessitated the modelisation of these waves first. So astronomy is needed as an input and also progress as an output of the telescope..
  - klodolph 8y ago
    I'm still convinced that (Mis)Quoting Dijkstra Considered Harmful. A Dijkstra quote derails a conversation about CS almost as surely as anything else.
  - LukeShu 8y ago
    > As a result, primarily in the U.S., the topic became prematurely known as "computer science"---which actually is like referring to surgery as "knife science"---and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment. Edsger W Dijkstra. Mathematicians and computing scientists: The cultural gap. Abacus, 4(4): 26–31, June 1987. ISSN 0724-6722. URL http://dl.acm.org/citation.cfm?id=25596.25598 http://dl.acm.org/citation.cfm?id=25596.25598. Which is similar in spirit to the contested quote, and predates by a few years any of the references on Wikiquote.
- cicero 8y ago
  I have heard critiques of functional programming, but not that there is a problem with leaky abstractions. Can you provide an example? Does it invalidate the discipline of trying to use pure functions when possible? I learned to program using BASIC on an Apple II. All of the variables were global, and it wasn't until I got Apple Pascal that I had access to a language that had local variables. I immediately saw the advantage of the discipline of using local variables whenever possible because I had experienced the difficulty of tracking down where in the whole program a global variable might be changed. It could be argued that local variables are just syntactic sugar over a global memory space, but no one credibly argues today that we should therefore only use global variables. Local variables make it easier to reason about the behavior of a program, and it appears to me that functional programming takes that idea even further.
  - Retric 8y ago
    Program execution time and memory footprint are great examples. Math does not care about these details, but just because two programs are logically equivalent does not mean they will behave identically. I am very pro functional programming, but your mental model needs to be accurate to really dig into the details. As such you really need to understand ASM and procedural code or it will eventually bite you.
    - ken 8y ago
      That's a curious place to draw the line. As we've seen in the past year, assembly isn't good enough. You need to understand your microcode or it will eventually bite you ... and you don't. But that's all just nit-picking <<1% cases. When's the last time you saw a functional program whose execution time or memory footprint were unacceptable, and required knowledge of assembly language (or lower) to resolve? I can't say I ever have.
      - Retric 8y ago
        The best example I can give is not quite functional code. I have seen a lot of horrific SQL because someone did not really understand that Joins for example had a cost based on some understandable criteria. You need to have a basic mental model of what the database does to write good SQL. I don't expect everyone to proficient in ASM let alone microcode, but I do expect them to at least understand that they exist. Beyond that I expect any decent CS program to enable someone to build a useful mental model of what's going on. Plenty of subject matter experts write very valuable code without that knowledge, but they tend to hit a very real wall.
- StreamBright 8y ago
  And what about humans? You are rarely writing code for computers, but for humans. Many companies optimize code for readability. And there is a reason. Usually multiple people are working on the same code at the same time, or over time at least. It is the compiler's job to translate the code to computers language which can be imperative, I would still prefer the human side functional and declarative. Maybe it is just me. I have struggled with the concepts of Java for a long time, especially with the many keywords that I cannot relate to, private, final, static, void while I understood majority of Clojure at the first glance. I could not write Java without an IDE but more than happy to develop Clojure with VI. It appears to me that we overcomplicate things for no good reason and underestimate the power of simplicity.
  - Retric 8y ago
    Education is there to teach you. I don’t think everyone will use SQL or ASM for example, but IMO every CS program needs to have at least one class covering each of them in depth for at least a few weeks. Procedural code is even more central, and should be covered in depth.
  - ChristianGeek 8y ago
    “I don’t understand it, therefore it is inferior.” I currently program for a living with Java. It clicked with me the moment I first learned it. (It was also my first introduction to OOP.) Right now I’m struggling to learn the nuances of functional programming with both Scala and Haskell. Do I consider functional programming, Scala, or Haskell inferior because they’re not as straightforward for me as Java (or C#, or C, or even ASM) was? Of course not.
  - jtms 8y ago
    To be fair, almost no one can (or should) write java without an IDE. IntelliJ + ideaVIM has been a great compromise for me as a long long time VIM user. I know I am not responding to your main point (of which I am sympathetic) but I figured I'd throw it out there anyway
- 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 ago
    Yeah, 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 ago
      On 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.
- vmchale 8y ago
  > so all functional code is arguably syntactic sugar No. "Syntatic sugar" implies that it is relatively trivial 1-1 translation that could in principle go backwards. Functional programming has many, many more optimizations and transformations.
Joe-Z 8y ago
Would you mind elaborating on "why separate address spaces connected by pipes are such a powerful abstraction", or point me to some sources? Likewise if there's something you can recommend for reading up on the Actor model?
- theoh 8y ago
  The phrase probably refers to Unix pipes: https://wiki.tuhs.org/doku.php?id=features:pipes https://wiki.tuhs.org/doku.php?id=features:pipes
- zackmorris 8y ago
  Ya in my mind, executables that do one thing well and are connected by pipes is one of the most proven models for getting things done. Even relatively nontechnical people can write shell scripts, batch files and macros that take some kind of data from a socket/file/pipe, pass it through a bunch of black boxes and spit out an answer. This is very similar to the Actor model and is much simpler to reason about than the shared state threads of languages like Java. Optimizations like copy on write can eliminate most of the overhead of sending data between processes. Here's a quick overview of how the Actor model is better than shared state (mainly by avoiding locks and nondeterminism): https://doc.akka.io/docs/akka/2.5.3/scala/guide/actors-intro.html https://doc.akka.io/docs/akka/2.5.3/scala/guide/actors-intro... And just as an aside, I haven't fully learned Rust yet but from what I understand, the borrow checker only applies to mutable data. If you write a fully immutable Rust program then you can avoid it altogether. So to me, this is a potential bridge between functional and imperative programming. It also might apply to monads, since (from what I understand) languages like ClojureScript can run in one-shot mode where all side effect-free code runs completely and then the Javascript runtime suspends execution, only starting it again once new data is ready. This might also be a bridge between functional and imperative code, because I've found monads to be one of the weakest links in functional programming and I've never quite wrapped my head around how they work or if they're even a good abstraction. Maybe someone can elaborate on them! In short, the goal here is to reduce all concurrent code to a single thread of execution that is statically analyzable as much as possible. So a typical C++ desktop app may not see much benefit from this, but anyone who has found themselves in Javascript callback hell can certainly appreciate the advantages that async/await provides, since it more closely approximates the message passing of Erlang/Go, which is more similar to shell scripting. If we had a "perfect" language that optimized all code to be concurrent as much as possible, for example by converting for-loops into higher order functions like map and then running them on separate threads behind the scenes, then we could offload the wasted work currently done by humans onto the runtime. So that would mean that instead of writing programs that, say, access remote APIs, cache the data somehow, remember to invalidate it when the source of truth changes, etc etc etc, that complexity instead could be reduced to a dependency graph that works like a spreadsheet and updates all dependencies when something changes. This seems to be where the world is going with reactive programming, with a lot of handwaving and ugly syntax because it's reimplementing old concepts from Lisp etc: https://en.wikipedia.org/wiki/Reactive_programming https://en.wikipedia.org/wiki/Reactive_programming Sorry this got a little long, I could ramble about the downsides of programming in these times for hours.
Koshkin 8y ago
> time to phase out teaching imperative Knuth would probably disagree.
romaniv 8y ago
>Honestly I think it might be time to phase out teaching imperative and object-oriented programming. I have seen plenty of universities teach Java and C++, haven't seen any that teach actual OOP. James Coplien aptly calls the current paradigm "class oriented programming".
- outworlder 8y ago
  It triggers me to no end when I watch an introductory course, for people with no previous exposure to any programming language, and the teacher starts with "public static void main()" In order to understand it, you need to have a good grasp of classes, static methods, access controls. This is usually followed up by a request to ignore the entire line, which is one of the worst habits you can have as a developer. Then you have to compile this. It used to be the case that people would copy and paste command line excerpts (bad habit!), but now they will get a pre-configured "IDE" where they can punch the compile button (ok, but I have met plenty of professionals who never left this stage). Instead, they could avoid the whole thing by using something else, say, Python, or even Javascript. In both cases you can quickly drop to a repl and start trying stuff out. Once the basics are there, then you can proceed to object orientation. And perhaps even to Java as a more advanced course, only you now have the proper concepts to understand the very first line you are supposed to write. Why would universities teach Java and C++ anyway? They are either 'boring' from a computer science perspective, or too convoluted for teaching concepts.
  - scarface74 8y ago
    Why would universities teach Java and C++ anyway? They are either 'boring' from a computer science perspective, or too convoluted for teaching concepts. Not a fan of Java by any means, but they should teach Java so graduating students can put that on their resume and get a job so they won't live with their parents until they are 35....
    - _emacsomancer_ 8y ago
      This is presumably why they do teach Java.
quickthrower2 8y ago
I disagree that they should phase out imperative / OO programming, but from my experience more emphasis on different languages i.e. throw in a ML (as in Meta Language) and a Lisp, and most importantly some information about the trade offs. However it would require a culture shift as a university being a place to get you ready for a career in industry rather than academia. Because you are prepping for academia it is OK for them to postpone functional to later years on even the PhD. You mention grief with OO - but I think a lot of it you would get with Functional too and it has more to do with the incentives and people structures in organisations that produce code. Usually praise goes to those who get a 8 hour Jira ticket done in 4, or a 5 week task done in 4 weeks etc, and from the users point of view 'it works'. The structure of the code is not discovered until later. Code reviewers are working at the deckchairs level, they are unable to change the Titanic's direction, and again both parties in a code review have incentive to do it as quick as possible (while not looking like they obviously brushed over it), so it become mostly a potential bug hunting and syntactic cleanup exercise. It's almost a running joke that refactoring rarely gets done, and if it does it is trivial, and usually required some stealth from a developer or manager to create cover to do the refactor. The only hope we have is to work somewhere where there is a good understanding of code quality from top to bottom in the org, or at least when you cross the technical/non-technical boundary there is a high degree of trust to let the tech people do the right thing, and not KPI them into submission.
- zackmorris 8y ago
  You summed it up nicely. After writing my comment, I realized that imperative programming is so much more difficult than functional programming that in a way, it's the majority of the work of programming. Anyone can learn to use a spreadsheet, but it takes years of dedication to master debugging enterprise software. So there will always be huge demand for that skill, and so colleges should probably continue building it in students. I'm still in mourning though imagining how far programmers could go if they weren't stuck endlessly debugging imperative code that will never be deterministic or free of side effects. Lots of lost potential there. I'm coming up on 3 decades of experience doing that and it feels like well over 90% of the code I've written was a waste of time. I guess it paid the bills though.
laythea 8y ago
"...have logic flows having no obvious connection to one another, or transition through async handlers connected by a convention which isn't immediately obvious to the developer" This is very true. I hate parsing code written like this, or code written using a mashup of concepts, requiring mind gymnastics to fathom an implementation of a solution to a relatively simple problem. It makes the job so much more unnecessarily difficult. Points for simplicity if you ask me.
- seanmcdirmid 8y ago
  Inverted control is a hallmark of many programming domains. It’s not like you can get the user to be synchronous with respect to the program they are using (unless it is a non interactive batch tool). Even functional paradigms like Rx have control flow running around all over the place, the only saving grace is if you can keep it encapsulates via a set of opaque data flow pipes (and often you can’t).
munchbunny 8y ago
> Honestly I think it might be time to phase out teaching imperative and object-oriented programming. Most of the grief in my career has come from them. I don't care if they're where the jobs are. The mental cost of tracing through highly-imperative code, especially the new implicit style of languages and frameworks like Ruby and AngularJS (which have logic flows having no obvious connection to one another, or transition through async handlers connected by a convention which isn't immediately obvious to the developer) is so high that the underlying business logic is effectively obfuscated. I don't think this is a fault of functional programming as much as it is a fault of implicit language constructs. There are common conventions where being able to chuck functions and closures around is actually useful (e.g. sorting). These language constructs/conventions are useful because they can be extremely expressive, but unfamiliar implicit behaviors cost me much more "working memory" to understand when I'm reading the code. There's a version of object-oriented programming that mostly sticks to declarative behaviors and uses inheritance, unions, mix-ins, etc. to actually hide behavioral abstractions. The problem is that it often takes 5-10 years of experience before the programmer (myself included) begins to appreciate how important future readability of the code is, and to understand that the more exotic language features should be used sparingly.
vmchale 8y ago
> show how spreadsheets and functional programming are equivalent They are not in fact equivalent, unless the functional programming you're doing is trivial.
macspoofing 8y ago
>I think it might be time to phase out teaching imperative and object-oriented programming. Most of the grief in my career has come from them. Good luck. Computer Science degrees are balancing act between practical and theoretical. More importantly students want to work with technologies that are popular in the industry today. You can try to to stand against the tide, but you will lose.
ezoe 8y ago
Real hardware is imperative. Object-oriented programming was once treated like Functional programming. The languages which did implement OOP as it was originally thought was horribly inefficient. So practical languages took the good idea out of OOP for convenient syntax sugars. Functional Programming will follow the same path. You probably don't like it for it will be ended up impure and just some syntax sugar that looks like FP, but rest of the world like it because it gets the job done.
- vmchale 8y ago
  > Real hardware is imperative. Wrong. > So practical languages took the good idea out of OOP for convenient syntax sugars. Also wrong, unless by "syntactic sugars" you mean "nontrivial compiler rewrites" > Functional Programming will follow the same path. Doubt it. > You probably don't like it for it will be ended up impure Purity does not constrain efficiency at all.
  - learc83 8y ago
    >Wrong. At an abstraction level below digital circuits, you are correct. But thankfully the layers on top of that do almost always do a very good job of hiding it. >Doubt it. Functional programming is already following the same path. Sure there will non-hybrid languages around if you want to use them, but take a look at the functional constructs that have made their way into almost every procedural language in use today. Most people have never touched Haskell, but almost everyone has seen a map function. >Purity does not constrain efficiency at all. Maybe not inherently, but there's a reason we have to break out and use mutable data structures when we really need performance. For the systems we are working on today purity does impact performance/efficiency.
mattnewport 8y ago
Could you elaborate on how you came to be programming in C/C++ for 7 or 8 years before encountering a spreadsheet? That seems an unusual path even back in the 90s.
- zackmorris 8y ago
  Ya I picked up my first programming book when I was 12, then started with HyperCard and Visual Interactive Programming (VIP) on the Mac Plus with my friend (another guy named Zack): https://en.wikipedia.org/wiki/HyperCard https://en.wikipedia.org/wiki/HyperCard http://mstay.com/images/screens/vpc1.gif http://mstay.com/images/screens/vpc1.gif So thought of code as a big flowchart where you fill in the boxes with business logic. Transitioned to C within a year or two and got incredibly deep into assembly language and low level code for blitters back in the 486 era when DOOM came out. Unfortunately moderately priced Macs were an order of magnitude too slow to play fullscreen scrolling games at 640x480x8 resolution until the 60 MHz PowerPC came out in the mid 90s. So never made any real money on Mac shareware games, but I digress. The Mac had an informal programming environment (no console or office suite with standardized inter-application communication) and I hadn't seen MS Access or FileMaker yet, or spreadsheets. When I first encountered them for writing reports in college and it finally clicked for me that code didn't have to be run imperatively, it was devastating in a way. But I made a full recovery in the early 2000s when PHP/MySQL got popular and I was able to get back into rapid application development with ORMs. I feel like the world is about ready to make the jump from hands-on tools like Laravel to WYSIWYG tools like Wix. Most of the attempts I've tried are frankly terrible, but I'm optimistic.
  - scroot 8y ago
    If you compare the ease of "authoring" in the top hypermedia environment of its day (Hypercard) with doing the same today (the web) it's plain as day that things have regressed. Here is a straight up comparison someone made if anyone is interested: https://twitter.com/ecgade/status/1029795513514774529 https://twitter.com/ecgade/status/1029795513514774529

Retric 8y ago

Computers are still imperative, so all functional code is arguably syntactic sugar over that core causing a lot of leaky abstractions to show up all over the place. I think the problem with Object-oriented programming is it's taught to soon. Start with Imperative then Functional then toss object oriented into your senior year.

Koshkin 8y ago
> Computers are still imperative "Computer Science is no more about computers than astronomy is about telescopes." — (Mis)attributed to Edsger Dijkstra, 1970.
- dmpk2k 8y ago
  Meanwhile, in the real world...
- AllegedAlec 8y ago
  That explains why astronomers are so incredibly enthousiastic about telescopes, and spend immense amounts of time trying to create better ones to overcome the limits of what they can do now.
  - Koshkin 8y ago
    Sure, everyone is enthusiastic about their tools. Still, it is not telescopes that are the subject of the science of astronomy.
    - AllegedAlec 8y ago
      It's not the subject, no, but the limitations on telescopes are what places limits on how much astronomy can do, and by improving their telescopes, and by improving how they use their telescopes, they can find out more than what they could before.
      - renox 8y ago
        Note that the detection of gravitational waves necessitated the modelisation of these waves first. So astronomy is needed as an input and also progress as an output of the telescope..
- klodolph 8y ago
  I'm still convinced that (Mis)Quoting Dijkstra Considered Harmful. A Dijkstra quote derails a conversation about CS almost as surely as anything else.
- LukeShu 8y ago
  > As a result, primarily in the U.S., the topic became prematurely known as "computer science"---which actually is like referring to surgery as "knife science"---and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment. Edsger W Dijkstra. Mathematicians and computing scientists: The cultural gap. Abacus, 4(4): 26–31, June 1987. ISSN 0724-6722. URL http://dl.acm.org/citation.cfm?id=25596.25598 http://dl.acm.org/citation.cfm?id=25596.25598. Which is similar in spirit to the contested quote, and predates by a few years any of the references on Wikiquote.
cicero 8y ago
I have heard critiques of functional programming, but not that there is a problem with leaky abstractions. Can you provide an example? Does it invalidate the discipline of trying to use pure functions when possible? I learned to program using BASIC on an Apple II. All of the variables were global, and it wasn't until I got Apple Pascal that I had access to a language that had local variables. I immediately saw the advantage of the discipline of using local variables whenever possible because I had experienced the difficulty of tracking down where in the whole program a global variable might be changed. It could be argued that local variables are just syntactic sugar over a global memory space, but no one credibly argues today that we should therefore only use global variables. Local variables make it easier to reason about the behavior of a program, and it appears to me that functional programming takes that idea even further.
- Retric 8y ago
  Program execution time and memory footprint are great examples. Math does not care about these details, but just because two programs are logically equivalent does not mean they will behave identically. I am very pro functional programming, but your mental model needs to be accurate to really dig into the details. As such you really need to understand ASM and procedural code or it will eventually bite you.
  - ken 8y ago
    That's a curious place to draw the line. As we've seen in the past year, assembly isn't good enough. You need to understand your microcode or it will eventually bite you ... and you don't. But that's all just nit-picking <<1% cases. When's the last time you saw a functional program whose execution time or memory footprint were unacceptable, and required knowledge of assembly language (or lower) to resolve? I can't say I ever have.
    - Retric 8y ago
      The best example I can give is not quite functional code. I have seen a lot of horrific SQL because someone did not really understand that Joins for example had a cost based on some understandable criteria. You need to have a basic mental model of what the database does to write good SQL. I don't expect everyone to proficient in ASM let alone microcode, but I do expect them to at least understand that they exist. Beyond that I expect any decent CS program to enable someone to build a useful mental model of what's going on. Plenty of subject matter experts write very valuable code without that knowledge, but they tend to hit a very real wall.
StreamBright 8y ago
And what about humans? You are rarely writing code for computers, but for humans. Many companies optimize code for readability. And there is a reason. Usually multiple people are working on the same code at the same time, or over time at least. It is the compiler's job to translate the code to computers language which can be imperative, I would still prefer the human side functional and declarative. Maybe it is just me. I have struggled with the concepts of Java for a long time, especially with the many keywords that I cannot relate to, private, final, static, void while I understood majority of Clojure at the first glance. I could not write Java without an IDE but more than happy to develop Clojure with VI. It appears to me that we overcomplicate things for no good reason and underestimate the power of simplicity.
- Retric 8y ago
  Education is there to teach you. I don’t think everyone will use SQL or ASM for example, but IMO every CS program needs to have at least one class covering each of them in depth for at least a few weeks. Procedural code is even more central, and should be covered in depth.
- ChristianGeek 8y ago
  “I don’t understand it, therefore it is inferior.” I currently program for a living with Java. It clicked with me the moment I first learned it. (It was also my first introduction to OOP.) Right now I’m struggling to learn the nuances of functional programming with both Scala and Haskell. Do I consider functional programming, Scala, or Haskell inferior because they’re not as straightforward for me as Java (or C#, or C, or even ASM) was? Of course not.
- jtms 8y ago
  To be fair, almost no one can (or should) write java without an IDE. IntelliJ + ideaVIM has been a great compromise for me as a long long time VIM user. I know I am not responding to your main point (of which I am sympathetic) but I figured I'd throw it out there anyway
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 ago
  Yeah, 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 ago
    On 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.
vmchale 8y ago
> so all functional code is arguably syntactic sugar No. "Syntatic sugar" implies that it is relatively trivial 1-1 translation that could in principle go backwards. Functional programming has many, many more optimizations and transformations.

Joe-Z 8y ago

Would you mind elaborating on "why separate address spaces connected by pipes are such a powerful abstraction", or point me to some sources? Likewise if there's something you can recommend for reading up on the Actor model?

theoh 8y ago
The phrase probably refers to Unix pipes: https://wiki.tuhs.org/doku.php?id=features:pipes https://wiki.tuhs.org/doku.php?id=features:pipes
zackmorris 8y ago
Ya in my mind, executables that do one thing well and are connected by pipes is one of the most proven models for getting things done. Even relatively nontechnical people can write shell scripts, batch files and macros that take some kind of data from a socket/file/pipe, pass it through a bunch of black boxes and spit out an answer. This is very similar to the Actor model and is much simpler to reason about than the shared state threads of languages like Java. Optimizations like copy on write can eliminate most of the overhead of sending data between processes. Here's a quick overview of how the Actor model is better than shared state (mainly by avoiding locks and nondeterminism): https://doc.akka.io/docs/akka/2.5.3/scala/guide/actors-intro.html https://doc.akka.io/docs/akka/2.5.3/scala/guide/actors-intro... And just as an aside, I haven't fully learned Rust yet but from what I understand, the borrow checker only applies to mutable data. If you write a fully immutable Rust program then you can avoid it altogether. So to me, this is a potential bridge between functional and imperative programming. It also might apply to monads, since (from what I understand) languages like ClojureScript can run in one-shot mode where all side effect-free code runs completely and then the Javascript runtime suspends execution, only starting it again once new data is ready. This might also be a bridge between functional and imperative code, because I've found monads to be one of the weakest links in functional programming and I've never quite wrapped my head around how they work or if they're even a good abstraction. Maybe someone can elaborate on them! In short, the goal here is to reduce all concurrent code to a single thread of execution that is statically analyzable as much as possible. So a typical C++ desktop app may not see much benefit from this, but anyone who has found themselves in Javascript callback hell can certainly appreciate the advantages that async/await provides, since it more closely approximates the message passing of Erlang/Go, which is more similar to shell scripting. If we had a "perfect" language that optimized all code to be concurrent as much as possible, for example by converting for-loops into higher order functions like map and then running them on separate threads behind the scenes, then we could offload the wasted work currently done by humans onto the runtime. So that would mean that instead of writing programs that, say, access remote APIs, cache the data somehow, remember to invalidate it when the source of truth changes, etc etc etc, that complexity instead could be reduced to a dependency graph that works like a spreadsheet and updates all dependencies when something changes. This seems to be where the world is going with reactive programming, with a lot of handwaving and ugly syntax because it's reimplementing old concepts from Lisp etc: https://en.wikipedia.org/wiki/Reactive_programming https://en.wikipedia.org/wiki/Reactive_programming Sorry this got a little long, I could ramble about the downsides of programming in these times for hours.

Koshkin 8y ago

> time to phase out teaching imperative Knuth would probably disagree.

romaniv 8y ago

>Honestly I think it might be time to phase out teaching imperative and object-oriented programming. I have seen plenty of universities teach Java and C++, haven't seen any that teach actual OOP. James Coplien aptly calls the current paradigm "class oriented programming".

outworlder 8y ago
It triggers me to no end when I watch an introductory course, for people with no previous exposure to any programming language, and the teacher starts with "public static void main()" In order to understand it, you need to have a good grasp of classes, static methods, access controls. This is usually followed up by a request to ignore the entire line, which is one of the worst habits you can have as a developer. Then you have to compile this. It used to be the case that people would copy and paste command line excerpts (bad habit!), but now they will get a pre-configured "IDE" where they can punch the compile button (ok, but I have met plenty of professionals who never left this stage). Instead, they could avoid the whole thing by using something else, say, Python, or even Javascript. In both cases you can quickly drop to a repl and start trying stuff out. Once the basics are there, then you can proceed to object orientation. And perhaps even to Java as a more advanced course, only you now have the proper concepts to understand the very first line you are supposed to write. Why would universities teach Java and C++ anyway? They are either 'boring' from a computer science perspective, or too convoluted for teaching concepts.
- scarface74 8y ago
  Why would universities teach Java and C++ anyway? They are either 'boring' from a computer science perspective, or too convoluted for teaching concepts. Not a fan of Java by any means, but they should teach Java so graduating students can put that on their resume and get a job so they won't live with their parents until they are 35....
  - _emacsomancer_ 8y ago
    This is presumably why they do teach Java.

quickthrower2 8y ago

I disagree that they should phase out imperative / OO programming, but from my experience more emphasis on different languages i.e. throw in a ML (as in Meta Language) and a Lisp, and most importantly some information about the trade offs. However it would require a culture shift as a university being a place to get you ready for a career in industry rather than academia. Because you are prepping for academia it is OK for them to postpone functional to later years on even the PhD. You mention grief with OO - but I think a lot of it you would get with Functional too and it has more to do with the incentives and people structures in organisations that produce code. Usually praise goes to those who get a 8 hour Jira ticket done in 4, or a 5 week task done in 4 weeks etc, and from the users point of view 'it works'. The structure of the code is not discovered until later. Code reviewers are working at the deckchairs level, they are unable to change the Titanic's direction, and again both parties in a code review have incentive to do it as quick as possible (while not looking like they obviously brushed over it), so it become mostly a potential bug hunting and syntactic cleanup exercise. It's almost a running joke that refactoring rarely gets done, and if it does it is trivial, and usually required some stealth from a developer or manager to create cover to do the refactor. The only hope we have is to work somewhere where there is a good understanding of code quality from top to bottom in the org, or at least when you cross the technical/non-technical boundary there is a high degree of trust to let the tech people do the right thing, and not KPI them into submission.

zackmorris 8y ago
You summed it up nicely. After writing my comment, I realized that imperative programming is so much more difficult than functional programming that in a way, it's the majority of the work of programming. Anyone can learn to use a spreadsheet, but it takes years of dedication to master debugging enterprise software. So there will always be huge demand for that skill, and so colleges should probably continue building it in students. I'm still in mourning though imagining how far programmers could go if they weren't stuck endlessly debugging imperative code that will never be deterministic or free of side effects. Lots of lost potential there. I'm coming up on 3 decades of experience doing that and it feels like well over 90% of the code I've written was a waste of time. I guess it paid the bills though.

laythea 8y ago

"...have logic flows having no obvious connection to one another, or transition through async handlers connected by a convention which isn't immediately obvious to the developer" This is very true. I hate parsing code written like this, or code written using a mashup of concepts, requiring mind gymnastics to fathom an implementation of a solution to a relatively simple problem. It makes the job so much more unnecessarily difficult. Points for simplicity if you ask me.

seanmcdirmid 8y ago
Inverted control is a hallmark of many programming domains. It’s not like you can get the user to be synchronous with respect to the program they are using (unless it is a non interactive batch tool). Even functional paradigms like Rx have control flow running around all over the place, the only saving grace is if you can keep it encapsulates via a set of opaque data flow pipes (and often you can’t).

munchbunny 8y ago

> Honestly I think it might be time to phase out teaching imperative and object-oriented programming. Most of the grief in my career has come from them. I don't care if they're where the jobs are. The mental cost of tracing through highly-imperative code, especially the new implicit style of languages and frameworks like Ruby and AngularJS (which have logic flows having no obvious connection to one another, or transition through async handlers connected by a convention which isn't immediately obvious to the developer) is so high that the underlying business logic is effectively obfuscated. I don't think this is a fault of functional programming as much as it is a fault of implicit language constructs. There are common conventions where being able to chuck functions and closures around is actually useful (e.g. sorting). These language constructs/conventions are useful because they can be extremely expressive, but unfamiliar implicit behaviors cost me much more "working memory" to understand when I'm reading the code. There's a version of object-oriented programming that mostly sticks to declarative behaviors and uses inheritance, unions, mix-ins, etc. to actually hide behavioral abstractions. The problem is that it often takes 5-10 years of experience before the programmer (myself included) begins to appreciate how important future readability of the code is, and to understand that the more exotic language features should be used sparingly.

vmchale 8y ago

> show how spreadsheets and functional programming are equivalent They are not in fact equivalent, unless the functional programming you're doing is trivial.

macspoofing 8y ago

>I think it might be time to phase out teaching imperative and object-oriented programming. Most of the grief in my career has come from them. Good luck. Computer Science degrees are balancing act between practical and theoretical. More importantly students want to work with technologies that are popular in the industry today. You can try to to stand against the tide, but you will lose.

ezoe 8y ago

Real hardware is imperative. Object-oriented programming was once treated like Functional programming. The languages which did implement OOP as it was originally thought was horribly inefficient. So practical languages took the good idea out of OOP for convenient syntax sugars. Functional Programming will follow the same path. You probably don't like it for it will be ended up impure and just some syntax sugar that looks like FP, but rest of the world like it because it gets the job done.

vmchale 8y ago
> Real hardware is imperative. Wrong. > So practical languages took the good idea out of OOP for convenient syntax sugars. Also wrong, unless by "syntactic sugars" you mean "nontrivial compiler rewrites" > Functional Programming will follow the same path. Doubt it. > You probably don't like it for it will be ended up impure Purity does not constrain efficiency at all.
- learc83 8y ago
  >Wrong. At an abstraction level below digital circuits, you are correct. But thankfully the layers on top of that do almost always do a very good job of hiding it. >Doubt it. Functional programming is already following the same path. Sure there will non-hybrid languages around if you want to use them, but take a look at the functional constructs that have made their way into almost every procedural language in use today. Most people have never touched Haskell, but almost everyone has seen a map function. >Purity does not constrain efficiency at all. Maybe not inherently, but there's a reason we have to break out and use mutable data structures when we really need performance. For the systems we are working on today purity does impact performance/efficiency.

mattnewport 8y ago

Could you elaborate on how you came to be programming in C/C++ for 7 or 8 years before encountering a spreadsheet? That seems an unusual path even back in the 90s.

zackmorris 8y ago
Ya I picked up my first programming book when I was 12, then started with HyperCard and Visual Interactive Programming (VIP) on the Mac Plus with my friend (another guy named Zack): https://en.wikipedia.org/wiki/HyperCard https://en.wikipedia.org/wiki/HyperCard http://mstay.com/images/screens/vpc1.gif http://mstay.com/images/screens/vpc1.gif So thought of code as a big flowchart where you fill in the boxes with business logic. Transitioned to C within a year or two and got incredibly deep into assembly language and low level code for blitters back in the 486 era when DOOM came out. Unfortunately moderately priced Macs were an order of magnitude too slow to play fullscreen scrolling games at 640x480x8 resolution until the 60 MHz PowerPC came out in the mid 90s. So never made any real money on Mac shareware games, but I digress. The Mac had an informal programming environment (no console or office suite with standardized inter-application communication) and I hadn't seen MS Access or FileMaker yet, or spreadsheets. When I first encountered them for writing reports in college and it finally clicked for me that code didn't have to be run imperatively, it was devastating in a way. But I made a full recovery in the early 2000s when PHP/MySQL got popular and I was able to get back into rapid application development with ORMs. I feel like the world is about ready to make the jump from hands-on tools like Laravel to WYSIWYG tools like Wix. Most of the attempts I've tried are frankly terrible, but I'm optimistic.
- scroot 8y ago
  If you compare the ease of "authoring" in the top hypermedia environment of its day (Hypercard) with doing the same today (the web) it's plain as day that things have regressed. Here is a straight up comparison someone made if anyone is interested: https://twitter.com/ecgade/status/1029795513514774529 https://twitter.com/ecgade/status/1029795513514774529