You could feasibly do the same stuff in an interpreted language, but (I suspect) it would be substantially slower than directly running those compiled command-line tools underlying it.
That sounds bass ackwards if you ask me. A command line tool is usually a thin wrapper around a library, for a reason.
I realize it might seem crazy to duplicate functionality from gs into your library, but then the tool should link against those code bases as libraries instead of calling some gs executable (which of course in turn is just a wrapper around a gs library and so on).
Making a library call to re-scale an image or convert from formatA to formatB shouldn't be a shell execute call to begin with, and it shouldn't be making any shell exec calls of its own.
It's historically grown. The tool came first, the library was tacked on later.
And yes, it's a mess. That's why the much saner GraphicsMagick was forked off it… in 2002. People just never migrated.
That being said, I wouldn't be surprised if porting those things over from compiled languages to be a part of the library would prove to be substantially slower. For high-volume applications, it would very possibly make the library totally unusable.
I agree that it's a backwards way of doing things in a perfect world, but the perfect is the enemy of the good. Sometimes you've gotta make compromises for reality's sake.
I must have missed something, I thought ImageMagick was a collection of C libraries and C programs, which in turn occasionally called other libraries and programs (such as gs).
What I meant was that a graphics utility should be a c library that exports functions like
scale_image(source_image, target_image, scale)
convert image.jpg -resize 0.5