5 ms·

1.With “von Neumann style” you are closer to the metal. 2.With "declarative", (e.g. SQL) you're preparing input data -NOT describing an algorithm- for a runtim

by lucio 11y ago

1.With “von Neumann style” you are closer to the metal. 2.With "declarative", (e.g. SQL) you're preparing input data -NOT describing an algorithm- for a runtime or a compiler or a server, which in turns will run “von Neumann style” algorithms composed from your declarations. If you need to optimize the last drop of resource usage and speed you use 1).

nickpsecurity 11y ago
Maybe. There were LISP machines developed that did all that natively. The metal was a high-level language of incredible power with good implementations doing low-cost abstractions via macros. Almost all investment went to the other architectures for sheer price/performance and backward compatibility. Reliability, maintenance, integration of 3rd party code, security, etc weren't a concern at all. Now they are: even mainstream is tossing much of the old stuff where possible. Your same argument might have worked in reverse had several billion dollars of engineering gone into hardware designed to implement ML, Scheme, Haskell, and so on. Besides, there's little debate to be had on what's the best model: all of these are built on hardware that's interacting functional programs (combinatorial logic) and finite state machines (sequential logic). How they're combined varies on a chip by chip basis. Underneath, though, everything boils down to a careful combination of functional and semi-functional programming implemented in silicon. Except analog which is purely functional. ;) Note: This brings out another angle whereby we use tens of thousands to billions of circuits running concurrently in a functional way to simulate a sequential, imperative machine that does way less in a clock cycle. This is why porting the algorithms onto FPGA's almost always has significant speed-up unless the imperative machine is insanely optimized (i.e. Intel/AMD/IBM). It's also why even prototypes like SHard produce efficient, better-than-generic hardware from functional language specifications of algorithms. Maybe we should just go functional all the way and invest money into CPU's which do that with utmost efficiency, eh?
- 0xdeadbeefbabe 11y ago
  > Besides, there's little debate to be had on what's the best model. Are you saying there is no debate that functional is the best model because that is what is going on in the hardware? I haven't heard that point of view before. Does Knuth's use of MIX in the AOCP mean he doesn't share that view or does it mean something else?
  - nickpsecurity 11y ago
    I'm saying it's a path worth exploring. The research on LISP machines, synthesis, splitting of apps between CPU and FPGA's... all this showed functional approach got the job done better with less hardware and the well-known software benefits. Even the workhorse instructions of the imperative processors operate in a functional way when you look at how the processors actually work. There's so much overhead in supporting the illusion of sequential, imperative programming that it might be better spent utilizing hardware to support concurrent, functional programming more efficiently.
- lucio 11y ago
  I do not see LISP as "declarative". I see LISP as recursive+immutable but “von Neumann style” on the end. LISP is not declarative, I think.
  - nickpsecurity 11y ago
    I mostly agree with you. I'm using it in the sense that functional programming is closer to declarative programming in saying what must be done and letting the compiler/hardware do it. LISP also easily implements true, declarative programming. It also does a form of it with some domain-specific languages. So, it seems like one of the best compromises. I recall doing automatic programming research long ago. We got to the 4GL's that automated much of what you want. There were even programs that took requirements put into CASE tools and synthesized simple code to meet them. Eventually we found that we'd have to precisely specify behavior, requirements, and constraints w/ heuristics-driven tools synthesizing the system. Probably led to concept for 5GL's being constraint-programming. In any case, if you look at all of that, functional programming or 4GL combined with a formal specification language + good QA tools are MUCH EASIER. One person told me you'd have to think like a lawyer to do English precise enough declare an app into existence. While there's even non-technical people cranking out working, readable code in Python and Ocaml. Cleanroom's restrictive method got similar quality out of languages not known for it. I think combining approaches like that is better than declarative approach for the general case w/ DSL's (in LISP etc) being used for declarative programming of specific components (GUI's, database integration). The constraints and heuristics mean you're always doing more work than mere declarative programming outside simple stuff like SQL.

by lucio 11y ago

nickpsecurity 11y ago

Maybe. There were LISP machines developed that did all that natively. The metal was a high-level language of incredible power with good implementations doing low-cost abstractions via macros. Almost all investment went to the other architectures for sheer price/performance and backward compatibility. Reliability, maintenance, integration of 3rd party code, security, etc weren't a concern at all. Now they are: even mainstream is tossing much of the old stuff where possible. Your same argument might have worked in reverse had several billion dollars of engineering gone into hardware designed to implement ML, Scheme, Haskell, and so on. Besides, there's little debate to be had on what's the best model: all of these are built on hardware that's interacting functional programs (combinatorial logic) and finite state machines (sequential logic). How they're combined varies on a chip by chip basis. Underneath, though, everything boils down to a careful combination of functional and semi-functional programming implemented in silicon. Except analog which is purely functional. ;) Note: This brings out another angle whereby we use tens of thousands to billions of circuits running concurrently in a functional way to simulate a sequential, imperative machine that does way less in a clock cycle. This is why porting the algorithms onto FPGA's almost always has significant speed-up unless the imperative machine is insanely optimized (i.e. Intel/AMD/IBM). It's also why even prototypes like SHard produce efficient, better-than-generic hardware from functional language specifications of algorithms. Maybe we should just go functional all the way and invest money into CPU's which do that with utmost efficiency, eh?

0xdeadbeefbabe 11y ago
> Besides, there's little debate to be had on what's the best model. Are you saying there is no debate that functional is the best model because that is what is going on in the hardware? I haven't heard that point of view before. Does Knuth's use of MIX in the AOCP mean he doesn't share that view or does it mean something else?
- nickpsecurity 11y ago
  I'm saying it's a path worth exploring. The research on LISP machines, synthesis, splitting of apps between CPU and FPGA's... all this showed functional approach got the job done better with less hardware and the well-known software benefits. Even the workhorse instructions of the imperative processors operate in a functional way when you look at how the processors actually work. There's so much overhead in supporting the illusion of sequential, imperative programming that it might be better spent utilizing hardware to support concurrent, functional programming more efficiently.
lucio 11y ago
I do not see LISP as "declarative". I see LISP as recursive+immutable but “von Neumann style” on the end. LISP is not declarative, I think.
- nickpsecurity 11y ago
  I mostly agree with you. I'm using it in the sense that functional programming is closer to declarative programming in saying what must be done and letting the compiler/hardware do it. LISP also easily implements true, declarative programming. It also does a form of it with some domain-specific languages. So, it seems like one of the best compromises. I recall doing automatic programming research long ago. We got to the 4GL's that automated much of what you want. There were even programs that took requirements put into CASE tools and synthesized simple code to meet them. Eventually we found that we'd have to precisely specify behavior, requirements, and constraints w/ heuristics-driven tools synthesizing the system. Probably led to concept for 5GL's being constraint-programming. In any case, if you look at all of that, functional programming or 4GL combined with a formal specification language + good QA tools are MUCH EASIER. One person told me you'd have to think like a lawyer to do English precise enough declare an app into existence. While there's even non-technical people cranking out working, readable code in Python and Ocaml. Cleanroom's restrictive method got similar quality out of languages not known for it. I think combining approaches like that is better than declarative approach for the general case w/ DSL's (in LISP etc) being used for declarative programming of specific components (GUI's, database integration). The constraints and heuristics mean you're always doing more work than mere declarative programming outside simple stuff like SQL.