You are not logged in.

This website is a static copy. You cannot log in or post messages.

Developer Discussion

Re: Rewrite: Programming language

25th of September, 2017 18:43

Re: [tsc-devel] Rewrite: Programming language

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 <taranlynn0@xxxxxxx>:
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, 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