HN user

qppo

2,567 karma
Posts1
Comments780
View on HN

I think you have a false dichotomy.

Slack and email are for talking to people who I'm not on the phone/video conference with or are away from their desk when I'm working. That is an orthogonal problem from the "Maker" tools you listed.

Jira is for specifying future tasks and goals, it's also an orthogonal problem to the tools you listed.

Fat chance of this changing anything. Berkeley is liberalism run amok. Unless you already own property in one of the shrinking "nice" parts it's not that nice of a place to live, and loosely committing to allowing multifamily zoning is not going to change that.

I'll bet money that even if the commitment turns into law in 2022, it will still cost north of $1,000,000 to actually construct or convert a multifamily property due to ridiculous permitting costs that you can't see up front.

To me, there's an irony that the nationalist desire to sever Britain from the EU is the best way to hasten the dissolution of Great Britain. Now that Brexit is done with, reunification of Ireland and Scottish Independence are in the conversation.

I'm also not British so I don't know how serious those conversations are. But the assured economic and political disaster of Brexit wasn't enough to stop that ridiculous idea, so who's to say the same won't happen to the marginally less ridiculous proposition to reunify Ireland and establish an independent Scotland for the first time in centuries?

I'd question why you're running code in a meeting. That's some morning standup stuff for your team which can be done at your desk or placed in a gif in an email, not hauled off to a separate room.

Meetings are for collaboration, not demos...

I don't know how this should be structured but there has to be some principle of "use it or lose it" for IP protections, and some limitations on transference of IP.

Obviously there are a lot of negatives to implementing some kind of legal framework around those ideas but something has got to give here, the existence of patent trolls and defensive patent strategies is offensive to the notion that we should encourage innovation.

I think the answer is to look at things that can't be done by executing code from a library. In other words, think about something you can compile that isn't executable code.

Some examples: hardware description languages (VHDL, Chisel), human readable graphics languages (shaders, SVG), languages for describing music or instruments (super collider, SOUL, Max/MSP, Pure Data), other creative coding, generative art, etc. Essentially think about all the things that programs arent, and think of how a DSL can represent them - be it abstract information like art, physical things, or other things not readily represent able as digital data.

But to the first part of your question: it's not hard to make a DSL. It's hard to make one that people will use. The hardest problem in developing one is dogfooding it, you need users from Day 1 to give feedback on what works and what doesn't make sense. Another way to think of it is that the technical problems of DSL development are straightforward, the social problem of making one that's useful isn't.

I don't think it's even technically true, they're fundamentally different circuit elements that just share a principle of operation. Diodes allow current to flow in one direction (rectification), triodes provide a proportional increase in the energy of a signal (amplification).

Their shared implementation details mean you can wire a triode as a diode but I don't think it's even a better diode.

The story I've heard is that the original lightbulbs filled with soot and darkened well before they burnt out. Edison guessed the soot was coming from the filament and was charged, so he placed a charged plate across from the filament to attract the soot before it could stick to the glass. It worked, but the bulb was much darker than before as the charged plate siphoned a lot of current off the filament.

That device would have three conductors, which you can see in the photos. Two for the filament, one for the "plate." Later, a fourth conductor called the "cathode" was added to be heated by the filament (rather than pulling charge directly from the filament) to make the first diodes.

There's something funny about how modern active components are designed to reduce how much heat they consume, but the first active devices required an active heating element to function at all.

Type inference is great and undeserving of the "bah humbug" type comments. Not a fan of it in function return types but that's easy to avoid in code review or linting (both of which you need plenty in C).

The closure proposal is much more interesting. I skimmed the discussion and it points out many of the benefits and some syntax proposals, but I'm wondering about memory management.

In C++ a lambda may not be convertible to a function pointer if the captured context is non zero sized, and if the captured context is larger than the size of a pointer it must use some kind of dynamic allocation. C++ has scoped destructors, making implementation of that relatively straightforward (free the context when the lambda goes out of scope), but what would C require? Defer statements? Require a free() without matching call to malloc?

Closures in C are still possible using void* as a user context, which is common both for closure semantics in libraries as well as implementing closures in languages transpired to or interpreted in C. The memory management is explicit, the types remain explicit (except for the closed over context), albeit a bit verbose.

As much as I love functions as types and programming with them I'm confused how this is a positive feature for C, which lacks some of the semantics that other languages have making closures sensible.

Why ship a desktop app when you can ship a browser product?

The business incentives often outweigh the technical benefits of desktop apps. DRM and payment processing are easy. Discoverability is a shit show but the only competitive advantage to app stores is exclusivity. No need to worry about provisioning user machines, DLL hell, whatever.

And whatever you do you're going to pay a couple of release engineers anyway.

Phonetic alphabets tie the representation of information to human vocalization, which is only slightly more useful than tying it to human sight like pictographs.

Without launching into a diatribe on all the shortcomings of phonetic alphabets for representing spoken language (for example speakers of the same language can't even agree on the same set of phonemes to use, and they shift over time) there are plenty of examples I can think of, like musical notation, signal flow graphs, type system notation, circuit diagrams, etc, which notate extraordinarily complex and compounded information into terse representations without terrible ambiguity and plenty of flexibility just like alphabets. Without the shortcomings of human language itself. I'd suggest those systems, many of which have been iterated and improved, more "advanced" than the humble alphabets.

That growth isn't exponential. Mortgage debt isn't a bad thing, the equity you build through it means you essentially come out ahead or even, once adjusting for inflation.

In other words, real estate is a great way to preserve wealth.

Consumers want one cable and connector for all devices regardless of the ridiculous notion that all devices should have similar enough electrical requirements that they could use one cable. The result is USB.

A question I like for non-tech businesses is: "do you see this as a software business or transitioning to become one?"

Because these days every business has to be investing into software products, and the ones that don't recognize that the software is key to all their products are the ones that are dead folks walking. They're also great targets for SaaS consultant vultures.

I'm getting quite tired of these false equivalencies.

Trump directed a mob yesterday to storm our Capitol and it sounds like you're being sarcastic about him threatening our democracy. What does he need to do? Burn it down and hang the Vice President for not exceeding his ceremonial powers like his mob chanted?

The claims of the election should be dismissed by rational people, which is exactly what happened in legislatures and courts across the country led by people of every political position except those that want to tear down our democracy for a demagogue and lie to their constituents about reality.

Point 3 sounds made up. Banks are in the business of lending, I can't really imagine a scenario where they have an incentive to lend less.

This page looks incomplete.

Tangent: I'm very interested in implementations details for ordered key-value stores. B trees and their variants like B+ trees are pretty straightforward conceptually but there seems to be scarce resources on the nitty gritty details past find/insert/delete.

For example I'm interested in redistribution algorithms, duplicate key semantics, and merging. The relative naivety of their implementation can have a large impact on performance/storage depending on how the store is used.