Re: What will many cores mean to future Windows releases?

"Paul Nichols [TeamB]" wrote

Views are to perform a consolidations of several tables to allow for
viewing on joins that are normal operational processes. I do not see how
that relates to a VM at all.

Technically you're right of course--there's no relation. But conceptually I
think there is an analogy: each is a way of presenting a programmer with a
simplified representation of the underlying reality against which (in theory
<g>) he can program more productively.

Or if you don't like the view analogy one might think about an OPF (object
persistence framework) an another sort of 'VM'--let the programmer write
myObj.Save and an entire underlying layer is invoked. Does such a system put
programmers in a box and retard their learning? Quite possibly. But well
done, it also allows newbies right out of school to create perfect ACID
transactions involving hundreds of objects--something they'd otherwise
struggle with for weeks or months.

However, if we had a VM caching mechanism that would read and write the
core processes to a permanent store, after the first run, then VMs would
be much more efficient.

Basically such a system would have to be able to detect system configuration
changes and invalidate the realized code caches as required, but I see no
reason why that shouldn't be possible. Though I'm not sure how much savings
would actually result. Many of the programs I'm concerned with run for hours
or days at a time--eliminating a first-run JIT really wouldn't achieve that
much in our use profile.

current OS performs. Does anyone truly believe that Vista makes good use
of system resources?

not touchin' that ... <g>, but I'll make the point below that that's not so
different than was the case with the first compilers.

advances in programming technology, but in the past few years, I see way
too many so called programmers that do not even know how to perform a
stack dump, write a batch file, or know how to run a debug command. This
isn't advancement, this is kiddie scripting. :)

Yes and no--the old guard might say the same about me in that I never made a
living or got really comfortable with ASM. Any climb in abstraction is
accompanied by some loss of competence in the layers below--and that's been
the case since the original 'comp sci.' departments evolved from mathematics
or electrical engineering. Few programmers nowadays have any training in IC
design--and neither do I; but I don't feel the lack of an EE degree as my
biggest professional void. I don't think that anything can be said against
VMs that couldn't equally be urged against any language higher than op code.
Certainly as much was urged against the notion of an OS itself: writing to
an OS is nevero going to be as efficient or elegant as just writing to the
hardware. But OS's won anyway.

This puts developers into a box. Get them out of the box and they are
lost. I personally feel you are not free to innovate and improve
operations, if you do not have control over how the operations work. Maybe
I am just an old timer :).

So to climb up several levels, I'm not sure that the VM puts programmers
into a box any more than the VCL does: we've both seen programmers that
don't have a clue how the VCL is actually structured despite Borland
shipping the source, much less being comfortable with the underlying windows
API. Is that Delphi's fault?

I've generally heard it said that a programmer should be competent one layer
lower than he actually works, and at least passingly familiar with the layer
under that. But that's generally not the actual case, and I doubt it ever
was. If programmers are, on the whole, more incompetent than normal
nowadays, it's probably a reflection of two things: the rate at which what's
possible keeps expanding (giving us ever more to know), and the fact that,
as you note, the reality of VMs lags their promise by some ways. But then
again, is was years before compilers became smart enough to outcode most ASM
writers--I don't think it's entirely unexpected that VM runtimes are equally
'un-optimised.'

On the general issue of programmer competence, I thought this interesting:
http://www.ftponline.com/vsm/2007_05/magazine/departments/guestop/

Opening line: "The point at which anyone on the planet is competent to write
..NET applications passed sometime in the last year or so."

Good discussion, BTW.

Yes, thanks.

bobD


.

Relevant Pages

  • Re: Advantages of object-oriented programming
    ... like which often get ignored by programmers and are equally, ... object (it lacks action and tangibility). ... You can combine services and mixins together (one usually acts on the ... Presentation Layer. ...
    (comp.object)
  • Re: Advantages of object-oriented programming
    ... like which often get ignored by programmers and are equally, ... object (it lacks action and tangibility). ... You can combine services and mixins together (one usually acts on the ... Presentation Layer. ...
    (comp.object)
  • Re: What will many cores mean to future Windows releases?
    ... Or if you don't like the view analogy one might think about an OPF an another sort of 'VM'--let the programmer write myObj.Save and an entire underlying layer is invoked. ... The programmers must concentrate on their human problem, ... In fact, these aren't VM anymore but, as you stated, JIT compilers. ... The gap between the best software engineering practice ...
    (borland.public.delphi.non-technical)
  • Re: How do I become a professional PHP Developer in the UK? Advice needed pls
    ... Towing the corporate line can cover a LOT of shortcomings. ... I've had some relatively new programmers on projects. ... As for competence - I don't know any company who will put up with a person who's unable to do a job and not willing to learn to do it. ...
    (comp.lang.php)
  • Re: Results of the memswap() smackdown from the thread "Sorting" assignment
    ... that once known is remembered by C and C++ programmers. ... both got low grades on a test of C and C++ competence, ... which show global incompetence and global dishonesty. ... productive technical thread, I worked in C. ...
    (comp.programming)