The beauty of scheme is that it is quite possible to design statically typed meta language. And if we let the guile hacker doggies chew on the guile stake a little bit more, you would also see a speedup of the generated code that will essentially mean that just a tiny bit of C-code needs to be written. In all a perfect setup for fast maintainable and secure code. But the bit's needs to be in place. Why don't we try to copy typed racket over to guile?
/Stefan On Sat, Mar 8, 2014 at 5:37 PM, Taylan Ulrich Bayırlı/Kammer < taylanbayi...@gmail.com> wrote: > Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> writes: > > > On 08/03/14 00:32, Mark H Weaver wrote: > >> Mateusz Kowalczyk <fuuze...@fuuzetsu.co.uk> writes: > >>> I doubt that going from a single inherently unsafe but bloody fast > >>> language to slightly less unsafe but much slower language is an > >>> advantage here… > >> > >> "Slightly less unsafe"? Seriously? > > > > Sure. You get rid of pointer arithmetic which is the beg evil in C but > > you lose any kind of static typing. It's about as safe as Python, Ruby > > and whatever new and hip dynamic language is popular today: not a > > whole lot. > > Your tone makes me unsure whether I should try to argue but, since when > does "safety" in programming languages have anything to do with static > as opposed to dynamic type-checking? > > The notion of safety I know prescribes well-defined behavior in error > situations, and disallowing behavior that doesn't make sense from an > abstract point of view, which is roughly anything that exposes details > of the underlying machinery during computation, like the raw > byte-sequences denoting the abstract entities worked with. These are > also, from my knowledge, the main target of security exploits, > specifically memory unsafety. > > If we treat safety/unsafety as a boolean, then the dynamically typed > languages you mentioned are safe, whereas C is not; both in terms of > types and memory, and memory safety is the security-relevant notion of > safety I know. > > If we were to treat it as a continuum, I would rather call a type-safe, > memory-safe, dynamically typed language slightly less safe than a > type-safe, memory-safe, statically typed language, and I'm unsure how > much this notion of safety is relevant to security exploits. > > The mention of speed, by the way, seems very off-the-mark. > > I know nothing about any previous arguments you were in, but from these > three e-mails alone I'll sadly have to agree that you appear to have a > bias against so-called "dynamic" languages. :-) > > Taylan > >
