Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #271 > unrolled thread

Re: Time for a new language?

Back to article view | Back to comp.lang.misc

Contents

  Re: Time for a new language? Jacko <jackokring@gmail.com> - 2011-05-03 18:58 -0700
    Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-06 10:16 -0500
      Re: Time for a new language? Nomen Nescio <nobody@dizum.com> - 2011-06-06 21:45 +0200
        Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-06 13:10 -0700
          Re: Time for a new language? Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-08 14:09 +0200
            Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-08 12:56 -0500
              Re: Time for a new language? Nomen Nescio <nobody@dizum.com> - 2011-06-09 02:31 +0200
                Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-09 09:10 -0500
                Re: Time for a new language? cri@tiac.net (Richard Harter) - 2011-06-09 16:37 +0000
                  Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-09 10:39 -0700
                    Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-10 04:46 -0700
                      Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-10 12:15 -0700
            Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-08 11:03 -0700
        Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-06 16:47 -0500
          Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-07 01:17 -0700
            Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-07 03:07 -0700
              Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-07 04:21 -0700
            Re: Time for a new language? "BartC" <bc@freeuk.com> - 2011-06-07 11:26 +0100
              Re: Time for a new language? pete <pfiland@mindspring.com> - 2011-06-07 07:45 -0400
                Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-07 13:02 -0700
              Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-07 12:49 -0700
            Re: Time for a new language? gremnebulin <peterdjones@yahoo.com> - 2011-06-13 16:36 -0700
            Re: Time for a new language? Ian Collins <ian-news@hotmail.com> - 2011-06-17 10:25 +1200
              Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-16 23:11 -0700
                Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-17 01:39 -0700
                  Re: Time for a new language? "H.J. Sander Bruggink" <sander.bruggink@uni-due.de> - 2011-06-17 11:05 +0200
                    Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-17 02:54 -0700
                  Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-17 10:55 -0700
              Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-17 00:55 -0700
          Re: Time for a new language? Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-08 23:54 +0200
            Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-08 17:37 -0500
          Re: Time for a new language? Marco van de Voort <marcov@turtle.stack.nl> - 2011-06-14 10:23 +0000
          Re: Time for a new language? torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-06-14 16:45 +0200
            Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-14 15:11 -0700
            Re: Time for a new language? "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-15 01:41 -0400
              Re: Time for a new language? Nomen Nescio <nobody@dizum.com> - 2011-06-15 15:40 +0200
            Re: Time for a new language? Marco van de Voort <marcov@turtle.stack.nl> - 2011-06-16 09:32 +0000
              Re: Time for a new language? Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-17 03:25 +0200
                Re: Time for a new language? Marco van de Voort <marcov@turtle.stack.nl> - 2011-06-17 08:38 +0000
                  Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-17 07:42 -0500
                    Re: Time for a new language? Marco van de Voort <marcov@turtle.stack.nl> - 2011-06-17 12:59 +0000
                      Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-17 08:48 -0500
                        Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-17 14:07 -0700
                        Re: Time for a new language? Marco van de Voort <marcov@turtle.stack.nl> - 2011-06-19 15:57 +0000
                          Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-20 13:21 -0500
                    Re: Time for a new language? Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-17 22:10 +0200
                  Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-17 07:47 -0500
                    Re: Time for a new language? Marco van de Voort <marcov@turtle.stack.nl> - 2011-06-17 13:02 +0000
                      Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-17 09:06 -0500
                  Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-17 07:53 -0500
                    Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-17 13:37 -0700
                  Re: Time for a new language? Nomen Nescio <nobody@dizum.com> - 2011-06-17 19:25 +0200
                  Re: Time for a new language? Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-22 09:41 +0200
                    Re: Time for a new language? torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-06-22 11:06 +0200
                      Re: Time for a new language? Nomen Nescio <nobody@dizum.com> - 2011-06-22 19:30 +0200
                    Re: Time for a new language? "BartC" <bc@freeuk.com> - 2011-06-22 10:21 +0100
                Re: Time for a new language? "Tony" <nospam@myisp.net> - 2011-06-17 07:37 -0500
                  Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-17 11:18 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#301

On 7 Jun., 12:26, "BartC" <b...@freeuk.com> wrote:
> "tm" <thomas.mer...@gmx.at> wrote in message
>
> news:043628bb-8b8b-4094-8e7b-b1c61a69b525@c41g2000yqm.googlegroups.com...
>
> > I consider Seed7 higher level than Java and C++ because Seed7
> > defines things in libraries that Java and C++ have hard-coded in
> > their compilers.
>
> Isn't it the other way around? If a feature exists only in a library, it
> must be defined using more primitive elements in the language.

Features defined in a library can be used in the same way as
built-in features. Neither the usage nor the performance differs.
But when a feature is defined in a library its interface is
accessible to normal users. You can look into the library and you
will find the interface (header) of the feature. The interface of
a build-in feature is defined in a reference manual or in the
compiler / interpreter source. But reference manuals and
compiler / interpreter source are just something different.
Reference manuals use natural language, but the interface (header)
of a feature is defined in the programming language itself.

> If the feature is built into the language, then surely that makes it higher
> level?

You seem to separate a language from its library. For me the
standard libraries, the libraries which are always shipped with the
language, are part of the picture. Otherwise a language with
everything built-in, including the kitchen sink, would be the
highest level language. When language and standard libraries are
viewed together, moving a feature to a library makes the pure
language more slim and elegant. Note that many languages are not
capable to define statements or user defined operators in a library.
This languages have no choice and must provide such features
built-in. As such Seed7 is higher level because even the most basic
features (the statements and operators of the language) can be (and
in fact they are) defined in a library.

> > So I consider arrays defined with an abstract data
> > type as higher level than hard-coded arrays.
>
> Arrays are usually fairly primitive types. If a language doesn't directly
> have arrays, and they have to be constructed (by building a new data-type
> with pointers or whatever), again I don't see that as a high-level feature!

The user does not need to construct arrays from pointers or
something else. Arrays are predefined and provide good performance
(for resizeable arrays). The difference to built-in arrays is:
The interfaces of all functions provided by arrays can be looked up
in a library. The body of most array functions consists of so called
primitive actions. A primitive action corresponds to a C function
which implements the functionality (compiled programs use inline
code instead). E.g.: The action "ARR_IDX" provides access to an
array element by indexing. Many languages provide user defined
containers. Some of them even use the syntax of arrays for them
(indexing with [ etc.). The Seed7 arrays use the usual syntax and
are defined the same way as other containers (in a library).

> > I consider things, that everybody can define, as higher level than
> > hard-coded do what I mean concepts (that only authors of compilers
> > and interpreters can change).
>
> A brick, that can be used to make anything, is higher level than a
> pre-fabricated section?

A system that allows user defined pre-fabricated sections is
higher level compared to one that only provides a fixed set of
pre-fabricated sections.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#317

On Jun 7, 9:17 am, tm <thomas.mer...@gmx.at> wrote:
> On 6 Jun., 23:47, "Tony" <nos...@myisp.net> wrote:
>
>
>
> > Nomen Nescio wrote:
> > > "Tony" <nos...@myisp.net> wrote:
>
> > >> Jacko wrote:
>
> > >>> long arr = new long[256,-2]; should be more than sufficient,
>
> > >> Of course it isn't. You are ignoring the fact that memory footprint
> > >> and layout matters sometimes. Either that or you are making a very
> > >> HLL, something above the level of C and C++, something at the level
> > >> of scripting languages.
>
> > > Since when are C or C++ HLLs? I think it goes approximately like this
>
> > > microcode -> object code -> assembler -> c -> c++ -> HLL -> Java ->
> > > scripting lang
>
> > I have always understood and used "HLL" to mean "above assembly
> > language". I put C and C++ at the same level. How could one not? That a
> > language has more features than another does not put it at a different
> > level. Assembly is the LLL and I don't have to worry about anything
> > lower. Example:
>
> > Low Level: Assembly Language
> > High Level: C, C++, Java (but a different animal from C, C++)
> > Higher Level: Scripting Languages
>
> Sripting Languages is a coarse description of a goup of languages.
> They tend to be interpreted and dynamically typed, but this is not
> granted. The only thing that they really have in common is the name
> "Scripting Language". There is no reason to consider all languages
> with this label "Higher Level".
>
> The term "Higher Level" often includes subjective feelings. People
> tend to consider things they like "Higher Level" and things they
> don't like "Lower Level". Because of such things an explanation is
> needed to show why something is considered higher level.
>
> I consider Seed7 higher level than Java and C++ because Seed7
> defines things in libraries that Java and C++ have hard-coded in
> their compilers. So I consider arrays defined with an abstract data
> type as higher level than hard-coded arrays.
>
> To see how hard-coded things work, look at the C conversions for
> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>   Intergral Promotion
>   Integral Converions
>   Integer and Floating
>   Floating Types
>   Arithmetic Conversions
>   Pointers and Integers
> The rules are not simple, and they changed between K&R-C and ANSI-C.
> All this rules are hardcoded in every C compiler. Seed7 has no such
> rules. There are just definitions of operators and functions for
> numeric types. I consider that this simplification makes Seed7
> (besides other things) higher level than C.
>
> I consider things, that everybody can define, as higher level than
> hard-coded do what I mean concepts (that only authors of compilers
> and interpreters can change).
>
The next logical step in higher levelness: pluggable types.

> Greetings Thomas Mertes
>
> --
> Seed7 Homepage:  http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#324

On 06/ 7/11 08:17 PM, tm wrote:
>
> I consider Seed7 higher level than Java and C++ because Seed7
> defines things in libraries that Java and C++ have hard-coded in
> their compilers. So I consider arrays defined with an abstract data
> type as higher level than hard-coded arrays.
>
> To see how hard-coded things work, look at the C conversions for
> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>    Intergral Promotion
>    Integral Converions
>    Integer and Floating
>    Floating Types
>    Arithmetic Conversions
>    Pointers and Integers
> The rules are not simple, and they changed between K&R-C and ANSI-C.

They may not be simple, but they are well understood and contribute to 
the metaphors that enable C programmers to understand each other's code.

> All this rules are hardcoded in every C compiler. Seed7 has no such
> rules. There are just definitions of operators and functions for
> numeric types. I consider that this simplification makes Seed7
> (besides other things) higher level than C.

Isn't that a recipe for write only code?  The reader not only has to 
follow the logic the code attempts to express, but also the rules used 
to express the logic.

> I consider things, that everybody can define, as higher level than
> hard-coded do what I mean concepts (that only authors of compilers
> and interpreters can change).

That's a bit like saying Leggo is the highest level toy...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#326

On 6/16/2011 3:25 PM, Ian Collins wrote:
> On 06/ 7/11 08:17 PM, tm wrote:
>>
>> I consider Seed7 higher level than Java and C++ because Seed7
>> defines things in libraries that Java and C++ have hard-coded in
>> their compilers. So I consider arrays defined with an abstract data
>> type as higher level than hard-coded arrays.
>>
>> To see how hard-coded things work, look at the C conversions for
>> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>> Intergral Promotion
>> Integral Converions
>> Integer and Floating
>> Floating Types
>> Arithmetic Conversions
>> Pointers and Integers
>> The rules are not simple, and they changed between K&R-C and ANSI-C.
>
> They may not be simple, but they are well understood and contribute to
> the metaphors that enable C programmers to understand each other's code.
>

yeah, and generally the rules make sense...


>> All this rules are hardcoded in every C compiler. Seed7 has no such
>> rules. There are just definitions of operators and functions for
>> numeric types. I consider that this simplification makes Seed7
>> (besides other things) higher level than C.
>
> Isn't that a recipe for write only code? The reader not only has to
> follow the logic the code attempts to express, but also the rules used
> to express the logic.
>

yeah...

in my case, I think it much more sensible to hard-code all the basics, 
and allow plugins for the rest...


for example, consider a person wants to add "some feature X" to the 
language, how may they do it?...

well, they can create a loadable component which:
plugs itself into the parser, so that the new syntax may be parsed;
plugs itself into the bytecode compiler so, that any new AST structures 
can be compiled;
maybe plugs into the bytecode VM, adding support for any new opcodes;
adds stuff for any new types;
...

ultimately, this is probably good enough, and if one really wants, an 
extension can be written which allows calling back into the language to 
implement extensions.


>> I consider things, that everybody can define, as higher level than
>> hard-coded do what I mean concepts (that only authors of compilers
>> and interpreters can change).
>
> That's a bit like saying Leggo is the highest level toy...
>

yeah, Lego is probably a lower-level toy, if anything because one is 
building things out of blocks, rather than out of pre-formed pieces.

FWIW, ASM also allows building programs out of large numbers of 
fundamental parts, and this is generally called low-level.

[toc] | [prev] | [next] | [standalone]

#329

On 17 Jun., 08:11, BGB <cr88...@hotmail.com> wrote:
> On 6/16/2011 3:25 PM, Ian Collins wrote:
>
>
>
> > On 06/ 7/11 08:17 PM, tm wrote:
>
> >> I consider Seed7 higher level than Java and C++ because Seed7
> >> defines things in libraries that Java and C++ have hard-coded in
> >> their compilers. So I consider arrays defined with an abstract data
> >> type as higher level than hard-coded arrays.
>
> >> To see how hard-coded things work, look at the C conversions for
> >> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
> >> Intergral Promotion
> >> Integral Converions
> >> Integer and Floating
> >> Floating Types
> >> Arithmetic Conversions
> >> Pointers and Integers
> >> The rules are not simple, and they changed between K&R-C and ANSI-C.
>
> > They may not be simple, but they are well understood and contribute to
> > the metaphors that enable C programmers to understand each other's code.
>
> yeah, and generally the rules make sense...

You are probably used to them. Sometimes it helps to
take a step backward (to get a broader view). A neutral
outsider would probably have a different view on the rules.

> >> All this rules are hardcoded in every C compiler. Seed7 has no such
> >> rules. There are just definitions of operators and functions for
> >> numeric types. I consider that this simplification makes Seed7
> >> (besides other things) higher level than C.
>
> > Isn't that a recipe for write only code? The reader not only has to
> > follow the logic the code attempts to express, but also the rules used
> > to express the logic.
>
> yeah...
>
> in my case, I think it much more sensible to hard-code all the basics,
> and allow plugins for the rest...

Plugins are a fashion now. Firefox, Eclipse and many other
programs use them. It is iteresting to see that my ideas
become acceptable, when the term plugin is used. But plugins
are IMHO a much more low level concept to reach the same goal.
A plugin usually has access to the data structure of the main
program via an API. I see my approach with syntax definitions
(see: http://seed7.sourceforge.net/manual/syntax.htm) and
function definitions (which use the new introduced syntax)
as much more high level.

> for example, consider a person wants to add "some feature X" to the
> language, how may they do it?...
>
> well, they can create a loadable component which:
> plugs itself into the parser, ...
> plugs itself into the bytecode compiler so, ...
> maybe plugs into the bytecode VM, ...

What a complicated concept. You need to know the internals
of parser, compiler and VM to do that.

I suggest that a person who wants to add "some feature X"
takes a look at Seed7. :-)

> ultimately, this is probably good enough, ...

This must be a joke. You expect that people know the
internals of your parser, compiler and VM to do something
that Seed7 can do in just a few lines?

[snip]

> >> I consider things, that everybody can define, as higher level than
> >> hard-coded do what I mean concepts (that only authors of compilers
> >> and interpreters can change).
>
> > That's a bit like saying Leggo is the highest level toy...
>
> yeah, Lego is probably a lower-level toy, if anything because one is
> building things out of blocks, rather than out of pre-formed pieces.

You probably haven't played with Lego for a long time.
(I have children, so I see what Lego provides now).
Now they use a lot of pre-formed pieces which allow some
things to be build more quickly. But this has the
disadvantage that some things become impossible to create.

> FWIW, ASM also allows building programs out of large numbers of
> fundamental parts, and this is generally called low-level.

ASM has a 1:1 mapping to machine code, this was the reason
it was considered a 2nd generation language.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#330

On 06/17/2011 10:39 AM, tm wrote:
> You are probably used to them. Sometimes it helps to
> take a step backward (to get a broader view). A neutral
> outsider would probably have a different view on the rules.

A very good tip! Maybe you should try it yourself with your
own language, as well.

groente
-- Sander

[toc] | [prev] | [next] | [standalone]

#331

On 17 Jun., 11:05, "H.J. Sander Bruggink" <sander.brugg...@uni-due.de>
wrote:
> On 06/17/2011 10:39 AM, tm wrote:
>
> > You are probably used to them. Sometimes it helps to
> > take a step backward (to get a broader view). A neutral
> > outsider would probably have a different view on the rules.
>
> A very good tip! Maybe you should try it yourself with your
> own language, as well.

Okay.
What are you trying to tell me?


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#341

On 6/17/2011 1:39 AM, tm wrote:
> On 17 Jun., 08:11, BGB<cr88...@hotmail.com>  wrote:
>> On 6/16/2011 3:25 PM, Ian Collins wrote:
>>
>>
>>
>>> On 06/ 7/11 08:17 PM, tm wrote:
>>
>>>> I consider Seed7 higher level than Java and C++ because Seed7
>>>> defines things in libraries that Java and C++ have hard-coded in
>>>> their compilers. So I consider arrays defined with an abstract data
>>>> type as higher level than hard-coded arrays.
>>
>>>> To see how hard-coded things work, look at the C conversions for
>>>> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>>>> Intergral Promotion
>>>> Integral Converions
>>>> Integer and Floating
>>>> Floating Types
>>>> Arithmetic Conversions
>>>> Pointers and Integers
>>>> The rules are not simple, and they changed between K&R-C and ANSI-C.
>>
>>> They may not be simple, but they are well understood and contribute to
>>> the metaphors that enable C programmers to understand each other's code.
>>
>> yeah, and generally the rules make sense...
>
> You are probably used to them. Sometimes it helps to
> take a step backward (to get a broader view). A neutral
> outsider would probably have a different view on the rules.
>

the type tower, promotion rules, ... are not magic.


>>>> All this rules are hardcoded in every C compiler. Seed7 has no such
>>>> rules. There are just definitions of operators and functions for
>>>> numeric types. I consider that this simplification makes Seed7
>>>> (besides other things) higher level than C.
>>
>>> Isn't that a recipe for write only code? The reader not only has to
>>> follow the logic the code attempts to express, but also the rules used
>>> to express the logic.
>>
>> yeah...
>>
>> in my case, I think it much more sensible to hard-code all the basics,
>> and allow plugins for the rest...
>
> Plugins are a fashion now. Firefox, Eclipse and many other
> programs use them. It is iteresting to see that my ideas
> become acceptable, when the term plugin is used. But plugins
> are IMHO a much more low level concept to reach the same goal.
> A plugin usually has access to the data structure of the main
> program via an API. I see my approach with syntax definitions
> (see: http://seed7.sourceforge.net/manual/syntax.htm) and
> function definitions (which use the new introduced syntax)
> as much more high level.
>

probably everyone here knows by now how you are doing things...

I am doing things differently, mostly hard-coding most core parts of the 
language, and using plugins for the rest.


>> for example, consider a person wants to add "some feature X" to the
>> language, how may they do it?...
>>
>> well, they can create a loadable component which:
>> plugs itself into the parser, ...
>> plugs itself into the bytecode compiler so, ...
>> maybe plugs into the bytecode VM, ...
>
> What a complicated concept. You need to know the internals
> of parser, compiler and VM to do that.
>

most of it is done via API, most of which can abstract over a lot of the 
"ugly details". partly, this is called "abstraction".

anyways, one could argue the same thing against, say, Lisp, because you 
need to know all these ugly details of how Lisp works in order to use it.


most of the low-level VM interfacing would likely involve a lot of 
dynamic types and S-Expressions, as this is a large part of what the VM 
is built on (most of these APIs are independent of the VM itself).

although not perfect, the parser API mostly boils down to S-Expressions 
/ Lists and a "char **" pointer (the latter may be wrapped in some sort 
of API, as to hide its "char **" nature).

actually, the AST format is vaguely similar to Scheme, albeit with some 
alterations over the years mostly to address representation issues.

the main alternative would have been XML based, but it seems at this 
point, S-Exps won this particular game.


either way, it is not assumed here that newbies will be sitting around 
writing VM plugins, as FWIW, newbies will make nastiness of pretty much 
any feature they use.


> I suggest that a person who wants to add "some feature X"
> takes a look at Seed7. :-)
>
>> ultimately, this is probably good enough, ...
>
> This must be a joke. You expect that people know the
> internals of your parser, compiler and VM to do something
> that Seed7 can do in just a few lines?
>

FWIW, this may not matter.


the main use for language extensions would likely be to add DSL-like 
functionality, which would ultimately depend mostly on the host app.

it then allows a host app, presumably written in C or C++, to plug in 
whatever new features it needs.

the language doesn't really need to be self-extending, because this 
isn't really all that likely to be useful.



>>>> I consider things, that everybody can define, as higher level than
>>>> hard-coded do what I mean concepts (that only authors of compilers
>>>> and interpreters can change).
>>
>>> That's a bit like saying Leggo is the highest level toy...
>>
>> yeah, Lego is probably a lower-level toy, if anything because one is
>> building things out of blocks, rather than out of pre-formed pieces.
>
> You probably haven't played with Lego for a long time.
> (I have children, so I see what Lego provides now).
> Now they use a lot of pre-formed pieces which allow some
> things to be build more quickly. But this has the
> disadvantage that some things become impossible to create.
>
>> FWIW, ASM also allows building programs out of large numbers of
>> fundamental parts, and this is generally called low-level.
>
> ASM has a 1:1 mapping to machine code, this was the reason
> it was considered a 2nd generation language.
>

yes, and as a child (elementary-school years) ASM (along with BASIC, 
namely QBasic) was one of the earlier languages I learned...

initially, I actually understood ASM a bit better than C, but C had its 
merits which made me mostly switch to it as my primary language 
(actually, early on I partly learned C by compiling programs to ASM and 
then reading the ASM output, giving me more a grasp on what some of 
these code fragments were doing).

at one point I had tried, without all that much success, to bridge 
between ASM and QBasic.

what finally killed me using Basic was (then in middle school) jumping 
ship to Linux as my main OS for a number of years, where Linux didn't 
have QBasic, so most new code was written solely in C.


and then many years went by...

[toc] | [prev] | [next] | [standalone]

#327

On 17 Jun., 00:25, Ian Collins <ian-n...@hotmail.com> wrote:
> On 06/ 7/11 08:17 PM, tm wrote:
>
>
>
> > I consider Seed7 higher level than Java and C++ because Seed7
> > defines things in libraries that Java and C++ have hard-coded in
> > their compilers. So I consider arrays defined with an abstract data
> > type as higher level than hard-coded arrays.
>
> > To see how hard-coded things work, look at the C conversions for
> > numeric values. Chapter A6 of ANSI-K&R distinguishes between:
> >    Intergral Promotion
> >    Integral Converions
> >    Integer and Floating
> >    Floating Types
> >    Arithmetic Conversions
> >    Pointers and Integers
> > The rules are not simple, and they changed between K&R-C and ANSI-C.
>
> They may not be simple, but they are well understood ...

They are fair understood by people who already know C.
I am quite sure that most C programmers had experiences
where they searched for the reason of an overflow or a
compilation warning regarding implicit conversions.

> ... and contribute to
> the metaphors that enable C programmers to understand each other's code.

In other words:
When you know a language you can understand programs
written in it. This is self-evident and has nothing to
do with the complexity of the rules above.

> > All this rules are hardcoded in every C compiler. Seed7 has no such
> > rules. There are just definitions of operators and functions for
> > numeric types. I consider that this simplification makes Seed7
> > (besides other things) higher level than C.
>
> Isn't that a recipe for write only code?

Why should it be?
The rules in Seed7 are simpler and the interfaces of all
operators and functions can be found in libraries.

> The reader not only has to
> follow the logic the code attempts to express, but also the rules used
> to express the logic.

This is true for every programming language. As stated
above the rules to express the logic in Seed7 are simpler.

> > I consider things, that everybody can define, as higher level than
> > hard-coded do what I mean concepts (that only authors of compilers
> > and interpreters can change).
>
> That's a bit like saying Leggo is the highest level toy...

The area of toys is much larger than the area of programming
languages. Comparing programming languages is more like
comparing construction kits.

Construction kits often have pre fabricated special parts.
E.g. the undercarriage of a train. This is advantageous,
since it allows you to build a train more quickly. Now
assume you want to build a steam locomotion whith big wheels
and coupling rods. When no such pre fabricated part exists,
you are out of luck.

When a construction kitt offers you a way to create your
own special parts, your possibilities multiply. In case of
the steam locomotion you need separate wheels in different
sizes and pieces to be used as coupling rod.

That is what Seed7 offers you: Pre fabricated parts AND
the possibility to create your own special parts.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#307

"Tony" <nospam@myisp.net> wrote:

> Nomen Nescio wrote:
> > "Tony" <nospam@myisp.net> wrote:
> >
> >> Jacko wrote:
> >>
> >>> long arr = new long[256,-2]; should be more than sufficient,
> >>
> >> Of course it isn't. You are ignoring the fact that memory footprint
> >> and layout matters sometimes. Either that or you are making a very
> >> HLL, something above the level of C and C++, something at the level
> >> of scripting languages.
> >
> > Since when are C or C++ HLLs? I think it goes approximately like this
> >
> > microcode -> object code -> assembler -> c -> c++ -> HLL -> Java ->
> > scripting lang
> 
> I have always understood and used "HLL" to mean "above assembly 
> language". 

That's just because you guys don't have any sense of history. It doesn't
make it right.

> I put C and C++ at the same level. How could one not?

Because C++ started out as a preprocessor for C and adds abstractions and
features on top of C, it's obviously a higher level. C++ is approaching an
HLL but isn't quite there.

> That a language has more features than another does not put it at a
> different level. Assembly is the LLL and I don't have to worry about
> anything lower.

But there are lower levels, notably microcode and object code. Just because
"you" don't have to worry doesn't change the reality there are people
working at those levels. There's nothing in the definition of low level, mid
level, high level langs etc that says anything about some guy on usenet
worrying about it or not.

> Java can be between High and Higher, but it's nothing I need to worry 
> about. 

Nobody has to worry about it unless we're discussing definitions. I don't
know what your post is about if you don't have to worry about anything.

> 
> 

[toc] | [prev] | [next] | [standalone]

#308

Fritz Wuehler wrote:
> "Tony" <nospam@myisp.net> wrote:
>
>> Nomen Nescio wrote:
>>> "Tony" <nospam@myisp.net> wrote:
>>>
>>>> Jacko wrote:
>>>>
>>>>> long arr = new long[256,-2]; should be more than sufficient,
>>>>
>>>> Of course it isn't. You are ignoring the fact that memory footprint
>>>> and layout matters sometimes. Either that or you are making a very
>>>> HLL, something above the level of C and C++, something at the level
>>>> of scripting languages.
>>>
>>> Since when are C or C++ HLLs? I think it goes approximately like
>>> this
>>>
>>> microcode -> object code -> assembler -> c -> c++ -> HLL -> Java ->
>>> scripting lang
>>
>> I have always understood and used "HLL" to mean "above assembly
>> language".
>
> That's just because you guys don't have any sense of history. It
> doesn't make it right.

Just because you still like to wear your straw hat doesn't make it 
fashionable again. :P

>
>> I put C and C++ at the same level. How could one not?
>
> Because C++ started out as a preprocessor for C and adds abstractions
> and features on top of C, it's obviously a higher level.

For you it is by your subjective definition. Many consider assembly 
language low level and things above it high level. It is quite, quite 
common. C++ is exactly at C level (hehe C-level (sea level), OK, corny. 
Nevermind.) even by your classification because it does not remove the 
lower level primitives.

And THAT is what you meant with "sense of history"? You're a youngster!

> C++ is
> approaching an HLL but isn't quite there.

"Way back when", thre was this thing called "assembly language", you see, 
but way before your time. Look it up, you'll be enlightened! :P

>
>> That a language has more features than another does not put it at a
>> different level. Assembly is the LLL and I don't have to worry about
>> anything lower.
>
> But there are lower levels, notably microcode and object code.

Microcode is not relevant to to most programmers and object code is in a 
different category because no one programs in object code.

> Just
> because "you" don't have to worry doesn't change the reality there
> are people working at those levels.

No one (but you apparently) was trying to come up with a grandiose view 
of all code anywhere ever, but rather pondering their window into it. No 
one was ignoring those other things which you seemed to be hell-bent on 
suggesting that other people don't know about.

> There's nothing in the definition
> of low level, mid level, high level langs etc that says anything
> about some guy on usenet worrying about it or not.

It's not a definition, it's a subjective thing. Your LLL may be another's 
HLL. Learn to accept and deal with non-absolutes.

>
>> Java can be between High and Higher, but it's nothing I need to worry
>> about.
>
> Nobody has to worry about it unless we're discussing definitions.

I think you are the only one who would like to impose some kind of 
defintions while others are just fine with their views and curious about 
others' views. There is no definition of HLL and LLL unless you have a 
context in which to define them. For a developer who always develops 
above the hardware level, there is no need for the tedium of an 
encyclopedic classification of levels for daily use that includes 
microcode in it. It simply does not fit in the system of classification 
of languages for that person.

> I
> don't know what your post is about if you don't have to worry about
> anything.

Caffeine make you irritable much? 

[toc] | [prev] | [next] | [standalone]

#318

On 2011-06-06, Tony <nospam@myisp.net> wrote:
>
> Low Level: Assembly Language
> High Level: C, C++, Java (but a different animal from C, C++)
> Higher Level: Scripting Languages

For me scripting language is higher level too, but not on a language level,
but more on an usage level.

IOW scripting languages are used to connect other systems (data from one
program to another with minimal transformation, perform
nightly jobs) etc. That's where the name comes from, replaying a fixed
script of actions.

One could probably discuss if something as python and php are really
scripting languages.


I do realize that definition is outdated and does not really apply to
current use, but I haven't been able to distil anything more from current
use except the fact that languages that want to be regarded as easy to use
OR are interpreter based describe themselves as scripting languages.

One way or the other, I don't think they have a fixed place in the
"higher/lower" language spectrum.

[toc] | [prev] | [next] | [standalone]

#319

"Tony" <nospam@myisp.net> writes:


> Low Level: Assembly Language
> High Level: C, C++, Java (but a different animal from C, C++)
> Higher Level: Scripting Languages
>
> Java can be between High and Higher, but it's nothing I need to worry 
> about. 

One way of seeing the distinction is how removed from a particular
physical machine the language is: The less assumptions a langauge makes
about the machine, the higher level.  Most language scan be implemented
on any Turing-complete machines, but if the physical machine does not
fit the assumptions of the language, you will either have suboptimal
performance or lose portability of programs.  C, for example, makes few
assumptions about the wordsize, and it is indeed possible to implement C
on a machine using 24-bit one's complement integers with no byte
addressing, but you wouldn't expect to run very many unmodified C
programs on this, as most programmers assume two's complement and at
least (or exactly) 32 bits and byte addressability.

That more or less fits the above list, but puts Java at a higher level
than C and C++ and scripting languages not (much) above Java, since Java
makes fairly few assumptions about specific machines.  It does, however,
implicitly assume that integers are 32-bit two's complement, which is a
good fit to most machines at the time it was designed, but is hardly
abstract and removed from assumptions about machines.

Most scripting languages make similar assumptions about integer ranges,
but there are exceptions.  Lua (IIRC) uses only floating-point numbers,
but assumes these are IEEE double precision FP.  A few languages (like
Scheme) have unbounded integers, but most of these allow bitwise
operations on integers that assume (unbounded) two's complement
notation, i.e., that -1 is the infinite sequence of 1 bits.

Note that this only gives a partial order on levelness: A language may
make more assumptions than another about some aspects of the machine
(such as number range) and fewer asssumptions about other aspects (such
as byte addressibility or endianness).

Another way to see language level is how much a programmer needs to
specify to solve a given problem: The more you have to specify, the
lower level the language.  For example, GC implies higher level than
(unsafe) manual freeing of memory, foreach-loops on collections or
vectors imply higher level than for-loops with explicit sequence of
indices and so on.  This, too, is not a total ordering as some languages
might require strict sequential loops but include GC while others may
have parallel loops but no GC.

	Torben

[toc] | [prev] | [next] | [standalone]

#320

On 6/14/2011 7:45 AM, Torben Ægidius Mogensen wrote:
> "Tony"<nospam@myisp.net>  writes:
>
>
>> Low Level: Assembly Language
>> High Level: C, C++, Java (but a different animal from C, C++)
>> Higher Level: Scripting Languages
>>
>> Java can be between High and Higher, but it's nothing I need to worry
>> about.
>
> One way of seeing the distinction is how removed from a particular
> physical machine the language is: The less assumptions a langauge makes
> about the machine, the higher level.  Most language scan be implemented
> on any Turing-complete machines, but if the physical machine does not
> fit the assumptions of the language, you will either have suboptimal
> performance or lose portability of programs.  C, for example, makes few
> assumptions about the wordsize, and it is indeed possible to implement C
> on a machine using 24-bit one's complement integers with no byte
> addressing, but you wouldn't expect to run very many unmodified C
> programs on this, as most programmers assume two's complement and at
> least (or exactly) 32 bits and byte addressability.
>
> That more or less fits the above list, but puts Java at a higher level
> than C and C++ and scripting languages not (much) above Java, since Java
> makes fairly few assumptions about specific machines.  It does, however,
> implicitly assume that integers are 32-bit two's complement, which is a
> good fit to most machines at the time it was designed, but is hardly
> abstract and removed from assumptions about machines.
>

or, currently, my language and implementation has an issue with some of 
this:
int is "generally understood" to be exactly 32 bits (this is also 
currently what my spec says).

however, my implementation can only fit 28 bits in a fixnum on 32-bit 
targets.

this means either int has to only guarantee a smaller number of bits 
(say, 24 or 28), or live with the issue of having to still use 
type-checking, eliminating some possible optimizations.

alternatively, I could switch to using 64-bit references on x86, but 
this creates a number of technical issues with the present 
implementation (mostly many cases where I would need to either marshal 
values, or "upgrade" many things to use 64-bits, neither of which would 
be free).


> Most scripting languages make similar assumptions about integer ranges,
> but there are exceptions.  Lua (IIRC) uses only floating-point numbers,
> but assumes these are IEEE double precision FP.  A few languages (like
> Scheme) have unbounded integers, but most of these allow bitwise
> operations on integers that assume (unbounded) two's complement
> notation, i.e., that -1 is the infinite sequence of 1 bits.
>

yeah...

Lua had an interesting way of doing references:
double is the default type, and object-pointers/... are encoded as NaNs...

I implemented a similar system, but haven't really put it into use, as 
for the most part it would be very costly apart from making drastic 
alterations to a fair amount of code (at the very least, the core 
interpreter and OO facilities would need to be somewhat altered).

meanwhile, most of the advantages would go away on x86-64, and instead 
leave disadvantages.


I have considered the possiblity of doing more like Scheme and making 
unbounded integer types the default (currently, even with dynamic types, 
"upcasting" is still needed if one wants more range, or one can perform 
arithmetic against a wider type to implicitly upcast...).

also, presently there are no unbounded bignums, as "int128" is the 
biggest conventional integer type, and beyond this one has a BCD-based 
type, but it ultimately has a limit as well (presently 4096 digits).



> Note that this only gives a partial order on levelness: A language may
> make more assumptions than another about some aspects of the machine
> (such as number range) and fewer asssumptions about other aspects (such
> as byte addressibility or endianness).
>
> Another way to see language level is how much a programmer needs to
> specify to solve a given problem: The more you have to specify, the
> lower level the language.  For example, GC implies higher level than
> (unsafe) manual freeing of memory, foreach-loops on collections or
> vectors imply higher level than for-loops with explicit sequence of
> indices and so on.  This, too, is not a total ordering as some languages
> might require strict sequential loops but include GC while others may
> have parallel loops but no GC.
>

yep...

and, maybe counter to good sense, my stuff supports iteration which 
resembles the C way:
for(x=arr; x; x++)
	print(*x);

although the implementation is different (these are not direct pointer 
operations), and also presently the pointer will become NULL if one goes 
off the end of a string or array.

the language technically includes a variation of a foreach loop ("for(x 
in arr) ...") but I am not certain it actually works.


more recently, I also added the ability to do things like:

function foo(rx)
{
	*rx=3;
}

function bar()
{
	var x;
	foo(&x);
	printf("%d\n", x);
}

mostly as a lazy way of adding support for references.

once again, these look like C, but the way it works is a good deal 
different (the reference is actually a boxed object type, ...).

currently though, it only works on certain types of variables (namely, 
only those declared either at the toplevel, or directly visible as a 
part of the lexical or dynamic environments, which currently excludes 
package-import or delegate variables).

technically, they work more like the "locatives" which are present in 
some Scheme implementations.


but, the advantage is that these allow more quickly/easily performing 
some tasks than with some other alternatives (such as using an array to 
pass values, or by using method calls).


or such...

[toc] | [prev] | [next] | [standalone]

#321

"Torben Ægidius Mogensen" <torbenm@diku.dk> wrote in message
news:7zei2wh3p8.fsf@ask.diku.dk...
>
> One way of seeing the distinction is how removed from a particular
> physical machine the language is: The less assumptions a langauge makes
> about the machine, the higher level.

Are you sure that argument is a solid one?

> Most language scan be implemented
> on any Turing-complete machines, but if the physical machine does not
> fit the assumptions of the language, you will either have suboptimal
> performance or lose portability of programs.  C, for example, makes few
> assumptions about the wordsize, and it is indeed possible to implement C
> on a machine using 24-bit one's complement integers with no byte
> addressing, but you wouldn't expect to run very many unmodified C
> programs on this, as most programmers assume two's complement and at
> least (or exactly) 32 bits and byte addressability.
>
> That more or less fits the above list, but puts Java at a higher level
> than C and C++ and scripting languages not (much) above Java, since Java
> makes fairly few assumptions about specific machines.

Your definition of a higher level language also places a language, like
Forth, above all of them ...  Forth makes even fewer assumptions.  It only
needs the primary integer size to be the same as the address pointer size,
and that's probably not a requirement.  C and Forth are the two languages
that are the most widely implemented, i.e., they are the most portable.
Forth has been implemented on even more platforms than C.  Are you really
arguing that a language like Forth is superior to C, or another language,
simply because it is the most abstracted from the host machine?  That's
absurd!  Forth is nowhere near C in terms of functionality or usefulness or
readability.  Is it possible to do everything in Forth that one can do in C?
Yes, but that can be said of other Turing-complete languages too, e.g.,
Brainfuck (BF).  Who is going to code an operating system or a serious
application in BF?  No one.

> Another way to see language level is how much a programmer needs to
> specify to solve a given problem: The more you have to specify, the
> lower level the language.

I see that argument as being flawed also.  Some languages, like C, have
large sets of standardized functions available as libraries.  I.e., in a
sense, they are more complete.  Other languages, do not.  For the more
complete languages, much work was done for the programmer in advance.  So,
there is less for programmers in that language to do.  Does that mean a more
complete language should be ranked above a less completed one, just because
it's more complete?  No, it doesn't.  They should be ranked by their
usefulness or capability as a language.  That's why C should rank above C++.
C++ is more complete, but it's less effective and functional.  That's also
why Forth, or Pascal, or Basic, or Fortran, or Cobol, ... shouldn't be
ranked as high as C.  They don't do low-level stuff too.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#322

"Rod Pemberton" <do_not_have@noavailemail.cmm> wrote:

> "Torben Ægidius Mogensen" <torbenm@diku.dk> wrote in message
> news:7zei2wh3p8.fsf@ask.diku.dk...
> >
> > One way of seeing the distinction is how removed from a particular
> > physical machine the language is: The less assumptions a langauge makes
> > about the machine, the higher level.
> 
> Are you sure that argument is a solid one?

I am. I thought it was an excellent post and presented many of the arguments
I would have written, except that Tony was the one arguing.

> Your definition of a higher level language also places a language, like
> Forth, above all of them ...  Forth makes even fewer assumptions. 

Yes and no. Forth often comes with an assembler, so it would be hard to
argue it makes no assumptions since the assembler won't run on more than
one machine. Forth on the other hand is sortof VM-ish and does tend to allow
you to abstract away from the machine. So it probably falls in both
categories, it's certainly a hybrid in that way.

> that are the most widely implemented, i.e., they are the most portable.
> Forth has been implemented on even more platforms than C.  Are you really
> arguing that a language like Forth is superior to C, or another language,
> simply because it is the most abstracted from the host machine?  That's
> absurd!

Rod, I'm shocked! How can you confuse the designation high or low level
languages as better or worse? One has nothing to do with the other!

> I see that argument as being flawed also.  Some languages, like C, have
> large sets of standardized functions available as libraries.  I.e., in a
> sense, they are more complete.  Other languages, do not.  For the more
> complete languages, much work was done for the programmer in advance.  So,
> there is less for programmers in that language to do.  Does that mean a
> more complete language should be ranked above a less completed one, just
> because it's more complete?  No, it doesn't. 

Uhm yes it does. We're not talking about how good something is, just
comparing levels and talking about what makes something a higher or level
lower language.

> They should be ranked by their usefulness or capability as a language.

Uhm maybe, but not in this thread since it is about the *level* of a
language and not the *goodness* of a language.

> That's why C should rank above C++.

Not when we're discussing what's an HLL and what's a VHLL, etc. What are you
discussing?

[toc] | [prev] | [next] | [standalone]

#323

On 2011-06-14, Torben ?gidius Mogensen <torbenm@diku.dk> wrote:
>> Java can be between High and Higher, but it's nothing I need to worry 
>> about. 
>
> One way of seeing the distinction is how removed from a particular
> physical machine the language is: The less assumptions a langauge makes
> about the machine, the higher level.

Higher level is not more abstraction from the machine, but closer to the
problem domain. 

While the first steps away from assembler are the same in both definitions,
one could discuss if Java really is closer to the problem domain than e.g. 
C++.  They are both similar OOP general purpose languages.

Scripting languages originally were closer to the problem domain, since they
were engineered to script various binaries together in a "script", and thus
more highlevel. 

An OS specific scripting language is thus still more highlevel than a
general purpose portable language.

Well, unless you define portability as your main problem domain, obviously
;-)

[toc] | [prev] | [next] | [standalone]

#325

> Higher level is not more abstraction from the machine, but closer to the
> problem domain.

That would be a good definition in theory but it reality it is not that
way. There used to be more domain specific languages than there are now. Now
the higher and higher level languages are just scripting languages that are
general purpose languages.

> While the first steps away from assembler are the same in both
> definitions, one could discuss if Java really is closer to the problem
> domain than e.g. C++.  They are both similar OOP general purpose
> languages.

You may have a good point and I think it has to do with the libraries more
than the languages. People have really made a mistake by separating
libraries and languages because it's a false separation. Just because they
decide to separate the implementation of libraries and languages is no
reason to package them separately. Neither Java nor C++ would be worth
anything without their respective libraries.

> Scripting languages originally were closer to the problem domain, since
> they were engineered to script various binaries together in a "script",
> and thus more highlevel.

Hmmm not sure what you meant here, but my bullshit detector moved to the red
zone ;-)

> An OS specific scripting language is thus still more highlevel than a
> general purpose portable language.

Yes but can you name any? Almost all scripting languages today are cross
platform.

> Well, unless you define portability as your main problem domain, obviously
> ;-)

No, that is a very big mistake in logic. Portability is not a problem
domain, it's a feature (or not).

[toc] | [prev] | [next] | [standalone]

#328

On 2011-06-17, Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> wrote:
>> Higher level is not more abstraction from the machine, but closer to the
>> problem domain.
>
> That would be a good definition in theory but it reality it is not that
> way. There used to be more domain specific languages than there are now.

True. But does that change a definition?

> Now
> the higher and higher level languages are just scripting languages that are
> general purpose languages.

What is your argumentation for that? People want to believe scripting
languages like Perl and Python are higher level because they are relatively
new (or at least became popular relatively recent) and shiny. 

But I'm not doing marketing for those language, I prefer an objective
definition.

>> While the first steps away from assembler are the same in both
>> definitions, one could discuss if Java really is closer to the problem
>> domain than e.g. C++.  They are both similar OOP general purpose
>> languages.
>
> You may have a good point and I think it has to do with the libraries more
> than the languages.

IMHO that is a different subject, but that is certainly happening.

> People have really made a mistake by separating libraries and languages
> because it's a false separation

Depends on your viewpoint what you are interested in. Getting work done? And
where do you lay the line ? Portable functionality? Whatever the vendor
provides? These are tradeoffs that are different for everybody (or even
everybodies distinct projects)

But since this is comp.lang.misc not comp.libraries.misc, I think it is
entirely justified ot limit it to the language.

(though I'm actually a language runtime maintainer, and that is where my
interests lie, the lowlevel library and how it interacts with the language)

> Neither Java nor C++ would be worth anything without their
> respective libraries.

(well, that depends if you deem them worth anything with them in the first place :-)

Kidding aside, it is certainly true. But to be honest, I think a main player
pushing a solution is more important than design. All post 2000 languages
(and the major scripting languages are actually mostly older than that) are
pushed by big corporations.

.NET wouldn't have been as popular if it came from Borland, despite that
Borland's former architect designed it.

The libraries bit makes it more than just market power. Huge libraries need
huge investments, both in the making and maintaining. And .NET is huge.
Really huge.

>> Scripting languages originally were closer to the problem domain, since
>> they were engineered to script various binaries together in a "script",
>> and thus more highlevel.
>
> Hmmm not sure what you meant here, but my bullshit detector moved to the red
> zone ;-)

To get to a current definition/placement of scripting languages I go back to
what they originally were meant to do. Execute programs in a certain order.

Later some variables and flexibility of execution order (control statements)
were added.

I found it a bit paradoxal and amusing that such definition would put the batch like
scripting languages of old on a higher level (since  engineered €for a specific problem domain, and thus higher level.

>> An OS specific scripting language is thus still more highlevel than a
>> general purpose portable language.
>
> Yes but can you name any? Almost all scripting languages today are cross
> platform.

Huh? The most used ones not. Admitted batchfiles work on windows AND dos,
but is that portable? VBScript?

And one could easily argue that many of the so called portable languages
really never left Unix. Or can stock Python finally deal with an UNC path
nowadays and change the current directory to it?

>> Well, unless you define portability as your main problem domain, obviously
>> ;-)
>
> No, that is a very big mistake in logic. Portability is not a problem
> domain, it's a feature (or not).

I tend to agree with you, but in rare cases it can be the fundament of a
business model. (integration of systems in heterogenous environments)

But on the other side you can turn everything into a businessmodel. If you
have an unreadable scripting language you can make a fortune selling books
that explain it. Tim O'Reilly did with Perl :-)

[toc] | [prev] | [next] | [standalone]

#334

Marco van de Voort wrote:

> .NET wouldn't have been as popular if it came from Borland, despite
> that
> Borland's former architect designed it.

.Net is popular, not because it's a good framework (and I'm not saying if 
it, is or isn't, good), but because it is THE Windows framework. Its 
popularity stems from its association with Windows.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.misc

csiph-web