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: eugen@eugenkiss.com

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.

Just a remark.

The others are (by their own descriptions) micro-frameworks, suitable for smaller applications with 10 URLs or so.

I don't think the attribute micro relates to the size of the projects you can create with these frameworks but rather the way they are written: Keep the core small and rely on external libraries for specific functionality.

I'd like to add that I already count Javascript as a "big language" as I wrote:

As we all know C, C++, C# and Java are these big mainstream languages of today with “recent” additions Python, Ruby, Javascript and, especially in the Apple world, Objective-C.

I totally agree with you that Javascript is going to get much bigger but to me it is already big so it doesn't even need to contend against the other languages in my blog post ;).

What I meant by that is that PHP is admittedly used widely on the web but almost nonexistent in other "niches" like game programming, kernel programming, artificial intelligence, high performance computing etc.

I'm thinking of the ecological meaning of the word niche not the meaning of "something small".

Yes, you are absolutely right. In fact I had started a chapter about the "far future" where I wanted to elaborate more on the computer architecture change and its effect on programming languages. But I thought the scope would become too large.

If you are interested I gathered some links about the "far future":

* https://channel9.msdn.com/posts/Charles/Jonathan-Edwards-Pro...

* http://lambda-the-ultimate.org/node/4088

* http://lambda-the-ultimate.org/node/4090

Well, that is highly subjective of course but I give you some examples:

- The fact that the syntax is almost constantly of this form (function arguments) and that you can create sophisticated "blocks" out of a small set of language features

- Recursion is an essential part of the language it is fun to implement algorithms that way

- Great IDE (DrScheme)

It all boils down to that you have a simplistic, consistent, "small" language without ambiguities and a rapid feedback if you use DrScheme (because of the REPL, Debugger...).

If you hint at something graphics wise with "wow" I can tell you that our instructors showed us some games in scheme that other students created as assignments (we implemented minesweeper) and source code wise they were quite good. They, however, gave us their hombrew object oriented pack that we should use. And this is another "wow" in Scheme (and probably in any other LISP). You can build your own object system - something that would be impossible in for example Java... (albeit it is possible in lua through metatables and also in javascript and theoretically should be possible in Python, too. However the flexibility regarding the syntax is on scheme's side). Frankly, implementing an object system would be overkill for your niece but the fact that it is (relatively easy) possible is a "wow" IMHO.

If you install the DrScheme Environment you get a lot of example applications (Card Games...). So you can easily get something visual done in DrScheme.

* I have to note that I'm talking about Racket Scheme (formerly PLT Scheme)

I don't know about your niece, but if I'd be 12 again I think Scheme would have been ideal because the syntax is actually very easy and the language is very explicit (that's important for someone without programming experience). She, of course, does not need to learn about continuations, macros etc. only the basics.

Although python (2.6) looks easy it has its ambiguities (for newcomers to programming); list.sort() <-> sorted(), default arguments issues, scoping issues, if a statement doesn't fit a line you have to enclose it in parantheses... the list goes on. Lua and especially Javascript aren't better either.

I can only say, although I had some experience in functional programming, that scheme was really an eye opening experience when I learned it in university. Plus, it made things clearer about things I did with Javascript/Python in the past.

DrScheme is a great environment for learning Scheme and programming in general and there is tons of learning material about scheme. Maybe that http://world.cs.brown.edu/ is something for your niece (I haven't read it).

Going from Scheme to Lua/Python/Javascript is then a small step and you have a saner picture about what happens in those languages.

Also going from Scheme to Lua won't be such a cultural shock. Just like the list is the primary data structure in Scheme the table is the primary data structure in Lua. And with Lua under her belt she can try LÖVE.

BTW, I think pygame is too low level. One can argue it is better for learning the concepts but I don't know. When I was younger I wanted to have results fast. In that respect I think LÖVE is better. And although I would not recommend Java for your niece there is a nice game framework called Pulpcore which let's you quickly get something done.