At any rate I believe this modular / one domain at a time and
layered approach would be the correct one, and setting
priorities. Then we'd have to eventually start sooner than later
filling out implementations, because the optimal previous design
time is sadly always less than infinite. :o) The
On Wednesday, 15 April 2015 at 16:19:07 UTC, CraigDillabaugh
wrote:
For Satellite image processing at least GDAL can take care of
most of the memory/image handling stuff. I have some D Bindings
(largely untested).
Maybe a good idea would be to collect bindings for a single
domain (like image
On Wednesday, 15 April 2015 at 15:49:10 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 15 April 2015 at 15:36:44 UTC, XavierAP wrote:
That looks like good architecture. I'm not sure if 2 and 3
wouldn't be at the same level of (non-) dependency? Or maybe
it's the image processing example you've u
On Wednesday, 15 April 2015 at 15:36:44 UTC, XavierAP wrote:
That looks like good architecture. I'm not sure if 2 and 3
wouldn't be at the same level of (non-) dependency? Or maybe
it's the image processing example you've used. In any case 2
would have more priority because of practical reasons
So many good ideas and points posted. Something should come out
after this discussion...
On Wednesday, 15 April 2015 at 14:07:11 UTC, Ola Fosheim Grøstad
wrote:
I think maybe a modular approach is better, to have different
profiles:
1. foundational libraries (basic types)
2. architecture re
On Wednesday, 15 April 2015 at 14:03:13 UTC, Tobias Pankrath
wrote:
No. We were talking about parts of e.g. the python standard
library that have been completely superseded by third party
solutions at least for new projects.
Well, that has not happend. What has happend is that people use a
mi
On Wednesday, 15 April 2015 at 14:01:54 UTC, XavierAP wrote:
That list is small compared to the whole of available Python
libraries, but what you can do with it is already enormously
more than you can do with Phobos or CRT+STL. If D had half of
it people would be using it...
Yes, it is the st
On Wednesday, 15 April 2015 at 13:40:36 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 15 April 2015 at 13:18:55 UTC, Panke wrote:
There will always be a better solution in the future than the
implementation included in the standard library today. However
that is no argument against the kitchen
On Wednesday, 15 April 2015 at 13:19:32 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 15 April 2015 at 13:06:26 UTC, weaselcat wrote:
See: python, many people actively avoid using the standard
library in favor of third party libraries that accomplish the
same task.
Some third party libaries a
On Wednesday, 15 April 2015 at 13:18:55 UTC, Panke wrote:
There will always be a better solution in the future than the
implementation included in the standard library today. However
that is no argument against the kitchen sink.
That's dodging the foundational issue which is that different
ap
The problem with a kitchen sink approach is that you have to
make sure the libraries stay up to date - and phobos already
has a few rotting modules.
Which modules do you mean? There are some modules that are
considered to have a bad design or lacking implementation, but
none that do not wor
On Wednesday, 15 April 2015 at 13:06:26 UTC, weaselcat wrote:
See: python, many people actively avoid using the standard
library in favor of third party libraries that accomplish the
same task.
Some third party libaries are considered defacto standard and are
shipped with distributions or eve
On Wednesday, 15 April 2015 at 12:36:16 UTC, Rikki Cattermole
wrote:
Nope. Good API isn't good enough. For things like window
creation, image library ext. If they ain't in phobos, it ain't
gonna get used.
That's my experience with Devisualization anyway.
Go, Dart, Python and Javascript are go
On Wednesday, 15 April 2015 at 09:57:29 UTC, John Colvin wrote:
On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
Nowadays a standard library should include classes or
functions, not only for data structures, algorithms etc., but
also for: GUI cross-platform creation, graphics,
mult
On Wednesday, 15 April 2015 at 12:00:54 UTC, Ola Fosheim Grøstad
wrote:
clip
Yes, there is a lot of overlap in the D community: 4 D compiler
projects, a bunch of IDE projects, a bunch of GUI library
projects, a bunch of (basic) game engine projects... All rather
large in scope if you want to
On 16/04/2015 12:00 a.m., "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
On Wednesday, 15 April 2015 at 11:45:37 UTC, XavierAP wrote:
I understand such a library collection would have many holes right
now, but movement also creates its own momentum. I just think it would
be good that dlang.org p
Exactly, and with the overlapping efforts the result is less than
the division among the parts, because none of them reach critical
mass.
But this has already been kind of done in the past regarding
Tango vs. Phobos. I think it would be good to extend the same
guidance to a gradually growing
On Wednesday, 15 April 2015 at 11:45:37 UTC, XavierAP wrote:
I understand such a library collection would have many holes
right now, but movement also creates its own momentum. I just
think it would be good that dlang.org provided some more
guidance.
Yes, there is a lot of overlap in the D co
I understand such a library collection would have many holes
right now, but movement also creates its own momentum. I just
think it would be good that dlang.org provided some more guidance.
I don't know, I hope to get some time on lazy Sundays to finally
read Alexandrescu's book which I bought
On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
also for: GUI cross-platform creation, graphics,
multi-threading at low and high level, SQL, XML, JSON,
networking on all layers from raw sockets to TPC and HTTP, FTP,
etc... etc.; and since the reason for native is performance, I
wo
On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
Otherwise try to convince a _business_ guy that switching to D
will have any significant advantage (he will implicitly expect
you to "prove it in advance"). These all-in-one solution
standard libraries are in my opinion the main reaso
On Wednesday, 15 April 2015 at 09:39:09 UTC, XavierAP wrote:
Nowadays a standard library should include classes or
functions, not only for data structures, algorithms etc., but
also for: GUI cross-platform creation, graphics,
multi-threading at low and high level, SQL, XML, JSON,
networking on
Hi people. I've followed D for many years, although I haven't
used it for anything big or even have a good knowledge of Phobos.
I currently work in C++ a lot, although I am convinced that in
theory the only reason not to run away from C++ is being tied
down to a large existing codebase; and yet
23 matches
Mail list logo
