5 ms·

Removing implicit side-effects and global state from code and having strong, static types can go very far in allowing this, without much overhead. Unfortunatel

Removing implicit side-effects and global state from code and having strong, static types can go very far in allowing this, without much overhead. Unfortunately, there isn't a really great language that enforces working like this, while being simple enough to push onto a big team :/ (if there is, please let me know)

bpicolo 10y ago
F# is probably a pretty decent candidate for this (it's next on my list of languages to really take a critical look/attempt at). I've done a lot less statically-typed code than dynamic (mostly Python) in the last few years, but I was playing with Unity3d recently and had a chance to write a good deal of C# with Visual Studio. I hit a hairy problem some time along and had to do a big refactor to support a new feature. I deleted a single line of code, followed an error trail for 10 minutes, and suddenly everything was just done. It was a pretty interesting moment for me. 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. (And Visual Studio with C# is about the best pairing you can get). I've had to reconsider my thoughts on these things a bit. Sure, there are things that statically typed languages can make much harder to test or work with. (Want to stub an external provider? Okay, you're going to need an extra interface, then you'll need to create a new stub version that implements that. Want to read/write pretty-arbitrary JSON? Good luck). But there are other places where you get huge wins by bugs just disappearing by the boatload. I'm still not on board with heavy OO/inheritance, and love the pattern of simpler struct-style constructs with just functions in functional programming, but the static typing can give a lot of wins. 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! I can take an object and know what I can do with it at a glance. I haven't seen a functional language with enough structure to support that simple feature yet (though maybe I'm just not looking hard enough). This is really where statically typed languages can make the most of an IDE. For some reason, that's the big thing I think of when I'm thinking about the downsides of functional programs I'm working with. The editors just seem to help a lot less (though I haven't written any FP professionally-speaking, so have less experience in general with tooling). F# using Records with member methods looks like it might be able to get that sort of benefit though, I'll need to try that. It looks like they're just pure functions declared on immutable structs, which I think is the perfect middle ground. 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.
- couchand 10y ago
  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.
  - taeric 10y ago
    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.
    - bpicolo 10y ago
      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.
      - taeric 10y ago
        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.
fbonetti 10y ago
In terms of web languages, Elm is perfect for this purpose. It's a statically typed, pure functional programming language. It's impossible for functions to generate side effects. Side effects must captured by the type system as external "Commands". Also, the type system is inspired by Haskell but far more basic. To hardcore functional programmers this is a negative, but Elm is really easy to teach to JavaScript programmers as a result.

bpicolo 10y ago

F# is probably a pretty decent candidate for this (it's next on my list of languages to really take a critical look/attempt at). I've done a lot less statically-typed code than dynamic (mostly Python) in the last few years, but I was playing with Unity3d recently and had a chance to write a good deal of C# with Visual Studio. I hit a hairy problem some time along and had to do a big refactor to support a new feature. I deleted a single line of code, followed an error trail for 10 minutes, and suddenly everything was just done. It was a pretty interesting moment for me. 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. (And Visual Studio with C# is about the best pairing you can get). I've had to reconsider my thoughts on these things a bit. Sure, there are things that statically typed languages can make much harder to test or work with. (Want to stub an external provider? Okay, you're going to need an extra interface, then you'll need to create a new stub version that implements that. Want to read/write pretty-arbitrary JSON? Good luck). But there are other places where you get huge wins by bugs just disappearing by the boatload. I'm still not on board with heavy OO/inheritance, and love the pattern of simpler struct-style constructs with just functions in functional programming, but the static typing can give a lot of wins. 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! I can take an object and know what I can do with it at a glance. I haven't seen a functional language with enough structure to support that simple feature yet (though maybe I'm just not looking hard enough). This is really where statically typed languages can make the most of an IDE. For some reason, that's the big thing I think of when I'm thinking about the downsides of functional programs I'm working with. The editors just seem to help a lot less (though I haven't written any FP professionally-speaking, so have less experience in general with tooling). F# using Records with member methods looks like it might be able to get that sort of benefit though, I'll need to try that. It looks like they're just pure functions declared on immutable structs, which I think is the perfect middle ground. 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.

couchand 10y ago
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.
- taeric 10y ago
  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.
  - bpicolo 10y ago
    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.
    - taeric 10y ago
      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.

fbonetti 10y ago

In terms of web languages, Elm is perfect for this purpose. It's a statically typed, pure functional programming language. It's impossible for functions to generate side effects. Side effects must captured by the type system as external "Commands". Also, the type system is inspired by Haskell but far more basic. To hardcore functional programmers this is a negative, but Elm is really easy to teach to JavaScript programmers as a result.