newgame

Fair enough.

Though I'd like to think that I presented clear arguments even though I didn't present _empirical_ evidence for my arguments. I presented ideas and logical steps how to arrive at them. Which, to me, makes it more than "just an opinion". Sure, you may disagree with the ideas and or the steps–it's not a mathematical proof, it's much softer. Sidenote: Nonetheless, I provided two links to empirical research finding counterintuitive results from TDD and from unit tests.

Clarification: I am not engaging in a strawman. I didn't claim that _you_ said these are the only dimensions. I tried to express, generally, that software quality is one of several important dimensions. I could have phrased it in a clearer way.

Software quality can be measured in different ways. Software quality is not the only dimension to care about when developing products.

I have worked on the initial version of www.stiki.io. Our vision was to create a super fast/lean wiki for teams. It's a subscription based model. No stakes in the company anymore but I think it might work for your use case.

Location: Berlin, EU

Remote: Yes

Willing to relocate: No

Technologies: Web/Frontend (HTML,CSS,JS), TypeScript, React, MobX, Kotlin, Android, Angular2, Java, Some backend experience (Node, Spring)

Résumé/CV: http://stackoverflow.com/story/eugenkiss

Email: [email protected]

Primarily interested in (mobile) UI app engineering position and, to a lesser extent, full-stack position.

Yes, much better. For anyone interested, here's a link with background information: http://stackoverflow.com/questions/1196586/calling-remove-in...

Good additional point that demands repetition: Don't mutate arguments to a (public) method if not absolutely necessary.

Just to be clear, that does not make the approaches "incorrect". The list "names" is not necessarily an argument to a method. It might be a local, intermediate result that does not have the risk of "mutation at a distance".

What about iterating from the end of the list in this particular case. This way you don't need a temporary list

    for (int i = names.size()-1; i >= 0; i--) {
        String name = names.get(i);
        if (name.startsWith("B")) names.remove(i);
    }

Admittedly, needing to use an explicit index counter is not as nice (and more prone to errors) as using the other for syntax. But one could imagine a language with e.g. macros that made the backwards-looping syntax more intuitive (I assume a single-threaded situation and an ArrayList).

Your general point still stands though.

Very cool to see my master's project here on hn!

Let me give you some background information. The idea for 7GUIs was born while I was writing my master's thesis Comparison of Object-Oriented and Functional Programming for GUI Development[1]. My advisor and I first agreed to compare Java7/Swing and Clojure/Seesaw. That's the reason why you see these implementations in the repository. Over the course of writing the thesis we changed the scope to compare JavaFX in Java and Scala as well as some novel FRP-inspired frameworks and all that with a GUI _programming_ usability benchmark which I named 7GUIs. I received great input from my expert reviewers, especially Tomas Mikula[2].

Anyway, 7GUIs is work in progress although nowadays I have much less time to work on it (not studying anymore but working). Not all implementations are complete (e.g. Android/Elm) and I'm sure the existing ones can be improved. So I'd be very happy if others would help to extend 7GUIs with more implementations or analyses. I still want to try out other approaches myself and compare them with 7GUIs but again time is limited sadly.

You can find much more information in the thesis[1] if you're interested. I've also written a short overview blog post[3] that deals with Reactive GUI Programming.

[1]: http://www.eugenkiss.com/projects/thesis.pdf

[2]: http://tomasmikula.github.io/blog/

[3]: http://www.eugenkiss.com/b/overview-of-reactive-gui-programm...

> The first case would be a compile time error in Kotlin

FYI, Kotlin will have the same behavior as Ceylon in the future, i.e. it's going to be a runtime error in the first case: http://blog.jetbrains.com/kotlin/2014/10/making-platform-int...

Another, imho, more appealing Swift on Android is Kotlin http://kotlinlang.org/

It shares many features with Xtend but offers more. It has the opposite "problem" wrt IDE support though: Great IDEA support but no Eclipse support.

From what I understand, although Conal Elliot coined the term FRP first in a relatively narrow sense, today the term FRP is used much more freely to describe reactive programming using functional building blocks (especially combinators like map, filter etc.).

There are some nice papers that give an overview of the FRP landscape.

“A Survey on Reactive Programming”: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.416...

“Towards Reactive Programming for Object-oriented Applications”: http://www.guidosalvaneschi.com/attachments/papers/2014_Towa...

If you're interested in FRP in terms of GUI programming, as described in the linked article, you should definitely checkout ReactFX [0], an FRP library for JavaFX, and also the author Tomas Mikula's blog [1] that contains very convincing examples of FRP's usefulness for real UI tasks [2].

[0]: https://github.com/TomasMikula/ReactFX

[1]: http://tomasmikula.github.io/blog/

[2]: http://tomasmikula.github.io/blog/2014/04/25/combining-react...

If you are confused by the term FRP and its different interpretations, I tried to summarize them in a stackoverflow answer: http://stackoverflow.com/questions/22795062/is-it-possible-t...

> His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production?

He pointed out that a more nominal type system is a solution. Because when you give meaningful names to your types the error messages will become clearer and not full of long, inferred types that reveal potentially confusing or unimportant implementation details.