etwigg

If you wanted to buy some thinking, you used to have to pay a human! Humans are social creatures, we delegate some of our thinking to our social fabric, and some of that fabric are already avatars on screens. This is definitely new!

If the text is good, and someday it will be, I don't care if an LLM wrote it. If it's bad, I don't care if a person wrote it.

The only reason to care is that the implicit proof-of-work signal has broken because LLM text is so cheap. Open forums might need to be pay-per-submission someday...

Hal Galper is a jazz musician famous for his teaching methods. My favorite take away was "You couldn't play it because you couldn't hear it... How many of you feel that you have trouble playing what you hear? You are all wrong - you are playing exactly the way you hear." I feel like he should have a bigger audience outside of just music education.

https://www.halgalper.com/articles/radical-vs-incremental-gr...

Whenever I am trying to figure what is true and/or good for me, there are some people who want to help me and others who want to help themselves (sell me cigarettes, negative sum politics, etc). This is the battle where AGI seems spooky - eventually people are not able to tell which way is up.

We should consider the OODA loop of a person's self-determination separately from the menial tasks a person undertakes to make a living. Automating a task is totally different than breaking a person's ability to self-orient.

I've always been a fan of Rich Hickey's talks. After I wrote this blog post I cold-emailed Rich and said roughly: "Thanks for sharing your talks, I wrote this about your last talk, hope you have a good week." and he replied back same day with a nice note. 10/10 would recommend cold emailing your heroes.

Adopting automatic semver took some of the "publish fright" away from my libraries. One less thing to think about if the version is automatic.

Every oral historian podcast that I listen to (Marc Maron WTF, Joe Pug Working Songwriter, I'm sure others) has lost incredibly valuable recordings on account of not pressing the button. I think the physical affordance of the spinning wheel is invaluable, along with the simple VU meter. The extravagance of the wheel is closer to the importance of a gun safety in that context.

Worst possible option. Unmute Trump, or mute all election conspiracists including Fox. Force the vandals to organize on Parler amongst the people they scammed, and don't let people get sucked in on accident while they were just trying to look at baby pictures.

This half-measure is the most dangerous of all paths. Depending on your interpretation of the 1st Amendment, you have to do either A or B. This is short-term survival at great long-term cost.

- we stuffed all the presidential debates into git

- https://github.com/mytakedotorg/us-presidential-debates

- serve them to users from git

- https://github.com/mytakedotorg/mtdo/blob/53f3be668719a03a25...

- stuff them into lucene for search indexing

- https://github.com/mytakedotorg/mtdo/blob/staging/lucene/src...

- and into d3 for visualization

- https://github.com/mytakedotorg/mtdo/blob/53f3be668719a03a25...

This is a great UI, but the quality of the results will depend on the selection bias of the inputs. For example, if you used rally speeches for one side, vs prepared speeches for the other side, that would skew things quite a bit. Can you elaborate on the corpus which is backing this?

I've been working on something similar, but it's got less to say because we've constrained ourselves to just the presidential debates, since they're "fair". https://mytake.org/search?q=supreme%20court

I'm a big fan of "provably neutral" project to try to bring reality into politics, so I hope your project is successful!

Here is a repo of every presidential debate in history, in an easy-to-parse format. I'm adding the VP debates in tomorrow: https://github.com/mytakedotorg/us-presidential-debates

We're a group of volunteers trying to build "Wikipedia for primary sources". We've taken every presidential debate in U.S. history, stuffed them into a git repository, and made it searchable. We've also built tooling so that other "factsets" besides the debates could be added in the future.

You can highlight any snippet of a fact, and post it to social media. We render the text of the snippet as the social preview, and if people click it, they can see the full context it came from.

I'm gonna be transcribing the 2020 debates live at https://www.twitch.tv/mytakedotorg

If you're interested, we really need a designer!

I've been working on this with a couple friends for the past few years. We took every videotaped presidential debate in history, synced the transcripts with the video, and made it all searchable. If you highlight a snippet of a debate and post it to social media, we generate a fancy image of the text as the thumbnail. Once somebody clicks your post, they can see the full context it was taken from.

Our original idea was (and is) to something like medium or substack, except the authors can only link to finite set of facts. It's more interesting read someone you disagree with if you at least agree on some of the facts. We ran out of time, so today we're releasing just the parts that work.

An interesting piece is that we serve all of our facts straight out of GitHub (proxied behind an HTTP cache, of course). So you can git blame typos and corrections, etc.

We're really eager to find more committers, so take a look and drop me a line if you'd like to get involved!

https://github.com/mytakedotorg/mtdo/blob/95af2d1b8c24eaeec1...

https://github.com/mytakedotorg/us-presidential-debates

"The only risk you take is that you might select a bad company." - that's the same risk an investor takes no? Except the investor can diversify across many companies, while the employee can rely on only one. Yours seems like an argument for investors to pay a higher rate than an employee, because they can diversify their risk.

Personally, I don't think taxes should be based on risk assessment.

Dogs are fantastic for addressing childhood anxiety, and although they are expensive, they are much cheaper than a therapist. [1]

[1] https://www.researchgate.net/publication/284277087_Pet_Dogs_...

I sell a niche desktop application to engineering companies. They self-police themselves pretty well - we're really not concerned with them cracking our software at all.

We built our own stupid-simple licensing system. True, it wasn't that hard, but it would totally be worth $100/mo to have this maintained by somebody else, so we could focus only on our product.

Their competition (FlexLM, etc) is horrific. This looks much better.

That's a great goal to have! But if you're putting energy into a flow using a propeller or fan, aerodynamic stall means that each propeller can only put a limited amount of energy in. This is why jet engines have so many compressor stages - each one adds as much energy as it can without stalling out:

https://en.wikipedia.org/wiki/Gas_turbine#/media/File:J85_ge...

In the engine pictured, which has 8 compressors in a row, the energy which those fans are able to put into the flow is miniscule compared to the energy that you can dump in by burning fuel (or electricity) in the tiny combustion chamber.

F-16 in afterburner is consuming 64,000 pounds of fuel per hour = 18 pounds per second A pound of Jet-A has 20 MJ per pound.

So that's 360 MW of thermal power. Even if you're only turning 10% of that into usable thrust, that's 36MW of power.

Here's what a 35MW power plant looks like: http://www.power-technology.com/projects/ctds_chp/ctds_chp5....

The people working on electric jets are well aware of the Carnot limit, and it's true that they don't want that. But for now, we'd need a lot of new tech to put 35MW of thrust power into a flow using electric motors and fans. Heck, we need a lot of new tech to put 350MW of power electronics onto an airplane!! My only point is that I don't think we should look down our noses at the people working on thermodynamic machinery. Until we can do better, they're the best we've got :)

> You have to distinguish the conventional (high efficiency) cycle of a jet engine at low Mach, from the reheat (low efficiency) operation usually used for high Mach.

Exactly. At high mach, almost all of the energy being put into the flow is from expanding combustion gases - not the compressor stage. If you wanted to go at supersonic speeds using only spinning fans, you will need a heck of a lot of fans. Maybe we could do it! But we haven't so far.

If you take a course in energy conversion, and also an economics course, then you would consider this.

https://en.wikipedia.org/wiki/Nuclear-powered_aircraft

Some joules are more expensive than others :)

Which was seriously considered during the cold war: https://en.wikipedia.org/wiki/Nuclear-powered_aircraft

As bad of an idea as using javascript to do addition rather than assembly. You're assuming electric energy is the same order of magnitude cost as electric energy. It's possible that could change some day.

Aircraft weight turns directly into fuel cost via induced-drag. If electric energy is wildly inexpensive, you can afford very heavy airframes.

See https://en.wikipedia.org/wiki/Nuclear-powered_aircraft

When a jet engine burns fuel, some energy goes into turning the fan, and some energy goes into creating thrust.

At low-mach, the fuel burn is primarily producing torque which turns the fan. This fan could be turned by electricity.

At high-mach, the fuel burn is primarily producing pure thrust, and the fan portion hurts the engine's performance.

Supersonic turbofans are a compromise that have to produce thrust from takeoff through to high speed. I may be incorrect, but I don't believe we have ever built a ducted fan which can use pure torque to generate supersonic thrust, although I guess I don't see why it wouldn't be theoretically possible. We can put megawatts of energy into a fast-moving flow using thermal energy and a brayton cycle. In order to put megawatts of energy into fast-moving flow using rotors would require a totally new design - nothing like the supersonic turbofans currently in production.

You are correct that it's wasteful, if one joule of electric energy and one joule of chemical energy cost the same.

But if you are getting electric energy for free from solar panels, and you're getting chemical energy by pumping taxed dinosaur carbon into the air, then you might find that the electric energy could be more efficient.

You're absolutely correct that it's wildly inefficient by any metric now. But if clean electric energy became wildly abundant, that would change.

In computing, there are all kinds of wildly wasteful things (web browsers) that are the best way to do things because computation is extremely cheap. It's very interesting to think about what kinds of devices would make economic sense if electric energy had the same price collapse that computation has done.

The fact that we "burn electricity" in electric water heaters, stoves, and toasters rather than only using high-entropy energy sources like gas water heaters and gas stoves is an example where present-day electric energy supply chains have beaten out the theoretical advantages of only using high-entropy energy sources when it is possible to do so.

> Once you are no longer combusting fuel, all of that compression is simply wasted energy.

Not true. Instead of burning fuel, you can use electricity (something like an arc welder) to generate heat. And the efficiency with which that heat is turned into mechanical power will be dependent on the compression ratio, regardless of whether the thermal energy is coming from electricity or burning fuel.

Thermal energy in chemical fuel and the potential energy in a battery or a raised weight have the same units, but there's actually a difference. You can turn energy in a battery or a raised weight into mechanical energy with 100% efficiency - not achieved in practice, but there's no theoretical limit.

When you turn thermal energy into mechanical energy (via Otto cycle in a car or Brayton cycle in a jet), the peak efficiency you can achieve has a theoretical limit based on how much you can compress the working fluid (air) before injecting thermal energy (burning fuel or an electric arc).

So if you've got electic energy that you can turn into mechanical energy in a fan with 100% efficiency, why would you take the thermodynamic losses of "burning" that electricity? Because we don't know how to go supersonic speeds with a fan or propeller - the only way we know how, for now, is with a jet running on the brayton cycle. And all the advances we've made in high compression fuel-burning jets would apply to electric jets just as well.

If you're okay limiting your top speed to ~Mach 0.7, then you're correct spinning a large propeller using electricity is absolutely a better way to go, and you can make that propeller a lot bigger if you're able to tilt it.

Karem Aircraft has done extremely interesting work on figuring out how to tilt rotors, and much of their research would apply to electric motors as well: http://karemaircraft.com/

SWT (the eclipse widget toolkit) takes this approach. It's very difficult to maintain API compatibility with the myriad browser versions out there, not to mention having the content in those browser windows display reliably.

The real killer-feature of Electron et. al. is only having one browser version to test against. I think embedding CEF is definitely the right call.

This is especially true with Java 8's lambda syntax and method references. Because a Java function's signature includes its checked exceptions, implementing a functional interface can require lots of verbose nested try-catches.

e.g. rather than being able to write:

  foodOnPlate.forEach(this::eat);

You end up having to write:

  foodOnPlate.forEach(food -> {
      try {
          eat(food)
      } catch (Barf e) {
          // handle?  rethrow as unchecked?
      }
  });

This library does a pretty god job handling that case:

https://github.com/diffplug/durian/blob/master/test/com/diff...

Pure-native was a full C++ port. The Java part of SWT uses manual memory management, and is written very simply. I think you could autoconvert it to C++ and present the API that way.

Nice work, but I wish SWT had picked up more steam outside the Java community. It's the same idea, but with a decade+ of banging on the corner cases for the use cases of the Eclipse IDE.

In addition to all the standard controls, it's also got OpenGL and browser embedding since before Electron was cool.

Using it on the JVM is very easy, but there was a short-lived attempt to maintain a C++ API.

- How it looks: https://www.eclipse.org/swt/

- From Jython: https://github.com/danathughes/jythonSWT

- From JRuby: https://github.com/neelance/swt4ruby

- From C++ (defunct): http://www.pure-native.com/

It's built out of small chunks of C code: https://github.com/eclipse/eclipse.platform.swt/search?p=1&q... that are wrapped in a Java API with a straightforward coding style that seems amenable to automatic source translation. And it doesn't need GC - it actually requires the Java programmer to manually dispose resources, which is easy because it always requires objects to have a parent, so everything goes away when the pane / window / whatever gets disposed.