OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Apr 18, 2024 8:01 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Programming language features
PostPosted: Mon Nov 04, 2002 5:54 pm 
Hi,

The following question may seem to be pointless to some of you, but I assure you it's not:

What kinds of "unusual" features would you like to have in a strongly typed language?

I'm not referring to any library features here, but, rather, to more fundamental concepts; however, any suggestions would be appreciated :-)

(In case you're wondering, I'm looking for ideas to explore in my (upcoming) thesis work; these features would serve (a) to check whether what I'm doing is OK wrt them, and (b) to explain why it is. Yes, I know I'm trying to abuse your creativity here... ;-)

llap,
Christoph


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Mon Nov 04, 2002 8:47 pm 
I would have to say that I wouldn't want ANY "unusual" features in my language. I would especially prefer that if there were any "unusual" components, these would be on the side and not integral to the function of the language.

Sorry...


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Mon Nov 04, 2002 9:00 pm 
I don't like C++'s unusual cin and cout functions...good think C++ compilers come with stdio.h and the other C stuff :D

But I do like C++'s object-oriented stuff..
but I don't liek C++'s weird things you do with the < and << functions...

But one weird(unusual ) thing I like about C++ is that it makes you use ->'s instead of just .'s for structures and classes.
I would like somthing that comes with C/C++ that works like the times directive in NASM ( I think that is a little unusual )


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Mon Nov 04, 2002 10:06 pm 
Hi,

to clarify: I'm not looking for syntactic features (like [tt]cout << "foo" << endl[/tt] as opposed to [tt]puts("foo")[/tt]) or issues that can be moved to modules (manual database/file system access, matrix operations etc.), but, rather, for features inherent to the language that cannot just be "imported" from a library or a header file's #defines, such as subtyping, information hiding, parametric polymorphism, pickling/marshalling/serialization etc.

Sorry for not explaining this in more detail before, and thanks for the feedback so far anyway, though!

llap,
Christoph


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Mon Nov 04, 2002 11:52 pm 
If you had done any substantial amount of LISP programming, you'd know that any 'language feature' can be provided by libraries and programmer extensions :) The fact that most other languages are insufficiently flexible is doubtless a flaw in their design...

Don't Believe me? Examples of this are the original Prolog implementations (which ran as an extension to InterLISP, IIRC); CLOS, the Common Lisp Object System (the first ANSI standard OO language, and often implemented in plain-vanilla Common LISP itself - see The Art of the Metaobject Protocol by Kiczales et. al., for more details); the various package/namespace systems that have been implemented for Scheme; the 'compatibility libraries' that most LISP implementations have, allowing them to run code from wildly different dialects unchanged; and so on.

FORTH and Smalltalk allow for similar modification of the language by way of programmer extensions, IIUC.


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Tue Nov 05, 2002 2:44 am 
looking from the C++ perspective, i don't see any way you could add something to the language that can't already be done by using templates, operator overloading, and classes.

looking from the Pascal perspective, the only improvement that can be made is taking a quick trip back in time, finding the guy that created it and shooting his bloody head off.


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Tue Nov 05, 2002 10:07 am 
What I like in a programming language, is that it's unusually easy (like AGI) and has the same capacities of C++ (Don't think such a language exists, though. <sigh>)

-Kon-Tiki-


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Tue Nov 05, 2002 2:54 pm 
Hi,

Schol-R-LEA wrote:
If you had done any substantial amount of LISP programming, you'd know that any 'language feature' can be provided by libraries and programmer extensions :) The fact that most other languages are insufficiently flexible is doubtless a flaw in their design...


I have done quite some LISP programming; however, I should point out that I was referring to typed programming languages there. While it's true that recent work by Simon Peyton-Jones has introduced powerful meta-programming facilities into Haskell (a strongly typed language), those do not appear to be guaranteed to terminate during compile time.

Schol-R-LEA wrote:
Don't Believe me? Examples of this are the original Prolog implementations (which ran as an extension to InterLISP, IIRC); CLOS, the Common Lisp Object System (the first ANSI standard OO language, and often implemented in plain-vanilla Common LISP itself - see The Art of the Metaobject Protocol by Kiczales et. al., for more details); the various package/namespace systems that have been implemented for Scheme; the 'compatibility libraries' that most LISP implementations have, allowing them to run code from wildly different dialects unchanged; and so on.

FORTH and Smalltalk allow for similar modification of the language by way of programmer extensions, IIUC.


Neither CLOS nor Smalltalk are strongly typed languages, thus this is a moot point.

llap,
Christoph


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Tue Nov 05, 2002 2:59 pm 
Hi,

grey wolf wrote:
looking from the C++ perspective, i don't see any way you could add something to the language that can't already be done by using templates, operator overloading, and classes.


Adding stuff like distributed objects, object serialization, or bounded parametric polymorphism to C++ (other than by the "implicit" ad-hoc "type" given by its template arguments) doesn't seem particularly straightforward, although I'll admit that I'm not a very experienced C++ programmer.

llap,
Christoph


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Wed Nov 06, 2002 12:33 am 
you just described Java and its many "features".

all of the things you mentioned can be done in C++ by an experienced programmer. it does, admittedly, require a bit of effort, but it is quite possible.

object serialization, BTW, is a function provided by a library in Java, so a similar feat in C++ would mean simply a new library.

honestly, i think the C++ comittee has pretty much covered everything if you're looking for a language with any obscure feature.


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Wed Nov 06, 2002 7:42 am 
This may seem off-topic, but I guess Reichenbach can use it as well (and it's interesting to know ;) )

Are there any restrictions to C++?

-Kon-Tiki-


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Wed Nov 06, 2002 9:58 am 
I don't have much programming knowledge. But, I imagine as everyone said, there could be ways to do "everything". So, how about changing the super basics. A unusual way to handle conditionals, variables, loops, etc. These seem to be basically the same across most languages, so, I suppose the only drastic change you could make to programming languages in general would be at this level. I'm not really talking about syntax as much as I am about how it is handled. I really don't know enough about programming to give any kind of example as to how one might do this.... This is kind of a shot in the dark, but, no one seems to have responded with much more than "it can all be done". I think two other areas come into play, on a assembly level, I'm sure there is some way a programming language could be set up to handle memory movements differently. The second thought is in AI. There has to be some unusual tricks that AI programmers would love to have. Ways to handle massive amounts of decisions with very little programming.

thanks,
-junc


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Wed Nov 06, 2002 1:31 pm 
Hi,

grey wolf wrote:
you just described Java and its many "features".


Well, Java doesn't have bounded parametric polymorphism yet (and it's not fully statically typesafe anyway), but the features listed were close to what it's supposed to have RSN. It does not, however, fully type side-effects (as Haskell does) or allow explicit slicing ("execute this function, but don't allow it to do file output"), which I admittedly haven't seen anywhere in live action anyway, though.

grey wolf wrote:
all of the things you mentioned can be done in C++ by an experienced programmer. it does, admittedly, require a bit of effort, but it is quite possible.


Doesn't that violate the principle of information hiding? Given an arbitrary object, how can I hope to marshal it without explicit support by its original programmer? Similarly, how can I turn it into a "networked" object if I don't have reflection capabilities to determine (at runtime) which methods the object exports in the first place?

If you have all the code, you can always work around these things by coding them by hand (or using preprocessors, which would be somewhat more appropriate). But that means it's not a language feature, or something you can provide with a library-- you'll have to use external tools.

(LISP's meta-programming facilities mentioned above try to capture as much of the potential use of pre-processing facilities as possible in-language, so they would count-- but LISP is dynamically typed and thus beyond what I'm trying to look into).

grey wolf wrote:
object serialization, BTW, is a function provided by a library in Java, so a similar feat in C++ would mean simply a new library.


I'm pretty sure it's not a library feature (although Java tries to make it look like one)-- otherwise, information hiding would be violated severely.

Note that networked objects (non-migratable ones) can be done reasonably if reflection capabilities are present, but these introduce something very similar to dynamic typing, so they're somewhat problematic from a "language safeness" point of view.

-- Christoph


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Wed Nov 06, 2002 1:42 pm 
Hi,

Kon-Tiki wrote:
This may seem off-topic, but I guess Reichenbach can use it as well (and it's interesting to know ;) )

Are there any restrictions to C++?

-Kon-Tiki-


Well, C++ is just as Turing-complete as most dialects of BASIC, shell scripts and assembly are (as well as INTERCAL and Brainfuck, of course (hey! who put that '*' character there? That's not the language's name... looks like the BBS software is broken)). The actual question you want to ask is a bit harder to formulate, I guess "are there any features useful for engineering that C++ doesn't have?" comes close.

Full static typesafeness is certainly something C++ is missing; it's type system is somewhat... original in that it combines the worst of C with just enough restrictions to allow templates to compile.

In theory, a good static type system would put strong limits on the ways in which you can screw up, while still allowing you to express (almost) everything you'd like to do without compromises. It would not allow you to use type-casts or void pointers, for one thing, since it wouldn't need to.
In Theory. In Practice, we're not quite there yet, although we're much closer to that than C++ or Java would make it seem.


-- Christoph


Top
  
 
 Post subject: Re:Programming language features
PostPosted: Wed Nov 06, 2002 1:52 pm 
Hi,

juncmodule wrote:
I don't have much programming knowledge. But, I imagine as everyone said, there could be ways to do "everything". So, how about changing the super basics. A unusual way to handle conditionals, variables, loops, etc.


Well, there are a couple of languages that don't have variables and loops, namely pure functional languages-- they're generally considered to be more readable and easier to optimize, although compiling them is somewhat slower in general (try "hello world" in Haskell versus C).

In case you're interested in this, consider a lazy evaluation language (i.e. one where

Code:
f(g(), h())


would only compute g() and h() if they were really used within f(), and then define
Code:
true(x, y) { return x;}
false(x, y) { return y;}

typedef bool = enum { true, false};

if_then_else(bool b, x, y) { return b(x, y); }

(OK, that's somewhat informal, but I hope you get the idea...)

That's a "classical" way to do this (although it's usually done in lambda calculus; I apologize for this bastardization ;-)


That's just a fun way to re-write booleans, of course; this is somewhat useful in a couple of theoretical concepts, but doesn't really help programmers much (unlike the elimination of variables and loops, although the former is somewhat problematic when trying to express certain things in some higly specific fields such as matrix computations).


-- Christoph


Top
  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 51 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group