Speaker 1: How'd you like to listen to. NET Rocks with no ads? Easy.
Speaker 1: Become a patron. For just $ 5 a month, you get
Speaker 1: access to a private RSS feed where all the shows
Speaker 1: have no ads. $ 20 a month will get you that
Speaker 1: and a special. NET Rocks patron mug. Sign up now
Speaker 1: at patreon.dotnetrocks.com. Hey, and welcome back to. NET Rocks. I'm
Speaker 1: Carl Franklin.
Speaker 2: And I'm Richard Kaplan.
Speaker 1: Our friend Don XML, I mean, Don Demsack is here.
Speaker 3: Oh, jeez.
Speaker 1: Or is he Don Jason? Are you Don Jason now?
Speaker 4: That's my brother.
Speaker 2: At least he didn't say Don Yammel. God knows. No.
Speaker 5: No.
Speaker 1: This is going to be a good one. This is
Speaker 1: episode 2018. And as we always do at the top
Speaker 1: of the show, let's talk about things that happened that year.
Speaker 1: I get all the depressing ones and Richard gets all
Speaker 1: the happy ones in space and tech.
Speaker 2: Just have to pick carefully.
Speaker 1: Yeah, I guess so. But, you know, these are important events, right?
Speaker 2: Are they?
Speaker 1: School shootings.
Speaker 2: Are they?
Speaker 1: Robert Mueller's Russia investigation.
Speaker 2: Oh, yeah.
Speaker 5: Well.
Speaker 1: Brett Kavanaugh, Supreme Court confirmation battle.
Speaker 4: Yeah.
Speaker 1: The 2018 midterm elections when the Democrats took over. The
Speaker 1: Democrats strike back. Did they?
Speaker 5: Okay.
Speaker 1: Well, okay.
Speaker 2: I don't know.
Speaker 1: Trump and Kim Jong-un, still crazy after all these years.
Speaker 4: Nice.
Speaker 1: Still friends.
Speaker 2: I think that was one of the first meetings, wasn't it?
Speaker 4: Yeah, yeah.
Speaker 1: June 12th in Singapore. Jamal Khashoggi, as Trump said, these
Speaker 1: things happen. He was killed and dissolved in a bathtub
Speaker 1: of acid.
Speaker 2: Or something.
Speaker 5: Okay. Okay.
Speaker 1: Or something. That's what we think. California wildfires happens every year,
Speaker 1: but 2018 was particularly bad. The Me Too movement and
Speaker 1: the Larry Nassar scandal. And just to put a little
Speaker 1: fine point on it, hurricanes Florence and Michael.
Speaker 3: Right.
Speaker 2: Those are good ones.
Speaker 1: Catastrophic flooding in the Carolinas.
Speaker 2: Yeah.
Speaker 1: And the Florida panhandle. All right, Richard. That's enough.
Speaker 2: Well, it was also, remember that cave rescue in Thailand? Oh, yeah.
Speaker 2: Those students went in and there was the flash flood.
Speaker 2: That's when that happened.
Speaker 1: That was a good story.
Speaker 5: It was.
Speaker 2: I mean, one of the rescuers lost their lives trying
Speaker 2: to save those kids. Right. But they were successful. Do
Speaker 2: you remember when, I think that's when Elon started going crazy. Yeah.
Speaker 2: Remember he really wanted to be involved in that. It's like,
Speaker 2: you're not actually qualified. I'll build a submersible. It's like, A,
Speaker 2: you don't know how to build a submersible. And B,
Speaker 2: that's not going to work in a cave either. And
Speaker 2: then he got really snarky and started calling people pedophiles
Speaker 2: and things. Yeah. I don't know. It was one of
Speaker 2: those moments because this is the same year that the
Speaker 2: Falcon Heavy flies for the first time and Elon put
Speaker 2: his red Tesla Roadster on top of it as the payload,
Speaker 2: which was pretty cool.
Speaker 1: I thought that was the cool Elon doing that.
Speaker 2: Yeah. But it's interesting to think that's the same year
Speaker 2: he goes nuts on this cave rescue thing so i
Speaker 2: mean things are just getting.
Speaker 1: Weirder and weirder yeah weirdness weirdness abides um also i
Speaker 1: want to mention aretha franklin and anthony bourdain died in
Speaker 1: 2018 yeah very sad also paul allen very sad about
Speaker 1: have you there's a new movie like a documentary about anthony.
Speaker 2: There's an anthony bourdain movie coming out imminently yeah so
Speaker 2: it hasn't come out yet I think it's just out
Speaker 2: brand new. Okay.
Speaker 1: Yeah. I want to see that.
Speaker 5: Yeah.
Speaker 1: Also George H.W. Bush and John McCain died. Yeah.
Speaker 2: All right, Richard, save us from this misery. So I
Speaker 2: mentioned the Falcon heavy flight, which, yeah, that was pretty cool.
Speaker 2: We ended up doing a geek out about it. I mean,
Speaker 2: it was just an extraordinary rocket strapping three side by side.
Speaker 2: Originally he had planned on doing something called asparagus staging,
Speaker 2: where he was actually going to feed the fuel from
Speaker 2: the wing of boosters into the center so that when
Speaker 2: the outer boosters were empty and separated, the center booster
Speaker 2: would be completely full. Never happened. Instead, they do it
Speaker 2: the simpler way, which is simply to throttle down the
Speaker 2: center booster so it doesn't burn as much fuel. That
Speaker 2: being said, Falcon Heavy, you'd be never real happy with
Speaker 2: it The simple reason that it has a lot of power,
Speaker 2: but it doesn't have a lot of payload space. And
Speaker 2: so there's relatively few cases where it's needed. And he
Speaker 2: was already talking about what we now know is Starship, uh,
Speaker 2: and starting to do prototypes around all of that. Uh,
Speaker 2: we have a lot of cool, uh, satellites up in 2018,
Speaker 2: starting with tests, the transiting exoplanet survey satellite. So this
Speaker 2: was the only, the third of the dedicated finding exoplanet
Speaker 2: satellites that the, the successor of Kepler. Kepler had launched
Speaker 2: back in 2009 and found 2,600 exoplanets. That was Kepler's
Speaker 2: mission was to do deep surveys to see how common
Speaker 2: are planets. And the answer is very common. Most stars
Speaker 2: have planets. TESS as a survey satellite is not designed
Speaker 2: to observe as closely, but to cover much larger tracks
Speaker 2: of the sky. And fast forwarding eight years now, it's
Speaker 2: found over 8,000 potential objects that generally need additional surveying.
Speaker 2: because it is a survey spacecraft. But of those 8,000,
Speaker 2: almost 1,000 have not been confirmed as exoplanets. So if
Speaker 2: you're keeping count, we're up around 6,300 confirmed exoplanets so
Speaker 2: far from all of our different collection methodologies. This is
Speaker 2: not how Star Trek was supposed to work. Remember in
Speaker 2: Star Trek, you had to fly to the solar system
Speaker 2: to see the planets? No, we're going to have a
Speaker 2: map of all of them long before we can get
Speaker 2: to any of them. There's a couple of asteroid missions.
Speaker 2: Hayabusa 2 in June got to Rigu. And in December,
Speaker 2: OSIRIS-REx gets to Bennu, which is cool. We start to
Speaker 2: explore asteroids sort of on a regular basis. In August,
Speaker 2: the Parker Solar Probe, the first time we've ever tried
Speaker 2: to fly a satellite to the sun. to actually do
Speaker 2: measurements of its outer atmosphere. That's a very difficult thing
Speaker 2: to do. You have to go really, really fast to
Speaker 2: do that.
Speaker 1: Remember Richard Pryor's bit, the first man to walk on
Speaker 1: the sun?
Speaker 4: Ooh, ah, ah, ooh, how?
Speaker 2: So to make the solar probe go fast enough to
Speaker 2: get that close to the sun, they launched on a
Speaker 2: Delta IV, which is one of the highest performance rockets
Speaker 2: ever made. It's largely obsolete now and retired and broke
Speaker 2: a bunch of speed records to try and get it
Speaker 2: down there. It'll take a while to actually get close
Speaker 2: enough and actually start to do sampling of the sun.
Speaker 2: Also in August was when on the International Space Station,
Speaker 2: Soyuz MS-09, this is the vehicle that they transport astronauts
Speaker 2: to and from the space station, which at that time,
Speaker 2: because the shuttle is no longer flying and Crew Dragon
Speaker 2: doesn't exist yet, it's still in development, was the only
Speaker 2: way to get to the station. They find a two
Speaker 2: millimeter hole in the orbital module of the Soyuz. And
Speaker 2: there was a lot of controversy about whether it was
Speaker 2: drilled because it was sort of a perfect hole or
Speaker 2: was it just that right hole? you know, penetrator that
Speaker 2: it went through there. Anyway, fixed with a piece of
Speaker 2: cape on tape.
Speaker 1: Could have been mice.
Speaker 2: You know, and because it was the Orbridge module, it
Speaker 2: doesn't have to survive re-entry, so it's not that big
Speaker 2: of a deal. But yeah, it kicked up a lot
Speaker 2: of speculation. And if that wasn't enough, the very next
Speaker 2: Soyuz in October, this is Soyuz MS-10, it was only
Speaker 2: carrying two passengers. Normally, the Soyuz can carry three, but
Speaker 2: occasionally fly with less. In this case, it had Alexei Ovichin, And, uh,
Speaker 2: from Roscosmos and Nick Hague from NASA, they were going
Speaker 2: to be part of the exhibition 57 to the international
Speaker 2: space station. But two minutes after launch, there was a failure.
Speaker 2: And Soyuz is one of the most reliable, most flown
Speaker 2: spacecraft of all time.
Speaker 1: Yeah.
Speaker 2: This was one of the very rare failures and it
Speaker 2: was a failure that had never occurred before. There was
Speaker 2: something wrong in the sensor of one of the strap-on boosters.
Speaker 2: There are four strap-on boosters that famously separate from a
Speaker 2: Soyuz and do what they call the Korolev cross. As
Speaker 2: they come flying off. And it didn't happen this time.
Speaker 2: And the one booster hung up. And then when it
Speaker 2: did break away, it struck the central booster core. And
Speaker 2: that ended the going into space. As Nick Hague said,
Speaker 2: as soon as the bouncing around started, I guess we're
Speaker 2: not going to the space station. But at this point,
Speaker 2: they're already 50 kilometers up. And that's too high for
Speaker 2: the escape tower. So it's already been ejected. But there is...
Speaker 2: Mode 2, Ascent Abort, a system that had been tested
Speaker 2: but never used. And this was the first and only
Speaker 2: time it's ever been used.
Speaker 1: So they basically turned it around and re-entered?
Speaker 2: It's more complicated than that because you've got an exploding
Speaker 2: rocket behind you, so you don't want to be near that.
Speaker 2: So instead of abort motors fire and push the Soyuz
Speaker 2: assembly away from the booster, and then you have to
Speaker 2: get into... descent mode because you're carrying the propulsion module
Speaker 2: as well as descent module and the orbital module so
Speaker 2: those each have to be pushed off and then it
Speaker 2: has to switch over to descent mode get the heat
Speaker 2: shield pointed down and actually land because of the angle
Speaker 2: of ascent they only get to about 90 kilometers so
Speaker 2: they spend some time in free fall still going up
Speaker 2: the explosion happened.
Speaker 1: At 50 dude you should make movies This is great.
Speaker 2: It's crazy.
Speaker 1: It's like I'm on the edge of my seat.
Speaker 2: And they're in free fall, and now they have to reorient,
Speaker 2: and they do a ballistic return, which means those poor
Speaker 2: guys pulled about seven Gs as they came back down.
Speaker 2: Worked perfectly. Both astronauts walked away. The crazy part is
Speaker 2: realizing from launch at Balkanur to on the ground about
Speaker 2: 200 kilometers downrange in Kazakhstan, 19 minutes.
Speaker 4: Oh, my God.
Speaker 1: Goodness.
Speaker 2: It was fast and it's all automated. Like basically they
Speaker 2: were having trouble keeping up with the control systems working
Speaker 2: through it.
Speaker 1: That's definitely not enough time for a feature film.
Speaker 2: No, it's pretty quick, but I'm sure there's a bit
Speaker 2: of story to go around it. Anyway, it worked flawlessly.
Speaker 2: and they would eventually get to space on a different
Speaker 2: spacecraft because that one weren't no good no more. In November,
Speaker 2: we have the 20th anniversary of the International Space Station
Speaker 2: because the Zarya module went up in 1998. We're also
Speaker 2: fully over into commercial resupply now. So Roscoff's mostly due
Speaker 2: to five deliveries in 2018. But SpaceX does three on
Speaker 2: Cargo Dragon. Orbital ATK does three with Cygnus. And JAXA
Speaker 2: has one HTV delivery. So a total of, what is that, 12.
Speaker 2: And also in November, the InSight lander lands on Mars.
Speaker 2: First thing to have landed on Mars since Perseverance. And
Speaker 2: it's doing measurements of Mars quakes and interior mapping of Mars.
Speaker 2: by looking at reverberations that travel through the planet. And finally,
Speaker 2: in December, China launches the Chang'e 4 relay satellite in
Speaker 2: preparation for their landing, putting a lander and rover down
Speaker 2: on the far side of the moon. They need a
Speaker 2: satellite to be able to communicate with the far side
Speaker 2: of the moon. So that goes up in 2018. The
Speaker 2: big mission will be in 2019. Ready for compute stories?
Speaker 1: Yes.
Speaker 2: And you always think I have to give you all
Speaker 2: the good news. So let's start off in January with
Speaker 2: Meltdown Inspector. Okay.
Speaker 1: Okay.
Speaker 2: So these were discovered potential exploits using a speculative execution
Speaker 2: that exists in both AMD and Intel processors. And there
Speaker 2: was no security around that. So the theory was that
Speaker 2: if you did stuff exactly right, you might be able
Speaker 2: to grab data from another virtual machine that was running through.
Speaker 2: This exploit has never been found in the wild. Even
Speaker 2: attempts to try and utilize it have been largely futile.
Speaker 2: But at the time, they really freaked out. And putting
Speaker 2: security rules in place caused substantial performance penalties. I think
Speaker 2: to talk about literally 20% of available compute disappeared to
Speaker 2: fix spectrum and meltdown.
Speaker 1: Not good.
Speaker 4: Remember that?
Speaker 1: Wow.
Speaker 2: And adding to my, I don't only have good news
Speaker 2: stories in 2018, Google officially removes their don't be evil
Speaker 2: from their code of conduct. I mean, they didn't add
Speaker 2: be evil, but they just took out the don't be.
Speaker 2: And then in March, uh, The Cambridge Analytica scandal. Oh, yes.
Speaker 2: Where Cambridge Analytica had mined Facebook data in a way
Speaker 2: that not even Facebook had thought about and was very
Speaker 2: effective at doing things like creating ads for individuals where
Speaker 2: the individual didn't realize they're the only ones seeing the ad.
Speaker 2: A very effective strategy for getting a group of English
Speaker 2: people to vote against their best interests and exit the EU.
Speaker 1: Now we have Facebook and nobody cares.
Speaker 2: There you go. Yeah.
Speaker 1: Targeted ad.
Speaker 2: And in April, Belgium declares... video game loot box systems
Speaker 2: to be gambling and illegal for minors, which it is.
Speaker 2: I don't disagree with them. Interesting problem. Yeah. Don't manipulate children, please. Well,
Speaker 2: not too heavily. And then in May, the GDPR is enacted.
Speaker 2: It's been in development for a few years. This is
Speaker 2: why you have to keep agreeing to cookies as well
Speaker 2: as a bunch of other things like the right to
Speaker 2: be forgotten and serious fines for not being forthright with breaches.
Speaker 5: Yeah.
Speaker 2: Um, over on the Microsoft side of things, it may,
Speaker 2: we have build 2018, which ships.net core 2.1. But also,
Speaker 2: and I realized this in hindsight, when I was putting
Speaker 2: this together is sort of the first wave of AI stuff.
Speaker 2: Remember visual studio and telecode? I think we did a
Speaker 2: show on it.
Speaker 4: Yeah. Yeah.
Speaker 3: Yeah.
Speaker 2: Where it wasn't an, you know, we're really talking about having,
Speaker 2: helping to generate code for testing and things. It's also
Speaker 2: the year they ship ml.net machine learning.net for, for doing
Speaker 2: models that way.
Speaker 5: Right.
Speaker 2: And certainly last but not least, for the build announcements,
Speaker 2: one of the ones that I jumped over was Azure Sphere.
Speaker 2: Do you remember this? This is when Microsoft starts building
Speaker 2: their own flavor of a Linux operating system for IoT.
Speaker 2: It's subsequently been phased out now, but for a few
Speaker 2: years here, it's like, Microsoft makes their own Linux. I
Speaker 2: love that.
Speaker 5: Mm-hmm.
Speaker 2: Later in the year, in October, well, actually it was
Speaker 2: announced in June, but completed in October, Microsoft acquires GitHub
Speaker 2: for $ 7. 5 billion. And our friend, Nat Friedman, formerly of Xamarin,
Speaker 2: now a Microsoft employee, becomes the new CEO of GitHub.
Speaker 2: We get Core 2.2 at the end of the year
Speaker 2: in December. Yeah.
Speaker 4: A couple other compute stories.
Speaker 2: This is the year that Elon Musk attempts to take
Speaker 2: over OpenAI from his partners and gets booted out of it.
Speaker 2: And he's still angry about that and purse fights with
Speaker 2: Sam Altman on regular basis.
Speaker 1: Yeah, because... That's where he is right now.
Speaker 2: Because reasons, because I realized all the same, the same
Speaker 2: year that he flies the biggest rocket in history into
Speaker 2: space and puts a sports car into space, which still orbiting,
Speaker 2: you know, between the earth and Mars also, you know,
Speaker 2: call some guy trying to save children in Thailand, a pedophile, uh,
Speaker 2: also tries to hijack the AI company. Yeah. Uh, We're
Speaker 2: coming into the period of excitement as we're going through
Speaker 2: these next few years in quantum computing. And in 2018,
Speaker 2: there was a very important paper published, the NISC paper,
Speaker 2: which means Noisy Intermediate Scale Quantum, this paper by John Preskill.
Speaker 2: This is the point where companies are starting to build qubits,
Speaker 2: build these chandelier dipped in liquid helium style computers that
Speaker 2: have about 50 qubits or so forth. And in this paper,
Speaker 2: he talks about it's all going to be about error correction.
Speaker 2: that we're getting out of the lab. These things are
Speaker 2: going to be able to do certain levels of compute,
Speaker 2: but without really fault tolerance in this, you're not going
Speaker 2: to be able to get much done. And that sets
Speaker 2: up Google, who's driving a lot of this stuff with
Speaker 2: their quantum toolkit, aimed at researchers for testing what prototype
Speaker 2: hardware could do, which is funny because next year they'll
Speaker 2: actually produce the second market process. So obviously Google was anticipated.
Speaker 2: And that's what I got.
Speaker 4: All right.
Speaker 1: Well, before we bring Don on, let's talk about Better
Speaker 1: Know Framework. Roll the music.
Speaker 5: Awesome.
Speaker 3: All right, man.
Speaker 1: What do you got? Guess who's back in Better Know Framework?
Speaker 2: I think I know. He's Australian. It's Simon.
Speaker 4: It's Simon.
Speaker 1: So he belongs to our Appfee Next Slack channel. And
Speaker 1: he basically knew that I had done some work into
Speaker 1: looking into serializing link queries and passing them from client
Speaker 1: to server and pretty much gave up. And there was
Speaker 1: a whole smattering of GitHub repos out there of people
Speaker 1: who attempted it. And I tried like 50% of them
Speaker 1: and they all failed. And so he came up with
Speaker 1: this thing called SCRY, S-C-R-Y, or maybe it's SCARY. I
Speaker 1: don't know.
Speaker 2: Or Scree.
Speaker 1: Or Scree?
Speaker 4: Yeah.
Speaker 1: He doesn't have a pronunciation legend, but he says it's
Speaker 1: a type-safe serializable link from a client to a server
Speaker 1: side EF core model. And I had told him, and
Speaker 1: both Mateus Carvalho and I had worked on this before,
Speaker 1: and Mateus came up with something, and I came up
Speaker 1: with something, AVN repository, that basically tells Did the same,
Speaker 1: but I used classes and serialized those classes for filtering
Speaker 1: and basically all aspects of a SQL query, a link query, right?
Speaker 1: A where, an order by, all of that stuff just
Speaker 1: turned into data and passed in.
Speaker 2: And it works.
Speaker 1: But as Simon pointed out, it's not as efficient as
Speaker 1: what he's doing. Yeah. So this is, and he has a,
Speaker 1: there's two links. We're going to give you a link
Speaker 1: to the scary or the scry or scree project. And
Speaker 1: then there's this doc querying MD composing a query at runtime.
Speaker 1: And so he just talks about how to do that,
Speaker 1: how to create projections and computer projection members. It's really cool. And,
Speaker 1: and it works interesting.
Speaker 2: And so, yeah.
Speaker 1: And, and so, yeah. Um, Simon, you win the prize.
Speaker 2: You're awesome.
Speaker 1: You're the first person I know who has actually done this.
Speaker 1: And maybe I just resigned and said, I can't be done.
Speaker 1: And maybe it was done, you know, long before that.
Speaker 2: I don't know.
Speaker 4: But that reminds me of link to rest.
Speaker 1: Oh, link to rest. Well, that sounds exactly like what
Speaker 1: I was doing.
Speaker 2: Yeah. Yeah.
Speaker 4: Because it was the inverse.
Speaker 3: Right.
Speaker 4: Where you, well, you created from a link query, you
Speaker 4: could create a query string.
Speaker 3: Right.
Speaker 1: But you couldn't put it back on the other side
Speaker 1: and turn it into a link query, which is, which
Speaker 1: is what he's doing. And what I wanted to do
Speaker 1: as well, right? Because you've got a form and it's
Speaker 1: got a whole bunch of search parameters. And if your
Speaker 1: data is local, great link query.
Speaker 4: Well, no, so it did it the other way too.
Speaker 1: If it's behind an API.
Speaker 4: Link to REST, it would, it was an ASP.NET. It
Speaker 4: was NBC, ASP.NET. It would, take that query string and
Speaker 4: then turn it into a link.
Speaker 1: Oh, okay. Well, that's great. Link to rest, rest to link. Okay. Well,
Speaker 1: check out scary or scree or scry or whatever it is.
Speaker 1: And ask Simon how to pronounce this thing.
Speaker 2: Cause I don't know.
Speaker 4: I'm sure there's a difference, but yeah.
Speaker 5: Right.
Speaker 4: I just remember link to rest.
Speaker 1: Well, Richard, who's talking to us today?
Speaker 2: Grabbed a comment off show 1994, the one we did
Speaker 2: with our friend Brady Gaster, talking about Squad. A lot
Speaker 2: of good comments on that show.
Speaker 3: Yeah.
Speaker 2: And this one comes from Paula Pinto, who says, while
Speaker 2: interesting as always, the whole Squad enthusiasm was pretty much
Speaker 2: focused on single developer workflow. Now not having to depend
Speaker 2: on anyone else to do related development tasks. It was
Speaker 2: all about their nicknamed agents without any ethical discussion of
Speaker 2: what tooling like Squad will have in developer teams. I've
Speaker 2: already observed how teams have been downsized. Thank the SaaS
Speaker 2: products for placing the need for backend developers, AI tooling
Speaker 2: doing the work of team members that used to do
Speaker 2: translations or asset creations for CMS platforms. Now we get
Speaker 2: tools like Squad reducing even further the amount of humans
Speaker 2: in the loop, getting celebrated for what a single developer
Speaker 2: could choose while taking into account the repercussions it has
Speaker 2: on those that are deemed no longer needed to be
Speaker 2: kept around as employees.
Speaker 1: Unless you didn't have a team to begin with.
Speaker 2: In a late capitalism-driven society, if $ 5 can do what...
Speaker 2: work of 20 developers thanks to tooling like squad the
Speaker 2: remaining 15 are out of the company like an old
Speaker 2: detroit they will need to find work that isn't yet taken.
Speaker 1: By ai unless you didn't start with a team yeah
Speaker 1: you were always one guy.
Speaker 2: But i also think it's kind of a short-sighted mindset
Speaker 2: too because i'm seeing more nobody team's not getting laid
Speaker 2: out but just working on the other stuff they hadn't
Speaker 2: gotten to like the joke for years was none of
Speaker 2: us would get to the bottom of our to-do list
Speaker 2: And now we're getting through the feature lists and starting
Speaker 2: to get into tech debt. And then other features start
Speaker 2: to appear. It's only the shortest-sighted of companies that would
Speaker 2: work on one thing and not think, what are the
Speaker 2: other things we could do? You've got a group of
Speaker 2: people who are now more powerful. Utilize them.
Speaker 1: You take all those people on the team, give them
Speaker 1: all a unique task, give them their AI tools. And
Speaker 1: set them free. And before you know it, you're through
Speaker 1: all of those things.
Speaker 5: Yeah.
Speaker 1: Technical debt's a big one.
Speaker 2: I also think there is a larger conversation about what
Speaker 2: the shape of teams looks like with these tools going forward. Right.
Speaker 2: We're still in early days.
Speaker 4: I've been running into folks who, in the startup community,
Speaker 4: are saying they don't need developers anymore.
Speaker 2: Yeah. That doesn't seem true.
Speaker 4: Somebody I ran into, he just came back from two
Speaker 4: weeks of a startup incubator, and he was saying, Of
Speaker 4: the 20 or so startups there, none of them had developers.
Speaker 3: Yeah.
Speaker 4: Right.
Speaker 1: That's easy to understand.
Speaker 2: Sure. All right, Paulo. Thank you so much for your comment.
Speaker 2: And a copy of Music Code Buy is on its
Speaker 2: way to you. And if you'd like a copy of
Speaker 2: Music Code Buy, write a comment on the website at. netronics. com
Speaker 2: or on the Facebooks. We publish every show there. And
Speaker 2: if you comment there and I read it on the show,
Speaker 2: we'll send you a copy of Music Code Buy.
Speaker 1: Or you could just go to musictocodebuy.net and get it yourself. MP3, WAV,
Speaker 1: and FLAC formats. Go ahead. You know you want it.
Speaker 1: All right, let's bring on Don Demsack. Don is a
Speaker 1: technology leader dedicated to strengthening the tech ecosystem in Central
Speaker 1: Pennsylvania and beyond. His day job is with a major
Speaker 1: technology company's infrastructure group where he helps CIOs and CTOs
Speaker 1: think like COOs. His nights and weekends go to volunteering
Speaker 1: as a board member of the Technology Council of Central
Speaker 1: PA and as an active member of Tech Lancaster. You
Speaker 1: can find his latest ramblings over on Substack. This is
Speaker 1: his fourth trip to. NET Rocks and the first in
Speaker 1: almost 20 years.
Speaker 2: It's been too long.
Speaker 1: Dude, I remember your first episode. It was during the
Speaker 1: Rory years. So it's episode 62. Rory years were 50
Speaker 1: to 100. And he somehow convinced you to come up
Speaker 1: to the studio. And you were there in the studio
Speaker 1: for us, with us.
Speaker 4: Yep. And you remember.
Speaker 1: Richard Roy used to do the Google weirdos thing.
Speaker 5: Right.
Speaker 1: So just for people who don't remember, he would look,
Speaker 1: he had a blog, popular blog, neopolian.com. And it was
Speaker 1: hysterical and very, very surreal. And he took it down
Speaker 1: because he, he wanted to be taken more seriously as
Speaker 1: a developer and everybody just wanted comic relief, but he
Speaker 1: was very funny. Anyway, he would look at the logs and,
Speaker 1: of what people typed into Google and then landed themselves
Speaker 1: on his blog, right? He could tell that it came
Speaker 1: from Google and the string is in the log, right?
Speaker 4: The URL.
Speaker 1: And so he would read these and they were just crazy,
Speaker 1: what people were looking for. But one of them, and
Speaker 1: I remember this specifically, Don, tell Don XML to come
Speaker 1: home and take out the garbage.
Speaker 4: You just made my wife's week. That is exactly. Make
Speaker 4: sure Carl brings that up.
Speaker 1: Oh, well, how could we not?
Speaker 2: I mean, it's crazy.
Speaker 1: But yeah, you used to be Don XML. And then
Speaker 1: I think by your third episode, which was 271, it
Speaker 1: was Don Demsack on Link to XML.
Speaker 4: Yeah. And who did the session before Mike? Do you remember?
Speaker 2: Uh, two 70 to 70.
Speaker 1: Let's see. I got the list right here.
Speaker 2: It's funny. It's all online. That's weird.
Speaker 4: Yes, it is. I can tell you.
Speaker 1: No, I got it right here. It was Eric Meyer,
Speaker 1: Eric Meyer.
Speaker 2: Oh, why the Eric Meyer on link on link? Yeah.
Speaker 2: The guy who helped create it.
Speaker 1: Something he knows a little thing about.
Speaker 3: Yeah.
Speaker 4: Just a little. Um, if you haven't, he, or, uh,
Speaker 4: been paying attention to him, uh, He recently has a
Speaker 4: video up on YouTube of a presentation.
Speaker 2: AI.
Speaker 4: Engineering, around how AI agents got teeth once we allowed
Speaker 4: them to do more than just chat when he gave
Speaker 4: them access to tools. And he throws out a whole
Speaker 4: theory of how we can lock down AI agents by
Speaker 4: making them do... mathematical proofs that the stuff that they're
Speaker 4: doing won't negatively impact something. It is an awesome video.
Speaker 1: Yeah, we need more of that. Absolutely.
Speaker 4: 100%.
Speaker 1: I saw an article that you wrote on LinkedIn, which
Speaker 1: was also on your sub stack. Everything that I've seen
Speaker 1: from you has been thought-provoking, but this was about the
Speaker 1: new MCP 2.0 and how you can't make a stateful
Speaker 1: MCP server anymore if you're using 2.0. And so, yeah,
Speaker 1: we talked about that. I talked about that with Rocky
Speaker 1: on Code with AI. And Richard found your substack and
Speaker 1: found some good stuff that you're thinking of and talking about.
Speaker 1: And here you are.
Speaker 4: Yeah, it ties right back to what Eric is talking about.
Speaker 4: It was funny because I've been working on this for
Speaker 4: a bit. But this whole idea of how do we
Speaker 4: govern these agents better?
Speaker 2: Right. Sure.
Speaker 4: Everybody. Now, for the last two years, people have been
Speaker 4: really complaining about governance. But the big thing everybody now
Speaker 4: is complaining about is tokenomics.
Speaker 1: Tokenomics.
Speaker 4: That's the big thing that everybody is looking because now
Speaker 4: there's a cost per token.
Speaker 2: Right.
Speaker 4: Well, those two things are kind of related. about two
Speaker 4: years ago, just over two years ago, through my day job,
Speaker 4: I got to see a demo of some agentic AI.
Speaker 4: And the demo that they created was really thought-provoking because
Speaker 4: it didn't just show what the agents were working on,
Speaker 4: but it actually, at the bottom of it, showed the
Speaker 4: conversations the agents were actually having with each other. And
Speaker 4: I was like, wow, that looks like a Teams or
Speaker 4: a Slack conversation. But I'd never thought of agentic AI
Speaker 4: in that way. We're software developers. We think about APIs,
Speaker 4: application programming interfaces. Now there's this whole idea of a
Speaker 4: natural language interface.
Speaker 2: Or semi-natural, like The way those tools talk to each
Speaker 2: other is not that normal, but I get what you're saying.
Speaker 2: It is English of a sort.
Speaker 4: And that, that was the thing that jumped out at
Speaker 4: me was it was too generic in a team's chat.
Speaker 4: You expect a lot of three letter acronyms and very
Speaker 4: specific words. for each of the roles that are there.
Speaker 4: Think about chat between a DBA, a front end developer
Speaker 4: and a middle and a mid tier developer, all the conversations,
Speaker 4: all the acronyms that they wind up using.
Speaker 2: Yeah.
Speaker 4: That was lacking.
Speaker 2: It speaks to a lack of common context between the agents.
Speaker 4: And that's where my head was going was how do I, that,
Speaker 4: that seems to be missing. Um, and as you guys know,
Speaker 4: and you've got, you guys had a bunch of over
Speaker 4: the years, especially recently, domain-driven design type folks. I was like,
Speaker 4: there's no ubiquitous language.
Speaker 5: Right.
Speaker 4: What if we made these agents speak the ubiquitous language
Speaker 4: of the domain that they're in charge of?
Speaker 2: Right.
Speaker 4: That would be super cool.
Speaker 2: And really what you're doing is bracketing their context, right?
Speaker 2: That they need to use the correct language.
Speaker 4: Correct. And by doing that, there's side effects, lots of
Speaker 4: good side effects. If you can constrain them or control
Speaker 4: their language, I'm calling it a controlled natural language. Um,
Speaker 4: then they can only do what they can express.
Speaker 5: Yeah.
Speaker 2: And it's another kind of constraint.
Speaker 4: Think about the open AI hacking of hugging face.
Speaker 5: Right.
Speaker 4: Where it had access via MCP to a tool. figured
Speaker 4: out how to do something that wasn't desired by that tool.
Speaker 4: But if we had a natural, a constrained or controlled
Speaker 4: natural language in front of that, then they wouldn't be
Speaker 4: able to ask the things that they shouldn't be able
Speaker 4: to do.
Speaker 2: Yeah.
Speaker 4: So that's, and so the term, these are patterns that I,
Speaker 4: I'm using for this is instead of bounded context, domain-driven design,
Speaker 4: how about bounded agency? So how do we build walls
Speaker 4: around what the domain that that particular agent can do,
Speaker 4: not via just security, but actually ways to express it?
Speaker 4: If they don't have the language to express it, they
Speaker 4: can't do it.
Speaker 3: Right.
Speaker 1: So if you're adding another layer... Doesn't, uh, doesn't that
Speaker 1: affect your tokenomics?
Speaker 4: That's the other side is now you can actually decrease the, um, the,
Speaker 4: the verbiage that's going across. Um, and one of the
Speaker 4: major challenges with a natural language as us as humans
Speaker 4: is there's a lots of different ways to say the
Speaker 4: exact same thing, which leads to ambiguity. Right. And there's, and,
Speaker 4: By constraining it or controlling that language, you actually reduce
Speaker 4: the actual word count, which you're going to reduce the tokens.
Speaker 4: But then you're also decreasing your ambiguity, too, because you
Speaker 4: can only say it a certain way.
Speaker 1: Well, aren't you using tokens for that intermediate layer that
Speaker 1: does the translation?
Speaker 4: So originally, that's where I was thinking. But then I
Speaker 4: take it one step further.
Speaker 5: If I.
Speaker 4: can control the language, and so I can control the syntax.
Speaker 4: And this goes back to stuff that you guys know
Speaker 4: me from, XML. What did I do with XML? I
Speaker 4: created domain-specific languages. What did you do with JSON? Create
Speaker 4: domain-specific languages. What do we do with Fluent APIs and LINQ?
Speaker 4: We created the Fluent APIs and other languages within code. Well,
Speaker 4: with all the stuff that's been going on with chat
Speaker 4: GPT and natural language processing and stuff that we were
Speaker 4: doing with, with link back in the day. What if
Speaker 4: I could put a intent compiler in front of the
Speaker 4: tool that then parses that text because it's a constrained
Speaker 4: natural language. And instead of feeding everything to the model,
Speaker 4: what if I if I knew what words mapped to
Speaker 4: specific functions, I could actually call those functions instead of
Speaker 4: having to pass it through to the agent who would
Speaker 4: eventually pass it through to an MCP server somewhere to
Speaker 4: actually call the tool. So now I've actually reduced, dramatically
Speaker 4: reduced how much is actually going to the models because
Speaker 4: I'm pulling some pieces of that.
Speaker 1: From this static glossary kind of thing. But, And I
Speaker 1: imagine that the best of both worlds would be if
Speaker 1: the word doesn't exist in the glossary and it can't
Speaker 1: express it in a more concise way, then it would
Speaker 1: go out and get definitions for those words and add
Speaker 1: them to the domain.
Speaker 4: So you, you, you really want to control that language
Speaker 4: so that you're controlling what it can do.
Speaker 1: Right.
Speaker 4: So you would prefer, uh, to keep to, uh, to
Speaker 4: programmatically add the new languages. Don't let it do it
Speaker 4: on its own.
Speaker 1: Well, at least it could make you a list.
Speaker 4: A list of it.
Speaker 1: Yeah, a list of things that it didn't understand or whatever.
Speaker 4: Correct. And you can publish that language. And that's one
Speaker 4: of the things that models are great at, converting from
Speaker 4: one language to another language.
Speaker 2: Right.
Speaker 4: So if you have a way to declare that controlled
Speaker 4: natural language, it can convert it automatically.
Speaker 1: Yeah, that's right. I could see repos for all sorts
Speaker 1: of vertical industries, uh, DSLs in used in that way to,
Speaker 1: to rein in your LLMs and your tokenomics.
Speaker 4: I make it a heck of a lot easier for that.
Speaker 4: And so, um, so I actually built, uh, uh, uh,
Speaker 4: I built a couple of different things based on that,
Speaker 4: but I actually have a, uh, MVP that you can
Speaker 4: go pull down from GitHub. It's called Limelight X. Well,
Speaker 4: Rush is out this year, right?
Speaker 2: Doing the tour.
Speaker 4: So Rush fan had to pull that in. So Limelight X.
Speaker 4: And so you go there, you can actually go see
Speaker 4: how to do this. So you can give it the
Speaker 4: natural language, the constrained natural language. give it a text
Speaker 4: and it will actually give you the intermediate steps so
Speaker 4: you can visualize it. So how do you parse that
Speaker 4: apart to an AST? How do you take that AST
Speaker 4: and optimize it? Then you take that AST and turn
Speaker 4: it into intermediate result, which then gets put into an
Speaker 4: expression tree a la link. How do you do that?
Speaker 4: Because what I've found is, Most people doing AI engineering,
Speaker 4: AI agents, they don't come from our comp sci background. Right.
Speaker 4: They come from the dynamic language.
Speaker 2: Side of the house.
Speaker 4: They're Python and JavaScript type script. So parsing and compiler
Speaker 4: theory type stuff is not something that sits in their domain.
Speaker 4: While you can do some of that stuff with those languages,
Speaker 4: you don't typically do it. So they're not thinking that way.
Speaker 4: So how do I get best of both worlds? That's
Speaker 4: part of the challenge.
Speaker 1: Before we go any further, I think we should take
Speaker 1: a little break. You think so, Richard?
Speaker 2: Sure, let's do it.
Speaker 1: All right, we'll be right back after these very important messages. Hey,
Speaker 1: Carl here. You probably know text control is a powerful
Speaker 1: library for document editing and PDF generation. But did you
Speaker 1: know they're also a strong supporter of the developer community?
Speaker 1: It's part of their mission to build and support a
Speaker 1: strong developer community by being present, listening to users, and
Speaker 1: sharing knowledge at conferences across Europe and the United States.
Speaker 1: So if you're heading to a conference soon, check if
Speaker 1: Text Control will be there and stop by to say hi.
Speaker 1: You can find their full conference calendar at www.textcontrol.com. And
Speaker 1: make sure you thank them for supporting. NET Rocks.
Speaker 2: And we're back. It's.
Speaker 3: NET Rocks.
Speaker 2: I'm Richard Campbell. That's Carl Franklin.
Speaker 4: Hey.
Speaker 2: Talking to our friend Don Demsack a bit about, well,
Speaker 2: you just brought up Limelight X as a way to
Speaker 2: sort of create a natural language-like set of instructions, which,
Speaker 2: I mean, in some ways reminds me of the way
Speaker 2: we write specs anyway. Software development is somewhat language. I mean,
Speaker 2: you have the programming language is a constraint. But if
Speaker 2: you also notice, the average product manager speaks in a
Speaker 2: somewhat constrained language. They're trying to communicate with developers, and
Speaker 2: developers speak a weird form of English.
Speaker 1: Dilbert proved that.
Speaker 2: They're really trying to just be very clear on what
Speaker 2: the intent is, and I think it serves the LLMs
Speaker 2: pretty well to stick with that same kind of language barrier.
Speaker 1: 100%.
Speaker 4: And then domain-driven design never took off.
Speaker 2: Yeah.
Speaker 4: We all know it works, but one of the side
Speaker 4: effects of implementing it is you needed to have a
Speaker 4: subject matter expert who can pull that the main logic
Speaker 4: out of that, those communications that was very specialized.
Speaker 2: Yeah.
Speaker 4: Well, nowadays with coding assistance and the spec driven development world,
Speaker 4: we are starting to put that context into text documents
Speaker 4: that obviously we could use models to start pulling out
Speaker 4: that domain-specific language from the specifications.
Speaker 1: I would even go one step further and say we're
Speaker 1: heading towards, if we're not there already, just not thinking
Speaker 1: of it, conversation-based development. In this last episode that I
Speaker 1: did with Rocky Latka, he talked about how he and
Speaker 1: three other guys sat down to design a system He
Speaker 1: whipped out his Android phone, started recording. It made a transcript.
Speaker 1: He uploaded that transcript to Claude and said, build me
Speaker 1: a spec based on this conversation. Whoa. I mean, talk
Speaker 1: about layers, right?
Speaker 2: Using the tool as the preprocessor.
Speaker 1: Yeah.
Speaker 4: It's an interesting space that we're in because that's been
Speaker 4: the art of being a developer is has been really
Speaker 4: taking these vague requirements and then converting it into code.
Speaker 4: What was my favorite, what's the number one thing whenever
Speaker 4: I would build something, the business person would typically turn
Speaker 4: around and say, I know that's what I asked for,
Speaker 4: but that's not what I wanted.
Speaker 2: Yeah, right.
Speaker 4: Because humans are really, really, really bad at giving requirements. Weird.
Speaker 2: Yeah. And in some ways, like you want the domain
Speaker 2: expert because they know the space, but they often skip over.
Speaker 2: essential parts because they're so knowledgeable in the space. They
Speaker 2: don't even realize what they know.
Speaker 4: Yeah.
Speaker 2: Yeah.
Speaker 4: And that's, I mean, because Rocky's been around, he knows
Speaker 4: what he needs to put into that. And so how
Speaker 4: do you teach that to these new wave of, uh,
Speaker 4: coding engineers that are using coding assistants to do that. Well,
Speaker 4: we could teach them better requirement skills. And that's one
Speaker 4: of the things I started doing a couple of years
Speaker 4: ago in prompt engineering was a big rage two years ago.
Speaker 4: And now it's context engineering. But when I explain it
Speaker 4: to the average person, what a prompt is, I tell
Speaker 4: them it's a requirement. Think of it as giving it
Speaker 4: a requirement to another human.
Speaker 5: Right.
Speaker 4: Got to put in all that extra context. And then
Speaker 4: because of my agile background, I like to use given
Speaker 4: when then, so that as measured by. And then I
Speaker 4: would teach people to write their prompts in that structured
Speaker 4: form and they get better results out of the engine
Speaker 4: because you're giving it all the context that you would need.
Speaker 1: Yeah. That's brilliant.
Speaker 4: And so that's, And so that's the same problem that
Speaker 4: I'm running into with the spec-driven development is while they
Speaker 4: have great structure for the documents, how do you build
Speaker 4: the tests? Right. What you really kind of need to
Speaker 4: be able to do is create, given when then type scenarios,
Speaker 4: do more behavior-driven development. So testing for behavior that's expected
Speaker 4: or not expected. rather than writing generic tests.
Speaker 2: You're right. Domain-driven development is great at defining what we'd
Speaker 2: like it to do, but behavior-driven development is much better
Speaker 2: at defining what it actually does and if that's what
Speaker 2: we really wanted to do.
Speaker 4: And then if you could take that, those behavior-driven tests,
Speaker 4: now you can also use that to drive the controlled
Speaker 4: natural language because you're expressing the behaviors that you're looking for.
Speaker 2: And so.
Speaker 4: Besides Limelight X, I have a project called VectorRen, V-E-C-T-O-R,
Speaker 4: my SVG days, Ren, R-E-N, so two R's. And it
Speaker 4: was built with that in mind to show developers how
Speaker 4: to build an SVG game, a web-based with JavaScript, with
Speaker 4: generic JavaScript, no framework. And so what was the, you
Speaker 4: guys remember, what the big game was when we were
Speaker 4: trying to do demo SVG back in the day, it
Speaker 4: was asteroids. Right.
Speaker 1: Oh yeah. So that's right.
Speaker 4: There is in half an hour using this methodology, I
Speaker 4: describe what the game should do and given one then,
Speaker 4: and it generated a simple implementation of asteroids. And you
Speaker 4: can go to vector ren.org or go to vector ren, uh,
Speaker 4: the GitHub page, uh, out there and you can pull
Speaker 4: it down. And it's a very simple way to learn
Speaker 4: JavaScript from this point of view, without any of the frameworks,
Speaker 4: something simple that, that, that people can actually leverage, uh,
Speaker 4: because we have this generation of developers who don't have
Speaker 4: the traditional comp side background.
Speaker 2: Right.
Speaker 5: Yeah.
Speaker 2: I'm just thinking about, we're revising this. We've been playing
Speaker 2: with what the software development life cycle with these tools
Speaker 2: is supposed to look like. And, and I'll, I think
Speaker 2: there's a lot more energy put into the context up
Speaker 2: front just because the tools will generate lots and lots
Speaker 2: of code. It's just most of it is not that
Speaker 2: good if you haven't really done a good job of
Speaker 2: setting up these constraints.
Speaker 4: I've been doing a lot of stuff with AI here
Speaker 4: in Central Pennsylvania. One of the interesting feedback I'm getting
Speaker 4: from non-traditional developers is we don't care.
Speaker 2: Yeah.
Speaker 4: It gets the job done, and that's all.
Speaker 5: I care about.
Speaker 2: You're going to care.
Speaker 4: I hit up one of the folks I was talking about.
Speaker 4: I was talking about, hey, you're just creating dynamic scripts.
Speaker 4: This feels a lot like what JavaScript felt like before jQuery,
Speaker 4: before we got V8, before we got TypeScript. We're sending around.
Speaker 2: Yeah, before we put constraints around for reliability.
Speaker 4: And consistency. So, and I was like, you know, from
Speaker 4: a tokenomics point of view, every time you send that text,
Speaker 4: you're getting charged for it. Yeah. And so there's a
Speaker 4: cost because I don't care. It's cheaper for me to
Speaker 4: do that than to spend the time to actually write
Speaker 4: the compiled code.
Speaker 2: For now, anyway, the costs are going up. But often
Speaker 2: the folks don't care because they don't know the consequences.
Speaker 4: They don't know good engineering principles.
Speaker 2: Yeah, they don't know how the software will bite them later.
Speaker 2: It's generally what works right now.
Speaker 4: And what I'm seeing is a lot of the vibe
Speaker 4: coders realizing that they can only go so far of
Speaker 4: vibe coding, and then they start going to coding assistants,
Speaker 4: but then they don't know how to create these good
Speaker 4: engineering principles. And so I think there's a big market
Speaker 4: for that.
Speaker 2: So the AKA they're starting to care.
Speaker 4: And it makes me sad because as a VB guy,
Speaker 4: old school VB guy, isn't that what the C plus
Speaker 4: plus people complained about us about?
Speaker 2: Yep.
Speaker 4: Yeah, we weren't real developers.
Speaker 2: Well, Yeah, and again, the argument was, is the software
Speaker 2: quality sufficient? And let's face it, we built a lot
Speaker 2: of bad quality software, and then we learned, hey, software
Speaker 2: quality matters. And you could do it with VB, you
Speaker 2: just had to follow some good practices.
Speaker 1: I think a lot of that nose turning down at
Speaker 1: VB developers was a byproduct of what happened between C
Speaker 1: developers and basic developers in the very early days of programming.
Speaker 1: Basic with go-tos was looked at as horrible. I was
Speaker 1: using Visual Basic and then attending a community college and
Speaker 1: the computer science lady, I told her that I was
Speaker 1: using Visual Basic. She goes, oh, basic. Oh, you can't
Speaker 1: say basic.
Speaker 4: No go-tos, no go-tos.
Speaker 1: I'm like, no, it's completely changed now. You know, it's
Speaker 1: come into its own and they still just, you know,
Speaker 1: you get an idea in your mind and it's hard
Speaker 1: to shake.
Speaker 4: And I don't want to be that Get off my
Speaker 4: lawn guy. Yeah, right. And I don't want to be
Speaker 4: that old guy.
Speaker 1: Nobody does.
Speaker 4: I've got the gray hair, fine. But I don't want
Speaker 4: to be that guy. Same thing with coding assistants. What
Speaker 4: I've been talking about to a lot of folks is
Speaker 4: coding assistants is the new IDE. I remember back when
Speaker 4: we were talking, you know, Vim was it. You didn't
Speaker 4: use Studio.
Speaker 3: Right.
Speaker 4: IntelliSense. Coding is novel. You had to know it and
Speaker 4: remember it in your head and use a text editor.
Speaker 4: Real developers use text editors.
Speaker 1: I think it took Don Box a long time to
Speaker 1: come to grips with the fact that people are going
Speaker 1: to use IDEs, not them.
Speaker 4: It would be interesting to get his opinion on coding.
Speaker 2: You see those positions all over the place. I think
Speaker 2: you're making a mistake as soon as you're bound to
Speaker 2: a tool. In the end, the goal was to deliver
Speaker 2: value to customers.
Speaker 4: And then there's this whole, and this ties into Run
Speaker 4: As Radio, then there's this whole angle from the IT
Speaker 4: admin side of the house where IT admins were doing automation,
Speaker 4: but they were doing it via a GUI tool because
Speaker 4: IT admins didn't write code.
Speaker 3: Right.
Speaker 4: That was for the developer world.
Speaker 1: Right.
Speaker 4: In my day job, what I'm starting to see is
Speaker 4: more and more IT admins admins leveraging coding assistance to
Speaker 4: actually create better code than they could ever written because
Speaker 4: all they ever wrote scripts. This is much better code
Speaker 4: and it's making their lives a heck of a lot easier.
Speaker 4: So that's just, I mean, that's an unintended consequence, but
Speaker 4: it's helping, especially in these days when so many companies,
Speaker 4: so many on-prem companies who are using VMware and now
Speaker 4: they're kind of A little bit of a backlash. They're
Speaker 4: all trying to move off, and now they're more open
Speaker 4: to how do I do this automation rather than using
Speaker 4: a tool.
Speaker 1: One quick correction. I think I misspoke. When I was
Speaker 1: in a community college, it wasn't VB. It was Quick Basic.
Speaker 1: Quick Basic. Quick Basic was compiled, and it was structured,
Speaker 1: and it was great back then. And this computer science
Speaker 1: person was like, no go-tos.
Speaker 5: Don't say it.
Speaker 2: Well, and it's the thing, there's nothing wrong with the language.
Speaker 2: It just had a construct that was a problem. Hey,
Speaker 2: remember option explicit? Like we did learn.
Speaker 3: Sure.
Speaker 1: On error, resume next.
Speaker 2: Yeah.
Speaker 1: I don't have any bugs.
Speaker 2: What?
Speaker 5: Yeah.
Speaker 4: So one of the things that I've been starting to
Speaker 4: work with is how do I start creating skills to
Speaker 4: be able to help teach these non-developers these good habits?
Speaker 4: So like one of the things, That's in a beta
Speaker 4: right now is a requirements interrogator skill. So help the
Speaker 4: average person create that given when then brief so that
Speaker 4: they get better requirements when they're trying to build something.
Speaker 2: Yeah, you have to wonder if we're not going to
Speaker 2: end up with more opinionated agents that are like, I
Speaker 2: can't start building this until I have these broader requirements
Speaker 2: settled around those kinds of constraints that are going to
Speaker 2: matter for security and architecture and reliability and scalability. all
Speaker 2: of the abilities that everyone doesn't care about until they
Speaker 2: care about them.
Speaker 3: Yeah.
Speaker 4: One of them I'm playing with right now is, is
Speaker 4: creating a skill to create architectural decision records.
Speaker 5: Right.
Speaker 4: We've never, I mean, we all always wanted to have them,
Speaker 4: but now if I'm using a coding assistant, that helps
Speaker 4: make my coding system better. It tells the architecture and
Speaker 4: the reasons why we picked certain things.
Speaker 2: Yeah.
Speaker 3: Yeah.
Speaker 2: There's lots to all of that. I mean, again, I
Speaker 2: feel like we're just groping around right now trying to
Speaker 2: figure out.
Speaker 4: It's early days.
Speaker 2: What are the, yeah, the tools are shifting. Just remember,
Speaker 2: we were trying to develop on. NET in the early
Speaker 2: days where every time they got a build out, the
Speaker 2: editor changed, the framework had changed, and the language had changed.
Speaker 2: Everything you're doing, incorrect. Yeah.
Speaker 4: I was part of that early days. I don't even
Speaker 4: remember if I ever mentioned it to you guys, but
Speaker 4: the framework The client that I had back in 99, 2000,
Speaker 4: their president was on the board for Microsoft, and I
Speaker 4: was building dashboards for him, and I got introduced to
Speaker 4: Project Cool.
Speaker 2: Before it was announced. Before it became C Sharp?
Speaker 4: Yeah, before 2000, the announcement at PDC 2000.
Speaker 3: Yeah.
Speaker 2: I think it was actually TechEd, but yeah.
Speaker 5: TechEd.
Speaker 4: Yeah, it was TechEd. That's where I'm at.
Speaker 2: But yeah, but I'm also thinking about the craziness that was.
Speaker 2: NET Core in, you know, 2018 or 2016. Because it
Speaker 2: took them 18 months to get that first version built
Speaker 2: and there were so many previews. And every time you
Speaker 2: got a preview, everything shuffled on you. And it just
Speaker 2: seems an awful lot like trying to work with Anthropica
Speaker 2: or OpenAI or any of these tools right now, where
Speaker 2: every time you get A new build, new harness, like
Speaker 2: there's so many different components that presuming it works the
Speaker 2: same way is crazy. It changes. It changes a lot.
Speaker 1: And just like with. NET Core, Richard, I think that
Speaker 1: there's still a lot of people not dipping their toes
Speaker 1: into AI developer-wise for the very same reason.
Speaker 4: So have you guys had anybody on for Microsoft Foundry Local?
Speaker 4: Not yet.
Speaker 2: Not yet. No, it's on my radar.
Speaker 4: I've been intimate with that. So that's part of what
Speaker 4: the bounded context. Part of what I realized is to
Speaker 4: use these smaller models, you had to be very prescriptive
Speaker 4: in the prompts that you were giving.
Speaker 2: Right, right.
Speaker 4: And when I started writing the code, I didn't want
Speaker 4: to put that code as text into my program. I
Speaker 4: wanted to pull it out. And so I created a
Speaker 4: YAML language that did essentially prompt as a function so
Speaker 4: that you could import it in and create it. And
Speaker 4: there's a couple different prompt as a function frameworks out there.
Speaker 4: BAML is one and DPSY, another where it makes it
Speaker 4: easy to put prompts into your programming languages. The Dipsy
Speaker 4: is Python only. BAML is TypeScript and Python. And so
Speaker 4: I built a framework to be able to do that
Speaker 4: because I was trying to run local models. I was
Speaker 4: running local models on what I'm using now, Copilot Plus PC.
Speaker 4: The Copilot Plus PCs were supposed to be the place
Speaker 4: to be able to run these models. It's just not.
Speaker 4: Not as good as it could have been.
Speaker 2: At 40 tops, that's not a lot. Meantime, I'm looking
Speaker 2: at my RTX 5080 at 1,500 tops and saying, why
Speaker 2: aren't I a co-pilot PC?
Speaker 4: So I am super excited for the new RTX Spark laptops.
Speaker 4: I'll be the first to go buy one of them
Speaker 4: when they come out.
Speaker 2: They're actually going to be a laptop, because right now
Speaker 2: it's a NUC.
Speaker 4: Well, the big difference is the DGX Spark, Right. That's
Speaker 4: the one you're thinking is the RTX Spark. Two separate things.
Speaker 4: The DGX is Linux.
Speaker 3: Right.
Speaker 4: The RTX laptop, which is, that was, it was a nook.
Speaker 4: The RTX is a laptop. It is going to run
Speaker 4: Windows on ARM.
Speaker 2: Right.
Speaker 4: So it's, you could think of it as the Uber
Speaker 4: Co-Pilot Plus piece.
Speaker 2: Possibly, yeah. It'll be interesting. It's one of the things
Speaker 2: I've seen over and over again with the DGX Spark,
Speaker 2: but folks are actually using it is, You end up
Speaker 2: running NVIDIA's models because they're so much better optimized for
Speaker 2: their hardware that you just get vastly better responses or results.
Speaker 2: So it's not a universal anything. Where is our ODBC
Speaker 2: so that you really have some equanimity across all of
Speaker 2: these different products? and can really see what all the
Speaker 2: different hardware solutions can be there. I hate that we're
Speaker 2: building dedicated to hardware solutions, but I get it.
Speaker 4: Part of why I created that prompt as a function
Speaker 4: to make it portable, to describe what's the model, what's the,
Speaker 4: am I using VLR? Am I using Foundry Local? What's
Speaker 4: the model? So I can abstract that away so you
Speaker 4: don't have to worry about it and be able to
Speaker 4: switch it in and out. And so I've got a
Speaker 4: framework for that and I'm, I hit my limit with
Speaker 4: the Copilot Plus PC and I'm waiting for these new
Speaker 4: ones to come out. But that's a whole different conversation
Speaker 4: because there's so many people, so many clients and customers
Speaker 4: I talk to that can't use public models.
Speaker 5: Right, right.
Speaker 2: There's whole classes of work that are just not an
Speaker 2: option to be going, leaving your machine in any way.
Speaker 2: Combined with tokens are only getting more expensive and all
Speaker 2: you can eat is disappearing and The methodologies we've been
Speaker 2: using with the sort of adversarial agent model are just
Speaker 2: mo tokens.
Speaker 4: And smaller models hallucinate less. Right.
Speaker 2: They are more bound.
Speaker 4: And then you bound it by a language, a constrained language,
Speaker 4: a controlled language, and you can reduce it even worse.
Speaker 4: That's kind of where I'm going with this. Still early days.
Speaker 4: I do a lot of Foundry local type stuff, running
Speaker 4: to issues, report bugs. There's a whole Viber community. Folks
Speaker 4: who are interested in getting into dipping their toe in
Speaker 4: how do I inject AI LLMs, highly recommend checking it out.
Speaker 4: It's an easy install. And there's a command line tool
Speaker 4: that you can use just to get started to have
Speaker 4: a chat. Have some fun. And then they've got some
Speaker 4: great SDKs, whatever language you want to use from.
Speaker 2: NET to Rust.
Speaker 1: It's out there.
Speaker 4: I highly recommend it.
Speaker 1: This is good stuff, Don.
Speaker 5: Excellent.
Speaker 2: And it got me thinking.
Speaker 1: Yeah, definitely got us thinking. Where can we find you
Speaker 1: online besides your Substack?
Speaker 4: My Substack and LinkedIn. I do both. LinkedIn, it's marketing
Speaker 4: hell right now. People are all complaining. Um, it's not
Speaker 4: where the developers are. Right. And Substack, I tried Reddit.
Speaker 4: I tried, uh, various Discord servers. Um, my local Lancaster
Speaker 4: folks have a great Slack team. So I'm there, Tech Lancaster.
Speaker 4: Those folks are awesome. But Substack feels like the blogging
Speaker 4: from the old days. It's, it's, it's a good community there.
Speaker 1: So in the Lancaster area, do you find that there
Speaker 1: are many Amish developers there?
Speaker 4: There are some that you'd be surprised.
Speaker 3: Wow.
Speaker 4: You'd be surprised. And I wrote up a whole article on,
Speaker 4: because I'm new to the area, Lancaster feels to me
Speaker 4: like Portland, Oregon 20 years ago. They like that weird,
Speaker 4: let's be weird attitude.
Speaker 2: Right.
Speaker 4: They like the back to nature, had the farming, all
Speaker 4: that sort of stuff.
Speaker 2: Yeah.
Speaker 3: But.
Speaker 4: They also like the tech side and there's two massive
Speaker 4: data centers coming in. Coral Reeve is the big AI
Speaker 4: company is putting a big data center and Google's putting
Speaker 4: a big data center in there. So there's a lot
Speaker 4: of innovation going on in that Amish community. It's an
Speaker 4: interesting time.
Speaker 1: Yeah.
Speaker 4: Most people don't think of it that way, but land
Speaker 4: is a heck of a lot cheaper. They can't build
Speaker 4: any more data centers in, um, Northern Virginia. So they're
Speaker 4: moving north into central PA and south into Richmond.
Speaker 5: Okay.
Speaker 1: Well, you have to keep us apprised. And when you
Speaker 1: trade your first AI training for a shoe fly pie,
Speaker 1: let me know. All right, Don, thanks very much.
Speaker 2: Good to catch up with you again.
Speaker 4: Good to catch up. And let's not make it in
Speaker 4: another 20 years.
Speaker 1: Definitely. And we'll talk to you, dear listener, next time on.
Speaker 1: NET Rocks.
Speaker 5: NET Rocks is brought to you by Frankenstein.
Speaker 3: Net and produced by Plop Studios, a full-service audio, video,
Speaker 3: and post-production facility located physically.
Speaker 5: In New London, Connecticut, and, of course, in the cloud.
Speaker 5: Online at pwop.com.
Speaker 3: Visit our website at dotnetrocks.com for RSS feeds, downloads, mobile apps, comments,
Speaker 3: and access to the full archives going back to show
Speaker 3: number one, recorded in September 2002. And make sure you
Speaker 3: check out our sponsors. They keep us in business. Now
Speaker 3: go write some code.
Speaker 1: See you next time.