Comments on Moserware: Towards Moore's Law Software: Part 3 of 3

Anonymous: Sure. I agree with the classic definiti...

2009-06-13T11:49:12.592-04:00

Anonymous: Sure. I agree with the classic definition of Moore's Law. What I was going for in this series was to see what it would take to have the Moore's Law metaphor become a reality in terms of software development/expressiveness.

Moore's Law is really about scaling and the ab...

2009-06-11T15:38:58.535-04:00

Moore's Law is really about scaling and the ability to predict performance and control costs over multiple scales of manufactured size.

Ivan Tihonov and jim: Good thoughts.

Peter ...

2008-06-24T22:02:00.000-04:00

Ivan Tihonov and jim: Good thoughts.

Peter Christensen: Would you say that hardware design is really an identical solution? With all of the pipelining and so forth, it seems like modern chips have quite a bit of innovation and different solutions. Maybe it was that the interfaces were a bit clearer? But, perhaps there was an element of making hardware more of a commodity.
Unfortunately, I don't know enough about hardware to compare the AMD and Intel designs. What is interesting though, is that the functionality had to be identical (plus or minus some fancy multimedia instructions for parallel computing). This is something that you almost never see in software except in space craft or flight control systems (two programs designed to do the exact same thing in the same way). Some might argue that IIS 7 and Apache 2 might be close enough to that (at least in theory with a modular HTTP architecture.)

Is software different in a fundamental way? What about reusable components in COM or .NET? Perhaps the arranagement of components is different, but ultimately there is a lot of reuse. Unfortunately, reuse often isn't a major priority.

I think that if I understood more about modern chip design, I'd probably conclude that it's more varied than it appears. I still think that the biggest influence of Moore's Law is that it clearly gave chip designers a feeling for when they were falling behind. We just don't have that in software.

I think that's why the future needs to have more of the software pushing the hardware design rather than the other way around.

Perhaps I didn't fully catch your thread. Maybe you can elaborate more on it?

Interesting thoughts; thanks for sharing!

To give you an idea of how much I enjoyed this, he...

2008-06-12T14:31:00.000-04:00

To give you an idea of how much I enjoyed this, here's a thought I had in the shower this morning (2 months after I first read it):

Hardware could follow Moore's Law because it was one identical solution to everyone's problem: general computing hardware. Once the variation and diversity of solutions moved above hardware and into software, then a single hardware solution could apply to every problem. All other solutions became unnecessary and all effort gets focused on increasing the speed of the accepted hardware solution.

Software is different - every problem is different and nearly all solutions aren't applicable to another problem. Therefore, optimizations, energy, and time are divided widely among different projects. The bigger the mindshare of a project, the more mature the software is (like Linux, Apache).

Also, software is trying to meet an infinite and growing number of needs, while hardware just had to meet one need and extremely well: fast computation.

Hardware is like making airplanes: even competitors are more similar than different. Software is like movies: each one has different goals, needs, resources, momentum, and direction, and achieves wildly different results.

I don't think I'd say it quite as strongly as Ivan...

2008-04-19T10:05:00.000-04:00

I don't think I'd say it quite as strongly as Ivan did, but I kind of agree. Forth has some really good ideas and if you're willing to dive into the internals, you'll see just how much you can accomplish with very little code. Chuck Moore did a complete CAD system for designing IC's in something like 8k. That included simulation with virtual probes he could put on individual circuits to see how the signals looked.

Forth is excellent for low-level stuff, but you have to be disciplined about maintaining simplicity. What's special about "Thinking Forth" is that it lays out how to think about programming and how to keep things simple. Read it for the ideas it has that you can apply to other languages, not for the sake of learning Forth. A similar book that I've read lately is "The Little Schemer". Highly recommend it as well.

Joe, Factor, even ANS Forth are against Moore's id...

2008-04-19T05:57:00.000-04:00

Joe, Factor, even ANS Forth are against Moore's ideas. They all break the "simplicity" rule.

Do not use Forth as a programming language. Read "Thinking Forth", ultratechnology.com and colorforth.com and use these ideas in a language of your choice.

It's not about stacks and reverse polish notation. It's about being stupid in a clever way.

There is a reason for not using Forth language. Your environment is C-friendly. May be C#-friendly. Or Java-friendly. But for sure it was designed without Forth in mind.

Programming in Forth is like driving a car of octopus alien race with your two mankindish hands. It just does not fit.

It is pretty comfortable if you have no need to deal with all these OS/API/XML stuff which burdens our minds and hard drives. But life differs.

Btw, here is an interesting view why Forth is unsuccessful in a mainstream.

http://www.msmisp.com/futuretest/Forth's_Dilemma.htm

jim: I did a search and found the book online as you said. It seems that Forth is sort of like thinking in the CLR's IL (stack based). It seems a bit overly terse (but not quite like J). I suppose it looks better with more experience.

I hadn't looked into Clojure before. It's sort of like F# on the CLR side but with more LISP syntax. I welcome the languages to try out ideas. Like I mentioned, it's really nice we can leverage the huge frameworks like the JRE's libraries on the JVM.

Thanks for the info!

Chuck Moore did some incredible stuff with Forth. ...

2008-04-17T23:51:00.000-04:00

Chuck Moore did some incredible stuff with Forth. A good book is "Thinking Forth" by Leo Brodie, it's a free download I believe.

Also, you should check out Clojure. It's a new dynamic language for the JVM that is built around immutable data structures, excellent concurrency ideas, Java interop and Lisp syntax/macros. Cool stuff

Ivan Tihonov: This is interesting. I had a convers...

2008-04-17T22:28:00.000-04:00

Ivan Tihonov: This is interesting. I had a conversation with someone at work a day earlier and he mentioned someone that used Forth as well. The particular use was for a driver. Do you see thoughts from this language entering into more mainstream languages? If so, any example that you'd like to see?

It's interesting that both Moore's are noted for their appeal for an improvement in efficiency.

Moore does not write much. You could read articles...

2008-04-17T13:34:00.000-04:00

Moore does not write much. You could read articles by Jeff Fox on www.ultratechnology.com about Moore and his ideas.

http://www.ultratechnology.com/moore4th.htm
http://www.colorforth.com/1percent.html

Btw, Occam, Enstein and Exupéry said same things decades before him. "KISS principle" is widely accepted. But what is seen as "simple" today is overcomplicated actually.

Steve Campbell: Part of me agrees that they're rea...

2008-04-16T21:03:00.000-04:00

Steve Campbell: Part of me agrees that they're really approaching a limit, but another part of me hopes there is still another sizable increase (I can't think of it though -- however Alan Kay mentioned that part of their goal is to raise the bar enough to let others possibly see it)

Good job on watching out for the "Turing Tar Pit" on your own parser/interpreter.

It is harder to write, but as you noticed, it has some artistic elegance and beauty which is a rare find in code.

Thanks for the thorough comment!

Ivan Tihonov: Are you referring to the inventor of Forth? Is there a specific paper or book you can point me to that is a sample of what you're speaking about? I saw some thoughts in terms of chip design but not clear ones in terms of software.

Peter Christensen: I'm not worthy of having my own law :)

anonymous: I briefly looked at the code and it seemed to be interesting, but quite a lot of C code. Besides its implementation on microcontrollers, what stuck out about the implementation that you found interesting?

Adam Dunkel's uIP that is used in Contiki is very ...

2008-04-16T16:42:00.000-04:00

Adam Dunkel's uIP that is used in Contiki is very interesting implementation of the TCP/IP stack.

For the last 3 days, I've been reading it as "Mose...

2008-04-16T15:05:00.000-04:00

For the last 3 days, I've been reading it as "Moser's Law of Software". Oops!

You should read about Chuck Moore's ideas. He is t...

2008-04-16T14:40:00.000-04:00

You should read about Chuck Moore's ideas. He is talking about this for last 40 years.

Yes, I think its possible to get a one-time multip...

2008-04-16T11:29:00.000-04:00

Yes, I think its possible to get a one-time multiple-order-magnitude increase in software. Unlike Moore's law, there is an easy to define upper limit though. I think Alan Kay's group are already at that limit.

On the expressiveness of the TCP example, I have done similar things before, and they have worked *really* well. It was a risk though, because I had to trust that I understood the problem domain well enough to invest a lot of time in the parser/interpreter.

The interesting thing about this sort of code is that it is *never* legacy code. As long as the abstraction holds and the concept it supports is needed, the code is correct and can be re-used, independent of platform, language, technology etc.

Final thought - the transformation+model-based thinking that is necessary to work in this way will not come easily to everyone. Some (maybe most) programmers will never make the leap.