chrsig

which is actually pretty often for a demo!

I hope you can appreciate that the problem here is that the proposition that you "aren't going to change" is entirely unfalsifiable, reliant on trust, and that the individuals making the proposition are in a position to enforce it ad infinitum.

Consider me skeptical.

Because I wasn't hurting enough without having to worry about parser alignment.

That's a very reasonable boundary. Health insurance covers therapy, it's reasonable to expect coworkers routinely exhibiting unacceptable behavior to make use of behavioral therapy and show that they're at least working on the issue.

It's also amazing what a "sorry, x,y, and z are very hard for me, I'm doing my best and still learning to do better" will go. Of course, not everyone receives that with grace, but that speaks to their character.

> I'm begging to be rejected because I don't want to work with such people.

...you do know you can reject the position, correct? You're not obligated to take the job once the interviewing process has started.

> Since that education is sorely lacking, I made a course. It's called Team Dynamics and Soft Skills for Developers. I put my 25 years of dev, management, tech education, and interpersonal communication training into it. I think you and your team will find it useful.

There's the pitch.

Most of the time people aren't trying to be jerks. They're just not having a need met. They may or may not know about the need, or may or may not be working to address it. It may be something that you're responsible for that you're not acknowledging.

Don't underestimate how far a little humility, open ears, and boundary setting might get you. Writing the person off as a jerk just makes the problem worse.

Not to say you're responsible for anyone elses bad behavior, but it's also not ok to pin all the problems of team dynamics on one person. Having a emotionally healthy productive team is a lot of work, and it's a group effort.

Hmm. I'm going to go ahead and blame twitter here. I don't see any additional links in the tweet or anything.

Is there more of an explanation? I see a baseless claim without any specificity.

I'm not saying it's right/wrong, just that no evidence was presented.

So first of all, thanks for writing the books. I'm a happy customer :)

Second, I felt a lot of empathy for this, having gone through a similar situation, ultimately the company getting acquired during the pandemic.

I've learned many things, but I think I can share one takeaway that might resonate in this conversation:

Know thy users.

Keep the people that are directly using the software in mind. In times of corporate strife: remember the users. Let their happiness be your guiding light.

There are real people that depend on the software we write. Regardless of how any corporate decision turns out, those people will always be thankful that you made their day to day lives a bit easier.

Find the disproportionate pain points. That one preference that were it defaulted differently would save 90% of users a one time frustration when on boarding. That one janky error message that no one understands. Fix that sort of stuff, the stuff that users are interacting with regularly.

At the end of the day, unless you're contractually entrenched at oracle levels, if the users aren't happy, then whatever corporate structure that puts food on your table probably wont do well. They may not do well if users are happy, but very likely wont if users are angry.

Any given change might not matter to your executives, but they matter to your users, keep them in mind and heart and you'll know what to do. And periods of corporate strife like in the article are a great time to actually get that sort of stuff prioritized, because no one can say anything else is more important.

> Who will judge this once the ball gets going? The judges now appointed by you?

This is what lifetime appointments were intended to address. There's no incentive to rule in the president's favor. Of course, now there's the prospect of gratuity for services rendered.

Slightly tangential question: Where is jsx defined, as a language? are there multiple transpiler implementations? is it standardized at all?

Commands can have a maximum number of arguments. Try globbing on a directory with millions of files.

My hero!

I looked into what it would take to tackle it from the source code, There were some barriers, like the jars not really being published to maven, but the biggest just being the time & energy investment to pick up java again.

I'll definitely be looking into this project and seeing if there's anything I can contribute back.

I've been learning Alloy[0], which I think is probably more practical for most software engineers. I'm using it with the goal of documenting and decomposing a legacy system that I've been working with for a number of years.

It's more geared towards the static elements of the system, and writing a spec feels quite like writing a relational database schema -- mostly because they're both expressions of relationships.

It seems like a pretty natural path to write a spec in alloy before building out some crud interface.

I think there's a huge tooling gap though. Alloy, TLA+ and friends all seem to be very jvm/UI centric, really targeting a user who is working in the editors the language ships with.

I'd really love to see more tooling to run model checkers in a CI pipeline, or generate stubs and test cases for various languages. If that were in place, I think there would be more stickiness to formal methods.

I've started writing a Go parser for alloy, in part to learn it better, in part because I know go and want to write some tooling that I think go would be a good implementation language for. I don't know if anything will come of it, but at least having a parser would allow for things like a formatter or code generator. If I were feeling ambitious, I might try to implement a model checker.

[0] https://alloytools.org/

> Some bit of reflection magic which allowed objects to remove methods from their method sets at runtime would be perfect. You'd just use interface upgrades and you'd be sure that it would work.

Given that methods sets are...sets. I'd be interested at a language level, what it would look like to add some notion of set difference or expressing disjointedness in some way, e.g.,

    type ReadOnly retraction {
        Write([]byte) (int, error)
    }

    type ReadOnlyFile struct {
        ReadOnly
        *File
    }
 

where `ReadOnlyFile` would have all of `*File`'s methods minus the methods defined in `ReadOnly`

restriction probably isn't a good term, I could see it easily being misinterpreted, but I haven't all day to ponder it :)

(edit: after publishing I realized `retract` might be more clear)

I don't know if it would ultimately simplify the problem or not, but I agree that having some way to easily mask or hide a method subset could be quite nice.

Edit:

I want to add that the idiomatic thing to do now would be

    type ReadOnlyFile File
    / *proceed to implement every method you want accessible */

maybe something like the following could be possible

    type ReadOnlyFile retracts *File {
        Write([]byte) (int, error)
    }

I face this a lot, and I think you have one very valid approach to it that I often employ. Especially if you have some centralized point to make a list of structs, or walk a tree to collect them.

I think another other route is to provide lots of tooling to inspect the object graph -- include a pretty print function in the interface or something to that effect.

There's equivalency between the two, the struct with pointers to implementation functions can implement an interface. Likewise, the implementation functions may call other implementations, so you haven't exactly solved the proxy problem, the state controlling which implementations becomes function local instead of on a struct. Unless you start to provide a struct with all of the context, at which point you've actually re-invented interfaces. I've grown wary of having too much of the details as function local like this because it hinders making more advanced tooling by hiding intermediate state from reflection.

The interface provides the means to give other representations, and allows for embedding one within another, and gives runtime tooling to inspect underlying types. It gives more elegance and flexibility to the problem at language and standard library scale.

One of the nice things is that it gives a sort of bidirectional refactoring path. If someone chose struct-of-pointers and it's at it's breaking point, those structs can stay as is and start to implement the interface with minimal effort. Likewise, if I need to boil down a hodgepodge of implementations into a really simple control flow, struct methods capture the struct and can be passed around as ordinary function pointers, so I can built a struct out of existing interface implementations.

There's no real way around the complexity -- leaky abstractions are a thing. I think the author got it right: use interface upgrades and proxies sparingly. If they are the right tool for the job, then it's probably a good idea to go the extra mile to provide good documentation and instrumentation with extra attention to caller/callee expectations.

Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.

It's in the category of "you better have a damn good probable cause" if you want to forcibly intervene with publishing.

> you're going to get some "average" Shakespeare

The point was that no, you wont (necessarily) get some "average" shakespeare. A sampler may introduce bias and look for the "above average" shakespeare in the distribution.

I really appreciate the simplicity of the DSL presented.

I'm curious how you see the project evolving as you add those things. How do you see it differentiating itself from rails or django?

This really stood out to me. Fork a github repo and manually merge in every upstream commit yourself if that's how you want software delivered to you.

This is perhaps the most practically useful thing to come out of academia since the technology that allowed for the leaf blower.

They're the worst. A noise pollution posterchild.

Have you seen....people? Quality of an idea has marginal influence on people's decision to execute on it.

I don't know if I'd call it a "web shell", or what that would really mean. It's a dsl for content generation that got not enough up front thought followed by an unreasonable time and human suffering investment.

It's in a better situation now than it was. I hope.

It's a sophisticated bike shed. Much more of the population has a working knowledge of go than about the linux kernel's Usermode Driver API

...So what color is their gopher?

You're just experiencing time passing on the internet. Some discussions spring eternal, because there's a constant stream of people having it for the first time.

I can +1 this approach and report a good amount of success with it using mysql.

it really enabled end to end level testing as well as being able to stand up development instances quickly.

I don't think that there's a "win" here. It's just sort of which way you tilt your head, how much space do you have to cram a ton of cores connected to a really wide memory bus and how close can you get the storage while keeping everything from catching on fire, no? ("just sort of" is going to have to skip leg day because of the herculean lift it just did)

It's a fairly fractal pattern in distributing computing. Move the high throughput heavy computation bits away from the low latency responsive bits ("low latency" here is relative to the total computation). Use an event loop for the reactive bits. Eventually someone will invert the event loop to use coroutines so everything looks synchronous (Go, anyone? python's gevent?).

After it seems to me that the only real question is if takes too long or costs too much to move the data to the storage location the heavy computation hardware uses. There's really not much of a conceptual difference between airflow driving snowflake and c++ running on a cpu driving cuda kernels. It takes a certain scale to make going from a OLTP database to an OLAP database worth it, just like it takes a certain scale to make a GPU worth it over simd instructions on the local processor.

I'm by no means an expert in the topic, but to share my take anyway: It seems to me like there's just diminishing returns in SIMD approaches. If you're going to organize your data well for SIMD use then it's not a far reach to make it work well on a gpu, which will keep getting more cores.

I imagine we'll get to a point where CPUs are actually just pretty dumb drivers for issuing gpu commands.

That's somehow both a much less elaborate and significantly more invasive approach to pranking wfh coworkers.

Anticipation is a hell of a drug. You'd think they'd start improving their technique though.