4 ms·

Couple of really nice things about F#: - It's multi-paradigm. If you just gotta have classes? Go make some. But if you want to learn and take your game to the

Couple of really nice things about F#: - It's multi-paradigm. If you just gotta have classes? Go make some. But if you want to learn and take your game to the next level, you'll soon ditch a lot of them. F# means you can move from OO to (mostly) pure FP without having to change languages or stacks. - You can plug in stuff made in all the other .NET languages. There's a ton of stuff out there that you can just pick up and use. I like F# because the more I use it, the better I get. I know I don't want classes, for loops, mutable state, and the rest -- but sometimes I just can't see how to get around them. So I throw them in there, get the code to work. Then I go back and figure out where I went wrong. Those "going back" moments are like miniature programming lessons tailored just for the things I don't understand well. Very cool.

graycat 11y ago
> But if you want to learn and take your game to the next level, you'll soon ditch a lot of them. "Next level"? Sorry, I don't believe it. All I see is more programming style, and that is no more significant for something better than some new Paris designer dress style. Functional programming style? Not interested. Showing that P = NP? Sure, interested!
- DanielBMarkham 11y ago
  Perhaps I didn't state that well. I'll try again. I know what good OO looks like. I can apply SOLID and a lot of other techniques to make my class graph "correct". When I'm done, I have a well-decomposed mostly-isomorphic view of the problem domain (usually along with a lot of "helper" stuff thrown in.) If you know how good OO looks, and you look at your classes and they don't look that way? You can learn a lot by continuing to clean them up. Same goes for FP. But currying, partial application, and composition allows for a huge amount of code reduction (and corresponding better problem understanding) than OO. So as you "clean up" your functional code, you're learning much better refactoring skills than you ever would with OO. It's not surprising. OO is mainly concerned with where things go. Learn you some OO and you know where to put stuff. FP is mainly concerned with what things do. Learn you some FP and you'll learn how to make the computer do more with less code. Less code generally means less bugs and easier maintenance, but we can save that for another day. The point of my original post is that F# can let you learn both ways -- and move from OO to FP in an incremental, self-directed fashion. That's pretty cool.
- lsadam0 11y ago
  I'm not seeing your point. Your posts I have read thus far are arguing for a specific programming style....but you dismiss all other programming styles. Your style is just another 'paris designer dress'. Objectively, certain styles have distinct advantages over others. Your argument comes across as "Broadband? Why would I need broadband? I have a perfectly fine dial-up modem!". I'm trying to say this as nice as possible: You come across as a person who is against learning any new concepts. As if you learned one thing many years ago and refuse to change.
  - deleted 11y ago
    [deleted]
    - lsadam0 11y ago
      Apologies, there's some confusion here. I was attempting to direct my reply to Graycat, and not you. Throughout the thread Graycat has been singing the praises of VB.Net while dismissing most other languages and styles. It's a curious position, I'm interested in his justification. Edit: Unless you are Graycat & DanielBMarkham :)
  - graycat 11y ago
    I learn new stuff right along. Just now I'm trying to get my startup live so am cutting back on learning new stuff, but I have several lifetimes of new stuff I'm eager to learn. I've learned lots of new stuff in computing and in programming languages. But, by now, in programming languages, mostly I give up -- structured programming, object oriented programming, logic programming, rule based programming, functional programming, programming based on actors, threaded, stack based programming, frame based programming, strongly typed programming, programming based on communicating sequential processes, literate programming -- because the tools are, net, not better. For some progress, it would be good to be able to have some proofs of correctness. I looked at that field, and it's hopeless: First problem, the proofs are too long and hard to do, e.g., have some astounding collection of induction arguments. Second, with programming language side effects, etc., have to assume away a lot of possibilities for errors. Third, a proof needs some hypotheses and conclusions, that is, givens and results, and for realistic software those two are too difficult to have in precise terms. E.g., for realistic software, it's just too tough to describe in principle, as needed for a solid proof, all the possible inputs and what should be done for all the cases. So, attention to proofs of correctness mostly went away. Net, in my programming, for progress in having the software simple, efficient, easy to understand, easy to write, debug, and change, my approach is just good conceptual design, documentation, and use of the basic tools in VB .NET. I'm no longer looking for such progress via programming language syntax, semantics, constructs, or features.

graycat 11y ago

> But if you want to learn and take your game to the next level, you'll soon ditch a lot of them. "Next level"? Sorry, I don't believe it. All I see is more programming style, and that is no more significant for something better than some new Paris designer dress style. Functional programming style? Not interested. Showing that P = NP? Sure, interested!

DanielBMarkham 11y ago
Perhaps I didn't state that well. I'll try again. I know what good OO looks like. I can apply SOLID and a lot of other techniques to make my class graph "correct". When I'm done, I have a well-decomposed mostly-isomorphic view of the problem domain (usually along with a lot of "helper" stuff thrown in.) If you know how good OO looks, and you look at your classes and they don't look that way? You can learn a lot by continuing to clean them up. Same goes for FP. But currying, partial application, and composition allows for a huge amount of code reduction (and corresponding better problem understanding) than OO. So as you "clean up" your functional code, you're learning much better refactoring skills than you ever would with OO. It's not surprising. OO is mainly concerned with where things go. Learn you some OO and you know where to put stuff. FP is mainly concerned with what things do. Learn you some FP and you'll learn how to make the computer do more with less code. Less code generally means less bugs and easier maintenance, but we can save that for another day. The point of my original post is that F# can let you learn both ways -- and move from OO to FP in an incremental, self-directed fashion. That's pretty cool.
lsadam0 11y ago
I'm not seeing your point. Your posts I have read thus far are arguing for a specific programming style....but you dismiss all other programming styles. Your style is just another 'paris designer dress'. Objectively, certain styles have distinct advantages over others. Your argument comes across as "Broadband? Why would I need broadband? I have a perfectly fine dial-up modem!". I'm trying to say this as nice as possible: You come across as a person who is against learning any new concepts. As if you learned one thing many years ago and refuse to change.
- deleted 11y ago
  [deleted]
  - lsadam0 11y ago
    Apologies, there's some confusion here. I was attempting to direct my reply to Graycat, and not you. Throughout the thread Graycat has been singing the praises of VB.Net while dismissing most other languages and styles. It's a curious position, I'm interested in his justification. Edit: Unless you are Graycat & DanielBMarkham :)
- graycat 11y ago
  I learn new stuff right along. Just now I'm trying to get my startup live so am cutting back on learning new stuff, but I have several lifetimes of new stuff I'm eager to learn. I've learned lots of new stuff in computing and in programming languages. But, by now, in programming languages, mostly I give up -- structured programming, object oriented programming, logic programming, rule based programming, functional programming, programming based on actors, threaded, stack based programming, frame based programming, strongly typed programming, programming based on communicating sequential processes, literate programming -- because the tools are, net, not better. For some progress, it would be good to be able to have some proofs of correctness. I looked at that field, and it's hopeless: First problem, the proofs are too long and hard to do, e.g., have some astounding collection of induction arguments. Second, with programming language side effects, etc., have to assume away a lot of possibilities for errors. Third, a proof needs some hypotheses and conclusions, that is, givens and results, and for realistic software those two are too difficult to have in precise terms. E.g., for realistic software, it's just too tough to describe in principle, as needed for a solid proof, all the possible inputs and what should be done for all the cases. So, attention to proofs of correctness mostly went away. Net, in my programming, for progress in having the software simple, efficient, easy to understand, easy to write, debug, and change, my approach is just good conceptual design, documentation, and use of the basic tools in VB .NET. I'm no longer looking for such progress via programming language syntax, semantics, constructs, or features.