On Sat, Dec 06, 2014 at 05:17:25AM +0200, Vlad wrote:
> Hi, Henrik
>
> I think that you nailed a lot of the problems still plaguing Python
> on the head, however OCaml and Modula are a bit obscure and lack the
> extensive libraries that Python brings to the table, moreover a lot
> of people know python, it is used extensively in other distros, and
> it is a relatively easy language to learn, I took a look at OCaml,
> and while it had some very neat features I really don't think that
> it is something that many people would like to learn or use.

the main problems with OCaml as a language:
(1) Although strongly typed, a correct program only very rarely needs
to specify them explicitly. The implementation is amazing in terms
of managing to figure them out. That doesn't sound like a problem,
does it. But when things go wrong the resulting error messages are
completely incomprehensible; you have to figure out why the type
inference went wrong, and tracking it down to your source code mistake
can be very obscure indeed. The language seems to encourage the
typeless look, although, yes, you can specify the explicitly almost
everywhere, and it's a good thing to do.
(2) The syntax is somewhat unconventional. Its operators have
consistent priorities, which leads things to look a little different
from the usual syntax when it comes to function arguments and the like.
But you can *always* use parentheses to make things clear, which is not
the case in some other languages (eg., in C declarators unnecessary
parentheses lead to unexpected function types.)

Of course the real reason for using files written in a so-called
scripting language instead of the object code frm a conventional
conpiler is that you can be certian that the code you are running
indeed does correspond to the source ode you're looking out -- it's the
same file.

So if you want strong typing *and* this kind of assurance as to what
ode is *really* being run, *and* you want to use off-the-shelf tools
almost immediately, there are few alternaties. Typed Racket might be
one; OCaml is another. (I think it interesting, but irrelevant to the
present purpose, that both languages have their ultimate rigins in the
AI community.

> This is of course just a first impression based on a cursory look at
> it, I might be wrong, I am kind of curious about OCaml.

Developing a new language to meet our concerns might be an alternative,
but I wouldn't do it now.

In fact, I wouldn't spend a lot of time right now rewriting what's
currently in Debian, either. The first order of business is to get the
fork to some kind of viablility. We should probably start by
collecting Debian packages that don't depend on systemd.

One approach might be to take a Jessie without a systemd, and get its
package list, and copy them over from Debian.

My Jessie system does not have systemd in it But, alas, it does have
libsystemd0, and when I went into aptitude and asked it to delete is, I
had a few surprises. I never dreamed that bsdutils would depend on it.
Granted, it only predepends on it, whatever that means, but that
initself is, I suppose, already a problem.

The complete list (as aptitude tels me interactively)

bsdutils
acpi-fakekey
cups-demoon
dbus
gnome-session-bin
gnome-system-monitor
libaccountsservices0
libmutter0e
libpolkit-backend-1-0
libpolkit-gobject-1-0
libpulse0
pulseaudio
realmd

Of course, other packages might in turn depend on *these*.

I don't know what half of these do, or whether I need them for
something.

-- hendrik

>
> We should also consider Go and Julia IMO.

I've heard of Go. I haven't heard of Julia.

>
> Oh, and Microsoft is planning to open source and port .NET to Linux, please everybody hold the 'M$ is Cancer' comments for a sec, C# is a pretty decent language for application development, IMO it blows Java out of the water and it might have its uses.

I think that is probably irrelevant. Certianly irrelevant at this
time. Certainly irrelevant if they make .NET depend on systemd.

-- hendrik