Reviews for Formal program development

The average rating for Formal program development based on 2 reviews is 4.5 stars.

Review # 1 was written on 2013-01-04 00:00:00 Mathew Hawn A common refrain, in software development, is the need for code reuse. Object-Oriented analysis and design is an attempt to to this. After all, if you have a significant library of pre-written code which yet can leverage, that saves you from reinventing the wheel and allows you to deliver finished projects more quickly. There is another issue which software development is running into: parallel processing. Most code written, whether object-oriented or otherwise, is written in a rigidly procedural fashion. And why not: that's the basis of Von Neumann architecture. That's what we're used to. Unfortunately, that's not how things will work, going forward. While multiprocessor machines used to be extremely expensive, extremely high-end systems, they are found everywhere, today, including in cellphones. The author, originally, put together a system where various components were pre-compiled and could be "wired" together into networks which comprise complete applications. He was able to reuse existing code, with very little new code being written. Because the various components were connected in asynchronous fashion, the various components could be time-shared on a single processor or spread across multiple processors in a large system, or even scattered across multiple machines spread across the globe. Ergo, this system solves the code reuse problem and solves the multiprocessing dilemma. This isn't some theoretical exercise; this code has been in production use for multiple decades. This was, originally, developed at IBM Canada in the late 1950's and 1960's. And, once you wrap your head around it, it's extremely intuitive. Anyone who has done a "one-liner" on a Unix system, making use of the "pipe" to send the output of one command to the input of another, understands this. Unix systems have plenty of small, special purpose tools which accomplish certain tasks on a stream of text. Take this idea, turn it up to "11," kick it up a few notches and put it on steroids and you approach Flow-Based Programming. Anyone who has used a spreadsheet, where this cell depends on that cell and this other cell depends on this cell, gets this. Now, instead of a single piece of data going into the first cell resulting in a bunch of calculations, imagine all of the records from a database query being plugged into that cell, in turn, with the results being collated into a report or another database. In both cases, the calculations/transformations are broken into bite-sized pieces which makes the logic easier to develop and maintain. In both cases, hardcore developers have developed the tools and less skilled people can use these tools to accomplish the tasks. Years ago, I was working for a web design firm. The were developing some projects using Coldfusion, where the designer adds custom tags to the HTML. The person doing this can be mostly a graphic designer, with limited programming skills. I theorized that such a company would need one or more of such people. But, when new capabilities are needed, they would also require one or more hardcore programmers who can create new tags, when needed, which the graphic designers could use. This way, the graphic designers could focus on what they do best and the hardcore programmers could concentrate on what they do best. Traditional web-based development, as I'm experiencing it today, is not that way. I write HTML, CSS, JavaScript and server-side Java. This means that someone who is NOT a particularly good graphic designer is doing both front-end and back-end development. In the meantime, we have people who are graphic designers trying to program. There is little separation between the two, and there should be. That same pattern should also be usable with application and report development. There are people who know the business logic well, who aren't so good with programming. There are programmers who are excellent at querying and processing data, but don't know the business well. Indeed, that is one of the things businesses are most heavily seeking in programmers today: the ability to become experts, not just in the technology, but in the business, as well. These are very different skillsets. It's no mystery why people who can do both tasks are in such short supply. You can find ways to separate the layers, so that people with different skillsets can excel in their particular areas. Or you can push people to become Jacks-of-all-trades, but masters of none. Flow-Based Programming allows you to do the former. Solving the twin issues of code reuse and multiprocessing is just icing on the cake. If you are a programmer who is ready to have your mind blown, acquire a copy of this book and dig in.

Review # 2 was written on 2019-10-26 00:00:00 Michael Rawlinson An absolute gem of a book that helps you discover the magic in large scale collaborative programming and shows you how back-office integration work using business applications can be... fun? I really think this book needs a new edition right about now. The field has exploded in the past 5 years (does Zapier count?) and some of the references and examples aren't intuitively understood for a newly minted programmer.