Re: Pragmatic Requirements Summary : update

--- In [email protected], Brian Hurt <bhurt@s...> wrote:
> 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.  

 You may be right. We want power and the ability to get pretty low 
level but not at the cost of consitancy. Hmm, we are still pretty 
young, we will have to see where things go.

> 
> 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).  
> 

 PL/I is still used just not much. I am pretty sure that one-to-
allness wasnt the only thing wrong with PL/1


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