skore

I see no way to get a hold of that particular soundtrack and searching the web failed me. How did you get a copy? Any tips?

skore

4 年前議論

Would also highlight Martin Owens' Video: https://www.youtube.com/watch?v=TMHnyL4cRYA

He has been consistently putting out videos on his process and has been a (the?) main driving force behind the new pages addition.

He's also on patreon: https://www.patreon.com/doctormo

skore

5 年前議論

https://en.wikipedia.org/wiki/Ever_Given

vs.

https://en.wikipedia.org/wiki/Evergreen_Marine

skore

5 年前議論

"issue" filed. My apologies for the lack of brevity.

https://github.com/build2/build2/issues/135

skore

5 年前議論

Very likely, yes. I'm generating my own makefiles anyways, so generating something that build2 could consume should be possible, too.

Would it be appropriate to open a github issue for discussing this further? I would like to share some example for how my current setup is working and having the github syntax available would be helpful.

skore

5 年前議論

Very VERY interesting!

The one thing that I'm currently struggling to find information on is dynamic dependency handling (dyndep in ninja terms).

Is that something that build2 covers as well? Any resource you could point me to?

skore

5 年前議論

That looks very good! I wonder if I can make it fit my file-based approach.

edit: Yeah, doesn't seem like it.

skore

5 年前議論

I will check it out, thank you for the suggestion - what I glanced at seems very interesting.

skore

5 年前議論

I've seen it before but discarded it because since my workflow is heavily file-based, I DO need makes capacity as a build system, not just a task runner. Will check it out to see whether that changed.

edit: Yeah, I can't see how I can make it work for a file-based approach.

skore

5 年前議論

To me, the core of the syntax is:

    target: prereq | ooprereq
        recipe

In my eyes, the most important thing when building something that is complex is the dependency graph and it makes sense to make the syntax for defining the graph as simple as possible. I think the make syntax just nails it and most of the other approaches I have seen so far add complexity without any benefit. In fact, most of the complexity they introduce seems to stem from confusion on the side of the developer being unable to simplify what they're trying to express.

At the level of variable handling and so forth, make is slightly annoying but manageable.

Anything beyond that - yeah, I'm with you, a lot of that is terrible.

skore

5 年前議論

I just wish someone would RIIR Gnu make.

I use it heavily and think it's extremely underappreciated, so instead of reinventing it, I would like to build on it. But - trying to extend the old C codebase is daunting. I'd even be happy with a reduced featureset that avoids the exotic stuff that is either outdated or no longer useful. The core syntax of a Makefile is just so close to perfect.

(I wrote about some of this in the remake repo: https://github.com/rocky/remake/issues/114 )

skore

5 年前議論

6 years into writing my own kind of SSC, based entirely on make.

AMA ;-)

skore

6 年前議論

I do understand you're not reading the replies and I'm trying to not make the same mistake that you did, so I'm not responding to the emotional content (which I could, at length, in kind) of your message, but what I think is the meat of your misunderstanding.

I find it odd that you're focussing on making people understand that many in your profession care. It has been my experience that most health care providers… care.

Let's suppose that health care is like any other profession - let's say it's just like programming, something most people understand deeply on here.

We all know programmers who care and programmers who don't care. The best programmers I know are the ones who care, are competent, but also able and willing to have their understanding of the subject matter challenged. They're not married to their craft - they keep the right distance to excel at it.

The worst ones I know are those who care just as much, but are utterly incompetent. The ones who are so deep into it that they literally cannot see any other way. To them, everything is clear and obvious. They're willing, enthusiastic and overjoyed to be working. And they're wrong. There is not a codebase they touch where every hour of work they put in produces ten or twenty times as much work for others, later on.

I think caring about your craft is a force multiplier and it's a necessary one. You don't want a mindless drone who doesn't give a damn about either your health or your codebase, no matter how competent they are. To care means to have a vital part of you engaged in such a way that all that you could bring to the table does get there. But it has to be lightly held and accepting of being challenged.

You care. I get it. But that doesn't mean everybody cares. (Again, really struggling here to not respond in kind with examples of people I have met who clearly did not care.) And even if everybody did care - some people are actually more useless the more they care.

But - it's up to the customers (or patients) to navigate that landscape. There has to be a mutual understanding that all parties involved are just human and can make mistakes. Our understanding of health care moves forward and things that are standard care today had to be invented, sometimes just a few years ago, often replacing things that used to be just as firmly a standard, before. Challenging what is accepted practice should be a healthy part of this interaction.

There's a limit to how many people care. There is a limit to how useful it is that people care. There is a limit to how effective you can be for your patients when you walk around with a chip on your shoulder, thinking that people just don't get how much you care.

skore

6 年前議論

Thiel actually lampshades this himself:

> Warp drive is in fact hard to take seriously because its basic physics are so far beyond the furthest reaches of our knowledge as to debilitate would-be researchers—not to mention reasonable doubts about the friendliness of faraway foreign species. (Some of them, I assume, are good aliens.)

skore

6 年前議論

Ouch, that "Subscribe today" banner should have its fonts either embedded on the page or rendered into paths. Without that, it looks like this: https://imgur.com/a/kxie7Cb

skore

6 年前議論

Goodhart's law - "When a measure becomes a target, it ceases to be a good measure."

I used to work for a company that bills their customers for dev hours spent. The software they put together worked fabulously well - in the production of billable dev hours.

skore

7 年前議論

Since some people might pay again to see the "improved" version (after some of them likely saw the original version to see for themselves what all the screaming was about) - is this a film industry version of a DLC?

skore

7 年前議論

The frustrating thing is - the more you learn about what the OS can do, the more you realize that many programming languages and the applications written in them quite often reimplement large parts of the OS for an astonishingly large portion of their codebase. That isolates developers from learning about the OS in the first place. (They always end up needing to learn about it, anyhow, so it's a bit futile. Now, however, they feel smug about it and pretend like they shouldn't need to learn all this OS stuff.)

I guess developers always implement their own ignorance to a certain degree (and how could they not!? except, you know, spending more time learning their craft). What they don't know the OS can do, they will recreate - often poorly - in their own software. It does get rather comical and the various frameworks that you can subscribe to in modern programming languages repeat the concept, just that now, you're reimplementing things that the language can already do, but in the framework.

My favorite example is the various kinds of "service" patterns, like dependency injection - in many instances that I've seen, you could boil most of its use down to simple function calls. But since global functions are ew, you instead create a service that you inject and then call a method in. Boom, the gods of OOP are happy and nobody is allowed to say: "Wait a minute, if I take a few steps back and squint a little, what you're doing looks surprisingly similar to a global function call."

(And yes, I know, DI is supposed to be about overriding functions, yada yada very few people actually do that and it's often such an organizational hassle with downstream problems that projects eventually resort to put up conventions from doing that most of the time. Anyways - tell that to the people that I've seen implement, I kid you not, a CamelCaseService.)

skore

7 年前議論

Yeah, I'm using a preprocessor to generate the makefiles from what is basically blueprints.

skore

7 年前議論

Yes! It's basically a built-in stack trace! Permanently written straight to your disk!

It does get unwieldy after a certain size, but that's what I'm building tooling for.

投稿

I want an Eben Moglen in my office.

Mark Blyth: Austerity - The History of a Dangerous Idea

OK Soundcloud, I love you, but here are eight things that have got to change

コメント