POV-Ray : Newsgroups : povray.off-topic : Programming language development : Re: Programming language development Server Time
5 Sep 2024 15:21:18 EDT (-0400)
  Re: Programming language development  
From: Orchid XP v8
Date: 2 Oct 2009 06:41:18
Message: <4ac5d8ce$1@news.povray.org>
>>>  > To avoid security problems?
>>> I guess this would require a proper definition of "security problems".
>>
>> Code doing things the author didn't want it to do because malicious 
>> people intentionally caused it to happen.
> 
> There's no general way around it, because malicious people of this type 
> are highly intelligent and inventive. Whatever you'd integrate into the 
> language itself would just give you a /false sense of/ security.

As far as I can tell, 98% of all security issues are buffer overruns - 
trivially fixable, yet nobody seems to think it's necessary.

Then there are things like data tainting (which could be enforcible at 
compile-time with no run-time overhead). Hell, in Haskell land, people 
regularly attempt to write code which is *provably secure*. (But then, 
you have to define "secure" first... It's easy to prevent buffer 
overruns, but not so simple to prevent glitches where access denied 
messages inadvertantly reveal information indirectly.)

>> Stuff like the ability for me to know that my change hurt your code. 
>> Something like unit testing, only built into the language, say.
> 
> That seems to go into a similar direction as contract-oriented design.

Yeah, that's a nice idea. Doesn't seem very popular though...

> Try implementing and using generic container classes in a non-OO language.
> 
> Then try to refactor your application to use a deque container instead 
> of a stack for a certain job. Or a tree-backed map instead of a 
> hash-table-backed one someplace else.
> 
> You won't have much success without implementing verbosely what OO 
> languages do for you behind the scenes.

Tried using Haskell recently? Haskell is not OO.

Sure, you need encapsulation, and you need polymorphism. You also need 
dynamic binding *if* you want to change your mind about which data 
structure you're going to use *at run-time*. But you don't necessarily 
need implementation inheritance, or mutable state for that matter...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.