> [static typing] feels like it's in the way between components and results in some boilerplate, verbosity, and overly tight coupling
Just curious, is this with regards to Elm / ML-style static typing specifically, or were you talking about it in combination with languages like C#/Java/etc?
I'm an elm noob, but I've been using F# for a good while, and its ML style of static typing is almost like the exact opposite experience of working with things like Java. Significantly less code, less boilerplate, and more expressive[0][1]. For example, one of the coolest features of F# that really showcase this, are type providers:
With them, you can leverage F#'s type system to automatically infer the structure and type of any external data source. Which means practically zero boilerplate or "ORMs" needed for things like reading-from/writing-to databases, making web api calls, parsing json/xml, or even interfacing with packages from entirely different languages like R [2].
So static typing can definitely have a lot of cool/practical benefits besides just catching bugs that make life easier, while still maintaining the flexible/lightweight feel of languages like python. However languages like C++ and Java have definitely seemed to have given it a bad name for a while, and haskell's whole tie-in with abstract math hasn't historically made it very accessible for us average programmers to notice all the tricks it has up its sleeve.
Elm is still young and I'm a total novice to it, but after working in F#, I'm definitely sold on it and like where it's going.
So here's the Elm high level on the tree of components:
An Elm component is typocally a Model type and a Msg type. When side effects occur, the component receives a call to update with the model and the message. It returns a new model and a new side effect to cause (could be none). The model is then rendered into a view.
If you have a user profile component then maybe you have a user info component and a settings component. And maybe the settings component has a notifications component and a privacy component.
The Model for that is pretty straightforward. It's just a tree of data.
The Msg for that is what is being complained about. Any side effects caused by a child component will call the update function of the parent. It then has to route that to the child component.
The result is that you have:
type Msg = ProfileMsg Profile.Msg | SettingsMsg Settings.Msg
type Profile.Msg = ...
type Settings.Msg = NotificationsMsg Notifications.Msg | PrivacyMsg Privacy.Msg
type Notifications.Msg = ...
type Privacy.Msg = ...
So now your top level msg could be a SettingsMsg (Settings.PrivacyMsg (Privacy.SetDefault Privacy.Self))
And in order to process it in update you have to unwrap the outer type (like SettingsMsg) and then call update on the child component with the data from the msg. You repeat until a component can handle it. The the component returns a new model and possible new side effect. You wrap up that side effect in something like SettingsMsg and return it along with your new model.
It's a lot of boilerplate. As far as creating coupling, what if you want to use the notification component elsewhere in the app. Now something other than Settings needs to wrap it so you get Settings.NotificationMsg and Toolbar.NotificationMsg.
Thank you for taking the time to clarify and explain. That's exactly what I was talking about.
Worth noting -- it might be that there's just a missing construct/approach itty bitty piece of language support here that would make this problem a lot smoother.
I'm actually surprised I've not heard of anyone else express something other than complete satisfaction about it as it doesn't take much messing around to whack into it.
The F# support is what got me to try vscode at all. Before that, I was skeptical about all js-based editors (being an emacs guy), but I was pleasantly surprised at how well this vscode+ionide setup works.
Visual Studio is still a bit nicer with regards to handling all the .fsproj stuff, and visually showing you the order of your files, but the editing itself on vscode is definitely on-par with it.
I bought a kobo ereader over a kindle not too long ago, precisely because it supported this font. I tend to prefer Comic Sans[0] over it a bit though, and use Pointfree[1] on all my code editors. None of those make reading completely smooth experience of course, but they do provide a noticeable improvement over traditional serif text.
I'd say having a large line spacing, an unjustified text layout, and a darker/lower-contrast[2], all help more than the font choice itself, but any tiny optimization is helpful.
[0] as a former graphic designer, it actually took me a while to get comfortable with the idea that I found Comic Sans useful for anything, lol
I am amazed about this unexpected compliment to the Comic Sans MS designers. I always thought that this font is, conversely, harder to read than serif fonts. Seemingly this is not always the case in practice.
Yeah, what's missing is a software build by Robert Martin that is used and admired by several people.
Considering software is much more easily distributable than hardware makes the fact that there is none works against him.
Robert Martin may be good at Marketing, but I've never seen something from him that I liked.
Closer to Woz would be people who ACTUALLY shipped working code (Linus Torvalds as an example) then people who like to complain about code not having enough test coverage
So yeah, I hold no respect for this "Uncle Bob" guy
I wish there were (more?) people who feel about software like Steve Wozniak feels about hardware. Because it is an art, a pursuit of perfection.
Didn't mention anything about shipping popular software, so I'm not sure where you're getting that metric from, but it's completely irrelevant to what OP was describing, and uncle bob fits OP's description perfectly. His talks show how passionate he is about code as a craft, and how he wants to strive for perfection. The popularity of his code doesn't take away from that (not to mention that Jobs played a significant role on Woz's end for that, so it's not exactly an apples-to-apples comparison either). The fact that Martin has good rationales to support his ideas is just an added bonus in that regard. I get the impression that he's disliked more just because people have a fear of falling into the 'java culture' than because of his actual arguments.
Also, Linus is nothing like Woz other than their shipping of popular products. Nothing against the guy, I'm sure we're all grateful for his work, but he doesn't seem to display the same kind of childlike wonderment of his craft like woz does.
Dart only looks like java (this was a deliberate design choice to increase familiarity and ease learning/adoption), but it works a lot more like ruby and go.
I was interested in the same question but there hasn't been any research as far as I have found. There are anecdotal accounts in various tDCS communities such as /r/tdcs
Agreed. Up until recently, I too used to prefer working with raw HTML... then I started working on a couple large apps, tried polymer/angular, and ended up gaining a new-found appreciation for frameworks like react/mithril/mercury.
The cost of abstracting away the DOM isn't as much as I would've expected compared to the cognitive overhead of switching back and forth between languages, making sure everything is linked up nicely, as you normally would. There are a few times when that abstraction can lead to annoying hidden bugs, but overall I've found the workflow to be much nicer.
http://blog.nikosbaxevanis.com/2015/04/25/fsharp-on-emacs-wi...
[0] http://spacemacs.org/