tmerr

Some comparisons based on my reading so far:

Adding a language:

  Kythe: a language implementation provides some structured graph
  SourceGraph: a language implementation is an LSP server

Backend logic:

  Kythe: has common logic for querying for relationships
  SourceGraph: simply proxies LSP requests through to the appropriate language server.

Terminology:

  Kythe: An indexer is a language implementation
  SourceGraph: The index means something completely different, it's what keeps track of git repositories.

SourceGraph Architecture: https://github.com/sourcegraph/sourcegraph/blob/master/docs/...

Adding lang server to SourceGraph (probably somewhat stale) https://github.com/sourcegraph/sourcegraph/blob/master/xlang...

It probably refers to distribution of binaries without source code, which MIT license allows. Wording could be better

And here I am using for loops like a caveman

Yes, that's the school I went to

I'll add that DC is alive and well on my college campus. Beyond speed, it's less likely to get you in trouble with the college + ISP than torrenting, and has some textbooks and other locally relevant content.

This is likely borrowed from Haskell where functions starting with special characters are treated as infix. Parens and backticks allow for switching between the conventions

    add a b = a + b
    -- these are all the same
    3 + 4
    (+) 3 4
    add 3 4
    3 `add` 4

The article might also make slightly more sense in context, I think it was in part an idea for how to make infix notation more useful in Kitten: https://github.com/evincarofautumn/kitten/issues/174

Thanks for the correction! I don't think manifests were mentioned in the whitepaper but I found some info on the wiki: https://github.com/freenet/wiki/wiki/Simple-Manifest.

It looks like I will also have to learn more about IPFS's routing. Clearly Freenet's has some merits, and I would hope that IPFS is strictly faster since it sacrifices privacy, but I don't understand it well enough to make sense of how it scales.

Hmm they are sort of different things. Freenet basically has hash-addressed content plus some relationship between human-readable strings and the hashes, so you/can/refer/to/stuff/like/this making it easy to use HTTP on top of Freenet for navigation. In contrast IPFS makes the hashed content itself in charge of navigation by using git-like objects -- if you understand the way git objects work https://git-scm.com/book/en/v2/Git-Internals-Git-Objects then you understand that this allows you to navigate an immutable tree of content and an immutable history. In contrast, on Freenet particular files are immutable, but that's as much as they guarantee.

They also differ in the way routing works. On Freenet you ask a (mostly) random neighbor whether they have a file with the hash you want. If they don't have it, they ask another (mostly) random neighbor. This can go on for a while, until it either finds the content or hits a maximum number of hops, in which case it backtracks. The only point of these rube-goldberg shenanigans is anonymity. Since IPFS is more concerned about performance it flips this on its head: instead of blindly asking nodes for content, it carefully keeps track of peers who advertise what they're looking for; aside from being much more efficient, this also allows you to choose not to do business with leechers, like in bittorrent.

Maybe IPFS is a reinvention of a past technology, but certainly not Freenet. (Does anyone know of something closer?)

Freenet paper: http://www.cs.cornell.edu/courses/cs414/2003sp/papers/freene...

IPFS paper: https://github.com/ipfs/ipfs/blob/master/papers/ipfs-cap2pfs...

  https://www.w3.org/People/Berners-Lee/FAQ.html
  Q: Do you have had mixed emotions about "cashing in" on the Web?
  A: Not really. It was simply that had the technology been proprietary, and in my total control, it would probably not have taken off. The decision to make the Web an open system was necessary for it to be universal. You can't propose that something be a universal space and at the same time keep control of it.

I wonder if this might be closer to the reason that Xanadu didn't take off than "worse is better". Where is the Xanadu implementation we can hack on, other than an incomplete dump of code here http://udanax.xanadu.com/gold/download/index.html built on a proprietary platform? Why is it that when I look up ZigZag I find an open source project that closed down over patenting concerns http://www.nongnu.org/gzz/ ?

There is a neovim plugin for sublime if you want to benefit from both fancy hotkeys and the minimap / other IDE-ish niceities

The concern about stack space is slightly misleading since many languages, i.e. Scheme, can easily optimize such functions to use O(1) space by reusing stack frames across recursive calls. The problem is that while Scheme guarantees this tail-call optimization in the spec the are many other languages that leave it up to implementation, or intentionally omit it because they don't want to lose stack traces.

Anyway I agree with the overall sentiment, and will check out the talk you linked. There's another good one along similar lines: "The Clean Architecture in Python" by Brandon Rhodes: http://pyvideo.org/pyohio-2014/the-clean-architecture-in-pyt...

I use Selenium to drive a firefox browser under the assumption that banks don't care enough to detect it: https://github.com/tmerr/bank_wrangler . I am also slightly worried about banks not liking it, but if they do care I guess I will receive a scary cease and desist in the mail and I will cease and desist.

I came to a smiliar conclusion and have been working on a solution for my particular set of bank accounts. So far it downloads transactions from citizens bank or venmo using selenium. Then in a separate stage it parses them into a python object based spreadsheet.

I've also used YNAB and loved how it could categorize spending. So a part of my project is that it lets you use udev-inspired matching rules to assign categories or other properties to transactions.

You can also put credentials for each bank in an encrypted file behind a master password. I can't promise it's secure but it's enough for me to not worry about saving the info to disk.

There's still work to do: I've only implemented a couple bank backends and some core logic, and haven't got around to adding anything for analysis, or a real setup.py, or a readme. Still working on it a bit every day. Fidelity is next. Would love it if anyone was interested and wanted to add their own equally jank bank backend.

https://www.github.com/tmerr/bank_wrangler

This works well, but the web interface seems like an unnecessary layer on top of what could just be a terminal based tool. I'm trying to resist the urge to fork this, putting another project on my todo list I will never finish

Sure statically typed functional languages are enjoying a lot of success right now, but there are still plenty of LISPs in the playing field like Clojure that can't be discounted as parlor tricks. You might disagree with them philosophically, but it doesn't change the fact they're being used in production.

What bothers me more about JS as a functional language is the lack of tail call optimization. While it's in the ES6 spec, last I heard there was some question of whether it would actually be implemented for web browsers.

>Nobody uses it, but it's the best choice, both can't be true

Sure it can. It is possible for both to be true, as long as developers don't pick languages rationally, which they probably don't.

There are a few biases at play. One is that people are only exposed to a subset of the languages that exist, which are those that are either used in industry, or are making the rounds in news. Another bias is that we like to pick languages based on familiarity. For example most of my college courses used imperative languages: Python, C++, and Java. From that experience I am quicker at thinking in terms of for loops than folds and maps. So when I try a language like Haskell or LISPs I think "That's neat!" but when faced with a deadline I switch back to something closer to my first languages.

It could be that I am the only one that thinks like this, and everyone else sits down and spends equal time on every language in existence, but I doubt it.

In any case at one point LISPs were popular, so why did they lose all of their momentum?

I agree USA has an impressive track record for space exploration and is at the forefront of computing, but that seems like more of a reflection of our economy and top talent than overall math literacy. Ideally we would have the best of both worlds: good high school education, and a good economy, but for some reason the former lags behind.

Imagine a language where you work with blobs of data and have no restrictions on the operations between them. Like assembly languages. You can add a char* and float and the compiler won't complain. I would call that untyped. A typed language restricts the operations you can perform on blobs of data by classifying them.

A user could build a more restrictive type system on top of an already typed language. The distinction between a type system and an arbitrary source of runtime errors is that a type system has the properties i described earlier, and also it has the cohesion you would expect from it being a "system". A smattering of if statements wouldn't qualify.

That's one way to look at it I guess. Everyone has their own working definitions so I still it's still reasonable if you consider dynamically typed languages to be untyped.

Hi Alan,

I watched an OOPSLA talk where you described how tapes were used when you were in the air force. The tape readers were simple because they stupidly followed instructions on the tapes themselves to access the data. You seemed to like this arrangement better than what we have with web browsers and html, where the browser is assumed to know everything about the format. One way to interpret this is that we should have something more minimal like a bytecode format for the web, in place of html.

So I'm interested on your take: Is WebAssembly a step in the right direction for the web? (Although it's not meant as a replacement for html, maybe it will displace it over time).

The only reason some regular expression engines take exponential time to match strings is because those implementations don't use regular expressions at all. Features like backreferences break them out of that class of languages. When you take the "regular" bit seriously you can guarantee linear time matching. See the engines used in Rust and Go.

In what ways?

It seems like Microsoft wants to free the developer tools but control the distribution of binaries through the Windows Store. Seems like an intelligent business decision to me.

You can develop Linux or Mac but you're not going to get the same quality tooling (hello Universal Windows App Model).

Yeah Error handling bloat is a problem.

You can use convenience functions: expression.expect("panic with this message if expression evaluates to an Err")

You can also use macros: try!(expression) makes it so if expression evaluates to an error it returns the error immediately, otherwise it does nothing.

This approach is still more verbose than using exceptions but on the flip side dealing with errors up front can make it easier to write reliable code.

Hey, this seems like an application of induction. You choose some property you want to prove about your program, show it is true before the loop (base case), then show it remains true for any next iteration (inductive step), therefore it is true for all iterations.

It reminds me of the hand-wavy inductive proofs I run through my head when I write recursive functions. Usually it's not even about eliminating bugs, it's just the most natural way to understand why the code works. It seems less natural for imperative for/while loops but still a good tool to keep in mind.

Interesting point but I'm not sure how it applies to the argument. If websites are low quality, is that justification for an ISP to block them?

I don't have anything against philosophy. But I can't help but think if you want to understand quantum physics you should study quantum physics. And if you want to understand AI you should study AI. Starting with philosophy rather than the evidence is a good way to get entrenched in world views that don't make sense.

In AI the dominant attitude is that the mind can be considered a machine and that consciousness can be ignored. It dodges the philosophical questions entirely in the name of practicality. If anyone's going to find the answer to how consciousness works it will be neuroscientists, so in the meantime what's the point of debating it on philosophical grounds?

Similarly quantum physics didn't originate from philosophers who thought "It just doesn't seem right that the universe is deterministic! At a microscopic level electron positions must be probabilistic". No, these are things scientists figure out and philosophers reconcile.

It's not clear that AI researchers or quantum physicsts would lose anything by ignoring philosophers.

Without the cosmetics would this just be a run-of-the-mill chatbot or is there something more here? It's hard to tell from the article and video alone.

Web applets are terrible because

  - The JVM takes forever to spin up  
  - The JVM tries to do too much with tons of class libraries  
  - The JVM is insecure  
  - The JVM is proprietary. While there are open source
    implementations, it is still tethered to Sun and now
    Oracle. They call the shots on the features and have
    sued both Google and Microsoft for implementing their
    own versions.

Similar arguments can be made against Flash.

We shouldn't expect WebAssembly to have the same pitfalls, since

  - WebAssembly does not take forever to spin up  
  - WebAssembly doesn't try to do too much. There is no huge
    standard library. For now it doesn't even include a GC.  
  - WebAssembly isn't insecure. Why would it be? I assume
    applet exploits are a product of the large standard 
    library (more attack vectors) and privilege escalation
    (certain exploits let you break out of its security
    settings to gain control). All of this seems like it's
    because web applets are monkeypatched on top of the 
    existing JVM.  
  - WebAssembly isn't proprietary.

We should have had a standard like WebAssembly from the beginning. The lack of it is the reason for the outrageous explosion of features in web browsers. At first html made sense: it was ideal for quick transfer and rendering of documents. But today that's not enough. So we keep tacking on layers atop already fat abstractions. And all this fat is trying to support a moving target. At first it was about rendering text, but then it was animations, and then videos, and 2D games, and advertisements, and now 3D games and full fledged apps. Notice that operating systems don't play this game trying to build an abstraction for every possible use of a computer because it's unwinnable. And now, some 25 years since its inception, the web is learning the same lesson.

Web browsers have been like operating systems all along, because they execute programs, albeit with different performance and safety characteristics. That the two are converging upon the same solution to the problem of hosting apps should be reassuring, not concerning.

Well, that's just confusing.