Re: Re: Pragmatic Requirements Summary : update

On Mon, 4 Aug 2003, Martin DeMello wrote:

> --- Brian Hurt <[email protected]> wrote:
> > My understanding of the pragmatic philosophy was 180 degrees seperate.  
> > Being pragmatic meant not beleiving in golden hammers- *any* golden 
> > hammer.  You learn a new language a year so you know a lot of languages, 
> > and can use the right one for the job. Tip #17 is "program close to the 
> > problem domain".  Up to and including inventing new languages that are 
> > even closer to the problem domain.  
> 
> Which is why my ideal language is a kitchensink of features to let you easily
> build any given dsl atop it.
> 

Wonderfull theory.  Too bad it doesn't work.

I'll give you one example of why.  Many operating systems, internally, 
have the concept of swappable vr.s non-swappable memory.  Swappable memory 
is allocated in regions the OS can swap out if it's running short of 
memory- nonswappable is (obviously) memory it won't swap out.  Here's the 
thing- while holding a spin lock or in interrupt concept, you don't dare 
touch swappable memory, in *any* form.  If you do, and the memory happens 
to be swapped out, you panic the system.

Which means you need absolute control over where- in what type of memory-
everything gets put.  Where functions and constant data end up you
generally end up using compiler-specific extensions to specify (which
segment they go into, for example).  For data structures, you generally
replace malloc() with some other routine which has an extra parameter
saying which memory space to allocate from.

C doesn't have "hidden" memory- making it easy to tack down every single 
bit of memory used and figure out where it goes.  C++ starts having 
"hidden" memory.  The first place you hit it is the virtual function 
dispatch tables associated with most every object.  Where is this table, 
and what memory space does it go into?

This is just one example.  Hardware-level programmers need not just the 
ability to do things (e.g. pointer arithmetic), but the ability to *not* 
do things (touch swappable memory).  I don't even need to start talking 
about memory-size or real-time constraints.

Now, I turn the question around: assume you can't use Pragmatic to write 
your OS in.  So what?  Not that many people writting OSs anyways, really. 
IMHO, at least half the stuff written in C shouldn't be.  If you're not
directly banging on hardware, if you're not at least considering assembler
as the alternative, you shouldn't be coding in C.  All you lose is the 
ability to claim you are the one true language.  

My experience with One True Languages is that they're so busy trying be 
everything to everyone, they end up being nothing to anyone.  Who now 
remembers PL/I?  The great language, it'll replace all other languages.  
You can even- demonstratably!- write an OS in it (Multics was written in 
PL/I).  

Brian


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/sO0ANB/LIdGAA/ySSFAA/W4wwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/