"if it compiles, then it just seems to work"
Man, now that is tempting.
Also, how easy are the ports? In ClojureScript you can use JavaScript pretty directly, but I often got a bit hung up translating the syntax (it's not that hard, it was just me).
I've never used ClojureScript so I can't speak for that, but the ports are now a lot easier in 0.17 as an outgoing port is simply a function that you can call, instead of messing about with Signals. Effectively, you send stuff to Javascript by calling the port function with a Javascript compatible value, and then you subscribe to messages on the way back in, which end up triggering a message on the update function of whatever component sent it out in the first place.
TL;DR its pretty easy once you've done it a few times
Ports are essentially event emitters. You can expose them from elm, and in your JS code you attach event handlers to them using .onMessage (I think, been a while).
You can post and receive messages from ports (depending on type). Type checking is done at runtime to make sure nothing breaks.
Cljs interop is easier (can just call a function directly).
Apparently a human-readable homoiconic language is still an unsolved problem...
In 0.17, commands and subscriptions mean that, not matter how deep you nest components, you can still send and receive messages to/from the outside world (i.e. ports).
In ClojureScript, we have the re-frame pattern/framework, which is built on Reagent, which is a ClojureScript wrapper of React.
re-frame is all about subscriptions, using a "big atom" to hold application state client-side. Seeing Elm implement the same subscription pattern makes it look pretty tempting.
My understanding is that ClojureScript and Elm have some similarities - functional, pleasant to work with - with one significant difference being that Elm is typed.
Elm is typed, Clojurescript is homoiconic. 2 great features.
Wondering if you could make a lisp where `lambda` or `fn` required type annotations, such as
(defn add
[int -> int -> int] ;; type annotation
[x y] ;; arguments list
(+ x y))
Then it would be homoiconic - something that has saved me hundreds of lines of code (and the less code, the less bugs as a rule of thumb).
Then every function down to the very basic lisp functions would have types. Dunno how doable this is - but it doesnt matter. Someone implemented it in Common Lisp in the 80s I'm sure.
There's Typed Racket [1] and for Clojure there's core.typed [2]which do pretty much that. For Clojure there's also Schema [3], which is a bit lighter weight (it's not a full type system), but still gets you some of the benefits like validation and documentation.
Neither fit the bill though - because not every function ever written in the language is annotated. To be nice to use, it should be an all-or-nothing affair.
I say this as a huge clojure fan - my clojure programs with dynamic types work great. I rely on predicates (functions ending in -?) in I/O, otherwise I'm sure things work.
Why is annotation important? I agree it needs to be possible, but ultimately I want to push the majority off into inference, and only explicitly annotate when necessary or formalizing interfaces OCaml-style.
Though I sure do wish I could have lisp (or clojure, specifically) syntax in OCaml-land.
This is why (ignoring the batshit syntax) I'm quite fascinated by urbit's language hoon, since it handles type signatures by evaluating the function with type objects rather than straight arguments, so the above without the annotation would already be strongly typed and valid across anything that supported +
There's Typed Racket and Clojure's Core.Typed. In Common Lisp you can `declaim`/`declare` attributes to functions and values, and many implementations allow `declaim`-ing types. It's also common for them to propagate and check type assertions at compile-time e.g.
(defun foo (bar)
(if (numberp bar)
(car bar)
x))
should error out in SBCL because BAR is a number but CAR takes values.
> Wondering if you could make a lisp where `lambda` or `fn` required type annotations
…
> Someone implemented it in Common Lisp in the 80s I'm sure.
Even better, it's a standard part of Common Lisp: functions default to being 'typed' to take the universal type, but annotations can be used to declare any types you want (to include types like (integer 3 27), which specifies an integer between 3 and 27), which can be compiler-enforced.
I really don't understand why Common Lisp doesn't see more use. It's modelling clay for computation.
There was a small thread on the Shen Google Group about adding docstrings [1].
There is an BSD version of Shen that can be forked and docstrings added by whomever wants to pickup the work. The language's footprint is small enough now at the moment, that now's the time to get the first chunk done.
The BSD version is pretty impressive, and could be turned into a great project if people picked it up. A lot of interest has been expressed, but it is the commercial version that is moving ahead with lots of improvements. Shen's creator, Mark Tarver has added Griffin, an optimizing compiler, concurrency, and HTML generator in the form of SML (Shen Markup Language).
It is a very fun project. The small set of instructions it is based upon Klambda, has since been ported to many languages - Ruby, Python, Lisp, Haskell and more. The SBCL port is the main one. Aditya Siram (Deech) has just created an Elisp port, shen-elisp! [2]
I personally use ClojureScript with type annotations from Plumatic (former Prismatic) Schema and it works really well. Obviously it's not the same as an actual typed language, but it gives me a good-enough starting point to leverage some typing information and perform some rudimentary (runtime) type checking. I also feel it's really nice as some kind of "inline documentation" to be able to see the type of your parameters (obviously this is a given benefit for statically/explicitly typed languages).
Just dive into it. After wanting to be a bit more descriptive and assertive about the input and output of certain functions in some code I was writing, I must have spent all of half an hour reading documentation and successfully adding Schema to my code. Might be a bit of a rose-tinted memory here in respect to the pastimate :) But it certainly is both easy to understand and use.
Might be off topic but I was interested in the "a big atom". Reagent is using a big atom and some small atoms to simulate component state -- which breaks hot code swapping. And I tried a way to abstract out component states into a single atom to fix it by building my own React like library. Now it's "two big atoms" on my side.
Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big atom updates with subscriptions. Subscriptions hold reactions, which only update if the underlying value changes.
Not to get off-topic though! I am used to working with dynamic languages, but I really should work with a typed language. Elm looks like it offers many of the benefits of ClojureScript, but with typing as well.
Also, ClojureScript lets you write HTML and CSS in your code, but a quick web search indicates Elm may have gone further with incorporating CSS (?).
Can you talk a little more about your thoughts on one big atom? I've been looking at Redux and they also seem to follow this approach. The re-frame readme quotes the Elm Architecture as justification, but that same document goes on to describe nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting.
I come from a Haskell perspective and having one big blob of state sounds to me like it makes your type signatures less informative and increases the scope for error.
First, in Reagent/FRP, I was updating a view based on the value of an atom. This meant I had different default values in different atoms. The big atom let me unify where I stored values, and reuse values, without a performance hit. Second, the big atom made storing application state trivial: you can just throw the map/record in Redis or something.
However, the big atom is just a big map, and keys can be paired with any value, so it is not enforcing types. From a Haskell perspective (where I understand the program almost falls out of the types you define!), this probably does increase the scope for error.
This can be mitigated with Schema (which I never used effectively), logging changes to the console, and being able to see your default map easily (like, there's a map in one file which I load upfront, so I can see what values are there).
I'd welcome hearing from anyone with a more advanced or precise use of re-frame state.
I think that's true. Most biotech companies are filled with PhDs. The cloud lab Transcriptic is an exception, started by a biomedical engineer in undergrad, but generally speaking it seems you need a PhD for credibility (not to discount the deep domain expertise one needs as well).
FourSigma and IndianAstronaut, what do you think about doing bioinformatics as research, formulating and testing hypotheses, and then either using a cloud lab or a garage lab for at least some wetlab testing?
I've been researching intensively whether to go get a life sciences PhD, and I'm now leaning instead toward just learning bioinformatics and ML, with the wetlab stuff as an adjunct. If that's an effective way to do "real research", then it might be more accessible.
I would 100% lean towards to a more computational skill set while having some exposure to a wet-lab experimentation. I think having a data science skill set in biology is becoming extremely valuable. Moreover, if you choose to leave academia you have a set of skills that are in high demand across a range of industries.
I posted above why I like Org-Mode. Here are a few things it doesn't do well.
1. Because it is text-based, its visual summaries are limited. Like, there's a calendar, and for org-habits a simple color-coded chart to show consistency, but that's about it. If you're looking a week or a month ahead to visually see how many tasks you have coming up, the org-agenda is text-based.
2. While org-mode can sync with Trello, Beeminder, and a couple other task-management systems, its integrations are pretty limited. If you want to integrate with Contacts or whatever you'll have to work a bit.
3. org-mode's part of Emacs, so you'll need to be comfortable with Emacs.
Contrast this with Sunrise Calendar. Sunrise Calendar grabs gmail messages and appointments, iCal, google calendar, and displays them all nicely.
Pluses and minuses, depends on your needs and what you like.
Because a couple people here have expressed curiosity, here's what I like about org-mode.
1. The workflow is key. From any document, if I want to note down a task, I use org-capture. This creates a to-do item in To-Do.org. Alternatively, I can use org-capture to create a blog post, or an item for org-drill, or whatever. In either case, I don't break my flow of thought.
org-capture to create a new task looks like the equivalent of "task add" on Taskwarrior, except you do it from anywhere inside Emacs, not from the command line.
2. The org agenda shows all upcoming scheduled tasks. I also use org-habit, which are just repeating tasks that show how often you've completed them (and can prompt for a note when you mark it as done - "30 pushups" for TODO: exercise, or whatever).
3. I can "clock in" on a task in To-Do, and when I'm done archive the task in an automatically-created archive file. I can then see total time worked on that day, broken down by task. When clocking in, org prompts me for a time estimate.
4. Because all tasks are just bullet-points, I can nest sub-tasks, and expand or collapse them, like the app Workflowy. The top-level task can show percent or fraction of sub-tasks completed.
5. Best of all, at the end of the day, and despite all this manipulation, it's just text. I can edit time spent on a task, or whatever. There's no hidden magic.
This workflow is pretty GTD-ish, because it helps you get everything out of your head on the fly, and break things down into sub-tasks. It also works well with SRS and incremental reading. I see myself sticking with this, but I've used other systems productively, so whatever floats your boat.
Hmmm. Where do you get that from this article, or his blog post?
Sure, he did get the 23andMe interview from a friend. But Google? and AirBnB? and Yelp? and Uber? and Twitch? Man, that would be a lot of connections.
Ben Horowitz carefully orchestrated a bidding war when it came time to sell his company. Qureshi "cracked the coding interview" and then orchestrated a feeding frenzy of a bidding war.
Can you explain what you mean by "it simply gives the author's a narrative to fake"?
At the very least, pre-registration helps guard against the "file-drawer" effect, where a negative result simply goes in the trash, and no one ever knows it occurred.
If you mean that pre-registration will not prevent jiggling the results until the researcher gets a significant p-value, then I agree that many forms of pre-registration which lack registration of the analysis and so on will allow the authors to fake the narrative.
I've spent the last couple of weeks intensively researching paths into the life sciences without a PhD (I'm deciding whether to go get one).
I haven't found a way in either. If you start your own company somewhere in the field, or otherwise support yourself, you can rock and roll as an indie researcher. Otherwise, a Ph.D. seems necessary.
I wonder if this will change over the next decade, as synthetic biology continues to expand rapidly.
There is no non-PhD pathway into biomed research that leads to career advancement beyond the drone level [1]. If you do get a PhD, there are few jobs, relative to the number of graduates. All in all, I'd advise against it, unless you have a very specific love of the field, and can handle a modest, academic lifestyle in exchange for working very hard at what you do. And for that, the drone-level jobs are perfect for testing the waters: you should get a job in industry first, and if you decide that you love it, get a PhD.
Also, beware the "$TOPIC is expanding rapidly" trap: synthetic biology is merely the buzzword of the moment. When I started, it was computational biology. Later, genomics. The number of opportunities created by these booms has never kept up with the hype waves that preceded them.
[1] There is, however, a pathway for "business" people who enter biomed. But I'm assuming you're not interested in this, and in any case, getting a PhD won't help you with it.
Thanks for the advice, that all sounds right to me. I particularly like the point about the $TOPIC of the moment.
The roll-your-own-company lab approach sounds a little better, overall. One tricky thing is that I'd have a lot more credibility starting a biotech company with a Ph.D. Right now I'm considering a Ph.D. to get the training and credibility (union card, as someone else said). Still not a slam dunk, though - Transcriptic's founder just has a bachelor's.
Contract enforcement is a government activity, though. To enforce a contract, you ask the government (via the courts) to force the other party to give you assets, or not to work somewhere, etc.
By the same reasoning, if I sue you for defamation for calling me a lamebrained chucklehead, courts refuse to entertain the suit because the government won't restrict free speech. You're entitled to express your opinion, and the government won't assist me in suppressing your speech.
In many states, the government is happy to assist employers in restricting job-hopping.
I take your point that this government activity has its immediate catalyst in private actions in the free market, and that's different in important ways from other government activity. But still.
Consent under coercion which most work contracts are implicitly, else how are you going to pay for your living expenses, by necessity require government intervention.
You can not eliminate this source of coercion without for instance giving people free living wage. Eliminating such contracts would not eliminate the coercion but make it worse. Maybe not as bad a contract, because people can still walk away, but still could end badly.
The natural state of mammals on this planet is hunter gatherers. Hunter gatherers don't have any way of storing food, so they take only as much as they need. They are under constant coercion by their environment. So I guess the environment is coercing, whether that's nature or it's society. There is a way to get the basic resources for survival. For hunter gatherers they may go out at any time and if food is available they can hunt it. In society, there is no way to get that unless there is some form of contract or agreement for some resources in return for work.
