newgame's comments

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.

> The trigger might have to be a little different

The "dot-autocompletion" has a pretty good usability in my opinion. You write down the name of the variable, enter a dot and you get a filtered list of methods that "make sense" to call on the receiver (key word: discoverability of the API).

How exactly would one implement the trigger with multimethods? I think this is an important consideration to make from a usability standpoint.

There is 'This Week in Rust': http://cmr.github.io/blog/categories/this-week-in-rust/

Maybe, in a couple of years, javascript (or any language like coffescript that compiles to javascript) will fit your needs, especially regarding the control flow problem.

Here's an excerpt of a blog post (http://blog.mozilla.com/dherman/2011/01/30/proper-tail-calls...) from a research engineer at Mozilla Labs who works on the new ECMAScript standard:

  >Having an officially guaranteed tail call mechanism   
  >makes it possible to compile control constructs like 
  >continuations, coroutines, threads, and actors. And, 
  >of course, it’s useful for compiling source languages 
  >with tail calls!

Of course, it is a long way to go until one is able to use these features. So, for now, you are better off to look somewhere else for your specific needs.

Here's a thread from the forums regarding love2d+luajit:

http://love2d.org/forums/viewtopic.php?f=4&t=2409

Seems to be somehow possible to get it working. It is not officially supported, though. I guess as luajit matures there is a decent possibility that it will be a supported option since games (even 2d) would benefit from the increased speed. OTOH portability of love2d would probably be decreased, too.

Yes, there is. Would you provide us with a link or some more information?

I concur with your points. These are some of the problems I had, too, coming from a python background. To add to your list: the # operator confuses a lot of people as can be seen on the mailing list (although its semantics are well-defined actually). Nevertheless there are also convincing reasons for these decisions. Have a look at e.g. http://lua-users.org/wiki/LocalByDefault. And the use of "end" certainly helps with anonymous functions.

Purely looking at the language resp. the consistency of the design I would even say that Lua is more beautiful than Python even though Lua has its share of warts. Note that this does not say anything about which language is easier to use in practice (which is Python imho).

But that aside, I think it is important to mention that comparing Lua and Python is a bit like comparing apples to oranges as they pursue different philosophies. Lua gives you just as much as you need but no more. This is the reason why it is so flexible and suited for embedding. Python, on the other hand, is a full blown general purpose programming language with a huge community/ecosystem.