Functional Programming book review
in [Cobol]
|
From: Howard Brazee on 8 Jun 2010 13:39 On Tue, 08 Jun 2010 11:54:12 -0400, Michael Wojcik <mwojcik(a)newsguy.com> wrote: >[1] I've done some significant research into source code readability, >particularly the history of attempts to make source code more readable >for maintainers (see previous posts about my 2009 ATTW presentation), >and I strongly suspect that most arguments about programming-language >readability are vapid. Few people bother to look at any empirical >research or even present sensible hypotheses; few even bother to try >to construct arguments on the topic - they just state their >prejudices. And programming language readability is a small part of >source code readability. Very good point. "Readability" means code written the way *I* would write it (at least if I wrote it to be readable). It would be nice to see some empirical research. Trouble is, our languages are changing rapidly enough that such research would need to be updated pretty much continuously. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Howard Brazee on 9 Jun 2010 09:29 On Wed, 9 Jun 2010 18:37:26 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >> [1] I've done some significant research into source code readability, >> particularly the history of attempts to make source code more readable >> for maintainers (see previous posts about my 2009 ATTW presentation), >> and I strongly suspect that most arguments about programming-language >> readability are vapid. > >Wow! I accept your informed opinion on this, Michael, but that was a major >selling point for COBOL for decades. > >I wonder if it WAS true at some point (maybe during the transition from low >to high level languages) but became less true as a diversity of languages >appeared and people became more used to using them? I suspect so. We have a lot of languages which use similar syntax that has become familiar to us. The more familiar we are with a language and the more we use it in routine ways, the more readable it is. Obviously it isn't hard to make code difficult to read, and some languages make this easier. Usually this is a result of sites not demanding readability from programmers, but sometimes it is a matter of using inappropriate tools. (I once worked in a shop that used to be RPG2 only. There were some very interesting and obscure tricks the programmers used get the results they needed). -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Michael Wojcik on 11 Jun 2010 17:24 Pete Dashwood wrote: > > I have recently learned PHP and found it to draw heavily on C#. I don't think so, if you mean that literally. For one thing, PHP is about five years older than C#. I've used PHP fairly extensively, and I don't think there's much design behind it at all, to be honest. It's basically a mishmash of whatever the developers (first Rasmus Lerdorf and friends, and later Zend) want to throw into it. A lot of it is (awkwardly) adapted from the C language family - several elements of the basic syntax, many of the string functions, etc. It also clearly owes a lot to the major Unix scripting language family tree, from Bourne shell through Perl. PHP's object syntax has a superficial resemblance to C#'s, but that's because they're both notational descendants of C++ by way of Java. Note for example that PHP uses C++'s scope-resolution operator ("::") rather than C#'s ("."). C# is a far cleaner language than PHP (but then, so are most languages that weren't assembled by throwing in anything that seemed like a good idea at the time). Just take a look at PHP's "magic methods", for example. Or its mix of real functions/methods and special keywords like "echo". If you're coming from a pure procedural background, plus some exposure to a contemporary language like C#, PHP would definitely resemble the latter more. But that's just because it has modern features. The same would be true of, say, Ruby or Python (both of which are a lot saner than PHP, though they have their faults too). > I like it, > and for people who are involved with web development (as I currently am) it > is a very useful tool. I would recommend COBOL people who are involved with > web stuff to look at it. The problem is that PHP encourages really poor code. Few people seem to want to make the effort to write decently structured, maintainable, robust code when they work in PHP. The typical PHP page seems to be a tangled mess of PHP and HTML fragments, with most of the PHP slapped-together procedural code and echo statements. It may take longer to build a site using something like Ruby on Rails, but at least when you do it has an actual architecture. > At the same time, I had a look at Haskell but I have decided not to pursue > this at the moment. There are functional facilities in C# that currently > meet my needs and I think you are absolutely correct about the mixing of > functional and imperative paradigms within a single language. I guess we all > want the best of all possible worlds... :-) The functional facilities in C# are getting better, and if you want to try a mostly-functional language, F# would seem like a better choice, since it's a .NET language and comes with Visual Studio. One problem with F# is that the syntax is rather terse with lots of special symbols - something it inherited from OCaml - which makes it very difficult for someone who's not familiar with the language to read. >> [1] I've done some significant research into source code readability, >> particularly the history of attempts to make source code more readable >> for maintainers (see previous posts about my 2009 ATTW presentation), >> and I strongly suspect that most arguments about programming-language >> readability are vapid. > > Wow! I accept your informed opinion on this, Michael, but that was a major > selling point for COBOL for decades. Yes, but originally it referred to a very special kind of reading: letting experts in other domains (mostly accountants and lawyers) compare source code to a set of requirements (like tax laws, for example). Later that goal was erroneously generalized to "you can read COBOL if you can read English", which is clearly not true in any useful sense. > I wonder if it WAS true at some point (maybe during the transition from low > to high level languages) but became less true as a diversity of languages > appeared and people became more used to using them? Generally we can say that HLLs are easier to read than assembly, if we're talking about non-trivial programs, just because the information density and abstraction level are higher. And COBOL is generally easier to read than, say, APL. But yes, I think that source language readability was more important in the 1960s than it is today. Not because reading source is less important, but because we have much more resources available to do a much better job of documenting source code, regardless of the language. A well-written C program, with ample comments and embedded documentation, formatted with something like Doxygen, is more readable than the equivalent COBOL program written in the classic 1970s verbose-for-the-sake-of-verbose style. You don't even need to know C if the documentation is decent. That was part of Knuth's point when he introduced Literate Programming: you should be able to understand the program from the text, and having the source code there is just to show you how it's implemented (and so that the LP engine can extract it for compilation, of course). -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Pete Dashwood on 11 Jun 2010 22:11 Michael Wojcik wrote: > Pete Dashwood wrote: >> >> I have recently learned PHP and found it to draw heavily on C#. > > I don't think so, if you mean that literally. For one thing, PHP is > about five years older than C#. I didn't check the history of it and my comments were subjective :-) To me, I see a number of similar constructs to C#.That made it easier and quicker for me to learn it (I'm already pretty facile with HTML). I shouldn't have said it draws heavily on C# (in this forum, at least) without checking the history. I should have said : "It has many similar constructs to C#" :-) > > I've used PHP fairly extensively, and I don't think there's much > design behind it at all, to be honest. It's basically a mishmash of > whatever the developers (first Rasmus Lerdorf and friends, and later > Zend) want to throw into it. OK, here's the scenario that brought me to it: In the Beginning... :-) I learned HTML and wrote a web site using Notepad. It worked and I learned how to put music, images (I had one of the first digital cameras available), and animations onto it. Cool. Then I realized it could do more if the pages were "smarter", so I learned Javascript and added client side .js. It worked. I came to realize the limitations of this and decided the smart (and more secure) way to add capability to pages was to run server-side code. When I first wanted to use server-side code to make some "smartness" for web pages I used CGI code in COBOL. It worked fine. Gradually I realized that if I used Active Server Pages (ASP) I could make things happen on a page and could intersperse the ASP code with HTML, moving easily from one to the other. Not great architecturally or in a pure sense, but very practical and useful. It worked fine. Then I got into C# and became aware of how much easier things are in the ..NET environment. By now I had VS 2008 and it automatically supports ASPX (Extended ASP). ASPX separates presentation from processing (which I am a great fan of) by placing the code onto an attached page, called a "code-behind". There are pairs of pages; a display page in HTML (which can be a shell and populated dynamically at run time), and an associated "code-behind" page, written in a .NET language and using the full programming facilites of .NET. (Obviously, I write mine in C#, but you don't have to...) This is the best scenario as far as I'm concerned, and all the PRIMA web sites and pages are written using this. (I'm sure you know all this, Michael, I'm documenting it as the actual path I went down and for the benfit of people who haven't encountered this stuff before.) Using .aspx pages gives me the best flexibility and I can write shared modules and components that are resident on the server and called from pages that need them, just like standard programming practice. But recently I agreed to help out on a web site that has been built from templates using GoLive. (GoLive is a simple tool from Adobe that lets people who are not web developers generate consistent web pages. Intelligence is provided on the client by Javascript, mostly generated and transparent to the user. The person who did it did a good job but she hasn't time to take care fo it any more so it fell to me to take over the Web Mastering of it. At the same time, it needs to be updated with forms and DB support, plus automated generation of email.) I don't have GoLive, but I do have it's big brother, Dreamweaver. I converted the site to Dreamweaver, and started looking again at ASP. Then I realised that PHP is becoming popular for this sort of thing so I investigated it and was pleased to find I could pick it up easily. It would have been too much effort to convert the whole site to .NET and use ASPX, so my options were really ASP or PHP. PHP is better, in my opnion; it certainly has more facilites...). OK, from a pure programming point of view, I don't disagree with your comments about the mishmash nature of it, but it works and I have, within a couple of days, already got forms that work perfectly (and are actioned by PHP) and generated email that comes from the same PHP code. Receiving the data from the forms is a doddle and the next step is to update an online DB with it. (At the moment I am suffering from an ear infection which has slowed me down a bit; coding when you are in pain is not good... :-)) Dreamweaver won't step through it so it is a bit tricky to debug, but DW does validate it and colour codes the source. (And I can add temporary echo statements to see what's going on...) I did spend 2 hours locating a missing semi-colon :-) (DW validated the page as OK, but as soon as the form was transmitted I got a 500 internal server error and no clues...). I consider that part of a learning curve and it taught me a lesson. It hasn't happened since. So, for me at least, PHP is a very useful tool. It isn't pure or something I would want to build a modern web site based around (I would use aspx for that until I get a better idea), but it is great for easily and quickly adding functionality to old static web pages. > A lot of it is (awkwardly) adapted from > the C language family - several elements of the basic syntax, many of > the string functions, etc. It also clearly owes a lot to the major > Unix scripting language family tree, from Bourne shell through Perl. I have no experience in this area so wouldn't see it as you do. > > PHP's object syntax has a superficial resemblance to C#'s, but that's > because they're both notational descendants of C++ by way of Java. > Note for example that PHP uses C++'s scope-resolution operator ("::") > rather than C#'s ("."). > > C# is a far cleaner language than PHP (but then, so are most languages > that weren't assembled by throwing in anything that seemed like a good > idea at the time). Just take a look at PHP's "magic methods", for > example. Or its mix of real functions/methods and special keywords > like "echo". .... or nl2br (That one amused me... :-)) > > If you're coming from a pure procedural background, plus some exposure > to a contemporary language like C#, PHP would definitely resemble the > latter more. But that's just because it has modern features. The same > would be true of, say, Ruby or Python (both of which are a lot saner > than PHP, though they have their faults too). Haven't had time to explore Ruby so don't know. > >> I like it, >> and for people who are involved with web development (as I currently >> am) it is a very useful tool. I would recommend COBOL people who are >> involved with web stuff to look at it. > > The problem is that PHP encourages really poor code. Few people seem > to want to make the effort to write decently structured, maintainable, > robust code when they work in PHP. That is hardly a fault of the language. (I didn't notice PHP saying: "Come on, Pete, write me sloppily... " :-)) I have limited the PHP involvement to mainly actioning forms, where the code is ALL PHP with little or no mixed in HTML. The form pages are standard ..html with the "action=handleMyForm.php". The .php pages are small and I don't think it is hard to follow. > > The typical PHP page seems to be a tangled mess of PHP and HTML > fragments, with most of the PHP slapped-together procedural code and > echo statements. Yes, I can see how that could happen. Nevertheless, people did exactly the same mishmash of ASP and HTML code and the world seems to have survived... :-) > > It may take longer to build a site using something like Ruby on Rails, > but at least when you do it has an actual architecture. > As noted above, I would not build a site based around PHP. But it is very useful for enhancing an already built static site. >> At the same time, I had a look at Haskell but I have decided not to >> pursue this at the moment. There are functional facilities in C# >> that currently meet my needs and I think you are absolutely correct >> about the mixing of functional and imperative paradigms within a >> single language. I guess we all want the best of all possible >> worlds... :-) > > The functional facilities in C# are getting better, and if you want to > try a mostly-functional language, F# would seem like a better choice, > since it's a .NET language and comes with Visual Studio. Yes, I have looked at it. The main use I have for functional programming is around LINQ so I don't need to really get into it at the moment. > > One problem with F# is that the syntax is rather terse with lots of > special symbols - something it inherited from OCaml - which makes it > very difficult for someone who's not familiar with the language to > read. > Agreed. :-) >>> [1] I've done some significant research into source code >>> readability, particularly the history of attempts to make source >>> code more readable for maintainers (see previous posts about my >>> 2009 ATTW presentation), and I strongly suspect that most arguments >>> about programming-language readability are vapid. >> >> Wow! I accept your informed opinion on this, Michael, but that was a >> major selling point for COBOL for decades. > > Yes, but originally it referred to a very special kind of reading: > letting experts in other domains (mostly accountants and lawyers) > compare source code to a set of requirements (like tax laws, for > example). Later that goal was erroneously generalized to "you can read > COBOL if you can read English", which is clearly not true in any > useful sense. > >> I wonder if it WAS true at some point (maybe during the transition >> from low to high level languages) but became less true as a >> diversity of languages appeared and people became more used to using >> them? > > Generally we can say that HLLs are easier to read than assembly, if > we're talking about non-trivial programs, just because the information > density and abstraction level are higher. And COBOL is generally > easier to read than, say, APL. But yes, I think that source language > readability was more important in the 1960s than it is today. Not > because reading source is less important, but because we have much > more resources available to do a much better job of documenting source > code, regardless of the language. As someone who routinely uses objects and components which I don't have the source for, source code readability is NOT a big issue for me. However, I would agree that code I DO have source code for should be clear. I worry more about the FUNCTIONALITY of a component being documented with a full description of its methods, properties, and event handling. Whether this is produced on demand by the component itself, or whether it comes as an external document file, THAT I consider to be essential, and MUCH more important than the quality of code documentation, which I will probably never look at, even if I have it available. We live in a different world than the one we lived in 40 years ago. > > A well-written C program, with ample comments and embedded > documentation, formatted with something like Doxygen, is more readable > than the equivalent COBOL program written in the classic 1970s > verbose-for-the-sake-of-verbose style. You don't even need to know C > if the documentation is decent. That was part of Knuth's point when he > introduced Literate Programming: you should be able to understand the > program from the text, and having the source code there is just to > show you how it's implemented (and so that the LP engine can extract > it for compilation, of course). Not come across Literate Programming. Interesting. Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 13 Jun 2010 19:02 In article <huu9lq0crm(a)news2.newsguy.com>, Michael Wojcik <mwojcik(a)newsguy.com> wrote: [snip] >Few people seem >to want to make the effort to write decently structured, maintainable, >robust code when they work in PHP. Oh, I *cannot* resist... .... and this makes PHP differ from just about any other language... how? DD
|
Next
|
Last
Pages: 1 2 3 Prev: cobol pic definition Next: Readibility of code was Re: Functional Programming book review |