Re: modularity... (was: Re: Looking for real world examples to explain the difference between procedural (structured?) programming and OOP)

Responding to Smith...

nevermind that JavaScript is also an OOPL FWIW...

LOL. It is a stretch to even call it object-based.

Show me a complex web site that uses a lot of JavaScript and I will show you a web site with chronic broken page problems. JavaScript gets my vote for the worst contribution to software development since MS-DOS or the old UNIX sendmail program.


Your criticism of the language seems to be based on the things web developers create with it. That seems a bit unfair to the language. Web developers do things in very strange ways.

I was mainly objecting to the notion of JavaScript as an OOPL. It does not <directly> support very basic OOA/D concepts, such as the separation of relationship implementation, instantiation, and navigation. Worse, it encourages bad OOA/D practices, such as passing object references around. Those issues, in turn, adversely affect the maintainability of large applications because one cannot properly isolate and encapsulate concerns separately when necessary.


Granted, there are certainly shortcomings with the language. The typeof, operator parseInt, and the Date object, to name a few.

Host objects are such things as an HTML document, the browser window, or XMLHttpRequest. These things are not native to the language. The APIs developed by Netscape, Microsoft, and the w3c have affected how we code our scripts. Many of the w3c standards were copied from vendor APIs, such as microsoft's DOM. Sometimes the standard was specified in ways that are incompatible with the original.

I agree that the infrastructure vendors have not helped and, in fact, have often discouraged good OOA/D practice. That's because they were largely designed to support the CRUD/USER layered models and the RAD form/table paradigm.

But, as you point out, that just leads to a chicken & egg problem. Did the infrastructures build around JavaScript or did JavaScript build around the infrastructures?

For the record, I have nothing against JavaScript per se. I see no problem with using it for form-based processing in thin clients. My problem lies in using it on the server side or for fat clients when complex processing non-CRUD/USER needs to be done -- or calling it an OOPL.


[...]


If one reads books by OOA/D authors like Jacobson, Wirfs-Brock, Mellor, et al it superficially appears that they are talking about quite different things complete with different terminology. But those differences represent attempts to map the underlying OO fundamentals into something familiar to novices. Thus Wirfs-Brock emphasizes roles while Jacobson emphasizes use case analysis. That mapping to familiarity is necessary because the OO paradigm is not intuitive in terms of conventional algorithmic computation.

Incidentally, Rebecca Wirfs-Brock is married to Allen Wirfs-Brock who is
a member of TG 39.

[...]

Criticism on the HTML 5 specification can be directed to the whatwg mailing list.

Criticism to the ECMAScript 5 specification can be directed to es-discuss mailing list.

OK, but the context here had nothing to do with JavaScript or web-based implementation infrastructures. It was only about different views of OOA/D.



--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
.

Relevant Pages