coriny

Ah sorry, I missed a key phrase out - _pre-tax_ UK prices are the highest, and they are by a long way. Post-tax they're nearer the middle as the UK has by far the lowest energy taxes.

Unfortunately it's too late to edit my comment for clarification.

The wikipedia link: https://en.wikipedia.org/wiki/Energy_subsidies. e.g. in the UK north sea oil exploration is heavily subsidised: http://www.independent.co.uk/news/uk/politics/uk-government-.... Of course there's lots of politics and commercial interests here, so I don't overly trust the upfront numbers given by articles in newspapers.

As a reference point the UK has about the lowest consumer energy taxes in the EU, and the highest consumer prices.

e.g. https://hyper.sh/howto/

> This guide shows how you can launch a full functional Jenkins server in one minute And then configure this Jenkins works with you Github account.

It's probably linked to this quote:

> I will spend my last dying breath if I need to, and I will spend every penny of Apple’s $40 billion in the bank, to right this wrong,” Jobs said. “I’m going to destroy Android, because it’s a stolen product. I’m willing to go thermonuclear war on this.

The primary strategy appears to have been to use IP courts to make Android undistributable rather than competing directly, as Apple have no interest in capturing the bottom 90% of the mobile market. The Oracle v Google case is probably part of the same campaign.

The post-WW2 soft power strategy by the US was awesome and extremely effective. Sadly, it seems that by the 70s the pentagon had become solely obsessed with the projection of hard power. I personally reckon this has a huge amount to do with the decline of the US's popularity around the globe in the subsequent decades.

It's a difficult thing to compare, so I wouldn't totally believe the absolute comparisons, but generally most countries in Europe are considered to have higher social mobility than the US. The exceptions are Italy & the UK, with maybe France level pegging with the US.

e.g. https://www.oecd.org/eco/growth/NERO-22-June-2015-income-ine...

Wow, right. When I first saw the link I thought, "Excellent, MS are contributing some good to the world via accessibility tools". By the time I had scanned the page, I had come to the conclusion that it was just marketing blather for their equivalent of material design.

Maybe they're testing AI-generated content?

Maybe it looks like that to you because you're unfamiliar with this format? To me it looks like he's written a short bio that's ready for dropping into where it's needed.

e.g. top hit on google: http://smallbusiness.chron.com/write-short-bio-yourself-5728...

As a habit it is bad, but this is actually standard for short bios. It allows it to be dropped in place directly for conferences, PR shots, news articles, etc without any rewrite.

How do you define what a society wants? There is not an implicit goal when a society exists, there is just a collective of individuals who happen to have some interaction. So essentially, this is the function of politicians in a democracy: to reconcile the irreconcilable views of individuals. However, as with all compromises, often no one is left happy...

I'm not explaining things well I think, hope you can make sense of that!

I'm not sure, I kind of disagreed with both statements you were making, and decided to pick holes in the latter, since it was providing support for the former.

If I'm missing a "wider point", can you elucidate?

> If farmers can get rich growing crops, there will never be a famine.

You're not considering that food has a limited shelf life, seasonal, difficult to distribute efficiently and the customers have highly variable purchasing powers. Also local production is incredibly sensitive to local environmental variation. We already produce enough food to feed nearly twice the global population, and yet plenty of people are malnourished.

I would personally suggest that the best way to prevent famines is to improve food storage and distribution methods, and have robust systems for environmental or conflict induced local famines. Though the unbalanced nature of consumer wealth is also important - it makes sense to waste 50% of your crop selling it in Europe if you can sell it for 3x as much than locally. So maybe the best thing is simply to raise the wealth of poorest people in the world?

Nicely demonstrated in Derren Brown's "The System": https://www.youtube.com/watch?v=9R5OWh7luL4.

Though we've rather ruined the twist ...

> Ireland failed to collect the correct amount of money owed to the EC

Just for your info this isn't what happened, it's Ireland's tax money. The EC doesn't collect taxes. Instead the EC ruled that Ireland was providing illegal state aid (under EU rules) to Apple through its tax arrangements. So this loophole was nullified and Apple have to pay the back taxes to Ireland. The EU gets nothing (the EC is the executive body of the EU).

This investigation into dodgy corporate tax deals has nothing to do with Brexit (note that this is about Ireland, not the UK), and it's been going on for most of a decade now.

I surprised there hasn't been more suggestion of this. There's are known classic scams for stealing laptops from security lines - the one I saw demonstrated used two people and a common type of laptop case. The entire context here is suspicious - I would be willing to bet at least pennies that the laptop will never turn up.

I think the URL everyone is looking for is http://www.truecaller.com/unlist. Impossible to check if it works though without creating an account and handing over all your details.

They really should provide a "Is my number listed?" search (and maybe a "Who do I blame if it is?"). Also, they should probably add some verification you own the number I guess, since I was able to delist my wife's without question.

I wasn't think the US, particularly amongst the general population, particularly cared if the UK was invaded. There was strong anti-British sentiment, further boosted by the UK effectively defaulting on its WW1 war debts to the US, much of which came out of "ordinary" Americans' pockets.

:) "perl harbor", very HN typo ...

I know _ad hominem_ is generally uncalled for, but he's not known for doing anything else. As the Guardian tech editor he had a reputation for showcasing (i.e. Boot Up, which got pretty toxic) and writing articles attacking Android. Most of it based on tedious market analysis.

Sorry, I'm going to nit pick, but non-coding and "junk" aren't the same thing:

Non-coding just refers to not being translated to protein, and we know (as you list, more for the benefit of others) that there are many non-coding functional elements.

Junk DNA is non-conserved DNA (e.g. shows only neutral selection). And if it's not being selected for or against, then it probably doesn't have much effect either way.

I think people get emotive over the term 'junk'. It was always just a phrase rather than a technical description. We know that ~80%, maybe a little more, of the genome does not show conservation. If the function was important to the survival of the organism it have been selected for and thus evolutionarily conserved - hence the 85% "junk" figure. This does not mean that it isn't entirely biochemically inactive, or that there are some longer range periodicities in the sequence that are not elucidated. And as another commenter has noted, about half of the genome is composed of remnants of the Alu element, which jump about occasionally, but mostly degrade into total inactivity (sometimes being reactivated by recombining broken parts together).

What has gained a lot of attention was the massive ENCODE project, which sought to provide a detailed atlas of biochemical function in the human genome. The headline figure from there has been that 80% of the human genome has some function. There's a lot of controversy (understatement hat on) on the basic experimentation done for ENCODE, the structure of the project, the usefulness of the data produced and how they define biological activity.

The debate possibly got a bit out of control - the most sarcastic peer reviewed article I have ever read stirred the pot a bit (for more info: http://www.scilogs.com/next_regeneration/the-encode-controve...). I think most biologists (warning, personal opinion) would still hold that 80% of the genome is not meaningfully biologically functional.

PostgreSQL is a very different beast to what it was 10 years ago.

So for a while it didn't support use cases as well as various NoSQL/NewSQL databases. However, PostgreSQL has also been built by great bunch of developers who are happy to adapt and implement the new, instead of harping on about the past.

So personally I adapt that advice to instead "use evidence to guide decisions".

Maybe in Danish it's only 6 syllables? Because the English language completely agrees with you.

Thanks for the interesting reply. At the moment I guess it's a case of wait and see. I think it's fair enough to have some non-specific skepticism about Perl 6 given the history, however it's clear the designers are putting a lot of thought and love into it. And I can see how it will provide a powerful means of generating pipeline-type analysis tools.

However, it actually makes it seem to me that even more so Perl 6 makes the same "mistake" as Perl 5. The surface area of the language now seems fractal in complexity, and unless rigorous discipline & best practices are applied it's going to be very hard to build working complex projects. So great for individuals, very powerful for highly disciplined teams, but not good for the below average programmer - as 90% of biologists are. Perl 5 was full of magic, but in the hands of most biologists & less disciplined bioinformaticians that was a bad thing.

Take that SQL Slang example, great for quick scripts, but it's seems a long long way from a production ready library that can be used in a complex application. And maybe I just don't see the great advantage in being able to hide a couple of lines that make it exactly clear about what you're doing. If I'm maintaining code I want to see those explicit statements if possible. And really it's not exactly a big win over "&sql($statement)".

Anyway, it's interesting and luckily I can observe from a distance now.

I'm increasingly of the opinion, after having to deal with biologist data format hackery for many years (they have no shame!), that every biologist should be taught relational database normalisation. That would make them actually stop and think about the structure of the data they're recording and how to make it computationally tractable. Even more, they should not even start their experiment until they've cleared their data recording structure with a bioinformatician.

Then we ban them from using flat files. Related tables or nothing. I've wasted too much time, and they're not competent enough to work with JSON/XML/Excel.

Absolutely, with any serious application, it takes time to break it down and understand it. But the majority of perl generated in bioinformatics are basically advanced shell scripts and should be immediately comprehensible. This is rarely true, mostly because there's so many ways to do things that everyone uses their own personal conventions. Learning perl 5 is a bit like collecting pokemon.

As for the Perl 6 features, I had already looked at the list and was hoping you may have some insight as to why these might be killer features for bioinformatics in particular. e.g I know what currying is, but I don't think most computational biologists will care. I actually can't see anything there that says, "Science, do it here".

Julia is a very promising language due to its focus on mathematics, readability & performance and seems to be gaining traction. R has an unbeatable set of statistical libraries. Python is now deeply embedded and has IPython, and links back end to web very nicely. C/C++ & Fortran are are miles out in front for number crunching. Java is excellent for reusable code and distributed development, and can be used in almost any layer and has proven very difficult to dislodge as the general purpose language. At the moment I don't see a niche being available to Perl 6, unless something really useful for scientists (like IPython notebooks) is brought to the table. If they really backed it as a parsing language, and provided some really sweet tools for handling biological data files - e.g. something more like an interactive IDE rather than having to write out a script in emacs. Actually give me that, I'd be very happy. But I honestly think it's the associated tools & ecosystem which will determine if Perl 6 can succeed, not a laundry list of features.

And will it ever come out? :) I remember going to a Perl learning course in 2002 where the instructor was very excited about the new version 6, which was going to be out by 2004.

BioPerl has probably got a lot better over the years, I haven't touched it in a long time (5 years+), so my views may be very out of date. I don't really want to get into reviewing Bio* libraries generally :)

There is a general problem I think though, and other people have experienced the same. I've been trying to reason why, but I think it's due to multiple factors. By the time you've managed to get that bit working reliably with BioPerl you could have written it yourself. And it would be faster and use less memory. BioPerl has the problem of trying to solve every case, whereas normally I'm working with a limited subset of possibilities.

So why? I think it's a combination of dodgy, manually hacked inputs (e.g PDB files!), the learning curve, poor backwards compatibility preventing upgrading, and, ah I don't know. Every time it's seemed like a good idea, and yet every time I've ended up abandoning BioPerl. Maybe it's too integrated with itself as a library of functions?

Take parsing a FASTA. By the time I've read the BioPerl documentation, I could have already written that one line split string statement (because I e.g. know in advance the sequence string is always on one line). It's hard to overcome that laziness and make the commitment to learn it and become fluent in it.

Bioinformaticians are generally capable of writing truly awful code... that's why I like to call myself a Computational Biologist. I still write crap code, but no one's expecting any better from a biologist ...

Sorry, I was just pointing it out in case for anyone copying the code as they are both very common cases - especially dots as gap characters.

The Grammar system does look quite nice. Parsing is definitely a Perl forte - though I seriously hope bioinformatics in general will continue to abandon these crazy formats that can't be read easily by humans or machine.

>> To accurately follow anything non-trivial written by anybody in any programming language will require you a good grip over the language and its corner cases. There is no magic here, if a language doesn't offer facilities to heavy lift a certain thing you will end up writing those yourself.

I'm going to have speak subjectively and relative to my own skills here. Without rigorous use of standards Perl 5 is a nightmare to read. With very clear and consistent style then it can be readable, but this has to be enforced extremely strictly for any code base beyond trivial. Perl's 100 ways to do things is not a positive in this context.

Case in point, I was given a bit of perl two weeks ago by a bioinformatics lecturer. Did not use strict or warnings; variables weren't declared in scope; no subroutines, let alone Moose objects. And this is typical of ~90% of bioinformatics perl that gets written. What's more, it was a trivial script that was simply parsing some BLAST matches from CSV, checking for overlaps and assigning a type based on the match gene combination - and was completely indecipherable. It took me two days of refactoring to pick out all the details. And he managed to use a couple of magic symbols I'd never seen before.

The first time I was given a bit of python, without learning the language at all, I was able to extend the script and get it do some new things (it was considerably more complex than the aforementioned perl script).

And even when it is well written and documented - I did work with some very good perl programmers - it's tended to end up as very fragile and difficult to extend or even substantially redevelop due to the heavy use of context for determining behaviour (and the actual context can be difficult to determine). Unit testing had to be very extensive since it was difficult to isolate changes.

I'm going to have to be precise here - I'm attacking Perl 5. It just seemed from that section that Perl 6 doesn't solve the major problem (difficult to deduce the context and work out the resulting effect) I had with Perl 5. I may be completely missing the mark and actually readability is much better. I really hope so.

>> Perl 6 isn't production ready yet. But even a cursory glance over the features tells, Python isn't even in the same league of tools Perl 6 will be.

Vapourware is vapourware. Perl 6 was meant to be production ready a decade ago. On the other hand, I'm interested in knowing what you think Perl 6 brings that will give it the edge over Python? Do you see it displacing Python as rapidly as Python replaced Perl 5 as the science "glue" language of choice? With the apparent rise of Julia as well, could it just be too late?

Just one technical comment - that parser will break on many FASTA files. They can also include '.' & * characters ('.' is often output by sequence aligners to indicate sections outside of the model, * is there for aa but not dna/rna and I have seen them in sequencer output for uncertain positions). I think this kind of edge case variance is possibly why the various Bio-* tools have not been very successful in all, you end up spending hours trying to work out why it's not working with your particular inputs.

On a personal viewpoint: "Take a look at the REPL dump below and see if you can work out where we are implicitly using $seq as a Str rather than Seq:" - this section pretty much sums up why I've always hated working with Other Peoples' Perl. To accurately follow someone else's perl requires either an encyclopedic knowledge of the language and it's edge cases or very heavy documentation and a set standard of coding practices. It's a shame that this looks true for Perl 6 as well.

Great for personal use, I guess. But by and large I'm glad to see more projects switch over to python.