Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > Microsoft, JBoss link server software

Reply
Thread Tools

Microsoft, JBoss link server software

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      09-30-2005
In article <1127867610.2d8f00291d84cb626d95d479a9416273@teran ews>,
"AD." <(E-Mail Removed)> wrote:

>When Unix was first developed, computers didn't really have a lot of extra
>resources to waste on translating cases etc.


Actually, that's not true. The very first computer system I was exposed
to was RSTS/E (look it up on Wikipedia). It was unbelievably primitive
even by other systems of the day, yet it was quite capable of accepting
lowercase commands, filenames etc and uppercasing them internally.

>For native english speakers it doesn't seem like much benefit at all, but
>apparently in other languages the rules for character case can get a lot
>more complicated and code that is case insensitve has to add a whole lot
>of complicated rules.


This wasn't so important back in the 1970s or so when the computing
world was pretty much North-American-centric. But it does matter now
with increasing internationalization and widespread adoption of Unicode.

Even in English, lexical ordering rules can get complicated. Does "Mc"
come before "Mac" in the phone book?
 
Reply With Quote
 
 
 
 
AD.
Guest
Posts: n/a
 
      10-01-2005
On Fri, 30 Sep 2005 20:26:43 +1200, Lawrence D'Oliveiro wrote:

> In article <1127867610.2d8f00291d84cb626d95d479a9416273@teran ews>,
> "AD." <(E-Mail Removed)> wrote:
>
>>When Unix was first developed, computers didn't really have a lot of
>>extra resources to waste on translating cases etc.

>
> Actually, that's not true. The very first computer system I was exposed to
> was RSTS/E (look it up on Wikipedia). It was unbelievably primitive even
> by other systems of the day, yet it was quite capable of accepting
> lowercase commands, filenames etc and uppercasing them internally.


I stand corrected.

OK, maybe the designers of Unix felt they didn't have the resources to
waste on such things - you'd have to admit wasting resources on fluffy
niceties was never one of Unix's primary design considerations

--
Cheers
Anton
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-01-2005
In article <1128163045.d3531fd6073489e3642400960d118a90@teran ews>,
"AD." <(E-Mail Removed)> wrote:

>On Fri, 30 Sep 2005 20:26:43 +1200, Lawrence D'Oliveiro wrote:
>
>> In article <1127867610.2d8f00291d84cb626d95d479a9416273@teran ews>,
>> "AD." <(E-Mail Removed)> wrote:
>>
>>>When Unix was first developed, computers didn't really have a lot of
>>>extra resources to waste on translating cases etc.

>>
>> Actually, that's not true. The very first computer system I was exposed to
>> was RSTS/E (look it up on Wikipedia). It was unbelievably primitive even
>> by other systems of the day, yet it was quite capable of accepting
>> lowercase commands, filenames etc and uppercasing them internally.

>
>I stand corrected.
>
>OK, maybe the designers of Unix felt they didn't have the resources to
>waste on such things - you'd have to admit wasting resources on fluffy
>niceties was never one of Unix's primary design considerations


Actually, it was a long-standing convention on UNIX systems that, if you
logged in by entering your username all in uppercase, then the login
program would set the tty modes for lowercasing all input and
uppercasing all output.

I think the assumption was that you must be using a terminal that wasn't
capable of dealing with lowercase.

Or that you were a doofus who had left caps lock on. But caps lock is a
whole separate peeve.
 
Reply With Quote
 
Bok
Guest
Posts: n/a
 
      10-02-2005
AD. wrote:
> On Wed, 28 Sep 2005 22:40:14 +1200, Rob J wrote:
>
>
>>Most people don't want it to.
>>
>>Case sensitive file names and case sensitive programming languages are the
>>most moronic concepts ever invented in computing.

>
> Ambiguity is seldom a good thing in a programming language. All you are
> doing is creating opportunities for inconsistancies that make a
> programmers job harder.

That argument can be applied both ways. Case sensitivity allows for Foo
and foo to refer to exactly the same kind of entity in a name space.
What's that if it's not amgiguous?

The arguments for and against case sensitivity are overrated in my
opinion. Case sensitivity can be useful if you have a naming convention
where types start in upper case and variables and functions start with a
lower case (as an example). That allows you to have a variable called
file of type File. Apart from that kind of naming convention, I don't
see any real advantage in enforcing case sensitivity in a programming
language.

> A coder scanning code for a certain name might overlook ones written a different way.
>
> Making programmers jobs harder also leads to greater chances of those
> programmers producing bugs.
>
> Having case sensitive variables, functions, classes etc makes enforcing
> naming standards easier and any mistakes show up earlier.

I disagree. Case sensitivity just increases the size of the namespace.
It doesn't in itself enforce any naming standard - development teams do
that. Language Type safety can help prevent certain kinds of error but
that's nothing to do with naming conventions and casing of the namespace.

> Do you want obvious bugs or subtle bugs?

Can you provide a real example of a coding error that was attributable
to case ambiguity?

> As for filesystems - it's neither here nor there really. I happily use
> systems with both, and it's only when they have to interoperate that it
> becomes a pain. And for interoperability, the best approach is to just
> act like you're using a case sensitive filesystem all the time.

You can't do that unfortunately since Makefile and makefile overwrite
each other on windoze. You can of course leverage the fact that current
windoze file systems preserve case.








 
Reply With Quote
 
Bok
Guest
Posts: n/a
 
      10-02-2005
Lawrence D'Oliveiro wrote:
> In article <uXj_e.14754$(E-Mail Removed)>,
> "Ron McNulty" <(E-Mail Removed)> wrote:
>
>
>>Integrating Active Directory is good if you want to run on Windows - but
>>goes against the Java philosophy of write once, run anywhere.

>
>
> Well, Java itself doesn't exactly conform to that philosophy, so no big
> loss.

I'd say, it's actual philosophy appears to be more along the lines of
write once, debug everyhere.
 
Reply With Quote
 
Bok
Guest
Posts: n/a
 
      10-02-2005
Steve H wrote:
> On Wed, 28 Sep 2005 10:45:13 +1200, Ron McNulty wrote:
>
>>My wish list for interoperability is short and sweet:
>>1. Change windows to use the '/' as the directory delimiter

>
> iirc, ntkrnl takes either - its the shell guys who **** that up (try it in
> some shell windows, it barely works)


I've always used '/' as a directory seperator on Windows/DOS, yes even
DOS accepted it. The WIN32 APIs and certain shell functions (the one's
I've used anyway) also handle '/' as a seperator. It gets messy with UNC
names since you have to prefix server name with a double backslash for
it to be recognized as a UNC name.
 
Reply With Quote
 
AD.
Guest
Posts: n/a
 
      10-02-2005
On Sun, 02 Oct 2005 13:07:04 +1300, Bok wrote:

>> Ambiguity is seldom a good thing in a programming language. All you are
>> doing is creating opportunities for inconsistancies that make a
>> programmers job harder.

>
> That argument can be applied both ways. Case sensitivity allows for Foo
> and foo to refer to exactly the same kind of entity in a name space.
> What's that if it's not amgiguous?


That's why you have coding standards for consistency (it's not an
either case sensitivity or naming standards thing - you need both). The
case sensitivity just means that all programmers have to work with the
same capitalisation. Would you let different programmers on a team use
different indenting styles? If not, why would you let them use different
capitalisation styles?

Worrying about the ambiguity of having too many similar but different
names might indicate that the codebase isn't designed that well in the
first place - eg overuse of global variables, functions or classes that
are too large, badly designed APIs etc

>> Having case sensitive variables, functions, classes etc makes enforcing
>> naming standards easier and any mistakes show up earlier.

>
> I disagree. Case sensitivity just increases the size of the namespace.


Only if you don't have any standards for what capitalisation to use.

> It doesn't in itself enforce any naming standard - development teams
> do that.


Yep I never claimed otherwise, but it does make deviations from the
standard more readily apparent to the programmer making them.

--
Cheers
Anton
 
Reply With Quote
 
Bok
Guest
Posts: n/a
 
      10-02-2005
AD. wrote:
>>That argument can be applied both ways. Case sensitivity allows for Foo
>>and foo to refer to exactly the same kind of entity in a name space.
>>What's that if it's not amgiguous?

>
>
> That's why you have coding standards for consistency (it's not an
> either case sensitivity or naming standards thing - you need both). The
> case sensitivity just means that all programmers have to work with the
> same capitalisation.

Not entirely. All it means is they have to use the same case once the
program element has been defined. Language enforced case sensitivity
doesn't prevent a programmer from defining a new function tolower when
the 'team' coding standard calls for mixed case ie toLower or ToLower.
Furthermore, if you opt to use a third party library that has a
different casing convention, then you are forced to use that convention,
whereas a case insensitive language would allow you to stick with your own.

At best all language case sensitivity does is provide consistency of
usage once an element has been defined. An intelligent IDE can do that
for you too.

I normally avoid case sensitive versus insensitive arguments - I don't
see any real advantage of one over the other. The point I'm trying to
make here is the benefit of case sensitivity is overrated.

> Would you let different programmers on a team use different indenting styles?
> If not, why would you let them use different capitalisation styles?

I don't disagree with consistency in coding styles. What's in dispute is
the extent a case sensitive language helps maintain that consistency.
I've already provided an example were it can subvert consistency.

>>>Having case sensitive variables, functions, classes etc makes enforcing
>>>naming standards easier and any mistakes show up earlier.

>>
>>I disagree. Case sensitivity just increases the size of the namespace.

>
> Only if you don't have any standards for what capitalisation to use.


>>It doesn't in itself enforce any naming standard - development teams
>>do that.


> Yep I never claimed otherwise, but it does make deviations from the
> standard more readily apparent to the programmer making them.

Possibly, but only after an element has been defined with a specific
case not before.




 
Reply With Quote
 
AD.
Guest
Posts: n/a
 
      10-02-2005
On Sun, 02 Oct 2005 18:55:47 +1300, Bok wrote:

> Not entirely. All it means is they have to use the same case once the
> program element has been defined. Language enforced case sensitivity
> doesn't prevent a programmer from defining a new function tolower when the
> 'team' coding standard calls for mixed case ie toLower or ToLower.


Wouldn't disregarding the naming standard be a bug in that case that
needed changing? Just the same as it would be with a case insensitive
language too. Making it a moot point.

The "new stuff" example has the team enforcing the standards. It works the
same either way. And generally the amount of adding new stuff vs
maintaining old stuff is pretty small. And enforcing the case standards
when working on the old stuff is generally easier with a case sensitive
language.

I'm not saying case sensitivity is an advantage in every single situation,
but most of the counter examples just work out neutral rather than actual
advantages for case insensitive languages.

> Furthermore, if you opt to use a third party library that has a different
> casing convention, then you are forced to use that convention, whereas a
> case insensitive language would allow you to stick with your own.


Sure that's one example that works out in favour of case insensitivity on
the face of it.

But there are also some mitigating factors that can move it back towards
neutral in some cases. Most modern languages with large system libraries
tend to have their own best practices around case standards that
practically everyone else follows as well - Java being the prime
example. So it's not as big a deal as it might be with C or C++. And also
people that use 3rd party code libraries sometimes use wrapper functions
or Adapter patterns to interface with the other code.

> At best all language case sensitivity does is provide consistency of usage
> once an element has been defined.


And how often is an element referenced vs how often it is created? It must
be 99% of the time at least for most codebases.

> An intelligent IDE can do that for you too.


Sure, but thats a mitigating factor that brings it back to neutral
in some cases instead of being an advantage. And some (not me) might even
argue that these kinds of things should be made part of the core language
rather than the tools.

> I normally avoid case sensitive versus insensitive arguments - I don't see
> any real advantage of one over the other. The point I'm trying to make
> here is the benefit of case sensitivity is overrated.


I can accept that it's overrated, but I still think that on balance the
pros outweigh the cons.

>> Would you let different programmers on a team use different indenting
>> styles?
> > If not, why would you let them use different capitalisation styles?

> I don't disagree with consistency in coding styles. What's in dispute is
> the extent a case sensitive language helps maintain that consistency. I've
> already provided an example were it can subvert consistency.


True, but I reckon the 70% of the time where it helps consistency
outweighs the 25% of the time it is a wash either way and the 5% of the
time where it actually subverts it.

Yep those numbers are entirely pulled out of thin air

In some way it's a little bit like comparing the ease of maintenance
between Perl and Python code. Perl encourages all kinds of 'creativity'
(there's more than one way to do it) while Python aims for consistency and
obviousness up front (There should be one--and preferably only
one--obvious way to do it). I've never heard anyone argue that Perl is
easier to maintain than Python, but I've heard plenty arguing the other
way around. Sure you can write maintainable code in Perl but it requires a
lot more discipline and talent than it does in Python where the language
is designed with that in mind.

(If anyone wants to draw me into a Perl vs Python debate, it was just an
example - and I'm not biting hehe)

--
Cheers
Anton
 
Reply With Quote
 
Bok
Guest
Posts: n/a
 
      10-02-2005
AD. wrote:
>>Not entirely. All it means is they have to use the same case once the
>>program element has been defined. Language enforced case sensitivity
>>doesn't prevent a programmer from defining a new function tolower when the
>>'team' coding standard calls for mixed case ie toLower or ToLower.

>
> Wouldn't disregarding the naming standard be a bug in that case that
> needed changing?

Depends on your definition of a bug and how strictly your team enforces
coding standards. In my view, such a violation would really only be of
concern if it affected a public interface. We tend to favour discipline
over formality.

>>I normally avoid case sensitive versus insensitive arguments - I don't see
>>any real advantage of one over the other. The point I'm trying to make
>>here is the benefit of case sensitivity is overrated.

>
> I can accept that it's overrated, but I still think that on balance the
> pros outweigh the cons.

As I said I'm not strongly for or against. I've primarily been using
C/C++ for development over the last 15 years (and mostly case
insensitive languages prior to that) - case sensitivity is something I
now take for granted.

> In some way it's a little bit like comparing the ease of maintenance
> between Perl and Python code. Perl encourages all kinds of 'creativity'
> (there's more than one way to do it) while Python aims for consistency and
> obviousness up front (There should be one--and preferably only
> one--obvious way to do it). I've never heard anyone argue that Perl is
> easier to maintain than Python, but I've heard plenty arguing the other
> way around. Sure you can write maintainable code in Perl but it requires a
> lot more discipline and talent than it does in Python where the language
> is designed with that in mind.
>
> (If anyone wants to draw me into a Perl vs Python debate, it was just an
> example - and I'm not biting hehe)


Not really.
All I'll say is I quite like Python.
No comment on Perl (I did use it a bit before I discovered Python).







 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Internet Application in JBoss Portal on Liferay JBoss LprzemekL Java 0 04-10-2008 12:03 PM
Eclipse/Lomboz/JBoss: Cannot Start JBoss (Debug) Server from Eclipse Using Lomboz Plugin Jubz Java 0 05-30-2006 10:24 PM
jboss 4.0.3 jboss portal 2.2.1 han Java 0 05-08-2006 10:35 AM
RE: Link Link Link =?Utf-8?B?REw=?= Windows 64bit 0 05-17-2005 12:15 PM
Re: Link Link Link DANGER WILL ROBINSON!!! Kevin Spencer ASP .Net 0 05-17-2005 10:41 AM



Advertisments