Avatar
unclebobmartin
2ef93f01cd2493e04235a6b87b10d3c4a74e2a7eb7c3caf168268f6af73314b5
Uncle Bob, Software Craftsman. http://cleancoder.com http://cleancoders.com

Elon and Maher. This is priceless. "The Woke Mind Virus"

https://youtu.be/oO8w6XcXJUs

Hello!

I started programming in 1964. I worked on IBM360s, Honeywell H200s, Varian 620s, DEC PDP-8, PDP-11, 8080, Z80, and a zillion other devices. Now I'm coding in Clojure and working on the nostr client "more-speech" github.com/unclebob/more-speech.

Welcome to Nostr. It's a hell of a place!

>From: (rfgeier) at 04/29/23 14:31:34 on wss://relay.damus.io

>---------------

>Hello Damus! Hello Nostr! This is my first day here and my first post. I’m an old dinosaur trying to learn new tricks. An analog man in a digital world. I started programming in 1975 on old mainframe computers. No monitors. Only printout. I’ve always loved technology and this is no exception. The future is wide open and exciting. Growing up, we would have never imagined cell phones or the internet. Now look! Good luck to everyone involved. Much love. To infinity and beyond! 😎

GM-PV Notrologicals,

I just pushed a new version of more-speech. It's really coming together nicely. It's not quite grandmother-safe, but is far less dependent upon technical knowledge to operate. It provides a very different view of nostr than you may be used to.

github.com/unclebob/more-speech. Check out the wiki, there's a "Getting Started" page that is pretty much up to date. You can download and compile it, or just download the jar file and run it.

Hossenfelder has, over the last two years, become my favorite science YouTuber. This one took guts.

Is being trans a social fad among teenagers? https://youtu.be/oR_RAp73ra0 via @YouTube

OK, Looks like batching is working in more-speech. Now the backlog of incoming events remains reasonable even when trying to pull down a days worth of events or metadata or contacts, etc.

This was a fun problem because ... well because anything that has to do with time windows is a challenge.

There are a few tricky issues like empty batches, and bunches of events with the same created_at time. But if you are careful you can inch your way back in time without too much trouble.

It's pretty easy to do. NIP-01 says that if you use the "limit":n argument then the _latest_ n events are sent. That's perfect. You you get that batch, find the minimum created-at set that to the next "until" and back the "since" up.

You have to coordinate with the EOSE messages, and I've found it wise to send a CLOSE before the next REQ.

Good Morning Nostroids,

Today I'm working on the batching of requests in more-speech. Rather than pull several thousand events at a time, I'm walking backwards in time by batches of 100 events, waiting for them to be processed, and then requesting the next batch.

This allows new events to come in and be displayed in approximate real time while old events continue to trickle in.

This is fun!

>From: (benc) at 04/27/23 08:46:28 on wss://relay.damus.io

>---------------

>I wonder if low code/no code technology is an attempt to automate to the extreme. Build the platforms that enable more people to construct applications. I guess we see things like IFTT, zapier, salesforce, etc and it hasn’t changed much in the software world yet. I think public API products fit into this category too.

All the low/no code products are an attempt to use fewer programmers and to make it easier for non-programmers to configure their systems. In the simplest cases is works OK; but no system stays simple forever. As the complexity rises the Low/No code systems become much more of a liability than a benefit.

>That brings up and interesting thought. How does relate to the average level of craftsmanship across the profession? It seemingly creates a divide. Those who enable more software development must be must account for the delinquency of a newer generation of software development.

The average level of craftsmanship decreases because of the exponential growth. The need for craftsmanship _increases_ because the complexity increases. It's a dilemma.

My glasses work quite well. I keep the font size pretty small on all three of my screens.

>From: Sherry<-cameri at 04/27/23 08:23:07 on wss://relay.damus.io

>---------------

>😝respect! While I always have a question for you sir. Do you need a special screen? Or you are natural born with good eyes.

I'm 70 and I still think I can make a difference. :-P

>From: (WaterBlower) at 04/27/23 08:00:56 on wss://relay.damus.io

>---------------

>2 reasons

>1. Being truly good at programming take time. It’s not the same as finding a job in big tech where you literally just do leetcode and know nothing about real programming

>

>2. Nostr also represents a set of values that can only be truly understood once you’re 30, when you see enough shits of the society but still young enough to believe that yourself can make a difference.

...and it looks like putting the "Good Morning" in the subject of the note fooled the Cyborg.

It's a beautiful morning in the north woods of Wisconsin.

Today we sell our boat (we hope). Lots to do today to get things ready for the sale. Last night I blew up all the recreational toys that we used to tow behind the boat for the entertainment of our children and grandchildren.

I'm also hoping to work on the subsccription model within more-speech. Right now when more-speech starts up it queries all the events from the last N days from the relays. This creates a flood of events that all queue up to be processed. The backlog can grow to thousands of events, and take several minutes to drain. (Yeah, Clojure is a bit slow). So my plan is to query some small number of past events and wait for the relays to finish delivering them, and wait for the backlog to drain, before querying the next small batch. This will prevent the backlog from blocking real-time events.

Clearly the growth cannot remain exponential. If it did then thirty years from now 3 out of 4 humans on the planet will be programmers. That's not feasible.

What is driving the current exponential growth? Exponential demand. Every N years the demand for new software that people are willing to pay for doubles. Thus, every N years we must double our capacity to write software.

What will slow the exponential demand for nnew software? Perhaps we'll run out of applications. Or, perhaps the price of software will increase.

Why would the price of software increase? Because the supply of programmers will become too low to meet the demand. This will drive programmer salaries up and therefore software prices up.

What could increase our capacity to write software? Hiring more programmers of course; but also better tools, better languages, better environments etc.

Will our tools become so powerful that we can meet the exponential demand for software without hiring more programmers? That doesn't seem likely; but some folks worry that AI will take over most of the work of writing software. If that happens then software will get cheaper, and demand for new software will increase without the need for more programmers.

The most likely outcome of all this that the exponential growth of programmers will eventually consumem the supply, driving programmer salaries up. This will create enormous pressure to automate more and more of the software process, allowing programmers to magnify their productivity. At some point all these forces will stabilize and the exponential growth of programmers, and demand for software, will plateau.

>From: (benc) at 04/26/23 23:38:35 on wss://nos.lol

>---------------

>#[3]​ when suggesting the population of programmers doubles every five years we end up with an exponential growth.

>

>Exponential growth isn’t very natural.

>

>Any thoughts on it being more like logistic growth and that some compensating factor will curb growth in the future and maintain an equilibrium?

Good Morning Notripolitains:

Today I must prepare for, and then deliver, the final session in my 13 week Clean Code Master Course. I've had a lot of fun with this one.

When that's complete, my honey and I will scurry up north to our love-nest hideaway for a few days. I'll grab some time up there to continue working on more-speech.

Yes, So far, to my knowledge, no mobile platform supports Linux, OSX, or Windows. (Though some used to run Windows CE). One day perhaps...

As far as I know it is relay dependent. Some relays may allow larger messages than others. Some months back I created a message that was many K long. I don't remember the actual size but it made it onto the relays we were using at the time.

>From: bigmarh<-DerekRoss at 04/25/23 12:40:11 on wss://relay.damus.io

>---------------

>Is there a spec on the Max Size of event content that relays will take? I can't seem to find it spelled out anywhere.