gjuggler

The most interesting thing here is that Claude Science runs a local server and a web-based UI that connects to that server from your browser. This is very different from Claude Code and Cowork, where the UI is more tightly coupled to the host machine (which makes things like computer use possible).

I think I recognize the strategy: most pharma environments connected to interesting data are tightly locked down, to the point where you can't just connect your Macbook to the source data.

Similarly, access to large genomic biobank datasets like UK Biobank or NIH's All of Us program is granted only through a Trusted Research Environment (TRE), a remote data analysis platform usually quite restricted on internet access, etc. You can't easily run desktop apps, but these environments do usually support running JupyterLab or VS Code, tunneling the user interface through to the end user. (Source: I previously ran the team that built the All of Us TRE.)

Claude Science looks a lot more like something one could imagine spinning up in one of those highly-constrained data environments (with the "server" running within the TRE and the UI proxied to the end user's browser) than the does-everything Claude mega-app. That will be critical for traction within pharma R&D environments.

I will say that for moderately-computational scientists, who are daily driving RStudio, JupyterLab, or maybe VS Code, Claude Science will be quite an unfamiliar shaped product. I'll be curious to see whether something like this gains adoption (1) in place of, (2) alongside, or (3) eventually wrapping around the more traditional data science workbench tools out there.

Thanks for sharing your process! It's helpful and refreshing to hear from someone about how they engage with AI when writing, and where / when the detection tools may fail.

(We obviously live in a more nuanced world than most social media interactions might make you think :P)

> On a lighter note, decades ago, in middle school, we had an exercise to summarize a book we read.

My first experience with plagiarism was in first grade, when we were told to write a book report about a subject during our library time. I diligently took my book on the musk ox and copied three pages word-for-word into my notebook as my report. I can't remember when or how we learned this wasn't "right", but I still think back on that and laugh.

I was surprised not to see any discussion on whether the author used AI to help write this post. As many people say, writing is thinking.

I started getting that "I'm reading another AI-written blog post" feeling around 1/3 of the way through, but I don't consider myself super calibrated on this.

Pangram seems pretty confident it's AI (https://www.pangram.com/history/e9f6eb77-86f9-46d0-a6c1-e57c...). But I know these tools aren't perfect. I'd love to hear from the author what their process was in writing this piece!

Related question (I'm trying to work this out for myself):

If you believe using AI to write an email or blog post for you isn't okay, but using AI to write code for you is... what's the difference?

Right now my instinct is something like:

- Code can be verifiably correct (especially w/ good tests) so it's less of a purely-creative act than writing.

- But always, always double-check the tests!

- I still wouldn't submit a PR where I can't vouch for every line of code.

- AI-written documentation and specs are mostly still bad and should be looked down upon. But mostly because the quality, at least today, is poor. (Lots of duplication, lack of a clear understanding of the reader's intent and needs, no thoughtful curation, etc.)

- Be psychologically ready to update these priors as models change.

I'd love to hear from anyone who's thought more about this.

I think Gemini is just broken.

Instead of forwarding model-generated links to https://www.google.com/url?q=[URL], which serves the purpose of malware check and user-facing warning about linking to an external site, Gemini forwards links to https://www.google.com/search?q=[URL], which does... a Google search for the URL, which isn't helpful at all.

Example: https://gemini.google.com/share/3c45f1acdc17

NotebookLM by comparison, does the right thing: https://notebooklm.google.com/notebook/7078d629-4b35-4894-bb...

It's kind of impressive how long this obviously-broken link experience has been sitting in the Gemini app used by millions.

It's important to recognize that PLOS' new data sharing policy is only about data directly tied to the publication of a traditional journal article. So while PLOS authors are being forced to share their data, it's only done in the context of a published article, which will accrue citations, recognition, and attribution in the standard way.

So any data shared by this policy WILL absolutely be tied to the traditional methods of scientific credit, via the linked journal article. To me, requiring that reasonable data is published and archived alongside scientific literature doesn't seem absurd at all.

> Journals try to enforce data sharing because they want to maintain their position as arbiters of academic affairs.

Is there any evidence behind this claim? PLOS seems to behave in exactly the opposite way. It's true that SOME journals use extreme selectivity or control over copyright to maintain their position as arbiters of science. But PLOS, whose largest journal PLOS One is both open access and makes no judgment on the impact of the science it publishes, seems to be actively reducing the amount of control it exerts over academic activities.

While this problem may be true of certain poor actors in some fields of science, I would argue that it's far more the exception than the rule.

My experience (in genomics / evolutionary genetics) was overwhelmingly positive, with huge amounts of collaboration all around. Scientists did try to publish at the highest-impact journal because they care about their career prospects, and there were often competitive labs racing to the finish line with a breakthrough publication.

But I never saw researchers withhold important details in order to accelerate their own publication or to hamper the efforts of others. By and large, I saw huge teams collaborating on large projects with a deep sense of purpose to move the field forward and improve understanding.

In fact research funding in genomics became so collaborative — with increasing portions of the research budget being put towards huge consortium-based projects — that smaller labs began criticizing funding agencies because their smaller projects weren't being funded. These projects are typically more competitive and higher risk, yielding potentially high-impact articles with a far smaller number of authors.

What's the answer in the end? As with many things, it's balance. Cooperation is great, but to a fault. Sometimes having small labs working in relative isolation, even competing against other small labs, can yield great innovation and progress. Other times you need a huge collaborative effort to do something big, expensive and important for the future of the field.

This is a very cool technical integration between two services that are — or should be — used by most scientists working in code. But what exactly is the "problem" of citation of code that this solution fixes?

Let's say you release your project to GitHub & figshare and now have a DOI in hand. What are you supposed to do with it? Do you ask your users to cite this DOI if they use your software? If so, what text should accompany the citation? How do you track citations to your code? Will they show up in Google Scholar, Scopus, Web of Science?

And what if the journal one of your users is submitting to doesn't accept figshare / github citations? It's unfortunate but true that many publishers disallow citations to unpublished / non-academic works. This is why many scientific software projects have resorted to publishing papers on their software — it's a hack to make a software project fit into the traditional social system of scientific credit.

DOIs are a technical glue that binds together the thousands of academic publishing outlets, but they do not solve the scientific or cultural issue of what is the minimum viable citable scientific product, and how those citations are generated, propagated, or valued.

Securing a DOI only solves a small slice of the problem of scientific credit — a point most colorfully expressed by this blog post from CrossRef, the largest DOI registrar for academic work: http://crosstech.crossref.org/2013/09/dois-unambiguously-and...

This is a really thoughtful post highlighting many of the deeply-rooted problems in securing funding as an early-stage academic. It's depressing for bright young scientists to be looking forward to lives as assistant professors submitting grant after grant with an expected ~10% success rate.

But what surprised me most was that at the end of the essay, after having described his fear of facing such uncertainty in NIH funding, the author mentions that he left academia to co-found a startup making software for life scientists.

Wait a minute — don't small software startups have equally poor success rates? (e.g. http://www.quora.com/What-is-the-truth-behind-9-out-of-10-st...)

If uncertainty of success was his major concern, hasn't the author chosen a pretty poor next step in life?

Really cool to see this! I'm sure the effort required to make it open source will pay off in fostering an active technical community. Given the target market I'm sure you have many highly skilled users who would love (at the very least) to fix their favorite bugs.

On a related note, recently at http://paperpile.com/ we've been thinking about ways to help our users connect their reference manager with web-based writing environments like ShareLaTeX. We've had some ideas about how to do this simply and cleanly, but I suppose now we could show you guys (via pull request) rather than tell now. :-)

Really? As far as I can tell extensions like Evernote (3.2m users), Pocket (1.5m) and Buffer (250k) are heavily used, well understood, and loved by many average consumers.

You could make the argument that the variety of use cases is limited: all of the above are fairly simple "click a button to save somewhere" apps, and they don't do too much fancy integration beyond laying an iframe with their save dialog onto the page.

Our own academic-focused extension (https://chrome.google.com/webstore/detail/paperpile-extensio...) is a bit more niche, but does some cool stuff: we use the background page to parse metadata from PDFs, content scripts to insert buttons into academic search results (Buffer does something similar for Twitter), and it plugs into Google Docs to provide an extra layer of UI.

But alas, the most useful thing our extension does is similar to Evernote/Pocket/Buffer: save a piece of content (in this case journal articles) for later.

I think the problem with doing cool extension stuff is that it's often really hard to get just right: you need to tread carefully when working on a system that could interfere with your user's most basic browsing experience!

No, I didn't intend the irony — I didn't know it was common for employers to formally request that salaries be kept confidential.

However, even if intra-company sharing is discouraged / disallowed, it is still common for job-seekers to know what salary they could expect based on their skill level, other offers of employment, sites like glassdoor, etc.

Perhaps more accurately, you might say journal subscription NDAs are like the only employer in the world threatening to fire you if you ever posted your salary to glassdoor or shared it with a friend who's just starting his career what he might expect to make.

These clauses are aggressively anti-librarian, and unfortunately librarians don't have a choice but to subscribe at whatever price. Academic papers don't exist in a competitive marketplace; once a non-open access paper is published it's considered part of the permanent academic literature, which academics are professionally required to read and cite. Yet each paper is only available from the publisher that owns its copyright.

It's no wonder why Elsevier draws such ire from the librarian community... an analogy would be if a company legally disallowed its employees from discussing their salaries with anyone, in order to reduce the information available when any other employee negotiates a salary or raise.

And even though David Tempest argues that the main reason for these clauses is to maintain price differentiation between countries, I'd guess that this policy is equally designed to convince small but well-funded US research institutes to keep their non-discount subscriptions, while giving relatively steep discounts to large accounts like the UC system that have negotiating power due to their size.

Fundamentally, the ecosystem of subscription journals is full of non-market dynamics and requires extensive legal management (think NDAs, copyright transfer agreements, DMCA takedowns and copyright infringement enforcement). On the other hand, the rise of Open Access journals has produced a healthy competitive market, where authors can choose where to publish based on a variety of factors including cost, quality of peer review, user-friendly submission tools, and prestige of the journal brand. Plus, copyright is largely a non-issue for open access: authors keep their copyright and there's no cost to the publisher for enforcing against infringement.

I think the more market-driven nature of OA, plus the obvious desire to have publicly-funded research be publicly available, will compound its growth and cause it to eventually overtake the subscription journal model.

There's nothing controversial here — Elsevier merely bumped up the rate at which they're sending Academia.edu takedown notices for obvious infringement by its users.

What's more interesting to me is that ResearchGate, a site which is virtually identical to Academia.edu in its "mission" and design, has been redistributing a shockingly large number of Elsevier PDFs for a long time. Unless these google searches are misleading, there seem to be many thousands of them:

https://www.google.com/search?q=site:researchgate.net+filety...

https://www.google.com/search?q=site:researchgate.net+filety...

I'm really stumped as to how ResearchGate gets away with this, but Academia.edu is getting hit with DMCA takedowns. Maybe Elsevier and other publishers haven't yet learned to reliably "find" ResearchGate's shared papers, or perhaps they've come up with some arrangement that allows them to publicly share thousands of paywalled PDFs with impunity?

Re: PDF / attachment handling, you may be interested in what Paperpile (http://paperpile.com) does with PDFs: we create a subfolder in your Google Drive space which automatically stays synced with your reference library, so PDFs and supplementary files are accessible from anywhere.

It's tuned more specifically towards academic work than Evernote, but the Drive sync is quite simple and robust.

(Disclaimer: I co-develop Paperpile, a web-based reference manager)

A large chunk of ORCID actually is open source: https://github.com/ORCID/ORCID-Source (though I don't necessarily agree that it should be, since ORCID is not a library or tool, but rather a service that only has real value if there's a single instance in existence).

I think there's a misunderstanding here on what ORCID is exactly. The name is an acronym for "Open Researcher and Contributor ID." It has nothing to do with publishing, but rather is being built as a central arbiter of academic identity.

Academics love to measure their importance by the papers they've authored or co-authored. Most databases currently track the names of authors associated with each published paper. But names are frustratingly ambiguous or degenerate, which makes it difficult to do things like create an auto-updated list of all the papers you've published.

ORCID is a publisher-funded non profit designed to reduce ambiguity in author identification, by simply assigning a UUID to every researcher. This is a case of publishers agreeing that collaboratively funding a single, centralized technical solution will benefit everyone much more than having a bunch of competing, siloed systems.

Have you tried actually logging in? This is not quite arxiv.org — I'd estimate that 90% of the engineering going into academia.edu has gone towards features on par with LinkedIn for their spamminess. I signed up, and was asked about 10 times to connect to Facebook, Gmail, invite my friends, etc.

They have some interesting features (such as feeds of recent articles organized by journal you can sign up for), but by far the most important feature of academia.edu is growing academia.edu.

Have you seen eLife's Lens reader? Example article is at http://lens.elifesciences.org/#00772

They took a fresh, web-centric look at how to interactively display research papers. It's being used — right now — to display all of the new articles from a major biology journal.

I think it's quite nice.

A great example of a web-friendly, interactive view of a scientific paper is the eLife Lens, example here: http://lens.elifesciences.org/#00380 . They announced the open source project back in June (blog post http://www.elifesciences.org/lens/). This is the direction that web-based paper views are moving toward, and some publishers (notably PLOS) already have quite nice interactive components.

PubMed, the government-run biomedical abstract database, also recently introduced its PubReader app for reading biomedical papers (http://www.ncbi.nlm.nih.gov/pmc/about/pubreader/). But my money's on eLife here — NCBI is better known for its databases than its user interface design (to say the least).

It would be great to see some innovation here (some publishers have absolutely awful web-based journal article views). But as the main format for paper publishing and dissemination, I think the PDF won't be going away anytime soon.

Using straight console.log statements seems to be non-negotiable for effective debugging, at least until a good workaround for the above is found.

For using Chrome's logging styles, we define a few short helper functions — l1(), l2(), l3(), etc. — that return predefined CSS strings, then doing our logging like

    console.log("%cThis is a heading", l1())
    console.log("%cLess important stuff", l2())

This means you're only adding 6 or so characters to get nice styled console messages that also maintain the nice line numbers and links to the source. Plus, it's similar enough to h1, h2, etc. that it's easy to remember.

We found that varying the font color (black vs. gray) and margin-left (2em, 4em) were most helpful in differentiating more and less important log messages.

There's an associated website at http://birdtree.org/ .

They don't seem to be providing the actual phylogenetic tree data (there's a cryptic note "More information will be made available here with the print publication of the study"), but there is a link to a higher-resolution PDF: http://litoria.eeb.yale.edu/bird-tree/images/BirdTreeHighRes...

You can also download the supplementary PDF at http://www.nature.com/nature/journal/vaop/ncurrent/extref/na... which has a lot more detail and some pretty pictures towards the bottom.

I think the logo clicking decision isn't crazy. My interpretation is that Google is "un-training" users from using this valuable piece of screen real estate for a useless no-op function, in anticipation of putting a more useful function in its place.

Does anyone remember a few weeks back, when Google tested a "new way to browse Google's services"? They turned the logo into a button, producing a drop-down menu of services to navigate to.

My guess is that they found the new logo-button didn't work well, mainly because so many users saw the logo as a big button which refreshed the page or went to the inbox.

At the risk of making predictions, I'd guess this recent change is a grace period, designed to get us all used to using other buttons for reaching the inbox. And once people no longer instinctively click the logo-button, they'll introduce the new navigation which makes better use of that valuable screen space.

I could very well be way off the mark here... but it seems pretty clever to me, TBH.

One of my greatest regrets from undergrad days was having graduated a year too early to enroll in this course. Scott Strobel was something of a visionary for setting it up, and it seems to have paid off with at least one cool result -- not to mention, a handful of students who now know how it feels to find something new.

I wish more professors would actively engage their students in "real" research projects, i.e. beyond the usual cookie-cutter laboratory lessons or follow-a-grad-student internships. Sure, it's more work for everyone involved, but experiences like this are the best way to convert bright students into real scientists, IMO.