We are having another PLATEAU workshop at SPLASH 2014. We have a new category for "Hypotheses Papers" and thought this would be particularly appealing to the LTU community.
Programming languages exist to enable programmers to develop software effectively. But how efficiently programmers can write software depends on the usability of the languages and tools that they develop with. The aim of this workshop is to discuss methods, metrics and techniques for evaluating the usability of languages and language tools. The supposed benefits of such languages and tools cover a large space, including making programs easier to read, write, and maintain; allowing programmers to write more flexible and powerful programs; and restricting programs to make them more safe and secure.
PLATEAU gathers the intersection of researchers in the programming language, programming tool, and human-computer interaction communities to share their research and discuss the future of evaluation and usability of programming languages and tools.
Some particular areas of interest are:
- empirical studies of programming languages
- methodologies and philosophies behind language and tool evaluation
- software design metrics and their relations to the underlying language
- user studies of language features and software engineering tools
- visual techniques for understanding programming languages
- critical comparisons of programming paradigms
- tools to support evaluating programming languages
- psychology of programming
PLATEAU encourages submissions of three types of papers:
Research and position papers: We encourage papers that describe work-in-progress or recently completed work based on the themes and goals of the workshop or related topics, report on experiences gained, question accepted wisdom, raise challenging open problems, or propose speculative new approaches. We will accept two types of papers: research papers up to 8 pages in length; and position papers up to 2 pages in length.
Hypotheses papers: Hypotheses papers explicitly identify beliefs of the research community or software industry about how a programming language, programming language feature, or programming language tool affects programming practice. Hypotheses can be collected from mailing lists, blog posts, paper introductions, developer forums, or interviews. Papers should clearly document the source(s) of each hypothesis and discuss the importance, use, and relevance of the hypotheses on research or practice. Papers may also, but are not required to, review evidence for or against the hypotheses identified. Hypotheses papers can be up to 4 pages in length.
Papers will be published in the ACM Digital Library at the authors’ discretion.
Workshop paper submission due - 1 August, 2014
Notification to authors - 22 August, 2014
Early registration deadline - 19 September, 2014
Josh Bloch, former Chief Java Architect at Google and Distinguished Engineer at Sun Microsystems.
I want to archive this solution if anyone else hits this issue.
On x64 Windows installing 2013.2.0.0
Close all running programs, for me this included but was not limited to eclipse, skype and firefox. I'm not sure which was the offender. Now re-run the installer and you should be good.
This post doesn't need upvotes but i want to store this solution for if someone searches for it.submitted by IndexPlusPlus
[link] [1 comment]
Sorry for the newbie question, but Google wasn't too helpful (googlebot doesn't parse punctuation).
Is there a Monadic equivalent to <* that I've overlooked? Something like << ? I find myself doing things like:mobitFoo >>= (\x -> bar >> return x)
ordo x <- mobitFoo bar return x
Also, I've only been Haskelling for a little while, and I'm pretty sure this is reason #97 I've found why Applicative should be a superclass of Monad.submitted by Considered_Harmful
[link] [17 comments]
Hi! I've started reading Learn you a haskell for great good! as I suppose most of you guys have read. I'm at the data type section where the author is making a 3D vector type. He goes on saying
Let’s implement a 3D vector type and add some operations for it. We’ll make it a parameterized type, because even though it will usually contain numeric types, it will still support several of them, like Int, Integer, and Double, to name a few.
data Vector a = Vector a a a
But what I truly want is "data Vector = Vector Num Num Num" right? Why is this not possible (or if it is, how to do it?). Num takes a parameter so I tried something like "data Vector a = Vector (Num a) (Num a) (Num a)" but this did not work. So what's the deal?
Thanks for the help!submitted by frerom
[link] [36 comments]
-- Sample test data
type Sales = (String, String, Int)
-- First String is title of track, Second String is artist name, Int is number of tracks sold
testData :: [Sales]
testData :: [("Me and My Broken Heart","Rixton",5),("It’s My Birthday","will.i.am",4),("Problem","Ariana Grande",3)]
-- record a sale of a track
sellTrack :: String String Int -> [Sales]
sellTrack :: trackName artistName numberSold = [Sales] ++ [(trackName, artistName, numberSold)]
I get the error "illegal literal in type : "Me and My Broken Heart"
Thanks in advance.submitted by Rifaz1
Just a quick note on the relationship between ESI scores and allele frequencies. Allele frequency differences is of course related to – perhaps even the definition of – diversification, but the information we gain from observing an allele also depends on the specific allele frequencies involved. The graph below shows how this is related.
Each line represents a fixed allele difference, from 0.05 at the bottom, to 0.95 at the top, and the x-axis is the average allele frequency between populations. We see that for small differences, the actual frequencies matter little, but for moderate to large allele differences, allele frequencies near the extremes have a large effect.
Note that this is information per allele, and thus not ESI (which is the expected information from observing the site, in other words a weighted average over all alleles).
Hi everyone, new to haskell and trying to open my .hs file.
I've tried ":cd" and ":L" both the haskell platform and my .hs file is on my desktop.
Any help would be appreciated, Thanks all.submitted by Rifaz1
[link] [2 comments]
A few weeks ago I asked people to predict, without trying it first, what this would print:perl -le 'print(two + two == five ? "true" : "false")'
(If you haven't seen this yet, I recommend that you guess, and then test your guess, before reading the rest of this article.)
People familiar with Perl guess that it will print true; that is what I guessed. The reasoning is as follows: Perl is willing to treat the unquoted strings two and five as strings, as if they had been quoted, and is also happy to use the + and == operators on them, converting the strings to numbers in its usual way. If the strings had looked like "2" and "5" Perl would have treated them as 2 and 5, but as they don't look like decimal numerals, Perl interprets them as zeroes. (Perl wants to issue a warning about this, but the warning is not enabled by default. Since the two and five are treated as zeroes, the result of the == comparison are true, and the string "true" should be selected and printed.
So far this is a little bit odd, but not excessively odd; it's the sort of thing you expect from programming languages, all of which more or less suck. For example, Python's behavior, although different, is about equally peculiar. Although Python does require that the strings two and five be quoted, it is happy to do its own peculiar thing with "two" + "two" == "five", which happens to be false: in Python the + operator is overloaded and has completely different behaviors on strings and numbers, so that while in Perl "2" + "2" is the number 4, in Python is it is the string 22, and "two" + "two" yields the string "twotwo". Had the program above actually printed true, as I expected it would, or even false, I would not have found it remarkable.
However, this is not what the program does do. The explanation of two paragraphs earlier is totally wrong. Instead, the program prints nothing, and the reason is incredibly convoluted and bizarre.
First, you must know that print has an optional first argument. (I have plans for an article about how optional first argmuents are almost always a bad move, but contrary to my usual practice I will not insert it here.) In Perl, the print function can be invoked in two ways:print HANDLE $a, $b, $c, …; print $a, $b, $c, …;
The former prints out the list $a, $b, $c, … to the filehandle HANDLE; the latter uses the default handle, which typically points at the terminal. How does Perl decide which of these forms is being used? Specifically, in the second form, how does it know that $a is one of the items to be printed, rather than a variable containing the filehandle to print to?
The answer to this question is further complicated by the fact that the HANDLE in the first form could be either an unquoted string, which is the name of the handle to print to, or it could be a variable containing a filehandle value. Both of these prints should do the same thing:my $handle = \*STDERR; print STDERR $a, $b, $c; print $handle $a, $b, $c;
Perl's method to decide whether a particular print uses an explicit or the default handle is a somewhat complicated heuristic. The basic rule is that the filehandle, if present, can be distinguished because its trailing comma is omitted. But if the filehandle were allowed to be the result of an arbitrary expression, it might be difficult for the parser to decide where there was a a comma; consider the hypothetical expression:print $a += EXPRESSION, $b $c, $d, $e;
Here the intention is that the $a += EXPRESSION, $b expression calculates the filehandle value (which is actually retrieved from $b, the $a += … part being executed only for its side effect) and the remaining $c, $d, $e are the values to be printed. To allow this sort of thing would be way too confusing to both Perl and to the programmer. So there is the further rule that the filehandle expression, if present, must be short, either a simple scalar variable such as $fh, or a bare unqoted string that is in the right format for a filehandle name, such as `HANDLE``. Then the parser need only peek ahead a token or two to see if there is an upcoming comma.
So for example, inprint STDERR $a, $b, $c;
the print is immediately followed by STDERR, which could be a filehandle name, and STDERR is not followed by a comma, so STDERR is taken to be the name of the output handle. And inprint $x, $a, $b, $c;
the print is immediately followed by the simple scalar value $x, but this $x is followed by a comma, so is considered one of the things to be printed, and the target of the print is the default output handle.
Inprint STDERR, $a, $b, $c;
Perl has a puzzle: STDERR looks like a filehandle, but it is followed by a comma. This is a compile-time error; Perl complains “No comma allowed after filehandle” and aborts. If you want to print the literal string STDERR, you must quote it, and if you want to print A, B, and C to the standard error handle, you must omit the first comma.
Now we return the the original example.perl -le 'print(two + two == five ? "true" : "false")'
Here Perl sees the unquoted string two which could be a filehandle name, and which is not followed by a comma. So it takes the first two to be the output handle name. Then it evaluates the expression+ two == five ? "true" : "false"
and obtains the value true. (The leading + is a unary plus operator, which is a no-op. The bare two and five are taken to be string constants, which, compared with the numeric == operator, are considered to be numerically zero, eliciting the same warning that I mentioned earlier that I had not enabled. Thus the comparison Perl actually does is is 0 == 0, which is true, and the resulting string is true.)
This value, the string true, is then printed to the filehandle named two. Had we previously opened such a filehandle, say withopen two, ">", "output-file";
then the output would have been sent to the filehandle as usual. Printing to a non-open filehandle elicits an optional warning from Perl, but as I mentioned, I have not enabled warnings, so the print silently fails, yielding a false value.
Had I enabled those optional warnings, we would have seen a plethora of them:Unquoted string "two" may clash with future reserved word at -e line 1. Unquoted string "two" may clash with future reserved word at -e line 1. Unquoted string "five" may clash with future reserved word at -e line 1. Name "main::two" used only once: possible typo at -e line 1. Argument "five" isn't numeric in numeric eq (==) at -e line 1. Argument "two" isn't numeric in numeric eq (==) at -e line 1. print() on unopened filehandle two at -e line 1.
(The first four are compile-time warnings; the last three are issued at execution time.) The crucial warning is the one at the end, advising us that the output of print was directed to the filehandle two which was never opened for output.
[ Addendum 20140718: I keep thinking of the following remark of Edsger W. Dijkstra:
[This phenomenon] takes one of two different forms: one programmer places a one-line program on the desk of another and … says, "Guess what it does!" From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz., to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language.
But my intent is different than what Dijkstra describes. His programmer is proud, but I am discgusted. Incidentally, I believe that Dijkstra was discussing APL here. ]