dnbgfher

Right... and then they got a response that they might want to ask a different question along with a suggestion of how to answer it.

Now you are trying to treat that solution that is explicitly meant to answer the new question as if it were an answer for the original question, going so far as to apply logic issues from the old onto the new.

Discussions, particularly ones of this nature, change and shift direction. It doesn't mean that later topics inherit logical traits or something from earlier ones.

Their comment wasn't directed towards improving the ratio. They were suggesting that the focus should instead be on the current users. I imagine this is a result of everything being so new, they think it makes sense to take some time and figure out why people are actually using the app before trying to tackle more directed problems like the uninstall ratio.

In that context, it's really not a survivorship bias. If you want to know about the survivors, it's not wrong to consider the surviors only.

I'm not sure I see the reason reality and laws must be made to match. I don't see that as something that is inherently all that valuable (if at all), and certainly not to the degree that it's worth doing whatever is easiest regardless of costs to make it happen.

What? Rightsholders aren't going to respond to reality, so in order to let them continue to ignore it we should ramp up enforcement methods, further isolating rightsholders from being forced to deal with it?

How does this make any sense?

From other comments, it sounds like something called Cocalc might be of interest to you. I haven't even looked at it yet but it sounds like it does at least some of those things.

> My solution is to try to condense the useful code built up across different cells into a reusable block, most often a function. Do that while the 'state' is still fresh in your mind and you remember the order of execution.

Right, that's the sort of thing I was talking about in terms of "using it right." It makes sense and is really a good idea, it just starts eating into the advantages you get from using Jupyter in the first place.

I'm still trying to figure out how best to integrate it in my workflow. So far I've mostly settled on using it to get some rough ideas about the data and libraries I'm using, and then just reworking from scratch in a more stable setting. As needed I'll go back and try things out there, possibly in a new notebook entirely and just do my best to copy/paste the setup over. In getting it working the setup stuff at least gets consolidated. It's... well awful but eh, I haven't really found a better way.

Maybe I can provide a bit of perspective on this, as I have lots of conflicting feelings about Jupyter.

When I'm doing some bit of data wrangling or just exploratory work with data I quite like it - at least at first. As you pointed out, it's really easy to extremely quickly iterate on things and start to get an idea of what's in the data, what techniques work, and which don't. It's great.

Until it isn't. I'm probably "using it wrong" but all the suggestions I've seen for doing it "right" start cutting into the iteration time. If I'm in Jupyter it's because I want to flail around real fast and see what happens. And that causes all sorts of problems. Which cells do I need to rerun together? Which cells should I not run again. What the heck is actually in all these variables right now anyway, because I don't remember which order I've run (and rerun) all the cells in. And what was that one approach or parameter that really worked well that one time? I don't remember.

These sorts of things aren't an issue with a non-Jupyter approach. And because I'm taking my time anyway I'm probably being diligent with source control, and all that. Even pulling code out of a notebook into a more stable workflow is a pain, because you have no assurances you can just copy/paste a cell and have it work. In my experience, it never will.

It's one of those things that has a pretty heavy costs and benefits. And unfortunately they aren't really possible to separate.

Not coincidentally, I feel the same about dynamic languages and even less usefully typed static languages. Jupyter takes an already fairly extreme position on the stable(safe)/easy continuum and really ramps it up to a point where it's hard to wrangle time and work done easy into some sort of stability. It's great, and it's awful.

Having done just enough robotics stuff to have used linux before (though not controlling anything even kind of large), I find this an odd notion. It's not that I think linux would go wrong for this sort of thing often, but when dealing with things like rockets or self-driving cars I'd think you want more assurance than "well we haven't had it be slow yet."

I haven't messed with an RTOS before but have done some fooling around with scheduling on microcontrollers and I can see why linux is tempting for ease and speed. But we're talking rockets and self-driving cars. These things are expensive as hell, can easily kill people, or both. It seems like the exact sort of place you'd want to take the time and effort to be sure.

So I'm coming at this from the perspective of somebody that has been vegetarian for about a decade or so.

I agree the bleeding bit seems pretty gimmicky, but if it helps convince non-vegetarians to give it shot it might make sense.

Otherwise, I rather disagree with your post. It's certainly one of the better veggie burgers that, to me, tastes quite a bit like real meat. The Beyond Burger, which is in the same niche as the Impossible Burger, actually tastes too much like meat for my mother (vegetarian for far longer than me) to enjoy. I don't think I'd confuse either of those for real meat, but it does hit a lot of the same notes which is more than I can say for any other veggie burger I have tried.

A friend who really enjoys his meat tried the Impossible Burger and found it almost identical to some non-burger meat. I think it was some sort of pate from an animal I don't think many Americans usually eat.

I suspect you haven't tried many of the standard grocery store veggie burgers. Like so many vegetarian and vegan products, despite their branding they are really more for making a new dish that's similar to the meat version. I think if they branded themselves more as alternatives rather than exact replacements they would be far more acceptable to people.

Only recently, with products like the Imposible and Beyond Burger, have we started to see products that are really starting to push into the realm of direct replacements. I don't think it's fair to call them just average veggie burgers.

Interesting.

But as an external package it still has the issues I described as not being part of the defaults of the culture. Without that it just becomes a nice-to-have that only people serious about writing good quality, usable code are going to use. And these are the people most likely to have good documentation in any case.

This is not that hard of a problem to solve to a useful level.

If you want to get fancier, yeah, it gets hard. But something as simple as a syntax block that lists the interface methods would be enough for now.

The fancier stuff is already projected so far out to at least 2.0 that I don't understand why a simple working solution wouldn't be desired for now. It would also simplify the work of changing code later to work with 2.0.

I really don't understand how this issue wasn't addressed a long time ago, and why it wasn't a blocker for 1.0.

I think you need language changes no matter what. I've seen some of the previous trait packages and while extremely cool, they're insufficent for tackling this problem for a couple reasons.

First, this extends deep into the core of Julia, and I don't see how a traits package would be involved with that.

Second, and this dovetails with the first issue, this needs to be something that people actually use as a default action. Part of that means ensuring the built-in types make use of this.

Related to all of this, I worry it's too late to really make a meaningful change here. The culture and existing packages are already set without it. Adding the feature as a requirement isn't going to happen anytime soon unless people are willing to continue to break things post 1.0. And it needs to be a requirement or it won't get used except by people that will already provide documentation.

The lack of interest I mentioned mainly came from some github issues which either received little attention, had creators that had a very "maybe it would be nice if" attitude, and responses that were questioning the benefit compared to the cost of implementing the syntax changes.

This seems like a good argument for improving the quality of prison food in general, rather than only allowing prisoners with access to money to improve their own situation.

I'm sure this is too late to get much visibility, but I recently looked into using Julia (for my MS thesis) and found it sorely lacking in one major way that I found unforgivable.

Their type system is pretty interesting, and allows for some really cool abilities to parameterize things using types. I'd like to have seen more work done on, effectively, strong typedefs (or whatever $lang wants to call them). However that sort of thing is fairly uncommon so it's hard to hold it against them too much.

The biggest issue, and one they seem unwilling to really address, is that actually using the type system to do anything cool requires you to rely entirely on documentation which may or may not exist (or be up-to-date).

Each type has an entirely implicit interface which must be implemented. There is no syntax to mark which methods must be present for a type. No marker for the method definitions, no block where they must be named, or anything like that. You can't even assume you'll find all the interface methods defined in a single file because they can appear literally anywhere.

Whoever wrote the type has in mind some interface, a minimal set of methods, that must be present for any derived type. There are only two possible ways to determine this. The first is to look to the documentation. Even for the basic types defined by Julia this documentation doesn't seem to exist for all types. I don't have high hopes for most libraries to provide, and keep up to date, this documentation either. This concern gets even greater when considering the focus is largely on scientific computing.

Without up-to-date documentation, the only option is to manually review every file in a library and keep track of the methods defined for the type you're interested in. With multiple dispatch, you can't even get away with just checking the first parameter either. Then you need to look at the definitions for those methods to narrow your list down to the minimal set required. This is not an easy task.

This issue has been brought up before and discussed, but nobody seemed very interested in it. This is a fairly major issue in my view, as it cripples the otherwise very interesting type system. As it stands, it seems to be a fairly complex solution to the issue of getting good compiled code out of a dynamic language. It could be so much more.

I mean, a canary is only as good as your trust in the people putting it out.

As for the engineer/management idea,their statement revoking it was signed the same as their canary. Aside from the exceptional circumstances I described earlier, if you trusted their canary then the statement should be trusted too.

Like I said, I think we're most likely looking at incompetence.

While I agree the canary should be considered dead on principle, I don't find this particular argument very convincing.

I think the main point here needs to be that the entire notion of a canary only works if we can count on them being killed only for the purpose they were created. If it becomes acceptable to kill canaries because the signers are tired of signing them then we have a bit of a problem.

Now, for this specific case...

It sounds like you are arguing that a NSL has compelled them to make false statements. This seems fairly unlikely given what we know about the current legal situation. The idea that they may be lying for the sake of their business is more convincing.

However, if they are lying for whatever reason, why not just continue to sign the canary? The only plausible reason to do this is some sort of malicious compliance with a sloppily worded order compelling them to lie. It would make no sense for them to decide to lie for the sake of the business and then do all of this instead of just signing the canary.

If they have received a NSL this basically leaves two sequences of events, both of which contain some rather unlikely events. If I had to bet, I'd probably bet against them having received a NSL.

However, the canary should still be considered dead. They literally killed the canary. Their reasoning provided for it is really quite bad. Basically they ask users to trust their unsigned website because users already trust their (closed source) code. So they have either received a much more powerful NSL than thought legally possible, or are doing the worlds worst job of lying about not receiving a NSL, or they have not received a NSL and view a regular page on their website as a suitable alternative to their previous solution which involved three people in three different countries signing the canaries with keys stored on air-gapped computers. If you are counting on them for security, none of options are good.

I'm not sure the comparison to the actual canary in a coal mine is particularly relevant here. Clearly that inspired the name, but beyond that...

Assuming it is a good comparison - if you are the one in the coal mine and the carnary keels over, are you going to start trying to figure out the exact cause of death or just hurry up and get the hell out of the mine?

I'm not sure why you wouldn't. You're spending a significant chunk of your time at the office. If you are uncomfortable all of that time it's a significant issue.

I mean if your job only allowed you to sit on a small unpadded stool, wouldn't that motivate you to find a new job?

For me, yes. Even at 65 I'm very happy wearing shorts and tshirts.

Meanwhile you have people like me. I'm are already uncomfortably hot no matter how I'm dressed (or not) at 78. Even in shorts and a tshirt, most offices are warmer than I'd prefer.

This may be my own biases at play here, but it's really not that hard to warm up by dressing warmer. You don't have that option for cooling down unless you want to wear a vest full of icepacks or something. If the goal is to maximize comfort, it seems like the thermostat should be set lower rather than higher.