So what dimensions do you propose to care about? Do the dimensions I mention not matter at all? If they do matter then I think there is still a point here.
You are engaging in a strawman. I don't claim anywhere that these are the only dimensions to care about, I simply claim that these are some things we've noted that testing leads to improvements.
Ultimately though my primary claim is simply that I see less value in opinions vs evidence.
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
This statement is an implied counter argument. If not then what is it? If so, then I suggest it is a strawman as I never argued against that.
> I'd like to think that I presented clear arguments
If you are referring to the original article I was not aware you were the author, so my response above simple responded to your statement in context and not the article as a whole. I'll do so below.
I don't argue that the article presents it's arguments clearly, though I don't necessarily agree with them. Actually, my main issue is with the rhetorical style it is presents it in.
It tries to hard to sell less testing as a solution to testing pain, rather than exposing it as a possible idea to be discussed. Using mostly a combination of appeals to authority and association with the term "lean" as rhetorical devices. This, to me, smells like the last generation "Agile" snake oil.
On separate level I do disagree with presenting logical reasoning as a counter argument to empirical evidence. Logical reasoning may be a compelling reason to seek empirical evidence through trial and experimentation, but reasoning alone can't invalidate evidence. With that said, I do believe some other commenters here mentioned that there is evidence on both sides of this debate, so I won't say your idea's are not worth exploring, though they definitely contradict my own experiences with testing.
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.
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).
Both implementations are incorrect as they needlessly mutate the input list:
List<String> namesNotStartingWithB = new ArrayList<>();
for (String name : names) {
if (!name.startsWith("B")) {
namesNotStartingWithB.add(name);
}
}
Imagine a scenario where you're filtering one of the arguments to a method: the input will be mutated with no indication to the caller (or in the method signature), causing bugs, iterator invalidation etc.
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".
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.
I am building a side project app in Kotlin right now and so far it goes well.
There are some minor problems with IDE support (kotlin source folder is not marked as a source folder when mixing Android and Kotlin together), but that is fixed with one click of a button.
I really like it!
I don't know how kotlin fares in practice for android, but I experimented with scala on android a few years back successfully.
The thing is, android doesn't really need a marketing blitz as big for alternative languages to be usable. dex converter did well enough on jvm bytecode.
Kotlin for instance doesn't support something similar to active annotations aka compile-time macros. This is a very powerful concept. Here's an example of an annotation from the Xtendroid project (https://github.com/tobykurien/Xtendroid/blob/master/examples...)
Does that violate the new ruling in favor of Oracle lately? If not, what if Oracle pursues that in the future, too? If I were Google I'd be like on needles about continuing to support Java on Android, and I'd start looking for a complete replacement (which will take years to come to fruition anyway, so all the more reason to start now).
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.
This is not true at all. It is only recently and only in the SF hacker bubble that FRP has been co-opted to mean anything that is functional, reactive, and programmed.
Outside, FRP still means FRP, and using the term will automatically put your work in a certain specific bucket that you might not want to be in.
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.
Most programming languages with Damas-Hindley-Milner do not prevent you from using explicit type annotation, and inventing semantically meaningful type names.
More importantly, I think the reason why error messages are sparse and not meaningful in languages with Damas-Hindley-Milner is that nobody bothered to improve the situation. And the reason why nobody botheres is that it's simply not a problem in practise. Any even moderately experienced programmer can easily detect and fix typing errors as they are given in Haskell, Ocaml, F#, Scala etc.
