Here's a better list:

- Being under the public eye—all the time—is one of the top reasons to not be famous. Famous people must constantly self-monitor what they say and do because casual mistakes can trigger disproportionate backlash or headlines.

- You lose the ability to have genuine, equal interactions—people treat you differently, with deference or expectation, rather than as a peer.

- Privacy disappears as curious strangers can easily discover where you live, details about your family, and how much wealth you have—information you'd normally share only with people you trust.

- Strangers form opinions about you before ever meeting you, based on whatever fragments of your public persona they've encountered.

- A public persona can become a cage, limiting your freedom to change, experiment, or reinvent yourself.

I could have asked ChatGPT myself.

There is a method to this madness.

Elon Musk's strategy is to control the government operations through controlling its IT department.

The smart people of 18f stands in the way. By removing it and hiring his loyalists to run the government IT he gets to control the government's operations.

In go you mix state with logic (example below), which apparently is a "major catastrophe" according to some on this thread.

   type Engine struct {
       HorsePower int
   }

   func (e Engine) Start() {
       fmt.Println("Engine is starting with", e.HorsePower, "horsepower.")
   }

This does a better job: https://visualdb.com/

I build a better one https://teable.io/ and plan to open source it next week

teable looks very interesting, I hope you do follow through on open sourcing it.

There's also https://www.airsequel.com/

And

https://airforms.com/

https://airforms.com/ and https://visualdb.com/ appear to be the same thing?

Airforms is self-hosted

Also, Visual DB has Airtable-like features

I'll share my own project: https://www.myowndb.com/, running since 2006. I neglected the project for a couple of years but recently launched the new version. It's open source: https://gitlab.com/myowndb/myowndb

I enjoy the technical side, but I'm struggling to commercialise it so don't hesitate to give me your feedback here or on https://www.myowndb.com/contact.html which is of course powered by a myowndb public form :-)

heh, I'll throw my formial (https://github.com/nathanstitt/formial) project onto this thread. I probably need to update it a bit but it's been working well in production for 2+ years now.

Where were all these alternatives when I was looking for a WYSIWYG form builder?

Wasn't he president of some kind of startup incubator? Some "combinator" company.

Well, obviously quite against the goal of non-profit, safe the humanity company. President of some “combinator” is the money maker.

Can't tell if this is a joke lol

It seems you only support Postgres. Do you have plans to support other databases as well, such as MySQL?

Good question. We've taken a somewhat unique approach of integrating tightly with PostgreSQL in order to leverage its strengths. In the short term, we plan to continue with this focus on PostgreSQL, but we are considering supporting other DBs in the long term. Thanks for your comment though! Knowing that you have an interest in using Mathesar with MySQL is a useful data point for us!

It's a very common pattern, almost every modern language has a "map" function. The map function can throw a superset of the exceptions that its argument can throw. If checked exceptions can't deal with this, they'll be of limited use.

> The map function can throw a superset of the exceptions that its argument can throw.

Wait. Why should a map care about what exceptions it's arguments can throw?

A map is storing a thingit. A thingit should exist independently before it gets placed into a map. Placing a thingit into a map should not invoke anything on the thingit. The only exceptions coming back from attempting to place a thingit into a map should be exceptions caused by the map.

What am I missing?

Obviously, there are maps that conflate themselves and do things like take ownership when an object is placed into the map. But that's not the general case and presumably you wrote the map specifically with that in mind.

You're thinking of a finite map, also called a hash table or a dictionary.

The map function takes a function and a list and applies the function to every element of the list:

  map(double,[1,2,3]) = [2,4,6]

Grandparent could've used the for loop rather than the map function to make his point:

  for i in [1,2,3]:
      print i * 2

-- because in general instead of the i * 2 we might have a call to a function that might raise an exception.

ADDED. That is wrong: the for loop would not a good example at all because it is not customary to declare the type of a for loop or to need to declare which exceptions a `for` loop might throw.

Whoops. Yeah, I wasn't thinking about map, fold, accumulate, etc. Thanks for the correction.

In the case of map function hopefully you're using it with methods that don't fail in serious ways, and don't need strong error recovery. If so Java has RuntimeException to handle that case. If serious errors are possible and strong error recovery is needed, then you need to avoid the conveniences offered by functional style programming.

The problem is that if some code you call throws a checked exception (InterruptedException being an extremely common culprit) then you must wrap... and suddently nobody calling YOUR code can catch that InterruptedException reliably because it's now a SomeException (doesn't even have to be RuntimeException specifically) with an added "suppressed" exception that you now have to check for.

... so the basic "catch" syntax starts to fall apart because now you have to catch everything and resort to stuff like Guava's Throwables helpers.

It's madness.

The problem ultimately is variance: Methods are covariant, but throws clauses must be contravariant.

There are ways to solve this but "checked exceptions" (as in Java) are not the right way. Ask anyone who's worked in Scala on the JVM which they prefer and you'll have your answer.

It's possible to use a type parameter in a throws clause in Java, last I checked (as I also mentioned in more detail above). But it doesn't seem to be common practice, so interop is still a disaster.

That only works up to one checked exception type, because Java doesn't have anonymous union types.

It really is a lose-lose unless Java grows a more powerful system around this.

Sorry. This is nonsense. map() is the bread and butter of any program. Besides, you cannot ever decide whether an exception is important or not -- it's always in the purview of the user.

Re-throwing a non-checked exception is what I described as the usual / typical coping mechanism in languages with checked exceptions. Which is obviously a way to negate the whole feature.

Sorry, disagree. map() didn't even exist in Java until recently. It is convenience at the cost of some safety. If you're writing a non-critical or throw away code you may not care about strong guarantees. Personally I prefer strong guarantees over convenience. I would only use map() for things that can't throw checked exceptions. A for loop isn't that hard to write.

Do you mean Turbo Pascal? He didn't design it, Niklaus Wirth did. Or do you mean C#? James Gosling designed most of that (C# got its start by copying 90% of Java). Do you mean TypeScript? That's mostly JavaScript.

You're certainly entitled to your opinions.

Those are facts

Or Airforms if you don't like coding: https://airforms.com/

What about it doesn't scale? Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. If MVC doesn't scale the folks who maintain those frameworks would have noticed by now.