arohner

I wasn't planning on announcing yet, but this seems like a good opportunity.

I'm working on a service that does real-time monitoring of your website performance, as measured by your actual users, on their browser. If that sounds interesting, my email is in my profile.

The Ketchup Conundrum (2004) http://gladwell.com/the-ketchup-conundrum/

> The idea behind "not everything is an expression" is that ordinary macros only extend the expressions in a language.

That sounds great, for lisps, when everything is an expression. I feel like you haven't fully embraced lisp, because the article just kind of asserts that not everything is an expression, without justifying it.

In lisp the point of expressions isn't that everything has a return value, the bigger gain is that everything fits together, like legos. One of the big wins is that you can use your same toolkit, functions & macros, on everything. The point of the article seems to desire restricting that.

And my point is that everything isn't a list, but it is data. Macros are functions that take data, and return data. Their most common usage is that that they take lists and return lists, but that isn't required.

Macros hinge on the idea that code is data. Macros are functions that run at "compile-time" [1], that take unevaluated code (i.e. data) and return any valid data, it just happens that returning a list is interpreted as a function call. But I can also define:

(defmacro foo [x] :foo)

which always returns a keyword.

All lisps that I'm aware of only let macros dispatch on list evaluation, i.e. when you see (foo ...), call the function defined in (defmacro foo), but I'm not aware of any limitation preventing you from applying that to other types of data.

[1] technically, they run at macro-expansion time, which is after reading the expression, and before evaluating.

> 2. This is relatively easy. The sandboxed code could "open" handles by calling into an API, and the code could "close" them when no longer needed.

That's easy to specify, but is it good for the user? You've just opened the door to memory leaks on my machine in poorly-written "javascript".

Your response gave the impression that you think you should get into YC because of your programming ability. Startups aren't about your code skill. It helps, but there are several things that matter more:

    - your personality & attitude
    - the idea
    - the size of the market
    - the skillsets of your cofounder(s), and your ability to communicate/work together

But websockets doesn't give you raw tcp, right? Do they have a proxy somewhere?

Ok, I understand how you'd run a CPU emulator written in JS, in a browser, but how do these things get raw socket access?

If you're running in a browser, all the network access you get is HTTP AJAX, right?

I had a conversation with another semi-famous PL designer. Not one of the ones you list, but only a little below them. He primarily worked on languages the C/C++ family, and had no conception of the value of a closure.

There are lots of smart PL designers working systems languages, and there are lots of smart PL designers working on high-level, functional languages. That doesn't mean that either group is necessarily aware of everything the other group is doing, and it doesn't mean they share the same goals, experience, or taste.

> Would more talented people in the U.S. pursue Silicon Valley careers if they got 3% instead of 1% to be an early employee?

IMO, no. The difference between founder and employee #1 is still too large, even though the risk is not significantly higher.

Assume there are two founders, splitting 50/50, then there's a 10% employee option pool, so the founders have 45% each. Moving from 1 -> 3% is not enough incentive, but moving from 1->10% might be.

Not necessarily. Surely there are people out there who have the potential to be exceptional, but never reach it, because they never got started, never realized they'd be exceptional, etc. Converting the potential exceptionals into actual exceptionals, is a very big win.

SEEKING WORK - remote, Austin, TX

I fix things.

Skills:

- I'm a Clojure expert, using since 2009. I have commits in many major libraries, I've talked at Clojure/West twice. I've run 3 SaaS companies on Clojure stacks, including Om & Clojurescript.

- technical marketing

- SaaS operations (CI/CD, linux performance benchmarking & optimization)

- AWS

- customer development

- frontend code (but I'm not a designer!)

- Apple Swift

Multi-line lambdas, for one.

IMO, the problem is that your standard OS has way too much stuff running.

A SaaS app running in production should be about the size of your binary, and the libraries it uses. Instead, we have X, smtp, terminals and a full filesystem running. home directories and uids make no sense in an app that uses no unix users except for the one you're forced to use.

I'd really like to see a much smaller, simpler, non-posix OS for running server apps.

OSX as an OS is weaker than Windows at games performance. For example, Valve officially supports Mac & Windows in-house, and running the same game (e.g. TF2) on the same hardware in windows will see framerate increases of 20%-100%.

Completely agree. I also think projects should draw a clearer distinction between queues, and messaging. ZeroMQ for example, is not a queue, it's a toolkit for building a message bug!

> Personally I'm not going to get a smartwatch because I hate interruptions. I hate OS X notifications; I hate it when the phone rings; I hate reading Twitter (but it's an addiction that's sometimes hard to overcome). I certainly don't want a blob on my wrist endlessly buzzing and tapping away, trying to figure out my heart rate and mood and generally being a bothersome noisy little electronic snoop.

I agree with the sentiment, but, based on my interactions with OSX and iOS, I assume it's not essential that the watch buzz and interrupt you all the time. I have all popups & notifications disabled in OSX and iOS, and they're still great tools when you're ready to pay attention to them.

I won't be getting an Apple Watch v1 (because it's not waterproof, and well, v1), but it wouldn't surprise me if I bought one down the line. I think there's a lot of interesting things that can be done with all the new sensors, and UX.

No. My stereotypical use case is say, responding to an HTTP request that involves side-effects:

    (post "/user/foo" [request]
      (update-db)
      (future (send-user-email))
      {:status 200
       :body (render-page)})

What happens if email delivery fails? What happens if this box powers off? etc. Queues don't solve all your failure scenarios here, but they're a great first step.

Great article, thanks.

[from TFA]

    > This however does come with a cost:
    > - We cannot use Clojure’s concurrency primitives (futures/promises/agents).

Running my own large-ish Clojure service (CircleCI), I'm pretty convinced that futures are an anti-pattern in many situations. If your future is for side-effects, rather than for computation, the future call should probably be going on a durable queue being processed by a cluster of machines.

I recently started using mutt, connecting to GMail w/ IMAP. It's been working pretty well.

I'm still really interested in a full mail client that supports all of gmail's features (labels, archiving, etc), and works well with Emacs.

The halting problem is unsolvable in the general case, but there are lots of specific, practical cases where you can answer "yes, this program terminates".

Is it possible to specify the complexity of every arbitrary function? Probably not. Is it possible (and useful!) to specify the complexity of most functions you use on a daily basis? Absolutely.

A stronger critique I heard once is that 'computer generated complexity analysis has too much noise in it', where you ask what is the complexity of this fn, and rather than giving you O(n^2), it gives you back O(n^2 * m * q * log(r) * s^4), but it turns out 's' is "always" a small number, and m & q are constants. You can improve (but not completely eliminate) this by doing empirical testing, i.e. "the statistical sample of 1000 test runs varying the input does appear to fit an O(n^2) curve".

Completely agree. For a long time, I've thought that humans shouldn't be in charge of version numbers at all. The main problem is that a human isn't reliable at determining "is this change breaking?".

Unfortunately our software isn't well-specified enough to allow the computer to determine version numbers automatically yet. To make this a reality, you'd need Haskell-level type safety, along with specifying other constraints, like "this fn is O(log(n)) or better".

>If you're pinning versions, you're reducing the package manager to a glorified CURL

I'm actually quite happy with this. I realized it when a few weeks ago, bower broke for me. Turns out, a grandchild dependency of bower failed to follow semver. This means that it's not enough for you to follow semver, every single dependency of all of your dependencies have to follow semver as well.

> In other words, it lacks the most important mechanism that lends dynamically typed languages like JavaScript and Ruby their power.

I think you haven't spent much time using Clojure.

Your phrase "it is more of a mashup of a few ideas from functional and OO languages" seems intended to downplay the language as nothing important. By that metric, Ruby and Javascript are both "just" mashups of lisp/scheme, perl, smalltalk and self.

Clojure can be just as dynamic as JS & Ruby. On the JVM, protocols are implemented in terms of Java interfaces, because that's how you get fast dispatch, however, protocols share little in common with "standard" OO. There's no implementation inheritance, a protocol can be extended to any type (except for a few limitations caused by the JVM, those limitations don't apply to other implementations, like CLJS).

>Memory safety does not require VM management (or so Rust is trying to prove).

I agree, with a few qualifications. I think Haskell has already proved it's possible.

I think Swift + ARC isn't a strong enough guarantee of memory safety for two reasons:

1) Swift has to interact with a huge amount of objC code, of varying degrees of quality (some Apple code, some OSS code via cocoapods). Swift itself would be much safer if all objC was rewritten in Swift.

2) ARC isn't as strong a guarantee as either GC or Rust's pointer semantics. For example, it's easy to hold weak references to something you thought was retained, and then dereference an invalid pointer.

So yes, you can have a memory safe language without a VM, but I think you need GC and/or much stronger pointer semantics, ala rust.

If you stay in pure swift, it's much harder to segfault, but it's still possible, mainly due to the amount of objC code you interact with. Today, it's not reasonable to expect a swift programmer to be proficient without knowing objC, the way it's reasonable for a Java programmer to not know C.

The segfault I hit yesterday had to do with a CoreData API that didn't retained its argument, when I assumed it did. The bug doesn't appear when compiling with -Onone, but does appear in -O. Compiler flags are another place where Swift is still very much in C-land, rather than Java/Python/Ruby land. You still need to understand the C compilation model, and e.g. getting your ARC flags wrong in a cocoapod will still cause crashes.

To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language.

Spending the last month swapping between Swift and Clojure, there's still a very large safety difference between ARC & a memory-safe VM.

The problem is, compiler magic gives the illusion of safety, and then you segfault and remember that you're in a non-memory safe language. Swift is a big improvement, but it's still basically a DSL on top of objC, with all of the downsides that implies.

I'm not claiming there aren't huge downsides to being in SF. I'm claiming

- there are some advantages, but it depends

- the advantages depend on your target market, the stage of your company, and your desired direction, in terms of bootstrapping vs. raising

- you can't know ahead of time which way (SF vs. STL) will be more advantageous, and you can't repeat the experience, because the second time you'll have more experience, more talent, etc. This is a path-dependent experience.

Maybe if they did the startup in SF, they'd meet an advisor who changed the direction of the company to something even better, or maybe they wouldn't, in which case low cost of living in STL is an advantage. But pointing at cost-of-living alone isn't a useful comparison.

Counterfactuals are very hard to know. At CircleCI, being in SF gave numerous advantages early on. We had multiple paying customers in the first two office buildings. We had multiple customers within walking distance, and many more within cycling distance. Being able to talk to real customers using the app was extremely valuable.

Customers aside, there are tons of people willing to help, either through advice or introductions. There's an entire ecosystem who understand startups, and have been there.

My failed started before that was in Austin, Tx, and the startup density just wasn't there at the time (2009).

Not every developer in SF is as mercenary as you make it sound. For your first employee hire, you might find a single person living in an apartment in SF vs. a family man in St. Louis who has to pay for day care and save for college. Their salary requirements might be comparable. [Edit: my point here is not to say that SF people are only single, and STL people only have kids, but that salaries are a distribution, and that there are places where the SF and STL distributions overlap, based on the individual's experience, desires and stage in their life.]

SEEKING FREELANCER

Remote or Austin, TX

Founder & CTO of a startup of 14 employees, consisting of 11 engineers. 5 years experience managing engineering teams of 5-11 developers. Skilled in backend engineering, system architecture, distributed systems, performance optimization.

- Worldwide Clojure expert, I have commits in Clojure core and most of the libraries used to run a Clojure web stack. 6 years full time experience in Clojure (7 is the maximum possible!). - Strong Linux Ops knowledge, I've shipped kernel modules. Built, deployed and monitored the production AWS cluster, consisting of 100 cr1.8xlarges.

- Enough javascript to build UI features, but need the help of a designer to make it not look terrible. - Proficient, but rusty in: C, C++, Java, Python, Ruby.