"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Just a short interchange on personal style, no further implications
intended. However, I could respectfully contend that one who actually *knows
the nomenclature* of the *placement of curly braces* may also be spending
too much time on the wrong topic. I will, however, try to concentrate on the
dismal state of my software here onwards.
Unfortunately I'm still using ED.

Excellent quote! Worth remembering.

As one who's helped create an extremely workable RDP, the client side of
which works entirely with JavaScript, I would have to disagree with,
apparently, myself, or at least the impression I gave you in my last post.
Iae, a few points:

1) The fact that JavaScript is a "script" language is irrelevant. So could
you classify mvBasic. Like mvB, JS has a syntax checker and, no doubt, a
p-code type runtime. A true script language decodes on the fly (like Proc)
and the main objection to such is lack of speed and error checking only on
execution of the statement.

2) Once again, I do not understand the concerns above. You say that "People
these days are asking for thin clients that look just like a thick app."
Which describes my BUI. What, exactly, is wrong with that if a) it works
efficiently b) satisfies the user's needs and c) is totally maintainable (at
present I'm practically the entire R&D staff, for complex reasons.) We've
already discussed the benefits and otherwise of thin vs thick clients over
and over.

3) Don't understand the deployment issue comment either. Why would having
the odd java applet or ActiveX be a problem? I do have some, and I don't
have any problems; in fact I remember you once saying that thick client
software was easy to deploy though some Acronym I've forgotten. Since I
don't have any problems even without using said deployment software,
where's the beef?

3) We're not "writ[ing] an operating system, compiler, database, etc." in
JavaScript, we're writing very basic but necessary UI stuff. What, exactly
is wrong with "more code on the client?"

Chandru Murthi

As long as that AJAX library takes care of my target users' preferred
browsers (or PDAs, or cell phones, or gaming consoles, or
refrigerators, etc.) then I vote *for* making thin clients look like
richer apps. As both of you have pointed out, the big issue is
overcoming variation at the client.

I'm sure we all know a bunch of Pick installations that have
dependences on specific telnet emulators, and once we have the emulator
hooked up we still have to be sure it's set to ADDS VP or VT100 and the
keyboard map is defined just-so. And then we write documents for
support on what to say when the user starts futzing around with
settings, or worse, when some enterprising programmer writes server
side code to push settings on the fly and then proceeds to crash in
mid-script and leave the settings in a broken state, preventing the
user from returning to the main menu ... (breathe, Jeff. Just breathe).

Isn't the browser -- or to use the new flex phrase, the "user agent" --
just the latest terminal emulator in the fight against what we might
call deployment entropy? I think we're going to see some changes here,
and the press is going to tell us it's about fighting that entropy.

Microsoft's offering is partly a Vista plug. It's a recently released a
tech preview download of WPF/E, an SDK and Flash-like browser plug-in
that has *some* cross-platform capabilities. Its goal is to extend some
of the Vista "user experience" beyond strictly MS platforms. Behind the
scenes it apparently uses (you gessed it) javascript to talk to Firefox
and Safari but I don't think we need to write any js code. Microsoft
promises to conceal that javascript complexity from the programmer. And
yes, it does require a little plug-in. I haven't tried in Firefox on my
Fedora box yet but I wouldn't rule it out.

What's my point? We'll it certainly isn't to plug Microsoft although
I'm glad they finally understand the "richness versus variation"
problem. My real point is that glue languages like javascript are
definitely here to stay if they're showing up in things WPF/E and GWT
(Google Web Toolkit). As long as it remains a glue language and it's
buried in big containers like AJAX libraries, WPF, GWT then I have no
complaints. Let their armies of programmers worry about what browser
dialect my refrigerator speaks, not me.

JW

"Jeff Wilson" wrote:
That's really where I see that it's OK to have heavy use of JavaScript
- within tools where it's functional, bug-free, unseen, and abstracted
from the business end of the user experience.

I don't object to JS itself, I happen to really like it. And like
Chandru and oodles of other geeks, I'm exactly the kind of guy who is
tempted to build massive JS codeblocks into a BUI to make it do really
cool things - but then I don't because I know it's asking for trouble.
I prefer to let others write tools on which I can build. And if I can
rely on someone else's Ajax interface to handle the front end while I
do all of the magic on the back-end, I'm happy.

The problem with this phenomenon with JS is that it's so popular that
people are fooled into thinking that they can actually write code -
(asking for it here I guess) just like Pick BASIC. The word "Java"
gives people permission to proudly state they write Java code, and I
can't tell you how many people I have not wanted to embarrass when
they make claims like that. The word "Script" differentiates the
language from the other languages which demand more knowledge, it
makes it more friendly and inviting. Put them together and you have a
lot of people who are really happy because they think they are writing
sophisticated code. The reality is that the deceptive simplicity of
the language ultimately lowers the bar for quality. More people put
out bloated crap, and the public becomes tolerant of bloated crap
because that seems to be the norm.

Now remember, as I said above, the problem isn't with the language
itself, it's about the abuse that the language gets because it's so
accessible. Of course I do have beefs with the language itself in
terms of runtime errors, standards, etc, but that's not what I'm
talking about at the moment. I would feel much better about all of
this if all of the virtues of JavaScript were tempered through
education, so that people wrote better code, code that's higher
quality, more performant, and less subject to issues between browsers
and releases.

I feel the same when a lot of concepts come to the masses, and I know
it makes me sound elitest but I firmly believe education needs to come
before adoption of just about anything. Here are some examples:
- It's not about JavaScript, it's about the people who abuse it.
- It's not about guns, it's about control.
- It's not about religion, it's about everyone saying God is on their
side.
- It's not about people having babies, it's about people who don't
know anything about life having lots of babies.
- The internet isn't a bad place, it's the bad stuff people put on the
net.
- The problem isn't kids' music, it's the lack of parental guidance
that allows kids to internalize lyrics and take it literally.
- The problem isn't email, it's that we allow spammers to dominate our
networks.
- Democracy isn't bad, it's when the masses allow their elected
officials to get away with abuse of power ... the sort of power people
abuse when they write big JavaScript code. "Absolute power corrupts
absolutely?"


If you're wondering what the hell I'm talking about or you just got
very offended by something then I guess I once again didn't express
myself properly. I assure you I have a smile on my face as I write
this because I think it's funny that this topic can be taken in so
many directions.

Regards to all.
T

"Chandru Murthi" wrote:

And please do understand that I also imply nothing when I'm writing
this stuff. I am not somehow implying your name or code when I'm
going on about this stuff though sometimes it seems like you think so.

I only learned those terms when I read the references that I cited.
Your point is taken that it would be both sad and funny if I actually
knew those things before starting.


Sorry, but that's no surprise here.


I comment on this similarity in my response to Jeff W. I see a big
similarity in the mindset of those who write MV BASIC and those who
write entire apps in JavaScript. Both languages are deceptively
empowering. Both languages allow completely non technical people to
do amazing things and to call themselves programmers when they're
done.

I don't want to insult many of our respected colleagues here who have
developed their skills over the years, but let's face it, a lot of
Pickies came to the table as business people first and they knew
nothing about technology until they were introduced to Proc and ED.
Many of the rest of us learned the technology before the business
side. Those who have learned coding by performing the act (without
prior education) often have no idea what's happening under the
hood/bonnet and don't really care - it just works, and sometimes it
doesn't. That's not usually a solid foundation for good software.
The people who are still here after so many years have 1) learned how
to code better and re-wrote their original code (laughing as they see
their old mistakes?); 2) hired other people to take the good ideas and
wrap some solid code around them (stand on the shoulders of giants?);
3) just had such great functionality and enthusiasm that they were
able to sell a lot of what they had despite how crappy the code was
written (which I suspect is the story for most).

I see the same sort of cludge solutions in MV BASIC as I do in
JavaScript which is written by someone who uses AOL and thinks they're
a hacker. One of the few things that redeems JavaScript is that a lot
of code people copy/paste into their own bloatware comes from freeware
sites where someone with a clue at some point may have had their hands
in it. Unfortunately in the MV world where few people share code, we
don't see the same sort of cross-pollination of good ideas which
allows software to evolve.

There's no real point there, just observations.

The syntax checker is in the runtime, that's the problem. The
developer often doesn't know there are problems until the end-user
complains about an annoying dialog box appearing or some button not
working.

About p-code, you know more about that area than almost everyone here
- I'm surprised you mention that. P-code is generated by a
pre-compiler, and there is none for JS. JS is purely interpreted.

And FWIW, there are no absolutes regarding JS interpreters. The
interpreter for every product is different and is implemented
differntly, albeit usually with some reverence for the ECMA standard.
People tend to talk about JS like it's "one thing", but what you get
from JS is really dependent on whose interpreter you're using. Google
for "javascript interpreter" (without quotes, then with quotes
afterward) to see hundreds of examples.


There's nothing wrong with a consumer wanting a product that's
attractive or feature-rich. The problem is that they have come to
expect it from the browser container which is subject to issues with
security, stability, and consistency, and performance. People don't
understand that they've traded the complexity which is provided by
their workstation for the diversity available on the internet. They
expect the internet and the container which represents it to be as
powerful on their desktop as any application they can run right off
the metal.

My beef is that the internet browser was the wrong component on which
to base these expectations, and JavaScript only facilitates people who
want to consume and provide such solutions. It's that we're doing the
right things for the wrong reasons. It's a patch on top of a bad
implementation. If we had a decent container to provide what the
consumer wants then we wouldn't have people support something like JS
as the answer to the problems.

In this regard, Java applications are much better than Java because
they're (arguably) cross-platform, compiled/interpreted like MV BASIC,
and they can easily be deployed over the internet. It allows for the
feature-rich user experience that people want, security, and
(arguably) decent performance. And yet after all of these years Java
still hasn't quite captured the imagination of the masses - partially
because people insist everything needs to be deployed through the
browser.

And why haven't Java Applets taken off? Partially because it's just a
little too complex for the sort of people who tend toward JavaScript.
(Present company not included Chandru - you've _chosen_ JavaScript as
a solution which is far different than using it because it's the only
thing you can get your head around. I'm talking about a completely
different developer type there.)

I could ellaborate on this Java Application/Applet thing, and include
ClickOnce deployment for .NET, but the point is that people are
insisting on getting the right things from the wrong places, and I
personally think JavaScript is a brain-dead solution to the real
problem that people are trying to solve.


Apparently you haven't spoken to some of the people who come to me
asking me how to get away from the ActiveX deployment problems.

For an Internet app, ActiveX is completely out. I hope that doesn't
need more explanation.

For an Extranet app, you need to deal with the network administrators
at other companies who have fought really hard to lock down their
environment - only to have some trading partner ask them to load just
one more harmless ActiveX.

For Intranet or Extranet, once an ActiveX is loaded, updates are still
difficult when the new code has a different signature - it's like a
new porting effort, and when an admin has a lot of workstations and
probably a lot of sites to update, ActiveX becomes a real
administrative burden on top of so many others. Java applets? There
are fewer issues for those but as I mentioned above, Java just hasn't
captured the imagination of the masses, so many people leave it turned
off.

Again, that's not a complete answer and I'm sure you can refute stuff
I haven't included. (I tire of these long threads as much as others
do so I'm trying to be not so all-inclusive these days.) I just hope
that's enough explanation about why ActiveX in particular isn't ideal.

I just mentioned ClickOnce above. Here's info in one of my blogs:
http://tinyurl.com/y4crg8
That's not ActiveX, it's a thick client app that's bound to a security
model and it's updated over the web (like Java Web Client as Dawn or
Luke once pointed out I think).

You apparently don't have problems because your users allow ActiveX
because they have to (security bells are ringing here, or is that just
my tinnitus?), and/or your end-user sites are smaller and have less
admin burden. As soon as you need to deploy to 50 sites with 50 users
and a team of angry admins, you'll realize exactly where the beef is.

And please don't compare apples to oranges with this "I do the same
thing as technology X and I'm so smart and everyone else is so stupid
and I don't need their newfangled thingamabobs..." Your software
isn't self-updating over the internet and running thick apps within a
secure sandbox that prevents it from accessing specific parts of an
end-user system. There are reasons technologies like this are
developed and that's that no lone star has come up with the equivalent
functionality using prior technologies. If you do have such
solutions, I suggest you contact Microsoft and Sun Microsystems to
sell them some of your time.


The more code I see on the client the more unstable and insecure the
client becomes when exposed to an increasing variety of end-users.
Fix that problem and I don't care how much code you put in my browser.

If I haven't been clear in all of this, Chandru, I'd welcome your code
on the system of anyone I know or do business with. It's not your
skills that bother me, because knowing you're a competent developer I
know you'll do well with the tools available, and that you'll support
whatever fails in the process. My beef is with the bloated and buggy
crud that so many other people come up with because this medium
fosters that sort of "lowest common denominator" development - it's
that "dumbing down" thing I've mentioned in the past that I object to.

Regards,
T

Thanks for the chuckles, Tony. I too am impressed with how far afield
computer architecture can take the imagination. Don't get me started on
how learning the "inversion of control" design principle finally woke
me up to the value of abstract deities in society. In that spirit,
allow me to wish all those who are into one particular concrete deity a
happy instatiation celebration, a.k.a. a Merry Christmas.

<snip>

Just to set my "stall" out - so to speak. I should state that we
deploy a thick client - written in vb.net, and deployed using self
installing msi files.

I see the pro's and cons of this from my perspective :

1. All code is written and compiled in a single environment (pro)
2. It pretty much runs equally on all PC's (ok as long as they run
windows) (con)
3. I'm stuck with Windows desktops only (never ever ever been asked to
run on anything else so thats ok with me). (con)
4. The "rich" interface is much easier to put together on a thick
client (ok this is subjective but I would believe it to be true). (pro)


The problems as I see with a web-client is :

1. Browser incompatibility - this issue just never seems to go away!
(con)
2. Multiple languages - javascript/java/active-x (interestingly
active-x suggests running on Windows only - which makes my no 3 fail)
(con)
3. Cross platform compatability (pro)
4. Easier to get a "pretty" user interface (ever given a designer a
windows form to design on ?) (pro)
5. More difficult (ok subjective) to make the application smoothly
responsive. (con).
6. Too much moving technology (it's still not a stable platform to
develop on).
7. Easier to deploy software updates (pro)

Whilst I would content that there are good well written web-clients
that are provide a rich user experience - and that it's possible to
write thick-clients that are exactly the opposite - I would contend
that the main issues are deployment and cross-platform compatiblity.

Obviously, there are certain applications that should be targeted
towards a browser (online banking for example - though I note all my
online bank'here in the uk only run on ie5+ on windows!) - most
business applications would probably be better served with a thick
client - the main issue of deployment is not an issue today.

I've simplified most of my arguments and left out a few (firewalls for
example).

Bottom line, what I'm actually saying is that for any application we
should consider all the pros and cons to decide whether thick or web
client are the best for the job. I'm not contending that thick is
always better but that I see too many applications written as a
web-client that would probably be better served as a thick client (and
I have seen the odd thick client that would be better served as a web
client).

One example, is a competitor of mine - that sells on the basis that the
application is high-tech browser based.. The application is written
using asp.net technology. It looks fantastic, but some of the user
interface is very slow (due to continued round-trips to the server).
I've never heard any performance related issues of our thick-client
application.

What I find most interesting is the contention by my competitor that
"web-client" is automatically better. I think that this is a key point
behind the web/thick client debate - developers are sometimes believing
the hype.

Just to conclude, whilst I've responded to Chandru's post, I'm not
making any suggestion that he's got it wrong. If he has a functioning
web client that fullfills all the aims of his application then he must
have got it right! I don't know if he would have been better served by
a thick-client (and am making no suggests that he might!)

Regards
Simon

Simon

Chandru:

You've touched on an interesting point; that current languages are
predicated on poorly designed runtimes and environments, thus, the
programming structures themselves, based on work-arounds and
inconsistencies, are nothing but "the emporer's new clothes"! Hence, this
is an excellent explanation of why we get lousy software today, and will in
the future.

"Chandru Murthi" <cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote...

[snipped]

[snipped]