Live data from Hacker News

Ask HN: What interesting problems are you working on?

news.ycombinator.com

591–600 of 633 posts

Re: Ask HN: What interesting problems are you working on?

#591
post #520

Earlier quoted context omitted.

My understanding of the pertinent terms in this specific context is as follows: 1) Multiplying: Asexual reproduction only. 2) Reproduction: Sexual and asexual reproduction. 3) Procreation: Sexual reproduction only.

I appreciate the way you understand the terminology. However, I'm not sure everyone else understands it the same way. Although, I do admit the terms can be confusing. BTW: I don't see how 'multiplying' could refer to just asexual reproduction. People often use it in sentences like 'the deer population near here multiplied the last couple years'.

Well, I see how referring to reproduction in a herd of deer, as a collective, in everyday speech, by using the word "multiplying", but not on an individual level, which adds to my point.

As you can see, getting terminology right is challenging and not always straightforward.

Re: Ask HN: What interesting problems are you working on?

#592
post #562

Earlier quoted context omitted.

Are these body double volunteers active part of the ADHD community? I can see how this can set you apart from the competition as you have already an active and enthusiastic members among the community doing their best to help each other since they share the same background and life experience.

Double will be matching people with others that are performing similar tasks. In this way, we will be able to foster communities of people that have similar goals. Down the line, we do have ideas on incorporating “hosting” a Double to help give a sense of service and further reinforce the community aspect as well.

I got it.

Can you tell me please why opted for this esoteric and non mainstream term and not for a more common one like "companion" and the likes?

Re: Ask HN: What interesting problems are you working on?

#593
post #483

Earlier quoted context omitted.

That sounds interesting. How do plan to fund that? 100mt a year of sequestration sounds like there would be a fair amount of costs and labour involved.

For the past year I've been paying the bills (this is hardly my first startup) but we're just starting to talk to investors to bring some more staff on and start scaling up. We only need a few million for this stage. There are people who pay for GHG removal and we have plans on how to expand that. We think it can be self-sustaining.

Would love to support you on this journey! I'm on the team at Fifty Years, we've backed teams like Noya (carbon removal) and Solugen (Carbon negative chemical manufacturing). Would love to chat! Feel free to email me at peregrine at 50y.com

Re: Ask HN: What interesting problems are you working on?

#594

Earlier quoted context omitted.

One of the premises behind the language is parametric rendering. So nothing described with Matry is static. The difference, however, between Matry and something like xstate is that the actual state is intended to be left to developers, because I’m trying to create an interface that allows designers to just focus on what they need to focus on. So take something like dark mode. A designer might allow for a Boolean para…

Designers absolutely need to focus on dynamic issues and state issues. Not all state is exclusively the developer’s domain. There’s language, locale, time of day (which you mention), accessibility, screen resolution and those are just things off the top of my head that are implicitly exist as state in a designers head. Then there’s the whole idea of transitions which are explicitly about state and in designers domain…

No what I mean, is that they only care about the effect of the state on the UI.

There’s a difference between determining the state, and deciding how that state affects the pixels on the screen. The former is the domain of engineering, and the latter is the domain of design. I’m not saying at all that designers don’t care about state.

Re: Ask HN: What interesting problems are you working on?

#595

Writing automated tests for video games. Why is it interesting to me? I started to teach myself unity in December 2021. I've personally experienced benefits to writing automated tests and using CICD; therefore, I thought it would be fun to learn about writing tests for a 3D based software. It will be different from the web/CLI based stuff I usually write. So, it turns out that the video game community (or at least th…

This talk has some great ideas about testing areas that are considered untestable: https://youtu.be/5_IW7npQk9k

Re: Ask HN: What interesting problems are you working on?

#596
post #245

How does reality work? How could it be changed in a substantial, positive, intentional way, ideally in a surprisingly short time frame?

Im genuinely interested in this. Which aspect of reality? And when you say “positive”, from whose perspective or within which frame are you defining it?

> Which aspect of reality?

All aspects. Reality itself.

> And when you say “positive”, from whose perspective or within which frame are you defining it?

All of them. Reality itself.

Re: Ask HN: What interesting problems are you working on?

#598

Earlier quoted context omitted.

Designers absolutely need to focus on dynamic issues and state issues. Not all state is exclusively the developer’s domain. There’s language, locale, time of day (which you mention), accessibility, screen resolution and those are just things off the top of my head that are implicitly exist as state in a designers head. Then there’s the whole idea of transitions which are explicitly about state and in designers domain…

No what I mean, is that they only care about the effect of the state on the UI. There’s a difference between determining the state, and deciding how that state affects the pixels on the screen. The former is the domain of engineering, and the latter is the domain of design. I’m not saying at all that designers don’t care about state.

I disagree. If the UI person could handle a hover-over by defining the state themselves then they and developers would both be happier.

The developer wouldn’t need to implement yet another boolean for something trivial and the designer wouldn’t need to waste time prodding a dev to finally get around to implementing it.

That state has nothing to do with logic or state about the functionality of the program. It’s state who’s entire purpose it to control a bit of the UI.

Re: Ask HN: What interesting problems are you working on?

#599

Earlier quoted context omitted.

No what I mean, is that they only care about the effect of the state on the UI. There’s a difference between determining the state, and deciding how that state affects the pixels on the screen. The former is the domain of engineering, and the latter is the domain of design. I’m not saying at all that designers don’t care about state.

I disagree. If the UI person could handle a hover-over by defining the state themselves then they and developers would both be happier. The developer wouldn’t need to implement yet another boolean for something trivial and the designer wouldn’t need to waste time prodding a dev to finally get around to implementing it. That state has nothing to do with logic or state about the functionality of the program. It’s state…

Kind of. A simple hover, yes. But even then, there are some interactions that are fairly complex, and require in-depth understanding of the event model in order to implement correctly. Like knowing which events bubble and which don’t, for example.

I hear you though, it’s definitely more of a chore for devs to have to define all that stuff. But on the other hand, the UI would otherwise just be done by the time of handoff, which IMO would outweigh those cons.

Re: Ask HN: What interesting problems are you working on?

#600

Earlier quoted context omitted.

I disagree. If the UI person could handle a hover-over by defining the state themselves then they and developers would both be happier. The developer wouldn’t need to implement yet another boolean for something trivial and the designer wouldn’t need to waste time prodding a dev to finally get around to implementing it. That state has nothing to do with logic or state about the functionality of the program. It’s state…

Kind of. A simple hover, yes. But even then, there are some interactions that are fairly complex, and require in-depth understanding of the event model in order to implement correctly. Like knowing which events bubble and which don’t, for example. I hear you though, it’s definitely more of a chore for devs to have to define all that stuff. But on the other hand, the UI would otherwise just be done by the time of hand…

That’s why I like xstate’s visual state editor. Engineers and designers can both reason about and modify it in tandem.

I think most event models are conflating things much more than they need to be. By having clear point where the data model interacts with the UI model both sides have better clarity. Yes there are complex interactions, but designers also need to understand the model interactions to design the UI correctly.

If you have teams working on a single project and not communicating you’ll have problems no matter what tools you’re using.

Post reply on HN