Jump to page: 1 2 3
Thread overview
Re-thinking D's modules
Jul 18, 2012
Dejan Lekic
Jul 18, 2012
Paulo Pinto
Jul 18, 2012
Russel Winder
Jul 18, 2012
Paulo Pinto
Jul 18, 2012
Marco Leise
Jul 18, 2012
Paulo Pinto
Jul 20, 2012
Tobias Pankrath
Jul 18, 2012
Dejan Lekic
Jul 21, 2012
Wouter Verhelst
Jul 22, 2012
Russel Winder
Jul 22, 2012
Wouter Verhelst
Jul 21, 2012
Kagamin
Jul 21, 2012
Wouter Verhelst
Jul 21, 2012
Russel Winder
Jul 21, 2012
Kagamin
Jul 18, 2012
Dejan Lekic
Jul 18, 2012
Jacob Carlborg
Orbit (Was: Re-thinking D's modules)
Jul 18, 2012
Nick Sabalausky
Jul 18, 2012
Jacob Carlborg
Jul 18, 2012
Dejan Lekic
Jul 18, 2012
Jacob Carlborg
Jul 18, 2012
bearophile
Jul 18, 2012
Marco Leise
Jul 18, 2012
Paulo Pinto
Jul 18, 2012
Marco Leise
Jul 18, 2012
Paulo Pinto
Jul 19, 2012
foobar
Jul 19, 2012
Jacob Carlborg
Jul 19, 2012
H. S. Teoh
July 18, 2012
There are several places for D module system to improve.
One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion.

Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has.

More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01

Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important.

I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it...

Kind regards

July 18, 2012
On Wednesday, 18 July 2012 at 08:08:21 UTC, Dejan Lekic wrote:
> There are several places for D module system to improve.
> One thing we discussed in the past is the versioning, and as far as I remember, we did not come to any constructive conclusion.
>
> Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has.
>
> More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
>
> Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important.
>
> I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it...
>
> Kind regards

Jigsaw has just been dropped from Java 8.
http://mreinhold.org/blog/late-for-the-train

Still I would say this is so relevant that most current build systems
have versions as first class concept.

For those that don't know .NET, due to the DLL Hell experience, Microsoft
has built version support in the CLR from day 1.

--
Paulo

July 18, 2012
On 2012-07-18 10:08, Dejan Lekic wrote:
> There are several places for D module system to improve.
> One thing we discussed in the past is the versioning, and as far as I
> remember, we did not come to any constructive conclusion.
>
> Java has been criticised often for not having modules. Apparently Java 9
> SE will have them, and in my humble opinion, Java 9 module system is
> going to be far more powerful (or perhaps better word would be USEFUL)
> than what D currently has.
>
> More about Java Jigsaw:
> http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
>
> Why is this better? - Speaking from a (senior) software engineer point
> of view, Java Jigsaw is engineered for large systems where versioning,
> module-dependency, and module-restrictions are very important.
>
> I do not like few things about Jigsaw, but most of the things they plan
> there simply make sense, especially the versioning and
> module-restrictions, which I urge D developers to take a look and come
> up with something similar for D2 or D3... This is extremely useful, and
> will be even more useful once we have shared libraries where we can have
> N different shared libraries that contain the same module, but different
> version of it...
>
> Kind regards
>

Something like: https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

-- 
/Jacob Carlborg


July 18, 2012
Dejan Lekic:

> I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3...

Keep in mind that D language seems designed for its parts to be minimal (this means "the simplest thing that works"), and that the D module system is not yet fully implementing its current simple design.

In past I have asked for those "Entry points" (that it's an unsolved problem in D), and I appreciate those "Exports". The versioning too seems useful.

Bye,
bearophile
July 18, 2012
On Wed, 2012-07-18 at 11:00 +0200, Paulo Pinto wrote:
[…]
> > Java has been criticised often for not having modules.

In the beginning there was WORA which assumed so much that was unrealistic. It's consequence has been that artefact versioning is a complete mess in Java.  OK so the Maven repository and build frameworks like Gradle and Maven are getting close to defeating the problem. Sadly transitive dependencies are still a nightmare.

Of course I have probably violated a Sun/Oracle patent by even mentioning the acronym WORA.

> > Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has.
> >
> > More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01

Assuming that it doesn't get bounced to Java 10. It already got bounced from Java 7 to Java 8 and now Java 8 to Java 9.

> > Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important.
> >
> > I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it...

Isn't the real question why is the same dynamic library linking problem happening again. Has nothing been learned from UNIX shared objects and Windows DLLs?

Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications.

> >
> > Kind regards
> 
> Jigsaw has just been dropped from Java 8. http://mreinhold.org/blog/late-for-the-train

That is because to all intents and purposes Jigsaw is vapourware.  The competition, that the Jigsaw folks are studiously ignoring, is OSGi. I know there are some slight differences in overall aim and goal between the two, but in the end the effect is the same: being able to run different versions of the same artefact on the same JVM in the same application.

> Still I would say this is so relevant that most current build
> systems
> have versions as first class concept.

Certainly Gradle and Maven support this idea very well.  Sadly Make, CMake, Autotools, SCons, Waf,… tend to delegate the problem to someone else.

> For those that don't know .NET, due to the DLL Hell experience,
> Microsoft
> has built version support in the CLR from day 1.

But, as ever, Microsoft see things like this as a way to try and get everyone to use Windows via proprietary lock-in rather than by trying to educate people about possible solutions. Otherwise we would already have solved the problem rather than have the shared object mess we currently have, OSGi, Jigsaw, the mess that is Debian and Fedora support for multiple versions of dynamically linked libraries and Java artefacts.

Sadly I have nothing constructive to say except that which stems from the above: in a large system comprising subsystems with transitive dependencies, if I cannot use different versions of the same subsystem in the overall system then everything will break. Especially in the face of dependency injection.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


July 18, 2012
Am Wed, 18 Jul 2012 10:08:19 +0200
schrieb "Dejan Lekic" <dejan.lekic@gmail.com>:

> There are several places for D module system to improve.
> One thing we discussed in the past is the versioning, and as far
> as I remember, we did not come to any constructive conclusion.
> 
> Java has been criticised often for not having modules. Apparently Java 9 SE will have them, and in my humble opinion, Java 9 module system is going to be far more powerful (or perhaps better word would be USEFUL) than what D currently has.
> 
> More about Java Jigsaw: http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
> 
> Why is this better? - Speaking from a (senior) software engineer point of view, Java Jigsaw is engineered for large systems where versioning, module-dependency, and module-restrictions are very important.
> 
> I do not like few things about Jigsaw, but most of the things they plan there simply make sense, especially the versioning and module-restrictions, which I urge D developers to take a look and come up with something similar for D2 or D3... This is extremely useful, and will be even more useful once we have shared libraries where we can have N different shared libraries that contain the same module, but different version of it...
> 
> Kind regards
> 

Shared library versioning and dependency management is traditionally done at the OS level (WinSxS, soname, package managers). That may also apply to what is exported aka visible from a library aka module (e.g. export-all policy). Unlike byte code languages like Java or C#, native compiled languages must also consider the target platform in addition to the module version. In addition to this, the scope of a Java module can be anything, up to a complete tomcat web server, whereas the scope of a D module is a single file. A Java module can contain several packages, a D module cannot.

The main difference is in the eco system, in my opinion. Java or .NET are platforms on their own while systems languages integrate with the hardware and OS (starting with calling conventions, up to high-level dependency management). Java is free to innovate here, it is 'their' platform.

Maybe you can elaborate a bit more on what module-restrictions are useful for. I think they are the only feature that I haven't seen in package managers or programming languages. Also the compiler doesn't currently scan shared libraries or even require them to exist. The resolution of symbols is deferred to the linking stage where there are existing mechanisms to hide symbols from a library. And some people like the export-all policy with no hidden symbols, so we are in for a hot discussion on details. :D

P.S.: I am all for a D package manager for developers, that can pull source code and bindings from the web.

-- 
Marco

July 18, 2012
On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote:
> […]
> Isn't the real question why is the same dynamic library linking problem
> happening again. Has nothing been learned from UNIX shared objects and
> Windows DLLs?
>
> Go solves the problem by refusing all notion of dynamic linking and
> insisting on static linking of all applications.
>

As I already mentioned a few times in Gonuts, static linking makes
it hard to implement certain types of applications.

Plus, the Go folks seem to live in open source land, where the code
for all 3rd party libraries is available, and no one has any issues
with licenses that forbade static linking.

Their attitude to keep versioning out of "go get" is a reflection of this.

>> For those that don't know .NET, due to the DLL Hell experience, Microsoft
>> has built version support in the CLR from day 1.
>
> But, as ever, Microsoft see things like this as a way to try and get
> everyone to use Windows via proprietary lock-in rather than by trying to
> educate people about possible solutions.

To be fair to Microsoft, I am yet to see a commercial vendor that
does not do that.

The ones that do, usually have some consulting agenda, certifications,
whatever, to sell along their "free and standard" solution.


--
Paulo
July 18, 2012
>
> Jigsaw has just been dropped from Java 8.
> http://mreinhold.org/blog/late-for-the-train

Erm, read my original post - I did not mention Java 8, i wrote "Java 9 SE"...
July 18, 2012
On Wednesday, 18 July 2012 at 09:43:09 UTC, Marco Leise wrote:
> [..]
> Unlike byte code languages like Java or C#, native compiled languages must also consider the target platform in addition to the module version. [...]

Last time I checked, I could compile Java and C# to native code if I wished to do so.

--
Paulo
July 18, 2012
Am Wed, 18 Jul 2012 10:24:36 +0100
schrieb Russel Winder <russel@winder.org.uk>:

> Go solves the problem by refusing all notion of dynamic linking and insisting on static linking of all applications.

... not possible? While I learned a while back that system calls exist and are not dynamically linked, I wonder how Go goes about:

* basic system libraries (static linking to kernel32.dll?)
* executable bloat from large OO toolkits like Qt
* increased memory footprint by not allowing shared instances of DLLs/SOs
* modular development (e.g. separating "server" and "client" code in games)
* dynamically loadable plugins/extensions
* security and bug fixes to libraries used in dozens of programs
  (-> recompile of all library users ?)

-- 
Marco


« First   ‹ Prev
1 2 3