latk

That would actually be a sound argument: If we assume a linear damage model for radiation exposure (which is a generally accepted model for these circumstances), then there is no safe dose. Instead, any exposure increases your lifetime risk of cancer. It is therefore not useful to talk about how medical imaging causes an individual case of cancer.

But for a larger population we can figure out what the cancer risk without medical radiation exposure would be, and what the observed probability is. We can then ascribe the difference to these medical tests. Obviously there are a number of ways to fuck up this analysis. Geological differences in the natural radiation dose shouldn't be underestimated. However, almost half of the lifetime radiation dose of a human does come from medical applications, and it would certainly be good to reduce that.

Indeed. I would also like to see that British study that claims a link between CTs and leukemia – I smell selection bias. It is however true that a CT does imply a significant radiation dose.

This article is especially frustrating in that the authors seem to be doctors in the appropriate fields. I assume they just went too far in dumbing down the matter, which together with their source-less references to a dazzling amount of numbers and studies ends up obscuring their main point: A culture of using the “best” medical tool available instead of the “appropriate” tool can have adverse health effects, and has to stop.

All in all, there is a reason this article was filed under Opinions, not Science.

This article was trying its hardest to reinterpret “we have almost no data, and what we have looks boring” into a sensationalist story of master killers. 1/10 would not read again.

Maybe a solution would be to only communicate the bounds of a value rather than the value itself. E.g. Instead of “party A has 35% with sigma=2%” something like “we expect party A to have 33%–37%”. Providing a range is shorter than explaining the SD, and can be visualized easily, e.g. in a bar chart.

Two words: medicines and vaccines. Of everything there is a “too little” and a “too much”, which is especially true with programming paradigms. Some people write procedural code where OOP should be used, others abuse OOP for something that should have been done in a functional manner, and sometimes functional programs should rather be expressed with procedural code.

The argument that every function has arity 1 is technically true (this is the whole point of currying) but is not useful when definitions like "let a b c = ..." suggest other semantics. It's possible you've had a difference experience with this, but I tend to get confused when the semantic argument list isn't delimited.

There is nothing wrong with relying on the type checker, except that it tends to add cognitive overhead.

Currying can obfuscate what is applied to what. Consider in any ML language "a b c d" – we can see that "a" is a function, but we have no idea of its arity. Uncurried, it could be: "a(b, c, d)", "a(b, c)(d)", "a(b)(c, d)", "a(b)(c)(d)" (oh, that's the curried form again). Especially when function definitions are implied through pattern matching, it is hard to understand the contract of a function at a glance.

As a reader of that code cannot easily understand whether the number and type of arguments is correct, one has to rely on the type checker that everything will work out.

However, this is more of a criticism of ML syntax than of currying – all things are good in moderation.

This is a standard feature of many languages or libraries, and generally known as array programming – something APL is known for. It crops up in numerical libraries like "numpy" (Python) or "PDL" (Perl) where selected scalar operations distribute over the whole collection. This is great when using collections of numbers, but is not very generalizable: It may not be possible to distinguish whether a method was called on a collection or all items in the collection. One solution would be a “mapping method call operator” like "!" (it's like a method call "." and a shell pipe "|") – but now we have an explicit "map" again.

I think an explicit "map" is more flexible in a general-purpose language. Some languages do interesting experiments with this, e.g. Perl6 which uses “hyperoperators” to precisely control how a given operator is applied.

The judgement on the case would probably not be much different, considering that the Prenda lawyers have also lost various other cases without naming any ISPs as defendants.

This order discusses a motion by Comcast and AT&T for attorney fees, which the judge deems appropriate because (a) Prenda unnecessarily elongated the process by naming the ISPs as co-defendants without any valid claim, and (b) as a reprimand for Prenda'a “willingness to lie to the Court” and “disregard […] of justice”.

The damages are tabulated as follows:

    Anthony Smith (main defendant)
      187.2h á $200.00/h – $409.00/h →  $72,367.00
    AT&T
      158.7h á $110.00/h – $295.00/h →  $38,987.83 + $870.29
      215.0h á $250.00/h – $555.00/h →  $80,524.50 + $864.92
                                  total $119,637.05
    Comcast
      132.0h á $212.50/h – $531.00/h →  $57,144.23 + $806.98
       36.9h á             $300.00/h →  $11,070.00
                                 total  $69,021.26

                      TOTAL JUDGEMENT: $261,025.11

So yes, Prenda would have to pay a lot less attorney fees hadn't they got the ISPs involved, and possibly even none at all, considering that the motion for fees was brought forward by the ISPs.

You can read the judgement yourself at https://ia600705.us.archive.org/3/items/gov.uscourts.ilsd.58...

This has nothing to do with patents. The article describes a case of copyright trolling, which is a completely different matter.

Of course there are similarities between copyright trolls and patent trolls: Both acquire certain rights and try to extort money out of small actors for allegedly infringing use. In both cases the troll's calculation is that the proposed settlement fee is just below the cost of an effective defense.

Different languages get a different amount of execution time for the test cases. A factor is given in the table of available programming languages. It is interesting to see where the languages are grouped:

Compiled Languages (1 × time limit): C, C++, Perl, Clojure, JavaScript, Haskell.

Java (2 × time limit + 2): Java.

Scripting Languages (3 × time limit): Python, Ruby, PHP.

I guess the "+2" for Java tries to account for JVM startup. But if Clojure will also run on the JVM, why doesn't it get the same advantage?

I am also surprised to see Perl being grouped with the compiled languages, as it actually has a performance profile similar to CPython (which I assume will be used for Python – the entries for Python, Java, Ruby, PHP, Clojure don't mention which of the myriad interpreters/VMs will be used).

The parent post meant: “The Perl5 language can never increment its major version to 6, as the Perl6 name is already taken” – which is silly, as Perl5 is currently at version 18.

Java isn't a bad language, but the point is that it doesn't offer much what other languages don't. It's unique selling point is that it is there, and that it's widespread.

Said politely, Java is “conservative” to include new features. Take for example lambdas, which make writing async code, inversion of control, and yes, functional programming much more easy. All modern competitors to Java have lambdas: C++11 and C# (LINQ! need I say more?), plus basically everything except C. Java 8 has still to ship. A more flexible object system, e.g. using traits, would not be impossible to implement, but I doubt this will show up before C++ has them ;-)

Ecosystem? Well, that is a good argument, but other languages have ecosystems as well.

Nobody has ever used Ruby because he thought it might be faster than Java. Java primarily competes against C++, not against “scripting” languages like Ruby and Python which have significantly shorter edit-(compile)-run cycles. Each of these languages also have unique features that are difficult or cumbersome to model in Java (functional programming, metaprogramming, modern object systems).

I do not doubt that there can be cases where a transition like Python → Java can make sense, but it would be silly to assume this would generally be a good idea.

Good point(s), especially #4. The article compares an 80s language (C++) to a 90s language (Java), not to more recent compiler toolchains. Admittedly, there aren't many options here, and e.g. Scala (which I hope will be covered in future articles) relies on the java toolchain.

Edit: C++ and Java also have different cultures. The simplest compilation with g++ is "g++ foo.cpp -o foo", which isn't much more complex than "javac Foo.java". The fine-grained options clang/g++ give you are part of the “you pay for what you use”-mentality of C++.

The UN do a world of good. Unfortunately, the US – which are the central actor in this surveillance scandal – do not respect the UN and other institutions of international governance.

LyX is halfway there. It is a visual editor for LaTeX, but it does not actually show the final result. Instead, it operates on an intermediate representation. Stuff like section headings, math environments and tables are shown correctly (unless you use non-standard features), but margins and spacings are not. Ergo it isn't suitable for designing, or nitpicky typography. It calls this approach WYSIWYM – what you see is what you mean.

The user experience is quite similar to your regular word processor, except that the “paper” metapher is removed.

I tried it out for a while, but I feel more productive (and more in control) when using a regular editor with nice syntax highlighting.

You are correct in stating that LaTeX is no silver bullet. The clear disadvantage of LaTeX is the tweak-recompile cycle, whereas graphical tools have instant feedback which is more suitable for design. But for automated typography (≠ design), it is still unsurpassed after all those years.

The default LaTeX styles are still way prettier and easier to read than the random muck (12pt Times, small margins) that would be more widespread otherwise. For scientific papers this is truly awesome, especially when the author does not care about typography. But you are right, LaTeX is not the correct tool for every job.

What are you talking about? Word does not manage spacing (and other layout) on the level LaTeX does. Word processors usually allow you to type multiple adjacent spaces, which does not make any typographic sense. Instead, LaTeX uses spaces of different variable widths and heights. In some configurations, it will follow the double-width space after a sentence-convention.

Terrorism implies violence or threats of violence. Neither Greenpeace nor Chris Eaton can be reasonably labeled as “terrorist” or connected with terrorist actions. Calling such organizations and people terrorist is disrespectful to victims of actual terrorists.

It can be argued that eco-activism hurts “the economy”. But that argument goes both ways: Some practices like whaling, mining, fracking and deforestation do (or can do) massive ecologic damage, and are not sustainable.

On his blog, Mr. Eaton mentioned the possibility that he may be subject to such intimidation precisely because of the inability to connect him with illegal activities (http://chriseatondotnet.tumblr.com/post/59902438104/freedom).

The most amazing discovery I made was a minor mode that put a battery indicator into the status line. Emacs as OS – effectively true.

For me: a touchpad as the primary pointer input device. I use two fingers for scrolling and a two-finger tap as middle mouse button clicks. I really like that setup for web browsing, but it frequently messes up code in the editor.

Python is a very strict and comparatively easily parsed language. Python 3 is the clear successor to Python 2, and feels mostly the same for a programmer.

The idea for Perl 6 was the same: Clean up the language, add new features at the expense of compatibility, and create a v5 → v6 transition tool. During the evolution of Perl 6, this original goal became less important. Nowadays, Perl 5 and Perl 6 are seen as two sister languages in the same family, which take inspiration from each other, but are independent. There won't be mass migrations to v6 once it “arrives” (it already did in the form of Rakudo Star). There are, however, efforts to run v5 and v6 code in the same VM.

You make some very good points esp. wrt verbosity. However, I don't care about portability or not using experimental features for personal or exploratory projects: stability is silver, conciseness is gold. The "state" subs are a consequent extension of the variable declaration keywords "my", "state", and "our". I can see myself using "my subs" in the future, the other possibilities have less practical use. "my subs" are proper closures, so they are not shared.

But, somebody will probably write a "lexsub" pragma that does away with the "no warnings ...", and portability becomes less of an issue over the course of time, much like I can nowadays treat the features of v5.10 as given.

Perl had nested functions since v5, just with akward syntax. Does Python have proper <del>variable declarations</del> closures? That is more of a dealbraker than non-experimental nested function syntax for me ;-)

In the end, everything is syntax. In the first solution, the inner sub would be called as "$inner->()" or "&$inner()". With lexical subs, we get the much nicer syntax "inner()". This decreases the syntactic pain when structuring your code to use nested functions, thus encouraging good design.

Oh, and I guess lexical subs can have prototypes, which were ignored when calling a coderef with `&` or `->()`. This allows to create really nice, but properly scoped pseudosyntax.

Almost ;-) The current perl version is 5.018000, so that would take 982 releases until the numbering scheme breaks down. Of course, Perl v-strings can have elements of INT_MAX each, but I doubt such high numbers would ever be used, for back-compat reasons.

That article was more about declarative/functional programming than about the details of the Haskell syntax.

Types are capitalized. Lower-case types in signatures are placeholders in polymorphic functions. The signature

    (.) :: (b -> c) -> (a -> b) -> (a -> c)

means: The function that is the . takes a first argument (g) that maps some type b to some type c. The second argument (f) maps some type a to the type b. This ensures that you can always do g(f(x)). The result of the function . is a function that maps the type a (what f takes) to type c (what g returns).

The type signature only deals with types; this is not connected to the names of the function parameters.

Lambda expressions are written without types; they can be inferred (i.e. the return type is not void* , but exactly determined by the compiler). A lambda expression in lambda calculus notation would be written "λx.(+ x 1)". Haskell slightly modifies this, and allows infix operators: "\x -> x + 1"(the \ looks a bit like λ). Punctuation functions are infix by default.

About the data expression: This constructs a new type (typedef). The "|" operator is just used in a declarative fashion. Every time you write Empty in your source code, that thing is a list. The expression "list = Cons foo Empty" would create a list of one element (foo). A cons cell is a pair, this terminology is popular in Lisp. These confusing data type constructors allow pattern matching, as you have seen in the definition of "map": If the list is Empty, return Empty. If the list is a Cons of an element and another list, then return a Cons of (result of our function applied to that element) and (the rest of the list mapped) – recursion.

The main reason students should use non-low-level languages is to encounter new features, and new programming paradigms. Languages like C or Java don't have closures; this rules out real higher order functions. The type system of Haskell is refreshing. Object orientation in traditional languages seems crippled once you see CLOS, Ruby, Smalltalk or Perl6. The dynamic syntax of Lisp or Perl6 is interesting.

Even a modern low-level language like Go or OCaml is “better” than C(++), as memory safety rules our a majority of bugs. While everybody should understand the lowest level basics, there are modern languages with extraordinary features and great performance (2–300 times C) out there to get the actual job done.

You could have also noted that the choice of the language is largely irrelevant if the code is tested by language-agnostic tests. This would allow the lecturer to specify a number of languages that are available, and require the students to include a makefile to compile/build the actual project.