tag:blogger.com,1999:blog-6104420435021904082.post3957838443963400835..comments2024-03-13T12:21:27.016-05:00Comments on The Programmer's Paradox: Hard Code'nPaul W. Homerhttp://www.blogger.com/profile/02349253120538728302noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-6104420435021904082.post-47173961357342530542008-06-19T21:27:00.000-05:002008-06-19T21:27:00.000-05:00Hi Reino,I keep coming back to the idea that the A...Hi Reino,<BR/><BR/>I keep coming back to the idea that the Arabs based their early counting systems around ten symbols (base ten), while the Romans based theirs around an ever expanding number of symbols (although they seemed to stop at eight). <BR/><BR/>Both are abstractions for handling qualities in our world, yet they are very different. Although they both handle arithmetic, it is a far easier chore with the Arabic system. The merchants simplified the task, while the conquers stuck with a cruder system. But is it only culture that shaped that choice?<BR/><BR/>Underneath, both systems are equivalent and complete. They are pure mathematical abstractions, no matter how or why they came into being. So 2 + 3 = 5 = V = II + III is always true. Would the Romans have not eventually found base ten on their own? Once you find the path, culture may set your speed, but your goal is always the same.<BR/><BR/>In modern computer languages, the choice of technology generally comes with sets of predefined cultural bias. You try not to use loops in APL, while you tend to use partial objects (beans) in Java. But in the same sense as above, these are just points on the overall path forward. <BR/><BR/>I am guessing that no matter where we start we will all converge towards the same abstractions. The ones that really work. <BR/><BR/>In working with huge systems, they exceed our grasps too quickly, so at another site, <A HREF="http://softblue.wetpaint.com" REL="nofollow">http://softblue.wetpaint.com</A>, we've been slowly digging into the underlying essence of the design for software. Size I think is one of the paramount issues, modern systems are massive, making them easy to get off course. We are looking for ways to outline the design without committing to a huge amount of work first. <BR/><BR/>I'm inclined to believe that first working in another simpler and more relaxed notation will allow the direction to be more appropriately shaped before it gets cast in stone in a more rigorous programming language. <BR/><BR/><BR/>Paul.Paul W. Homerhttps://www.blogger.com/profile/02349253120538728302noreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-2656916908794694102008-06-17T11:16:00.000-05:002008-06-17T11:16:00.000-05:00A note about AbstractionsAbstractions are culture,...A note about Abstractions<BR/><BR/>Abstractions are culture, defined as conventions with semantics.<BR/>They can be used to describe the program and reason about the program, without any need to define and implement the program (that´s the responsibility of the evaluator and the compiler).<BR/><BR/>Sometimes the culture in the language gives you the wrong abstractions, so you have to describe more of the semantics in the program. <BR/>Then the language should give the developer more ways to define new abstractions, with new syntax and semantics in the evaluators, and more ways to select (and define and document) the right evaluator (or part of evaluator).<BR/><BR/>That requires a standard way to define and document the abstractions and the semantics in the evaluators, in a composable way (nested evaluators), that can be understood in a standard evaluator.<BR/><BR/>I think that is a function that very few programming languages are trying to support.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-17328644418612329072008-06-04T21:32:00.000-05:002008-06-04T21:32:00.000-05:00Hi Reino, Thanks for the comments. I think you're ...Hi Reino, <BR/><BR/>Thanks for the comments. I think you're right, you don't have to be actively building systems in order to have a real appreciation of the complexity of the problems that the software industry faces. Software is the juxtaposition of mathematical purity and human irrationality, sandwiched together at a haphazard moment, but constantly changing. <BR/><BR/>It all comes down to how you express your solutions for providing functionality to allow users to play with their piles of data. Expression is the key to all of your questions. We just haven't reached a point yet where we've even touched on a tiny fraction of the different ways to express our systems. We keep getting distracted by the technology.<BR/><BR/>Paul.Paul W. Homerhttps://www.blogger.com/profile/02349253120538728302noreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-78184341859079349242008-06-04T19:37:00.000-05:002008-06-04T19:37:00.000-05:00I am not a programmer or developer or teacher, but...I am not a programmer or developer or teacher, but i have read a lot of what they are saying about their problems. <BR/>And i have tried to find some kind of unifying logic in what they are doing.<BR/><BR/>I have learnt a few things:<BR/>A developer creates the design while a programmer implements it.<BR/>Linear static text is to much information and to little structure, all in the same dimension.<BR/>It´s called "code" for a reason.<BR/>The source makes a lousy specification - even if they call it "test".<BR/><BR/><BR/>Source-oriented software makes it difficult to formulate the right questions and separate the answers in different semantical layers:<BR/><BR/>What should the program do? <BR/>How should i describe it to the user?<BR/><BR/>What should happen in the program? <BR/>How should i describe it to the programmer?<BR/><BR/>How should i make it happen in the system? <BR/>How should i describe it to the compiler, and what kind of support can i get from the tools when i am doing it?<BR/><BR/>What can be done in the compiler instead of by the programmer? <BR/>What should it look like to the programmer, and what must the programmer do to "compute" what it means on the other side of the compiler?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-66918873667772395132008-05-15T11:09:00.000-05:002008-05-15T11:09:00.000-05:00Hi Steve,Your right, I think, in that programming ...Hi Steve,<BR/><BR/>Your right, I think, in that programming is constantly changing as we discover and use different idioms (APL, Lisp, Prolog) and higher level abstractions (3rd GL, OO, multi-threading, etc.). But while it is ever evolving and will never stop, the act of encoding a large sequence of steps into some form of syntactical primitives is mostly constant. Java is a little different than assembler, but still similar. What N steps do you need to implement X?<BR/><BR/>The convention is to not want to split out the different types of work, but I think it's the convention that is causing a lot of our problems. Lets face it, the industry as a whole is not functioning well. We're proud to have gone from a 30% success rate to a 50% one?<BR/><BR/>There are relativity few good designers and analysts but there are lots of people who can program. Leveraging this would lead to better systems. The fear for most people seems to be that they don't want to be 'just a programmer', which is understandable but only if they are willing to pick up all of the different skills needed to be an overall software developer. Somebody doing analysis that doesn't understand it or the problem domain is just asking for trouble. Right now, if they can code a sort algorithm, we think they're automatically qualified for everything else. They're not, that's why it blows up so often.<BR/><BR/><BR/>Paul.Paul W. Homerhttps://www.blogger.com/profile/02349253120538728302noreply@blogger.comtag:blogger.com,1999:blog-6104420435021904082.post-45463626750572774012008-05-15T10:08:00.000-05:002008-05-15T10:08:00.000-05:00I think programming itself is still growing as a f...I think programming itself is still growing as a field. Witness the very active debate over dynamic vs static languages, etc. Admittedly, the ideas have been around forever - however, we are still learning how to practically apply them.<BR/><BR/>I don't think it is useful to distinguish between programming and software development. The problem with doing that is it implies that there is a way to split the responsibilities - just give the programming to the junior guys (or India), and leave the heavy thought to the architects. That can work, but is inefficient because software development is a design process, and by its very nature highly iterative and communication-bandwidth intensive. (It is most efficient to have the designer also do the programming).Steve Campbellhttps://www.blogger.com/profile/16844901321480913008noreply@blogger.com