I find it curious that as languages and applications move toward higher levels of abstraction, they still enforce strong typing. Meanwhile, programmers overload functions and methods to reduce the headache it causes.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Tuesday, August 16, 2005 7:36 PM To: [email protected] Subject: RE: [Hardhats-members] MUMPS features That's a good one, too. I'm all in favor of eliminating noise, by which I mean parts of the program that are required but not directly related to what you're trying to do. But on the other hand, I wonder what kind of code I'd want to generate from A + B if I don't know if B is 2 or 2.1. Realistically, I'd need to store at least a value and a type for each variable, and for any variable that may be bound to multiple types, I'd have to allocate storage for every different type of value. That's not a problem in an interpreted language, but it gets interesting when you stsart thinking about how you;d handle compiled code. That being said, it is entirely reasonable to say that these are details the user shouldn't need to know or care about, and that it's a problem for the compiler writer. --- Gary Monger <[EMAIL PROTECTED]> wrote: > No strong typing. > > I think of a variable as a name for something. I am not interested > in the > underlying implementation of that something. MUMPS allows me to > focus on my > algorithm, not how many bytes I need to represent an integer. > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Greg > Woodhouse > Sent: Tuesday, August 16, 2005 4:51 PM > To: [email protected] > Subject: Re: [Hardhats-members] MUMPS features > > Hmm...I hesitate to do this, for fear of forgetting something, but my > MUMPS "greatest hits" list, includes at least > > 1. Global arrays > 2. Hierarchical arrays in general, and especially the ability to > store > values at non-leaf nodes. > 3. An integrated JOB command and the $J special variable > 4. Patterns > 5. The MERGE command > 6. Built in string handling functions > 7. Incremental locks (but see below) > 8. Indirection and the XECUTE command (again with some caveats) > 9. Simplicity > > By contrast, my "biggest gripes" list includes > > 1. Default global scope for variables > 2. No static scoping > 3. No interprocess communication or asynchronous signaling > 4. Weak support for I/O > 5. I'm sorry, but 2 + 3 * 4 is NOT 20 > 6. Unintuitive (and not clearly useful) semantics for reference > parameters > 7. Incremental locks don't block (like semaphores) > 8. No distinction between read and write locks > 9. No support for namespaces or packages > 10. No flexibility with regard to character sets > > > --- Chris Richardson <[EMAIL PROTECTED]> wrote: > > > I don't have much easy association with baseball, but; > > > > 1) the polymorphic Data Representation (for SET X="12 Cats"); > > A) a string, WRITE X > > B) an expression, WRITE X+"15 Dogs" > > C) a Truth Value, IF X WRITE "True" > > D) has properties, WRITE > > %DATA(X)_":"_$LENGTH(X)_":"_$LENGTH(X," ") > > (and a lot more) > > E) has substrings, WRITE $PIECE(X," ",2) > > F) extensible, SET X=X_" and kittens" > > G) malible, FOR I=$LENGTH(X):-1:1 WRITE $EXTRACT(X,I) > > H thru ZZZ) Lots more > > 2) data clustering, for the data created by FOR I=1:1:10 SET > > X($R(100))=I > > A) Evaluated, WRITE $DATA(X) > > B) Walked, SET Y="" FOR S J=$ORDER(X($G(J)) QUIT:J="" WRITE > > X(J)_":"_J,! > > C) Copied, MERGE Z=X > > D) Trimmed, SET J=$ORDER(X("")) KILL:J X(J) > > E) Killed, KILL X > > > > More later. > > > > ----- Original Message ----- > > From: "Gregory Woodhouse" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Tuesday, August 16, 2005 7:09 AM > > Subject: [Hardhats-members] MUMPS features > > > > > > > I've been thinking about the use of strings as a uniform data > > > representation in MUMPS and, to draw an analogy with baseball, it > > is > > > easy to come up with a hit (such as the ability to use the same > > > idioms, e.g., $G(X)="" for different kinds of data), or a double > > > (such as being able to intermix numbers and strings as subscripts > > to > > > the same array), but I can't think of a real home run. Thoughts? > > > > > > === > > > Gregory Woodhouse > > > [EMAIL PROTECTED] > > > > > > "Perfection is achieved, not when there is nothing more to add, > but > > > when there is nothing left to take away." > > > -- Antoine de Saint-Exupery > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is Sponsored by the Better Software Conference & > EXPO > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > > Agile & Plan-Driven Development * Managing Projects & Teams * > > Testing & QA > > > Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > > _______________________________________________ > > > Hardhats-members mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > > & QA > > Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > "Design quality doesn't ensure success, but design failure can ensure > failure." > > --Kent Beck > > > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
