Re: [tsc-devel] Rewrite: Programming language

Taran Lynn | Mon, 25 Sep 2017 18:43:45 UTC

The main problem with using Linux dependency management is that you 
cannot install multiple dependencies.
This can be a problem when working on several projects with different 
version dependencies. If you're using
several other people's projects this can make building them difficult. 
Personally, being able to type
'<whatever> build' and have all dependencies fetched and not have to 
worry about conflicts is nice.

Also, I was coming from a Haskell/ML background when I was thinking of 
error passing and generics. Haskell's
error passing is like go's, except errors are automatically passed up. 
So in psuedocode you would write

x = foo();

instead of
x, err = foo();
if(err != nil) {
     return err;
}

Generics (what we call parametric polymorphism) is also first class and 
much nicer than C++ templates. Still,
I find myself missing templates (mainly due to the STL) when I program 
in C. All in all I do appreciate C++'s
features, as they can save time and effort, even if they are ugly.

That said I don't really mind which language is (unless it's C, then I 
mind), and I'm gonna be busy with college anyway.
I just wanted to clarify where I was coming from on my last post.

On 09/25/2017 10:25 AM, Marvin Gülker wrote:
> Am 25. September 2017 um 07:47 Uhr -0700 schrieb Taran Lynn <…0@g…>:
>> There's a couple of problems I could see with go. Probably #1 is
>> dependency management. [...] However, considering current C/C++
>> dependency management is essentially "have the user manually install
>> the correct software and version" go's dependency management could
>> still be a huge benefit to ease of adoption of TSC.
> The current dependency management has its problems (too recent versions
> required, I accept I have made a big mistake in this regard), but to my
> knowledge is the standard way to do it in C/C++. I have build several
> open-source projects from source over the years, and apart from using a
> different build system (mainly Autotools vs. CMake), this is what is
> normal. If you find TSC's dependency management prohibitive, then you'll
> find most open source projects' dependency management prohibitive.
>
> I don't share this impression. In fact, I have always disliked
> in-language package systems like Ruby's RubyGems or now Rust's Cargo,
> because I think that dependencies should be provided by Linux
> distributions for security reasons. What benefit does a user have from
> having the same library in five versions installed via three different
> package managers on his system?
>
> As a Gentoo user, I like to keep my system slim and have no unnecessary
> cruft on it. I live fine without systemd, pulseaudio, a desktop
> environment and without most graphical programmes. mutt is a great email
> programme, by the way, and I still like mailing lists. Compiling a lot
> of software from source is natural to me, and I like fiddling with
> compilation options. I tell you this to give you an impression of my
> attitude towards computer software in general and what you can expect
> from me.
>
>> The current dependency management system is still experimental
>> https://github.com/golang/dep, and not widely adopted.
>> However, considering current C/C++ dependency management is essentially
>> "have the user manually install
>> the correct software and version" go's dependency management could still be
>> a huge benefit to ease of adoption of TSC.
> However we decide to manage dependencies, I hope that the number of
> dependencies can be cut down. My experiment with Allegro showed that
> integrating C libraries is very easy with Go and does not require
> language binding libraries as I know it from Ruby and D, thus avoiding
> the creation of additional dependencies.
>
>> The error passing can also get tedious, not just to write but also to read
>> as well. This didn't become
>> apparent in the gopong example (allegro seems to leave error conditions
>> undocumented), but
>> become more of on issue on a larger project.
> Go has an idiom in that it returns error conditions via a second return
> value on a public interface (it supports real multiple return values,
> not just parameter returns), thus the problem is not as difficult as in
> C, where the returned value and the error indicator usually mix up
> (except for POSIX functions, which usually use the clumsy `errno'). If
> you feel the need to use exceptions, you can use panic() and recover(),
> as long as you do not expose a panic over a package's public
> interface. By the way, TSC on many places does not use C++'s exceptions,
> because good parts of the code base date back to a time where C++ did
> not have exceptions. Most exceptions have been added after SMC was TSC.
>
> Allegro is a C library. It does not have stack-unwinding exceptions and
> indicates errors by means of the return value. My `gopong' example does
> not check the return values of Allegro's functions, which a real
> programme should do of course. Please do not consider `gopong' anything
> else than a try of mine to combine Go and C in one program, it
> definitely is not good code in any way.
>
> Delete `DejaVuSansMono.ttf' from the build directory and see it
> segfaulting because it does not bother checking the return value of
> al_load_ttf_font().
>
>> The last point is that go lacks templates (a.k.a. generics). This isn't much
>> of a problem though, as arrays
>> and maps are builtin to be generic.
> You are the first person I see who likes C++'s template syntax. I
> personally find it unusable and only refer to it where I cannot work
> around it easily. I actually expect a modern programming language to not
> provide such an awful piece of syntax. Languages without it have been
> going along pretty good as far as I can see as they offer different
> idioms on solving whatever problem is at hand.
>
> Go can accept any type of value by using the empty interface
> `interface{}'. That allows you to build type-agnostic containers or
> functions where you need it. And arrays/slices/maps are already
> type-independent as you mentioned. I very much like that Go has a
> builtin map construct with an unobtrusive syntax.
>
> Greetings
> Marvin
>