6 ms·

Procedural programming was never abandoned, it just doesn't have a hype machine around it. How much software is written in plain C which is neither OO nor funct

Procedural programming was never abandoned, it just doesn't have a hype machine around it. How much software is written in plain C which is neither OO nor functional?

pmarreck 6y ago
It is perfectly possible to use a functional style in an OO/procedural language, as John Carmack demonstrates below. You just lose the guarantees (which is a steep cost IMHO) https://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php https://www.gamasutra.com/view/news/169296/Indepth_Functiona...
- zackees 6y ago
  One of the main reasons why OOP is popular is not even talked about - the ability for AUTOCOMPLETE in the IDE to work extremely well. For example, I have an object... what do I do with it? So I hit the '.' on my keyboard and read the list of things that the object can do. This is why OOP is popular, it allows better tooling. If people want to move beyond OOP then they need to think about how the new style integrates with the IDE so that the programmer can hit the '.' or equivalent and get a list of useful things to do with the object in question.
  - kqr 6y ago
    This is a common idea but I'm skeptical it's that simple. Haskell has a powerful enough type system that it can enable "hole-driven development" where you specify the type of your code and then leave a "hole" in the implementation -- anywhere in the implementation, including making the entire implementation a hole! -- and the tools can suggest what should go in the hole, leaving new holes in the code. Then you can incrementally resolve smaller and smaller holes based on the suggestions you get, and finally you have a completely tool-written program, where you just helped disambiguate when you had to. This is the '.' on steroids. Haskell is not popular.
    - vkou 6y ago
      Haskell is weighed down with the problem that by the time I'm five pages into a "Haskell is actually easy, and let me show you how" tutorial, the average reader's eyes glaze over thanks to passages like: "While >>= and return are the basic monadic sequencing operations, we also need some monadic primitives. A monadic primitive is simply an operation that uses the insides of the monad abstraction and taps into the `wheels and gears' that make the monad work. For example, in the IO monad, operators such as putChar are primitive since they deal with the inner workings of the IO monad. Similarly, our state monad uses two primitives: readSM and updateSM. Note that these depend on the inner structure of the monad..." Or, possibly because when I make a post on Hacker News about how difficult it is to implement Quicksort in Haskell, the first response is a four-line Haskell implementation of Quicksort, spawning a 50-post subthread which points out that it's not actually an implementation of Quicksort, because it does not have the same performance characteristics as Quicksort, and instead has the performance characteristics of a lethargic water buffalo. By the end of the thread, the question of whether it is possible to write a Quicksort in Haskell that has the performance characteristics of Quicksort is left as an open research question.
      - microtherion 6y ago
        Instead of downvoting the parent, Haskell devotees would do well to recognize that this is a pretty good representation of the hurdle that would-be recruits to Haskell face.
      - kv_hrishikesh 6y ago
        There is a reason why Haskell is not popular. But I don't think the impenetrable passages about Monads are the reason behind it. It is more about what you gain by adopting Haskell and powering through the impenetrable passages. If it is not blazing fast runtime performance and fast speed of development and maintainable code, then Haskell is pointless. As such, if there are those kind of benefits available, there is plenty of extra brainpower available among developers to comprehend passages.
    - Der_Einzige 6y ago
      Haskell is popular in universities, fintech companies, and among the FP crowed at large. Many programmers know of it's benefits and simply avoid it because FP is very difficult for many to code in and Haskell is trying to be FP only...
  - dunefox 6y ago
    > One of the main reasons why OOP is popular is not even talked about - the ability for AUTOCOMPLETE in the IDE to work extremely well. That's just dot-syntax and modules. That has nothing to do with OOP itself. Nothing is keeping you from doing that in functional languages that support proper modules.
  - overgard 6y ago
    Well generally speaking you're just describing a search problem: I have this data, what operations can I perform on it? Hypothetically you could do something like if I type a keycode after a variable it lists functions that can be run on it. Its just a tooling thing not really a language design thing.
    - iainmerrick 6y ago
      But their point is -- and I agree! -- that with unfashionable OO languages there’s nothing hypothetical about it, it’s completely mainstream. All the IDEs have done this for years and it works extremely well.
  - simongray 6y ago
    > I have an object... what do I do with it? So I hit the '.' on my keyboard and read the list of things that the object can do. As a counterpoint (relevant Rich Hickey rant): https://www.youtube.com/watch?v=aSEQfqNYNAc https://www.youtube.com/watch?v=aSEQfqNYNAc
    - onemoresoop 6y ago
      I have a counterpoint. OOP made simple things way too complicated and that resulted in more jobs in software development. Its the sad truth. Or the happy one, depending on which side of the fence one is.
    - oftenwrong 6y ago
      The poor design of that class aside, I would rather have the specific version rather than the unspecified version. If I have a HttpServletRequest somewhere in my code, I have a good idea of its structure just by knowing its type. The same cannot be said of a blob of maps and lists.
      - simongray 6y ago
        > If I have a HttpServletRequest somewhere in my code, I have a good idea of its structure just by knowing its type. The same cannot be said of a blob of maps and lists. Non-trivial data structures are always conformed to some specification, doesn't matter if its Clojure or an OOP-language. If you receive an HTTP request over the wire you will have to check it. Once you conform it to the specification you know exactly how it looks and there's no need to jump through hoops to access the information.
        kqr 6y ago
        But with proper static typing you don't have to check it because you already know it's correct since it's construction. It relieves a lot of mental burden for me to not even have to consider the case that it might be incorrect, as long as I'm dealing with structures internal to my program. I have a lot of respect for Rich Hickey and I feel like he Understands something that goes straight over my head, but his appreciation for generic, shapeless maps and lists is something I just don't get.
deleted 6y ago
[deleted]
commandlinefan 6y ago
> How much software is written in plain C which is neither OO And I would assert that every maintainable C program is fundamentally designed in a relatively object-oriented way (functions that operated on structured, polymorphic function pointers, etc.) even if the original author wasn't particularly thinking in terms of classes or inheritance. C programs aren't functional because C isn't functional (no inherent concept of closures), but Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" usually applies.
- oivey 6y ago
  I don’t think it is correct to say that those things are OO because they predate the concept and are used in many paradigms. When I think of OO I think of strict encapsulation (via private), complex inheritance, methods bound and defined in classes, single dispatch, etc.
  - ferzul 6y ago
    so languages like self and javascript which, even in the modern forms, have no real classes are not oo to you? i mean, the fact that you can use class style syntax do define object constructors in javascript and tho result is fairly coherent, seems to suggest that classes are not inherent to oo. also, the fact that it's called “object oriented” not “classical”. other examples of non-oo with strict encapsulation includes haskell, where if you lack the constructor, you can only use it according to the public api. it also uses single dispatch for typeclasses. complex inheritance rare in oo - mostly only single inheritance is supported - and most oo design advocates pretty much say “don't use inheritance”. so it doesn't seem like it's intrinsic.
- phkahler 6y ago
  >> C programs aren't functional because C isn't functional (no inherent concept of closures) You don't need closures to do functional programming. I was recently tinkering in some C++ code and thought "this part should be able to run in parallel." It was simply doing the same operation of a list of objects. It's a complex operation involving some temporary data structures. I had to dig through several layers of functions, but I kept finding that all data was created locally. Functions that returned complex result are passed a class to fill out. It was then that I realized it was written in a functional style - or at least my limited understanding of what that means. The top level function is now run in parallel, which required no changes beneath that level. Now I prefer that style but like TFA here, I don't think 100 percent functional is a good idea.

Procedural programming was never abandoned, it just doesn't have a hype machine around it. How much software is written in plain C which is neither OO nor functional?

pmarreck 6y ago

It is perfectly possible to use a functional style in an OO/procedural language, as John Carmack demonstrates below. You just lose the guarantees (which is a steep cost IMHO) https://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php https://www.gamasutra.com/view/news/169296/Indepth_Functiona...

zackees 6y ago
One of the main reasons why OOP is popular is not even talked about - the ability for AUTOCOMPLETE in the IDE to work extremely well. For example, I have an object... what do I do with it? So I hit the '.' on my keyboard and read the list of things that the object can do. This is why OOP is popular, it allows better tooling. If people want to move beyond OOP then they need to think about how the new style integrates with the IDE so that the programmer can hit the '.' or equivalent and get a list of useful things to do with the object in question.
- kqr 6y ago
  This is a common idea but I'm skeptical it's that simple. Haskell has a powerful enough type system that it can enable "hole-driven development" where you specify the type of your code and then leave a "hole" in the implementation -- anywhere in the implementation, including making the entire implementation a hole! -- and the tools can suggest what should go in the hole, leaving new holes in the code. Then you can incrementally resolve smaller and smaller holes based on the suggestions you get, and finally you have a completely tool-written program, where you just helped disambiguate when you had to. This is the '.' on steroids. Haskell is not popular.
  - vkou 6y ago
    Haskell is weighed down with the problem that by the time I'm five pages into a "Haskell is actually easy, and let me show you how" tutorial, the average reader's eyes glaze over thanks to passages like: "While >>= and return are the basic monadic sequencing operations, we also need some monadic primitives. A monadic primitive is simply an operation that uses the insides of the monad abstraction and taps into the `wheels and gears' that make the monad work. For example, in the IO monad, operators such as putChar are primitive since they deal with the inner workings of the IO monad. Similarly, our state monad uses two primitives: readSM and updateSM. Note that these depend on the inner structure of the monad..." Or, possibly because when I make a post on Hacker News about how difficult it is to implement Quicksort in Haskell, the first response is a four-line Haskell implementation of Quicksort, spawning a 50-post subthread which points out that it's not actually an implementation of Quicksort, because it does not have the same performance characteristics as Quicksort, and instead has the performance characteristics of a lethargic water buffalo. By the end of the thread, the question of whether it is possible to write a Quicksort in Haskell that has the performance characteristics of Quicksort is left as an open research question.
    - microtherion 6y ago
      Instead of downvoting the parent, Haskell devotees would do well to recognize that this is a pretty good representation of the hurdle that would-be recruits to Haskell face.
    - kv_hrishikesh 6y ago
      There is a reason why Haskell is not popular. But I don't think the impenetrable passages about Monads are the reason behind it. It is more about what you gain by adopting Haskell and powering through the impenetrable passages. If it is not blazing fast runtime performance and fast speed of development and maintainable code, then Haskell is pointless. As such, if there are those kind of benefits available, there is plenty of extra brainpower available among developers to comprehend passages.
  - Der_Einzige 6y ago
    Haskell is popular in universities, fintech companies, and among the FP crowed at large. Many programmers know of it's benefits and simply avoid it because FP is very difficult for many to code in and Haskell is trying to be FP only...
- dunefox 6y ago
  > One of the main reasons why OOP is popular is not even talked about - the ability for AUTOCOMPLETE in the IDE to work extremely well. That's just dot-syntax and modules. That has nothing to do with OOP itself. Nothing is keeping you from doing that in functional languages that support proper modules.
- overgard 6y ago
  Well generally speaking you're just describing a search problem: I have this data, what operations can I perform on it? Hypothetically you could do something like if I type a keycode after a variable it lists functions that can be run on it. Its just a tooling thing not really a language design thing.
  - iainmerrick 6y ago
    But their point is -- and I agree! -- that with unfashionable OO languages there’s nothing hypothetical about it, it’s completely mainstream. All the IDEs have done this for years and it works extremely well.
- simongray 6y ago
  > I have an object... what do I do with it? So I hit the '.' on my keyboard and read the list of things that the object can do. As a counterpoint (relevant Rich Hickey rant): https://www.youtube.com/watch?v=aSEQfqNYNAc https://www.youtube.com/watch?v=aSEQfqNYNAc
  - onemoresoop 6y ago
    I have a counterpoint. OOP made simple things way too complicated and that resulted in more jobs in software development. Its the sad truth. Or the happy one, depending on which side of the fence one is.
  - oftenwrong 6y ago
    The poor design of that class aside, I would rather have the specific version rather than the unspecified version. If I have a HttpServletRequest somewhere in my code, I have a good idea of its structure just by knowing its type. The same cannot be said of a blob of maps and lists.
    - simongray 6y ago
      > If I have a HttpServletRequest somewhere in my code, I have a good idea of its structure just by knowing its type. The same cannot be said of a blob of maps and lists. Non-trivial data structures are always conformed to some specification, doesn't matter if its Clojure or an OOP-language. If you receive an HTTP request over the wire you will have to check it. Once you conform it to the specification you know exactly how it looks and there's no need to jump through hoops to access the information.
      - kqr 6y ago
        But with proper static typing you don't have to check it because you already know it's correct since it's construction. It relieves a lot of mental burden for me to not even have to consider the case that it might be incorrect, as long as I'm dealing with structures internal to my program. I have a lot of respect for Rich Hickey and I feel like he Understands something that goes straight over my head, but his appreciation for generic, shapeless maps and lists is something I just don't get.

deleted 6y ago

[deleted]

commandlinefan 6y ago

> How much software is written in plain C which is neither OO And I would assert that every maintainable C program is fundamentally designed in a relatively object-oriented way (functions that operated on structured, polymorphic function pointers, etc.) even if the original author wasn't particularly thinking in terms of classes or inheritance. C programs aren't functional because C isn't functional (no inherent concept of closures), but Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" usually applies.

oivey 6y ago
I don’t think it is correct to say that those things are OO because they predate the concept and are used in many paradigms. When I think of OO I think of strict encapsulation (via private), complex inheritance, methods bound and defined in classes, single dispatch, etc.
- ferzul 6y ago
  so languages like self and javascript which, even in the modern forms, have no real classes are not oo to you? i mean, the fact that you can use class style syntax do define object constructors in javascript and tho result is fairly coherent, seems to suggest that classes are not inherent to oo. also, the fact that it's called “object oriented” not “classical”. other examples of non-oo with strict encapsulation includes haskell, where if you lack the constructor, you can only use it according to the public api. it also uses single dispatch for typeclasses. complex inheritance rare in oo - mostly only single inheritance is supported - and most oo design advocates pretty much say “don't use inheritance”. so it doesn't seem like it's intrinsic.
phkahler 6y ago
>> C programs aren't functional because C isn't functional (no inherent concept of closures) You don't need closures to do functional programming. I was recently tinkering in some C++ code and thought "this part should be able to run in parallel." It was simply doing the same operation of a list of objects. It's a complex operation involving some temporary data structures. I had to dig through several layers of functions, but I kept finding that all data was created locally. Functions that returned complex result are passed a class to fill out. It was then that I realized it was written in a functional style - or at least my limited understanding of what that means. The top level function is now run in parallel, which required no changes beneath that level. Now I prefer that style but like TFA here, I don't think 100 percent functional is a good idea.