jbclements

As someone with a definite and well-established viewpoint on CS education, I sort of expected to hate this paper... but I didn't. I thought it made some excellent points, and I very much liked the idea that people not trained as programmers might be able to point us toward new paradigms.

At this point in the development of programming languages, the problem is not really that we can't build languages that do what you want; by and large, for unambiguous specifications (and yes, that is a big qualifier), we can.

At this point, then, the conversation shifts from "how can I meet the machine's needs?" to "how can the machine meet my (programming) needs?" Another analogy: we're no longer just stone-age people looking for a rock that doesn't shatter when we hit things with it; we're can shape our rocks now, and we're trying to figure out what shape allows us to hit things hard without cutting our hands.

Go, functional and declarative programming! Oops, I gave it away. Sorry.

I'm really astonished to find only a handful of references to DuckDuckGo in this discussion. I've been using it exclusively for about 2 years now, and had no problems at all. Perhaps I just don't know what I'm missing ... like mind control!

I have a lot of bones to pick with Mathematica, but calling it "clunky" seems like a stretch; my experience suggests that mathematica is the exact opposite of clunky; it has so much silky chrome that I feel like it's completely lost touch with its declarative core (if it ever had one).

I'll tell you what I want: I want Google to help identify non-DKIM-compliant forwarders. As the operator of (yes, I know) a vanity e-mail domain with DKIM, SPF, and DMARC records, I have no problem sending mail to gmail directly; in fact, my outgoing mail uses postmark, so I'm not even directly responsible for my sending reputation.

BUT! It drives me crazy that many of my recipients get e-mail at hosts (schools, mostly) that forward the e-mail with differences (encoding changes, subject changes, etc.) that invalidate the DKIM signature. Since they're forwards, the SPF check is going to fail, too, so the end result is that google shoves it into a spam folder.

I claim that google definitely has the data to be able to identify these bad forwarders--heck, even mail sent from gmail to these hosts will presumably fail DKIM checks on the way back into google--and I'd love to see them contact these domains, or even publish a list of known bad forwarders, so that I can push them to make changes.

I'm not so sure about that; I use a self-signed cert for port 25 TLS, and I just sent from google to my domain, and didn't see a warning.

I host with linode, and have had generally good results sending mail to gmail. They're definitely not the worst. Granted, I have had SPF enabled for about 10 years.

I geniunely do feel bad for magazines that are trying to figure out how to survive in a world of ad-blockers. I suspect that many hard-working journalists will lose their jobs as magazines like Wired go out of business. I personally subscribe to several newspapers, and I worry about them, too, and what's going to happen to journalism in this country (USA, sorry for my chauvinism).

BUT!

I want to KILL the free internet--that is, the internet that is paid for with slices of my attention and life. I do believe that advertisers are very good at extracting my attention and money, and I genuinely do want to destroy that internet model. What will emerge? I can only cross my fingers.

I'm very sad to see this announcement. I've been a big fan of persona since I first learned about it three years ago, and for a few months I tilted at windmills by writing to services I used, and asking them why they didn't support persona login.

After writing about four of these, though, I had a small epiphany; this is a ludicrously uphill battle, because Facebook and Google don't just make it easy to use their login because they're nice; the information that they gather from these logins is worth good money to them, and so of course facebook+google login is the most frictionless and butter-easy way to implement login.

Sigh.

Okay, I know this was totally obvious to everyone but me, but it does make me sad, and I can start to see the outlines of an internet that I'm somewhat less excited about than the one we have now.

I'll miss you, persona. Mozilla, keep up the good fight!

Sorry to see this post sink without a trace; I think this is a really big deal, and I'm excited to see a shared industry/academia ecosystem growing around Rust. Now if only the macro system were a little more hygienic ....

Main-line lefty here: I'm immensely frustrating to me to read articles that point out that there's no solid research on guns & gun violence when--to the best of my knowledge--congress has been blocking funding for this research for quite some time.

That's not a fair comparison. I can't believe I'm going to defend Apple here, but Apple's "walled garden" is an environment that they designed, that people can choose to use or not. We can tell people that there's a long-term price associated with this, but people that choose to support Apple's model are not in the same boat with people that choose not to believe in carbon dating.

After 10 seconds of inspection: no, not a good idea, don't think this solves a nice problem.

Speaking as a PL & s-exp guy, I don't really have a problem writing

(bullets (item "pick up milk") (item "drop off desk"))

... but at the end of the day, I see that I can convey the same structure in a clearer way using markdown. Markdown is lovely because it's the thinnest possible skin over the structure; you can immediately see what structure the syntax is attaching. (Yes, there's still some parsing nastiness around paragraphs). This thing, though, doesn't have that "brilliant solution to a simple but really important problem" feel to it. I don't see this catching on.

Of course, I said the same thing about the internet in the spring of 1993.

try it out! I found this style of password (horse-battery-staple) to be much longer and less memorable. The proof, of course, is in the pudding. The next step (for me) is to conduct a reasonable experiment to discover whether or not these passwords are memorable.

Yes, absolutely. 100% invertible.

cool... can you guarantee that every password is generated with equal probability?

Variable-order markov models do sound interesting; this tool isn't using them, though....

I tried it, and ... eliminating the double-quotes looks like a win. Average password lengths in the order-2 model don't increase measurably; it rounds to 20.0 chars for both models.

I've now deployed this.

Um ... I mean... what quotations? I don't see any quotation marks!

(Many thanks.)

Um... certificate pinning?

Fortunately, my last caveat covers a bunch of these.

Also, I think you(I) forgot:

* You are in fact hallucinating at this very moment.

Things will definitely get a bit longer if you make the source more uniform. I sympathize with you on the quotation marks, though; I think it might be nice to toss just those. Lemme try that.

I took a look at whole words. Things got a lot longer. Like, twice as long. Here, let me generate some. These are 56-bits each:

'(#" that looked up to Darnay: you not?\" \"Very willingly,\" pointing" #" that it was confirmed. \"He may not--thou wouldst rescue this is touched the child" #" that direction through his, and said Stryver, \"that, there! I" #" that criminal in Lombard-street, out at neighbouring streets that she" #" that he,\" said Darnay. Released yesterday. I.\" It was set, and--in a highly" #" that although Sydney Carton.\" This must have to finish that way" #" that Madame Defarge's wine-rotted fragments of his. \"Carton, idlest and its accessories" #" that every rapid movement, and, as the executioner showed a high grass and")

Really, I would not not like to type in "that every movement, and, as the executioner showed a high grass and" every time I opened my laptop.

Seriously. Has someone already done this? Next gen peer review, anyone?

you might be interested in http://try-racket.org . Quick online tutorial. Haven't worked through it myself, but spent 30 seconds with it to make sure I wasn't embarrassingly wrong.

I'm assuming that there's no memory safety guarantee for Swift code that interacts with Objective C code. Can anyone shed any light on this?

From a PL standpoint:

1) APL clearly made good use of an extensive symbol set. Now that many languages support unicode, this is totally do-able.

2) APL is in love with overloading. It's not totally my cup of tea, but you could definitely fit this into many modern languages.

3) I see a whole lot of MATLAB in there.

4) Did... this article actually define any functions at all? Perhaps I missed this.

5) It looks you could easily implement APL as a DSL within an existing language with an extensible parser. Racket, for instance.

This is absolutely the best news I've had all day. I've been a fierce advocate of proper tail calling since 1999, and I'm incredibly happy to see it gaining traction outside of niche functional languages like Racket. Many, many, many thanks to dherman and jorendorff and all of the others who made this happen.

Now, off to brag about this to my PL class!

Looks like no one's mentioned Benjamin Pierce's authoritative book on this, "Types and Programming Languages" (TAPL). I would certainly put it way, way above the Dragon Book. Bob Harper can certainly defend his opinions as well as anyone, but I think Pierce is currently the standard text here.

Also, if you're looking to add a static type system to a Lisp-like language, you should take a look at Shriram Krishnamurthi's Programming Languages and Interpretation, second edition, at http://cs.brown.edu/courses/cs173/2012/book/ . It's a free online book, and I'm currently using it as the text in my programming languages class.