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 3 of 3 — ← Prev page 1 2 [3]

#337

On 2011-06-17, Tony <nospam@myisp.net> wrote:
> 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.

Exactly, though I'd say Microsoft in general, and not Windows.

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

#339

Marco van de Voort wrote:
> On 2011-06-17, Tony <nospam@myisp.net> wrote:
>> 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.
>
> Exactly, though I'd say Microsoft in general, and not Windows.

Well, that is a contradiction. I opined that the popularity of the 
framework stems from the association with a popular of a product rather 
than popular because of association with a specific company. I posted 
because you opined that the company was the prime motivator, which I 
suggested is not the case. So, what you opine, is one or the other, hence 
"Eactly, though..." is a contradiction. 

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

#345

On 6/17/2011 6:48 AM, Tony wrote:
> Marco van de Voort wrote:
>> On 2011-06-17, Tony<nospam@myisp.net>  wrote:
>>> 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.
>>
>> Exactly, though I'd say Microsoft in general, and not Windows.
>
> Well, that is a contradiction. I opined that the popularity of the
> framework stems from the association with a popular of a product rather
> than popular because of association with a specific company. I posted
> because you opined that the company was the prime motivator, which I
> suggested is not the case. So, what you opine, is one or the other, hence
> "Eactly, though..." is a contradiction.
>

yeah.

Windows is the effective power-base of Microsoft.

Microsoft makes Windows, Windows makes Microsoft powerful, Microsoft 
makes more Windows, ...

so, .NET is made as a semi-official VM framework for Windows, and 
succeeds partly because of Windows, and partly because it is backed by 
MS, who is effectively the main authority over Windows, ...

also, in terms of interfacing with Windows, .NET is fairly well 
designed, whereas many other languages in their attempt to be portable, 
would not likely integrate nearly so well into Windows.

...


granted, I don't really use .NET because I don't so much want MS 
dependency (and do in-fact develop cross-platform), and because Mono 
isn't very good (it loses a lot of the advantages .NET has on Windows).

I also have a few issues with the JVM (Java is awkward and the FFI 
consistently sucks).

however, from my own experiences (doing my own implementation of the 
JVM), I have found that the terrible FFI is partly a natural consequence 
of the JVM's architecture, and there is no good way to fix it apart from 
making fundamental alterations both to Java and the JVM architecture, 
potentially introducing compatibility and backwards compatibility 
issues, and Oracle is happy enough to believe that the JVM *is* the 
machine and that non-JVM languages don't really exist...

unless of course someone uses some of the new JDK7 features as a basis 
to build a less terrible FFI.


hence, I am left basically using my own language, and facing my own sets 
of issues.

well, hell, it works...

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

#347

On 2011-06-17, Tony <nospam@myisp.net> wrote:
>>
>> Exactly, though I'd say Microsoft in general, and not Windows.
>
> Well, that is a contradiction. I opined that the popularity of the 
> framework stems from the association with a popular of a product rather 
> than popular because of association with a specific company.

The problem is that Windows and Office are closely related in terms of
popularity. I was hinting on that.

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

#349

Marco van de Voort wrote:
> On 2011-06-17, Tony <nospam@myisp.net> wrote:
>>>
>>> Exactly, though I'd say Microsoft in general, and not Windows.
>>
>> Well, that is a contradiction. I opined that the popularity of the
>> framework stems from the association with a popular of a product
>> rather than popular because of association with a specific company.
>
> The problem is that Windows and Office are closely related in terms of
> popularity. I was hinting on that.

As are Windows and .Net. One popular PRODUCT makes the related product 
popular. 

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

#343

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

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

No doubt, anything MS puts out with Windows will succeed simply for a lack
of options.

> 
> 
> 

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

#335

Marco van de Voort wrote:
> And .NET is
> huge.
> Really huge.

That is an opinion. I don't think it is "really huge" (I don't think I'd 
even call it "large"). Look for the .Net namespace chart (I think v3.5 is 
the latest chart available, but close enough) that lays it all out 
clearly and then tell us what you think.

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

#338

On 2011-06-17, Tony <nospam@myisp.net> wrote:
> Marco van de Voort wrote:
>> And .NET is
>> huge.
>> Really huge.
>
> That is an opinion. I don't think it is "really huge" (I don't think I'd 
> even call it "large").

That is your good right, but it would be interesting to know relative to
what?

That of course also goes for me, and I was thinking relative to earlier
application frameworks like Delphi's VCL and MS MFC.

And of course it depends what you take as .NET framework, I also count
directly related frameworks like WCF, WPF etc. Anything installed by the
runtime installer.

> Look for the .Net namespace chart (I think v3.5 is 
> the latest chart available, but close enough) that lays it all out 
> clearly and then tell us what you think.

The fact that it is a namespace rather than a class chart probably says
enough :-)

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

#340

Marco van de Voort wrote:
> On 2011-06-17, Tony <nospam@myisp.net> wrote:
>> Marco van de Voort wrote:
>>> And .NET is
>>> huge.
>>> Really huge.
>>
>> That is an opinion. I don't think it is "really huge" (I don't think
>> I'd even call it "large").
>
> That is your good right, but it would be interesting to know relative
> to what?

Good, now you see my point: your statement was vacuous because it did not 
state relative to what, and mine was facetiously just as vacuous.

>
> That of course also goes for me, and I was thinking relative to
> earlier application frameworks like Delphi's VCL and MS MFC.

But you are also using .Net as an endpoint and not doing any 
extrapolation. I, OTOH, did a lot of extrapolating and see .Net as an 
increment on frameworks such as MFC/OWL.

>
> And of course it depends what you take as .NET framework, I also count
> directly related frameworks like WCF, WPF etc. Anything installed by
> the runtime installer.

WCF and WPF are definitely part of .Net.

>
>> Look for the .Net namespace chart (I think v3.5 is
>> the latest chart available, but close enough) that lays it all out
>> clearly and then tell us what you think.
>
> The fact that it is a namespace rather than a class chart probably
> says enough :-)

Not at all. There are many, many more namespace possibilities, especially 
if you cross over to application domains rather than just the platform 
domain, and that's what I was hinting at. .Net "huge"? Not by any stretch 
of the imagination, IMO. 

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

#336

Marco van de Voort wrote:

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

Batch "programming" is very high level. Less capable/less knowledge 
required/manipulates things at a higher level. Hence, "higher level". 
Batch programming is akin to a program's commandline switches. Indeed, it 
is useful for exactly that!

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

#344

On 6/17/2011 5:53 AM, Tony wrote:
> Marco van de Voort wrote:
>
>> 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.
>
> Batch "programming" is very high level. Less capable/less knowledge
> required/manipulates things at a higher level. Hence, "higher level".
> Batch programming is akin to a program's commandline switches. Indeed, it
> is useful for exactly that!
>

and, meanwhile, I was idly considering the use of an extension for my 
language to allow it to more easily compose command-lines (similar to 
batch and bash-shell scripts).

this would probably be built using my apparently "much reviled" plugin 
system, and mostly as a possible alternative/supplement to my present 
strategy of using makefiles (the main alternatives being probably cmake 
or scons...).

I haven't yet devised a "good" way to approach using the language in a 
standalone/self-contained tool though, since I will have a big ugly mess 
if I would want to use it as-is to build itself (and am not so inclined 
to do a miniature/toolified version, mostly due to maintenance concerns).

although "bootstrapping" is theoretically possible, bootstrapped systems 
are kind of an ugly mess (much like trying to get a working GCC rebuilt 
from source, which seemingly itself is almost some kind of black art, 
and depends on already having a recent version of GCC around to build it 
with).


this leaves, of course, sticking with make and doing nothing, as the 
least effort issue...

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

#346

eMarco van de Voort <marcov@turtle.stack.nl> wrote:

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

I think it does in a practical sense since domain specific languages are
all but gone from mainstream use, except perhaps Fortran. I think any
practical definition has to focus on abstraction more than domain
specificity or it becomes irrelevant.

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

I don't think there's any question here. I don't understand what you are
asking. Languages aren't higher level because they are new or shiny, they're
high level because they provide more abstraction from the machine and hence
increased application portability. I can name (and will, further on) several
ancient languages that are significantly higher level than much newer
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.
> 
> IMHO that is a different subject, but that is certainly happening.

I think it reaches to the heart of the matter. The separation of languages
today from their essential libraries is misleading and confusing. It's
artificial in the sense the language is essentially unusable without the
core libraries.

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

To the extent libraries aren't exactly portable across implementations, the
separation is a perfect example of how not to implement things. Unnecessary
exposure of the way a system is designed just makes it less portable. When
the day comes that libraries are totally standalone from platform to
platform and language to language, this problem will be solved. Until then,
it doesn't help one bit in getting work done or anything but confusion and
artificially fragmenting the language spec just to make the language look
skinnier (and acceptable) than it really is. Nobody's fooling me when they
show me a language spec 20 pages long that actually provides no link to the
outside world and then has a library manual 1,200 pages long that you have
to use or else you can't get anything done except add two numbers together.

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

That's the point, the language can't stand on its own. Therefore, it's
misleading and dishonest to make this separation. Again, it's an
implementation issue, not a packaging issue. It should not be exposed in the
packaging, the language and libraries should be one coherent package and
nobody should know if he's using a native language feature or a library
call. Look at PL/I for a very old example of things should be done. PL/I has
a very rich language spec and nobody using it has to be aware of how its
implemented. A function call might be part of the language or it might be an
external library call. Nobody needs to know and it doesn't make any
practical difference.

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

Touche!

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

Yes, that is an excellent point that bears much repeating.

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

I don't know anything about it but knowing where it comes from I believe
you.

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

I guess I would dispute that definition since I am familiar with a
half-dozen scripting languages of the 1970s and later that I have used, and
a half dozen more that I used lightly in later years or saw being used.
Scripting languages weren't meant to execute programs in a certain order any
more than other programs could be said to be meant to do that. Scripting
languages at the beginning were ways to provide an interpreted facility that
made it easy to interact with the specific environment, usually for the
purpose of automating tasks that used to require human intervention. They
usually provided high level constructs and little recovery as opposed to the
compiled languages of the same era. It's true they've moved away from that
specific use *as a goal* to where they now try to compete with traditional
compiled languages, but the essence is still interacting with the system and
automating tasks in an interpretive way, it's just that they do it cross
platform now instead of being restricted to only one platform.

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

I don't know what time period you are talking about, but if you look at
exec, exec II, and REXX on IBM you will find even exec had variables and
control structures. And TSO proc also had the same thing, probably as far
back as 1972.

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

Again, the level has nothing to do with how new the language is, so I don't
see any contradiction. For example, look at APL and SNOBOL4. APL provides an
almost total abstraction such that it's portable across almost any platform,
and it's very high level, providing things like matrix inversion with one
operator. Again, I'm focusing on the use, not the implementation. I'm sure
it's a nightmare to port any heavily mathematical or string processing
language from platform to platform because of how differently different
platforms process those objects. SNOBOL4 aside from its I/O, which is
platform specific, is very high level and offers pattern matching far
superior to Perl raised to the power of Awk. And it has been ported to many
platforms (I don't have any experience with it except on 2 of those) so it
can be done and relatively painlessly as far as the guy using it is concerned.

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

Perl, Python, Ruby, Lua, and even bash are portable across every x86
platform and numerous other non x86 platforms. You can throw Rexx in there,
since it's been ported all over the place.

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

I don't know because I don't use it, but I believe it must because the
Windows port has been out a long time.

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

LOL!

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

#351

eMarco van de Voort <marcov@turtle.stack.nl> wrote:

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

I think it does in a practical sense since domain specific languages are
all but gone from mainstream use, except perhaps Fortran. I think any
practical definition has to focus on abstraction more than domain
specificity or it becomes irrelevant.

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

I don't think there's any question here. I don't understand what you are
asking. Languages aren't higher level because they are new or shiny, they're
high level because they provide more abstraction from the machine and hence
increased application portability. I can name (and will, further on) several
ancient languages that are significantly higher level than much newer
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.
> 
> IMHO that is a different subject, but that is certainly happening.

I think it reaches to the heart of the matter. The separation of languages
today from their essential libraries is misleading and confusing. It's
artificial in the sense the language is essentially unusable without the
core libraries.

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

To the extent libraries aren't exactly portable across implementations, the
separation is a perfect example of how not to implement things. Unnecessary
exposure of the way a system is designed just makes it less portable. When
the day comes that libraries are totally standalone from platform to
platform and language to language, this problem will be solved. Until then,
it doesn't help one bit in getting work done or anything but confusion and
artificially fragmenting the language spec just to make the language look
skinnier (and acceptable) than it really is. Nobody's fooling me when they
show me a language spec 20 pages long that actually provides no link to the
outside world and then has a library manual 1,200 pages long that you have
to use or else you can't get anything done except add two numbers together.

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

That's the point, the language can't stand on its own. Therefore, it's
misleading and dishonest to make this separation. Again, it's an
implementation issue, not a packaging issue. It should not be exposed in the
packaging, the language and libraries should be one coherent package and
nobody should know if he's using a native language feature or a library
call. Look at PL/I for a very old example of things should be done. PL/I has
a very rich language spec and nobody using it has to be aware of how its
implemented. A function call might be part of the language or it might be an
external library call. Nobody needs to know and it doesn't make any
practical difference.

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

Touche!

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

Yes, that is an excellent point that bears much repeating.

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

I don't know anything about it but knowing where it comes from I believe
you.

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

I guess I would dispute that definition since I am familiar with a
half-dozen scripting languages of the 1970s and later that I have used, and
a half dozen more that I used lightly in later years or saw being used.
Scripting languages weren't meant to execute programs in a certain order any
more than other programs could be said to be meant to do that. Scripting
languages at the beginning were ways to provide an interpreted facility that
made it easy to interact with the specific environment, usually for the
purpose of automating tasks that used to require human intervention. They
usually provided high level constructs and little recovery as opposed to the
compiled languages of the same era. It's true they've moved away from that
specific use *as a goal* to where they now try to compete with traditional
compiled languages, but the essence is still interacting with the system and
automating tasks in an interpretive way, it's just that they do it cross
platform now instead of being restricted to only one platform.

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

I don't know what time period you are talking about, but if you look at
exec, exec II, and REXX on IBM you will find even exec had variables and
control structures. And TSO proc also had the same thing, probably as far
back as 1972.

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

Again, the level has nothing to do with how new the language is, so I don't
see any contradiction. For example, look at APL and SNOBOL4. APL provides an
almost total abstraction such that it's portable across almost any platform,
and it's very high level, providing things like matrix inversion with one
operator. Again, I'm focusing on the use, not the implementation. I'm sure
it's a nightmare to port any heavily mathematical or string processing
language from platform to platform because of how differently different
platforms process those objects. SNOBOL4 aside from its I/O, which is
platform specific, is very high level and offers pattern matching far
superior to Perl raised to the power of Awk. And it has been ported to many
platforms (I don't have any experience with it except on 2 of those) so it
can be done and relatively painlessly as far as the guy using it is concerned.

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

Perl, Python, Ruby, Lua, and even bash are portable across every x86
platform and numerous other non x86 platforms. You can throw Rexx in there,
since it's been ported all over the place.

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

I don't know because I don't use it, but I believe it must because the
Windows port has been out a long time.

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

LOL!

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

#352

Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net>
writes:


> I think it does in a practical sense since domain specific languages are
> all but gone from mainstream use, except perhaps Fortran.

If you call Fortran domain specific, then all scripting languages are
domain specific: Fortran is used for scientific programming and
scripting languages are used for scripting.  Sure, some use scripting
languages for other things, but some use Fortran for anything (google
for "Real programmers don't use Pascal").

Also, there are more "real" domain-specific languages in use now than
there has ever been before.  Most are used for very specialised purposes
and possibly only within a single company, so few of them are known in
the general community.  See more in
http://en.wikipedia.org/wiki/Domain-specific_language

	Torben

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

#354

torbenm@diku.dk (Torben Ægidius Mogensen) wrote:

> Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net>
> writes:
> 
> 
> > I think it does in a practical sense since domain specific languages are
> > all but gone from mainstream use, except perhaps Fortran.
> 
> If you call Fortran domain specific, then all scripting languages are
> domain specific: Fortran is used for scientific programming and
> scripting languages are used for scripting. 

No, that's silly. Let's extend your metaphor and say all programming
languages are domain specific because they're all used for programming.

Fortran is a good example of a domain specific language because of two
facts. It has provisions for doing things in math with high accuracy and
precision with an ease and clarity that aren't found in many other languages
AND it is limited enough that it's not a good general purpose language.

Scripting languages today are wide open, they compete with compiled language
feature for feature (not implementation details, features). To say they're
domain specific is to totally misunderstand what scripting languages today
are about. They have moved far from the idea of automating administrative
tasks to where they are expected to be full programming solutions for cross
platform use, especially by people who aren't skilled in heavy languages
like C++.

> Sure, some use scripting languages for other things, but some use Fortran
> for anything (google for "Real programmers don't use Pascal").

Just because people abuse something doesn't change its definition. Real
programmers don't use Pascal, but real programmers don't use Fortran for
everything either. That's just stupid.
> 
> Also, there are more "real" domain-specific languages in use now than
> there has ever been before.  Most are used for very specialised purposes
> and possibly only within a single company, so few of them are known in
> the general community.  See more in
> http://en.wikipedia.org/wiki/Domain-specific_language

I stopped reading wikipedia because it's so full of errors. For sure nobody
can prove anything by pointing to wikipedia articles. Aside from hardware
design they are very few domain specific languages and even in that
environment there aren't many. For the last years things have been moving
towards general purpose bloatware languages and nobody is interested in
domain specific languages. Fortran is the last man standing.

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

#353

"Fritz Wuehler" <fritz@spamexpire-201106.rodent.frell.theremailer.net> wrote
in message
news:51fe5c9226a7990717bb8f64c4c21a2f@msgid.frell.theremailer.net...

> To the extent libraries aren't exactly portable across implementations,
> the
> separation is a perfect example of how not to implement things.
> Unnecessary
> exposure of the way a system is designed just makes it less portable. When
> the day comes that libraries are totally standalone from platform to
> platform and language to language, this problem will be solved. Until
> then,
> it doesn't help one bit in getting work done or anything but confusion and
> artificially fragmenting the language spec just to make the language look
> skinnier (and acceptable) than it really is. Nobody's fooling me when they
> show me a language spec 20 pages long that actually provides no link to
> the
> outside world and then has a library manual 1,200 pages long that you have
> to use or else you can't get anything done except add two numbers
> together.

My main language at the moment is interpreted, and has little in the way of
it's own libraries.

However it provides an easy mechanism to call any DLL function (this is for
Windows), and hence numbers of existing, external libraries are available
(for example Win32 API, even the C standard library). Sometimes the
interfacing is a little awkward, but no-one can say there is no way to talk
to the outside world! (Besides, basic i/o is done via statements, not
functions.)

Of course, for mainstream use, any libraries would need to be standardised
(for example Win32 is too crude and low-level to be used directly --  you
might as well use C -- so much wrapping of these is needed). Then the
libraries become part of the language. And the problem is that in other
people's hands, especially people with little else to do, these libraries do
seem to become huge as they throw in everything they can possibly think of.

-- 
Bartc 

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

#333

Fritz Wuehler wrote:

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

I use C++ extensively but eschew its standard library.

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

#342

On 6/17/2011 5:37 AM, Tony wrote:
> Fritz Wuehler wrote:
>
>> Neither Java
>> nor C++ would be worth anything without their respective libraries.
>
> I use C++ extensively but eschew its standard library.
>

yep.

it is just Java that wouldn't be worth much without its library, as the 
core language for Java sucks.

C and C++ OTOH, have a very capable core language, and so what can be 
done without using any library facilities is much greater (generally 
reducing library use mostly to things like interfacing with facilities 
provided by the external OS).


granted though, most Java developers have developed a mindset of "which 
class do I use to accomplish task X" and expect to be handed 
"PremadeClassWhichDoesTaskX", sort of rendering them fairly incapable of 
actually using core language facilities even if given a language which 
can do so.

this is partway why, even though my language mostly follows similar 
designs to the like of JavaScript, ActionScript, and Java, still ends up 
adding many C-like features.


for example, a few things which will work in BGBScript:
var s="Hello";
while(*s)
     printf("%d ", *s++);
printf("\n");

and:
function foo(rx)
     { *rx=3; }
var x;
foo(&x);

although, in both cases, how these features work differs somewhat with C 
(no raw pointers involved here...).

the former is based on a special property of strings and arrays.
in the later, the reference is based on using a boxed object.

I may later add the ability to type:
function foo(&x)
     { x=3; }
where accessing x will add the '*' on its own.
unlike C++, it will still be needed to use "&x" with the caller.


or such...

[toc] | [prev] | [standalone]

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

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

csiph-web