Hacker News Reader

Comment by vinceguidry | Hacker News Reader

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.

View on HN

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.

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.

This is also true in Java now

C++ also has auto now.

Function types don't need signatures in Java?

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 :)

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.

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.

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.

To me that isn't an improvement. It may be "statically typed", but it isn't clearly typed, the first set is not slow to enter or read and is 100x clearer.

To me var is only useful for writing generic lambdas & similar - you shouldn't use for regular variables.

I agree that "1" should annotated to specify which type of integer you are using. But IMO `var foo = new Foo()` is pretty clearly of type Foo. Furthermore the type is often not what I care about (the variable name and function call names generally tell me more about what is happening on that line of code), so I'm generally pretty happy if the type is a little more hidden.

The problem likely results from:

var i = someFunctionWithANonObviousReturnType();

Type inference may be easy when the left-hand side is a literal, but that's often not the case. And when the left-hand side isn't a literal, it definitely optimizes writing code at the expense of reading code. You can argue that IDEs should be helping us by show us the type when we mouse over or auto-completing available methods on the variable's type, but there are situations (code review, pair programming, etc) where we can't rely on tooling to help in this regard. I get why people like type inference and I use languages that have it on a daily basis, but I've also realized that I need to adapt my coding style to it or I'll end up with code that's difficult to read. In particular, I'm constantly considering whether the code I'm writing is understandable using local reasoning only and that I'm not forcing a reader of my code (who's likely to be me several months from now) to jump to some declaration somewhere else in the code.

Then add a type in that instance.

var i:ReturnType = someFunctionWithANonObviousReturnType

I found that in practice I don't need it.

yes, type inference is pretty comprehensive, function signatures don't usually need them even.

> 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) 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).

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-sw...

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.

F# comes from ML by way of OCaml.

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.

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.

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.

Erlang did that for me. I've looked at Elixir, but never used it in a project.

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.

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.

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.

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?

Reply on news.ycombinator.com