seagreen

Why do people keep reposting that first article? I encourage you to reread it with a critical eye.

A choice quote:

In contradistinction to this orthodoxy, I find the following five heresies to have more evidence to support them.

Intelligence is not a single dimension, so “smarter than humans” is a meaningless concept.

Humans do not have general purpose minds, and neither will AIs.

This is awfully similar to "On the Impossibility of Supersized Machines" (https://arxiv.org/pdf/1703.10987.pdf).

EDIT: Re: energy efficiency: the problem is that humans are too energy efficient. Your brain can keep functioning after 3 days of running across the Savanna without food, which is (a) awesome, and (b) not really helpful nowadays. The cost of this is that you can only usefully use a little energy each day, say 4 or 5 burgers at most. AGI prototypes will usefully slurp in power measured in number of reactors.

You can keep reposting the same job offer mentioning Haskell, and people will keep commenting not to do that if you don't actually have a Haskell job to offer.

Just FYI it's probably best not to mention highly desirable keywords like Haskell if you don't actually have that kind of work to offer.

This is definitely a problem, but the place to solve it isn't Son.

Son is intended to be a very simple project that grabs all the clear wins. Do we really need both `0` and `-0`, stuff like that.

There are too many different things JSON Numbers can represent for us to have a clear strategy for all them in Son. Int64s, doubles, floats, arbitrary precision numbers (eg https://hackage.haskell.org/package/scientific-0.3.5.2), etc. That makes this a good for for the schema layer (eg JSON Schema or whatever you're using), not the base specification layer.

You're looking for supersets of JSON, see the last section here: https://housejeffries.com/page/7. I'm partial to JSON5.

I opened an issue for this here: https://github.com/seagreen/Son/issues/10

I'm curious about how often enough trailing zeros occur in real world documents for lack of exponential notation to have a noticeable impact on document size.

I definitely meant ordering by Unicode code points. Someone very helpfully opened an issue and we're trying to figure out the right wording there: https://github.com/seagreen/Son/issues/13

For context, let's start with what JSON is. All the JSON spec really lets you do is say "this sequence of code points is JSON", or "this sequence isn't". It includes a few interoperability suggestions for how you might avoid JSON that will be hard to interpret, but it's extremely stark on parsing and generation.

For a pretty epic summary of this, see this Reddit comment: https://www.reddit.com/r/programming/comments/59htn7/parsing...

You have a comment downthread about how inadequate this is, which I totally agree with:

> The behaviour of the encoder and decoder are just as important to specify as the bytes across the wire. This is the whole problem with JSON in the first place.

Unfortunately since the goal of Son is to be a subset of JSON, there's not much we can do about encoding/decoding within Son's spec. Instead I hope to build a sane foundation on which other tools can be built. Limiting the scope of Son seems like a good way to go about this. In this case, that means not specifying ranges for numbers, so that future tools such as schemas have as much flexibility as possible (for instance to include arbitrary precision numbers).

EDIT: I'm mixing together two different things in my last paragraph. I don't want Son to know about Floats, Doubles, etc since JSON doesn't. That doesn't mean that we couldn't specify a range on number size though. The reason that is left out is to allow maximum flexibility for other tools to build on Son -- I'm trying to drop extraneous parts of JSON, but as few useful parts as possible. This needs more elaboration within the project's docs.

Limiting the size of numbers is intentionally left out of Son right now, because I'm not sure where that limit should be. My hope is that we eventually have a good schema language for JSON (something like JSON Schema, though I'm not sure about that one in particular) and then people can set number ranges in their schemas based on their particular use case.

There shouldn't be any remaining string escaping problems though! If you find one definitely open a GitHub issue.

Whoops, good point. In the long run I think Una's a good candidate for being installed at the systems level, because you really want to install unzip, etc. along with it.

EDIT: The idea being that if you install it with your system package manager it can have unzip etc. as dependencies so that's taken care of automatically.

una (https://github.com/jwiegley/una), a universal unarchiver which handles choosing between tar, unzip, etc. for you.

> that statement is true for any statically typed language.

It's a spectrum!

The awesome part about Haskell is that you can assume functions are deterministic and don't do IO unless they declare otherwise in the type signature. This is really a huge deal. I like statically typed imperative languages, but there's a big difference in expressiveness between a crude type signature like `String -> String` and something more fine grained like `URL -> IO ResponseBody`.

That said, Haskell has lots of downsides (many of which have been addressed in the last few years, some of which have not) so it's not a perfect language by any means. But it is very readable and refactorable.

Thanks for doing this!

I'm a PureScript fan myself, but I like what reason is doing. There are a _lot_ of JS projects out there that would benefit from being converted to a language with a real type system, and it's good there are people approaching this problem from all sides.

EDIT: If anyone reading this hasn't tried a language with an OCaml or Haskell-based type system, consider giving it a shot. If you're just familiar with static type systems from languages like Java I promise you this will be a totally different experience.

You're making some good points here. Neither category theory informed typeclasses nor laziness are required for pure functional programming (henceforth PFP). Up until recently Haskell was the only PFP language in common use, so all those things got conflated in a lot of people's minds. Now we have PureScript (which doesn't have laziness) and Elm (which doesn't have laziness or typeclasses).

That said, you really should listen to @willtim about the `IO` type. Purity really is a big deal, and `IO` doesn't break it at all.

The Myth of Superhuman AI has to be a joke. Please tell me it's a joke.

> Intelligence is not a single dimension, so “smarter than humans” is a meaningless concept.

So "I'm smarter than my dog" is a meaningless sentence? My dog will be happy to hear that . . . if he could understand it.

> Humans do not have general purpose minds, and neither will AIs.

This statement (even if true) seems totally irrelevant to his argument. So I was really looking forward to read the long form version in section #2 and see if it somehow makes sense.

It doesn't seem to.

His point is that minds involve tradeoffs, so specialized agents might be better than a big general AI. Whose side is he arguing on here? He isn't showing that a general intelligence couldn't exist that's better than humans in every way. He's just saying that even it would be inferior in specialized tasks to even more inhuman, specialized minds. Comforting this is not.

> Emulation of human thinking in other media will be constrained by cost.

This section is kind of a hack too, but since at least the title makes sense lets give him a freebie.

> Dimensions of intelligence are not infinite.

Oh golly. He starts off by asserting that the core of the AGI people's ideas relies on intelligence being on an unlimited scale. It includes this gem: "Temperature is not infinite — there is finite cold and finite heat." My estimate of this being a joke article is going back up.

Alright, I agree that intelligence, like temperature, is not infinite. I still don't want be be competing for a job opening with Von Neumann. Von Neumann doesn't want to be competing for a job with future-AGI-silicon-Von-Neumann, whose brain is 500 million GPUs in a datacenter stretching across Montana.

> Intelligences are only one factor in progress.

Right, just wildly the most important one.

My honest opinion is that I feel a little bad for the author. He clearly just doesn't want to believe the plausibility of this idea, and is just throwing every argument he can against it and hoping one of them sticks. I sympathize, but this kind of squid-ink writing probably doesn't serve as a great foundation for future debate.

> physicists who thought they had figured everything out in the '30s

Certain 30s physicists were making "My greatest fear is that my research is too successful" warnings that turned out to be pretty on-point.

Haskell's rough to learn because it hits you with purity, category theory inspired typeclasses, and laziness all at once. It's natural that people struggle with this (I sure did).

If you feel like trying a pure language again someday you could consider PureScript (which just has the first 2 things above) or Elm (which just has the 1st). If you do try I'd like to hear how it goes, email in profile.

Whoops, good point. Didn't mean to be so Linux-centric.

Amazing work. Thanks so much to everyone who's contributing. The upstream bugs filed are especially appreciated since they make the whole Linux ecosystem more solid, not just Debian.

Viper's inspired by Python, which (for all the nice things we can say about it) is a _terrible_ place to go for inspiration for this kind of task.

Absolutely true, and also a problem.

The fact of the matter is unskilled people are always going to be designing websites. This is OK!

However, it does mean that we should require them to do as little as possible so they have the best chance of getting it right. Asking them to design a second UI right from the start on top of the first HTML/JS one -- and then telling them never to change it(!) -- is a little much.

Instead of URLs, websites should have UUIDs to identify each resource. They should also have metadata describing what that resource is. The metadata (eg "articles/urls-are-uis") should be able to change without breaking links to the resource. Browsers should be intelligent enough so that when you hover over a link you see the metadata, not the UUID.

(This has one downside which if if you link to thing X and the UUID is later changed to point to thing Y, it may look like you linked to something you didn't mean to. This can be trivially fixed by including a "what the metadata was when I made the link" field in links along with the UUID)

EDIT: I'm actually not set on UUIDs specifically, they're a little long. Any random, non-meaningful identifier is fine.

Really I'm just saying that points 2 & 3 of the article are so good we should have made them the default (and perhaps only) option from the start.

I can, because I'm trying to explain a mindset, not make an argument. Maybe cryptocurrencies are the future, but there are reasons people are suspicious of them besides being silicon valley hegemons afraid of being disrupted.

> I feel like Silicon Valley hegemony has a grudge against crypto currencies

I have a grudge against crypt-currencies because their proponents think:

+ Implementations don't need specs

+ PL theory is below them (static typing? referential transparency?)

+ Repeated million dollar hacks aren't a problem

+ There's no shame in lying about the core purpose of your product (Etherium: The implementation is the LAW. Except when we don't feel like it.)

The sad thing is there are lots of cool things crypto currencies can do. They're great for moving money between countries (the banking system really needs to get its act together here). They're great for bug bounties. Someday they'll be good for contracts (bug-free code is possible if you take it seriously). Proponents should focus on those things ... but it's hard to take criticism seriously when you just want to pump up the value of your coins.

This should be higher up, I think TMSU is the best known product in this space, and a comparison between the two would be useful.

For one thing I think TMSU's achilles heel is handling renaming of files gracefully, I wonder how Tagsistant does it?

Plate isn't really in the same space as SQL.

SQL is such a shockingly good engineering choice that if you can use it I would. So even if Plate was done I would use Postgres instead of a Plate-based datastore inside my apps.

Plate serves a different purpose: schema'ing human-readable formats like iCalendar (https://en.wikipedia.org/wiki/ICalendar)[1] or JSON APIs. So even if you're using SQL within your app Plate may come in useful at the boundaries.

[1] Even if iCalendar was in JSON you couldn't write a Plate schema for it for the reasons listed here (https://github.com/seagreen/plate/blob/master/docs/prioritie...), but it serves as an example of a common human-readable data format.

Interesting. I see Plate as a much less ambitious project since Plate values can't be functions.

However, any comparison to one of Gabriel Gonzalez's projects can't fail to make my day:)

It's only like Haskell's type system compared to other schema languages (most of which don't even have product and sum types). Plate has parametric polymorphism, phantom types, and algebraic data types. It doesn't have typeclasses however (I don't see a way to implement them, thoughts here: https://github.com/seagreen/plate/issues/1#issuecomment-3028...) and so advanced Haskell features like type families are out.

Great questions (author here).

> The argument against JSON Schema presented in the readme is that is is too expressive. Can someone explain to me, as someone who's used JSON Schema before, why this should concern me?

If it doesn't affect you, then it doesn't affect you:)

The people who is does concern are tool authors. Trying to make an editor that handles schemas including things like "if field A is a string and matches regex X, then field B must match schema Foo instead of Bar" is really hard.

I believe the name for this in type theory land is dependent types.

> Compiling a subset of Haskell's type system to a JSON Schema just seems completely overengineered to me?

The subset of Haskell used is actually far, far simpler than JSON Schema. It's basically just parametric polymorphism and algebraic data types. They're my two favorite things from Haskell, and both are really simple.

There's been a simple counter to trusting trust attacks since 2009: https://www.dwheeler.com/trusting-trust/