Java Forum / General / May 2006
4 .Net contract positions
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 MagazinesGet 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 ...
|
|
|