cmontella

Trace debugging can be inefficient, but it's also highly effective, portable between all languages, and requires no additional tooling. Hard to beat that combo.

Well I don't agree with your premise on what University is supposed to be. There's a lot one has to learn about how things have been done before one can even conceive of whether or not an idea is new.

Today we stand on the shoulders of giants to create things previous generations could not, but we still have to climb up to their shoulders in order to see where to go. Without that perspective, people spend a lot of cycles doing things that have already been done, making mistakes that have already been made. There's value in gaining that knowledge yourself through trial and error but it takes much longer than a 4 year program if that's the way you want to learn.

My role is that of a ladder. People are free to do whatever they want, create whatever they want once they get to the top.

And anyway, we graduate students who go on to create new things every year. So proof is in the puddin.

Personally I have dyscalculia and to this day I need to add on my fingers. Still, I ended up with degrees in physics and computer engineering. I don't think those things you mention are useless, but they never worked for me so I don't view them as invaluable.

Yeah! Computer science students can do more "science" with the LLM. Before they spend all their time just writing and debugging. Instructors are happy if students can just write code that compiles.

When every student can write code that compiles, then you can ask them to write good code. Fast code. Robust code. Measure it, characterize it, compare it.

They're allowed to use whatever tools they want. But they have to meet higher standards in my classroom because more is going to be expected of them when they graduate. What would be unfair is if I don't prepare them for the expectations they're going to have to meet.

FWIW I teach upper level courses.

I see LLMs as almost sufficiently advanced compilers. You could say the same thing about gcc or even standard libraries. "Why back in my day we wrote our own hash maps while walking uphill both ways! Kids these days just import a lib and they don't learn anything!"

They are still learning, just at a higher level of abstraction.

I teach at the university level, and I just expect more from my students. Instead of implementing data structures like we did when I was in school, something ChatGPT is very good at; my students are building systems, something ChatGPT has more trouble with.

Instead of paper exams asking students "find the bug" or "implement a short function", they get a takehome exam where they have to write tests, integrate their project into a CI pipeline, use version control, and implement a dropbox-like system in Rust, which we expect to have a good deal of functionality and accompanying documentation.

I tell them go ahead and use whatever they want. It's easier than policing their tools. If they can put it together, and it works, and they can explain it back to me, then I'm satisfied. Even if they use ChatGPT it'll take a great deal of work and knowledge to get running.

If ChatGPT suddenly is able to put a project like that together, then I'll ask for even more.

That sounds like a feedback control loop. That's the basis of a programming language I'm writing ^_^

The problem with edtech is they make the key mistake of taking the curriculum intended for pen / paper / chalkboard and they just put it on a tablet and expect it to work.

Seymour Papert wrote "Mindstorms" about this very topic in the 80s when PCs were being put in classrooms. Back then, teachers took the multiplication tables they had been doing with pen and paper and just made kids do them on the computer. Teachers make the same mistake with iPads and iPhones. Papert's book talks about the right way to do it -- reformulate the entire concept of learning to include these new tools. Unfortunately, everything gets measured against the old standards, and when the new tools don't work as well to teach the old standards as the tools with which the old standards were designed to be taught, obviously the results are going to look bad.

The first one was great; I still get more traction from the 10 minute video I posted at HYTRADBOI-1 than any talk/paper I've presented at SPLASH. I had more salient questions about Mech than I've ever gotten from SPLASH, VC head hunters setting up meetings, and even Graydon Hoare stopped by for a chat.

What's the point of an online conference? Well you gotta go where your audience is, and for us that's online.

That’s the point — any person sitting on massive wealth is definitionally Smaug-like, because that’s exactly what Smaug did.

> Where's the gradient? Do they fly at the boundary between different wind speeds?

At the surface of the water, windspeed is lower than at higher altitudes, so that's where the gradient is. If you watch an albatross soaring over water, you'll watch it dive so low its wingtip touches the water surface, and then it'll climb in altitude, before turning to dive again. Here's a good diagram of the whole process: https://www.researchgate.net/profile/Sameh-Eisa/publication/...

This is the amazing evolutionary advantage of albatrosses; they fly using a technique called dynamic soaring, which allows them to extract kinetic energy from the wind. It's the same concept really as moving sidewalks in the airport, so their gliding heartrate is about the same as when they're resting on the beach or water. This is what allows them to fly such massive distances across the ocean!

It can work but it depends on the system. One field in which it's very useful is game development. I'm working on a language that has time travel debugging as a feature, so you can rewind a game back to a previous state. I've found it useful when there's a momentary bug that would be hard to recreate. With time traveling, you pause, rewind, inspect state, fix the bug in situ, then resume from that point to check that the behavior is correct.

Here's an example: http://docs.mech-lang.org/#/examples/bouncing-balls.mec

If you want these kinds of features in other systems, they'll have to be architected to support them. For example, the external database will have to be rewound as well. If it doesn't support that feature, then cool language-level debugging features won't be as useful.

Looking at the commit history of the Zig repo, the first commit was in 2016, so that can’t be right; Go hit 1.0 in 2012. Unless maybe it was just being talked about in 2012.

Either way, that’s still pretty new as far as languages go these days, and the bus factor still seems to be 1 or at best 3. There has to be some compelling reason that Zig was the choice here and I’m curious.

Building a new language in a new language (zig) is quite the choice. Usually you choose your host language to leverage some aspect of its ecosystem — whether that be a VM like JVM, or a standard library, or something else.

The other reason would be that writing a language takes time, measured in years and decades. Usually you would pick a well-supported language so that you can be assured it won’t disappear before you’ve finished yours.

I’m only just looking through the project now, but would be interested in finding the author’s rationale for writing this in Zig. Seems like with Zig you wouldn’t get any of this, so I’m wondering why go this direction.

Best use I've found for this is to make sure borrowed a Rc is dropped when you want it to be. Otherwise I've run into "this thing is already borrowed" errors when the runtime decided the thing should still be borrowed by something else.

See my comment about the moon ladder. Progress is nice, and I’m not saying there hasn’t been progress. But there is no indication that the methods of today that work to make taxi cabs in SF drivable will lead to a general-case self driving machine as promised for so many years.

The fact that the two cases that work best have a similar climate to the 2007 DUC really highlights the reality that these methods haven’t been proven to scale generally. The industry is still chasing that 2007 success, and it’s not surprising that over 15 years they’ve improved that. But do I need to link to all the promises from CEOs about where they thought we’d be today? Those predictions were based on the idea that the DUC prototypes would be more generally applicable. The successes since then have shown we can make the experience better, but don’t show we can solve autonomous driving in the general case.

> a large system where the logic just makes itself up as it goes.

What you describe is known as a “bureaucracy”, and indeed, it’s one of the seven levels of hell, and a primary weapon of vogons, next to poetry. That we aspire to put these in our computers, I agree, is unfathomable.

Yes, I do. The point is we didn’t solve the general case, we just learned how to scale the specific case that was demoed in 2007. This is like building a ladder to the moon; it’ll get you closer, but it’ll never get you to the moon.

There’s a parallel with self driving cars. We could make them go around a track autonomously in 2007, and so a lot of people were thinking “how much harder could it be to get this driving anywhere? We will have these everywhere in 5 years!”

15 years later and we are perpetually “5 years out”. Yes you can take a taxi ride in a closed circuit, but that’s much closer to where we were in 2007 than where we thought we’d be today, and it took 15 years to get here.

> Bret Victor has himself been working on the problem for ten years

tbf, he measures the timescale of the Dynamicland project in decades, and marks 2022 as the first time "Dynamicland meets the world" [1]. Seems like he's matching the pace he set for himself, so you really can't say he hasn't had popular success if he hasn't even tried to popularize it yet.

Also tbf, any concept involving "a place where a bunch of people congregate and touch things" has suffered since the pandemic, so I think we can still maintain a "wait-and-see" stance instead of declaring the ideas dead.

[1] https://dynamicland.org

Hi 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.

I'd start here for a quick 10 minute overview: https://www.hytradboi.com/2022/i-tried-rubbing-a-database-on...

Yeah, 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.

I 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.

I helped with the Eve language, which was a VC funded attempt down this path (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 you can play with an early alpha version here: 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.

Do you have a link to your thesis? I'd really like to read it!

GPU/FPGA Mech has been my dream since like... forever. I started taking a crack at it here: https://gitlab.com/mech-lang/core/-/blob/gpu/src/bin/gpu.rs, but mostly I was just figuring out wgpu's capabilities in Rust. But that was months ago and I've since decided to push it off until after I launch what I have done already.

I have a private slack that I've been using to work with my students, I'd love to send you an invite. Send me an email at corey@mech-lang.org and I'll send it to you. I've been putting off doing a discord channel because I wanted to code up a chat app in Mech instead :P I think I'm almost there but I've been thinking that for years >_<. If I don't have one by the time I launch in October I'll probably bite the bullet and do discord then.

Hey, thanks! That's one of the main and crucial differences between Mech and Eve, actually. The main reason I went with tables in Mech is because of the robotics domain. Robotics has a lot of linear algebra and much of the math can be parallelized naturally. This means in Mech we can store columns as contiguous arrays, and take advantage of SIMD optimizations. The triple store in Eve worked well with the whole relational algebra nature of that language, so it was a natural fit there. Not so much for my use case.

Maybe there's room for an Eve-Mech bridge where Eve can be used on the knowledge representation side, and Mech for the lower-level motion planning stuff. That's a fun thought!

They all have their own laptops and prefer to use them. We also don’t have enough money to provide a computer for everyone. But I mean the setup is just one part of the issue, as you note. What I’ve found is I’ve had way more success teaching robotics to younger students via matlab/windows than Linux/ros/c++.