Re using BREAK in 'C'

[Olin Lathrop]

Tony Smith wrote:
> I originally wrote 'almost no-one', but changed it to see who'd bite.

I can only respond to what you wrote, not what you considered writing.

> 'Blatantly' is a bit much,

No, you made a absolute statement which a single counter example can
disprove.  There are many counter examples of which I listed a couple.  If
you'd said something like "most programs don't need a compiled language
because speed is not the issue" I wouldn't have argued and even agreed, but
that's very different from what you actually said.

> sure Eagle needs to run fast, but you're
> not the one writing the auto-router.  Out of the thousand of Eagle
> users only one needs C, and that's the author.

And only one example disproves your blanket statement.

> It's also been true for a while that it's cheaper to buy more CPU
> power then spend days fiddling with something to make it faster.
> That offends people too, but a new PC divided by your hourly rate is
> a small number.  Which is better?

Again you're making a absolute claim, which of course is false.  Have you
really never run into programs that took longer to run than you wished, even
if you had the latest computer?  Even if you haven't, are you really saying
you've never heard of any or can't imagine any?  If so, then there's a big
world of computing you've managed to miss somehow.

The Eagle autorouter is a good example.  Some runs I've done have taken a
couple of hours, some overnight.  Let's say for sake of argument I have a
real problem that takes my current PC 1 hour to run.  Of course I'd like it
to be instant, but let's say 10 seconds would put it into the good enough
range so that I wouldn't have to alter my workflow around the program.
That's a factor of 360.  My PC is a few years old.  Maybe I could get 4x out
of a current mainstream model.  Let's be generous and say 8x.  That brings
the one hour down to 7.5 minutes.  That's still a "long" time in my context
and I'd definitely want it to be faster.

Thru the history of computing there have always been problems that taxed the
computers of the time where people had to wait inconveniently long for the
computer to finish or compromises were made to limit the problem.  As
computers got faster some problems could be solved fast enough so that
nobody cared anymore, but others could now be solved with a few less
compromises but are still a long way from good enough.  Generally the ones
that remain pushing computing limits today have to do with many passes over
large arrays.  Surely you've at least heard of some?

> C is rarely needed these days.

That's better, although I think you meant to say the extra performance of a
compiled language is rarely needed these days.  I agree with that, but note
that this doesn't make a compile language a bad idea, only that it makes
other alternatives viable.  There are still plenty of reasons for using a
particular language when performance isn't the issue and a wider choice is
therefore available.  Familiarity and investment in a particular toolchain
is probably top of the list.  For example, for PC programming I use my
Pascal to C translator with C compiler environment.  For some things I do, I
definitely need the power of a compiled language.  For most things I don't.
However, having everything written to the same toolchain is a huge
advantage.  It wouldn't make sense to write the programs that aren't CPU
critical in Java, for example, just because I could, keeping in mind that
occasionally I'd still have to go back to writing truly compiled code to get
the performance.

> PICs are the same, you have "slow cheap Pic + Assembler" vs "faster $
> PIC + compiler".  Not everyone needs assembler for PICs.

Right, but some do.  Even if you haven't encountered them, there are high
volume projects out there where $.05 microcontroller cost is significant.

> (and in reference to the subject line, BREAK is probably the dumbest
> idea ever, every other language got switches right)

I agree with that.  The C switch statement could have been designed better
with no more burden on the compiler or loss of machine code performance, but
with less likelyhood of a programmer screwup.  Worse, this same thing can be
said about too many other aspects of C.


********************************************************************
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]

> PPA wrote:
> Gerhard Fiedler wrote:
>> For me, being able to compile the program in different versions of a
>> compiler of the same vendor is the lowest level; I wouldn't even
>> call this "portability", it's more like version compatibility. The
>> next level is being able to compile on compilers from different
>> vendors (on the same operating system); this maybe I'd start to call
>> portability. Then come different operating systems and different
>> target processors; here we get into what I call portability.
>
> My assertions were a bit simplified; I'm sometimes a bit lazy on my
> keyboard... Sure that you are right on these points.
>
>> So how does this aspect look for Pascal? (This is not a rhetorical
>> question; I really want to know from someone who uses Pascal
>> portably.)
>>
> Is this irony? Well as I already said, you may use $ifdef constructs
> in "the units that gather all portability sensitive parts" to manage
> portability, say, from TP3 to Delphi (same vendor) or FPC (near
> compatible one) or Acme Pascal or whatever one.
>
> As I said no less no more than with C. OK, there may be more $ifdef
> than #ifdef due to language compatibility, but these language
> differences are very tight (more than in C witch may be qualified as
> nearly fully "standard"); that's not "impossible", please stop saying
> that: that's just a little bit harder than with C, no more. If you
> are used to do that that's not really boring.

I was asking specifically about what I classified as "portability"
above, and not ironically at all. But you didn't answer the question.

Again: How does the portability aspect look with Pascal? Can you take
your sources and compile on Linux, Windows, Solaris, Unix? Can you
create executables for x86, x64, Itanium, ARM? Can you use a compiler
(on a platform that's already supported by your sources) from a
different vendor (that you didn't consider when writing your sources)
and with little or no changes compile your sources with it?

Is this possible? Is this actually being done with Pascal? If so, since
when?

(Again, this is not ironical. This is just not answered yet. I thought
this isn't really possible, in the sense that it's commonly being done.
You seem to say the contrary, but not with the clarity I'd like to
have.)

>> Besides some odd vendors of small micro compilers, there aren't
>> really any C dialects. The few there are are really niche thingies,
>> mostly restricted to the PIC world (and maybe the one or other small
>> micro, but I think the PIC compilers are worse than most others in
>> this respect). In the great scheme of C, they almost play no role at
>> all. Every compiler that wants to be worth its money has to be
>> standard compatible, and therefore allows programming in standard C
>> (or C++). Which is more common as you seem to think.
>>
> You said "odd vendors", "niche thingies", "almost no role at all".
> There is always special needs and niches; people that are there would
> be upset to read your comments; some niches may be less than a few
> percent of percent of all the "great scheme of C world", but this may
> represent thousands of people that are NOT playing "no role";

Whoever wants to be upset about what I wrote here, be my guest :)

See, I'm one of those "niche C" users when I program in C on a PIC with
a not quite standard compliant C compiler. There's nothing wrong with
acknowledging that this is a tiny fraction of the usage of C, so when
talking about C in general, this simply doesn't count a lot.

But even then (in the PIC world, for example)... there are compilers
that are standard C, and there are compilers that aren't. And there are
compilers that are almost standard C with a few documented differences.
And there are compilers that call themselves C but are so far away from
the standard that they don't even list the differences.

So I have a choice... If I use one of the non-standard ones, I know that
I'm not programming in standard C, but in a proprietary language with
some similarity to standard C. This is different from not having a
standard at all -- /very/ different, IMO.

> On "has to be standard compatible" that's the point. Even if the
> standard is not good enough?

If the standard isn't good enough, it should be improved. This is what
for example is being done with the C and C++ standards. Not to
everybody's liking, of course... Some think more changes should be made,
some think that other changes should be made -- it's difficult to please
everybody :) And once there is a certain amount of source code out there
that relies on a standard, every improvement of that standard has to
take the issue of backwards compatibility into account.

But it's writing standard C++, for example, that allows me to pick any
old standard compliant compiler and compile my sources, and in general,
it'll just work.

(Repeating... I'm not saying C or C++ are good, or better than something
else. But people are saying that Pascal is better than C, yet C is more
popular, vastly more popular, than Pascal. There must be a reason... and
it's probably /not/ business. Microsoft didn't invent C, they're not
married to C, and Microsoft isn't a reason for C's popularity. The
calling convention for the Win16 API is the Pascal calling convention.
When they switched to the C calling convention for the Win32 API, they
probably followed instead of lead. There also seems to be a consensus
that Unix wasn't really commercial either.)

> Do you think that in 2050 we will use the same old low level less
> common denominator things?

I'm not sure, but I probably won't care. And I sure don't see what this
has to do with what I'm doing now. FWIW, I don't think that it'll be
that different. We'll just hobble along :)

> A language should evolve or die, C as any one; I think it will die
> because of these too low level standards that nobody can jump off.

Of course it will die, like every other language, sooner or later. But a
standard is not something that is necessarily contrary to evolution. And
the lack of a standard is not necessarily favorable for a language to
prosper.

> Other languages are born, some died; see Cobol or Fortran users that
> don't want to see the cliff edge: the final fall will be hard - same
> for me with my Pascal and its childs? Can be, but in a long time I
> hope; there's many choices nowadays;

I'm not sure, but I think Cobol is still alive and kicking. I may
remember this wrongly, but not so long ago I think I read that the
investment in Cobol programming is still among the top few. And I don't
think that all the program packages on university computers that are in
Fortran will be ported to something else any time soon.

Pascal won't die any time soon, either. That's not what I have been
writing about. The question is... how many shops do you know that hire
Pascal programmers (and pay them well)?

FWIW, I just ran a search on careerbuilder.com. Fortran: 13. Pascal: 15.
Delphi: 61. Cobol: 99. Python: 276. PHP: 1083. VB: 1173. C++: 1521. C#:
1892. Java: 3901. If this isn't "dead professionally", I don't know what
is. (I didn't search for C because unluckily "c" doesn't lend itself too
well for a keyword in a text-based search.)

> Java (a C child?) engines on chip among other not so new things...

I thought those Java chips are pretty much dead. Does anybody know
anything about them? Has anybody actually seen one in action? :)

> You're saying nice things and you say you don't like what has happened
> to it but also you say wrong things. If you gave up on Pascal, maybe
> it is because your job cannot be done with it at these times; that's
> not the case for everybody so far.

Not for everybody, but check out the job market for programmers and tell
me that there is a substantial market for Pascal programmers without
blushing :)

> I just don't like when people are saying that a language cannot do
> something without arguments or even that it is dead without
> seeing/knowing all the actual reality. This is surprising from
> somebody who comes from Pascal...

I have asked you, and you haven't responded. I asked about one Pascal
source compiling for different target operating systems, different
target processors -- and all you came up with was porting something from
MS-DOS through Win3.11 to Win32, with the MS-DOS (and Win3.11?) code not
having the same functionality as the Win32 code. This is not what I
meant; I meant a broader scope.

The other question is, and that's the real issue here, why is Pascal
dead in professional programming? By "dead" I don't mean that nobody
uses it, but for somebody's sake, 6 out of 8846 posted IT jobs on
careerbuilder.com mention Pascal, 19 mention Delphi, whereas 672 mention
C++ and 1666 mention Java... for me, that's "dead" as a general purpose
language.


> I may agree on discussions about why Pascal (or whatever language)
> does not have found its place,

I'd like to hear what you think why Pascal is so unpopular.

> Note that the beginning of the thread (not the OP) was on C good and
> bad behaviors, on it's poor type checking among other things, not on
> if Pascal didn't make it or was dead or not...

The thread has evolved, as with you answering me.

> You wrote yourself some assertions that can be read as the beginnings
> of another stupid language war by saying wrong things,

What's wrong in what I said?

> On Microsoft vs. Borland, don't forget that Borland C/C++ compilers
> was far better than Microsoft ones; all new improvements came from
> Borland; Microsoft has copied everything, with the power of
> Microsoft, as they do with other tools and good ideas, when finally
> they delivered their "revolutionary" Visual tools... This is not
> technical, this is business and in this domain they will stay #1 for
> a long time I guess.

This is exactly what I'm saying. Borland didn't have the economic power
to do it the same way as Microsoft, so they should've done it
differently. Trying to be the only player (by not standardizing the
language) only works well if you can do it like Microsoft and really be
the only player. (And even Microsoft standardized .NET and C#, for
whatever this is worth... :)

> Pascal side, Borland made a nearly de facto standard (the most used I
> think); I don't understand why an official standardization was not
> done when Borland was on top of the wave; then Pascal activity has
> decreased because they had enough concerns to make survive their
> non-Pascal tools against the power of Microsoft witch makes business
> on everything other than compilers. An excellent technical level is
> not enough.

Exactly what I'm talking about.

> See what Microsoft is giving us at each new good business idea: we
> need to come back to school to un-teach all what they teach us last
> time, new layers that gives slower software even with a CPU power
> that doubles regularly... Definitively not a good model for technical
> comparison of why something is popular or not...

There is no "technical comparison why something is popular". There are
technical comparisons, and there is the attempt of finding out why some
things are popular and others not, and how this relates to the technical
comparisons.

But IMO the popularity of C has not much to do with Microsoft, other
than that they provide a decent compiler for Windows that's among the
most popular compilers on Windows. Microsoft's compiler is probably very
rarely used to compile C sources.

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

[Olin Lathrop]

Gerhard Fiedler wrote:
> (Repeating... I'm not saying C or C++ are good, or better than
> something else. But people are saying that Pascal is better than C,

In a technical sense.  And Pascal is only one example.  I'm not pushing
Pascal, only trying to get everyone to realize how awful C is.

> yet C is more popular, vastly more popular, than Pascal. There must
> be a reason...

Of course, but since that reason is not technical superiority it is
irrelevant.  People use C because they have to, myself included.  There are
legitimate reasons to use C today, like it's what available employees know,
because new code has to be added to existing C code, because of wider
poratbility, because its the language of the available compilers for a
particular platform, because the customer insists on it regardless of why,
etc.  I think we all agree C has reached critical mass by a long shot.

The main point is that C is not technically superior.  In fact it's rather
inferior to better compiled languages like several of the Pascal variants
from the 1980s.  There is a serious cost in developing in C.  While none of
this is going to change that people continue to develop in C for all the
other reasons cited above, I'll be happy for now if only they grumble "I
have to use this $%&*@# C again, I wish I could use something better"
everytime they are forced to do so.  Things aren't going to change until the
general consensus is "C sucks".  Some are already there, but too many
sheeple aren't yet.


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

[Isaac Marino Bavaresco]

Gerhard Fiedler escreveu:
> I have asked you, and you haven't responded. I asked about one Pascal
> source compiling for different target operating systems, different
> target processors -- and all you came up with was porting something from
> MS-DOS through Win3.11 to Win32, with the MS-DOS (and Win3.11?) code not
> having the same functionality as the Win32 code. This is not what I
> meant; I meant a broader scope.

For simple console application, one should be able to just recompile his
code across DOS, Windows, Linux, etc. using C or Pascal (FreePascal).

Once you start speaking of GUI applications, things get more
complicated, even for C/C++.

There is wxWidgets (<http://www.wxwidgets.org/>), a free software
application framework available for lots of platforms.

Quote from the home page:
"wxWidgets lets developers create applications for Win32, Mac OS X,
GTK+, X11, Motif, WinCE, and more  using one codebase. It can be used
from languages such as C++, Python, Perl, and C#/.NET. Unlike other
cross-platform toolkits, wxWidgets applications look and feel native.
This is because wxWidgets uses the platform's own native controls rather
than emulating them. It's also extensive, free, open-source, and mature.
Why not give it a try, like many others have?"

It works also with Win64, Linux, NetBSD, FreeBSD, OpenBSD, Solaris,
HP-UX, AIX and more.

It has bindings for lots of languages: wxAda, wxBasic, C++ (native),
wxD, wxDelphi/wxPascal, wxErlang, wxEuphoria, wxHaskell, wxJava, jwx!
(also Java), GLUEscript(JavaScript), wxLua, wxMax, wxNet, wxPerl,
wxPike, wxPython, wxRuby, wxSqueak



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

[Tamas Rudnai]

Guys I totally lost the line now. We were already talking about library and
compiler differences, and that it is no matter if that is C or Pascal when
we want to compile a code into different platforms. I am not sure why are we
discussing about this even further? That is not a question that we could
develop in Pascal multiplatform, the original question was why C is used
nowadays instead?

Tamas



On Sat, Jul 11, 2009 at 11:01 PM, Isaac Marino Bavaresco <
isaacbavaresco@...> wrote:

> Gerhard Fiedler escreveu:
> > I have asked you, and you haven't responded. I asked about one Pascal
> > source compiling for different target operating systems, different
> > target processors -- and all you came up with was porting something from
> > MS-DOS through Win3.11 to Win32, with the MS-DOS (and Win3.11?) code not
> > having the same functionality as the Win32 code. This is not what I
> > meant; I meant a broader scope.
>
> For simple console application, one should be able to just recompile his
> code across DOS, Windows, Linux, etc. using C or Pascal (FreePascal).
>
> Once you start speaking of GUI applications, things get more
> complicated, even for C/C++.
>
> There is wxWidgets (<http://www.wxwidgets.org/>), a free software
> application framework available for lots of platforms.
>
> Quote from the home page:
> "wxWidgets lets developers create applications for Win32, Mac OS X,
> GTK+, X11, Motif, WinCE, and more  using one codebase. It can be used
> from languages such as C++, Python, Perl, and C#/.NET. Unlike other
> cross-platform toolkits, wxWidgets applications look and feel native.
> This is because wxWidgets uses the platform's own native controls rather
> than emulating them. It's also extensive, free, open-source, and mature.
> Why not give it a try, like many others have?"
>
> It works also with Win64, Linux, NetBSD, FreeBSD, OpenBSD, Solaris,
> HP-UX, AIX and more.
>
> It has bindings for lots of languages: wxAda, wxBasic, C++ (native),
> wxD, wxDelphi/wxPascal, wxErlang, wxEuphoria, wxHaskell, wxJava, jwx!
> (also Java), GLUEscript(JavaScript), wxLua, wxMax, wxNet, wxPerl,
> wxPike, wxPython, wxRuby, wxSqueak
>
>
>
> 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
>

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

[Tony Smith-11]

> Tony Smith wrote:
> > I originally wrote 'almost no-one', but changed it to see who'd bite.
>
> I can only respond to what you wrote, not what you considered writing.
>
> > 'Blatantly' is a bit much,
>
> No, you made a absolute statement which a single counter example can
> disprove.  There are many counter examples of which I listed a couple.  If
> you'd said something like "most programs don't need a compiled language
> because speed is not the issue" I wouldn't have argued and even agreed,

but
> that's very different from what you actually said.


Surely you've managed you spot the trolls these days.


> > It's also been true for a while that it's cheaper to buy more CPU
> > power then spend days fiddling with something to make it faster.
> > That offends people too, but a new PC divided by your hourly rate is
> > a small number.  Which is better?
>
> Again you're making a absolute claim, which of course is false.  Have you
> really never run into programs that took longer to run than you wished,
even
> if you had the latest computer?  Even if you haven't, are you really
saying
> you've never heard of any or can't imagine any?  If so, then there's a big
> world of computing you've managed to miss somehow.


Hardware is cheap, software isn't.  A PC is a few of hours of your hourly
rate.  How much auto-router code does that buy?


> The Eagle autorouter is a good example.  Some runs I've done have taken a
> couple of hours, some overnight.  Let's say for sake of argument I have a
> real problem that takes my current PC 1 hour to run.  Of course I'd like
it
> to be instant, but let's say 10 seconds would put it into the good enough
> range so that I wouldn't have to alter my workflow around the program.
> That's a factor of 360.  My PC is a few years old.  Maybe I could get 4x
out
> of a current mainstream model.  Let's be generous and say 8x.  That brings
> the one hour down to 7.5 minutes.  That's still a "long" time in my
context
> and I'd definitely want it to be faster.
>
> Thru the history of computing there have always been problems that taxed
> the computers of the time where people had to wait inconveniently long for

> the computer to finish or compromises were made to limit the problem.  As


Y'know, If I'd written that last bit, you'd have probably replied "Duh, go
buy a faster PC.  Why wait until some C guy finally knocks out a few more
bugs and make the autorouter run 5% faster.  A new PC will halve your run
time right now.".  There's a limit to the gains you can get with code, but
you can buy cheap CPU cycles right now.  And even more next year.

So you're happy to wait until the next Eagle release, fork over your licence
upgrade fee, and get something the may run a little bit faster?  I'll take
the PC.  No wait, your saying buy a new PC.  Hmm, you appear to be arguing
in full agreement with me.  I think.  Or are you waiting for the C
programmer to save the day with v4.56b?


> > C is rarely needed these days.
>
> That's better, although I think you meant to say the extra performance of
a
> compiled language is rarely needed these days.  I agree with that, but
note
> that this doesn't make a compile language a bad idea, only that it makes


No, I meant C.  C & a HHL language can both compile to something that's
pretty much indistinguishable.  Microsoft showed that with QuickC &
QuickBasic years ago.  Why write in a language that creates more coding
errors?  Which is, of course, what you're complaining about.  Ya gotta love
these threads.

Tony


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

[Olin Lathrop]

Tony Smith wrote:
> Surely you've managed you spot the trolls these days.

Is this the pot calling the pot black?

> Hardware is cheap, software isn't.  A PC is a few of hours of your
> hourly rate.  How much auto-router code does that buy?

I'm not sure if you're just trolling or somehow really didn't get the point,
so I'll give you the benefit of the doubt.  I was using the Eagle autorouter
merely as a example of something that consumes a lot of CPU time on current
machines because you claimed no such programs existed.

As for your side point, show me a machine for $2000 that can complete any of
the Eagle auto routes I've done in under a minute and I'll buy it.  In the
mean time I'll keep upgrading my PC occasionally.  I'm not going to run out
and get a new PC every 6 months though just because it would 25% faster.
Even ignoring the purchase price, there is a cost in down time of installing
all the software getting everything set up just the way I like, etc.  It
usually takes a day or even more just to switch to a new computer.  Anyway,
this is irrelevant to the point at hand.


********************************************************************
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]

Tony Smith wrote:

>> Again you're making a absolute claim, which of course is false.  Have
>> you really never run into programs that took longer to run than you
>> wished, even if you had the latest computer?  Even if you haven't,
>> are you really saying you've never heard of any or can't imagine
>> any?  If so, then there's a big world of computing you've managed to
>> miss somehow.
>
> Hardware is cheap, software isn't.  A PC is a few of hours of your
> hourly rate.  How much auto-router code does that buy?

Let's see... Imagine an auto-router that's used by 10'000 users. Let's
say "a few hours" is 10 hours. That's 10 hours per user, so it's 100'000
hours. How much auto-router code does that buy again? :)


> There's a limit to the gains you can get with code, but you can buy
> cheap CPU cycles right now.  

Isn't there also a limit how many cheap CPU cycles you can buy right
now? Where do you go when you have bought all the cheap CPU cycles you
can buy and still are not there where you want to be?

Of course, from the viewpoint of a single user this may be the solution
-- if no other solution is available. But between two autorouters with
similar functionality, one may be twice as fast, and only a bit more
expensive. So if such an option is available, which one would you pick?
The slower product?


> Or are you waiting for the C programmer to save the day with v4.56b?

You're good in setting up strawmen, or at least are trying to be. But it
may be that you don't have to wait... there's competition out there,
even for autorouters.


>>> C is rarely needed these days.
>>
>> That's better, although I think you meant to say the extra
>> performance of a compiled language is rarely needed these days.  I
>> agree with that, but note that this doesn't make a compile language
>> a bad idea, only that it makes
>
> No, I meant C.  C & a HHL language can both compile to something
> that's pretty much indistinguishable.  

Indistinguishable in what sense?


> Microsoft showed that with QuickC & QuickBasic years ago.  

What did they show? I tried to find something about this, but didn't
find any relevant findings :)


> Why write in a language that creates more coding errors?  

Like for example assembly? Because in some cases and instances the last
bit of control or optimization that a compiler can't give or do may be
important.

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

[Tony Smith-11]

> >> any?  If so, then there's a big world of computing you've managed to
> >> miss somehow.
> >
> > Hardware is cheap, software isn't.  A PC is a few of hours of your
> > hourly rate.  How much auto-router code does that buy?
>
> Let's see... Imagine an auto-router that's used by 10'000 users. Let's
> say "a few hours" is 10 hours. That's 10 hours per user, so it's 100'000
> hours. How much auto-router code does that buy again? :)


Not much.  So you get 100 man strong team together and they code away for 6
months.  In machine code because that's the 'in' thing.  More speed!
Ludicrous speed even!  They develop a whole new algorithm that's 10% faster!
Meanwhile I'd upgraded my 4 year old PC (like Olin has) and have had a
better speed increase than 10% for that time.  So, new PC with instant
results now, or wait 6 months for something that's 100% machine code, 10%
faster and buggy.  Let me think it over...

> > There's a limit to the gains you can get with code, but you can buy
> > cheap CPU cycles right now.
>
> Isn't there also a limit how many cheap CPU cycles you can buy right
> now? Where do you go when you have bought all the cheap CPU cycles you
> can buy and still are not there where you want to be?
>
> Of course, from the viewpoint of a single user this may be the solution
> -- if no other solution is available. But between two autorouters with
> similar functionality, one may be twice as fast, and only a bit more
> expensive. So if such an option is available, which one would you pick?
> The slower product?

If the slower product has less bugs and better support, then yeah.  But
that's irrelevant, of course you pick the faster one if everything thing
else is equal.  And buy a new PC to run it on.


> > Or are you waiting for the C programmer to save the day with v4.56b?
>
> You're good in setting up strawmen, or at least are trying to be. But it
> may be that you don't have to wait... there's competition out there,
> even for autorouters.


But the customers are locked in to their existing product.  No-one will
switch as you need to do all your libraries again.  But that's irrelevant
too.

> >>> C is rarely needed these days.
> >>
> >> That's better, although I think you meant to say the extra
> >> performance of a compiled language is rarely needed these days.  I
> >> agree with that, but note that this doesn't make a compile language
> >> a bad idea, only that it makes
> >
> > No, I meant C.  C & a HHL language can both compile to something
> > that's pretty much indistinguishable.
>
> Indistinguishable in what sense?

To the user.

 
> > Microsoft showed that with QuickC & QuickBasic years ago.
>
> What did they show? I tried to find something about this, but didn't
> find any relevant findings :)


I used to write in both.  The compiled QB programs ran just as fast as
compiled C ones, and TurboC & TurboPascal probably did too.  (Hence MS
dropping the compiler in VB to make C++ the 'better' choice.)  Sure it was
hard to write image manipulation stuff in QB as it lacks the bit-twiddling
stuff C has, but hardly anyone did that, despite many claiming to.  Write
that little bit in C and the rest in something easier to use.  

Or just buy a library where some other poor sod has done the hard work for
you.  Like Olin said, you don't write it yourself, but you still need to
know how to make the right choice.  Sorting routines are a good example.

Reminds that Olin mentions he had to write a program that took a long time
to do a lot of complicated stuff, but never actually mentioned what he wrote
it in.  Pascal?  ADA?  GWBasic?


> > Why write in a language that creates more coding errors?
>
> Like for example assembly? Because in some cases and instances the last
> bit of control or optimization that a compiler can't give or do may be
> important.


More than one company went broke waiting for the assembler programmers to
finish while the HLL (even C counts there) guys beat them to the market.
Fast doesn't matter much anymore unless it's fast to market.  Some people
want their stuff to actually work too, which is rather novel.

The car analog for this thread is arguing whether your car needs a rear wing
on it.

Tony

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

[Tony Smith-11]

> > Hardware is cheap, software isn't.  A PC is a few of hours of your
> > hourly rate.  How much auto-router code does that buy?
>
> I'm not sure if you're just trolling or somehow really didn't get the
point,
> so I'll give you the benefit of the doubt.  I was using the Eagle
autorouter
> merely as a example of something that consumes a lot of CPU time on
current
> machines because you claimed no such programs existed.
>
> As for your side point, show me a machine for $2000 that can complete any
of
> the Eagle auto routes I've done in under a minute and I'll buy it.  In the
> mean time I'll keep upgrading my PC occasionally.  I'm not going to run
out
> and get a new PC every 6 months though just because it would 25% faster.
> Even ignoring the purchase price, there is a cost in down time of
installing
> all the software getting everything set up just the way I like, etc.  It
> usually takes a day or even more just to switch to a new computer.
Anyway,
> this is irrelevant to the point at hand.


Getting a 25% speed increase by doing something trivial as buying a new PC
sounds good to me, beats waiting for the next software release (which is
very unlikely to be that good).

You complain something is slow when there's an easy solution at hand?

Disk cloning programs are pretty good these days.  Why build from scratch?

Tony

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

[Tony Smith-11]

> > Surely you've managed you spot the trolls these days.
>
> Is this the pot calling the pot black?


I wasn't implying you were a troll, Olin, just merely replying to one.  Oh,
I see, there's an odd typo.  That 2nd 'you' should be 'to'.  Bedtime, me
thinks.

Cheers,

Tony

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

[Olin Lathrop]

Tony Smith wrote:
> If the slower product has less bugs and better support, then yeah.
> But that's irrelevant, of course you pick the faster one if
> everything thing else is equal.  And buy a new PC to run it on.

It's funny how when someone refutes one statement you make you simply switch
to a orthagonal argument.

Let's keep in focus that your original statment was:

  "No-one needs the 'power' that C gives you these days, it's
  all libraries, web apps and front-ends for SQL databases.
  You don't need C for that."

Looking at that in hindsight it was apparently just trolling.

> Reminds that Olin mentions he had to write a program that took a long
> time to do a lot of complicated stuff, but never actually mentioned
> what he wrote it in.  Pascal?  ADA?  GWBasic?

I wrote it in Pascal, which gets translated to C as part of the build
process, then compiled with the MSVC compiler for PCs.

> More than one company went broke waiting for the assembler
> programmers to finish while the HLL (even C counts there) guys beat
> them to the market. Fast doesn't matter much anymore unless it's fast
> to market.  Some people want their stuff to actually work too, which
> is rather novel.

But low unit cost certainly does matter.  I've got a high volume project
that needs to be cheap, cheap, cheap.  This thing has to periodically send a
RF message that includes its 32 bit ID, a few status bits, and a CRC
checksum.  It also has to send a signature via IR, handle a user button and
a LED, compute life left and display it on the LED when asked, and a
proprietary wrinkle or two I don't want to get into.  This runs on a 10F202
using all 24 bytes of RAM, although a few bits here and there are not used.
Stuff that in your C compiler and see what you'd get.  No product because it
costs to much, I suspect.


********************************************************************
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]

Tony Smith wrote:
> Getting a 25% speed increase by doing something trivial as buying a
> new PC sounds good to me, beats waiting for the next software release
> (which is very unlikely to be that good).

In the example I used to refute your original statement, I needed a few 100x
for the speed increase to be really useful.  But that was just one example.

Do you really not see that there are problems out there for which no amount
of affordable CPU power is enough, or is this just trolling?


********************************************************************
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]

Tony Smith wrote:

> Not much.  So you get 100 man strong team together and they code away for 6
> months.  In machine code because that's the 'in' thing.  

If you really are into the 'in' things, that's a problem you should work
on.

> But that's irrelevant, of course you pick the faster one if everything
> thing else is equal.  

And in the meantime the company with the slower product goes out of
business. Some few made a bit of money, the society as a whole has to
pick up the tab. For some a viable life model... :)


>>> Or are you waiting for the C programmer to save the day with v4.56b?
>>
>> You're good in setting up strawmen, or at least are trying to be.
>> But it may be that you don't have to wait... there's competition out
>> there, even for autorouters.
>
> But the customers are locked in to their existing product.  No-one
> will switch as you need to do all your libraries again.  But that's
> irrelevant too.

Autorouters are often stand-alone apps that integrate with many layout
programs, because the ones that come with layout programs often are not
considered to be that good. So there's very little locking in with
autorouters.

Where are you trying to get with all this?


>>> No, I meant C.  C & a HHL language can both compile to something
>>> that's pretty much indistinguishable.
>>
>> Indistinguishable in what sense?
>
> To the user.

In some cases. GUI apps that don't do much and most of the time wait for
user input are such cases. But not anything that does some real
computing. Try to decrypt, sort and encrypt gigabyte files in
QuickBasic... and try to get your users to actually wait for the result.


> I used to write in both.  The compiled QB programs ran just as fast as
> compiled C ones, and TurboC & TurboPascal probably did too.  

FWIW, I think (even though I don't have any numbers anymore) that it was
generally easier to write fast programs with Turbo Pascal. AFAIR this
compiler was really good.

> (Hence MS dropping the compiler in VB to make C++ the 'better'
> choice.)  

This sounds as if you just made it up.

It didn't make much sense to make a VB compiler... the language was not
designed for ultimate speed anyway, the goal was different. And for
Microsoft, neither C nor C++ was a real focus at any time. As you can
see now... they're all about VB and C#, and for neither there is a
native compiler; C++ (for which there is a native compiler) is a real
step child, for example in terms of IDE support.


> Or just buy a library where some other poor sod has done the hard work
> for you.  

See, there are people happily making their living with this sort of
thing. Would you say they should do it in QuickBasic?

> The car analog for this thread is arguing whether your car needs a
> rear wing on it.

What's your point, really? You say "no need for C", but then you say
"whenever you need something fast, buy something that's written in C by
someone else", which seems to imply that there is a need for C (doesn't
matter who has to write it). Then you come with odd analogies...

So what's your point? Too much time on your hands?

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

[Marechiare]

> Getting a 25% speed increase by doing something trivial as
> buying a new PC sounds good to me, beats waiting for the
> next software release (which is very unlikely to be that good).

I'm almost sure you are trolling, you were told that reinstalling all
the software would take a day work. That's not cheap and it could be
rather tricky for the compatibility issues, - hardware drivers and new
Windows version (in case his old Windows were OEM).

And most probably he won't get 25% speed increase by replacing Core 2
system (2 years old) with newer Intel Core i7 system. For the
reasonably priced Core i7 configuration he will get sort of 10%-15%
speed increase at max on the processor intensive tasks, and none speed
increase on other tasks.

> You complain something is slow when there's an easy
> solution at hand?
>
> Disk cloning programs are pretty good these days.
> Why build from scratch?

How is "Disk cloning" related to the reinstalling the software on a
new hardware set?
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[CDB-3]

:: How is "Disk cloning" related to the reinstalling the software on a
:: new hardware set?

Some disk cloning software does allow ' foreign ' bare metal restore,
which if ti works right will install correct drivers etc for the new
hardware - time lost is all it takes to clone and possibly install the
drive.

Colin
--
cdb, colin@... on 13/07/2009
 
Web presence: www.btech-online.co.uk  
 
Hosted by:  www.1and1.co.uk/?k_id=7988359
 

 
 
 
 

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

[Gerhard Fiedler]

cdb wrote:

>:: How is "Disk cloning" related to the reinstalling the software on a
>:: new hardware set?
>
> Some disk cloning software does allow ' foreign ' bare metal restore,
> which if ti works right will install correct drivers etc for the new
> hardware - time lost is all it takes to clone and possibly install
> the drive.

Does this work reliably when switching the whole system (motherboard,
processor, disk controller, ...)? Won't the system load the wrong
drivers before it can recognize that it needs other drivers and starts
to install them?

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

[Carl Denk-2]

If we are talking Windows PC's, I have several times using Maxtor
(Seagate) software cloned HD's to replace drives, and/or changed out
motherboards, graphics cards, etc. with no problems. It will either find
the right drivers if they were previously installed or part of windows.
Yes sometimes if it can't find the drivers, it can be a time consumer to
find the right ones though. Kubuntu seemed to do it also, but don't have
enough experience with the dual boot to comment.

Gerhard Fiedler wrote:

> cdb wrote:
>
>  
>> :: How is "Disk cloning" related to the reinstalling the software on a
>> :: new hardware set?
>>
>> Some disk cloning software does allow ' foreign ' bare metal restore,
>> which if ti works right will install correct drivers etc for the new
>> hardware - time lost is all it takes to clone and possibly install
>> the drive.
>>    
>
> Does this work reliably when switching the whole system (motherboard,
> processor, disk controller, ...)? Won't the system load the wrong
> drivers before it can recognize that it needs other drivers and starts
> to install them?
>
> Gerhard
>  

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

It is a great discussion! How much further until a stand off truce is
declared acknowledging that there is no "One size fits all" computer
language and resource management is the real question?

Although I have heard most of these points before I have never found a
better fact based debate.


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

----- Original Message -----
From: "cdb" <colin@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Monday, July 06, 2009 12:15 AM
Subject: Re: Re [PIC]using BREAK in 'C'

> I'm surprised at how far off topic this thread has become.
>
> My question was answered looonnng ago, I wonder if this topic tangent
> which also interests me shouldn't perhaps become OT or Tech or
> something?
>
> Colin
> --
> cdb, colin@... on 6/07/2009
>
> Web presence: www.btech-online.co.uk
>
> Hosted by:  www.1and1.co.uk/?k_id=7988359
>
>
>
>
>
>
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

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

[John Gardner-3]

The most interesting thread I've read in a while.

Vitaliy does'nt need my help, but if anyone's
considering "Code Complete", be warned - Hard to
put down once picked up. My copy is worn out.

I've found OOP resistable so far, but Vitaliy's scheme
makes a lot of sense - I'm learning...

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