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 1 of 3  [1] 2 3  Next page →

#271 — Re: Time for a new language?

On Tuesday, 3 May 2011 22:03:53 UTC+1, BGB  wrote:
> On 5/3/2011 12:09 PM, Jacko wrote:
> > On Monday, 2 May 2011 23:02:51 UTC+1, BGB  wrote:
> >> On 5/1/2011 9:26 PM, Jacko wrote:
> >>> http://my.opera.com/jackokring/blog/java-oracle-android-and-google
> >>
> >> I disagree that this is a good design idea...
> >> to be more capable going forwards, one generally needs more, not less,
> >> features...
> >>
> >> for example, "industrial strength" languages tend to have big and
> >> complex typesystems and elaborate scope models, ...
> >
> > I disagree back, I'd also remove short, char and byte as types, and have a PackedArray class for such needs. To muddy the base type system with anything less than an int maybe is an obscure homage to history. I'd then be left with just int and long and object pointer and void.
> >
> 
> removing them would not make much sense, as in most cases where it 
> matters, compilers/VMs simply "upgrade" the types to integers anyways, 
> usually leaving arrays as about the only case where the compiler or VM 
> bothers to care about the difference.
> 
> hence, removing them from the base language wouldn't really buy anything 
> of value, apart from making it more awkward to use.
> 
> 
> awkwardness is generally not considered desirable in programmer land, 
> hence why people more often choose a complex tool which is less effort 
> to use, vs a simpler tool which is more effort.
> 
> and, about as soon as people can no longer simply type something like:
> "byte[] arr=new byte[256];" for a new byte-array, they will raise objection.

long arr = new long[256,-2]; should be more than sufficient, in fact the lucky bcd folks from the COBOL line would like the possible new long[256,-3]; option. The special of new long[256,1]; would produce an array of long. All intermediate calculations being long. Well, more to the point long being an array of int, and the second number being a multiplier/divider. The special value of default 0 being int[]... 

This is an effective way to build in multi-precision arithmetic.
 
> > Any other types would be library based. For example String.
> >
> 
> fair enough, but it is worth noting that in most "industrial strength" 
> languages, strings are mostly library features anyways (it is mostly 
> scripting languages which build strings directly into the VM).
> 
> but, not implementing some form of built in string support (at the 
> language level) just wouldn't work out well, as one needs to be able to 
> conveniently declare string constants.

Nothing wrong with the default way Java does strings. Except maybe the fact that string constant arrays can not be interleaved with other things without wierdness.

> > The scoping rules being strict relates to SMP. For recursive functions, the extra need to pass some extra parameters, to get extra locals is not a bad idea, as it forces an understanding that automatic synchronization, would already enforce. And would lead to simpler recursive functions using the instance variables as type 'static in the c function sense' for data pass back to the single writer previous recursion instance.
> >
> > Now if your thinking how would the usual ijk for loop variables be defined within multiple methods, and not generate a 'multiple writer method error' this is just syntax, and forcing actually descriptive variable names is surely a good thing. The fact that the data segment would grow in size, as the method instance variable set grew would be more of an issue. But then again, I never suggested removing the word 'transient'. After all if a stack frame local is not transient then what is? The word volatile also becomes redundant, as all class variables are volatile.
> >
> 
> I disagree, these don't seem like a good idea.

Thats because processors do not support fetch data as read only, and have much bus snoop logic to juggle the write back from multiple cores issue. Invalidation
 of cache line in the other core, can slow things down. The class variable idea, is just a syntax hack at present in the thought, but the one writer method is a useful idea for multi-threaded code.

> really, what I think as the baseline of what is needed is lexical-scope 
> and object-scope, and maybe some form of top-level scope (albeit Java 
> and C# and similar use class-static scope as an alternative here).

transient/local scope
method writable scope
class writable scope
package writable scope
 
> what is more optional is nested packages/namespaces and using/import 
> style semantics.
>  
> my BS2 language had included:
> lexical scope (in my case, following Lisp/Scheme style rules);
> dynamic scope (like in Common Lisp);
> object scope (AKA: 'this' scope);
> dynamic delegation scope (adapted from the Self object model onto a 
> Class/Instance system, as an extension to object scope);
> class-static scope (like in Java and C#);
> toplevel and package scope (included import and so on, uses AS3 style 
> syntax).
> 
> typically, all of these (including dynamic scope) generally followed 
> lexical-scope nesting order though, hence it was generally still 
> necessary to declare dynamic-scope variables (doing so would typically 
> also introduce a new binding frame for them).
> 
> 
> the BGBScript scope model is a little simpler:
> lexical scope;
> dynamic scope;
> object scope (includes dynamic delegation by default, BS uses a 
> Prototype-OO model).
> 
> the toplevel uses object scope, so effectively there are 2 object 
> scopes: 'this' and a mostly invisible 'top' object.

ActionScript has similar.

> at present, BS supports object delegation via the lexical scope as well 
> (newer feature), which is used for 'import' (previously, 'import' used 
> object delegation, which gives different semantics, whereas BS2 would 
> have included both forms as "import" vs "delegate import").
> 
> IOW:
> "import foo.bar;"
> is compiled as if it were:
> "delegate var XXX=foo.bar;" where XXX is a "GenSym()" name 
> (auto-generated variable name).
> 
> someone had before suggested "import foo.bar as baz;", which in the 
> current implementation would simply use "baz" in place of the "GenSym()" 
> call.

I had the idea once to have an encapsulate command, so all globals became instance vars, and all global functions became methods of a class which became encapsulated.

> conceptually, 'top', as well as packages, could be built simply via 
> placing delegates in the lexical scope. one could also place 'this' in 
> the dynamic scope, if so desired. conceptually, both dynamic and lexical 
> scope could be reduced to objects and delegation (essentially leaving a 
> variant on the Self model).
> 
> however, in a practical sense, there is little reason to do all this 
> (and it would also do bad things to performance and memory overhead).
> 
> 
> but, in any case, it makes some sense to support delegation as a basic 
> part of the scoping model.
> 
> then, for example, with a C-like core, one could have implemented much 
> of C++ semantics, effectively, simply as a library feature...
> 
> "dynamic delegate Object *this;"
> 
> 
> but, alas...

Sometimes I look at J and think, nice, but how is your average programmer going to make a multi-threaded timer synchronized arcade utility with that? Then I think back and wonder if compiled SuperBASIC would not be the way forward. Then I think of C and see there's a lot of it about, but is it really conceptually easy enough to give sensible execution with floating pointers? Then I give Tcl a whirl, and think, a bit strange for the small machine model. Then I think the scheme-ers will make a distro anyhow. And then Java, but do find it a pain, and soon to maybe need a license in certain markets. It is time for a new language for the android base, looks like ... 

[toc] | [next] | [standalone]

#289

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.

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

#290

"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 

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

#291

On 6/6/2011 12:45 PM, 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
>

generally, the term HLL is used for much of anything higher-level than 
ASM. also, C++ and Java are at roughly the same level of abstraction, 
differing mostly in terms of their implementations.

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

#303

BGB <cr88192@hotmail.com> wrote:

> On 6/6/2011 12:45 PM, 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
> >
> 
> generally, the term HLL is used for much of anything higher-level than 
> ASM.

That's not true. There are levels discernible between asm and HLL each with
its own characteristics like I mentioned.

> also, C++ and Java are at roughly the same level of abstraction, 
> differing mostly in terms of their implementations.

That's not true either. C++ is still compiled to native code. Java has a
whole order of abstraction more than that, it has its own underlying
machine, native GC etc.

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

#304

Fritz Wuehler wrote:
> BGB <cr88192@hotmail.com> wrote:
>
>> On 6/6/2011 12:45 PM, 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
>>>
>>
>> generally, the term HLL is used for much of anything higher-level
>> than ASM.
>
> That's not true.

He said "generally".

> There are levels discernible between asm and HLL
> each with its own characteristics like I mentioned.

That doesn't mean everyone chooses to recognize those differences or 
categorize them the same way.

>
>> also, C++ and Java are at roughly the same level of abstraction,
>> differing mostly in terms of their implementations.
>
> That's not true either.

Agreed for sure. What was he thinking?!

> C++ is still compiled to native code. Java
> has a whole order of abstraction more than that, it has its own
> underlying machine, native GC etc. 

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

#309

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

> Fritz Wuehler wrote:
> > BGB <cr88192@hotmail.com> wrote:
> >
> >> On 6/6/2011 12:45 PM, 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
> >>>
> >>
> >> generally, the term HLL is used for much of anything higher-level
> >> than ASM.
> >
> > That's not true.
> 
> He said "generally".

I guess it depends what circles you run in. I was around when there was only
assembler and FORTRAN. We continued making a distinction when new languages
came out.

> 
> > There are levels discernible between asm and HLL
> > each with its own characteristics like I mentioned.
> 
> That doesn't mean everyone chooses to recognize those differences or 
> categorize them the same way.

The people I work with all view it the same. You seem to lump everything
together. That isn't very meaningful. I prefer the way we look at it. More
distinctions are usually better than fewer when we are discussing technical
issues. I guess if you are a manager you only have to know assembly and HLL

;-)

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

#310

Nomen Nescio wrote:
> "Tony" <nospam@myisp.net> wrote:
>
>> Fritz Wuehler wrote:
>>> BGB <cr88192@hotmail.com> wrote:
>>>
>>>> On 6/6/2011 12:45 PM, 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
>>>>>
>>>>
>>>> generally, the term HLL is used for much of anything higher-level
>>>> than ASM.
>>>
>>> That's not true.
>>
>> He said "generally".
>
> I guess it depends what circles you run in. I was around when there
> was only assembler and FORTRAN. We continued making a distinction
> when new languages came out.
>
>>
>>> There are levels discernible between asm and HLL
>>> each with its own characteristics like I mentioned.
>>
>> That doesn't mean everyone chooses to recognize those differences or
>> categorize them the same way.
>
> The people I work with all view it the same. You seem to lump
> everything together. That isn't very meaningful. I prefer the way we
> look at it. More distinctions are usually better than fewer when we
> are discussing technical issues. I guess if you are a manager you
> only have to know assembly and HLL
>
> ;-)

Well, I maintain, as many, many others do, that assembly languages are 
2GLs (2nd Generation Languages), C and C++ are examples of  3GLs and 
those nifty "RAD" (remember that term?) tools are (were?) 4GLs. 
Generation 3 is the departure from LLL and everything in that 
"generation" and beyond is a HLL. If someone wishes to break down the 
main categories with some subjective other criteria within those groups, 
fine and dandy. A picture is worth a thousand words, so here:

Languages
    Low-Level Languages (1GL, 2GL)
        Assembly Languages, machine code...
    High-Level Languages (3GL, 4GL...)
        Fortran, C, C++, D, Java...

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

#311

On Thu,  9 Jun 2011 02:31:43 +0200 (CEST), Nomen Nescio
<nobody@dizum.com> wrote:

>"Tony" <nospam@myisp.net> wrote:
>
>> Fritz Wuehler wrote:
>> > BGB <cr88192@hotmail.com> wrote:
>> >
>> >> On 6/6/2011 12:45 PM, 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
>> >>>
>> >>
>> >> generally, the term HLL is used for much of anything higher-level
>> >> than ASM.
>> >
>> > That's not true.
>> 
>> He said "generally".
>
>I guess it depends what circles you run in. I was around when there was only
>assembler and FORTRAN. We continued making a distinction when new languages
>came out.

Don't forget Algol.  Actually lisp was around very early also.
>
>> 
>> > There are levels discernible between asm and HLL
>> > each with its own characteristics like I mentioned.
>> 
>> That doesn't mean everyone chooses to recognize those differences or 
>> categorize them the same way.
>
>The people I work with all view it the same. You seem to lump everything
>together. That isn't very meaningful. I prefer the way we look at it. More
>distinctions are usually better than fewer when we are discussing technical
>issues. I guess if you are a manager you only have to know assembly and HLL
>
>;-)

My experience is the other way around.  The original distinction was
and is significant; the other distinctions (gradations in height) are
mostly language marketing bushwa.  Over the years I seen a lot of
evaporating silver bullets.  The transition from programming the
language of the machine to programming an abstract language was
radical.  The various improvements, such as they are, in programming
technology since then are more in the nature of localized incremental
improvements.

  

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

#312

On 6/9/2011 9:37 AM, Richard Harter wrote:
> On Thu,  9 Jun 2011 02:31:43 +0200 (CEST), Nomen Nescio
> <nobody@dizum.com>  wrote:
>
>> "Tony"<nospam@myisp.net>  wrote:
>>
>>> Fritz Wuehler wrote:
>>>> BGB<cr88192@hotmail.com>  wrote:
>>>>
>>>>> On 6/6/2011 12:45 PM, 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
>>>>>>
>>>>>
>>>>> generally, the term HLL is used for much of anything higher-level
>>>>> than ASM.
>>>>
>>>> That's not true.
>>>
>>> He said "generally".
>>
>> I guess it depends what circles you run in. I was around when there was only
>> assembler and FORTRAN. We continued making a distinction when new languages
>> came out.
>
> Don't forget Algol.  Actually lisp was around very early also.
>>
>>>
>>>> There are levels discernible between asm and HLL
>>>> each with its own characteristics like I mentioned.
>>>
>>> That doesn't mean everyone chooses to recognize those differences or
>>> categorize them the same way.
>>
>> The people I work with all view it the same. You seem to lump everything
>> together. That isn't very meaningful. I prefer the way we look at it. More
>> distinctions are usually better than fewer when we are discussing technical
>> issues. I guess if you are a manager you only have to know assembly and HLL
>>
>> ;-)
>
> My experience is the other way around.  The original distinction was
> and is significant; the other distinctions (gradations in height) are
> mostly language marketing bushwa.  Over the years I seen a lot of
> evaporating silver bullets.  The transition from programming the
> language of the machine to programming an abstract language was
> radical.  The various improvements, such as they are, in programming
> technology since then are more in the nature of localized incremental
> improvements.
>

yep...

go and compare coding in, say, C or C++, with coding directly in ASM...
the ASM is *far* more painful, and *far* less portable...

also, the main cause of C code incompatibility is mostly OS-level API 
incompatibilities. whereas ASM will generally not work with either a 
different CPU architecture, or often usually with a different assembler.

adding a VM into the mix can improve OS portability, but usually at the 
cost of adding a dependency on the VM in use (so, a gain and a loss at 
the same time).

...


probably, the classification into 2GL / 3GL / 4GL is more useful IMO.
for example:
GAS (GNU Assembler) would be a 2GL;
C, C++, and Java would be 3GLs;
...

although they exist, the divisions between languages in a given 
"generation" are not nearly so drastic, and the exact differences in 
terms of "high-levelness" is a bit more blurry (it is much easier to 
compare features, say, which languages have and omit which features).
...

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

#313

On 9 Jun., 19:39, BGB <cr88...@hotmail.com> wrote:
> On 6/9/2011 9:37 AM, Richard Harter wrote:
>
> > On Thu,  9 Jun 2011 02:31:43 +0200 (CEST), Nomen Nescio
> > <nob...@dizum.com>  wrote:
>
> >> I guess it depends what circles you run in. I was around when there was only
> >> assembler and FORTRAN. We continued making a distinction when new languages
> >> came out.
>
> > Don't forget Algol.  Actually lisp was around very early also.
>
> >>>> There are levels discernible between asm and HLL
> >>>> each with its own characteristics like I mentioned.
>
> >>> That doesn't mean everyone chooses to recognize those differences or
> >>> categorize them the same way.
>
> >> The people I work with all view it the same. You seem to lump everything
> >> together. That isn't very meaningful. I prefer the way we look at it. More
> >> distinctions are usually better than fewer when we are discussing technical
> >> issues. I guess if you are a manager you only have to know assembly and HLL
>
> >> ;-)
>
> > My experience is the other way around.  The original distinction was
> > and is significant; the other distinctions (gradations in height) are
> > mostly language marketing bushwa.  Over the years I seen a lot of
> > evaporating silver bullets.  The transition from programming the
> > language of the machine to programming an abstract language was
> > radical.  The various improvements, such as they are, in programming
> > technology since then are more in the nature of localized incremental
> > improvements.
>
> yep...
>
> go and compare coding in, say, C or C++, with coding directly in ASM...
> the ASM is *far* more painful, and *far* less portable...
>
> also, the main cause of C code incompatibility is mostly OS-level API
> incompatibilities. whereas ASM will generally not work with either a
> different CPU architecture, or often usually with a different assembler.
>
> adding a VM into the mix can improve OS portability, ...

Most OS portability problems come from different OS APIs
and NOT from different CPU architectures. There are even
several operating systems that are available on different
CPU architectures. This way (the sourcecode) of programs
can be moved between CPU architectures. A VM does really
NOT help to solve OS portability problems. A portable
library can help to solve OS portability problems, but
this is independend of its implementation (with native
code or with a VM). Just because Java has a huge portable
library AND runs under a VM does not turn a VM into a
tool for portability. Java programs are portable because
of the library and not because of the VM. When Java would
be compiled to native code, it would still be portable,
because of its library.

For that reason I try to provide a portable library.
See: http://seed7.sourceforge.net/libraries


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]

#315

On 6/10/2011 4:46 AM, tm wrote:
> On 9 Jun., 19:39, BGB<cr88...@hotmail.com>  wrote:
>> On 6/9/2011 9:37 AM, Richard Harter wrote:
>>
>>> On Thu,  9 Jun 2011 02:31:43 +0200 (CEST), Nomen Nescio
>>> <nob...@dizum.com>    wrote:
>>
>>>> I guess it depends what circles you run in. I was around when there was only
>>>> assembler and FORTRAN. We continued making a distinction when new languages
>>>> came out.
>>
>>> Don't forget Algol.  Actually lisp was around very early also.
>>
>>>>>> There are levels discernible between asm and HLL
>>>>>> each with its own characteristics like I mentioned.
>>
>>>>> That doesn't mean everyone chooses to recognize those differences or
>>>>> categorize them the same way.
>>
>>>> The people I work with all view it the same. You seem to lump everything
>>>> together. That isn't very meaningful. I prefer the way we look at it. More
>>>> distinctions are usually better than fewer when we are discussing technical
>>>> issues. I guess if you are a manager you only have to know assembly and HLL
>>
>>>> ;-)
>>
>>> My experience is the other way around.  The original distinction was
>>> and is significant; the other distinctions (gradations in height) are
>>> mostly language marketing bushwa.  Over the years I seen a lot of
>>> evaporating silver bullets.  The transition from programming the
>>> language of the machine to programming an abstract language was
>>> radical.  The various improvements, such as they are, in programming
>>> technology since then are more in the nature of localized incremental
>>> improvements.
>>
>> yep...
>>
>> go and compare coding in, say, C or C++, with coding directly in ASM...
>> the ASM is *far* more painful, and *far* less portable...
>>
>> also, the main cause of C code incompatibility is mostly OS-level API
>> incompatibilities. whereas ASM will generally not work with either a
>> different CPU architecture, or often usually with a different assembler.
>>
>> adding a VM into the mix can improve OS portability, ...
>
> Most OS portability problems come from different OS APIs
> and NOT from different CPU architectures. There are even
> several operating systems that are available on different
> CPU architectures. This way (the sourcecode) of programs
> can be moved between CPU architectures. A VM does really
> NOT help to solve OS portability problems. A portable
> library can help to solve OS portability problems, but
> this is independend of its implementation (with native
> code or with a VM). Just because Java has a huge portable
> library AND runs under a VM does not turn a VM into a
> tool for portability. Java programs are portable because
> of the library and not because of the VM. When Java would
> be compiled to native code, it would still be portable,
> because of its library.
>
> For that reason I try to provide a portable library.
> See: http://seed7.sourceforge.net/libraries
>


a VM can help with cross-platform binary compatibility...

but, as noted, the CPU incompatibility was mostly in the context of ASM 
(generally *the* low-level language).

C is generally source-portable between targets, but may generally have 
OS API issues, and if compiled into native binaries, these binaries are 
not themselves portable.

any other language compiled directly to OS binaries will generally also 
not be binary portable between targets.

I had some ideas before for compiling C to bytecode and using JIT-time 
evaluation of #ifdef's, but have not (yet?...) done much of anything 
with it.


granted, one can distribute programs in source-form, and have them be 
generally portable, but this is generally anathema to traditional 
commercial software distribution practices.

or such...

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

#305

On 6/8/2011 5:09 AM, Fritz Wuehler wrote:
> BGB<cr88192@hotmail.com>  wrote:
>
>> On 6/6/2011 12:45 PM, 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
>>>
>>
>> generally, the term HLL is used for much of anything higher-level than
>> ASM.
>
> That's not true. There are levels discernible between asm and HLL each with
> its own characteristics like I mentioned.
>

not as per the term in standard usage.

the existence of finer-grained "levels" is largely irrelevant.

so, ASM is not an HLL (ASM and Macro-ASM are the true LLL's).
pretty much everything with a C-like syntax and above is an HLL.



>> also, C++ and Java are at roughly the same level of abstraction,
>> differing mostly in terms of their implementations.
>
> That's not true either. C++ is still compiled to native code. Java has a
> whole order of abstraction more than that, it has its own underlying
> machine, native GC etc.
>

these are covered by "mostly in terms of their implementations".

the implementation has a higher level of abstraction, but not the 
language itself.

if one were comparing the languages roughly in terms of the individual 
language features, there is not a whole lot of difference as per the 
level of abstraction between them.

both have roughly similar language features (in general, nevermind 
things like pointers and structs), similar capabilities, and similar 
expressive limitations.

both are generally considered to be 3GL's as well.


in terms of Java running on the JVM, and C++ generally compiling 
directly to native code, this makes a good deal of difference in terms 
of using the languages, but it is technically a separate issue.


if both were compiled to VM, or both compiled directly to native code, 
then there wouldn't be nearly as much of a difference. so, in Java's 
case, it is a "high-level implementation" rather than of 
"higher-level-language".

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

#292

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". 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

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

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

#296

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).


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]

#297

On 6/7/2011 1:17 AM, tm 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).
>

and, in my current scripting language, currently more stuff is 
hard-coded into the VM than in Java...


I disagree though that it makes it inherently lower-level though. just 
that the present main strategy is to implement things in C, and plug 
things into the VM (a lot is also done via vtables and callbacks).

this does make it easier for C code to extend/customize the VM, just 
this isn't so readily available for HLL code.

for example, many "Object" methods, such as "toString()" are infact 
special-case logic, which is redirected through C-side vtable structures 
by the VM (may redirect back to object methods for some types, such as 
Class/Instance objects).

others, such as "clone()", are handled by VM bytecodes. "toString()" 
could also be made into a bytecoded operation, FWIW.

strings themselves are pretty much entirely built-in types.
...


recently I also added new syntax for literal fixed type arrays:
"[1,2,3]UB" creates a 3 element array of unsigned bytes (this seemed 
like the "least nasty" solution).

as well as adding basic VM support for "value types" (could be used for 
"structs" or similar, and for other pass-by-value stuff).


or such...

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

#299

On 7 Jun., 12:07, BGB <cr88...@hotmail.com> wrote:
> On 6/7/2011 1:17 AM, tm wrote:
>
> > On 6 Jun., 23:47, "Tony"<nos...@myisp.net>  wrote:
>
> >> 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).
>
> and, in my current scripting language, currently more stuff is
> hard-coded into the VM than in Java...
>
> I disagree though that it makes it inherently lower-level though. just
> that the present main strategy is to implement things in C, ...

I talked about the interface to a feature, not about its
implementation. The interface should be defined in the language.
The implementation can be done in a different language, e.g.: C.
In case of functions and operators the interface is just the
function header.

The Seed7 library "integer.s7i" defines the addition of integers
with:

  const func integer:
     (in integer: summand1) + (in integer: summand2)
                                                is action "INT_ADD";

You now know that adding two integers yields an integer result.
The 'in' parameters tell you that 'summand1' and 'summand2' will
not be changed by + and that 'summand1' and 'summand2' can be
expressions.

The priority and associativity of the + operator is defined in
the library "syntax.s7i" with:

  $ syntax expr: .(). + .()                is  ->  7;

This tells you that + is an infix operator with priority 7 and it
works left to right. When + is overloaded (e.g. for float) the
overloaded + will have the same priority and associativity. So
only one syntax declaration for the (infix) + operator is needed.

In the example above the function body consists of:

  action "INT_ADD"

This refers to a C function, which implements the integer addition.
In an interpreted program the C function int_add() the does integer
addition. In a compiled program inlined C code is used instead.

BTW, the integer.s7i library is described at:

   http://seed7.sourceforge.net/libraries/integer.htm)

This is not the only library described. The Seed7 Homepage
contains descriptions of 50 libraries. See:

  http://seed7.sourceforge.net/libraries

> ...
> strings themselves are pretty much entirely built-in types.

All functions that deal Seed7 strings are defined in libraries. The
basic string functions are defined in the "string.s7i" library. See:

  http://seed7.sourceforge.net/libraries/string.htm

> recently I also added new syntax for literal fixed type arrays:
> "[1,2,3]UB" creates a 3 element array of unsigned bytes (this seemed
> like the "least nasty" solution).

Seed7 defines array literals also with operators.
Even in this case hard-coded syntax is not necessary.


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]

#298

"tm" <thomas.mertes@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.

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

> 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!

> 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? I don't think so. Although certainly it is useful to 
be able to make something different..

-- 
Bartc 

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

#300

BartC wrote:
> 
> "tm" <thomas.mertes@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.

C standard library functions don't have to be written in C.

-- 
pete

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

#302

On 6/7/2011 4:45 AM, pete wrote:
> BartC wrote:
>>
>> "tm"<thomas.mertes@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.
>
> C standard library functions don't have to be written in C.
>

yes, and in fact, some of them often aren't...

operations like strcmp, sin/cos/tan, ... are very often implemented in 
assembler, and also very often, also built right into the compiler (say, 
your call to strcmp or memcpy causing the compiler to emit specialized 
machine code).


also, my language (BGBScript) is in the category where, at present, the 
vast majority of its basic functionality is hard-coded into the VM.

for example, unlike Java, at present there are no 'Integer' or 'String' 
or 'Array' classes, ...


an advantage of not having 'String' though, is that the strings can be 
represented in a much lighter weight way, namely, the string can be 
encoded in UTF-8 and stored directly into memory.

if I did it like in Java, every string would involve:
a class instance;
an array of UTF-16 codepoints;
...

this would cost significantly more memory, as each class and array involves:
an object header;
the object data.


so, at present, built-in string "Hello":
uses 16-bytes of memory (8 byte GC header, padded up to multiple of 16).
I could store them a little more efficiently in string-tables, but this 
would give up the ability to GC old strings.


if I did it as an instance of a class:
32 bytes, object header, 16 bytes object data;
32 bytes, array header, 32 bytes array data.
total cost: 112 bytes.

is it worth using 7x the memory? IMO, no.
this is for x86, x86-64 would be a bit more (since there are pointers 
involved).

also, the internals would be a bit more complicated, and string 
operations likely a good deal more costly, if classes were used.

now, what about:
class Cons {
var lcar;
var lcdr;
function get car() return lcar;
function get cdr() return lcdr;
function set car(v) lcar=v;
function set cdr(v) lcdr=v;
function get caar() return lcar.car;
...
}

well, this would be looking at 48 bytes per cons (x86).
in the GC, cons cells take, 8 bytes (on x86, 16 bytes on x86-64).
worth a 6x memory overhead?... no.


also, in Java, when one does, say:
int i=42;
String s=i.toString();

it actually does the equivalent of:
String s=new Integer(i).toString();


so, at times, there seems to be good reason in hard-coding some things.


also, it makes it all a bit easier to customize and extend, from C...
after all, being a scripting language, the primary role of BGBScript is 
to expose application-provided functionality. it really doesn't need to 
be its own self-defining or self-contained island, as there is really 
not a whole lot to gain from this...


or such...

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web