5 ms·

I think anyone who has coded long enough would recognize that OOP, functional, imperative, etc all have their strengths and weaknesses, and all have problem dom

by atty 6y ago

I think anyone who has coded long enough would recognize that OOP, functional, imperative, etc all have their strengths and weaknesses, and all have problem domains they are better suited for. Unfortunately, this sometimes gets lost in the language fan wars - it’s easy to lose nuance when discussing something you are passionate about, I have made this mistake myself.

belval 6y ago
I'd go one step further and say that most people should care little about language features when doing an actual production project, as there are aspects such as how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That does not mean having a favorite paradigm or language is useless, of course I love Rust and I find functional programming elegant, but if you are working in a 5 years old app written in C# in a place where no one knows F#, then that should be part of your considerations.
- shaan7 6y ago
  > how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HTML/JS than C#/.NET, Qt/C++ etc. What should be just one of the factors has become the most influencing factor.
  - qsort 6y ago
    I'm all for the 'right tool for the job' mindset, but why would it be bad in principle to write an application in JS? Leaving aside the fact that modern JS is ~3x slower than C++, i.e. slightly slower than C# and Go but in the same league as Java/Haskell, not in the same league as Ruby and Python, programs like VSCode are written in JS and they have no performance issues. It's true that performance is often ignored for no good reason at all, but it's not such a pressing concern for most applications. Very little software needs to be performant to the point that what language it's written in even matters.
    - jcelerier 6y ago
      > programs like VSCode are written in JS and they have no performance issues. here it is compared to qtcreator. it is so damn frustrating when you are used to computers responding near-instantly to have something that... takes its time or stutter to say the least https://vimeo.com/410735827 https://vimeo.com/410735827 https://vimeo.com/410739729 https://vimeo.com/410739729
      - m463 6y ago
        That is interactivity. It thinks along with you. I really dislike having to use microsoft stuff. No, I don't want to install the app. no I don't want to enable what you think I should enable. No I don't want cortana reading my email messages. No I don't want to use your OTHER product too.
      - shaan7 6y ago
        Thank you for recording these <3
    - jamil7 6y ago
      > VSCode are written in JS and they have no performance issues VSCode is not performant, especially on startup and especially when compared to editors like vim or sublime text. I agree that the reason likely isn't language choice though it's the use of electron. I don't agree with you about software not needing to be performant either, I believe developers should strive to make their software run as efficiently as they can.
      - pizza234 6y ago
        > I believe developers should strive to make their software run as efficiently as they can. This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature. Ultimately, it's about balance. Personally I find VSC's performance to be good, and at lot of other devs find it at least good enough (it's a widespread editor). I've actually switched away from ST3 because the development of their current version stagnated, and there are unresolved bugs and limitations that affected my everyday usage. In other words, the performance/features (and let's throw flexibility) balance of VSC is, for me, better than ST's (others may have have different requirements and different balances, of course). Ultimately, VSC is a bad example of tradeoff performance/ease of (internal) development. If people wants to find an example, Slack is by far the best (worst).
  - scarmig 6y ago
    Even if it's suboptimal from a technical standpoint, a company that went all in on an HTML/JS Frankenstein is likely to have seen more success than one that went all in on a more appropriate native desktop client. There's a reason we see a lot of the former and not much of the latter.
    - mattgreenrocks 6y ago
      How do you argue that based on technical choices alone? Seems quite reductive.
      - yowlingcat 6y ago
        It's lowest common denominator thinking, which isn't necessarily wrong. If the majority of cross-platform UI code is done in HTML/JS and the toolchain is mature, that becomes the default choice and you would need a compelling reason to not use it. And that has generally been my anecdotal experience.
  - dcolkitt 6y ago
    I’d agree with this. In my experience, choosing a language/platform based on the teams experience instead of the best tool for the job is a siren song. It’s less pain upfront, but way more amortized pain over the life of the project. Start with good engineers who understand CS fundamentals. After a week or two of immersion, they’re passable in a new language. After a month or two, there’s basically no difference with a veteran. Okay, sure there are exceptions with very different paradigms. Kotlin devs may take more time with low-level memory managed C code. C hackers may struggle with Haskell. But Pythonistas can write pretty good Typescript in their first week. In contrast starting with wrong tool for the job, just gets continuously worse as the project progresses. The friction of constantly cutting against the grain is an accumulated drag. As the project grows more complex, the kludges and workarounds become an increasingly heavy burden on a day-to-day basis.
    - swader999 6y ago
      In agreement and I'd add that I think it is a bit arrogant to assume a more junior programmer or a team of them can't learn better programming practices. A good lead will demand good code and support it with mentoring, pairing and time to refactor. It still doesn't give them license to do tech for the sake of tech. Every architectural choice and added complexity has to be justified by the value it brings. But programming for the lowest common skill level on a team is generally a bad idea.
    - z3t4 6y ago
      You might learn 95% in two months, but the last 5% might take decades. One fun thing is that the less you know the more productive you are. So a good strategy is to leave before you learn how horrible your code is, don't stay longer then two years so you don't have to deal with maintainability, performance, scaleability, security, etc.
      - lolc 6y ago
        If it were any other profession, I would clearly recognize this as satire.
  - z3t4 6y ago
    Actually the programming languages and frameworks are chosen by the buisness owners which have very little dev experience.
shallowthought 6y ago
Part of it is probably that people get defensive concerning anything on which they've spent a large amount of time and effort.
question000 6y ago
Yeah but the question is which one of these types are more "program-y" Functional programming while a valid form, is inherently better expressed by constraining the possible use cases. It's closer to electrical engineering or mechanics then "programming." "Programming" inherently rewards extendability, interoperability and readability, therefore it rewards OOP. Now obviously computers have Both mechanical and extendable use cases so it's up in the air. Stuff that's written better functionally tends to be optimized into oblivion very quickly, it becomes more of a hardware/math/physics problem. But you know that's fun too.
- zelphirkalt 6y ago
  So, you think (mainstream/message passing) OOP is more extensible / readable / interoperable than FP? Have you ever developed any non-trivial program in FP style?
mhh__ 6y ago
I think you're right. When I program I basically think in terms of abstraction and state - if the code is obviously going to be multi-threaded then I will focus on the latter. Being stateful can slow you down on one thread but fuck you hard if it's in multi-threaded environment. Abstraction should really be free if you know what you're doing (in your language if choice I suppose)

by atty 6y ago

belval 6y ago

I'd go one step further and say that most people should care little about language features when doing an actual production project, as there are aspects such as how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That does not mean having a favorite paradigm or language is useless, of course I love Rust and I find functional programming elegant, but if you are working in a 5 years old app written in C# in a place where no one knows F#, then that should be part of your considerations.

shaan7 6y ago
> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important. That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HTML/JS than C#/.NET, Qt/C++ etc. What should be just one of the factors has become the most influencing factor.
- qsort 6y ago
  I'm all for the 'right tool for the job' mindset, but why would it be bad in principle to write an application in JS? Leaving aside the fact that modern JS is ~3x slower than C++, i.e. slightly slower than C# and Go but in the same league as Java/Haskell, not in the same league as Ruby and Python, programs like VSCode are written in JS and they have no performance issues. It's true that performance is often ignored for no good reason at all, but it's not such a pressing concern for most applications. Very little software needs to be performant to the point that what language it's written in even matters.
  - jcelerier 6y ago
    > programs like VSCode are written in JS and they have no performance issues. here it is compared to qtcreator. it is so damn frustrating when you are used to computers responding near-instantly to have something that... takes its time or stutter to say the least https://vimeo.com/410735827 https://vimeo.com/410735827 https://vimeo.com/410739729 https://vimeo.com/410739729
    - m463 6y ago
      That is interactivity. It thinks along with you. I really dislike having to use microsoft stuff. No, I don't want to install the app. no I don't want to enable what you think I should enable. No I don't want cortana reading my email messages. No I don't want to use your OTHER product too.
    - shaan7 6y ago
      Thank you for recording these <3
  - jamil7 6y ago
    > VSCode are written in JS and they have no performance issues VSCode is not performant, especially on startup and especially when compared to editors like vim or sublime text. I agree that the reason likely isn't language choice though it's the use of electron. I don't agree with you about software not needing to be performant either, I believe developers should strive to make their software run as efficiently as they can.
    - pizza234 6y ago
      > I believe developers should strive to make their software run as efficiently as they can. This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature. Ultimately, it's about balance. Personally I find VSC's performance to be good, and at lot of other devs find it at least good enough (it's a widespread editor). I've actually switched away from ST3 because the development of their current version stagnated, and there are unresolved bugs and limitations that affected my everyday usage. In other words, the performance/features (and let's throw flexibility) balance of VSC is, for me, better than ST's (others may have have different requirements and different balances, of course). Ultimately, VSC is a bad example of tradeoff performance/ease of (internal) development. If people wants to find an example, Slack is by far the best (worst).
- scarmig 6y ago
  Even if it's suboptimal from a technical standpoint, a company that went all in on an HTML/JS Frankenstein is likely to have seen more success than one that went all in on a more appropriate native desktop client. There's a reason we see a lot of the former and not much of the latter.
  - mattgreenrocks 6y ago
    How do you argue that based on technical choices alone? Seems quite reductive.
    - yowlingcat 6y ago
      It's lowest common denominator thinking, which isn't necessarily wrong. If the majority of cross-platform UI code is done in HTML/JS and the toolchain is mature, that becomes the default choice and you would need a compelling reason to not use it. And that has generally been my anecdotal experience.
- dcolkitt 6y ago
  I’d agree with this. In my experience, choosing a language/platform based on the teams experience instead of the best tool for the job is a siren song. It’s less pain upfront, but way more amortized pain over the life of the project. Start with good engineers who understand CS fundamentals. After a week or two of immersion, they’re passable in a new language. After a month or two, there’s basically no difference with a veteran. Okay, sure there are exceptions with very different paradigms. Kotlin devs may take more time with low-level memory managed C code. C hackers may struggle with Haskell. But Pythonistas can write pretty good Typescript in their first week. In contrast starting with wrong tool for the job, just gets continuously worse as the project progresses. The friction of constantly cutting against the grain is an accumulated drag. As the project grows more complex, the kludges and workarounds become an increasingly heavy burden on a day-to-day basis.
  - swader999 6y ago
    In agreement and I'd add that I think it is a bit arrogant to assume a more junior programmer or a team of them can't learn better programming practices. A good lead will demand good code and support it with mentoring, pairing and time to refactor. It still doesn't give them license to do tech for the sake of tech. Every architectural choice and added complexity has to be justified by the value it brings. But programming for the lowest common skill level on a team is generally a bad idea.
  - z3t4 6y ago
    You might learn 95% in two months, but the last 5% might take decades. One fun thing is that the less you know the more productive you are. So a good strategy is to leave before you learn how horrible your code is, don't stay longer then two years so you don't have to deal with maintainability, performance, scaleability, security, etc.
    - lolc 6y ago
      If it were any other profession, I would clearly recognize this as satire.
- z3t4 6y ago
  Actually the programming languages and frameworks are chosen by the buisness owners which have very little dev experience.

shallowthought 6y ago

Part of it is probably that people get defensive concerning anything on which they've spent a large amount of time and effort.

question000 6y ago

Yeah but the question is which one of these types are more "program-y" Functional programming while a valid form, is inherently better expressed by constraining the possible use cases. It's closer to electrical engineering or mechanics then "programming." "Programming" inherently rewards extendability, interoperability and readability, therefore it rewards OOP. Now obviously computers have Both mechanical and extendable use cases so it's up in the air. Stuff that's written better functionally tends to be optimized into oblivion very quickly, it becomes more of a hardware/math/physics problem. But you know that's fun too.

zelphirkalt 6y ago
So, you think (mainstream/message passing) OOP is more extensible / readable / interoperable than FP? Have you ever developed any non-trivial program in FP style?

mhh__ 6y ago

I think you're right. When I program I basically think in terms of abstraction and state - if the code is obviously going to be multi-threaded then I will focus on the latter. Being stateful can slow you down on one thread but fuck you hard if it's in multi-threaded environment. Abstraction should really be free if you know what you're doing (in your language if choice I suppose)