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.
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.
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).
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.
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.
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].
> 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 "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.
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.
>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.
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.
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.
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.