seagreen

This gets repeated a lot but unfortunately isn't true.

See the spec: https://tools.ietf.org/html/rfc3339

    NOTE: ISO 8601 defines date and time separated by "T".
    Applications using this syntax may choose, for the sake of
    readability, to specify a full-date and full-time separated by
    (say) a space character.

Someday someone reading this is going to set out to make a new, small specification out of a huge specification. Reader, when you start to feel the temptation to make just the tiniest improvement-- resist! It's way more useful if it's actually a true subset.

Happily this particular issue is be easily fixed. Let's make a new spec, subsetting both ISO 8601 and RFC 3339.

I hereby introduce... RFC 3339T, which is exactly like RFC 3339, but you have to use a T instead of a space.

EDIT: joshuaissac spotted another difference.

Also I made a repo so we're official: https://github.com/seagreen/rfc-3339T

> Attoparsec and megaparsec don't backtrack.

There are two notion of backtracking at play here. One is backtracking out of a failing first branch of <|> even though it's consumed some input. The megaparsec authors consider this a form of backtracking (see https://hackage.haskell.org/package/megaparsec-9.0.1/docs/Te...).

The other is backtracking from a failure in the second argument to <> or <*>.

I agree that none of the libraries being considered do the latter. But the effect on memory use wouldn't just be slightly inefficient, it would mean keeping the entire input following a <|> in memory until the whole thing completes. Do you think this is the best way to do things in general, or just for specialized situations like parsing things with a fixed size such as config files?

> ... So long as you ignore that there are still things left unspecified by the interface, especially related to backtracking behavior. (I really hate how much mindspace Parsec-like libraries have in Haskell. They have the worst backtracking behavior.)

The one that auto-backtracks on Alternative is attoparsec (IIRC), parsec and megaparsec don't unless you use `try`. Is your problem with the attoparsec style or with all of them, and if the latter what do you prefer instead?

> languages like Haskell exist and isn't that on the whole programming using category theory?

It's not. However claims like that get thrown around a fair amount so the confusion is understandable.

That said, some important Haskell abstractions were designed using category theory. So it can be helpful to know some of the lingo (since it will show up in abstraction names and descriptions).

And if you're looking to design the next breakthrough Haskell abstraction it might be extremely helpful, but that's not 99% of programmers. However, the people who can do that are super cool, eg https://www.staff.ncl.ac.uk/andrey.mokhov/selective-functors....

> The 'problem' with Haskell is that, because of its roots in academic research the language will not chase success at any price (read hacks); and tends to eventually find solutions to its problems even if it means not being popular for a long time.

That's the PR line, but only describes about 5% of the problem with haskell.

But haskell's not relatively unpopular because it was late to add things like linear types. It's relatively unpopular because it doesn't care much about user experience.

Consider: it's getting linear types before an efficient string type in `base`. The first goal of this language is not good engineering practices and getting things right. The first goal of this language is "cool type stuff", with good engineering maybe goal 10 or something (is O(n^2) `nub` ever going to be deprecated I wonder?). And that's fine, we need a language for cool type stuff, let's just be honest about it.

Context: I've been Haskelling for 5 years, I've written a fair amount of FOSS in it, and it's my favorite language. I just want to help spread an honest impression of it.

> however it would be interesting to have some examples of haskell developments that are fueled specifically by cryptocurrency applications

An article saying "this sector of our community is bad and scamming retail investors" is already burning MAD BRIDGES and putting an enormous target on your back.

"Bob Smith and Joe Brown, specifically, are scamming retail investors" is going even a little beyond that. It's just not necessary.

EDIT: For the writer of the article, that is. We in the peanut gallery obviously want all the details, which is why a little detective work is often required in these cases.

YAML's way, way more complicated that JSON. To pick one rough measure, the spec is about 7x as long. It includes a bunch of things that could be seen as negatives, such as nine(!) different ways to write multi-line strings (https://stackoverflow.com/questions/3790454/how-do-i-break-a...).

I don't have a single competitor to recommend, but JSON5, TOML, JSONC (mentioned in a sister comment), or something else along those lines might be better. I'd probably just go with whichever of those is popular in your community.

Comments are a great idea... for a configuration format!

They're really bad for a data interchange format though, because people inevitably start putting important data in them and you end up with two different ways to write strings, one of which isn't supported by every parsing library.

Thus each discussion of JSON ends up being two groups talking past each other, the people using it as a configuration format who lament the lack of comments, and the people using it as a data interchange format who celebrate it.

The solution: since it's too late to add comments now, don't use JSON as a configuration format.

Just curious-- have you actually read the specifications for both? The difference in length and complexity is like this comment vs. War and Peace.

Which specification got an update last year? Google's not turning anything up.

> However, parts of me miss the Apple of the 1980s and 1990s, where the engineers and researchers there explored ideas of how to make personal computing better. I feel that the personal computing experience for desktops have been stuck in a rut for nearly 20 years, with some aspects actually degrading rather than improving.

I totally agree with this, and think it's an incredibly important issue.

If you post anything public about your Lisp-based DE please feel free to let me know (email in profile).

Thanks for the serious response to a somewhat snarky comment.

I see software development as only one among the many things a computing system should enable. It's definitely an important one. But computers should enable creativity and power for all kinds of tasks, not just programming.

It's sad to me that people in all these different fields besides ours get stuck with webapps. I understand why they use them, they're very convenient. But it would have been great if we could have provided them an even better OS/desktop environment so that they never would have had to switch to such an unempowering tool.

Additionally, programmers being one of the last holdouts of actually engaging with Unix-as-a-way-of-doing-things is a precarious place to be. Microsoft/GitHub is on full "embrace" mode again, and it looks like they're going to make another run at slurping everyone into their ecosystem. Same with tools like Repl.it. It seems to me that the proportion of people who are engaged with the Unix way of doing things (piping text around, etc.) is shrinking, not growing.

EDIT: To get myself back on topic, for these reasons I see people experimenting with new (and crucially local) environments as really exciting. Traditional Unix environments don't need to be the last word, we can do better.

> The fact that after half a century, Unix-like operating systems and programming environments are de rigueur is plain enough evidence of this.

Unfortunately Unix blew a 28-3 lead against Netscape Navigator and now 99% of people spend their time in web browsers instead.

I think this speaks to the weakness of the experience using Unix, not its strength.

This whole thread is going in my "Humility" file, not only did I misinterpret the error this one time, I've been messing around at the Erlang REPL putting a space after each command for absolutely no reason <headdesk>.

Oh, that makes sense! Thanks to both you and moreoutput.

My argument is wrong then-- this isn't shockingly bad anything, just a little quirkiness.

I've had trouble getting into it because the ergonomics are so incredibly, wonderfully, art-project level rough.

For example:

    $ erl
    Erlang/OTP 20 [erts-9.2] [source] [64-bit] [smp:8:8] 
    [ds:8:8:10] [async-threads:10] [kernel-poll:false]
    
    Eshell V9.2  (abort with ^G)
    1> 2 + 2
    1> 2 + 2.
    * 2: syntax error before: 2
    1> 2 + 2.
    4

Note the trailing whitespace(!) after the last `2 + 2. `, necessary for the result to be printed.

I was coming from Haskell which has its own very serious tooling and ergonomics problems. Trying Erlang made me realize things could be even worse. My internal model in my head of language designers/promoters is COMPLETELY wrong, I have absolutely no idea how people could spend time promoting languages with such strange tooling to a general audience with any expectation that it will work.[1]

[1] Not to say that these languages/tools aren't awesome. Trailing whitespace matters semantically absolutely not at all. But if you're trying to promote a language with meaningful trailing REPL whitespace to a general 2020 audience there is some terrible mismatch between your expectations and your actual chance of success.

> in my company (a Fortune 500 ecommerce brand)

My strategic advice is to get whatever's best in class, and not worry about $X0/month. Compared to what you should be spending on devs that rounds to free.

Huh, it seems obvious but I hadn't thought of this.

I think that's because I was coming at this from the perspective of trying to prevent getting hacked, but really I'm less worried about that than I am about losing access.

This kind of thing makes picking a personal email address a tricky decision.

Do I go with a @gmail.com or other corporate address? Then I risk losing my email if my account is suspended.

Do I go with a domain I own? Then I risk losing it if something like this happens.

Either way is serious because email is effectively a master key into all my accounts.

I'm honestly not sure what's best.

Name me a single company that uses Haskell 2010. It's completely irrelevant.

But I'll leave you to argue with Vitaly Bragilevsky (speaking at Galois):

"Haskell is a big language" -- https://galois.com/blog/2018/11/teaching-haskell-in-the-real...

Or Paul Hudak, Philip Wadler, and Simon Peyton Jones:

"Haskell is a big language" -- https://www.microsoft.com/en-us/research/wp-content/uploads/... (p.28)

Maybe those guys know something.

It's cool Haskell goes through a small IR. That doesn't make TH, rewrite rules, CPP, the million extensions, STG, the runtime, the gigantic syntax, or the quarter million SLOC implementation simple.

> I think it's equally a disservice to tell people it's too complex to learn. There's a common impression people get that they have to master category theory before they can begin to understand Haskell code. That's also troubling and kind of what I was getting at with this whole thing in a round-about-way.

Ah, I see where you're coming from more now. Yes, the "category theory is recommended alongside learning haskell" meme is terrible. In that context saying Haskell is simple is an improvement. I think people can handle nuance though, and "haskell has a simple core, but in practice GHC haskell is a big language" is something they can handle.

Your argument is that a language with a 750,000 line implementation and a zillion features is simple because one of its IRs is simple? Doesn't seem very convincing.

We're on the exact same page :)

I even think there's a place for fancy Haskell, but I think people reach for it a little too often.

> It's a qualitative statement and disingenuous. Complex relative to what?

Complex relative to most programming languages.

C++ is more complex. That says very little. C++ is an extreme outlier.

I think Haskellers do a disservice to people they're trying to convince to do haskell by saying it's not complex. Haskell has a zillion extensions and crazy features, most of which show up in at least some popular Hackage libraries. Arrow syntax! Type families! Data kinds! Pattern synonyms! View patterns! Existential types! Rank-N types! The list goes on and on.

PS: I think Haskell is awesome and one of the best languages out there. I've written a pretty decent amount of FOSS haskell stuff. Complex doesn't mean bad.

EDIT: The complexity doesn't come just through language extensions. The process GHC goes through to produce fast code is crazy too. It works, but it's not simple.

OP: haskell is extremely complex.

Responder: not it's not (eg C++ is more complex)

Me: actually haskell is a complex, beastly language, eg check out the language extensions

You: but C++ is more complex!

Me: i agree

EDIT: Didn't mean to sound snarky, the discussion has just gotten really layered and I wanted to explain my position.

It depends on what we mean by Haskell.

If we mean "Haskell the latest specification" that's Haskell 2010. I suppose we could think of it as pretty simple, though lazy evaluation means that any implementation of it is going to be complicated.

However I don't know of a single company that uses plain Haskell 2010. They all use GHC (or more complex tools like GHCJS!) and GHC Haskell is a beast: https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

The economics of the situation aren't friendly to humans, because human intelligence doesn't scale up well. Take energy consumption-- once you're providing someone 3 square meals they can't really use any extra energy efficiently. So we try training up lots of smart people and having them work together, but that causes lots of other problems-- communication issues, office politics, etc.

Additionally you can't replicate people exactly, so even when Einstein comes along we only have him for a short while. When he passes away we regress.

Computers are completely different. We can ring them in power plants, replicate them perfectly, add new banks of CPUs, of GPUs, wire internet connections directly into them, etc.

This didn't used to matter because the old "computers can only do exactly what you tell them to do, just really fast" limitation. Now that computers are drawing, making art, modifying videos, playing Chess and Go preternaturally, playing real time strategy games well, etc we can see that that limitation doesn't really hold anymore.

At this point the economics start to really kick in. More machine learning breakthroughs + much, MUCH bigger computers over the next decades are going to be interesting.

Mentioning H*skell in a Python job ad isn't a great look. You're better than that!

How has haskell been going so far?

I'm also curious why you chose Typescript over the more FP frontend options (not that I think it's a bad choice at all).

Why is this downvoted? It's a rust job in an important field.

(Disclaimer: I don't work there, but I've met a couple people who do.)