core features and functions required in modern programming l

Interesting places

news.only-4-geeks.com Forum Index » Programming

Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9 Next


	core features and functions required in modern programming l

Jump to:

Neil Morris

Posted: Thu Jul 24, 2008 5:58 pm Post subject: core features and functions required in modern programming l

Dear All

Having read/studied a few programming languages I would be interested to
know the core features functions etc that would be most desired? I have
listed below some features I would like to see.

1. ease of scripting languages with the near speed of compiled ones
2. linked to a core library of functions ie glibc
3. mozilla's XUL
4. SDL graphics opengl library
5. mozilla's XUL linked to 3. and 4.
6. message sending and receiving features such as SOAP WDSL RDF WDDX and
RPC
7. bytecode VM that can be translated in the native or targeted host
system via a JIT compiler
8. designed mainly for dymanic languages
9. reverse polish notation ie forth and postscript as core language
design or used as lower level conversation
10. MACROS like features
11. conditional compilation

any suggestions wellcome!

Neil Morris

S James S Stapleton

Posted: Thu Jul 24, 2008 6:04 pm Post subject: Re: core features and functions required in modern programmi

"Neil Morris" <neil.morris2@virgin.net> wrote in message
news:n95ik.26877$WT.25097@newsfe29.ams2...

Quote:

Dear All

Having read/studied a few programming languages I would be interested to
know the core features functions etc that would be most desired? I have
listed below some features I would like to see.

1. ease of scripting languages with the near speed of compiled ones
2. linked to a core library of functions ie glibc
3. mozilla's XUL
4. SDL graphics opengl library
5. mozilla's XUL linked to 3. and 4.
6. message sending and receiving features such as SOAP WDSL RDF WDDX and
RPC
7. bytecode VM that can be translated in the native or targeted host
system via a JIT compiler
8. designed mainly for dymanic languages
9. reverse polish notation ie forth and postscript as core language design
or used as lower level conversation
10. MACROS like features
11. conditional compilation

- Trivial C interaction, both in accessing libraries in the language from C,
and Writing C modules (libraries) for the language.

C is the most common programming language I've seen other languages able to
interact with, so it seems C is a logical choice to make the language able
to interact with as many languages as possible.

jimmaureenrogers@worldnet

Posted: Thu Jul 24, 2008 8:02 pm Post subject: Re: core features and functions required in modern programmi

On Jul 24, 1:58 pm, Neil Morris <neil.morr...@virgin.net> wrote:

Quote:

I suspect we can each come up with our own list of features.
For instance, I would not include any of the items in the above list.

Jim Rogers

Rod Pemberton

Posted: Thu Jul 24, 2008 8:10 pm Post subject: Re: core features and functions required in modern programmi

"James Harris" <james.harris.1@googlemail.com> wrote in message
news:f4fd39e2-7206-4cc7-98a5-f6e10f11a0e5@j33g2000pri.googlegroups.com...

Quote:

On 24 Jul, 20:58, Neil Morris <neil.morr...@virgin.net> wrote:

Having read/studied a few programming languages I would be interested to
know the core features functions etc that would be most desired? I have
listed below some features I would like to see.

1. ease of scripting languages with the near speed of compiled ones

Scripting languages, batch languages, aren't needed... IMO. I miss the more
rapid development on interpreters. But, if it can't produce an executable
binary, it has little value to me.

Quote:

2. linked to a core library of functions ie glibc

Libraries aren't needed, if the core language allows dynamic memory
allocation, and file I/O.

Quote:

3. mozilla's XUL

? Never heard of it.

Quote:

4. SDL graphics opengl library
Let's break that into two:

Quote:

4. SDL

SDL's (Simple DirectMedia Layer) best feature is that it allows emulation of
a source code OS (operating system), in SDL, on another OS. An SDL library
would be useful for an OS, or powerful language.

Quote:

4. opengl library

I think the graphics library should be left upto the host OS since the
functions required to get best results from graphics cards must go through
an/or bypass the OS's privilege and control mechanisms and are usually
highly custom to the graphics card chipset.

Quote:

5. mozilla's XUL linked to 3. and 4.

What's the purpose of XUL and/or XML?

Quote:

6. message sending and receiving features such as SOAP WDSL RDF WDDX and
RPC

Almost never heard of them. Why would you want message passing in a general
purpose programming language? Most language designs avoid this because of
the large overhead needed to implement them.

Quote:

7. bytecode VM that can be translated in the native or targeted host
system via a JIT compiler

VM's with bytecode is nice for portability. The question is do you really
need portability? x86 cpu's control 97% of the PC market and a large
percentage of higher processing markets. ARM controls the embedded market.
At most, you only need a compiler that supports two platforms. I.e., what's
the purpose, other than slow down the host system while the JIT compiles the
code?

Quote:

8. designed mainly for dymanic languages

Are you referring to a dynamicly typed language? I'm not sure if I want to
see a dy-manic language... ;-0

Anyway, this seems to be related to your preference for, uh, the "ultimate"
interpreted "connect to everything" language...

Quote:

9. reverse polish notation ie forth and postscript as core language
design or used as lower level conversation

IMO, this is a step backwards. There is nothing wrong using these in a
compiler. But, the reason FORTH (and probably PS, it's been a while since I
did and PS programming...) don't get adopted as primary languages is that 1)
they lack enough syntax that it's difficult for most people to follow what's
going on. And, 2) they require the user to keep track of variables, which
is a monumental task on larger applications.

Quote:

10. MACROS like features

Is this another language, or did you mean macro's, like those in an
assembler?

Quote:

11. conditional compilation

That's called a preprocessor. Public Domain (der Mouse, 3 variations of
DECUS, SCPP) and FOSS (had links to three - all dead now...) C preprocessors
exist. The C preprocessor will work with any language without a syntax
conflict (rare).

Quote:

(nothing for James...) Smile

This is my list:

1) language has both low level and higher level programming features (like
C)
2) language should have variables, unsigned integers, arrays, and strings
(floating point not necessary)
3) the low level features should closely correspond to the cpu's assembly
abilities
4) the higher level features should provide:
4a) flow control, variable allocation, abilities to manipulate
integers, arrays, strings
4b) dynamic memory allocation, functions for file I/O
5) the language, even if interpreted, should be able to produce binaries

(and a bunch of other useful stuff I'm probably forgetting...)

Rod Pemberton

James Harris

Posted: Thu Jul 24, 2008 8:22 pm Post subject: Re: core features and functions required in modern programmi

On 24 Jul, 20:58, Neil Morris <neil.morr...@virgin.net> wrote:

Quote:

There is a newsgroup specifically for language design, comp.lang.misc,
so am including that....

FWIW I don't like your list much. It seems like an ad-hoc feature list
related to some technologies that are currently in vogue. A general
purpose language should be more cohesive (i.e. have few "features" and
instead concentrate on unifying principles). Other things can be
provided by standard libraries but, IMHO, even these should be
minimalist. (This is NOT the path taken by Java which has extensive
libraries.)

Check out Principles of Programming Languages by Bruce MacLennan

LINK

for a clear set of guidelines to language design.

Gene

Posted: Thu Jul 24, 2008 10:44 pm Post subject: Re: core features and functions required in modern programmi

On Jul 24, 3:58 pm, Neil Morris <neil.morr...@virgin.net> wrote:

Quote:

I recommend you get a few good textbooks on the topic of programming
languages. Check the web pages of some high quality comp sci undergrad
language courses for titles. Study hard. From the new vantage point
you've gained, look again at a big collection of languages. Make sure
to include functional and logic programming, concurrent and
distributed programming as well. You'll have to write some programs
in each of a representative smattering of the entire range. Then
build a new list and ask your question on comp.lang.misc.

cr88192

Posted: Fri Jul 25, 2008 1:36 am Post subject: Re: core features and functions required in modern programmi

"Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message
news:g6aumk$62a$1@aioe.org...

Quote:

"James Harris" <james.harris.1@googlemail.com> wrote in message
news:f4fd39e2-7206-4cc7-98a5-f6e10f11a0e5@j33g2000pri.googlegroups.com...
On 24 Jul, 20:58, Neil Morris <neil.morr...@virgin.net> wrote:

Having read/studied a few programming languages I would be interested
to
know the core features functions etc that would be most desired? I have
listed below some features I would like to see.

1. ease of scripting languages with the near speed of compiled ones

Scripting languages, batch languages, aren't needed... IMO. I miss the
more
rapid development on interpreters. But, if it can't produce an executable
binary, it has little value to me.

yes, which is partly why I still stick mostly to C (I have forrays into C++
and Assembler, however, these are lesser used languages in my case).

and, having a scripting engine I can actually tolerate, as it so happens, it
compiles C code into native machine code. of course, it would be nicer if
some more of the technical issues/bugs were worked out, and the thing
compiled faster (a compiler design based heavily around XML DOM trees is not
the fastest thing around it seems, or at least when faced with big masses of
system headers...).

several seconds per-module can get a little more tiring than it would at
first seem...

an eventual option would likely be to make use of caching:
the compiler keeps around a big cache of ELF or COFF files, and re-uses
previously compiled modules if the file is unmodified and the dependencies
hold.

another issue is that the compiler keeps trying to multiply-link XML nodes
for some reason (ie, where it tries to include the same node in multiple
parent nodes), which results in cloning the nodes in question (as well as
issuing a warning message).

Quote:

2. linked to a core library of functions ie glibc

Libraries aren't needed, if the core language allows dynamic memory
allocation, and file I/O.

more likely:
can make use of the libraries that already exist, if it is a general-purpose
language.

it is the case for many special purpose languages that they need nothing
really beyond the core stuff needed to complete their task (for example, the
language may not even allow recursion).

Quote:

3. mozilla's XUL

? Never heard of it.

it is an XML-based representation for describing GUI's.

a slightly alternate option (something I had used before), was to make an
XML syntax mostly derived from GTK and HTML forms (some GTK constructions
replacing what would have been done via formatting features in HTML).

Quote:

4. SDL graphics opengl library
Let's break that into two:

4. SDL

SDL's (Simple DirectMedia Layer) best feature is that it allows emulation
of
a source code OS (operating system), in SDL, on another OS. An SDL
library
would be useful for an OS, or powerful language.

in my case, it would just be nice if some more things were standardized
between OS's, and that people would stop making a mess of things by trying
to endlessly re-invent everything.

but, then again, I am guilty to some extent of re-inventing things as well,
but mostly in areas where agreement is not generally reached between
OS's/frameworks (GC API, threads, sockets, ...).

but, at the same time, little prevents one from using the Win32 API or
pthreads or whatever in my case either...

ok, I don't generally use SDL in my case (I had personally found it more
painful than it was worth, since the native APIs tend to exist on the
systems in question, but SDL often has to be built and installed).

Quote:

4. opengl library

I think the graphics library should be left upto the host OS since the
functions required to get best results from graphics cards must go through
an/or bypass the OS's privilege and control mechanisms and are usually
highly custom to the graphics card chipset.

however, at least in the case of OpenGL, it is present on a wide variety of
OS's (Windows, Linux, some game consoles, many embedded systems, ...).

of course, many Windows (and XBox) developers would probably insist on
DirectX, but oh well...

Quote:

5. mozilla's XUL linked to 3. and 4.

What's the purpose of XUL and/or XML?

at least in my case, they are a fairly useful way of representing abstract
data and trees (albeit S-Expressions, or other more 'native' structures,
tend to be much more efficient).

Quote:

6. message sending and receiving features such as SOAP WDSL RDF WDDX
and
RPC

Almost never heard of them. Why would you want message passing in a
general
purpose programming language? Most language designs avoid this because of
the large overhead needed to implement them.

they could exist as library features, but IMO should be avoided as core
functionality (IMO, it is better to leave features out of the language
compiler/syntax proper if they can be more or similarly effectively pulled
of with library code).

even within a single process, certain kinds of message passing can be rather
useful (for example, a messaging system between threads, between the GUI
framework and app, ...).

Quote:

7. bytecode VM that can be translated in the native or targeted host
system via a JIT compiler

VM's with bytecode is nice for portability. The question is do you really
need portability? x86 cpu's control 97% of the PC market and a large
percentage of higher processing markets. ARM controls the embedded
market.
At most, you only need a compiler that supports two platforms. I.e.,
what's
the purpose, other than slow down the host system while the JIT compiles
the
code?

similar reasoning in my case, albeit x86-64 is rapidly growing, and may be
non-trivial to target (as I have found, due in large part to the complex
calling convention used on Linux and friends).

I don't really understand it anyways, noting that the register/memory
jerkoffs one has to go through may well cost more than the speedup of the
minor speed difference between registers and the CPU's local cache (where
the stack frames are almost invariably located).

IMO, the Win64 convention is less absurdly designed, but oh well...

Quote:

8. designed mainly for dymanic languages

Are you referring to a dynamicly typed language? I'm not sure if I want
to
see a dy-manic language... ;-0

Anyway, this seems to be related to your preference for, uh, the
"ultimate"
interpreted "connect to everything" language...

I use some dynamic features in C, and they are useful.

in all though, it is fairly similar to RTTI in C++ (only that I tend to test
using predicate functions rather than 'dynamic_cast' and similar...).

Quote:

9. reverse polish notation ie forth and postscript as core language
design or used as lower level conversation

IMO, this is a step backwards. There is nothing wrong using these in a
compiler. But, the reason FORTH (and probably PS, it's been a while since
I
did and PS programming...) don't get adopted as primary languages is that
1)
they lack enough syntax that it's difficult for most people to follow
what's
going on. And, 2) they require the user to keep track of variables, which
is a monumental task on larger applications.

yes, even then, one discovers that it only really makes sense as a
mid-level, if one is compiling to native code (where the much bigger part of
the compiler actually turns out being efficiently compiling this RPN-style
notation into native machine code...).

while I was still working on it, my newer compiler core had ended up going
from RPN to SSA, and then (incomplete), converting the SSA into commands for
a lower-level code generator (operated with yet more XML manipulation...).

if I resume this effort, I may likely replace this lower XML-level with an
S-Expression based form (as I had discovered in the RPN->SSA process, and in
the SSA manipulation code, S-Exps seem to work a lot better for this type of
thing, as well as being the higher-performance option).

basically, the awkward logic and munging of the parser and upper compiler
and similar, work better with XML, but the much more rigid transforms of the
lower compiler stages, and the linear relay of information and commands,
seem better suited to s-expressions.

Quote:

10. MACROS like features

Is this another language, or did you mean macro's, like those in an
assembler?

maybe he meant MACROSS...
yes, giant alians really can be turned into allies with the power of
music...

Quote:

11. conditional compilation

That's called a preprocessor. Public Domain (der Mouse, 3 variations of
DECUS, SCPP) and FOSS (had links to three - all dead now...) C
preprocessors
exist. The C preprocessor will work with any language without a syntax
conflict (rare).

I can imagine a few cases.
I guess it depends mostly on the type of syntax and tokenizing behavior.

for example, the C preprocessor would be a really bad fit for languages such
as LISP, Python, Smalltalk, ...

but then again, I have seen such syntactic horrors as, IMO, Objective-C.
actually, IMO, Brook+ is ugly, but at least this is likely to be far more
contained.

if I were to do similarly, it would likely be far more subtle:
a few special keywords (and likely also following the standard rules for
extensions, even if not the prettiest, macros can remedy this).

#define vector _Vector
....

vector float a[10][10], b[10][10], c[10][10];

c=a*a+b;

going a little further, one could add some minor tweaks to allow tensor
operations.

of course, Brook+ and Obj-C both have justifications for their horrid
syntax:
both were designed effectively as preprocessors which extract and rewrite
the code in question (in the case of Brook+, forming both C-based output,
and other code intended to be compiled and run on the GPU).

likely though, anything I added to my compiler would not likely run on the
GPU, since this is difficult to do generally and portably (thus far I mostly
target the GPU by going through OpenGL...).

most of what I have then, in my compiler, is utility functions for
convinient vector operations, which I can then optimize (eventually, GPU
targetting could be done via more conventional optimizations being applied
to already existing code).

for example, whenever one writes a loop performing certain kinds of
operations (such as loops linearly processing large arrays of numbers of
vectors), the compiler may be inclined to try to pass it off to the GPU...

Quote:

(nothing for James...) :-)

This is my list:

1) language has both low level and higher level programming features (like
C)
2) language should have variables, unsigned integers, arrays, and strings
(floating point not necessary)
3) the low level features should closely correspond to the cpu's assembly
abilities
4) the higher level features should provide:
4a) flow control, variable allocation, abilities to manipulate
integers, arrays, strings
4b) dynamic memory allocation, functions for file I/O
5) the language, even if interpreted, should be able to produce binaries

(and a bunch of other useful stuff I'm probably forgetting...)

yes, and luckily C already has these features...

C could use more reflection ability and more dynamic features (such as
dynamic loading and evaluation), then again, this is largely why I wrote a
compiler...

Quote:

Rod Pemberton

Guest

Posted: Sun Jul 27, 2008 4:58 pm Post subject: Re: core features and functions required in modern programmi

Quote:

Libraries aren't needed, if the core language allows dynamic memory
allocation, and file I/O.

ROTFL.

Quote:

3. mozilla's XUL

? Never heard of it.

Normally this would disqualify you from any further discussion.
You don't need to know it but you should have heared about it.

Quote:

VM's with bytecode is nice for portability. The question is do you really
need portability? x86 cpu's control 97% of the PC market and a large
percentage of higher processing markets.

And here you finally write to much bullshit.
On Desktops it's not so much about architectures but about OS. We have
Windows,Linux,FreeBSD,Solaris in both i386 and amd64.
Add NetBSD,HP-UX,OpenBSD as server systems. With servers we get
Sparc,
Power PC and Itanium as other architectures.

In the embedded you can also add hundert smaller (but yes there you
don't need
a VM because apps are much stricter deployed and you can live with a
"compile everywhere"
instead of "compile once".

gremnebulin

Posted: Sun Jul 27, 2008 6:43 pm Post subject: Re: core features and functions required in modern programmi

On 24 Jul, 20:58, Neil Morris <neil.morr...@virgin.net> wrote:

Quote:

Can always be bolted on with libraries, as it usually is. Or do you
mean support
in the basic syntax/keywords?

Quote:

7. bytecode VM that can be translated in the native or targeted host
system via a JIT compiler
8. designed mainly for dymanic languages
9. reverse polish notation ie forth and postscript as core language

Huh? Do you mean "intermediate" language? But why would you need a
forth-type language AND bytecode as intermediates?

Quote:

design or used as lower level conversation
10. MACROS like features

Can always be bolted on by textual pre-processing, although that is
not always the best answer.

Quote:

11. conditional compilation

Ditto.

Quote:

any suggestions wellcome!

Neil Morris

Rod Pemberton

Posted: Sun Jul 27, 2008 7:12 pm Post subject: Re: core features and functions required in modern programmi

<scholz.lothar@gmail.com> wrote in message
news:cf380ef3-ddf5-40d3-b9df-e3ca1f8fc772@p25g2000hsf.googlegroups.com...

Quote:

Libraries aren't needed, if the core language allows dynamic memory
allocation, and file I/O.

ROTFL.

Really? Why? I don't see what's so laughable...

(From my perspective, that was an accurate statement from programming for
about 27 years with experience in about 14 languages or so...)

Quote:

3. mozilla's XUL

? Never heard of it.

Normally this would disqualify you from any further discussion.

Why? There are lots of dead, useless, low usage and specific use languages.
Am I supposed to know all of them? I started to list some of them, but then
realized it would take me a few hours...

(I.e., if you were to tell me electrolysis of water is the only electrolysis
method that produces hydrogen. Am I to disqualify you from further
discussion for not knowing about the chloralkali process?)

Quote:

You don't need to know it but you should have heared about it.

Why? Unless one specifically searches for XUL, there's no mention of it...
So, how am I to meet your expectations of my exposure to XUL?

(I.e., this tends to imply to me that XUL's primary use is in a dedicated
situation, e.g., for a specific single application, or in some highly
limited environment. Is it?)

Quote:

I didn't. But, with a claim like that, you need to prove I'm wrong. Feel
free to post some respectable links with industry numbers that you think
contradict these:

LINK
LINK
LINK

Rod Pemberton

Page 1 of 9 .:. Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9 Next



Awesome Website Templates ©

poker online kat. stron internetowych - sport turystyka Interactive agency Pozwolenie na broÅ„ scooter insurance

core features and functions required in modern programming l

Awesome Website Templates ©