6 ms·
I helped with the Eve language, which was a VC funded attempt down this path (https://witheve.com https://witheve.com). This was cut short when the money ran ou
by cmontella 4y ago
I helped with the Eve language, which was a VC funded attempt down this path (https://witheve.com https://witheve.com). This was cut short when the money ran out, so it wasn’t a full attempt.
After that project ended I started working on my own attempt called Mech which specifically handles the time-travel and what-if features you mentioned (https://GitHub.com/mech-lang/mech https://GitHub.com/mech-lang/mech you can play with an early alpha version here: http://docs.mech-lang.org/#/examples/bouncing-balls.mec http://docs.mech-lang.org/#/examples/bouncing-balls.mec). I’ve made sure money running out won’t kill this project, so hopefully it’s a fuller attempt.
Someone else posted a link to futureofcoding.org, which is a community that works on these types of projects. You can find a lot more there.
- jacquesm 4y ago> This was cut short when the money ran out, so it wasn’t a full attempt. Hm, I'm not sure I would agree with that. It was a full attempt, but an unsuccessful one in my view, why do you think it wasn't a full attempt? You tried, it didn't work (which is fine) but money running out is usually not the cause of a failure but the reality check that the project is a failure, if it wasn't the money would not have run out!
- derangedHorse 4y agoThat's false. You could have a project well underway to fulfilling its goal but not in a timeframe in accordance with what a VC would expect. It's not a full attempt because the developers didn't get to give it their all until they gave up, they just didn't have enough money to both pursue it further and support themselves and/or their families at the same time.
- jacquesm 4y agoIf you can't communicate that you are on to an actual win before the cash runs out that's failure, pure and simple. I've seen more than a few of these 'oh, if only we had more money we'd have surely made it' or even 'the shareholders killed our company by refusing to invest any more' but that's in all of the cases that I've seen simply a company that is on life support from day #1 but refusing to admit the reality of the situation: that it's time to move on. Been there, done that, and I totally sympathize with how it feels but coming up with a realistic time-to-market and an actual working setup is part and parcel of success, the lack thereof is highly correlated with failure and/or acquihires. VCs don't have a set timeframe for your success, you set that timeframe yourself when you go and ask for money in the first place. There are some exceptions to the rule (Cisco comes to mind) but in general this is just another form of failure. Getting funding is to get someone to write a lottery ticket, they are under no obligation to provide more funding than that particular time and failure to raise more money from existing investors or new ones is strongly correlated with an inability to admit to failure and/or pivot fast enough that you can still land on your feet. This sort of introspection is a massive advantage for founders that are capable of doing that, and a huge hindrance for those that believe so strongly in their vision that they can not depart from their tracks until they hit the wall.
- Gene_Parmesan 4y agoFailure as a VC-funded enterprise != failure of the underlying 'thing' as a concept. A programming language seems to be a weird fit for the VC model in the first place, no?
- jacquesm 4y agoYes, that's true and that's why I state my position: the choice to bring in foreign capital changes the equation drastically. They were lucky to get funded, and burned through the cash at a higher rate than they should have to make it to the finish line. I don't see how you can blame the VCs for that. I've seen a couple of VCs invest in language eco systems and/or language related products and some of those are quite successful but they had a working product and paying customers, they decided to use VC as an accelerator which is perfectly ok. If you need VC to do your basic research and you are pre-product with all kinds of unknowns then that's a bad match regardless of the field, unless you make it perfectly clear up front that you expect that follow on rounds are going to be required. As for outcomes: there are successes, soft landings and failures, I have not seen a fourth case in practice across many, many companies. Not as many as YC but a fairly representative fraction of that number.
- cmontella 4y agoI interpreted the title of this submission to mean "Has anyone exhaustively tried out Bret Victor's ideas?" With respect to Eve, the answer is that although we tried many things he demoed, we didn't try them all, and therefore I characterized it as not being a full attempt at his ideas. And to be clear, I don't want to sell Chris short by implying that Eve was just some attempt at reifying Bret's ideas, because Eve did have a lot of ideas that didn't come from Bret (or that Bret himself got from others like Kay). Whatever failings of Eve a business idea (admittedly many), it didn't prove that these ideas are a dead end. Far from it, we arrived at the best ideas toward the end of our runway. Early on we spent a lot of time trying things out that seemed cool in Bret's demos, but didn't really scale to being an actually useful tool, either because the demo was too niche (e.g. the Mario jumping thing), or because it wasn't actually a useful thing (e.g. live coding by recompiling a program on every keystroke). That's what the 2mil actually bought I think. In the end, we abandoned the business but not the ideas. The Eve v0.6 runtime was forked into Mech, and although that's been largely replaced by now, it still maintains the spirit. Chris has been working on his own project for a while now based on the final Eve prototypes that we demoed right before we closed up shop. > burned through the cash at a higher rate than they should have to make it to the finish line. We were actually very frugal with the money, and set the burn rate as low as we reasonably could. Most of it went to our 5 salaries, which were far below market in SF; and our rent, which was pretty reasonable for SOMA. Like I said, Paul took a different more drastic approach with Dark to set their burn rate even lower, but Chris (and all of us really) didn't want to go that way because it was better working on Eve as a team. The best thing we could have done actually would have been to leave SF, but that wasn't really an option for many reasons. The problem with determining burn rate to make it to the finish line is: how do you a priori figure out where the finish line is in such a nebulous space? We went home in the end, because the entire idea of Eve was essentially about trying to identify that line. How far did we need to push in order to get to a business that empower a billion to code? We identified several viable businesses along the way (you can see companies like Wix and Miro becoming large in this timeframe, and Eve could have been something like that), but they weren't the business, the one that would bring a billion other people into coding. Low-code isn't the way. I'm sure we could have convinced some VC to fund a low-code SAAS at the time -- we had the team to build it. But it was a decision we made to actively not do that thing, and shoot for the moon. Can't blame VCs for not funding that kind of ambition in perpetuity, but I still can't characterize the effort, not having realized its full vision, as a full attempt.
- cloogshicer 4y agoMech looks really interesting! Does it handle cycles in the data dependencies? I find this usually to be the crux of the reactive model.
- cmontella 4y agoYeah, it does. We can have cycles in data and do recursion (although not in functions yet), but it is admittedly a little strange compare to imperative world; there's a recursion limit set that will short-circuit a computation if it nests too deeply. This isn't because of a danger of stack overflows, but because Mech programs are intended to reach some steady state at the end of each event. The problem with cycles is that we don't know when something is in an infinite loop, or if it's still churning before a steady state is eventually reached. That said, one of the things I'm really interested in is seeing how far I can take the model on a DAG, because programs are much easier to reason able when they don't have cycles in the data. So far it seems you can write some very complicated programs (games, graphical user interfaces, robotics) as a DAG.
- cloogshicer 4y agoThanks for the detailed explanation! I've been trying to write a game and I always keep running into cycles. You're right, a lot can be done as a DAG, but especially for games, cycles happen a lot. I'd love some resources on how to deal with those cycles when they come up.
- jay-barronville 4y agoThanks for sharing. Both Eve and Mech have me intrigued. I’m going to do a deep-dive into them later today to learn more and explore the concept.
- cmontella 4y agoI'd start here for a quick 10 minute overview: https://www.hytradboi.com/2022/i-tried-rubbing-a-database-on-a-robot https://www.hytradboi.com/2022/i-tried-rubbing-a-database-on...
- WickyNilliams 4y agoOh hey, I loved reading about Eve around the time of its release. Also isomorf (https://blog.isomorf.io/what-is-isomor%C6%92-bdc50ce597ee https://blog.isomorf.io/what-is-isomor%C6%92-bdc50ce597ee). Something about languages that try to shift the paradigm has always fascinated me. Looking forward to learning about mech!
- cmontella 4y agoHi Nick, thank for sharing that project, it hadn't been on my radar. I think it is a project squarely in the Eve ethos! Sadly I can't find any code on their GitHub accounts, so they must be doing development in private.