New soft processor core paper publisher?

[rickman]

On 6/20/2013 10:51 AM, Tom Gardner wrote:

Eric Wallin wrote:
I really want to like Forth, but after reading the books
and being repeatedly repelled by the syntax and programming
model I gave up.

Quitter! If the syntax (or near total lack thereof) bothers you, then
you must have a very thin skin.

Nobody /writes/ Forth. They write programs that emit Forth.
The most mainstream example of that is printer drivers
emitting PostScript.

LOL! I guess I was documenting something this morning rather than
writing code...

--

Rick

 

[Elizabeth D. Rather]

On 6/20/13 1:50 PM, rickman wrote:

On 6/20/2013 10:51 AM, Tom Gardner wrote:
Eric Wallin wrote:
I really want to like Forth, but after reading the books
and being repeatedly repelled by the syntax and programming
model I gave up.

Quitter! If the syntax (or near total lack thereof) bothers you, then
you must have a very thin skin.

Nobody /writes/ Forth. They write programs that emit Forth.
The most mainstream example of that is printer drivers
emitting PostScript.

LOL! I guess I was documenting something this morning rather than
writing code...

Eric, I'm curious what books these were that you found so offensive?

I'm also baffled about your comment about "programs that emit Forth."
Although PostScript has many features in common with Forth, it is quite
different, both in terms of command set and programming model.

Modern Forths (e.g. since the release of ANS Forth 94) feature a variety
of implementation strategies, ranging from fairly conventional compilers
that generate optimized machine code to more traditional threaded code
models.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

 

[Eric Wallin]

On Thursday, June 20, 2013 7:50:09 PM UTC-4, rickman wrote:

Quitter! If the syntax (or near total lack thereof) bothers you, then
you must have a very thin skin.

Ha ha! And I see what you did there.


On Thursday, June 20, 2013 9:31:53 PM UTC-4, Elizabeth D. Rather wrote:

Eric, I'm curious what books these were that you found so offensive?

The books ("Starting Forth", "Thinkind Forth", "Forth Programmer's Handbook") weren't themselves offensive, but they revealed Forth to be much lamer than I expected for all the stick-it-to-the-man ethos surrounding it. I was totally stoked for a stack-based language that would solve all my problems, but all I got was some books gathering dust.

I'm also baffled about your comment about "programs that emit Forth."
Although PostScript has many features in common with Forth, it is quite
different, both in terms of command set and programming model.

You're looking for Tom Gardner, he's down the hall near the elevators using a little stamp at the bottom of his cane to make little chicken footprints on the floor..

 

[Tom Gardner]

Elizabeth D. Rather wrote:

I'm also baffled about your comment about "programs that emit
Forth." Although PostScript has many features in common with
Forth, it is quite different, both in terms of command set
and programming model.

It was my comment, based on experience of writing
a few Forth and PostScript programs back in the mid 80s.

I'm know there are differences between Forth and
PostScript, but the similarities are /more/ significant.
Forth is like PostScript in the same way that Delphi
is like Pascal, C# is like Java, Scheme is like Lisp,
Objective-C is like SmallTalk (and unlike C++) etc.

And, more importantly, ForthPostscript is unlike C,
is unlike Prolog, is unlike Lisp, is unlike Smalltalk
is unlike Pascal.

I was beguiled by Forth and to some extend remain so:
I'd /love/ to find a good justification to use it again,
and might do so, just for the hell of it.

I'm sure Forth has moved on since the 80s, but it cannot
escape its ethos any more than C, Prolog, Lisp,
Smalltalk can. Or rather, if it did chance then it wouldn't
be Forth anymore.

Modern Forths (e.g. since the release of ANS Forth 94)
feature a variety of implementation strategies, ranging
from fairly conventional compilers that generate
optimized machine code to more traditional threaded code models.

I'm sure that's true, but it misses the point.
Interpreted Java is the same as jitted Java is
the same as Hotspotted Java.

Ditto Forth; if it wasn't then it simply wouldn't be Forth!

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.

I would, however, be interested to know whether Forth
has a defined memory model, since that's a _necessary_
_precondition_ to be able to write portable multithreaded
code that runs on multicore processors. Hells teeth,
even C has now has finally decided that they need to define
a memory model, only 20 years after those With Clue
knew it was required. (I don't think there are any
implementation though!)

 

[David Brown]

On 21/06/13 11:30, Tom Gardner wrote:

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.

Shouldn't that be "almost nobody Forth writes" ?

I wonder if Yoda programs in Forth...


(I too would like an excuse to work with Forth again.)

 

[Tom Gardner]

David Brown wrote:

On 21/06/13 11:30, Tom Gardner wrote:

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.


Shouldn't that be "almost nobody Forth writes" ?

Still use my HP calculators in preference to
algebraic and half-algebraic calculators!

 

[rickman]

On 6/20/2013 11:38 PM, Eric Wallin wrote:

On Thursday, June 20, 2013 7:50:09 PM UTC-4, rickman wrote:
Quitter! If the syntax (or near total lack thereof) bothers you, then
you must have a very thin skin.

Ha ha! And I see what you did there.


On Thursday, June 20, 2013 9:31:53 PM UTC-4, Elizabeth D. Rather wrote:
Eric, I'm curious what books these were that you found so offensive?

The books ("Starting Forth", "Thinkind Forth", "Forth Programmer's Handbook") weren't themselves offensive, but they revealed Forth to be much lamer than I expected for all the stick-it-to-the-man ethos surrounding it. I was totally stoked for a stack-based language that would solve all my problems, but all I got was some books gathering dust.

I'm also baffled about your comment about "programs that emit Forth."
Although PostScript has many features in common with Forth, it is quite
different, both in terms of command set and programming model.

You're looking for Tom Gardner, he's down the hall near the elevators using a little stamp at the bottom of his cane to make little chicken footprints on the floor..

I just saw that episode a few weeks ago. The chicken contest was pretty
cool actually.

I actually identify with House. Not that I am as smart as he is, but I
have a bad hip (waiting for Obamacare to kick in so I can get a new one)
and have a natural tendency to tick off people unless I work to reign it
in. :]

--

Rick

 

[rickman]

On 6/21/2013 5:30 AM, Tom Gardner wrote:

Elizabeth D. Rather wrote:
I'm also baffled about your comment about "programs that emit
Forth." Although PostScript has many features in common with
Forth, it is quite different, both in terms of command set
and programming model.

It was my comment, based on experience of writing
a few Forth and PostScript programs back in the mid 80s.

I'm know there are differences between Forth and
PostScript, but the similarities are /more/ significant.
Forth is like PostScript in the same way that Delphi
is like Pascal, C# is like Java, Scheme is like Lisp,
Objective-C is like SmallTalk (and unlike C++) etc.

And, more importantly, ForthPostscript is unlike C,
is unlike Prolog, is unlike Lisp, is unlike Smalltalk
is unlike Pascal.

I was beguiled by Forth and to some extend remain so:
I'd /love/ to find a good justification to use it again,
and might do so, just for the hell of it.

If you ever need to control hardware, you will want it. The
interactivity is great.
Actually, when doing things in real time the interactivity sort of goes
away (or at least the utility of it) since you can't type fast enough to
control a robot or intercept a serial port running at 38.4 kbps. But
you can very easily test small portions of your code in ways that are
tricky in C or the other languages you mention. Then those ideas can be
applied to any app... even if not real time.

I'm sure Forth has moved on since the 80s, but it cannot
escape its ethos any more than C, Prolog, Lisp,
Smalltalk can. Or rather, if it did chance then it wouldn't
be Forth anymore.

Can *any* of us ever escape our ethos? I know I've been trying for many
a year and it is still right here by my side, aren't you Ethos?
Actually, that would be a good name for a couple of dogs, Ethos and
Pathos, Chesapeake Bay retrievers.

Modern Forths (e.g. since the release of ANS Forth 94)
feature a variety of implementation strategies, ranging
from fairly conventional compilers that generate
optimized machine code to more traditional threaded code models.

I'm sure that's true, but it misses the point.
Interpreted Java is the same as jitted Java is
the same as Hotspotted Java.

Ditto Forth; if it wasn't then it simply wouldn't be Forth!

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.

So now I've been demoted to to "almost" nobody? What do I have to do to
work my way *up* to nobody?

I would, however, be interested to know whether Forth
has a defined memory model, since that's a _necessary_
_precondition_ to be able to write portable multithreaded
code that runs on multicore processors. Hells teeth,
even C has now has finally decided that they need to define
a memory model, only 20 years after those With Clue
knew it was required. (I don't think there are any
implementation though!)

Uh, can *someone* who knows something answer that one?

Do you have a lot of call to program multithreaded code for multicore
processors? What sort of apps are you coding?

--

Rick

 

[rickman]

On 6/21/2013 7:18 AM, David Brown wrote:

On 21/06/13 11:30, Tom Gardner wrote:

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.


Shouldn't that be "almost nobody Forth writes" ?

I would say that was "nobody almost Forth writes". Wouldn't it be [noun
[adjective] [noun [adjective]]] verb?

(I too would like an excuse to work with Forth again.)

What do you do instead?

--

Rick

 

[rickman]

On 6/22/2013 12:44 AM, Eric Wallin wrote:

On Friday, June 21, 2013 10:25:55 AM UTC-4, Tom Gardner wrote:

Still use my HP calculators in preference to
algebraic and half-algebraic calculators!

Same here! When manually calculating, give me HP (or similar) or give me death. But Forth kind of sucks (and it pains me deeply to have discovered that). The failure (as I see it) of Forth is the awkward target programming model (or virtual machine as the kids say these days - virtual anything is sexy).

There's a pretty big gulf between between manual data& operation entry on something like an HP (or any hand held calculator) and programming with Forth (or any language). A single stack very much facilitates the former but places handcuffs on the latter. These are two fairly different activities that IMO don't exactly have boatloads of overlap, however much we might want or personally need for it to be so.

I won't argue with any of that, or I might...

So why are you here exactly? I'm not saying you shouldn't be here or
that you shouldn't be saying what you are saying. But given how you
feel about Forth, I'm just curious why you want to have the conversation
you are having? Are you exploring your inner curmudgeon?

--

Rick

 

[Eric Wallin]

On Friday, June 21, 2013 10:25:55 AM UTC-4, Tom Gardner wrote:

Still use my HP calculators in preference to
algebraic and half-algebraic calculators!

Same here! When manually calculating, give me HP (or similar) or give me death. But Forth kind of sucks (and it pains me deeply to have discovered that). The failure (as I see it) of Forth is the awkward target programming model (or virtual machine as the kids say these days - virtual anything is sexy).

There's a pretty big gulf between between manual data & operation entry on something like an HP (or any hand held calculator) and programming with Forth (or any language). A single stack very much facilitates the former but places handcuffs on the latter. These are two fairly different activities that IMO don't exactly have boatloads of overlap, however much we might want or personally need for it to be so.

 

[Tom Gardner]

rickman wrote:

On 6/21/2013 5:30 AM, Tom Gardner wrote:
Elizabeth D. Rather wrote:
I'm also baffled about your comment about "programs that emit
Forth." Although PostScript has many features in common with
Forth, it is quite different, both in terms of command set
and programming model.

I was beguiled by Forth and to some extend remain so:
I'd /love/ to find a good justification to use it again,
and might do so, just for the hell of it.

If you ever need to control hardware, you will want it. The interactivity is great.

The first time I wished I had Forth was when manually
testing prototype hardware with a z80-class processor
c1983. Forth would have been ideal, and significantly
better than the rubbish I threw together.

That experience has shaped my views of "domain specific
languages" vs libraries to this day.

Actually, when doing things in real time the interactivity sort of goes away (or at least the utility of it) since you can't type fast enough to control a robot or intercept a serial port running at
38.4 kbps. But you can very easily test small portions of your code in ways that are tricky in C or the other languages you mention. Then those ideas can be applied to any app... even if not real time.

Just so. It seems we are in violent agreement.

One also has to consider the tools that other people
are familiar with; changing away from them requires
very significant advantages, and Forth just doesn't
have those.

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.

So now I've been demoted to to "almost" nobody? What do I have to do to work my way *up* to nobody?

Why are you assuming "demoted"? Is a screw above or
below a nail in some imagined hierarchy!

I would, however, be interested to know whether Forth
has a defined memory model, since that's a _necessary_
_precondition_ to be able to write portable multithreaded
code that runs on multicore processors. Hells teeth,
even C has now has finally decided that they need to define
a memory model, only 20 years after those With Clue
knew it was required. (I don't think there are any
implementation though!)

Uh, can *someone* who knows something answer that one?

Do you have a lot of call to program multithreaded code for multicore processors? What sort of apps are you coding?

Even cellphones have dual and quad processors nowadays.

And, of course, there are outliers like the Parallax
Propellor.

Multicore will become the norm in the near future; the
only constraint in embedded systems will be memory bandwidth.

 

[Tom Gardner]

rickman wrote:

I won't argue with any of that, or I might...

So why are you here exactly? I'm not saying you shouldn't be here or that you shouldn't be saying what you are saying. But given how you feel about Forth, I'm just curious why you want to have the
conversation you are having? Are you exploring your inner curmudgeon?

(a) because it is fun
(b) to gain a personal understanding of the advantages of
nails and screws, and when each should/shouldn't be used

 

[rickman]

On 6/22/2013 4:34 AM, Tom Gardner wrote:

rickman wrote:
On 6/21/2013 5:30 AM, Tom Gardner wrote:
Elizabeth D. Rather wrote:
I'm also baffled about your comment about "programs that emit
Forth." Although PostScript has many features in common with
Forth, it is quite different, both in terms of command set
and programming model.

I was beguiled by Forth and to some extend remain so:
I'd /love/ to find a good justification to use it again,
and might do so, just for the hell of it.

If you ever need to control hardware, you will want it. The
interactivity is great.

The first time I wished I had Forth was when manually
testing prototype hardware with a z80-class processor
c1983. Forth would have been ideal, and significantly
better than the rubbish I threw together.

That experience has shaped my views of "domain specific
languages" vs libraries to this day.

I'm not sure what that implies, but I'll go with it.

Actually, when doing things in real time the interactivity sort of
goes away (or at least the utility of it) since you can't type fast
enough to control a robot or intercept a serial port running at
38.4 kbps. But you can very easily test small portions of your code in
ways that are tricky in C or the other languages you mention. Then
those ideas can be applied to any app... even if not real time.

Just so. It seems we are in violent agreement.

Not *too* violent. I don't have guns or anything like that.

One also has to consider the tools that other people
are familiar with; changing away from them requires
very significant advantages, and Forth just doesn't
have those.

I'm not sure what tools you mean. Sometimes I miss using a debugger
where I can step through my code. Actually I bet Win32Forth has that
somewhere, but the docs are not so great and I am likely missing some
95% of what is in it. Still, debuggers have their limits, notably they
don't do a great job of getting you in the vicinity of the bug so you
can step through the code to find it.

My willingness to give up debuggers and "go with the Forth" was largely
prompted by a statement by Jeff Fox. I don't recall the context exactly
but I was talking about the difficulties of tracking down stack
underflows. My context was thinking like I was coding in C where I
would write a bunch of code and then start in on the bugs often adding
new ones in the process. Jeff pointed out that in Forth, if you have a
stack mismatch it shows that *you can't count*. Even though (or perhaps
because) it was so simple, that really struck me. If I can't write a
Forth word that balances the stack effects, it means I can't count to
three or four. Counting to three or four is a lot easier than using a
debugger!

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.

So now I've been demoted to to "almost" nobody? What do I have to do
to work my way *up* to nobody?

Why are you assuming "demoted"? Is a screw above or
below a nail in some imagined hierarchy!

Context is everything. I have no idea what the context of screw v nail
is about.

I would, however, be interested to know whether Forth
has a defined memory model, since that's a _necessary_
_precondition_ to be able to write portable multithreaded
code that runs on multicore processors. Hells teeth,
even C has now has finally decided that they need to define
a memory model, only 20 years after those With Clue
knew it was required. (I don't think there are any
implementation though!)

Uh, can *someone* who knows something answer that one?

Do you have a lot of call to program multithreaded code for multicore
processors? What sort of apps are you coding?

Even cellphones have dual and quad processors nowadays.

And, of course, there are outliers like the Parallax
Propellor.

Multicore will become the norm in the near future; the
only constraint in embedded systems will be memory bandwidth.

So which are you writing code for? Or is this just a theoretical
discussion?

As to multicore being the norm... well, the last toaster I bought does
seem to have a micro in it, *really*. It's a four slice unit, each half
has three little buttons for bagel, frozen and reheat, one button for
cancel and a darkness knob. You have up to five seconds after pushing
down the handle to make your selections. I'll bet you anything this has
a GA4 in it! I can't imagine doing this without a multicore
processor... oh, wait, that is programmed in Forth isn't it... what is
that memory model again?

--

Rick

 

[chrisabele]

On 6/22/2013 1:20 AM, rickman wrote:

...
Actually, that would be a good name for a couple of dogs, Ethos and
Pathos, Chesapeake Bay retrievers.
...

What happened to the third dog, Logos?

A funny omission, given that this group is primarily logic related (only
secondarily philosophy related).

Chris

 

[David Brown]

On 22/06/13 07:23, rickman wrote:

On 6/21/2013 7:18 AM, David Brown wrote:
On 21/06/13 11:30, Tom Gardner wrote:

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.


Shouldn't that be "almost nobody Forth writes" ?

I would say that was "nobody almost Forth writes". Wouldn't it be [noun
[adjective] [noun [adjective]]] verb?

I thought about that, but I was not sure. When I say "work with Forth
again", I have only "played" with Forth, not "worked" with it, and it
was a couple of decades ago.

(I too would like an excuse to work with Forth again.)

What do you do instead?

I do mostly small-systems embedded programming, which is mostly in C.
It used to include a lot more assembly, but that's quite rare now
(though it is not uncommon to have to make little snippets in assembly,
or to study compiler-generated assembly), and perhaps in the future it
will include more C++ (especially with C++11 features). I also do
desktop and server programming, mostly in Python, and I have done a bit
of FPGA work (but not for a number of years).

I don't think of Forth as being a suitable choice of language for the
kind of systems I work with - but I do think it would be fun to work
with the kind of systems for which Forth is the best choice. However, I
suspect that is unlikely to happen in practice. (Many years ago, my
company looked at a potential project for which Atmel's Marc-4
processors were a possibility, but that's the nearest I've come to Forth
at work.)

I just think it's fun to work with different types of language - it
gives you a better understanding of programming in general, and new
ideas of different ways to handle tasks.

 

[rickman]

On 6/22/2013 11:21 AM, David Brown wrote:

On 22/06/13 07:23, rickman wrote:
On 6/21/2013 7:18 AM, David Brown wrote:
On 21/06/13 11:30, Tom Gardner wrote:

I suppose I ought to change "nobody writes Forth" to
"almost nobody writes Forth.


Shouldn't that be "almost nobody Forth writes" ?

I would say that was "nobody almost Forth writes". Wouldn't it be [noun
[adjective] [noun [adjective]]] verb?

I thought about that, but I was not sure. When I say "work with Forth
again", I have only "played" with Forth, not "worked" with it, and it
was a couple of decades ago.

Hey, it's not like this is *real* forth. But looking at how some Forth
code works for things like assemblers and my own projects, the data is
dealt with first starting with some sort of a noun type piece of data
(like a register) which may be modified by an adjective (perhaps an
addressing mode) followed by others, then the final verb to complete the
action (operation).

(I too would like an excuse to work with Forth again.)

What do you do instead?


I do mostly small-systems embedded programming, which is mostly in C. It
used to include a lot more assembly, but that's quite rare now (though
it is not uncommon to have to make little snippets in assembly, or to
study compiler-generated assembly), and perhaps in the future it will
include more C++ (especially with C++11 features). I also do desktop and
server programming, mostly in Python, and I have done a bit of FPGA work
(but not for a number of years).

Similar to myself, but with the opposite emphasis. I mostly do hardware
and FPGA work with embedded programming which has been rare for some years.

I think Python is the language a customer recommended to me. He said
that some languages are good for this or good for that, but Python
incorporates a lot of the various features that makes it good for most
things. They write code running under Linux on IP chassis. I think
they use Python a lot.

I don't think of Forth as being a suitable choice of language for the
kind of systems I work with - but I do think it would be fun to work
with the kind of systems for which Forth is the best choice. However, I
suspect that is unlikely to happen in practice. (Many years ago, my
company looked at a potential project for which Atmel's Marc-4
processors were a possibility, but that's the nearest I've come to Forth
at work.)

So why can't you consider Forth for processors that aren't stack based?

I just think it's fun to work with different types of language - it
gives you a better understanding of programming in general, and new
ideas of different ways to handle tasks.

I'm beyond "playing" in this stuff and I don't mean "playing" in a
derogatory way, I mean I just want to get my work done. I'm all but
retired and although some of my projects are not truly profit motivated,
I want to get them done with a minimum of fuss. I look at the tools
used to code in C on embedded systems and it scares me off really,
especially the open source ones that require you to learn so much before
you can become productive or even get the "hello world" program to work.
That's why I haven't done anything with the rPi or the Beagle Boards.

--

Rick

 

[Tom Gardner]

Eric Wallin wrote:

Why is it that every "serious" processor is a ball of cruft with multiple bags on the side, some much worse than others, but none even a mother could love? Is it because overly complex compilers have made HW developers disillusioned / complacent?

1) an adherence to the von Neumann concepts of what a processor should be
2) processing models that worked well given previous technology limits,
but which don't scale to modern technology limits (e.g processor/memory
speed ratio, number of ic pins, cache coherence)
3) backwards compatibility (*the* dominant commercial consideration)

I honestly don't get how we got here from there. If it's anything, engineering is an exercise in complexity management, but processor design is somehow flying under the radar.

1) look at The Mill on comp.arch, for one beguiling possibility
2) message passing between processors/threads executing on
multiprocessor machines with non-coherent memories

 

[Tom Gardner]

Eric Wallin wrote:

On Saturday, June 22, 2013 1:26:53 AM UTC-4, rickman wrote:

So why are you here exactly? I'm not saying you shouldn't be here or
that you shouldn't be saying what you are saying. But given how you
feel about Forth, I'm just curious why you want to have the conversation
you are having? Are you exploring your inner curmudgeon?

Just venting at the industry, and procrastinating a bit (putting off the final verification of the processor). Apparently OT is my favorite subject as it seems I'm always busy derailing my own (and others) threads. That, and Y'all have very interesting takes on these and various and sundry other things.

Backing up a bit, it strikes me as a bit crazy to make a
language based on the concept of a weird target processor.
I mean, I get the portability thing, but at what cost?
If my experience as a casual user (not programmer) of
Java on my PC is any indication (data point of one,
the plural of anecdote isn't data, etc.), the virtual stack-based
processor paradigm has failed, as the constant updates, security
issues, etc. pretty much forced me to uninstall it.

None of those real problems are related to "virtual stack-based
processor paradigm".

And I would think that a language targeting a processor model
that is radically different than the physically underlying one
would be terribly inefficient unless the compiler can do hand
stands while juggling spinning plates on fire - even if it is,
god knows what it spits out.

That is just about what HotSpot does As L Peter Deutsch remarked
when people had similar reservations about the first (Smalltalk) JIT
in the mid 80s, if you can't tell the difference externally, the
internals don't matter.

Now for some fun how emulated processors can be faster than
native processors *even when both processors are the same*
- take processor X executing cpu intensive C benchmarks
compiled with optimisation on, and measure speed S1
- write an emulator for processor X and run that emulator
on processor X
- run those C benchmarks on in the emulator, see what the
code is actually doing (as opposed to what the compiler
dared not assume)
- use that knowledge to "patch the optimised binaries"
- run the patched binaries in the emulator, and measure
speed S2
- note that S2 can be faster than S1
http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1.html

Canonical stack processors and theirlanguages (Forth, Java,
Postscript) at this point seem to be hanging by a legacy thread
(even if every PC runs one peripherally at one time or another).

That's a bizarre assertion.

I find it exceeding odd that the PC industry is still using
x86 _anything_ at this point.

backwards compatibility is the dominant commercial imperative:
don't inconvenience your existing customers. (Windows 8? Tee hee)

Apple showed us you can just dumpyour processor and switch
horses in midstream pretty much whenever you feel like it
(68k => PowerPC => x86) and not torch your product line /
lose your customer base.

Only given preconditions that don't apply in the Wintel world.

 

[Tom Gardner]

David Brown wrote:

I do mostly small-systems embedded programming, which is mostly in C. It used to include a lot more assembly, but that's quite rare now (though it is not uncommon to have to make little snippets in
assembly, or to study compiler-generated assembly), and perhaps in the future it will include more C++ (especially with C++11 features). I also do desktop and server programming, mostly in Python,
and I have done a bit of FPGA work (but not for a number of years).

If C++ is the answer, I want to know what the question is.

How many *years* does it take before the first commercial
implementation of a C++ standard becomes available? Yes, I
know partial implementations become available pretty quickly.

Soustroup's tome describing "this is what I meant by the
various bits of C++" started out at ~400 pages and is now
around 1300 pages. 'Nuff said.

Don't forget that it is possible to get the compiler to
emit the sequence of prime numbers during the (unterminating)
compilation process. The language designers didn't realise
they had created such a monster until it was demonstrated
to them!
<http://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP>

I just think it's fun to work with different types of language - it gives you a better understanding of programming in general, and new ideas of different ways to handle tasks.

Very true. Choose the right tool for the task at hand.