shpongled

I just got a massive hit of dopamine from the nostalgia of seeing the classic homepage. So many hours of my middle school life spent playing Runescape...

I would argue that it appears very good at syntactic analysis... but semantic, not so much.

For rapid prototyping I (who you originally replied to) completely avoid lifetimes. If you think you have to "annotate lifetimes of everything you pass around", you should probably revisit Rust. This is simply not true.

I find type annotations to be a major benefit while prototyping - I know exactly what everything is, and can quickly refactor anything. The ability to use serde to deserialize/serialize into Rust structs is another huge benefit. Chaining iterators, collections, etc removes a lot of the boilerplate that I find myself doing in python.

I've also been using Rust as my primary programming language for 5+ years now, so I am definitely "in the zone"

Personally, I find rapid prototyping much faster in Rust than Python, and I don't think I'm a "top expert".

I still use python type hints (and TypeScript) - and while they have benefits, I find that they fall short of something like Rust, Haskell, etc (because they are just that - hints). I don't have the surety that the types as annotated are the same as the types at runtime.

You can write them, but without most of the benefits of static types

How is throwing a party during finals a facepalm? I recall that being one of the best times to party...

OP never said it was an abstract - they are from chem/bio (like me), where papers are submitted primarily to journals, not conferences. They mentioned abstracts in response to your comment about writing to the "steering committee of the conference"

Nice examples - you can also have languages (like SML) where monomorphization is simply an implementation detail. Some compilers (e.g., MLton) perform monomorphization and others don't.

Personally, the opposite is true for me - case in point: python.

I really dislike both the semantics and syntax of python. However, the scientific computing libraries (pandas, numpy, scipy, scikit-learn, matplotlib, seaborn, etc) are just too productive to turn away from for quick data analysis tasks. If these libraries didn't exist, I wouldn't touch python with a 500-foot pole.

I find it interesting that your complaints are almost totally about the syntax - that is generally the last thing I care about in a language.

When I choose languages, I choose them based on semantics, tooling, community/ecosystem, UX, and then maybe syntax

I work in proteomics, where the field decided to standardize on XML based file formats. It can take longer to parse the data out of the XML container than it does to actually run the analysis.

Personally, I would use Rust even if it was managed/not as low level. Advanced ML type system + best-in-class developer UX/tooling is the biggest selling point for me.

This is awesome, I will be installing and trying out later today!

I was working on a SML compiler [1] and language server in Rust as well, but I dropped the ball towards the end of 2020 as I had a PhD to finish!

SML is a great language, and I think some better tooling (like a language server) is all that it really needs to be useful.

[1] https://github.com/SomewhatML/sml-compiler

I personally find strong static typing (a la Rust, Haskell, Standard ML) to be much more expressive and with better UX/DX by miles.

I've also dropped mine several times (it did get a minor chip), beat it up a bit (despite trying to be careful), and even spilled water on it... liquid got behind a good 25% of the screen and I thought I would have to just suck it up and repair it, but it just evaporated/resolved itself after a couple of weeks.

Pleasantly surprised so far - knock on wood.

I'm building scientific software in Rust.

Phenomenal performance, drop-in concurrency support (`iter()` -> `par_iter()` with Rayon), and a great ML-based type system that makes writing correct code easy.

It also has some of the best developer UX/tooling out of any language I've used.

> Comparing alphafold to conventional homology modeling is disingenuous at its most charitable interpretation.

It's really not - have you played around with AF at all? Made mutations to protein structures and asked it to model them? Go look up the crystal structures for important proteins like FOXA1 [1], AR [2], EWSR1 [3], etc (i.e. pretty much any protein target we really care about and haven't previously solved) and tell me with a straight face that AF has "solved" protein folding - it's just a fancy language model that's pattern matching to things it's already seen solved before.

signed, someone with a PhD in biochemistry.

[1] https://alphafold.ebi.ac.uk/entry/P55317 [2] https://alphafold.ebi.ac.uk/entry/P10275 [3] https://alphafold.ebi.ac.uk/entry/Q01844

I would argue that depends on your definition of deep - we are certainly getting better at developing both genetic and chemical tools that allow us to probe specific pathways/sub-systems of biology, and read out the resulting perturbed phenotype(s).

> There's a huge gap between the fundamental units of biology (biochemistry) and the resulting emergent behaviour (living things). We don't have a good bottom-up system to predict the emergent behaviour so we're mostly left with observing from the top down and poking/prodding sub-systems, hoping to gain some insight.

I think this is just about the last thing that we will ever solve/figure out.

There are just a mind-boggling number of parameters, feedback loops, dynamic modifications, interactions, etc that are effecting cellular state (let alone organism state) - something that I think many CS oriented folks ignore when talking about "DNA as source code" (perhaps if program behavior depended on the size of indents, font, variable names, how many lines of code you wrote, the proximity in source location of different functions, etc).

It's certainly a goal to work towards. However, it's pretty difficult to build One ELN to Rule Them All given how flexible many kinds of biological experimental designs are - especially when you're working on the bleeding edge.

A good first step is to require supplemental materials are published in a machine readable format (e.g. not manually thrown together Excel files that lack any kind of normalization or rational schema)

We already know that many genes have more than one function (especially when you consider that one gene can produce many protein products)

I am a self admitted python- and ORM-hater and I agree. Django is pretty fantastic, and I have successfully used it to spin up several complete CRUD projects in a day or two

The parent comment was about a transpiler targeting brainfuck, not an interpreter. Writing a brainfuck interpreter (or compiler to x86/etc) is indeed trivial... writing a compiler targeting brainfuck is another beast entirely.

I have the compiler on GitHub [1] - I just started working on it again after a 2-year hiatus (to finish my PhD).

As for language-server, I'm currently sketching out some plans to use SMLnj's "Visible Compiler" feature, since that seems the easiest path forward. I have a half-baked language-server based on MLton's def-use output, but it's too unstable to share. I am planning to make some progress on the language-server in the next couple weeks.

[1] You'll notice it's just a fragment of the language for now, and only half-implemented. https://github.com/SomewhatML/sml-compiler and https://github.com/SomewhatML/sml-analyzer (again for a fragment of SML)

You have already linked to it :)

SML is one of my favorite languages (I've been (very) slowly writing a compiler & language server for it).

Sure, it has some warts/differences compared to newer languages - we have moved towards traits/typeclasses/etc, and I wish I could just write #[derive(Debug) - but I feel that SML fits in a very unique spot for programming languages. It's extremely simple, yet still powerful and expressive. I hope we will see continued work on SML/Successor ML descendants (like 1ML, etc), because I think there's still potential there

I think some updated language tooling would dramatically help.

Standard ML is one of my favorite languages. I would kill for a programming environment a la Rust

Indeed, I do a lot of Rust/ML-style programming, so the type-directed approach comes naturally.

> Let’s start with a general guideline for programming Go: write Go programs by writing code, not by defining types

I find this interesting - I think I typically do the reverse: I generally start by thinking of my program in terms of types and then write code to perform operations/transformations on those types (obviously this doesn't work 100% of the time).

That being said, I have never written any Go, but I can't imagine I would approach it differently.

Unfortunately, I haven't found a ton of "easily-digestible" and, at the same time, comprehensive guides on compiling functional languages. Generally you'll find a mix of blog posts/class notes/papers covering a single step.

Some resources I like:

- Andrew Kennedy's 2007 paper Compiling with Continuations, Continued [1]. This one is the most clear IMO

- Andrew Appel's Compiling with Continuations book (a bit outdated though... assembly code is for VAX)

- Matt Might's series [2]

- MLton's source and documentation [3]

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

[2] https://matt.might.net/articles/closure-conversion/

[3] http://mlton.org/