HN user
I don't think you can apply the same principles to OO and FP but in terms of refactoring, my experience is that pure functional code is a joy to test and maintain. Small pure functions (again functions can only be pure functions, otherwise you're really talking about procedures), are by their nature easy to test, compose, cache, parallelise and pipeline. If that sounds bad to you, then fair enough.
I personally found F# to be a decent alternative to Elm for small browser apps with Fable, Elmish/Feliz, Feliz.Plotly etc. You can generate typed interfaces for any libs you're missing which have a typescript interface using ts2fable, that's the kind of pragmatic tooling you need if you're veering off the well-trodden path in commercial development. Ionide in VSCode is excellent (though not perfect) and the compilation times are decent. In terms of community (which is not unimportant when it's that small) even the compiler gitter folks were super helpful when I had some reflection questions. Overall I'd use it again for small browser apps, for backend I guess it depends on your company and domain.
jet.com used it heavily for backend dev, grew quickly, were acquired by Walmart, 560million+ in funding: https://www.crunchbase.com/organization/jet
Even if you'd consider them the Jane Street of F#, it's a counterexample to your argument.
I found this project to be easy to use, it produces SVG output with d3:
It's true that it's easier to write and arguably harder to read code when types are not specified, or at least it's handy for public interfaces between modules. Luckily this is easy to do and often done:
https://fsharpforfunandprofit.com/posts/function-signatures/
It's the same deal with Haskell, you don't HAVE to specify the types of your code but it can help check your assumptions as to what the compiler is inferring. I've frankly found that a more frequent issue in Haskell because of pervasive use of Monads and other higher-order constructs.
Can you clarify what you mean? It gets subducted by plate tectonics and becomes steam when heated, presumably it's still there..
This article (which contains nothing but speculation) has been posted here already at least once.
Remote US only or remote EU also?
Way to ruin the fun for the rest of us ;)
More interesting to my mind is this (Diamondback Ruby):
http://www.cs.umd.edu/projects/PL/druby/
Some features:
--------------
Type inference:
DRuby uses inference to model most of Ruby’s idioms as precisely as possible without any need for programmer intervention.
Type annotations:
Methods may be given explicit type annotations with an easy to use syntax inspired by RDoc.
Dynamic checking:
When necessary, methods can be type checked at runtime, using contracts to isolate and properly blame any errant code, similar to gradual typing.
Metaprogramming support:
DRuby includes a combined static and dynamic analysis to precisely model dynamic meta-programming constructs, such as eval and method_missing.
Flash still powers Youtube for most users, Silverlight for Netflix and Unity's plugin is required for most 3D games on Chrome's Marketplace (not sure where else to look for successful HTML5 games).
By usability you surely mean something other than the traditional sense of the word. Exactly what was usable about the Reader interface?
There are actually several other casual gaming startups in Hamburg e.g. Bigpoint GmbH which followed a more American model of growing as fast as possible and selling out early, so I don't think it's a German/European thing necessarily. Given one of Jimdo's competitors Wix is IPOing this year after an enormous marketing spend, it doesn't seem industry niche-specific either. (Disclosure: I work at Jimdo, feel free to ask me anything)
Any performance benchmarks of Pixate vs procedural code or vs similar DSLs, e.g. Teacup, Formation in Rubymotion?
The author claims that C has "an order of magnitude more expressiveness" than assembly with no basis for the statement, but ok. He then throws all the "compile-to-JS" languages together even specifically mentioning Sibilant which has macros. If there is another 10x expressivity gain to be had by adding any language feature then surely macros are it.
"It's been a year since we've filed for bankruptcy and we're still there." - I work in a company that strives to follow such a model, and it honestly struggles to achieve the kind of efficiency most companies take for granted. I dearly hope it doesn't lead to that end, but from what I can see it's a distinct possibility.
Firstly:
http://www.ietf.org/rfc/rfc4627.txt
"An implementation may set limits on the size of texts that it accepts. " - How does that "support" streaming?
My argument is that most people don't need it most of the time (I can't prove this). It's also NOT a protocol designed for streaming. As regards API design, it's a matter of taste but my preference and that of many others who use python, as we can see with the popularity of requests, Flask, is that an API should be designed for simplicity for the common use cases rather than for absolute completeness. I'm not saying don't expose a low-level API full of BufferedReaders, JSONParserCursors, but don't force it on me to parse a tiny JSON document of known length.
It is perfectly acceptable to design a library with a simplified, restricted interface that covers the majority of use cases, but not all. e.g. requests vs urllib2 For me, that's a win for common sense. I have never even considered streaming JSON. The lack of streaming support should be a clue that the OP needs to look at whether what he's attempting is even sensible or could be better served by a different transport protocol with built in streaming support.
...we may have very few humans left of that era
"its because they did something smart" So intelligence == 'achievement'? That makes no sense.
As for nonsense, ok I'll retract that, it is an interesting but highly implausible topic that gets a large amount of discussion relative to it's likelihood. It's actually just another way of phrasing "Does God exist?" If there was a computer (God) simulating this universe and controlling it, then it'd require a host universe for itself to exist, and it's complexity has to be greater than what it is simulating. Therefore it is less likely, and not by an insignificant amount.
There are so many reasons not to do this. The potential site reliability risk of relying on someone else's free CDN (page not loading/loading slowly) far outweighs the slight benefit of CDN acceleration. When you CloudFront/Akamai your content, you have some sort of SLA, but don't complain when Google pull shared library hosting as they have many other free services.
Why do smart people love to debate the most implausible nonsense? Time travel through singularities anyone?
The world's already got a few of these to my knowledge, Brightcove launched one last week with native plugins..I personally would love to see a fully native version of this. People want real UIKit/Android components, not an approximation of same.
Also wondering about this, would be v. cool to play with it on iOS.
"Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers," said Cuong Do, Software Architect, YouTube.com.
There are many dynamic user driven sites which have scaled well (far less downtime than Twitter) without switching to static compilation.
You say array, I say heterogenous vector, let's call the whole thing off!
I guess, but this seems like something that could become a best practice for library authors, and it'd be fairly trivial to retrofit or fork existing libs with annotations.
I am not sure about the motivation for this project but this article helps explain why some folks are interested in type systems as detachable (pluggable) components, separate from languages:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.175...
They're implemented using the same data structure and given the language semantics (keys can be any scalar type intermingled horribly), how would you improve that?