Re using BREAK in 'C'

[Russell McMahon-4]

>> If you need rubber padding on the world to protect you, you might
>> be in the wrong line of work.

> So you really don't believe in the merits of tight type checking and
syntax
> with a better chance of human errors being illegal?

You have referred to high level GUI interactions when keyboard interface
would be superior as "clickety click".
[The trend to compulsion is ongoing - long time "power" users of Microsoft
products will notice that keyboard shortcuts tend to
vanish when 'applications' are 'upgraded'.]
I refer to people compelling me to conform to their controls and
"protections" on my activities (usually but not necessarily in a software
context) as "cottonwool".

The two concepts have some commonality. By all means offer tight type
checking, seat belts, air bags, crash helmets, anti-lock brakes, cruise
control, traction control, fly by wire decoupling of airframe pecidillos*,
control action inversion correction** and much more. BUT, in most cases,
please do not make such helpful interventions compulsory. People who write
software packages that utterly compel one/me to do something for my owen
good/ their sense of correctness/PC stupidity/other ... are not welcome. By
all means offer warnings, optional protections and more, but compulsion
based on somebody else's judgement indicates that they consider that their
juedgement and abilities are superior to mine. They may well be correct :-)
- but I want to be able to hold a variant position. I strongly suspect that
you do too.


    Russell

* Several airbus loses are attributed to such - rightly or wrongly.
** Makes the STS / Space Shuttle semi-manually flyable at high speeds. Few
if any complain about this feature.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Blick-4]

On Wed, 1 Jul 2009 11:23:49 -0400, "Olin Lathrop"
<olin_piclist@...> said:

> > If you need rubber padding on the world to protect you, you might
> > be in the wrong line of work.
>
> So you really don't believe in the merits of tight type checking and
> syntax
> with a better chance of human errors being illegal?

MISRA C ( http://en.wikipedia.org/wiki/MISRA_C ) and its guidelines are
an attempt to make C more robust. But it can't do everything, and C will
always be more "dangerous" than higher level languages.

C is a great compromise between assembly language and a true high level
language, and as such, is a pretty good choice for programming PICs and
other small micros, at least for me.

For anything with an operating system, C is not my first choice.

Cheerful regards,

Bob

--
http://www.fastmail.fm - mmm... Fastmail...

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Dave Tweed]

Olin Lathrop wrote:
> Gerhard Fiedler wrote:
> > Turbo Pascal was very popular. At some point, it probably was the
> > most popular development environment on CP/M and MS-DOS. I think
> > the main reason why it didn't "take over" like C was the lack of
> > standardization and the proliferation of dialects.
>
> Neither of those reasons make sense. Turbo Pascal was a single language
> that was well defined. There were no dialects.

That's the wrong argument to make. Turbo Pascal was only ever available
on two architectures: Z80 and x86 -- and, AFAIK, these weren't strictly
compatible with each other. If you wanted Pascal on any other platform,
you had to switch to a different vendor's dialect.

> I think the reasons C eventually dominated were because there were
> several free or low cost C compilers out there for a wide range of
> systems, it tagged along with the rise of Unix, and there were (even
> more than today) a large group of programmers lacking the maturity,
> discipline, and experience to see the advantages of a tightly typed
> language like Pascal.

There is also a body of "mature, disciplined and experienced" programmers
who see the limitations of a straightjacket language like Pascal. They get
an awful lot of useful programming done in other languages, including C.

> "Hacker" meant a different thing back then and was sortof a honorary
> title. Unfortunately it also included connotations of writing what we
> now call bad code, flagrant misuse of data typing, and using all manner
> of cutesy tricks that were a side effect of the language syntax. It was
> actually cool to write tiny maximally obfuscated programs. C is the
> perfect language for this, and I think this had some influece over the
> rise of C.

I seriously doubt that. Where's your objective evidence?

Sure, C programmers like to divert themselves with activities like the
"obfuscated C contest", but that hardly applies to the use of the language
in real applications.

> Eventually C got past the critical mass stage where you had to use it.
> I think we all agree that's where we are today. All my point is that
> while we may be forced to use C today, we should complain about it
> whenever possible. Changing the world won't be easy or quick, but it
> can't happen until we start to try.

The point that everyone has been making to you, Olin, is that no one is
forced to use C, not on any platform -- there's always an alternative
available.*

But the bigger point for you is that you need to do a better job of picking
your battles. Complaining to us here on the PIClist every time someone
*else* mentions C is not at all productive in the sense that you want, and
is completely counterproductive to everyone else who ends up participating
in the discussion -- and mildly counterproductive to all other readers who
have to skip over it. Annoying everyone here in this way does not help your
cause.

-- Dave Tweed

* Trivially true, of course, because you can always drop into assembly
  language.** Or get a different job.

** Except ... I have yet to find an easy way to write a nontrivial program
  in assembly for the PIC32. Microchip *really* wants you to program these
  chips in C!
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[John Ferrell-5]

I really love these arguments about what language is best. It always comes
down to a matter of what you want to do and what resources you wish to
optimize.

I really hate learning a new IDE though. It seems such a waste of time.

I would model everything after Turbo 3 if it were my choice with a compiler
directive built in so I could switch to K&R C wherever I wanted.  The
ability to use the same directive to switch in and out of assembler might
also be handy.

And NO FORWARD declarations please! A single pass compiler is fine.

THEN, I would only use the parts I like best!

John Ferrell  W8CCW

"Extremism in defense of liberty is no vice, and moderation in pursuit of
justice is no virtue."
-Barry Goldwater
"You don't get harmony when everybody sings the same note."
-Doug Floyd


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Dave Tweed wrote:
> There is also a body of "mature, disciplined and experienced"
> programmers who see the limitations of a straightjacket language like
> Pascal. They get an awful lot of useful programming done in other
> languages, including C.

So show me something reasonable and useful you can do in C that you can't in
Pascal (again, I'm using Pascal only as a example because I happen to know
it well).

> I seriously doubt that. Where's your objective evidence?
>
> Sure, C programmers like to divert themselves with activities like the
> "obfuscated C contest", but that hardly applies to the use of the
> language in real applications.

Unfortunately I think there is some spillover, especially in earlier days.
Of course I can't prove or disprove that, so it's my opinion only.  Back in
college (1974-1980) in certain cases it was a matter of pride how few lines
of code someone could use for a program to perform some task they had to
perform.  You might say they would never do that except for such class
assignments, but I'm not so sure.  These were not assignments where the
program was the result to hand in, but where you had to write a program to
get a result.

> The point that everyone has been making to you, Olin, is that no one is
> forced to use C, not on any platform -- there's always an alternative
> available.*

Perhaps technically, but not in practise.  Compare the number of C compilers
offered by Microchip for their chips versus non-C compilers they offer.
Look at the same statistics for third party vendors.  There are a few non-C
offerings out there, but are by far in the minority.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Olin Lathrop wrote:

> Gerhard Fiedler wrote:
>> Turbo Pascal was very popular. At some point, it probably was the most
>> popular development environment on CP/M and MS-DOS. I think the main
>> reason why it didn't "take over" like C was the lack of standardization
>> and the proliferation of dialects.
>
> Neither of those reasons make sense.  Turbo Pascal was a single language
> that was well defined.  There were no dialects.

Turbo Pascal was not a language, it was a dialect from a single vendor
-- one of many Pascal dialects. The C code I wrote in the 80ies still
compiles on modern compilers for CPUs that didn't even exist back then;
Turbo Pascal is dead for all practical purposes, and so is the code I
wrote for it. There you go... this is a good enough reason for many
companies not to bet on Pascal.

Lack of standardization is /the/ point. A commercially successful
language needs to have enough power that people believe it will still be
successful in a decade or more. Borland alone is not good enough; Embed
Inc alone isn't enough; Microsoft alone may be. All others need an
international standard (like there is for C).

Fact is that there is no universally accepted Pascal dialect. You didn't
use Turbo Pascal or Delphi (arguably the most successful Pascal
dialect); you used Apollo Pascal for your own implementation.


> I think the reasons C eventually dominated were because there were
> several free or low cost C compilers out there for a wide range of
> systems,

Why was this, you think? Why did the C community make compilers
available, and the Pascal community didn't? C originated in a commercial
venue, Pascal originated in a university. Should've been the other way
'round... :)


> ... and there were (even more than today) a large group of programmers
> lacking the maturity, discipline, and experience to see the
> advantages of a tightly typed language like Pascal.

This is pretty odd thinking, to say the least. C is not a safe language.
To produce anything of reasonable size in C, you need to have /more/
discipline and experience than in better typed languages, not less. Same
goes for assembly, FWIW. (Which is not a surprise, given that C is more
a portable assembly than anything else.)


> Eventually C got past the critical mass stage where you had to use it.  

Pascal had its shot. When I started to program on PCs, Turbo Pascal was
/the/ environment, it had the critical mass. Everybody programmed in
Turbo Pascal. C compilers were very rare to find. Borland seemed to have
decided not to standardize it, which probably would have meant opening
the market up to other vendors, and squandered the advantage.


> I think we all agree that's where we are today.  All my point is that
> while we may be forced to use C today, we should complain about it
> whenever possible.

Complaining without suggesting an alternative doesn't do much good, most
of the time. You keep saying "Pascal", but not exactly /which/ Pascal.
As long as there is not "the" Pascal, just pointing to "Pascal" doesn't
do any good. Somebody should put their money into their words and
standardize Pascal in some usable form. Then maybe it starts to pick up.
Until then, it's not much more than a pipe dream. A nice one at that,
but still... :)

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Vitaliy-14]

Olin Lathrop wrote:

>> The point that everyone has been making to you, Olin, is that no one is
>> forced to use C, not on any platform -- there's always an alternative
>> available.*
>
> Perhaps technically, but not in practise.  Compare the number of C
> compilers
> offered by Microchip for their chips versus non-C compilers they offer.
> Look at the same statistics for third party vendors.  There are a few
> non-C
> offerings out there, but are by far in the minority.

It would be interesting to get a compiler vendor's opinion on why there are
more C compilers. Is it simply because there's more demand for them, or
perhaps they're easier to write/port?

Don't we have a compiler vendor on this list?

Vitaliy

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Olin Lathrop wrote:

> Let's say I created a great compiler that minimized human error,
> caught a good fraction of the ones that you make anyway, allowed you
> to do what you needed when you need for efficiency, allows for
> generating tight code, slices veggies, walks the dog for you, and was
> free.  In short, it does everything you want by definition.  Would
> you use it?  

Yes, if ...

> Probably not since you have to link to existing libraries with
> interfaces only defined in C .h files,

... it interoperates where needed. The Win16 API used the Pascal calling
convention, and C compilers happily (or not... :) complied and made it
possible to use this API that used the Pascal calling convention. If
your language becomes successful, vendors will provide headers or
whatever is needed to use their libs with your language. Of course your
linker needs to be able to link in the most common library formats.
(Which is not really a language issue.) Since C header files are not
that complex, your compiler could be able to parse them, and you'd be
ready to go without support from library vendors and this would be a
non-issue.

And if it is standardized. I wouldn't bet a lot of money on Embed Inc.
If you want it to be successful, it doesn't only need to be good, it
needs to be stable. Only a really big company (Sun with Java, Microsoft
with VB) or an international standard (IEC with C and C++) can do that.

Sun did it with Java for PCs and servers. Somebody else could do it,
too, for the embedded market -- it's just that nobody is around
(apparently) to bet the necessary money on this.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Olin Lathrop wrote:

> Gerhard Fiedler wrote:
>> What would be your suggestion as to what's better? And don't say
>> "Pascal", because we all agree that "the" Pascal is not usable. So
>> you need to specify exactly which Pascal... and here the trouble
>> starts. There is not a usable Pascal... there was Turbo Pascal,
>> there is Delphi, there is Apollo Pascal, there is this and that
>> Pascal -- not a good starting point to argue for adoption of
>> "Pascal".
>
> I used Pascal only as a example because it does have a lot of the
> constructs designed better than their C equivalents and I happen to
> be familiar with it.  What I'd like to see is vendors innovating.  We
> haven't seen real innovation in reaonably available commercial
> languages for some time.  Most of your argument is that we're stuck
> with C because there is no viable alternative, which is true but not
> the point.

Most of my argument is not /that/ we are stuck, but /why/.

> The question is how to get out of this rut.  It will never happen
> without large numbers of programmers complaining loudly about being
> forced to use C whenever that occurs.

The /why/ we're stuck is IMO the point to start when trying to answer
the question about how to get out of it. And IMO standardization is the
single most important issue; it's required for having an alternative,
and complaining without alternative is usually not going very far.

Contrary to what you seem to think, it is my experience that the
shortcomings of assembly, C and C++ are widely known in the assembly, C
and C++ programmer community. They choose assembly, C or C++ not because
but despite their shortcomings, typically in a typical engineering-type
decision making and weighing of pros and cons.

FWIW, I held on to Turbo Pascal as long as I could. But it just died
away under my hands... :)

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Isaac Marino Bavaresco]

Gerhard Fiedler escreveu:
> What would be your suggestion as to what's better? And don't say
> "Pascal", because we all agree that "the" Pascal is not usable. So you
> need to specify exactly which Pascal... and here the trouble starts.
> There is not a usable Pascal... there was Turbo Pascal, there is Delphi,
> there is Apollo Pascal, there is this and that Pascal -- not a good
> starting point to argue for adoption of "Pascal".
>  

I like Pascal and I like C. For work I use C.

Don't forget FreePascal (<http://www.freepascal.org/>), it is free and
run on lots of platforms (excerpt from the web-site):


    *  arm
          o Linux
          o Windows CE
    * intel/i386
          o Dos (GO32v2 extender)
          o FreeBSD (FreeBSD 6.x and 7.x)
          o Linux
          o Mac OS X
          o OS/2
          o Win32, Win64 and WinCE (Windows 95, 98, ME, NT, 2000, XP,
Vista)
    * powerpc
          o Linux
          o Mac OS X
    * powerpc64
          o Linux
    * sparc
          o Linux
    * amd64/x86_64
          o Linux
          o Windows 64-bit

Regards,

Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/ 

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Isaac Marino Bavaresco]

John Ferrell escreveu:
> And NO FORWARD declarations please! A single pass compiler is fine.
>  


If you want to do indirect recursion with no forward declarations you
will need multiple passes. There are other cases where forward
declarations are useful.

You may do just one pass if you declare the not yet seen symbols as a
forward declaration (forward in Pascal, function prototype/extern in C).

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/ 

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Wouter van Ooijen]

> And NO FORWARD declarations please! A single pass compiler is fine.

Do you realize that you have ruled out mutual recursion?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Isaac Marino Bavaresco]

Isaac Marino Bavaresco escreveu:

Good news at <http://www.freepascal.org/news.var>:

Latest changes:
# June 25, 2009

    * During the last months a lot of work on the embedded support of
Free Pascal has been done. FPC can be used now to program
microcontrollers without any operating system. The current status, an
explanation how to use it and the supported controllers (only a few so
far) can be found at the FPC Wiki.


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/ 

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Dave Tweed]

Olin Lathrop wrote:
> Dave Tweed wrote:
> > There is also a body of "mature, disciplined and experienced"
> > programmers who see the limitations of a straightjacket language
> > like Pascal. They get an awful lot of useful programming done in
> > other languages, including C.
>
> So show me something reasonable and useful you can do in C that you
> can't in Pascal (again, I'm using Pascal only as a example because
> I happen to know it well).

That isn't what we're debating here. I'm sure that all useful Pascal
dialects are at some level Turing-complete.

I've used Pascal in the past (including Apollo Pascal), but I'm hardly
an expert. As I recall, the biggest difficulties were with I/O, where
you want to treat an arbitrary chunk of data as just a stream of bytes
or bits, possibly embedded in another data structure.

Marshalling data (and executable code) across an I/O interface is
nontrivial in any language, but strongly-typed languages make it
particularly tedious -- and arguably no less error-prone.

> > The point that everyone has been making to you, Olin, is that no
> > one is forced to use C, not on any platform -- there's always an
> > alternative available.*
>
> Perhaps technically, but not in practise. Compare the number of C
> compilers offered by Microchip for their chips versus non-C compilers
> they offer. Look at the same statistics for third party vendors. There
> are a few non-C offerings out there, but are by far in the minority.

So, you're saying that you're not unhappy because alternatives are not
available (they are), but unhappy because they're not as popular as C?
Geez, this discussion is more pointless than I thought!

-- Dave Tweed
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

John Ferrell wrote:
> And NO FORWARD declarations please! A single pass compiler is fine.

If you don't ever want to have multiple recursive subroutines.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Dave Tweed wrote:
> Marshalling data (and executable code) across an I/O interface is
> nontrivial in any language, but strongly-typed languages make it
> particularly tedious -- and arguably no less error-prone.

That's why I/O is usually not type checked.  Unless it's a higher level I/O,
like lines of text, it's usually just a sequence of bytes in most languages
and OS calls.

> So, you're saying that you're not unhappy because alternatives are not
> available (they are), but unhappy because they're not as popular as C?
> Geez, this discussion is more pointless than I thought!

You said there's always a alternative, but there really isn't.  There are a
very few non-C compilers for PICs, for example, but that doesn't help when
you have to link in with libraries defined with a existing C compiler's
calling conventions and read it's definitions from .h files.  And none of
them are directly supported by Microchip.

So yes there is a alternative or two, but only for small values of
"alternative".  Actually the only one I can think of off the top of my head
that supposedly is more than a toy is XCSB.  I know more work is being done
on JAL.  I don't know if it's far enough along to be production ready
though.  I have never used either, so I don't know for sure.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Dario Greggio (in giro)]

William Couture ha scritto:
> Seriously.  I use C every day.  I never run into stupid problems from
> trying to write something like Duff's device because I would never
> try to bend/break the language like that (and the compiler I use most
> gives me compile errors on that code).


definitely agreed. I like C.
And I use a lot of toother languages as well - some more suited for some
jobs and some not.



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[M.L.-2]

On Wed, Jul 1, 2009 at 3:21 PM, Olin Lathrop<olin_piclist@...> wrote:

> So yes there is a alternative or two, but only for small values of
> "alternative".  Actually the only one I can think of off the top of my head
> that supposedly is more than a toy is XCSB.  I know more work is being done
> on JAL.  I don't know if it's far enough along to be production ready
> though.  I have never used either, so I don't know for sure.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> [phone].  Gold level PIC consultants since 2000.

There's at least one Pascal for PICs:
<http://www.mikroe.com/en/compilers/>

As I see it there are at least three issues with not using assembly
language in a real-time application: timing, non-optimal compilation,
and the compiler vendor.

-
Martin

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[William "Chops" Westfield]

On Jul 1, 2009, at 8:04 AM, Olin Lathrop wrote:

> I think the reasons C eventually dominated were because there were  
> several
> free or low cost C compilers out there for a wide range of systems

I think a lot of work on pascal compilers was done on mainframes, and  
pretty much died with them (even I worked on the tops20 pascal  
compiler at one time!)  And a lot was aimed at the "teaching language"  
aspect rather than making pascal a more useful "general purpose  
programming language."  Consider UCSD pascal, which was one of the  
larger efforts, designed to be portable/etc.  But it had a pretty  
significant performance penalty over true compilers; it's only in the  
last decade or so that systems have really gotten fast enough that  
bytecode interpreted languages have begin to succeed.

For that matter, isn't a Pascal compiler part of gcc ("Gnu Compiler  
Collection", not "Gnu C Compiler", remember.)  That should mean that  
many of CPUs with a free C compiler also have a free pascal compiler.  
But I don't see much published using Gnu Pascal; is it really that  
useless?  (and if so, Why?)

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[William "Chops" Westfield]

On Jul 1, 2009, at 8:35 AM, Olin Lathrop wrote:

> we're stuck with C because there is no viable
> alternative, which is true but not the point.

So how do you feel about Java ?

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist