On 2022-03-18, abrsvc <dansabrservices@yahoo.com> wrote:
>
>> And if they only know Fortran, that's all they can do.
>> Simon.
>>
> Horse crap!!
>
> I started with an assembly language for the 6502 and the first "real" programming language was FORTRAN.
> Since then, I have successfully coded in many languages (last count 15+). Don't generalize.
>
> I also disagree that the language makes the programmer. Programming is a way of thinking and logical progression of steps. Yes these steps may happen in parallel, but fundamentally, programming is just a way to state steps in solving a problem.
>
> I think that it is much more valuable to learn how to think and break down problems into steps rather than to be an expert in the syntax of a language. You can easily look up the syntax on how to accomplish what you need to accomplish. It is much harder to "fit" an elegant technique to a problem just for the sake of using that technique. And yes, I have seen programmers "find a way" to use a feature of a language even though it was not the right way to get the job done.

And you have just made the same mistake that way too many people make Dan.

Learning a programming language is not about learning the syntax, it
is about learning the idioms of that language and _why_ those idioms
exist.

For one very specific example, you can write C style code using Ada
syntax (for example, by making everything an Integer, etc), but it
isn't until someone shows you the Ada way of doing things, and tells
you _why_ the Ada way of doing things exists, that you really start
to write more robust code using techniques that you can then use in
all your programs from now on.

That's why Pascal and other languages were created - to expose students
to concepts and techniques that they may otherwise have not have been
exposed to. So yes, the language the student uses to learn those concepts
really does make a major difference.

BTW, for another really simple example more people here might be aware of,
how many people still use the unchecked array access syntax in C++ because
that's what they are used to elsewhere, instead of having had it drummed
into them during teaching to use the checked access syntax instead when
they are writing important code (and ideally in all the code they write) ?

You can write valid C++ programs using the unchecked syntax, but more
errors will be detected in your code if you use the checked syntax instead.
So no, once again, it's not just about learning some new syntax.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-03-18 20:38, abrsvc wrote:
>
>> And if they only know Fortran, that's all they can do.
>> Simon.
>>
> Horse crap!!

I sortof agree with that. Just because you've only seen one language or
another does not mean you cannot figure other things out, or do things
in many different ways.

> I started with an assembly language for the 6502 and the first "real" programming language was FORTRAN.
> Since then, I have successfully coded in many languages (last count 15+). Don't generalize.

Definitely. One should never generalize.

> I also disagree that the language makes the programmer. Programming is a way of thinking and logical progression of steps. Yes these steps may happen in parallel, but fundamentally, programming is just a way to state steps in solving a problem.

Now, sadly, here is where you actually prove Simon right. But again, we
should not generalize. Just because you don't know does not mean others
cannot know or figure it out.

And actually, no, programming isn't necessarily what you describe. That
is one paradigm, and the most common one. But it's not the only one. And
for some kind of problems, you can gain a lot by not approaching a
problem that way.

My prime example is Prolog. Which is a programming language you would
probably struggle a lot with, because you do not describe a program as a
logical progression of steps. You instead describe things in the form of
associations or relations, and then you let the language find the
solution to your stated problem.

Which of course can then happen in many different ways, giving different
answers, and in different orders.

It's a very interesting language, and I know lots of people have
problems figuring out how to use it. But once you do, some things
suddenly become very easy, but different.

Languages like Lisp or Haskell or whatever, is also not really as step
wise as you think either.

You've basically been working in just one corner of programming, and
haven't even seen/realized that there are other ways.

> I think that it is much more valuable to learn how to think and break down problems into steps rather than to be an expert in the syntax of a language. You can easily look up the syntax on how to accomplish what you need to accomplish. It is much harder to "fit" an elegant technique to a problem just for the sake of using that technique. And yes, I have seen programmers "find a way" to use a feature of a language even though it was not the right way to get the job done.

Syntax is just a detail. You can look that up in any manual. And yes, if
you've figured out imperative language concepts, they are all pretty
much the same. Some have some feature or capability making solving some
problem a bit easier than others, but there is no significant difference.

But that's not the whole world...

Johnny

On 3/18/2022 8:55 PM, Johnny Billquist wrote:

> Now, sadly, here is where you actually prove Simon right.

Yes, quite sad ...

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Friday, March 18, 2022 at 11:30:57 PM UTC-4, Dave Froble wrote:
> On 3/18/2022 8:55 PM, Johnny Billquist wrote:
>
> > Now, sadly, here is where you actually prove Simon right.
> Yes, quite sad ...
>
> :-)
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

Johnny had it correct. I over generalized after telling Simon no to do just that. Logical steps can and often are comprised of relationships. I did not intend to mean just singular statement steps although that fits as well. Steps can include object creation and use as well as the relationships of those objects. The point I was trying to make (and somewhat failed...) is that syntax is not the key here. AS others have stated, you can look up the specific syntax, but you cannot look up how to think.

On 3/17/2022 7:57 PM, Arne Vajhøj wrote:
> On 3/16/2022 8:55 PM, Simon Clubley wrote:
>> On 2022-03-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 3/16/2022 8:09 PM, Dave Froble wrote:
>>>> On 3/16/2022 7:53 PM, Arne Vajhøj wrote:
>>>>> I think it would have been difficult to find a language easier to
>>>>> learn
>>>>> than Pascal.
>>>>
>>>> Basic on the various DEC systems.
>>>
>>> Wirth, Dijkstra etc. did not like Basic.
>>>
>>> But yes - Basic is also an easy language to learn.
>>
>> Easy to learn but it doesn't mean you are teaching students the right
>> things for when they need to start writing production code. :-)
>
> Teaching something that is easy to learn and teaching something
> that is "right" to learn are two different goals.

And both has changed since Wirth's and Dijkstra's time.

New languages that are easy to learn has been introduced.

And the classic strong static typed structured procedural approach as
the right one has been supplemented by many other approaches.

One reason being that few today believe in same approach to
all types of production code.

I don't think the two gentlemen would like JavaScript, Python,
PHP, R etc. but the fact is that those languages thrive today.

Maybe not in code that controls an airplane with 300 passengers,
but there are plenty of other areas.

Arne

In article <6235f4fc$0$702$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>On 3/17/2022 7:57 PM, Arne Vajhøj wrote:
>> On 3/16/2022 8:55 PM, Simon Clubley wrote:
>>> On 2022-03-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 3/16/2022 8:09 PM, Dave Froble wrote:
>>>>> On 3/16/2022 7:53 PM, Arne Vajhøj wrote:
>>>>>> I think it would have been difficult to find a language easier to
>>>>>> learn
>>>>>> than Pascal.
>>>>>
>>>>> Basic on the various DEC systems.
>>>>
>>>> Wirth, Dijkstra etc. did not like Basic.
>>>>
>>>> But yes - Basic is also an easy language to learn.
>>>
>>> Easy to learn but it doesn't mean you are teaching students the right
>>> things for when they need to start writing production code. :-)
>>
>> Teaching something that is easy to learn and teaching something
>> that is "right" to learn are two different goals.
>
>And both has changed since Wirth's and Dijkstra's time.
>
>New languages that are easy to learn has been introduced.
>
>And the classic strong static typed structured procedural approach as
>the right one has been supplemented by many other approaches.
>
>One reason being that few today believe in same approach to
>all types of production code.
>
>I don't think the two gentlemen would like JavaScript, Python,
>PHP, R etc. but the fact is that those languages thrive today.
>
>Maybe not in code that controls an airplane with 300 passengers,
>but there are plenty of other areas.

Cockpit display:

+--------------------------------------------+
| Engine number 3 has shutdown unexpectedly! |
| |
| Press [Control][Alt][Delete] to restart! |
+--------------------------------------------+

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On Saturday, March 19, 2022 at 11:21:35 AM UTC-4, Arne Vajhøj wrote:
> On 3/17/2022 7:57 PM, Arne Vajhøj wrote:
> > On 3/16/2022 8:55 PM, Simon Clubley wrote:
> >> On 2022-03-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>> On 3/16/2022 8:09 PM, Dave Froble wrote:
> >>>> On 3/16/2022 7:53 PM, Arne Vajhøj wrote:
> >>>>> I think it would have been difficult to find a language easier to
> >>>>> learn
> >>>>> than Pascal.
> >>>>
> >>>> Basic on the various DEC systems.
> >>>
> >>> Wirth, Dijkstra etc. did not like Basic.
> >>>
> >>> But yes - Basic is also an easy language to learn.
> >>
> >> Easy to learn but it doesn't mean you are teaching students the right
> >> things for when they need to start writing production code. :-)
> >
> > Teaching something that is easy to learn and teaching something
> > that is "right" to learn are two different goals.
> And both has changed since Wirth's and Dijkstra's time.
>
> New languages that are easy to learn has been introduced.
>
> And the classic strong static typed structured procedural approach as
> the right one has been supplemented by many other approaches.
>
> One reason being that few today believe in same approach to
> all types of production code.
>
> I don't think the two gentlemen would like JavaScript, Python,
> PHP, R etc. but the fact is that those languages thrive today.
>
> Maybe not in code that controls an airplane with 300 passengers,
> but there are plenty of other areas.
>
> Arne

I have used some of the mentioned languages for some projects with success. I suppose that the point I am making too is that the correct languages should also fit the problem. Using JAVA for example to solve numerical problems makes no sense. FORTRAN is ideal for such things. (I know, Simon will say that C is too...). Just because a language is new and is all the rage, does not mean that it is the right choice.

On 3/19/2022 12:26 PM, abrsvc wrote:
> On Saturday, March 19, 2022 at 11:21:35 AM UTC-4, Arne Vajhøj wrote:
>> On 3/17/2022 7:57 PM, Arne Vajhøj wrote:
>>> On 3/16/2022 8:55 PM, Simon Clubley wrote:
>>>> On 2022-03-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>>> On 3/16/2022 8:09 PM, Dave Froble wrote:
>>>>>> On 3/16/2022 7:53 PM, Arne Vajhøj wrote:
>>>>>>> I think it would have been difficult to find a language easier to
>>>>>>> learn
>>>>>>> than Pascal.
>>>>>>
>>>>>> Basic on the various DEC systems.
>>>>>
>>>>> Wirth, Dijkstra etc. did not like Basic.
>>>>>
>>>>> But yes - Basic is also an easy language to learn.
>>>>
>>>> Easy to learn but it doesn't mean you are teaching students the right
>>>> things for when they need to start writing production code. :-)
>>>
>>> Teaching something that is easy to learn and teaching something
>>> that is "right" to learn are two different goals.
>> And both has changed since Wirth's and Dijkstra's time.
>>
>> New languages that are easy to learn has been introduced.
>>
>> And the classic strong static typed structured procedural approach as
>> the right one has been supplemented by many other approaches.
>>
>> One reason being that few today believe in same approach to
>> all types of production code.
>>
>> I don't think the two gentlemen would like JavaScript, Python,
>> PHP, R etc. but the fact is that those languages thrive today.
>>
>> Maybe not in code that controls an airplane with 300 passengers,
>> but there are plenty of other areas.
>
> I have used some of the mentioned languages for some projects with
> success. I suppose that the point I am making too is that the
> correct languages should also fit the problem.

It is always good to pick the right language for the problem.

> Using JAVA for
> example to solve numerical problems makes no sense. FORTRAN is ideal
> for such things. (I know, Simon will say that C is too...).

Fortran is good at the numerical stuff. And newer language versions
are also way more modern than traditional 66 or 77.

There are some numerical work done in Java and there are numerical
libraries available. But it is definitely third tier in that domain.
I would prefer Kotlin over Java if I had to do numerical stuff in JVM.

> Just
> because a language is new and is all the rage, does not mean that it
> is the right choice.
Most new languages are fine for what they are intended for.

But the above 4 are not exactly new: JavaScript - 1995, Python - 1991,
PHP - 1995, R - 1993.

Arne

On 19/03/2022 18:29, Arne Vajhøj wrote:
> But the above 4 are not exactly new: JavaScript - 1995, Python - 1991,
> PHP - 1995, R - 1993.
>
> Arne
>
or Monty Python - 1969 :)

--
Chris

On 2022-03-19 13:29, abrsvc wrote:
> On Friday, March 18, 2022 at 11:30:57 PM UTC-4, Dave Froble wrote:
>> On 3/18/2022 8:55 PM, Johnny Billquist wrote:
>>
>>> Now, sadly, here is where you actually prove Simon right.
>> Yes, quite sad ...
>>
>> :-)
>> --
>> David Froble Tel: 724-529-0450
>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>> DFE Ultralights, Inc.
>> 170 Grimplin Road
>> Vanderbilt, PA 15486
>
> Johnny had it correct. I over generalized after telling Simon no to do just that. Logical steps can and often are comprised of relationships. I did not intend to mean just singular statement steps although that fits as well. Steps can include object creation and use as well as the relationships of those objects. The point I was trying to make (and somewhat failed...) is that syntax is not the key here. AS others have stated, you can look up the specific syntax, but you cannot look up how to think.

Thanks for being open about criticism.
But you really should look at Prolog. It's not doing steps even in that
more freer form you are trying to fall back to.
In the end, yes, any current Prolog will be doing steps under the hood,
since it is after all running on a traditional computer. But the
language itself is not meaningful to look at as a sequence of steps to
be performed. And yes, any program is inherently parallel.

It's a very interesting language, and one that is very useful for some
kind of problems, but horrible for others... But it's also a language a
lot of people struggle a lot to understand.

Johnny

On 2022-03-19, abrsvc <dansabrservices@yahoo.com> wrote:
>
> I have used some of the mentioned languages for some projects with success. I suppose that the point I am making too is that the correct languages should also fit the problem. Using JAVA for example to solve numerical problems makes no sense. FORTRAN is ideal for such things. (I know, Simon will say that C is too...). Just because a language is new and is all the rage, does not mean that it is the right choice.

Actually Dan, no, I most certainly would _not_ say that.

I would say that C is a _viable_ programming language in that case,
but I would not say that it is an _ideal_ programming language.

You may end up using something that is viable but is not your preferred
language. This could be due to language availability across multiple
environments, the ability of the language to be easily called from
other languages, etc.

This is especially important when you are writing library code for
example. Consider that I can write a portable library in C, and I can
then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
the library is small enough.

I can then easily call that C library from a wide range of languages
running on those multiple operating systems and environments. The language
also allows me to create code that runs both in kernel mode and user mode.

Name one other programming language that allows me to do all that.

So, yes, I do think C is the most viable language in a wide range of areas,
(and it's way better than Macro-32/Bliss), but I do not consider it to be
the _ideal_ language in those areas. I believe I have expressed my
language preferences enough times in this area. :-)

(And I still think it's a pity that Pillar never got established as
an alternative to C).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/21/2022 2:46 PM, Simon Clubley wrote:
> On 2022-03-19, abrsvc <dansabrservices@yahoo.com> wrote:
>> I have used some of the mentioned languages for some projects with
>> success. I suppose that the point I am making too is that the
>> correct languages should also fit the problem. Using JAVA for
>> example to solve numerical problems makes no sense. FORTRAN is
>> ideal for such things. (I know, Simon will say that C is too...).
>> Just because a language is new and is all the rage, does not mean
>> that it is the right choice. >
> Actually Dan, no, I most certainly would _not_ say that.
>
> I would say that C is a _viable_ programming language in that case,
> but I would not say that it is an _ideal_ programming language.
>
> You may end up using something that is viable but is not your preferred
> language. This could be due to language availability across multiple
> environments, the ability of the language to be easily called from
> other languages, etc.
>
> This is especially important when you are writing library code for
> example. Consider that I can write a portable library in C, and I can
> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
> the library is small enough.
>
> I can then easily call that C library from a wide range of languages
> running on those multiple operating systems and environments. The language
> also allows me to create code that runs both in kernel mode and user mode.
>
> Name one other programming language that allows me to do all that.

C compilers are available on most platforms.

But how many percent of C programs are written so that they
are actually guaranteed to work with all ISO compliant C compilers?

Arne

On 2022-03-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/21/2022 2:46 PM, Simon Clubley wrote:
>>
>> I would say that C is a _viable_ programming language in that case,
>> but I would not say that it is an _ideal_ programming language.
>>
>> You may end up using something that is viable but is not your preferred
>> language. This could be due to language availability across multiple
>> environments, the ability of the language to be easily called from
>> other languages, etc.
>>
>> This is especially important when you are writing library code for
>> example. Consider that I can write a portable library in C, and I can
>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>> the library is small enough.
>>
>> I can then easily call that C library from a wide range of languages
>> running on those multiple operating systems and environments. The language
>> also allows me to create code that runs both in kernel mode and user mode.
>>
>> Name one other programming language that allows me to do all that.
>
> C compilers are available on most platforms.
>

I would be interested in knowing about a platform they are not
available on. You can even get them for GPUs...

> But how many percent of C programs are written so that they
> are actually guaranteed to work with all ISO compliant C compilers?
>

The point is that you have the option to write to those standards
and run your code everywhere you might want to.

And just for the record, I _really_ wish C was not the only language
I could say that about...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/21/22 14:46, Simon Clubley wrote:
> On 2022-03-19, abrsvc <dansabrservices@yahoo.com> wrote:
>>
>> I have used some of the mentioned languages for some projects with success. I suppose that the point I am making too is that the correct languages should also fit the problem. Using JAVA for example to solve numerical problems makes no sense. FORTRAN is ideal for such things. (I know, Simon will say that C is too...). Just because a language is new and is all the rage, does not mean that it is the right choice.
>
> Actually Dan, no, I most certainly would _not_ say that.
>
> I would say that C is a _viable_ programming language in that case,
> but I would not say that it is an _ideal_ programming language.
>
> You may end up using something that is viable but is not your preferred
> language. This could be due to language availability across multiple
> environments, the ability of the language to be easily called from
> other languages, etc.
>
> This is especially important when you are writing library code for
> example. Consider that I can write a portable library in C, and I can
> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
> the library is small enough.
>
> I can then easily call that C library from a wide range of languages
> running on those multiple operating systems and environments. The language
> also allows me to create code that runs both in kernel mode and user mode.
>
> Name one other programming language that allows me to do all that.

What does any of that have to do with the language? The specific
compiler maybe, but not necessarily the language. I could see
not doing it in COBOL and probably LISP but otherwise, most languages
can do what you want.

Many programs, right down to the OS itself, on Primos were written
in a number of languages all linked together successfully.

Library-wise, The NAG Mathematical Library was written in Fortran
and I saw it linked to a number of other languages. The low level
languages offered on Primos could link to any other language they
offered (and there were a bunch!) I used the same library to do
an Editor in Fortran, a DNS clone for the Sytek Broadband Network
in Pascal. I saw it used in COBOL to provide Curses-like functions
before they became part of the standard. And even C for some
low level Primos stuff (And Prime had the weirdest C compiler
you are ever likely to see). Languages have little to do with
stuff like this, It is more the mindset of the developer.

>
> So, yes, I do think C is the most viable language in a wide range of areas,
> (and it's way better than Macro-32/Bliss), but I do not consider it to be
> the _ideal_ language in those areas. I believe I have expressed my
> language preferences enough times in this area. :-)
>
> (And I still think it's a pity that Pillar never got established as
> an alternative to C).

Maybe we need to bring back MP/M.... Simple enough that it could
be done on every machine I can think of. Powerful enough to do
the tasks you are talking about. Low-level enough to even do the
hardware stuff usually relegated to C. :-)

bill

On 3/21/2022 3:26 PM, Simon Clubley wrote:
> On 2022-03-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/21/2022 2:46 PM, Simon Clubley wrote:
>>>
>>> I would say that C is a _viable_ programming language in that case,
>>> but I would not say that it is an _ideal_ programming language.
>>>
>>> You may end up using something that is viable but is not your preferred
>>> language. This could be due to language availability across multiple
>>> environments, the ability of the language to be easily called from
>>> other languages, etc.
>>>
>>> This is especially important when you are writing library code for
>>> example. Consider that I can write a portable library in C, and I can
>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>> the library is small enough.
>>>
>>> I can then easily call that C library from a wide range of languages
>>> running on those multiple operating systems and environments. The language
>>> also allows me to create code that runs both in kernel mode and user mode.
>>>
>>> Name one other programming language that allows me to do all that.
>>
>> C compilers are available on most platforms.
>
> I would be interested in knowing about a platform they are not
> available on. You can even get them for GPUs...

I don't know any.

But if any then I would expect it to be either very old platforms
from before C or very tiny platforms only supporting assembler.

>> But how many percent of C programs are written so that they
>> are actually guaranteed to work with all ISO compliant C compilers?
>
> The point is that you have the option to write to those standards
> and run your code everywhere you might want to.

They could but they don't.

Arne

On 3/21/22 20:28, Arne Vajhøj wrote:
> On 3/21/2022 3:26 PM, Simon Clubley wrote:
>> On 2022-03-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 3/21/2022 2:46 PM, Simon Clubley wrote:
>>>>
>>>> I would say that C is a _viable_ programming language in that case,
>>>> but I would not say that it is an _ideal_ programming language.
>>>>
>>>> You may end up using something that is viable but is not your preferred
>>>> language. This could be due to language availability across multiple
>>>> environments, the ability of the language to be easily called from
>>>> other languages, etc.
>>>>
>>>> This is especially important when you are writing library code for
>>>> example. Consider that I can write a portable library in C, and I can
>>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>>> the library is small enough.
>>>>
>>>> I can then easily call that C library from a wide range of languages
>>>> running on those multiple operating systems and environments. The
>>>> language
>>>> also allows me to create code that runs both in kernel mode and user
>>>> mode.
>>>>
>>>> Name one other programming language that allows me to do all that.
>>>
>>> C compilers are available on most platforms.
>>
>> I would be interested in knowing about a platform they are not
>> available on. You can even get them for GPUs...
>
> I don't know any.
>
> But if any then I would expect it to be either very old platforms
> from before C or very tiny platforms only supporting assembler.
>

Well, Z80 and 6809 both meet your criteria of very old and very
small and both of them support C compilers. Maybe not ANSI C but
then, some of us are still quite happy with K&R.

bill

Den 2022-03-22 kl. 02:44, skrev Bill Gunshannon:
> On 3/21/22 20:28, Arne Vajhøj wrote:
>> On 3/21/2022 3:26 PM, Simon Clubley wrote:
>>> On 2022-03-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 3/21/2022 2:46 PM, Simon Clubley wrote:
>>>>>
>>>>> I would say that C is a _viable_ programming language in that case,
>>>>> but I would not say that it is an _ideal_ programming language.
>>>>>
>>>>> You may end up using something that is viable but is not your preferred
>>>>> language. This could be due to language availability across multiple
>>>>> environments, the ability of the language to be easily called from
>>>>> other languages, etc.
>>>>>
>>>>> This is especially important when you are writing library code for
>>>>> example. Consider that I can write a portable library in C, and I can
>>>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>>>> the library is small enough.
>>>>>
>>>>> I can then easily call that C library from a wide range of languages
>>>>> running on those multiple operating systems and environments. The
>>>>> language
>>>>> also allows me to create code that runs both in kernel mode and user
>>>>> mode.
>>>>>
>>>>> Name one other programming language that allows me to do all that.
>>>>
>>>> C compilers are available on most platforms.
>>>
>>> I would be interested in knowing about a platform they are not
>>> available on. You can even get them for GPUs...
>>
>> I don't know any.
>>
>> But if any then I would expect it to be either very old platforms
>> from before C or very tiny platforms only supporting assembler.
>>
>
> Well, Z80 and 6809 both meet your criteria of very old and very
> small and both of them support C compilers.  Maybe not ANSI C but
> then, some of us are still quite happy with K&R.
>
> bill
>
>

When talkning about these kind of systems, you need to
qualify "support". It is not that you are able to run
a C-compiler on any of those "platforms". But there are
dev tools available for Windows/Linux or such, that does
have a C-compiler included for these platforms.

It is more correct to talk about C-compilers that support
these platforms, not the other way around.

On 2022-03-21, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 3/21/22 14:46, Simon Clubley wrote:
>>
>> I would say that C is a _viable_ programming language in that case,
>> but I would not say that it is an _ideal_ programming language.
>>
>> You may end up using something that is viable but is not your preferred
>> language. This could be due to language availability across multiple
>> environments, the ability of the language to be easily called from
>> other languages, etc.
>>
>> This is especially important when you are writing library code for
>> example. Consider that I can write a portable library in C, and I can
>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>> the library is small enough.
>>
>> I can then easily call that C library from a wide range of languages
>> running on those multiple operating systems and environments. The language
>> also allows me to create code that runs both in kernel mode and user mode.
>>
>> Name one other programming language that allows me to do all that.
>
> What does any of that have to do with the language? The specific
> compiler maybe, but not necessarily the language. I could see
> not doing it in COBOL and probably LISP but otherwise, most languages
> can do what you want.
>

Fine. Where do I find the compilers in today's world that allow me
to do all of the above in a language other than C ? :-)

BTW, you are not going to be writing kernel mode device drivers or
kernel modules in Fortran (for example).

BTW #2, you can only easily call C++ code from a non-C++ program by
providing a C interface in the C++ library so you are back to using
C as an interface language even with C++...

Would be nice if that was not the only viable option, but the problem
is that C is a very viable language in all of these cases, even when
it is not an ideal language, so no-one has developed a viable alternative
over the decades.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-03-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> When talkning about these kind of systems, you need to
> qualify "support". It is not that you are able to run
> a C-compiler on any of those "platforms". But there are
> dev tools available for Windows/Linux or such, that does
> have a C-compiler included for these platforms.
>
> It is more correct to talk about C-compilers that support
> these platforms, not the other way around.
>

That's a fair point Jan-Erik. When talking about embedded environments,
we really are indeed talking about C compilers that support the embedded
environment as a target environment, not a host environment.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/22/22 14:38, Simon Clubley wrote:
> On 2022-03-21, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/21/22 14:46, Simon Clubley wrote:
>>>
>>> I would say that C is a _viable_ programming language in that case,
>>> but I would not say that it is an _ideal_ programming language.
>>>
>>> You may end up using something that is viable but is not your preferred
>>> language. This could be due to language availability across multiple
>>> environments, the ability of the language to be easily called from
>>> other languages, etc.
>>>
>>> This is especially important when you are writing library code for
>>> example. Consider that I can write a portable library in C, and I can
>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>> the library is small enough.
>>>
>>> I can then easily call that C library from a wide range of languages
>>> running on those multiple operating systems and environments. The language
>>> also allows me to create code that runs both in kernel mode and user mode.
>>>
>>> Name one other programming language that allows me to do all that.
>>
>> What does any of that have to do with the language? The specific
>> compiler maybe, but not necessarily the language. I could see
>> not doing it in COBOL and probably LISP but otherwise, most languages
>> can do what you want.
>>
>
> Fine. Where do I find the compilers in today's world that allow me
> to do all of the above in a language other than C ? :-)

Well, you missed the point of that entirely.
I specifically said it was the fault of the compiler and not the
fault of any language. Just because no one makes a compiler to
do what you want to do isn't the fault of the languages. Make
your own compiler.

I do have to admit that I am baffled why no one made/makes an
Ada compiler to do this. I thought that was one of the intents
of Ada. But it looks like language snobbery is strong in Ada.
Probably why even the agency responsible for it refused to use
it when it finally came out.

>
> BTW, you are not going to be writing kernel mode device drivers or
> kernel modules in Fortran (for example).

No, cause that's not the intended purpose of that language. But
that really has nothing to do with writing libraries.

>
> BTW #2, you can only easily call C++ code from a non-C++ program by
> providing a C interface in the C++ library so you are back to using
> C as an interface language even with C++...

Once again, languages don't define calling sequences, compilers do.

>
> Would be nice if that was not the only viable option, but the problem
> is that C is a very viable language in all of these cases, even when
> it is not an ideal language, so no-one has developed a viable alternative
> over the decades.

But they could. Just like they could develop a Safe C language and
make compilers for it. That was done. And was met with a resounding
silence and the company just went away. All of these things could be
addressed but all we seem to get is the latest ego language du jour.

bill

On 3/22/22 14:42, Simon Clubley wrote:
> On 2022-03-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>
>> When talkning about these kind of systems, you need to
>> qualify "support". It is not that you are able to run
>> a C-compiler on any of those "platforms". But there are
>> dev tools available for Windows/Linux or such, that does
>> have a C-compiler included for these platforms.
>>
>> It is more correct to talk about C-compilers that support
>> these platforms, not the other way around.
>>
>
> That's a fair point Jan-Erik. When talking about embedded environments,
> we really are indeed talking about C compilers that support the embedded
> environment as a target environment, not a host environment.
>

In the two examples I gave, Z80 and 6809 the C-compilers do support
the environment they run in. And do it natively.

bill

On 3/22/2022 2:38 PM, Simon Clubley wrote:
> On 2022-03-21, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/21/22 14:46, Simon Clubley wrote:
>>>
>>> I would say that C is a _viable_ programming language in that case,
>>> but I would not say that it is an _ideal_ programming language.
>>>
>>> You may end up using something that is viable but is not your preferred
>>> language. This could be due to language availability across multiple
>>> environments, the ability of the language to be easily called from
>>> other languages, etc.
>>>
>>> This is especially important when you are writing library code for
>>> example. Consider that I can write a portable library in C, and I can
>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>> the library is small enough.
>>>
>>> I can then easily call that C library from a wide range of languages
>>> running on those multiple operating systems and environments. The language
>>> also allows me to create code that runs both in kernel mode and user mode.
>>>
>>> Name one other programming language that allows me to do all that.
>>
>> What does any of that have to do with the language? The specific
>> compiler maybe, but not necessarily the language. I could see
>> not doing it in COBOL and probably LISP but otherwise, most languages
>> can do what you want.
>>
>
> Fine. Where do I find the compilers in today's world that allow me
> to do all of the above in a language other than C ? :-)
>
> BTW, you are not going to be writing kernel mode device drivers or
> kernel modules in Fortran (for example).
>
> BTW #2, you can only easily call C++ code from a non-C++ program by
> providing a C interface in the C++ library so you are back to using
> C as an interface language even with C++...
>
> Would be nice if that was not the only viable option, but the problem
> is that C is a very viable language in all of these cases, even when
> it is not an ideal language, so no-one has developed a viable alternative
> over the decades.
>
> Simon.
>

Your argument is, that if one desires to have transportable code, then C allows
that.

But what if one never intends to have transportable code? Then the argument is
meaningless, and, one should choose the language(s) that best support the
task(s) intended.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/22/2022 2:38 PM, Simon Clubley wrote:
> On 2022-03-21, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/21/22 14:46, Simon Clubley wrote:
>>>
>>> I would say that C is a _viable_ programming language in that case,
>>> but I would not say that it is an _ideal_ programming language.
>>>
>>> You may end up using something that is viable but is not your preferred
>>> language. This could be due to language availability across multiple
>>> environments, the ability of the language to be easily called from
>>> other languages, etc.
>>>
>>> This is especially important when you are writing library code for
>>> example. Consider that I can write a portable library in C, and I can
>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>> the library is small enough.
>>>
>>> I can then easily call that C library from a wide range of languages
>>> running on those multiple operating systems and environments. The language
>>> also allows me to create code that runs both in kernel mode and user mode.
>>>
>>> Name one other programming language that allows me to do all that.
>>
>> What does any of that have to do with the language? The specific
>> compiler maybe, but not necessarily the language. I could see
>> not doing it in COBOL and probably LISP but otherwise, most languages
>> can do what you want.
>
> Fine. Where do I find the compilers in today's world that allow me
> to do all of the above in a language other than C ? :-)

But it really all boils down to being widely available.

The reason you can build your library on all those platforms is because
a C compiler is available.

When it comes to code being portable then C code is generally not
great - more like somewhere in the middle (I would expect a higher
portion of Fortran and Cobol to build unchanged and a less portion
of Pascal and Basic).

And C does not have any particular advantages for language interop
either. But given how widely used C are then C interop get more
priority than other language interop.

> Would be nice if that was not the only viable option, but the problem
> is that C is a very viable language in all of these cases, even when
> it is not an ideal language, so no-one has developed a viable alternative
> over the decades.

Frequently it is the language available.

Arne

On 3/22/2022 4:05 PM, Dave Froble wrote:
> On 3/22/2022 2:38 PM, Simon Clubley wrote:
>> Would be nice if that was not the only viable option, but the problem
>> is that C is a very viable language in all of these cases, even when
>> it is not an ideal language, so no-one has developed a viable alternative
>> over the decades.
>
> Your argument is, that if one desires to have transportable code, then C
> allows that.
>
> But what if one never intends to have transportable code?  Then the
> argument is meaningless, and, one should choose the language(s) that
> best support the task(s) intended.

Unless one is writing very HW/OS close code, then portability
is always a plus - maybe it will one day be necessary to port
(only question is whether it is 1% probability or 99% probability)
and there is no drawbacks from being portable (in itself).

So portability should always be counted as a plus. But obviously
there can be other aspects outweighing that in the evaluation.

Also note that while portable code tend to be tricky among
native languages, then it is more the norm in non-native
languages.

Arne

In article <t1d53c$ges$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-03-21, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 3/21/22 14:46, Simon Clubley wrote:
>>>
>>> I would say that C is a _viable_ programming language in that case,
>>> but I would not say that it is an _ideal_ programming language.
>>>
>>> You may end up using something that is viable but is not your preferred
>>> language. This could be due to language availability across multiple
>>> environments, the ability of the language to be easily called from
>>> other languages, etc.
>>>
>>> This is especially important when you are writing library code for
>>> example. Consider that I can write a portable library in C, and I can
>>> then compile it unchanged on VMS, Linux/FreeBSD/Unix, Windows, embedded
>>> operating systems, bare metal ARM/MIPS/etc, and even 8/16-bit MCUs if
>>> the library is small enough.
>>>
>>> I can then easily call that C library from a wide range of languages
>>> running on those multiple operating systems and environments. The language
>>> also allows me to create code that runs both in kernel mode and user mode.
>>>
>>> Name one other programming language that allows me to do all that.
>>
>> What does any of that have to do with the language? The specific
>> compiler maybe, but not necessarily the language. I could see
>> not doing it in COBOL and probably LISP but otherwise, most languages
>> can do what you want.
>>
>
>Fine. Where do I find the compilers in today's world that allow me
>to do all of the above in a language other than C ? :-)

I do pretty much everything listed here in Rust on a daily
basis.

>BTW, you are not going to be writing kernel mode device drivers or
>kernel modules in Fortran (for example).

Hmm, I seem to recall that much of JNet was written in FORTRAN.
On several systems, it was extended enough to be a viable
language for low-level work.

>BTW #2, you can only easily call C++ code from a non-C++ program by
>providing a C interface in the C++ library so you are back to using
>C as an interface language even with C++...

That's not precisely true; you're using an ABI that the C
compiler targets, but that's qualitatively different than using
the C language. For example, in Rust, I can define structures
that use the layout of the system's native ABI, or functions
that use the ABI's calling convention, etc. In my work, that
usually implies calling between Rust and primitives written in
assembly, but not C. In some sense, the connection with C is
incidental, though admittedly many such ABIs were designed as a
target for C primarily.

>Would be nice if that was not the only viable option, but the problem
>is that C is a very viable language in all of these cases, even when
>it is not an ideal language, so no-one has developed a viable alternative
>over the decades.

It's true that e.g. Rust isn't presently as popular as C, but as
an alternative, it's pretty viable.

- Dan C.