Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Companies from the YC Summer 2018 Batch

blog.ycombinator.com

Post reply on HN
Print view View original

91–99 of 99 posts

Re: Companies from the YC Summer 2018 Batch

#91

Post by Fomite »

mmt wrote: post #89
Fomite wrote: post #86

Earlier quoted context omitted.

Yeah, "wet lab" is what most people thing of as a "lab". Some fields (lots of the biology and biology-adjacent ones) use "lab" as a logical unit of organization. So Professor So-and-So and their graduate students, postdocs, etc. is "The So-and-So Lab". "Wet lab" is useful to distinguish people with actual labs vs. my lab, which is just a bunch of people with laptops. The situation I'm dreaming of, is, for example, it…

> my lab, which is just a bunch of people with laptops. OK, so it's something akin to Wikipedia's description of "dry lab". > The situation I'm dreaming of, is, for example, it not being my problem when a grad student is having trouble getting software installed on the server. That would be something I'd love a lab manager or dedicated programmer to deal with This sounds very much like IT/Helpdesk support, of the kin…

"This sounds very much like IT/Helpdesk support, of the kind a programmer or a lab manager typically wouldn't want (and might not be qualified) to deal with, either." - Not if they were hired with that qualification in mind.

"Is there something unique to your lab environment that you couldn't use some kind of shared/general IT helpdesk service, perhaps focused on scientific software users?" - It's more there are parts of HappiLab that I could see using (managing grant budgets, which was...an unpleasant part of my week last week), etc. but my pain points are slightly different from those of a wet lab, but still within the realm of "I'd prefer someone familiar with academia and research rather than a general purpose group."

Re: Companies from the YC Summer 2018 Batch

#92

Post by mmt »

Fomite wrote: post #91
mmt wrote: post #89

Earlier quoted context omitted.

> my lab, which is just a bunch of people with laptops. OK, so it's something akin to Wikipedia's description of "dry lab". > The situation I'm dreaming of, is, for example, it not being my problem when a grad student is having trouble getting software installed on the server. That would be something I'd love a lab manager or dedicated programmer to deal with This sounds very much like IT/Helpdesk support, of the kin…

"This sounds very much like IT/Helpdesk support, of the kind a programmer or a lab manager typically wouldn't want (and might not be qualified) to deal with, either." - Not if they were hired with that qualification in mind. "Is there something unique to your lab environment that you couldn't use some kind of shared/general IT helpdesk service, perhaps focused on scientific software users?" - It's more there are part…

> Not if they were hired with that qualification in mind.

That's a big "if". That's why I said "typically". I think you'd find it difficult, if not impossible, to hire someone like that, even though they exist.

This is a conceit I often see in job postings, of listing skills that belong to two (or more!) different specialties. It seems more common in cases where the goal seems to be to have two specialists for the price of one [1].

> "I'd prefer someone familiar with academia and research rather than a general purpose group."

I'm pretty sure "prefer" rather than "urgently need" isn't compelling enough to give a startup a enough of a competitive advantage. There's also not much (if any) synergy with any of the rest of HappiLab's core competencies to make sense as an addon for them.

IT services could be just another vendor HappiLab handles.

[1] Uncharitably, two full-time experts for one salary, but, charitably, merely two half-time experts in one person, which seems likely for startups and other cash-strapped groups.

Re: Companies from the YC Summer 2018 Batch

#93

Post by jxub »

The downside to Web MD might be that any charlatan may pretend to be a doctor.

When you've got the answers for common diseases from the doctor who gets them from an app, the doctor himself is a repleacable middleman and can be anybody with enough confidence, even if faked.

Re: Companies from the YC Summer 2018 Batch

#94

Post by AriaMinaei »

handsomechad wrote: post #43
AriaMinaei wrote: post #36

Optic [0] caught my eye. They seem to have made possible a new kind of abstraction in code. Something that's different from both functions and macros. It's a kind of abstraction that can be arbitrarily customized at each call site, yet retain its identity across all of them. Example: foo = do_a() bar = do_b(foo) Example 2: foo = do_a() bar = do_z(foo) baz = do_b(bar) Example 3: foo = do_a() bar = foo + 10 baz = do_b(…

can someone ELI5 this? I am a former SW engineer, but havent read through code in a couple of years, so it can be a technical explanation. I just don't understand what is different about this than regular functions as first class citizens? I tried to get it but maybe there is an easier explanation for laymen-ish people.

You're right. My examples should've been more complicated for regular functions not to be a suitable abstraction. Now, assume that the examples are complicated. In that case:

One method to define that function would be to do it the way explained in this [0] comment. That is, express the solution with small, composable functions. This would work as long as you can express the program in a composable way. This is what I usually try to do first, unless I find expressing my solution with composable pieces is not worth the effort.

For example, an async solution to a problem would be very difficult to express composably without well thought-out building blocks. One such collection of building block is Reactive Extensions [1], which is the result of years of research and development. So, before RX and similar libraries existed, it was costly to express async programs composably. That cost may or may not have been worth it.

Another method to define that function, if we're not going for "composable," would be to write it with an `options` argument, which would look something like:

  type Options = {use_cache: boolean, skip_one_cycle: boolean, number_of_retries: number, ...}
The more options one function has, the lengthier its definition would get, which means its core logic could be obfuscated. So that'd be the tradeoff with this method.

Third method would be to define multiple variants of that function, like `do_things()` and `do_things_with_cache()` and `do_things_and_retry()`, etc. Here, each function is simpler than a single function taking an `options` arg, but then core logic would be repeated in all of them.

And since these three methods are not binary options, one may even use all three of them to some extent.

What Optic seems to provide is a fourth option which allows you to forgo defining that function (as long as that makes sense) and repeat your core logic in many different parts of your code. The devtool would then recognize the core logic in all those different repetitions and assign it a single identity, which would allow you to manage that core logic from a single place. This would be especially useful in a language that does not support macros.

(Btw, macros would be your fourth option if you're coding in lisp/rust/etc. The one tradeoff with macros is that they are yet another layer of abstraction that the author and the reader of the code should keep in their head.)

[0] https://news.ycombinator.com/item?id=17792770

[1] http://reactivex.io/

Re: Companies from the YC Summer 2018 Batch

#95

Post by AriaMinaei »

jpochtar wrote: post #64
AriaMinaei wrote: post #36

Optic [0] caught my eye. They seem to have made possible a new kind of abstraction in code. Something that's different from both functions and macros. It's a kind of abstraction that can be arbitrarily customized at each call site, yet retain its identity across all of them. Example: foo = do_a() bar = do_b(foo) Example 2: foo = do_a() bar = do_z(foo) baz = do_b(bar) Example 3: foo = do_a() bar = foo + 10 baz = do_b(…

why not just function baz(modifier) { let foo = do_a(); let bar = modifier(foo); return do_b(bar); } Example 1: baz((foo) => foo); Example 2: baz((foo) => do_z(foo)); Example 3: baz((foo) => foo + 10); which lets you be more concise with baz = (modifier) => do_b(modifier(do_a()))

I explained more here: https://news.ycombinator.com/item?id=17801256

Re: Companies from the YC Summer 2018 Batch

#96

Post by Fomite »

mmt wrote: post #92
Fomite wrote: post #91

Earlier quoted context omitted.

"This sounds very much like IT/Helpdesk support, of the kind a programmer or a lab manager typically wouldn't want (and might not be qualified) to deal with, either." - Not if they were hired with that qualification in mind. "Is there something unique to your lab environment that you couldn't use some kind of shared/general IT helpdesk service, perhaps focused on scientific software users?" - It's more there are part…

> Not if they were hired with that qualification in mind. That's a big "if". That's why I said "typically". I think you'd find it difficult, if not impossible, to hire someone like that, even though they exist. This is a conceit I often see in job postings, of listing skills that belong to two (or more!) different specialties. It seems more common in cases where the goal seems to be to have two specialists for the pr…

"I'm pretty sure "prefer" rather than "urgently need" isn't compelling enough to give a startup a enough of a competitive advantage. There's also not much (if any) synergy with any of the rest of HappiLab's core competencies to make sense as an addon for them.

IT services could be just another vendor HappiLab handles."

Potentially. I think one of the things that will become more important - and will synergize - is the number of wet/dry labs. There are an awful lot of new computational servers being bought by non-tech savvy PIs.

Re: Companies from the YC Summer 2018 Batch

#97

Post by boxcardavin »

syntaxing wrote: post #80
boxcardavin wrote: post #71

Earlier quoted context omitted.

I interviewed, I've talked to several other robotics companies that interviewed for S18. Absolutely dumbfounded that none of them made it, some of these in the batch seem like they could never be worth $10b.

Do you know of any open opportunities for Mechanical Engineers on the East Coast at these robotics company?

Sorry no, I'd have to dig up my notes from the interview and I'm slammed working on my startup. You don't wanna move to the west coast? You like bicycles and robots perchance?

Re: Companies from the YC Summer 2018 Batch

#98

Post by mmt »

Fomite wrote: post #96
mmt wrote: post #92

Earlier quoted context omitted.

> Not if they were hired with that qualification in mind. That's a big "if". That's why I said "typically". I think you'd find it difficult, if not impossible, to hire someone like that, even though they exist. This is a conceit I often see in job postings, of listing skills that belong to two (or more!) different specialties. It seems more common in cases where the goal seems to be to have two specialists for the pr…

"I'm pretty sure "prefer" rather than "urgently need" isn't compelling enough to give a startup a enough of a competitive advantage. There's also not much (if any) synergy with any of the rest of HappiLab's core competencies to make sense as an addon for them. IT services could be just another vendor HappiLab handles." Potentially. I think one of the things that will become more important - and will synergize - is th…

> bought by non-tech savvy PIs.

I'd hope that's not just viewed as an opportunity exploit information assymetry by tech/IT services firms.

I do believe, however, that scientific computing needs are similar enough to general computing needs that this won't be widespread (or at least not for long). It would also mean that it would make sense for a lab services provider to offer generic IT except as a pass-through for convenience (subject to cost-saving disintermediation).

IOW, I doubt you're that special, but that's a good thing!

Re: Companies from the YC Summer 2018 Batch

#99

Post by MediumD »

addcn wrote: post #60
MediumD wrote: post #58

Earlier quoted context omitted.

I was really fascinated by this as well. I think it's a great idea. Where does the 15 hours/per developer/per week come from. Couldn't find more information about that anywhere on your website.

Before I started Optic I watched 20 developers code for 1 day each. I kept logs of what they were working on and asked people to rate how they felt throughout the process. The 15/hrs/wk is a rough estimate of what we could automate. Our most avid users over the last month self report a little less but I think once we add better support for a few more things we’ll catch up. I never thought to publish those results. So…

Would love to see your findings!
Post reply on HN