> that Heroku hack

What is the "that Heroku hack?" mentioned in that article

I was also curious about this. As the article mentions, Slack doesn't make it easy for your organization to allow open registration. People have developed hacks around this by running a server on Heroku [0], or using Typeform combined with Slack's API [1].

0: https://github.com/rauchg/slackin

1: https://levels.io/slack-typeform-auto-invite-sign-ups/

> "You are scheduled to be deleted on our next cron job. Nothing complex."

Is this serious? What's a cron job have to do with knocking out information from a rdbms?

I imagine a cron job could be useful if there was a script to clear out any static files - but you can also invoke the script manually. "Nothing complex" :)

I’ll quote another comment from minimaxir:

> You're joking, but a quick Google search of [site:livecoding.tv banned] shows that's exactly what is happening.

> https://www.livecoding.tv/2pointoh/

> https://www.livecoding.tv/hekton/

Which shows their usual procedure for deleting or banning is... vandalism.

Perhaps it's a manual cronjob - developer wakes up every morning at 9:00am, SSHs onto the production system, starts up MySQL, runs all of today's DELETEs.

It's a devops world, nobody needs DBAs or Sysadmins anymore.

Maybe their sysadmin got replaced by a cron job.

What's the difference between this and flex/yacc?

From the readme, a workflow that doesn't make you want to kill yourself.

Also no generated code that requires extra build steps and instantly breaks platform compatibility. That said, inline grammar definition might not be for everyone.

Hmm. So for people who don't know how to use Unix/flex/yacc?

This is just reinventing an existing wheel.

I dunno that that's a fair criticism... by that same argument you could say yacc/bison is for people who don't know how to use C to write a parser. This looks like an attempt to do something along the lines of Parsec from Haskell, but in C.

Edit, because it looks like we hit the max reply depth: It's not like this is ever going to seriously replace Bison, I think it's just someone trying a different approach. It's not like flex/yacc/bison are the absolutely most perfect lexer/parser that can possibly exist. If people didn't try and reinvent the wheel every now and then, we'd still have stone wheels.

But doing this in C already exists and works well. I don't understand the point of it. Although, in this day and age, rather than use the standard Unix toolset, people invent their own tools as if they are new. "Make" versus "npm" for example.

Do you really think Make could replace npm?

Recursive descent parsing can handle different class of languages from what yacc or bison can do. It is possible to build lexerless parsers this way (so scrap your old useless flex).

So your trying to say this thing does a better job?

I seriously doubt it ever will, but you have to start somewhere.

I've used Parsec before and it is certainly nice. Honestly I think it's a bit weird to try and shoehorn it into C, but hey maybe something interesting will come out of it.

What bugs me is the suggestion that just because bison works well enough, nobody should try and make a new parser generator in C. They will probably not take over the wold, bison is big and battle tested after all, but bison is itself also a replacement for older tools. And hey, maybe mpc here will succeed and revolutionize parsing for the best; then we can have this discussion again in 20 years about someone attempting to replace it.

What you just said is this new thing isn't as good, and probably never will be, but you imply we should use it, even though the current tools are better.

See my complaint? If they are going to introduce a new tool, it must be better than the current tool. It's not and it's worse and not as mature.

I didn't say you should use it, nor would I. Only that it isn't pointless/futile to attempt. No tool will be as mature as bison or what have you until it has also been battle tested for 25+ years, but 25 years ago bison was also new and upcoming.

Not to mention that this is not even really a parser generator like bison or yacc... it's a combinator library. It's an entirely different way to write a parser. It's like me saying Python shouldn't exist because I know how to write C.

This one may not be that good. But any Packrat-based library is definitely much better than anything Yacc can offer.

It is different, targetting a different set of use cases.

In yacc the generator will tell you about shift reduce conflicts. Once you have debugged the grammar the parser is likely to work. With parser combinators you have no such assurance - you don't know if your grammar has loops, the parser might get stuck easily while parsing. However for a simple and regular input language like sexpr everything is fine.

In recursive descent you simply do not have any shift/reduce conflicts.

you can have left recursion, or implicit left recursion in your recursive descent grammar, if you have then the parser gets stuck while parsing a clause that contains left recursion.

Firstly, this have nothing to do with shift/reduce. Secondly, you can safely handle left-recursive grammars in Packrat (which, in turn, can be implemented with combinators).

I didn't say that left recursion has anything to do with shift reduce conflicts. Please read again.

I see, yes, you mentioned loops earlier. Anyway, it is not a problem for combinator-based parsing, just use Packrat with a left-recursive extension [1]

[1] http://www.vpri.org/pdf/tr2007002_packrat.pdf

I know how to use lex/yacc. This is much better as lex/yacc are, frankly, miserable to use.

Is there any other uses of snapchat outside sending nude photos?

Is it possible for Google to create a ToS that grants them all ownership of email you send?

> UPDATE: There are, by and large, two broad types of writers: extroverts who promote themselves capably, but might or might not have equally good skills, and introverts who lock themselves away and aren't great at self-promotion.

That in itself is a broad swath of a statement, and not necessarily true.

Why does being an extrovert have to be correlated with being and impostor, and introvert just simply these poor humble victims whose talents are overlooked?

What I saying is, if you're looking for work - applying for jobs is never the time to be humble. And if you are already confident, being humble won't help you.

1. What part of the phrase "might or might not" wasn't clear to you?

2. Where in "introverts who lock themselves away and aren't great at self-promotion" do you see any assertion about talent?

What you're saying is a word salad, primed by not reading what I wrote carefully.

The obvious answer is Haskell.

It is the only logical language that exists. Anyone who doesn't know it just hurting themselves.

After you master functional programming, you will be able to use it in EVERY other language.

You can even program ruby on rails functionally.

If anyway says anything negative about functional programming - they're just not dedicated or intelligent enough to understand its' abstract concepts.

In a world filled with hurt feelings and thin skin - finally seeing the logical essence of code is a transcendent experience.

That has got to be a troll post. Nonetheless, on the danger of starting a flame war, here is a brief answer:

No, Haskell is not the obvious language. Though no doubt a very nice language, it is nowhere near the top of the most commonly used languages. Thus, it's money-making potential (in terms of available jobs) is pretty low - which seems to be the main factor the OP is interested in.

As for functional programming: much as I love it, it is not the non-plus-ultra answer to life, the universe and everything. And even if it were, there are other languages that are also functional; all the various Lisp dialects to start with.

And by the way, please refrain from personal attacks on HN.