pka

> I can read through the 5 lines of Python code implementing insertion code, and be reasonably sure that it's correct.

Binary search is possibly one of the simplest and most basic CS algorithms, and yet, it took people who were "reasonably sure" 10 years to find that bug.

> I would have a much harder time verifying that 300 lines of Idris are specifying what was intended.

Then don't use Idris?

> I'm saying that you have diminishing returns.

I agree. However, that was not your argument. Your argument was that tests subsume proofs, and that's obviously wrong.

Also, types vs tests is a false dichotomy. Personally, I find a strongly typed language + QuickCheck to be the most practical way of developing complex software. YMMV, and that's fine.

> The type system in Java also failed to catch the bug

Java is not a theorem prover, and your comment was about theorem provers.

> you wouldn't end up with an error in a specification

Again, completely orthogonal to your argument. If you have an error in specification tests won't help you because you'll test the wrong thing.

> The thing to realize is that theorem proving is not a business goal in most cases. What you care about is being able to deliver software that works

Again, your comment was about "saying things are correct in the semantic sense". You're saying now "I don't care about correctness in the semantic sense, I care about delivering software that "works" (whatever this means; clearly it doesn't mean software without bugs) in a reasonable amount of time" and that's fine. I do too, but again, nothing to do with your original argument.

Re macros, I had a similar thought this morning. Except for code instrumentation and boilerplate generation I've actually never found macros to be useful.

ADT DSLs + free monads or similar abstractions give you everything you need, in a more principled way.

“Saying it’s correct in the semantic sense” = proving the code.

They found a bug in Java’s binary search after 10 years of it going unnoticed, so I think you’re overestimating your own ability to prove code correct in your head.

Generative testing/spec is absolutely useful. It doesn’t subsume static typing and much less theorem proving though, and you can QuickCheck your pre and postconditions in static languages as well.

This looks promising, can you expand on how this differs from clojure.spec and core.typed?

> i think in the distinct minority

I'm not so sure about that. Even though the HN rating system shouldn't be abused to express dis/agreement it often is, and my comment seems to have more upvotes than downvotes so far.

> that seems like a broken process or a poorly designed system

I'm sorry, but saying that as long as your process isn't broken (whatever this means) and your system isn't poorly designed then Rails is maintainable seems to be a pretty weak argument. In a perfect world with perfect, non-changing requirements, no deadlines and understanding clients you can probably make Brainfuck maintainable :)

> In order to scale, Ruby applications need very high coverage.

Exactly, this is the "at enormous cost" bit I hinted at.

From experience.

I've worked on 5+ years old Ruby projects having around 100KLOC (including tests), and adding a timestamp to an internal API that affects several other internal microservices (something that shouldn't take more than 15mins) takes a week of code reviews and writing tests.

As I said, I don't claim it's impossible to make Rails maintainable. Instacart is apparently a good example of how to do that.

For curious onlookers: true, one can "can whip together apps so quickly", as long as:

* Your code is empirically around ~1 KLOC

* You won't have to maintain it in the future

So yeah: if you're going to make a one-off-deploy-once-never-touch-again message board/blog app with Google Maps integration, choose Rails. Otherwise: don't bother.

Making Ruby/Rails maintainable at scale is a sisyphean task: it's possible, but at an enormous cost. This is why there are several attempts to bolt a type system onto Ruby, the most recent one being developed by Stripe [0].

I've no hard numbers, but the narrative "without Ruby my startup wouldn't last long enough to worry about engineering it the right way" sounds very very suspicious to me when talking about even remotely complex problem domains. Your speed will drop to zero in about 3 weeks from the start when you have to refactor some fundamental piece of code/data structure anyway, and then better hope you at least wrote some tests. And having to write tests essentially halves your dev speed anyway, so I really am not sure where this "prototyping speed" meme comes from.

[0] https://news.ycombinator.com/item?id=17217815

Yes, they more or less had to lift while/for/if/switch etc into the continuation monad :)

This is not as general as a monad though, it's just feeding the output of one function into the next.

I'm sure you know this, but the thing that makes monads a more general solution is that (because bind depends on a value produced at runtime) one can dynamically alter control flow, i.e:

    fetch = do
      user <- fetchUser "url"
      if userEmpty user
        then do
          fetchUserDetails "details"
          fetch -- recurse
        else
          fetchAddress user

For that to work, your functions inside the `composeAsync` array would need to able to return nested promises and at that point you've just reimplemented the continuation monad :)

Of course! When I said "it can't be implemented" I meant the logic that the continuation monad itself encapsulates, not async computations in general. For those you wouldn't even need promises, you could just use callbacks:

    fetchUser("url", (user) => {
      fetchAddress(user.address, (address) => {
        ...
      });
    });

But this repetetive plumbing is exactly what the continuation monad abstracts away:

    do
      user <- fetchUser "url"
      address <- fetchAddress user.address
      ...

So the point is that you can write your async code in the same way you'd write normal, sequential code (which is what the async extensions of JS/C# allow you to do).

Just to point out the probably obvious thing: that's only one type of monad (the state monad). There are many other things which form a monad and can't be represented easily in JS or other imperative languages.

Even though even the state monad is a clear win in my opinion (since it explicitly delimits a stateful computation which can then be embedded in a pure one in a principled way), the concept itself is much broader and thus much more useful than just allowing for imperative syntax in a pure language. For example, the continuation monad, which is just a library in Haskell, can't be implemented in most imperative languages without extending the language itself (async in JS, C#, etc).

> native script is just superior to react native in so many ways

Could you elaborate? If true that's amazing!

Yeah, your native vs truly native distinction is just splitting hairs. Unless you're making a game or an otherwise CPU intensive app why does it matter whether you create your UIViews from ObjC or a JS VM?

> But until it affects day to day dev work, there's a whole set of people that aren't going to give the slightest fuck.

That's a seriously toxic attitude to have.

People are using monads and other FP concepts daily to simplify "day to day dev work" (here's an example [0].) The fact that it's more or less mainstream to write off a concept because it sounds "academic" is worryingly anti-intellectual in a profession that is allegedly based in analytical thinking.

> Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec?

There are some in the linked github thread (which had to be reposted repeatedly until people actually stopped and read them, btw.) It's about being able to write DRY code that abstracts over not only promises, but anything else that forms a monad, like arrays, optional values, and so on.

[0] https://github.com/facebook/Haxl

> No global or hidden state

Does that mean that one can detach an input field, save its state somewhere, create a new one and attach it somewhere else again and have it appear exactly as it was before (i.e. cursor position, selection, focus, etc)?

That's one of the pain points with VDOM frameworks (i.e. need to diff around UI components which shouldn't lose state), so I'm curious if this library gets it right.

Just a clarification for anybody else who might be reading this: there absolutely are mutable variables in pure fp languages like Haskell, you just have to explicitly ask for them (and reflect that fact in the type), i.e:

    do
       x <- newIORef 0
       writeIORef x 2
       print =<< readIORef x

will print 2. In fact, I'd argue that many times writing programs with mutable state is actually easier in Haskell/etc, especially when it comes to concurrency where something like software transactional memory [0] is invaluable (and more or less practically unusable in other ecosystems), if it fits your constraints.

[0] https://en.wikipedia.org/wiki/Software_transactional_memory

> It is important to realize that they will increase bundle sizes

Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript.

That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.)

I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.

> And for non-functional languages?

I would recommend Typescript then.

> Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology.

True, FP excels at concurrent programming, but that's far from its only strong point. I'd propose that React-like architectures (which are based around a pure Model -> View function) and functional languages are a match made in heaven.

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful

Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, focused on pragmatism) would be right up your alley.

If you're ok with a dynamic language (i.e. strike rigour), then look no further than Clojurescript [3], Clojure's [4] little web brother. An elegant and simple Lisp, it makes almost all other dynamic languages completely obsolete.

There most definitely are sane options for developing for the web if one is willing to use a compile-to-js language.

[0] http://elm-lang.org

[1] http://www.purescript.org

[2] https://reasonml.github.io

[3] https://clojurescript.org

[4] https://clojure.org

I agree in general that sexps provide the best editing experience currently, but that's just a matter of tooling, it's not an inherent property of sexps vs infix or whitespace-dependent syntax.

Check out [0], a structured editing mode for Haskell, a whitespace-sensitive language.

Incidentally, while I have no problem with Lisps (I've used Clojure for about a year), I do prefer infix notation, precisely because it's not homogeneous.

[0] https://github.com/chrisdone/structured-haskell-mode

Yeah. Haskell is so imba people don't believe you when you tell them :)

It's understandable to show skepticism about "the new shiny thing" (although Haskell is > 30 years old) because most new shiny things turn out to be not that great after all. I've been struggling to communicate the "no, but really" distinction without much success to other people and it's frustrating.

(...for purely egoistical reasons though, I don't really care what people are using as long as I get to use a sane language in my day job, which is currently not the case.)

I doubt it, other than syntactic sugar, which makes tuples really easy to use, like destructuring and construction. I.e. in Python, if you have a function that returns a tuple:

    a, b = f(xxx)

To create a tuple you just do (a, b). In Haskell, you get some other benefits, like tuples being functors (i.e. "things that can be mapped over"):

    map show ("tuple", 5) == ("tuple", "5")

P.S. Not a Python expert, but I think tuples might be enumerable in Python, which works because Python is dynamically typed.

Tuples are just two or more values with separate types lumped together, i.e. (Int, String).

For example, in Haskell, to get the elements of a map, there's this function:

    assocs :: Map k v -> [(k, v)]

which gives you an array of tuples, the first element of which is of type k (the map key type) and the second element being of type v (the map value type.)

(To you and everybody else)

Point taken - apparently I mistook the particular echo chamber I happen to be in at that moment for a more general symptom. Glad to hear!

I started a new contracting gig a couple of months ago, in Ruby. I had used it briefly years before in another project, but it was so long ago that I had to learn it again basically from scratch.

Although I don't really think the language is anything special (i.e. it's a standard dynamic OO language), what really turns me off Ruby is this dogmatic, almost religious aspect of its community.

Take POODR - it's more or less the community bible. If it's not written in POODR - don't do it. If it is - do it that way or else. It's POODR's way or the highway.

According to more experienced Rubyists more than 80% of the Ruby community use Rails. Rails is so widely spread that its development even fundamentally affects Ruby's roadmap.

Now irregardless of what you think about POODR or OO or dynamic types or whatever, a homogenous echo chamber filled with people chanting the same things over and over again is not a good thing.

As a counter example, take Javascript. Yes, it has its warts; its equality table is a joke. Ruby is a better thought out and implemented language in almost every aspect (although I do like Javascript's minimalism better, but that's a matter of taste I guess.) However, Javascript's community is as diverse, vibrant and experiment-friendly as it gets - there are the OO diehards, but there's also React, fantasy-land, macros, monads. People are trying out new things constantly.

Now I know you have monads in Ruby too or flow-like gradual typing libraries or rewrites of Clojure's spec. But at least where I work (and I work with some very experienced Ruby people) those libraries and the ideas they embody would never ever be considered as serious alternatives for anything. POODR or else.

Yes, easymotion is very nice! Still, it's a cognitive overload I'd rather not have.

My dream is having an actually working/accurate to the character consumer-grade eye tracker that people can glue onto their screen. Then to move around in vim, look at where you want to go and just press a key.

I think this alone would allow for a jump in effectiveness almost as great as the jump from notepad to vim.

> People would deem this impossible with C for practical purposes, but I think it's just a matter of responsibility, discipline and devotion.

When do you reach the point of saying "ok, that's enough discipline and devotion" and how do you know that what you've done is indeed enough?

Is there a study on "subjective quality of software written in C vs number of actual security vulnerabilities"? I think that would help shed some light on the real world implications of that particular mindset many C programmers tend to have :)