5 ms·

I think F# just fits the way he thinks really well. I have that same sort of Zen experience when I code in Ruby. Ruby's object model sets like firmament in my m

I think F# just fits the way he thinks really well. I have that same sort of Zen experience when I code in Ruby. Ruby's object model sets like firmament in my mind and allows me to think about blobs of Ruby code in a discrete rather than a continuous fashion. Which is what I think the author is getting at with his praise. Abstraction verbosity golfed down to a minimum. I couldn't even imagine giving up Ruby's elegant object model for the verbosity of a static typing system. So when people tell me that Ruby or Rails is magical, I'm like, yeah, in a good way. But the arcane correspondences just aren't very accessible. If I want a functional programming model, I just code one up out of the basic building blocks of ruby. If I want a type system, I can make one.

chrischattin 8y ago
I get the same feeling when programming in Ruby and it seems like the entire community appreciates the same ascetic. I just love working with Rails. Matz took a unique approach when he decided to optimize for programmer happiness vs the machine and it turned out awesome.
melling 8y ago
Don’t languages like F# remove much of the verbosity of a type system? In fact, we’re finally loving away from that verbosity in general. Swift, for example, lets me write declarations like this: var done = false let language = “russian” let languages = [“english”, “french”, “german”, “russian”] let dictionary = [1:"english", 2:"french", 3:"german", 4:"russian"] The types are implied. The use of ‘let’ means immutable. I believe F# goes even farther but the verbose typing of a generation ago is almost gone.
- wenc 8y ago
  This. Static typing doesn't mean tedium in modern languages. In Java and old C#, you would write stuff like this: int x = 1; BigOldClass y = new BigOldClass() Dictionary<int, List<string>> z = new Dictionary<int, List<string>>(); int[] p = new int[] {1, 2, 3}; In modern C#, you can write cleaner code like this: var x = 1; // type is inferred var y = new BigOldClass(); // syntactic sugar to avoid repetition var z = new Dictionary<int, List<string>>(); var p = new [] {1, 2, 3}; Still strongly, statically typed, and obviously typed.
  - gbear605 8y ago
    This is also true in Java now
    - ma2rten 8y ago
      C++ also has auto now.
    - arwhatever 8y ago
      Function types don't need signatures in Java?
  - nbevans 8y ago
    I, as a F#'er, would argue that lines 2 and 3 of the C# snippet there is not an example of type inference. But I realise this is not a mainstream opinion so please don't downvote me :)
    - wenc 8y ago
      No, I don't think I meant to say all the lines were type-inferred. The type inference only happens on the 1st and 4th lines. In 2 and 3 the types were explicit. All lines however are statically typed.
      - barrkel 8y ago
        The type is inferred on all 4 lines and the mechanism is little different; the 4th line is the most complex one, because there's a type unification required across all elements of the array, but C# and Java and other languages with overloading already need to do very similar inference with the ternary operator - the types on each side of the branch need to be unified to resolve the overload. Hindley-Milner type inference (like used in F#) isn't hugely more complex; it's more aggressive at using type variables to generalize the code, and applies type unification in more situations.
  - gameswithgo 8y ago
    right, most languages do this now. But F# extends that further. Function signatures don't need types either. Record types can be inferred from their field names. If you write a function with no type signatures it is automatically made generic, as well. So you can often write large chunks of code with no specified types, but everything is still statically typed. Granted this is maybe not always good, sometimes it is productive to have types in the function signatures, though the IDE can supply these automatically with codelens featuers/on hover features.
- gameswithgo 8y ago
  yes, type inference is pretty comprehensive, function signatures don't usually need them even.
- gchadwick 8y ago
  > verbose typing of a generation ago is almost gone Worth pointing out such type inference is hardly a new idea e.g. see the ML type system: https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) which Wikipedia says first appeared in 1973. This actually traces its roots to the typed lambda calculus which predates electronic computers. However I think it is fair to say that type inference systems are finally appearing in more 'mainstream' statically typed languages (for example the auto keyword in C++ and your Swift examples).
  - melling 8y ago
    Yes, immutability, pattern matching, type inference, etc are not new ideas. Pattern matching is another concept that’s making its way into popular programming. https://www.bignerdranch.com/blog/pro-pattern-matching-in-swift/ https://www.bignerdranch.com/blog/pro-pattern-matching-in-sw... https://stackoverflow.com/questions/2502354/what-is-pattern-matching-in-functional-languages https://stackoverflow.com/questions/2502354/what-is-pattern-... C# and Java are also adding this feature. We’re taking the long way to becoming Haskell and oCaml programmers.
  - brianberns 8y ago
    F# comes from ML by way of OCaml.
brightball 8y ago
It's probably a little multifaceted. I'm a fan of Ruby but even Ruby develops warts with a code base that's too large. I was just about ready to exit programming entirely before I discovered Elixir, just because I got tired of dealing with the...exact...same...problems...in...every...single...dang...language. Elixir essentially forces you into a mode of operation that hits that perfect balance of productivity and concise code with a structure that inherently avoids almost every long term code base problem that I've dealt with in my career. It got me excited about programming again, which I didn't think was possible that far into my career.
- deleted 8y ago
  [deleted]
- vinceguidry 8y ago
  One of the things that made the article so interesting was that the author would try to find salvation in a solo side project, only to find himself right back in the same hell. I've been through this same problem, even with Ruby. What I ultimately had to realize is that you have to just get really really familiar with Ruby before you can get a taste for its superpowers. I don't think it has all that much to do with languages / stacks, though I do think it matters to a certain extent. I personally don't mind seeing warts in a Ruby codebase, because it means I'm at least working with Ruby. I've been violently dragged kicking and screaming away from Ruby more times than I ever want to see in my career.
  - jasim 8y ago
    I'm pretty comfortable with Ruby and have been programming in it for over 5 years now. But for any new project from now on I'd try to use a Typed Functional language - Reason/OCaml, Haskell etc. I used to argue strongly against types and functional programming, but that was before I actually knew the paradigm at all. I wonder if you have tried building anything non-trivial in a Typed Functional language, or even a different paradigm like logic programming. If you have and are not convinced, that'd be a great discussion to have. If you haven't, then based on my own experience, I think you might shift your opinions after spending a year or so with it.
empath75 8y ago
Ruby is a beautiful language but to me it’s too hard to understand what ruby code is doing by just looking at the code because so much happens with monkey patching and such.
bfrydl 8y ago
I used to feel exactly the same way about Ruby. Since then I have grown to value strict compile-time checks more so I don't really use it, but I still miss it. I wonder though if you have evaluated Crystal?
miki123211 8y ago
I have the same feeling when writing Go. I highly value minimalism and simplicity and I like understanding how things work on a deep level by reading and reflecting on it before actually using them. That's what Go lets me do. If I find a function, I know I can just llook at what that function does by looking at its source and I will probably figure it out. I don't always do, of course, but knowing I can gives me comfort. For my mental model, a function main with a lot of boilerplate code that sets up the database, the loggers, the services, injects all the dependencies etc. is much clearer than a directory of models, a directory of controllers, a directory of god knows what and some divine code sitting somewhere deep in the guts of rails doing something utterly magical and incomprehensible to make them work. I think a paradigm like Ruby's, where each line represents some clear and simple to understand fact about the code, in simple terms, like has_many :comments, would be much easier to understand with better tooling. I imagine a programming language (along with a very good IDE) where you could just hover over 10.days.ago and see exactly where that monkeypatch was defined and what it does.

chrischattin 8y ago

I get the same feeling when programming in Ruby and it seems like the entire community appreciates the same ascetic. I just love working with Rails. Matz took a unique approach when he decided to optimize for programmer happiness vs the machine and it turned out awesome.

melling 8y ago

Don’t languages like F# remove much of the verbosity of a type system? In fact, we’re finally loving away from that verbosity in general. Swift, for example, lets me write declarations like this: var done = false let language = “russian” let languages = [“english”, “french”, “german”, “russian”] let dictionary = [1:"english", 2:"french", 3:"german", 4:"russian"] The types are implied. The use of ‘let’ means immutable. I believe F# goes even farther but the verbose typing of a generation ago is almost gone.

wenc 8y ago
This. Static typing doesn't mean tedium in modern languages. In Java and old C#, you would write stuff like this: int x = 1; BigOldClass y = new BigOldClass() Dictionary<int, List<string>> z = new Dictionary<int, List<string>>(); int[] p = new int[] {1, 2, 3}; In modern C#, you can write cleaner code like this: var x = 1; // type is inferred var y = new BigOldClass(); // syntactic sugar to avoid repetition var z = new Dictionary<int, List<string>>(); var p = new [] {1, 2, 3}; Still strongly, statically typed, and obviously typed.
- gbear605 8y ago
  This is also true in Java now
  - ma2rten 8y ago
    C++ also has auto now.
  - arwhatever 8y ago
    Function types don't need signatures in Java?
- nbevans 8y ago
  I, as a F#'er, would argue that lines 2 and 3 of the C# snippet there is not an example of type inference. But I realise this is not a mainstream opinion so please don't downvote me :)
  - wenc 8y ago
    No, I don't think I meant to say all the lines were type-inferred. The type inference only happens on the 1st and 4th lines. In 2 and 3 the types were explicit. All lines however are statically typed.
    - barrkel 8y ago
      The type is inferred on all 4 lines and the mechanism is little different; the 4th line is the most complex one, because there's a type unification required across all elements of the array, but C# and Java and other languages with overloading already need to do very similar inference with the ternary operator - the types on each side of the branch need to be unified to resolve the overload. Hindley-Milner type inference (like used in F#) isn't hugely more complex; it's more aggressive at using type variables to generalize the code, and applies type unification in more situations.
- gameswithgo 8y ago
  right, most languages do this now. But F# extends that further. Function signatures don't need types either. Record types can be inferred from their field names. If you write a function with no type signatures it is automatically made generic, as well. So you can often write large chunks of code with no specified types, but everything is still statically typed. Granted this is maybe not always good, sometimes it is productive to have types in the function signatures, though the IDE can supply these automatically with codelens featuers/on hover features.
gameswithgo 8y ago
yes, type inference is pretty comprehensive, function signatures don't usually need them even.
gchadwick 8y ago
> verbose typing of a generation ago is almost gone Worth pointing out such type inference is hardly a new idea e.g. see the ML type system: https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language) which Wikipedia says first appeared in 1973. This actually traces its roots to the typed lambda calculus which predates electronic computers. However I think it is fair to say that type inference systems are finally appearing in more 'mainstream' statically typed languages (for example the auto keyword in C++ and your Swift examples).
- melling 8y ago
  Yes, immutability, pattern matching, type inference, etc are not new ideas. Pattern matching is another concept that’s making its way into popular programming. https://www.bignerdranch.com/blog/pro-pattern-matching-in-swift/ https://www.bignerdranch.com/blog/pro-pattern-matching-in-sw... https://stackoverflow.com/questions/2502354/what-is-pattern-matching-in-functional-languages https://stackoverflow.com/questions/2502354/what-is-pattern-... C# and Java are also adding this feature. We’re taking the long way to becoming Haskell and oCaml programmers.
- brianberns 8y ago
  F# comes from ML by way of OCaml.

brightball 8y ago

It's probably a little multifaceted. I'm a fan of Ruby but even Ruby develops warts with a code base that's too large. I was just about ready to exit programming entirely before I discovered Elixir, just because I got tired of dealing with the...exact...same...problems...in...every...single...dang...language. Elixir essentially forces you into a mode of operation that hits that perfect balance of productivity and concise code with a structure that inherently avoids almost every long term code base problem that I've dealt with in my career. It got me excited about programming again, which I didn't think was possible that far into my career.

deleted 8y ago
[deleted]
vinceguidry 8y ago
One of the things that made the article so interesting was that the author would try to find salvation in a solo side project, only to find himself right back in the same hell. I've been through this same problem, even with Ruby. What I ultimately had to realize is that you have to just get really really familiar with Ruby before you can get a taste for its superpowers. I don't think it has all that much to do with languages / stacks, though I do think it matters to a certain extent. I personally don't mind seeing warts in a Ruby codebase, because it means I'm at least working with Ruby. I've been violently dragged kicking and screaming away from Ruby more times than I ever want to see in my career.
- jasim 8y ago
  I'm pretty comfortable with Ruby and have been programming in it for over 5 years now. But for any new project from now on I'd try to use a Typed Functional language - Reason/OCaml, Haskell etc. I used to argue strongly against types and functional programming, but that was before I actually knew the paradigm at all. I wonder if you have tried building anything non-trivial in a Typed Functional language, or even a different paradigm like logic programming. If you have and are not convinced, that'd be a great discussion to have. If you haven't, then based on my own experience, I think you might shift your opinions after spending a year or so with it.

empath75 8y ago

Ruby is a beautiful language but to me it’s too hard to understand what ruby code is doing by just looking at the code because so much happens with monkey patching and such.

bfrydl 8y ago

I used to feel exactly the same way about Ruby. Since then I have grown to value strict compile-time checks more so I don't really use it, but I still miss it. I wonder though if you have evaluated Crystal?

miki123211 8y ago

I have the same feeling when writing Go. I highly value minimalism and simplicity and I like understanding how things work on a deep level by reading and reflecting on it before actually using them. That's what Go lets me do. If I find a function, I know I can just llook at what that function does by looking at its source and I will probably figure it out. I don't always do, of course, but knowing I can gives me comfort. For my mental model, a function main with a lot of boilerplate code that sets up the database, the loggers, the services, injects all the dependencies etc. is much clearer than a directory of models, a directory of controllers, a directory of god knows what and some divine code sitting somewhere deep in the guts of rails doing something utterly magical and incomprehensible to make them work. I think a paradigm like Ruby's, where each line represents some clear and simple to understand fact about the code, in simple terms, like has_many :comments, would be much easier to understand with better tooling. I imagine a programming language (along with a very good IDE) where you could just hover over 10.days.ago and see exactly where that monkeypatch was defined and what it does.