Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2006

Tip: Looking for answers? Try searching our database.

4 .Net contract positions

Thread view: 
luckystarduke - 19 May 2006 18:36 GMT
Hello All,

We have the following requirement.

Please send me matching Profiles along with the Contact Details,
Availability and Rate Expectations of the Candidate for the same.

Job Details:- We have the following 4 .Net contract positions in NYC.
Location:- NYC.
Duration:- 6 months +
Rate:- DOE.

FINANCIAL EXPERIENCE IS REQUIRED!!!

Major Responsibilities/Essential Functions:
Program using C#, ASP.NET and JavaScript.
Program using T-SQL in SYBASE or MS SQL Server. Must have good
knowledge of ADO.
Program for browser using HTML, DHTML, JavaScript, XML, XSL, HTTP. Must
have a good understanding for DOMs (HTML and XML).

Let me know if you need more information on the same.

Many Thanks,

Renuka
Technical Recruiter
KLM Software Services Inc.
1111 N. Plaza Dr
Suite 101
Schaumburg, IL 60173
Tel : 847-995-9556 Ext 212
Fax : 847-995-9557
Oliver Wong - 19 May 2006 19:00 GMT
> Job Details:- We have the following 4 .Net contract positions in NYC.
> Location:- NYC.
> Duration:- 6 months +
> Rate:- DOE.

   What's DOE? "Depends on Expertise" or something like that?

   - Oliver
Frank Seidinger - 20 May 2006 10:17 GMT
Oliver Wong schrieb:

>     What's DOE? "Depends on Expertise" or something like that?
>
>     - Oliver

I guess, that the original poster could answer your question. And I also
guess, that this will never happen. I consider this and similar posts in
other groups as spam and act accordingly.

Frank.

Signature

Geld allein macht nicht glücklich.
Es kommt auch auf die Menge an...

Rhino - 20 May 2006 00:48 GMT
> Hello All,
>
[quoted text clipped - 18 lines]
>
> Let me know if you need more information on the same.

This is not a very appropriate place to post this ad. You are looking for
JavaScript talent but this is a Java newsgroup. Java and JavaScript, despite
the similar names, are completely unrelated.

A better place to try would be comp.lang.javascript.

--
Rhino
Stefan Ram - 20 May 2006 01:33 GMT
>Java and JavaScript, despite the similar names, are completely
>unrelated.

 Both are trademarks of Sun Microsystems, Inc.:

http://www.sun.com/suntrademarks/

 And Java includes a JavaScript interpreter:

public class Main
{ public static void main( final java.lang.String[] args )
 { javax.script.ScriptEngineManager scriptEngineManager =
   new javax.script.ScriptEngineManager();
   javax.script.ScriptEngine scriptEngine =
   scriptEngineManager.getEngineByName( "rhino" );
   try
   { final java.lang.String myJavaScriptExpression = "1 + 10 * 10";
     java.lang.System.out.println
     ( scriptEngine.eval( myJavaScriptExpression )); }
   catch( final javax.script.ScriptException scriptException )
   { throw new java.lang.RuntimeException( scriptException ); }}}

101.0

 Is that »completely unrelated«?
Chris Smith - 20 May 2006 03:08 GMT
> >Java and JavaScript, despite the similar names, are completely
> >unrelated.
>
>   Both are trademarks of Sun Microsystems, Inc.:

Which would be relevant, if the name JavaScript were anything other than
marketing.  However, the language popularly known as JavaScript was
originally developed by Netscape under the name "LiveScript", and is
properly standardized under the name "ECMAScript".  Two popular
implementations of that spec are Microsoft's JScript and Netscape's
LiceScript, which is now called JavaScript.  The popular name was
introduced after the language had been developed independently of Java.

>   And Java includes a JavaScript interpreter:

Beginning on Java 6, Java WILL be distributed with a JavaScript
interpreter, as an example of a standard scripting language API.  Java
doesn't include (poresent tense) a JavaScript interpreter.  It is also
certainly not the case that the API will be in any way specific to
JavaScript; that just happens to be a convenient initial implementation.  
This is similar to the way Java currently "includes" XML, XSLT, and
XPath implementations.  No one could reasonably claim that XML, XPath,
and XSLT are related to Java because Java provides an API and default
implementation for using them.

>   Is that »completely unrelated«?

Yes, in all important senses in which the term is meant here.  The
languages are almost as different as two object oriented languages can
be except for sharing a few grammatical productions and basic operators
inherited from C.

If "exists in the same universe as" or "can be used with" count as
related, to you, then you can claim some kind of empty rhetorical
victory for this thread... but it won't mean anything.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Stefan Ram - 20 May 2006 03:38 GMT
>Yes, in all important senses in which the term is meant here.
>The languages are almost as different as two object oriented
>languages can be except for sharing a few grammatical
>productions and basic operators inherited from C.

 Yes, if you ignore or sweep aside all the features they have
 in common, there will be those features left, which they do
 not have in common. They are both imperative languages
 compared to declarative languages such as Prolog or
 functional languages such as Haskell and, thus, belong
 to the same »language family«. Within this family they
 even are in the same »subfamily« with a C-based syntax
 compared to languages with a Pascal-like syntax (»begin«,
 »end«) or with a special syntax (like Lisp or Forth).

>If "exists in the same universe as" or "can be used with" count
>as related, to you, then you can claim some kind of empty
>rhetorical victory for this thread... but it won't mean
>anything.

 By your above criteria, it seems as if you'd call two languages
 "not completely unrelated" only if they are essentially the
 same language.

 By the Merriam-Webster Online Dictionary, two things do not
 even have to be similar in any way to relate to each other,
 they just need »to have relationship or connection«.
Chris Smith - 20 May 2006 05:12 GMT
>   Yes, if you ignore or sweep aside all the features they have
>   in common, there will be those features left, which they do
>   not have in common.

And quite a few features there are in that set.  JavaScript has no types
at all, while Java provides moderately strong type rules.  JavaScript
has no classes and implements object prototypes for inheritance of
implementation, while Java requires that everything belongs to a class
and has no concept of a prototype.  JavaScript implements general
lexical scoping rules with full closure, while Java has more limited and
irregular rules of scope and accessibility.

These are fairly deep distinctions between the two languages.  Not as
deep as the distinction between JavaScript and Prolog, to be sure, but
it makes JavaScript far closer to quite a few other languages than it is
to Java, and vice versa.  The differences between Java and JavaScript
lead to rather important implications in the way one would accomplish
even everyday programming tasks.

So, when regulars on this group say that Java is not JavaScript, it
isn't just a deflection of a question to which we all know the answer.  
We aren't nitpicking.  Java is far closer, for example, to Eiffel than
it is to JavaScript -- despite the fact that Eiffel looks rather
radically different, while JavaScript shares both a name and things like
curly braces to delineate blocks.  A persone would be acting more
reasonably to post questions about Eiffel here than questions about
JavaScript.

I don't really care to discuss the exact definition of "related".  We
all know what Rhino meant.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Timo Stamm - 20 May 2006 06:25 GMT
Chris Smith schrieb:
>>   Yes, if you ignore or sweep aside all the features they have
>>   in common, there will be those features left, which they do
[quoted text clipped - 4 lines]
> has no classes and implements object prototypes for inheritance of
> implementation

The JavaScript implementation of Mustang is /based/ on Rhino. So we
don't know which Version of ECMAScript we are going to see.

If it is ECMAScript-262 Edition 3 (also known as JavaScript 1.5), you
are right. It has no typing and only prototype inheritance. The edition
4 however defines strong typing as well as class based inheritance.

ECMAScript 4 is as much Java as a scripting language could be while
still being called a scripting language.

Timo
Chris Smith - 21 May 2006 18:17 GMT
> If it is ECMAScript-262 Edition 3 (also known as JavaScript 1.5), you
> are right. It has no typing and only prototype inheritance. The edition
> 4 however defines strong typing as well as class based inheritance.

That's a shame.  Shall all languages become identical, now?

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Uppal - 22 May 2006 10:41 GMT
> > If it is ECMAScript-262 Edition 3 (also known as JavaScript 1.5), you
> > are right. It has no typing and only prototype inheritance. The edition
> > 4 however defines strong typing as well as class based inheritance.
>
> That's a shame.  Shall all languages become identical, now?

If Microsoft get their way, yes.

As I understand it, classes were added to ECMAScript at the urging of
Microsoft -- who's CLR has classes hardwired into it.

Damn shame.

   -- chris
Stefan Ram - 22 May 2006 16:45 GMT
>As I understand it, classes were added to ECMAScript at the
>urging of Microsoft -- who's CLR has classes hardwired into it.

 I believe that the common practice to consider languages as
 changeable is misleading. I.e., I do not oppose that Microsoft
 Corporation implements whatever language they want on their
 platform, but I disapprove it to use the same name as for
 another language. I.e., they should not call it »JavaScript«.

 I also have nothing against languages that do not support
 the commands INPUT, DATA, READ, DEF FN and line numbers.
 But, I think that they should not be called »BASIC«.

 We all would oppose a /change/ of the interface CharSequence
 (for example to an interface for codepoints with 32 bit),
 because it breaks existing code. It would be no problem
 instead, if another interface would be added with /another
 name/.

 Languages are (like) interfaces. So if »classes are added to
 JavaScript (ECMAScript)« existing assertions about it are
 broken. For example, a tutorial claiming that »there are no
 classes in JavaScript (or ECMAScript)« is now wrong (broken).
 So I'd prefer "value semantics" for names of programming
 languages. When the language »changes« in a major or relevant
 way, it should get a new name.

 A partial remedy might be to always use versions when speaking
 of languages. So, one should not say »JavaScript does not have
 classes« but »JavaScript 1.0 does not have classes.«.  
 But then, the assertion is too limited. The reader, who wants
 to learn »JavaScript 1.1« does not know whether this still
 applies there. So it should be »JavaScript 1.0-1.3 does not
 have classes.«. But this is complicated and now also needs
 maintanance: When JavaScript 1.4 appears and still does not
 have classes, the sentence does not become false, but should
 be changed to »JavaScript 1.0-1.4 does not have classes.«
Chris Uppal - 23 May 2006 13:40 GMT
>   Languages are (like) interfaces. So if »classes are added to
>   JavaScript (ECMAScript)« existing assertions about it are
>   broken.

Interesting idea.  A more general approach to the problem would be for people
to stop making assertions of temporally contingent truths as if they were
absolutes.  So we get:

   JavaScript is (in 1997) a classless language.

I don't kow how often one could use such dates without the message getting lost
in qualifications, but I think we (humans) could do better than we do[*].

But in this case the real issue (IMO) isn't that JavaScript has /changed/ but
that it been /spoiled/.

   -- chris

[*] In 2006 ;-)
Oliver Wong - 23 May 2006 15:15 GMT
>>   Languages are (like) interfaces. So if »classes are added to
>>   JavaScript (ECMAScript)« existing assertions about it are
[quoted text clipped - 6 lines]
>
>    JavaScript is (in 1997) a classless language.

   I think using version numbers is safer. As Stefan pointed out, if you
say "JavaScript 1.0 to 1.3 is classless", and then 1.4 comes out and is also
classless, you'd have to maintain/update your old assertion. But you'd have
to always updated your old assertion anyway, because you never know whether
the next version will have classes or not.

   The advantage of version numbers over years is that when a change
happens (e.g. classes are added to JavaScript), it's difficult to refer to
exactly when the change occured in terms of time, but relatively easy to
refer to it in terms of version number (contrast "JavaScript was classless
up to and including May 26th, 2006, 8:43.23.8299 AM, but has classes
immediately after that" with "JavaScript was classless up to 1.4. In 1.5, it
has classes.")

   - Oliver
Stefan Ram - 23 May 2006 15:28 GMT
>up to and including May 26th, 2006, 8:43.23.8299 AM, but has classes

 Such points of time also have the drawback that they are not
 Lorentz invariant, i.e., they can not be extended to the whole
 spacetime unless a specific frame of reference is chosen.

 For a long text about JavaScript, it might be tedious to
 repeat the version number over an over, so the text might
 declare initially that »JavaScript« in the text is to be
 understood as a certain version or range of versions.
Oliver Wong - 23 May 2006 15:37 GMT
>>up to and including May 26th, 2006, 8:43.23.8299 AM, but has classes
>
>  Such points of time also have the drawback that they are not
>  Lorentz invariant, i.e., they can not be extended to the whole
>  spacetime unless a specific frame of reference is chosen.

   I had assumed the frame of reference would be of that of the person who
is releasing the (new version of the) language.

   - Oliver
Chris Smith - 23 May 2006 16:00 GMT
>   Such points of time also have the drawback that they are not
>   Lorentz invariant, i.e., they can not be extended to the whole
>   spacetime unless a specific frame of reference is chosen.

I don't know that "drawback" is the word I would have chosen.  Perhaps
"property that is irrelevant in practice". :)

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Smith - 22 May 2006 17:28 GMT
> As I understand it, classes were added to ECMAScript at the urging of
> Microsoft -- who's CLR has classes hardwired into it.

Ah.  So we've now got at least a mangled Visual Basic, C++, JavaScript,
and an attempt at mangling Java.  Anyone else wish that .NET weren't
"portable across programming languages"?

(On the other hand, .NET really no longer has nothing to do with
bytecode or the CLR or such things any longer.  According to Microsoft
at http://www.microsoft.com/net/basics.mspx, .NET is now just another
word for web services. :)

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Uppal - 23 May 2006 13:28 GMT
> Ah.  So we've now got at least a mangled Visual Basic, C++, JavaScript,
> and an attempt at mangling Java.  Anyone else wish that .NET weren't
> "portable across programming languages"?

...or that it was in fact programming-language agnostic.

> (On the other hand, .NET really no longer has nothing to do with
> bytecode or the CLR or such things any longer.  According to Microsoft
> at http://www.microsoft.com/net/basics.mspx, .NET is now just another
> word for web services. :)

Nice link.  Very informative.  I even went to the trouble of clicking the "Rate
this article" button[*].

   -- chris

[*] I choose "Poor", but only for the lack of "Insultingly bad".
Stefan Ram - 20 May 2006 06:33 GMT
>I don't really care to discuss the exact definition of "related".

 There is no need to discuss it, because nobody has called the
 meaning of »related« into question and the common meaning of
 that word is well established. »related« means »related«, not
 »similar« or »equal«. »completely« means »totally« or »without
 any exception«, so »completely unrelated« means »without any
 relation«.

 When I look at the »Core JavaScript 1.5 Reference«, I can read:

     »These classes allow a Java object to access JavaScript code.«

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:LiveConnect

 This is at least one relation that suffices to contradict the
 apodictic assessment »completely unrelated«.
Arvind - 23 May 2006 17:15 GMT
<snip>
> And quite a few features there are in that set.  JavaScript has no types
> at all, while Java provides moderately strong type rules.
> --
<snip>

Javascript does support c-like Structure....you can define a structure

function dog (name)
{
 this.name = name;
}

and then instantiate it too...

var mydog = new dog('Tony');

--
Arvind
Chris Smith - 23 May 2006 18:43 GMT
> Javascript does support c-like Structure....you can define a structure

No, it doesn't.  JavaScript implements objects (it is, after all, an OO
language).  However, there is nothing analogous to a struct or class,
which would be an external specification of what members certain
categories of objects have.

> function dog (name)
> {
[quoted text clipped - 4 lines]
>
> var mydog = new dog('Tony');

and then

 var yourdog = new dog('Fido');

 mydog.poodlePoofiness = true;
 if (yourdog.poodlePoofiness == false) ... /* CRASH */

So you see, each object and its members are distinct from any other
object and its members.  The function that was used as a constructor for
the object is just that: an implementation choice of how to create an
object.  It is no more a part of that object's identity than which
method you called last.

That doesn't fit the definition of a class or a struct.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Arvind - 23 May 2006 19:20 GMT
> > Javascript does support c-like Structure....you can define a structure
>
[quoted text clipped - 26 lines]
>
> That doesn't fit the definition of a class or a struct.

I am not sure i understood your argument, mypoint was about the
reference to types. Now this 'dog' type can definitely be passed around
and used like any other object....

<!--
<script>
function dog(nm)
{
 this.name = nm;
 //this.age = 5;
}

var mydog = new dog('roger');
var yourdog = new dog('smith');

mydog.age = 1;
yourdog.age = 2;

alert ("mydog.name="+mydog.name+" and mydog.age="+mydog.age);
alert ("yourdog.name="+yourdog.name+" and yourdog.age="+yourdog.age);

</script>
-->

--
Arvind
Chris Smith - 23 May 2006 20:45 GMT
> I am not sure i understood your argument, mypoint was about the
> reference to types.

JavaScript has no types.  We weren't talking about types, anyway.  We
were talking about classes, which JavaScript (some versions) also
doesn't have, nor does it have anything like them.  You are attributing
too much meaning to "new dog(...)".

> Now this 'dog' type can definitely be passed around
> and used like any other object....

JavaScript DOES have objects.  That doesn't mean it has classes or
types.

There is do 'dog' type.  The only thing called 'dog' here is a function,
which happens to have been used as a constructor to create an object.  
The interpreter doesn't possess any knowledge about that object just by
virtue of its having been created by using the 'dog' function as a
constructor.  I could just as easily write:

 var herdog = new Object();
 herdog.name = 'Buddy';
 herdog.age = 1;

Now this new variable 'herdog' can be used in exactly the same places
and contexts as the variables 'mydog' and 'yourdog'.  If I then wanted
to pass 'herdog' to the airline reservation subsystem, I could write:

 herdog.carrier = 'United';
 herdog.flightNum = '1234';
 herdog.departure = new Date();
 reserveSeat(herdog, 'Prefer Window Seat');

That's what it means to not have types or classes.  'herdog' does not
necessarily have anything in common with any object that was created
with any particular constructor.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Arvind - 23 May 2006 21:07 GMT
> > I am not sure i understood your argument, mypoint was about the
> > reference to types.
[quoted text clipped - 15 lines]
> virtue of its having been created by using the 'dog' function as a
> constructor.

True, never looked at it from that perspective. Agreed

> I could just as easily write:
>
[quoted text clipped - 5 lines]
> and contexts as the variables 'mydog' and 'yourdog'.  If I then wanted
> to pass 'herdog' to the airline reservation subsystem, I could write:

Yes, this substantiates, that you pass around Objects, but not defined
'type'd objects as parameters

>   herdog.carrier = 'United';
>   herdog.flightNum = '1234';
[quoted text clipped - 4 lines]
> necessarily have anything in common with any object that was created
> with any particular constructor.

Makes sense !

--
Arvind
Mickey Segal - 20 May 2006 05:50 GMT
> Two popular implementations of that spec are Microsoft's
> JScript and Netscape's LiceScript, which is now called JavaScript.

If Netscape's implementation was such that people took to calling it
"LiceScript", no wonder people were willing to accept the confusing name of
"JavaScript".


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.