zenhack

Neat; simple but I like it. One concrete thing that jumps out at me as I play around with it: I keep instinctively trying to hit Ctrl+Z to undo, which doesn't work (and then I remember there's a button). Might be nice to make that shortcut work.

Also: I enjoyed this:

> No BS

> Browserboard is written by two people in their spare time who aren’t thirsty for advertising dollars. We have no reason to spam you or violate your privacy.

A thought: any interest in porting to Sandstorm? It seems like the app would be a perfect fit, and giving people an easy way to run it themselves gives you an out if it gets too popular for you to keep running it for free. If you're not familiar:

https://sandstorm.io

Relevant blog post: https://sandstorm.io/news/2014-07-21-open-source-web-apps-re...

(Disclosure: I am one of the more active contributors to Sandstorm)

Yeah, I think there's a lot of potential in hybrid models like this. You actually do see these things out in the wild -- GUI builders come to mind -- but they're not a replacement for a proper programming language.

As it turns out, the written word has some genuine advantages over other media? But on that point, the wall of text you see in published prose is an artifact of the printing press -- prior to that it was unusual to have long texts that didn't include little sketches, diagrams, illustrations...

Indeed, Amazon's behavior isn't the same shape as a typical monopolist. Krugman wrote an article a while back about this that I think cuts to the heart of the matter:

https://www.nytimes.com/2014/10/20/opinion/paul-krugman-amaz...

> thank god the FBI was able to order Facebook to hand over the comms of that MS-13 gang.

I think you may have misunderstood the article? It says Facebook won the case, and did not have to wiretap the app.

I don't see what is to be gained by the public not knowing why.

Yeah, this is kinda the cost of not having an encode/decode step. The Haskell implementation (of which I am the primary author) provides a higher-level API with "normal" data types for cases where performance requirements aren't stringent enough to merit the extra burden on the developer. I'm mostly interested in RPC, so I rarely use the low-level API myself...

Skimming the implementation, there is buffering, but it looks like it's bounded, so tight looping Write() you should still end up blocking on the OS at some point.

off the top of my head https://godoc.org/golang.org/x/net/websocket has a synchronous read/write api

Some of it is also that, much like in comparison to schema-less protocols, it's a bit of an apples-to-oranges comparision at the RPC level, since capnproto's RPC is so much more expressive -- but also complex to implement. I think only some of the difference in available implementations is due to reduced engineering effort; the long-tail of serialization-only implementations is testament to the fact that implementing cap'n proto rpc is Not Trivial. Unfortunately, I think a lot of this complexity is inherent to what cap'n proto rpc is trying to do.

Thoughts on Sam? It seems to me like it might be a much better fit, esp. given the ed-like command only mode. (And I always liked it better than acme anyway...)

The signing schemes I've seen used in binary protocols fall into two categories:

1. Canonicalize and sign: the format has a defined canonical form. Convert to that before doing cryptographic operations. If the format is well designed around it, this is doable, whereas JSON doesn't really have this and with many libraries it's hard to control the output to the degree that you'd need. 2. Serialize and sign: serialize the data as flat bytes, and then your signed message just has a "bytes" field that is the signed object. This is conceptually not far off from the base64 solution above, except that there's not extra overhead, since with a binary protocol you'll have a length prefix instead of having to escape stuff.

The difference is that with coroutines, yielding is explicit. Tight-looping will hog the CPU, and a blocking call will block other coroutines too. Typically "green threads" are semantically just threads but cheaper. They're scheduled independently, so there's no risk of them hogging the CPU, and you can use synchronous apis. The one downside is that you need explicit synchronization between them, whereas with coroutines you can mutate shared data structures and not worry about race conditions as long as you don't yield in between.

+1 for the bit about machine generated code. I think if you're going to have significant whitespace, Haskell does the right thing here: the indentation rules are specified in terms of automatic insertion of braces and semicolons. Almost nobody is them in by hand, but they make codegen easier.

Re: the bad merge, that can happen the other way to: this was the cause of Apple's infamous goto fail bug. I think block structured languages should do what go and some others do: braces on conditionals and loops are mandatory, parens are optional.

Are we even at the point where routers reliably support multicast?

The article actually advises setting fields to NOT NULL unless there's a specific reason to do otherwise.

And re constraints: eh, for most applications this feels like premature optimization. My usual approach is to include whatever constraints are easy to express, but also have the application not rely on the DB for enforcement. That way you get some extra safety checks that might catch bugs, but if they do become a bottleneck you can just drop them.

Not a DBA, just a software dev who's learned not to sacrifice safety for perf unless there's a clear, demonstrable need.

I struggled with this for a long time, I think a lot of us do. I don't know how broadly applicable my story is, but: at a certain point I basically cracked and picked a project and said "I'm going to finish this if it kills me." It was one of the larger-ish projects that I'd made a bit of progress on and put aside. The project became an exercise in finishing things, which helped motivate me through the times when I wasn't really interested in the project itself.

It took me longer than I care to think about to complete it. I think by the end I was pretty clear with myself that I wasn't really that interested in the project itself anymore; the point was to learn to finish something.

The result is here:

https://github.com/zenhack/haskell-capnp

Somehow this actually worked, and I've found myself not having that much trouble sticking with projects when I decide I want to build something. Most of my 2019 hacking was on a new programming language, which is "close" to being ready to announce (the code is up there if you look for it, but I haven't been too loud about it since I don't know what I'd tell someone if they showed up and wanted to help), though Sandstorm got active again and that's diverted some of my time. ...and I've been hacking on Sandstorm pretty consistently since.

Keeping myself organized and on track is still a struggle, but something shifted and sticking with something long term doesn't seem as hard.

ADHD is absolutlely a real thing, it is treatable, and there is a large adult population that is undiagnosed. If you're struggling and you suspect it may be related to ADHD, you should look into getting tested.

My girlfriend got her diagnosis just a couple years ago (she's 38 now). The impact Adderall has had on her organizational capacity is immense.

> Life is not fair, and you can't fix it.

I don't think the fatalistic attitude towards changing the system is any more (or, as much as I hate to admit it, less) reasonable than the "you could be Steve jobs too." Odds for both are pretty bleak, albeit non zero.

As advice to an individual in a rotten system, "make the most of what you've got" is fair enough. But when folks talk about politics they're not usually fishing for personal career advice. So when you bring this up in that context, either you've missed the point, or you're trying to distract folks from the issue at hand.

It seems like that's a concern with any testing strategy that mocks out some part of the system. Obviously there's no getting around actually testing against the hardware, but it seems like it could still be useful for the same reason tests with mock implementations are useful generally.

> Your second point I disagree with; I think if people raise objections, encourage people to switch, and volunteer to shepherd others through the technical details -- then people will be agreeable, and we'll see a shift which will gradually become pervasive.

This doesn't square with any experience I've ever had trying to get $alternative_technology adopted because of $principle in favor of $default_thing, and from what I've gleaned talking to others, and reading the experiences of others online, the problem isn't me.

Maybe post Cambridge Analytica the world has changed -- I at least don't get looked at like I have three heads when I tell people I'm not on Facebook anymore -- but if folks are still responding to complaints about privacy issues like this with what amounts to "meh, don't have the energy" then I'm skeptical. If zoom becomes "the standard," I don't think the inertia will be much easier to overcome.

I don't think we should be giving them tax breaks for investments that are only for themselves. They're going to do that anyway because it expands their business. If they were doing something that had a genuine public benefit, that they otherwise wouldn't do, that would be a different story.

The devil is in the details; a lot of the things they're getting tax breaks for don't benefit the public. Why are they getting tax breaks for building warehouses and data centers for themselves? Stock based compensation for executives?

Also, regardless of what breaks are available for what activities, their baseline tax burden ought to be much higher. We should be drawing funding from people who can afford it and use it to lift the burden on people who can't.

I'm not really interested in judging Amazon; they're a for profit company, they're going to do what's best for their bottom line. And I'm sure they don't care what I think. This is more about the systemic issues with the tax code itself.

> You realize the top 1% already pay for a disproportionate amount of the taxes?

In absolute terms maybe (though there are some glaring exceptions -- Amazon famous literally pays $0 in taxes), but not relative to how much they make.

> To tax people's wealth on top of the standard tax is plain evil,

I don't see any reason why taxing net worth is at all less sensible than income. If anything I think it makes more sense; why should someone who's had a lucky break but is still not rich have to pay taxes like they are?

> will end up driving all the wealthiest people out of the country...

I don't take seriously the idea that any of them are going to give up living in the US over a couple percent of their income (which is what the wealth taxes folks have been talking about would take, at most).

> As for endlessly scrolling the newsfeed all day, well that is not so much Facebook's fault as that people who do that are probably having too much idle time and not knowing how to do some productive or more creative activity. If Facebook did not exist those people would trawl through Twitter or Youtube or something else.

ehh... yes and no.

On the one hand, there is something to the idea that folks should take responsibility for figuring out how to not waste their time like this (if they consider it a problem; if you want to spend all day on goofing around on the internet, have fun I guess). There's some internal motivation required to make that happen that's a skill worth learning.

...but on the other hand, companies spend a ton of money researching how to keep people "engaged." This includes hiring psychologists to help them fine-tune the crap out of their platforms to make them addictive. Given that level of manipulative behavior, I don't think it's entirely fair to blame the users. And yes, without Facebook they might just do the same on Twitter or YouTube, but those platforms are doing the same thing. It doesn't make it ok just because everyone else is doing it.

I'd actually put modern crypto in the opposite bucket: there's virtually no physical constraints at all. You could do RSA by hand if you had to, and if nobody else has computers, you can pick a key size small enough for doing it manually to be practical.

I stand corrected.

I wish there was some nice off the shelf embed able FOSS DB like SQLite, but with datalog as a query language.

This is actually not true. Prolog is Turing complete, SQL is not. WITH RECURSIVE is limited to cases where you could basically use a simple foreach loop. The postgres manual has this to say:

> Note: Strictly speaking, this process is iteration not recursion, but RECURSIVE is the terminology chosen by the SQL standards committee.

That said, the feature was to some degree inspired by datalog.

EDIT: I should probably clarify, many dbmses probably have extensions that do make SQL turing complete, and the current standard is if you count stored procedures I guess. But CTEs themselves are more limited than what Prolog does.

> Set a pointer to and address and write to it. Better yet, I can define a packed struct that maps to a peripheral, point it to its memory address from a data sheet, and have a nice human readable way of controlling it: MyPIECDevice.sample_rate = 2000.

Just make sure you don't forget `volatile` in the right places. A lot of codebases end up just using their own wrappers written in asm for this kind of thing, because the developers have learned (rightly or wrongly) not to trust the compiler.

To be clear, it's not that hard to get the memory layout semantics you want in C. But issues around concurrent access, when it is acceptable for the compiler to omit loads & stores, whether an assignment is guaranteed to be a single load/store or possibly be split up (affects both semantics in the case of mmio and also atomicity), are all subtle questions, the answers to which are not at all suggested by the form of the code; The language is very much designed with the assumptions that (1) memory is just storage, so it's not important to be super precise on how reads and writes actually get done (in fairness, the lack of optimization in the original compilers probably made this more straightforward), and (2) concurrent access isn't really that important (the standard was completely silent on the issue of concurrency until C11). If you care about these issues there's a lot of rules lawyering you have to do to be sure your code isn't going to break if the compiler is cleverer than you are. A modern take on C should be much more explicit about semantically meaningful memory access.

I think you can make a sensible argument that wrt hierarchies C is at least not a heck of a lot worse than the instruction set, so maybe I'm conceding that point -- though the instruction set hides a lot that's going on implicitly too. Some of this though I think is the ISA "coddling" C and C programs; in a legacy-free world it might make more sense to have an ISA let the programmer deal with issues around cache coherence. I could imagine some smartly designed system software using the cache in ways that can't be done right now (example: a copying garbage collector with thread-local nurseries that are (1) small enough to fit in cache (2) never evicted and (3) never synced to main memory, because they're thread-local anyway). Experimental ISA design is well outside my area of competency though, so it's possible I'm talking out of my ass. But the general sentiment that modern ISAs hide a lot from the systems programmer and that other directions might make sense is something that I've heard more knowledgeable people suggest as well.

> Every single design decision about C was made with the computer in mind.

The only problem is that computers have changed a bit in the last 50 years, and C largely hasn't. There are a couple issues:

First, C was designed for single-pass compilers, because the PDP-7 it was designed for was too small to actually run much fancier of a compiler. So C is seriously sub-optimal for optimization in a lot of ways (because the assumption was you weren't going to do compiler optimizations anyway), and there are some user-visible warts like forward declarations that are completely unnecessary today.

Second, the relevant questions with regard to CPU performance have changed a lot. Most notably:

- CPU performance has completely outstripped memory perf, so memory hierarchies and locality are everything

- Parallelism everywhere. Multiple cores, but also deeper instruction pipelines and other such things.

The way those things map to C is completely implicit; they don't show up in the language at all, and getting the machine to do what you want requires knowing things that the code wouldn't suggest at all.

I think if the same people had designed a language for a similar niche today's hardware, a lot of things would be different.

It still exists, and there are no plans to get rid of it. Same with other community infrastructure, e.g. demo.sandstorm.io has been moved off of oasis and still runs as well. It's only oasis that's shut down.