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

H. S. Lahman wrote:
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.

I'm not familiar with the terms you guys use here relationship implementation, and navigation.

Instantiation is facilitated by |new| and by other means, such as certain notation as:-

var o = { name : "value" };
var arr = [true, false, /*elision*/ ,null];

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.


Objects can be passed in other languages, too.

En javascript, value object is preferable to long parameter list. This allows the caller to pass a value object that may have many options, or just a few.


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.

It is much worse than that. There are some very odd design choices that were made that have stuck. Callable objects, such as document.images. To elaborate, document.images was a collection, but MSIE decided to make it callable:-

document.images(0)

instead of sticking with just:

document.images[0]


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?


I can speculate on some of this, but the creator of javascript, Brendan Eich, would be the one who could provide the answer to that.

Competing Browser object models caused problems. W3C standards include functionality from those, some functionality that is copied from MSIE differently, and some features that were created by the w3c.

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.


You posted earlier:
| 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.

For the record; I agree. It's almost hard not to notice problems.

For example, try using Firefox "NoScript" extension, changing your user-agent string, using Opera, or turning javascript errors on and go surf the web. You will find sites that have small problems to completely broken and unusable sites. Even with a recent browser, using the default configuration, and English language, you will find many broken sites (aetna.com, or pubmed).

Ecmascript has problems, the browser object models have more and greater
problems. The w3c payers have strange ideas about API design what browsers should do and how the APIs should be designed.

The whatwg continues to design things that will cause compatibility problems (maybe to punish IE). Not bad ideas in hindsight, but bad ideas in foresight.

The whole browser scripting "platform" has problems and will continue to have problems.

That's putting it lightly, though.

Web developers do things in very strange ways. The "platform" has problems, web developers do things badly, and the process for building a web front end is almost always misguided and poorly done.

Anyone who recognizes those problems would expect the web to be mostly broken.

My point in all this is that ECMAScript itself gets a worse rap than I think it deserves. Partially because of the problems with browser object models, compatibility issues, and The Things Web Developers Do.

The dynamic nature of ECMAScript is well-suited to the task of web page scripting. Dynamic property lookup make feature detection and interface-based design work.


[...]


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.


I know. It is an interesting discussion. It's also a small world.

I have found your advice insightful and helpful in the past. It would be great to see some of the intelligence here applied to the whatwg list. They seem to emphasize what "all browsers" should do, to be consistent. Roles are never discussed. Use-case analysis is, but is not strongly enough emphasized, IMO.

I don't know some of the terminology used here. Is there a glossary somewhere?

Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
.

Relevant Pages

  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... 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. ... Your criticism of the language seems to be based on the things web developers create with it. ...
    (comp.object)
  • Re: Javascript Best Practices Document v1.0
    ... As soon someone accepts that they have to deal with javascript (and they ... accepting that their best interests lie in understanding how to use it. ... choice of learning what they are doing, ... I work with lots of web developers who don't understand javascript, ...
    (comp.lang.javascript)
  • Re: More bollocks from biggots
    ... - uses cookies for session maintenance ... execute uploaded Javascript then that Javascript will always be able to ... form of Session-IDs, or cookies, or domain pre-authorization, or anything ... a public web site or because someone has inside knowledge ...
    (comp.os.vms)
  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... Show me a complex web site that uses a lot of JavaScript and I will show ... That seems a bit unfair to the language. ... 'Python considered harmful'... ...
    (comp.object)
  • Re: Real time link to data element
    ... So I can get this real-time data to my own Web site using ... "script" directly into an MS Access db (on PC, no server issues). ... assuming one can use JavaScript, ASP VBSScript and ASP.NET with HTML to do ... The browser requests the page from ...
    (comp.lang.javascript)