Re: Re: [tsc-devel] Rewrite: Programming language

Marvin Gülker | Sat, 07 Oct 2017 09:11:11 UTC

Am 06. October 2017 um 15:34 Uhr -0500 schrieb Ryan Gonzalez <…9@g…>:
> Ah wait, are we implementing an OpenGL rendering engine? I thought we
> were going to use SFML or another drawing library again... ¯\_(ツ)_/¯

FYI, TSC currently does use its own OpenGL-based rendering engine. SFML
is used for text output, input handling, audio output and interaction
with the window manager. Rendering is done by custom OpenGL2 code.

> True, but C is treated as less of a transpilation target (as with
> CoffeeScript) and more of a high-level assembler. It also makes the
> code really easy to cross-compile (I've built Windows binaries before
> using only just the C cross-compiler, and everything else kind of
> "just worked"). I do understand your concerns, though.

I've cross-compiled C software many times over to Windows, and likewise
C++ software. There isn't much of a difference between the two
languages; the real problem in crosscompilation are the dependencies, or
more specifically, the dependencies' build systems. MXE[1] has done great
work in this regard.

If C++ would only address these issues:

- Away with #include. The numerous times where I have fought against
  macros from one library conflicting with macros from other libraries are
  countless. X11 defining a macro named "None" especially has given me
  headaches again and again, including with TSC.
- Away with header files. The duplicated work is error-prone.
- Make string literals Unicode by default and have string functions work
  on characters rather than bytes. Or at least introduce a unicode
  string type that does this.
- Make the template syntax readable. Allow templates in implementation
  files. Have template errors generate useful error messages instead of
  four screen pages full of template resolution due to a typo.
- Massively enrich the standard library with useful tools rather than
  yet-another-container for some very specific use case that requires
  one nanosecond more of performance. C++ is prone to drawing
  dependencies in, which can be seen nicely on TSC's current state.
- Especially, abstract over the encoding of path names (this is what my
  Pathie C++ library[2] does). UTF-16LE on Windows vs. UTF-8 on Linux.
  I want MSVC's nonstandard fstream constructor[3] on wchar_t* to be
  standardized and work on any platform path encoding!

Instead, the C++ committee forces type inference into the language more
and more, which is a feature I don't see as that useful. The main use I
have for the `auto' keyword is shortening iterator declarations, which
should have rather been fixed by sanitising the iterator syntax rather
than working around its ugliness.

My ideal C++ is D I think. It addresses all of the points above. But D
has a platform support issue on Windows if you come from the free
software movement and thus reject working with MSVC. The hard dependency
on MSVC's linker makes it unusable for me, who generally works with
MSYS2/MinGW when targetting Windows. I was pleased to see Go work with
MinGW flawlessly. I talked to the LDC folks and they plan on using
LLVM's linker instead, but the priority on the topic is too low to be
addressed anytime soon. If we dropped Windows support from TSC (or
someone volunteers to do the Windows work with MSVC), I still think D is
a viable alternative. Is D more pleasant to you than Go?

I want you to participate in TSC with fun, and since you have expressly
stated that you dislike Go, let's forego that for TSC's main corpus. I
on the other hand can't see me using a transpiled language. C++ is the
obvious compromise candidate then, but if we decide to drop Windows
support or give it to someone who actively uses MSVC, D may be another
choice.

If we go with C++, I suggest we should use modern C++. TSC currently
especially does not make use of std::unique_ptr and std::shared_ptr
(simply because they weren't around when it was developed
originally). Newer than C++14 is going to give us compiler support
problems, so we should stick to that. Ubuntu 16.04 LTS ships with GCC
5.3.1[4], which supports C++14 completely it appears[5].

By the way, the Go developers appearently consider adding generics[6].

> That being said, for the sake of my CPU, please don't make TSC an
> Electron app...

You have my word that this will not happen. Packaging a web browser in a
desktop application results in bloatware at its best.

Marvin

[1]: http://mxe.cc/
[2]: https://www.guelkerdev.de/projects/pathie/
[3]: https://msdn.microsoft.com/library/8473817e-42a4-430b-82b8-b476c86bcf8a.aspx#basic_fstream__basic_fstream
     (3rd constructor of std::fstream; MinGW GCC does not have it).
[4]: https://packages.ubuntu.com/search?keywords=g%2B%2B&searchon=names&suite=xenial&section=all
[5]: http://en.cppreference.com/w/cpp/compiler_support#C.2B.2B14_features
[6]: https://golang.org/doc/faq#generics

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F