Hacker News Reader

> I think something that gives an inherent advantage to OO languages in IDEs is that SomeThing.<tab autocomplete> makes a lot of sense and is easy to compute!

F# (as well as OCaml) offers something similar in that you'll use a lot of functions that are within modules with the same name as the type you're working with. So you can write "List." and get a list of functions (map, reduce, etc.). I'd prefer something like Idris which will disambiguate functions based on the relevant types, but at least it makes IDE support easier.

> A lot of object-oriented languages have taken tips from functional languages lately (map/reduce/filter is the new hottie), but I think there's a lot of benefit still to get in the opposite direction.

Something in particular I wish F# would add it general non-linearity of definitions. All files and definitions in F# must be strictly ordered (either type A can reference type B or vice versa, but not both) except for specific, contiguous blocks. It presents a challenge for type inference, but I think just punting it back to you for the tricky cases would be fine (and it often has to do this anyway).

I suspected as much, thanks for confirming! F# is definitely the plan for this weekend, then :)

I like having the linearity of definitions and files. It makes reading unfamiliar code bases much easier, as it means the code has a "beginning" and "end." To me it fits well with the F# theme of sensible defaults.

If you do need to get around it though, you can have mutually referential types in F# if you use the "and" keyword (although the definitions of the types have to be right next to one another). And in the next update to F# you'll be able to have mutually referential types and modules within the same file which is often good enough for most other things you might need that sort of thing for.[1]

[1] https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-in...

I think the linearity can force you to streamline things, but personally I often have to resist the urge to bike-shed the order in which I write functions in the same file, let alone what order I want to put my files in. I end up being torn between different orders I would want in different situations, and would love a language or IDE that would let me view definitions in different orders depending on what I'm looking for.

I don't find dynamically-typed languages productive at all once the program gets past about 400 lines and/or you figure out what you need to do.

The break-and-follow-the-errors approach is very powerful. It's usually not hard to find the exact break that will show you all the things you need to change, and then just work through them. My record is 5 days without buildable code, working in C++; once I'd worked through all of the errors, the program worked, and without any non-obvious problems.

I miss this a lot when working in a dynamically typed language.

(Thing by Jonathan Blow that touches on this: https://web.archive.org/web/20140929232443/http://lerp.org/n...)

> Want to read/write pretty-arbitrary JSON? Good luck

Parsing JSON in Java was one of my worst programming experiences, so I have to agree with you here.

But in Rust, using the `rustc-serialize` library (and Serde, but I haven't tried that yet), parsing and writing JSON is really pretty painless. The really nice part is that you can declare the structure of your JSON data as a completely normal Rust struct (just with a derive annotation that makes it Encodable and/or Decodable), and with a single function call turn an instance of that struct into a JSON string. And in reverse, you can just parse() a string and it will return either an instance of your struct or an informative error if the JSON is malformed or doesn't match your structure. Makes JSON really easy to work with.

I think 'arbitrary' was actually the key word. I agree that serializing/deserializing structs is pretty painless, the issue is when you're not sure what you're getting.

In golang recently I had to take some json (that I only knew part of the structure of), and modify just that small subpart of it without touching the rest. It was a really painful thing to develop, and the code ended up very messy.

There were a few golang libs for reading arbitrary json, but none supported writing to it that I could find.

Jackson (in Java) gives you pretty much the same experience, albeit I'd recommend a few annotations on your object. And you can read/write arbitrary JSON into JsonNode or Map<> objects.

> Want to read/write pretty-arbitrary JSON? Good luck)

I'm surprised this myth perdures.

Reading arbitrary anything is trivial in a statically typed language: use a hash map.

There. You're merely emulating what a dynamically typed language gives you, of course, but it's trivial. And at least, statically typed languages give you the choice: you can be dynamic or static. You don't have such a choice when you don't have types.

> I realized that statically-typed languages can really have the potential to be as or more productive than dynamically typed languages paired with a good enough IDE.

Indeed, and C# isn't even a particularly safe typed language. It still has pervasive null, for instance. When you get into F#/OCaml/Haskell/Rust-type languages, it's a real eye opener.

> Want to read/write pretty-arbitrary JSON? Good luck

Not sure I see the problem. Just deserialize JSON into a JsonValue which provides dictionary semantics like JavaScript.

I agree the property reference tab autocomplete is a pretty powerful feature. It's like autocomplete in a shell, but contextual, since the system already knows what you want the first argument to be. And I've seen a video with one of the big functional guys (maybe Brian Beckman?) pining for that feature.

I'd point out, though, that is still is only part of the picture. You're holding on to a value and you want to know what you can do with it:

    widget.<tab>

will show you everything of the form

    widget.someData
    widget.doSomething()

but you're still missing out on other structures like

    freeFunction(widget)
    handler.handleWidget(widget)
    hammer + widget
    widget[part]

    // returns a widget, does this one count?
    widgetFactory.buildWidget()

In nearly any language the first two will be common, and where available the others are critical usages, too. I want to be able to tab complete them!

It's hard to continue hewing to the tab as activation with these other structures, which may be why IDEs and REPLs don't really try.

That sounds like something that would be an awesome demo, but not really useful.

I actually dislike tab complete in usual forms most times. Auto import is nice, but i feel that auto complete is a form of searching the code base. And, when I am coding seems a poor tube to be searching for the answer.

When debugging, however, jump to symbol and quickly listing alternative methods helps. And sometimes I am just searching. So, good feature. Just not something i want to rely on.

In large code bases it can be really hard to keep everything in your head, and that's when a little tab complete can really come in handy. Just forgetting specific method names when you know there's one you want to use can be very handy.

It can help. Often does. But I treat it like spell check. If I need it, I'm probably using the wrong word. And I don't know how to use it to effectively search for words.