cmontella

Indeed, ROS set out to create an ecosystem of reusable robot software infrastructure, but a monoculture has grown instead.

I started building a ROS alternative called Mech (see my profile) after becoming frustrated with ROS. It’s getting there but not ready for prime time yet.

To answer the sibling comment, my biggest problem with ROS is how inscrutable it is for undergrads. I’ve witnessed students struggle to even install it while following directions step by step. It is a huge mess of incidental complexity, layering the complexity of C++ build systems on top of an IPC system on top of an expansive middleware.

The learning curve is so high that when I spend a semester teaching robotics, students still struggle with ROS basics at midterms. The course turns into more about learning ROS rather than learning actual robotics.

I’m hoping one day Mech will work along side and in conjunction with ROS to provide an easier way of doing things for those who want to get right to the heart of robotics.

> you're only going to invent RSA or blind signatures or zero knowledge once.

Well, maybe. Sometimes things that are discovered are lost or go completely unnoticed, so progress is not always monotonic. For example, for a long time it was believed that John William Strutt first documented dynamic soaring [1] in birds in the 1800s, but just recently (2018) it was found that actually none other than Leonardo DaVinci documented the phenomena in his notebooks centuries before [2]. People just didn't notice or forgot, despite those documents being some of the most poured over in history.

[1] https://en.wikipedia.org/wiki/Dynamic_soaring

[2] https://royalsocietypublishing.org/doi/10.1098/rsnr.2018.002...

You would only have no idea those variables are connected if the tooling for the language can't help you figure that out. Ideally, in such a language you could just query the program state to determine everything that would be influenced downstream. Also step-by-step execution and record/replay or program state can help debug those tricky issues. New paradigms of programming call for new paradigms of tooling and debugging, and figuring out what those are is part of the fun!

I helped build a language like this called Eve: https://github.com/witheve/Eve

It's defunct now, but it was indeed a Turing-complete SQL (but actually relational) with Prolog-like syntax and set semantics. We supported persisting data, and indeed you could think of it as programming within a database. Even though it's not worked on anymore, the last version in the repo worked pretty well IMO. I built a Spotify clone, and even a robot in the language. If you're interested in these ideas, you should give it a shot! Hopefully someone will pick up these ideas and run with them even further.

It's a pretty mind-bending experience to program this way, and I promise you'll have a new perspective on programming as a practice once you grok it (that was common feedback from our users).

I'm attempting to build such a language (you can find a link in my profile if you're interested. I don't want too much attention yet since I'm planning on a first release later in the year). You're right it can become difficult to follow code when it's not presented in a linear fashion. The flip side though is that you can write code in smaller chunks that can do a lot, so you write far fewer lines overall. The other thing is that it opens the door to more advanced tooling than we're used to as developers: things like time travel debugging, saving program state and querying it, or running hypothetical execution paths to find the best one. Bret Victor is famous for demoing prototypes of these debugging tools in one of his talks, and they are finally becoming real.

My language turns out to be very fun to write UIs and games in, so I'm glad you honed in on those two examples. Actually one way to view it is that it's a programming language with a game engine as a runtime. But robotics is the primary application I'm targeting.

In fact I had to choose between lazy and eager evaluation, and I've chosen eager because I want latency guarantees. With a lazy evaluation scheme, I was unsatisfied with the windup that would occur in some situations that would totally blow performance. And we don't have to recalculate everything all the time; we only have to recalculate the paths that have an input change. This may lead to recalculating everything, but most of the time we only have to focus on the execution path that is "dirtied" by the updated input.

Anyway if you want to test drive such a language as you're imagining, send me an email and I'll give you a tour/demo. The language isn't really user-friendly yet so there are some pointy edges that make it unusable to new users at this time (which is the main reason I don't want more attention on it until that is resolved.)

What are your major gripes?

I’m trying to launch a ROS alternative called Mech (github.com/mech-lang). Would be interested to hear what you find lacking in ROS.

> HN readers - do you have an "up and coming" language that you think has better structured the fundamentals from R, that you hope will someday have enough capabilities you can use it instead of R?

Hope is the operative word here!

I'm writing a language to compete in this area. It's called Mech and I'll be releasing the first beta in October. You can think of it like Matlab + Excel. It's very fast, has default-parallel semantics for operators and functions like Matlab, reactive dataflow like Excel, and supports full interactive coding with no startup/compilation latency issues. It's meant for robots, but I've also designed it to be a better Matlab, and I think it should take on R handily. Fair warning, it's public alpha now so error messages are sparse and the happy path is narrow.

https://github.com/mech-lang/mech

Yes that’s the one! It was Chris Granger’s project that Jamie worked on for a while (along with Josh Rob and Eric and myself). Eve came around at a time when Bret Victor’s videos were very popular and a lot of people were unhappy with the state of the web and programming in general.

Since then there’s been a pretty relentless if niche community growing around the idea. Eve is gone but the idea lives on in many different communities, and I think it’s clear the same spirit that spawned Eve motivates Jamie’s conference.

The primary venue for this kind of work has been the Live! workshop at SplashCon.

https://liveprog.org/

There’s also a community of people working on projects of this sort:

https://futureofcoding.org/

I think Jamie’s conference would be a good addition to this community, especially being in the spring, since Live is in the fall.

Sounds like Jamie is starting a conference that would be a good venue for Eves. I think the ethos of Eve was really about rubbing databases on everything and seeing what happened.

This conference really seems to be a future of programming conference moreso than a databases conference. Maybe I'll submit something! Good luck!

Very cool! We ran a competition like this once for undergrads: https://vaderlab.wordpress.com/roscar-robot-stock-car-autono...

It had to be a little more complex than line following, because at one point in the track there are a bunch of line crossings. So you had to do some mapping and tracking too in order to stay in the right lane.

It's really fun seeing how fast you can make them go. One team maxed out the speed on the platform.

That's a good suggestion. I'll do a little makeshift one here :)

Blog posts are mostly here: http://incidentalcomplexity.com and a couple here: http://www.chris-granger.com

Talks:

https://www.youtube.com/watch?v=2_4ecWDohnk

https://www.youtube.com/watch?v=5V1ynVyud4M

https://www.youtube.com/watch?v=DShccXxyiAY

https://www.youtube.com/watch?v=VZQoAKJPbh8

https://www.youtube.com/watch?v=a_o-ZzgpiK8

Prototypes are collected here:

https://github.com/witheve/eve-experiments

I'll try to make this nicer and put it on our homepage.

Ha touche. Although I would say my ceiling is just the inside part of my roof :P

I guess it depends on how your house is made.

> ceilings are useless for the most part

I would say they are underutilized. Ceilings are certainly useful for preventing rain from falling on our heads ;)

I took a couple courses by Baird at Lehigh before he retired. He used to teach "Pattern Recognition" as it was called before "Machine Learning". His approach was decidedly old school, but really that was the whole point; a lot of the trends in computing are cyclic, and if you focus on the fundamentals you have context for where new trends fit in.

One of his biggest take-aways in building systems like the one in the linked paper was the need for layered understanding. For example, to understand the meaning of a passage of scanned text, you can't just look at each individual letter of the text. There is ambiguity in characters like l and I or 0 and o and O. To remove that ambiguity, you bring in more context by looking at a character in a word. Then a word within a sentence. Then a sentence within a passage. This is how they were able to build highly accurate systems without massive amounts of training data.

Now that I'm on a roll recollecting the teachings of Henry Baird I will add two more:

1) There is a difference between an algorithm and a heuristic that is often overlooked these days: algorithms are provably correct. If you can't prove it's correct, then it's a heuristic. By this measure, there are very few algorithms out there, because there are very few proofs of correctness. Most likely, anything you've ever called an algorithm that you've written yourself is actually a heuristic.

2) Because of the above, Baird was very fond of KNN classifiers, because they are one of the few classifiers that have any sort of provable guarantees -- namely that with infinite data, the error rate is guaranteed to be no worse than 2x the Bayes error.

FYI there is a typo in the application:

"Do you generate direct program revenue or does it comes from donors? If both, what's the split?"

comes -> come

As someone who writes programming languages, let me tell you that people who do so don't do it to get rich. We do it because we see great inefficiency in the world of systems that needs to be corrected. It's like people who are social justice activists. They're not getting rich either, but they're doing what needs to be done.

> They are saying it is the driver's fault because he put too much faith into the autopilot system.

Any faith the driver had in Tesla's autopilot system would be due to Tesla's marketing. If Tesla believes its self driving capabilities are not quite ready for market, maybe they shouldn't be selling it and calling it an "autopilot".

> Why did you have to memorize everything? I have also done x86 assembly. You remember what you can. You look up the rest. Same today.

Looking stuff up took a lot longer then. It's the difference between firing up a search engine and typing words versus getting in your car, driving to the library, finding parking, walking to the door, finding the card catalog, finding the right card in the catalog, finding the right stack, finding the book on the shelf, scanning the book index, then finding the right page in the book. Memorizing had a better payoff back then.

Or think of it another way: looking stuff up today is like accessing L2 memory, and back then it was like a cache miss, where you had to take a trip out to disk before you could continue useful work.

The output of most programs is plain data -- an integer or text or something. If the output is wrong, it would be interesting for debugging purposes to trace how a particular output was generated, in order to figure out where exactly the program went wrong. This information is what people mean by the "provenience" of data.

Yeah, no doubt that tech will help you. But the line from a robot carrying your guns to a robot wielding your guns is a little too direct for me.to work on personally. It's not that I think you are bloodthirsty. I think the people you work for are.

> Sigh. Hacker News is a suspicious place these days. We have no rights to anything you produce, or datasets you use. We just want to help budding scientists.

It's not HN, it's the world. We live in a society where you have to beg and scrape for healthcare and a job and shelter. Then when you have it, the only way for most to keep it is to sell their labor to a corporation, who doesn't pay you for what it's actually worth (they take a profit). Then, when you go home to improve you life on your own time, the corporation tries to claim ownership over your ideas you work on in your spare time.

What you're proposing, "no strings attached" is counter to almost every expectation we've had our entire lives regarding "a free lunch". i.e. there's no such thing.

> IQ is highly heritable many in the 1% tend to be intelligent as well so the rich get richer.

I'm sorry, do you have a citation for this? I find this highly suspect. Everything I know about money and power and society suggests the reasons the rich get richer are money, power, and society. Nothing to do with IQ. This idea that the poor are poor because they are dumb is something rich people (who don't want you to be rich) want you to believe.

Reminds me of Frank Herbert's "Dune", where the greening of the desert was viewed as ecological destruction (and more), as it destroyed the habitat of the worms.

This reminds me of the movie "Cube", which is about a sadistic torture chamber built by accident through a network of government sub-contractors who each built some innocuous part of the thing, which was then assembled through layers of opaque bureaucracy. It's a terrible film, but I always thought that premise was hilarious.

https://en.wikipedia.org/wiki/Cube_(film)

As a roboticist at the beginning of my career working on drones, I decided then and there that I would never make "bombs", a metaphor I used to mean anything that could be weaponized. I realized a lot of the work I was doing was funded by DARPA, and I was very cognizant about my research being used in this way. And like Dr. Kearns suggests, it's not entirely black and white. Would my path planning algorithm be used to more efficiently deliver scientific payloads to the atmosphere, or would it be used to route missiles to maximize casualties? Hard to really say, but I've avoided overtly military applications (even things like BigDog, designed to carry equipment for troops).

Sometimes the distinction is even more insidious. I did work on perpetual flight for drones, and Facebook had a perpetual flight project that had the goal of bringing internet access to remote locations in Africa. Sounds humanitarian, but I also didn't want to be responsible for subjecting poor Africans to what I consider Facebook's panopticon. Or maybe it would have been a net boon for the region? It's really hard to tell a priori, so the best I have managed for myself is just to try and stay in theory, where developments are further removed from direct consequence.

I left a PhD program to join Eve, so I'm going to finish that and join academia to continue this research. I'm working to bring some of the ideas I learned from working on Eve into my own project called HiveMind, which in an OS written in Rust and an Eve-like language I call Mech: https://gitlab.com/cmontella/hivemind You can think of it like baremetal Eve.

In all three you manipulated your code directly (instead of indirectly through text or other interfaces).

In five square you worked with tables, and programming felt like exploring a database. You just created different tables of data and then filtered and joined them in a graphical way, then bound the result to an interface. In the end, we had a working fivesquare clone without writing a line of code, that could be built in a day or two from scratch.

In Wikieve, data was presented as card, or wiki pages that you could edit. With some clever tweaks, you could ge a working program out of this, but it felt more like managing a wiki.

Smalltalk Eve was more geared toward graphical applications, so a lot of neat things could be accomplished just by adding simple actions to objects on the screen. I had built a kinect application that allowed you to steer the wheels of a robot car using your hands, again without coding anything.

So direct manipulation of code and the ability to see your results immediately, and to progressively change them are the properties that made these versions good.

> And they both have one thing in common: only code or only data is visible most of the time (or by default)!

This is true, but one of the the biggest source of errors in spreadsheets arises from the inability to see code, and one of the biggest source of errors in regular code is the inability to see and record the data flow.

In Eve, technically you still could only interact with data, because code was treated as data too. We still had a lot of work to do in figuring out an interface for working with programs built in this manner.

> we want things hidden away 99% of the time, and we want to be spared from the paralyzing effect of endless choice that allowing us to interact with everything would cause.

I agree with you here, and this is one of the things we kept in mind when designing and building Eve. We likened it to having lego parts bucket on the floor. Sure, everything you need is right there, but the vast design space available to you limits your ability to work. But what if we could show you only the parts that were applicable at the current time. Or show you only the parts that would fit a certain spot. We could do this with Eve, because we kept information the compilers throw away and made it available (and added to it) during program execution.

This of course was never fully realized.

Experiments are collected here: https://github.com/witheve/eve-experiments

The way it's broken out in this repo corresponds closely to how this blog is presented. Earlier prototypes like Aurora aren't included here though.

So the US has a lower rate when you conveniently exclude a segment? Is that because you think suicide doesn't count because it's self inflicted? Would it surprise you to know many people who attempt suicide and survive later regret it, and many suicides could have been averted if a firearm wasn't readily available. I know a lot of people think someone who wants to kill them self can do so no matter what, but that simply isn't the case.