• Sjoerd van Leent <svanleent gmail.com> Jun 05 2009
• Robert Clipsham <robert octarineparrot.com> Jun 05 2009
• bearophile <bearophileHUGS lycos.com> Jun 05 2009
• Sjoerd van Leent <svanleent gmail.com> Jun 05 2009
• Robert Fraser <fraserofthenight gmail.com> Jun 05 2009
• Kagamin <spam here.lot> Jun 05 2009
• BCS <none anon.com> Jun 05 2009
• Sjoerd van Leent <svanleent gmail.com> Jun 05 2009

Sjoerd van Leent <svanleent gmail.com> writes:

Currently, there are two major commercial vendors of GIS Software (GE and
ESRI). GIS applications are big. They have a startup time of about 10 to 20
minutes. So GIS programmers prefer to be able to change code dynamically, not
having to restart every time.

To do this, both of them use a virtual machine. ESRI uses .NET and GE uses
Magik, a homebrewn language and VM. The most critical functions are implemented
in C.

However, both of them use old-fashioned approaches (The GE application stems
from the pre-Windows 3.0 era, but is the most efficient of the two). I'd like
to start with some serious redesigning. I've been looking into D, but since D
doesn't allow me to dynamically change behavior, it most likely requires a VM.
Currently, I've been looking into miniD and Ruby as possible languages that
could do what I want.

Currently, there are the following issues:

Database - GIS applications need a GIS oriented database, able to store and
perform calculations on coordinates, lines and polygons.

Database triggers/constraints/stored procedures - User defined functionality

User application - An application with custom windows, dialogs and menus to
interact with the GIS database(s)

On top of that, D is at version 2, whereas Tango is at version 1 of D. I'm
still in doubt whether Phobos would be better than Tango. If so, miniD would be
ruled out. If that would be the case, there needs to be a proper binding
between D and Ruby.

Any ideas...

Robert Clipsham <robert octarineparrot.com> writes:

Sjoerd van Leent wrote:
 On top of that, D is at version 2,


D2 is in alpha, D1 is "stable".

 whereas Tango is at version 1 of D.


Tango uses D1 because D1 is stable. There is a Tango 2 branch, I believe 
it is incomplete currently.

 I'm still in doubt whether Phobos would be better than Tango.


That depends on your needs. I personally prefer tango due to its speed 
and greater feature set. It's also actively maintained, phobos 1 only 
gets bug fixes now. If you decide to use D2 then phobos is probably the 
best (only?) option currently, it seems to be shaping up nicely.

 If so, miniD would be ruled out.


MiniD is an excellent language, I'd definitely recommend it if you 
decide on D1/Tango.

 If that would be the case, there needs to be a proper binding between D and
Ruby.


I don't believe any exist currently, you'd probably have to write your own.

You seem to require a lot of libraries for what you want, in which case 
D1 is probably best as there's a nice selection of libraries available 
for it. Sorry I couldn't help with any of your other issues.

bearophile <bearophileHUGS lycos.com> writes:

Sjoerd van Leent:
I've been looking into D,<


I suggest D1 running on LDC with Tango.


but since D doesn't allow me to dynamically change behavior, it most likely
requires a VM.<


With D you can use plug-ins with DDL (similar to windows DLLs). If you use LDC
it uses LLVM as backend, it's not a real VM like the JavaVM, but it can be used
in several smart ways to generate and run code at runtime anyway.


Currently, I've been looking into miniD and Ruby as possible languages that
could do what I want.<


Beside minD that is written in D, at the moment there are D bindings for Python
(Pyd). Pyd is designed for Phobos, but it may be adapted to Tango with some
work (probably quite less work than writing binding for Ruby. There will be
RuDy, but it's embryonic still
http://tomash.wrug.eu/2009/03/03/rudy-ruby-native-extensions-in-d-progr
mming-language.html ).
The usage of Pyd is nice, but it may have some scalability problems, so before
using it in production it's better to test it very well.


 User application - An application with custom windows, dialogs and menus to
interact with the GIS database(s)<


There are GTK and QT bindings in the work, they may be enough.

For other people here: GIS are a niche market, but there's LOT of money and
work in it. So if D starts to be used for it, it can be a very important thing
for D development. 

Bye,
bearophile

Sjoerd van Leent <svanleent gmail.com> writes:

bearophile Wrote:

 Sjoerd van Leent:
I've been looking into D,<


 I suggest D1 running on LDC with Tango.
 
 
but since D doesn't allow me to dynamically change behavior, it most likely
requires a VM.<


 With D you can use plug-ins with DDL (similar to windows DLLs). If you use LDC
it uses LLVM as backend, it's not a real VM like the JavaVM, but it can be used
in several smart ways to generate and run code at runtime anyway.
 


I'm aware of the existence of LLVM and as thus LDC. I should add it onto my
list. Generating machine code on the fly would be practical, and would increase
efficiency.

 
Currently, I've been looking into miniD and Ruby as possible languages that
could do what I want.<


 Beside minD that is written in D, at the moment there are D bindings for
Python (Pyd). Pyd is designed for Phobos, but it may be adapted to Tango with
some work (probably quite less work than writing binding for Ruby. There will
be RuDy, but it's embryonic still
http://tomash.wrug.eu/2009/03/03/rudy-ruby-native-extensions-in-d-progr
mming-language.html ).
 The usage of Pyd is nice, but it may have some scalability problems, so before
using it in production it's better to test it very well.
 


Many colleages prefer the ability to use things like blocks, which Smalltalk
and Ruby support. Although I'd believe that it can be done without, the
gigantic amount of code would be heklpen by things like closures, blocks,
coroutines, and the like.

 
 User application - An application with custom windows, dialogs and menus to
interact with the GIS database(s)<


 There are GTK and QT bindings in the work, they may be enough.
 
 For other people here: GIS are a niche market, but there's LOT of money and
work in it. So if D starts to be used for it, it can be a very important thing
for D development. 


This is exactly the reason why I start the topic. It may take years before
anything comes out of it, but I do believe that D development could use a
practical application for it's own growth.

 
 Bye,
 bearophile

Robert Fraser <fraserofthenight gmail.com> writes:

Sjoerd van Leent wrote:
 User application - An application with custom windows, dialogs and menus to
interact with the GIS database(s)


There are like 20 of these for D, most of which work reasonably well. 
I'd recommend DWT, which is cross-platform, and the newest branch is 
stable on D1+Tango and experimental on D2+Phobos. D1 still gets 
bugfixes; it's definitely not a "dead" language.

Kagamin <spam here.lot> writes:

Sjoerd van Leent Wrote:

 Any ideas...


I would start with search for bottleneck that takes 10 minutes to start.
I don't know what .net/ruby/vm can give you beyond any plugin system.
Integrated compiler is a technique to make compiling seamless, plugging
capabilities are a minor side effect.

BCS <none anon.com> writes:

Hello Kagamin,

 Sjoerd van Leent Wrote:
 
 Any ideas...
 


 start.
 
 I don't know what .net/ruby/vm can give you beyond any plugin system.
 Integrated compiler is a technique to make compiling seamless,
 plugging capabilities are a minor side effect.
 


From what little I know of GIS, it may well be disk IO for the data files. 
so short of a solution like OS type "hibernation" you might not be able to 
speed it up.

Sjoerd van Leent <svanleent gmail.com> writes:

Kagamin Wrote:

 Sjoerd van Leent Wrote:
 
 Any ideas...


 I would start with search for bottleneck that takes 10 minutes to start.
 I don't know what .net/ruby/vm can give you beyond any plugin system.
Integrated compiler is a technique to make compiling seamless, plugging
capabilities are a minor side effect.



I should mention that with GIS systems, databases are big. I remember a few
days ago, that I had a single migration run of data, increasing one of the
databases used by the system by more than 16 Gigabytes. An ordinary database
for a GIS system used for telecom and/or electricity can grow upto Terrabytes.

The startup time isn't dictated by poor design per se, but rather by I/O
slowing it down. I'd imagine that the only solution for this would be full
blown grid computing, but I doubt that the current systems are able to handle
that.

That said, a batch can have the need to be changed on the fly, even when the
software is still busy. Therefore, reloading an entire module, or even a single
class is often not wanted. Batches can take days, even weeks, to complete. You
don't want to halt such a process.

I realize that I should have put this in my original post, but that would make
the post to long. So run a thought over this.