Comment by inumanag | Hacker News Reader

Comment by inumanag | Hacker News Reader

Hi guys,

one of the authors (Ibrahim) here! Thanks a lot for the comments--- we definitely appreciate them!

A quick explanation why we built Seq:

- We were not happy with the existing bioinformatics libraries for various reasons. And honestly, while Julia is amazing project (and we do talk to the Julia team from time to time as they are located two floors above our office at MIT), it never 'clicked' with us or many other people in the field.

- While the main application domain is bioinformatics (that's where we came from), Seq is pretty much a strongly typed statically compiled Python. One of the main goals we had was to push the boundaries of how much stuff in Python can be deduced by compiler, as we loved the Python's syntax (Seq is to Python as Cystal is to Ruby--- or at least that is what we are aiming for).

- We do not want people to learn a new language--- Seq should be pretty much a drop-in replacement for Python, at least for most scientific/bioinformatics software. There still remains a small gap, but we are actively working to close it.

- At some level, Python libraries cannot cut it, especially when dealing with next-gen sequencing data. Also, owning the whole stack gives us the control to perform low-level pipeline optimizations. Chief example is out prefetch statement that is rather hard to implement in other languages.

Also, check out the paper (https://dl.acm.org/doi/10.1145/3360551) for more information. Let me know if you cannot access it for various reasons.

I'm going to humbly suggest that trying to own the whole stack is a mistake. Bioinformatics requires a varied toolkit to perform any single analysis. Each step along the way has a different set of challenges and requirements. Expecting to be able to use one toolset or language for each step, I think is a mistake.

You'd never want to write a production alignment algorithm in Python (not performant enough), just as much as you don't want to create a visualization in C (way to low-level). Different problems... different optimizations... different strengths.

Trying to be all things to all people is a good way to be mediocre at all of them.

In certain circumstances, I think there is value in a variant of Python that is statically typed. However, even in that case, restricting the use-cases to bioinformatics makes is accessible to only a small subset of people who might benefit from the speed increases.

"Trying to be all things to all people is a good way to be mediocre at all of them."

What prevents a language from providing high-level features on top of low-level ones? It's a false dichotomy.

You get C++... take that as you will.

All a high-level language needs to also be low-level is a minimal runtime and ability to manually manage memory.

This aspect (variability of requirements spectrum) is exactly why Julia language seems to be extremely attractive in that it represents an excellent and unique solution to the "two-language problem". The only issue that I'm seeing right now is a relative immaturity of the Julia ecosystem (tooling, talent, etc.), though progress in this regard is significant.

What does "first language tailored specifically to bioinformatics" mean?

I ask because I'm pretty sure there have been earlier languages for bioinformatics. Just looking around I see:

- "Composable languages for bioinformatics: the NYoSh experiment", https://peerj.com/articles/241/

> In order to evaluate the potential of language workbenches in bioinformatics, we tested a prominent workbench by developing an alternative to shell scripting. To illustrate what LWBs and Language Composition can bring to bioinformatics, we report on our design and development of NYoSh (Not Your ordinary Shell). NYoSh was implemented as a collection of languages that can be composed to write programs as expressive and concise as shell scripts.

- "Large-scale data integration framework provides a comprehensive view on glioblastoma multiforme", https://genomemedicine.biomedcentral.com/articles/10.1186/gm...

> Workflows are constructed using a custom workflow language called AndurilScript that resembles traditional programming languages and is designed to enable rapid construction of complex workflows. ... These characteristics of Anduril facilitate scientists without bioinformatics training to interpret complex data sets, such as TCGA.

- "SARVAVID: A Domain Specific Language for DevelopingScalable Computational Genomics Applications", https://engineering.purdue.edu/dcsl/publications/papers/2016...

> In this paper, we have presented Sarvavid and showed implementations of five popular genomics applications, BLAST, MUMmer, E-MEM, SPAdes and SGA in it.

I see the last includes K-merization, like Seq does.

Love your bio, and those are some cool links.

To your first question, seeing that in context of their paper abstract, I think the emphasis should be on the last part of the sentence, "...which marries the ease and productivity of Python with C-like performance."

There's a comma before that clause, which suggests that it's not meant to be interpreted as "the first bioinformatics-specific programming language to marry C and Python" but rather as "the first bioinformatics-specific programming language (oh, and it marries C and Python)."

Which bio? My most recently updated one is http://mmpdb.dalkescientific.com/about.html .

http://www.dalkescientific.com/company.html

Boy, what a body of work. Would love to hear your take on Seq if you get a chance to dig in more. I come from more of a Python background and really like what I see:

  - Python syntax for the most part
  - Mypy style type annotations
  - |> for pipelining and ||> to parallelize
  - match constructs (ML-ish with guards)
  - s'ACGT' and k'ACGT' for sequences and k-mers

It's relatively early in the project but I think the choices they have made give them a chance to continue to build momentum.

Thanks for the pointer. And praise. I have several bios out there, for different purposes. I should update that one .... and the web site. Been meaning to do that for a long time. sigh

I don't have the interest to evaluate Seq. I only did bioinformatics for a couple of years, and that was almost 20 years ago. I am incapable of giving it a serious look. My cursory look is that it's only really meant for DNA, and highly optimized for the specific k-mer benchmark compared.

My personal opinion is that developing a new programming language is a hard and almost thankless task. Yet they are also so very fun to do.

Back in the 1980s and 1990s, a number of computational life sciences packages (eg, Sybyl Programming Language (SPL) from Tripos, X-PLOR, Scientific Vector Language (SVL) from CCG) developed their own domain specific languages. They were successful (IMO) more because of the tools available through them than the language themselves.

In the early 1990s I started work on VMD. We had a simple scripting language. As one did back then. I found that Tcl was similar, embeddable, more powerful, and cleaner than anything we did, so we switched to that.

As a result, we got a lot of things "for free", like easy access to third-party packages designed for Tcl, and the faster bytecode engine from Tcl 8.

I switched to using Python full-time in the late 1990s, and again saw just how much I got "for free" by using a language designed by people with software language design and implementation expertise, and with the vast set of support packages.

Seq also gets some things "for free" because it builds on LLVM.

But since it's completely independent of the CPython run-time and garbage collection model, it's impossible to build on any of the existing modules.

Page 125:3 makes the claim "We introduce Seq, the first domain-specific language and compiler for computational biology" without further qualifier, so I think my interpretation is correct.

There is Darwin from the 90's https://inf.ethz.ch/personal/gonnet/DarwinManual/

Thank you! I remembered a group in Europe developed a language, but I couldn't remember the name - that was it!

FWIW, SARVAVID is mentioned in the "Related Work" but "it lacks generality".

And "Biopython" is misspelled as "BioPython." A common mistake.

I wonder what did not ‘click’ for your team in Julia?

I am interesting if it is something with the language that can be addressed in future releases? I like the language and hope to see it grow and stake (unlike Scala, my former main language, that seemed to be in decline due to over-complexity that was not addressed in time).

How easy is it to write a python library in Seq ?

If it is possible to write python modules in Seq as easily as writing plain Seq, that would give Seq a great possibility for benefiting from the popularity of Python.

Interoperability would increase adoption. Library authors and maintainers would sooner consider switching to Seq for performance reasons, while python users would still be able to use those libraries from Python.

I see a lot of dismissive comments in this thread, but I think Seq looks really nice. I'm not interested in bioinformatics, but the rest of the features look like what I would've wished had gone into Python 3. I hope it is a success for you, and I'll be curious to see benchmarks against C++ or similar. I also wonder if some future version will have a REPL.

The Github site has some benchmarking info: https://github.com/seq-lang

I believe Jupyter support is in the works and a REPL would seem possible/likely.

Nim seems like a similar project. How does it compare?

Reply on news.ycombinator.com