> [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.
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 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.
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.
Maybe I'm not getting something, but all this Flux stuff reminds me a lot of DDD+CQRS (domain driven design w/ command query response segregation), to the point where it seems like it's the same concepts repackaged with different terminology.
This post in particular seems to be advocating the concept of having a single 'aggregate root' as opposed to independently loaded 'entities', and Flux sounds like it just advocates the use of an 'event bus' to send separate 'read'/'write' 'commands' to 'domain objects'... the main difference of course being that all this recently has been specifically with the browser in mind. Is that a reasonable assessment?
Don't think I've had the pleasure of actually meeting any of those types in real life. It is a joke after all of course, but they do seem more like different 'hats' that most programmers come wear every now and then, rather than static 'types'... /pun
Yeah, using 'summon' works, it just kind of slips our minds that it exists when we're thinking/talking about the code, but that's likely just a familiarity issue. Mostly it's just the use-case of being able to casually see what a teammate is working on at a glance instead of asking distracting questions, but it's not a huge deal.
Thanks for the support! I've been working on a collaborative editing solution of my own for a while (though not for code), and can definitely appreciate the work that goes in to such a thing.
Have been using this to pair-program on a project recently. It's probably the best collaborative coding solution out there at the moment, but it still has some issues. Most notably, it inexplicably deleted an entire directory from our project between coding sessions at one point, causing us to delete and recreate our 'workspace' -- luckily it doesn't affect the source project of the collaborator that shared it, but still caused us to spend about an hour trying to figure out how to 'refresh' our projects. Another minor quibble is that you can't tell what file anybody is currently viewing/editing, which can cause some confusion when talking in a hangout call.
But overall it's pretty effective for those times when you just need to look at code with someone remotely.
Then Lion came along and slowed things down to a crawl. Definitely the slowest OSX release I've had on my old macbook (circa '08). I eventually downgraded back to snow leopard until mountain lion came out, which was noticeably faster than Lion, but still not quite as smooth as snow leopard. But now Mavericks is back to being pretty good.
All-in-all, still not a very straightforward 'improvement' path performance-wise -- at least not from the end consumer's point of view.
I'm not terribly experienced with React, but from briefly using it, I definitely prefer polymer's simple vanilla html+js declarative data-binding approach over react's JSX + element injection, from a basic usage perspective.
Which can be (and was) remedied by a simple reply to correct that one particular part. Indiscriminately pedantic downvoting on the other hand, just kills the potential for any fruitful discussion all for the sake of some silly minor mistake. Luckily, more people came in and got the comment out of the grey zone in this case.
http://blog.nikosbaxevanis.com/2015/04/25/fsharp-on-emacs-wi...
[0] http://spacemacs.org/