I think everyone loves Python because it is such an improvement compared to most scripting languages. But it's so unsuited for writing large- or even medium-scale systems.

@vitaut What makes a system large-scale if not insufficient abstraction?

@dascandy42 Does it mean any system written in python is large-scale?

@vitaut Most "large scale" systems I've seen develop like trudging through waist-high mud. They reimplement the same concept over and over again in different locations.

Python is not typically quite as bad in this. But many C++ code bases, and Java code bases, are. Medium sized C code bases are insufficiently abstracted too. You can open nearly any random C file and find a freshly implemented linked list.

@dascandy42 Just yesterday I removed someone's implementation of a weird set/map in C++ =).

@vitaut How do you make a C++ application that renders images?

You take two libraries, one that loads images and one that renders them. Then you have two image types. At least. Then you create your own, that converts to and from the other two.

And nobody can share the types, since C++'s lingua franca is "set", "string" and "vector". Which beats C but not by much.

@vitaut What about Mercurial?

@dascandy42 If package management was better I would expect some de-facto standard abstractions emerging. But everyone tries to avoid dependencies.

@vitaut
Right; so, is there a scripting language that *is* suited for writing medium-to-large scale systems?

@vitaut Everybody reimplements "image" but nobody creates an abstraction on its own with the purpose of sharing it.

We need to have at least one "lingua franca" C++ library, that defines types for the common real-world things programs concern themselves with.

Package management is taking the horse by the tail. We need to have *types* which live in headers. You don't need a package, you need to share the headers. Like with a git repo with only an include folder.

@edmundv If you mean that it's an example of such system then I don't deny that it's possible to build it. We have a bunch of those and they are a major pain to maintain.

@dougmerritt C/C++

@dascandy42 I envy your imagination.

@dascandy42 @vitaut Templates were the promise of this, but, uh...

Hasn't quite worked out fully, yet.

@vitaut @dougmerritt you two are so cute, the shitposter and the straight man

@ljs @vitaut
We try.

@vitaut trolling fingers try to make me write something sarcastic but i bravely fight against my temptation :-)

@jarkko Don't restrain yourself!

@thephd @vitaut Templates solve the C problem of having to rewrite a vector for each type, a map for each type etc. C++ *does* solve that problem.

This is a different problem.

@dascandy42 @vitaut Well, sort of. That's for "I need a generic type". The other half of templates was "you write this algorithm once, and everyone can opt into it".

The problem is that nobody's writing the proper algorithms for said image data types, so that even if you have 5 image types of varying quality, they can all be piped into the same algorithms.

(This might start changing now that mdspan is here...)

@thephd @vitaut No. You need higher level logical abstractions. An image is not just a mdspan of data; there are other properties and semantics at work.

@dascandy42 @vitaut mdspan has several template parameters that can change access and layout (e.g., you can do something like have a color table added or different sorts of access patterns). I do doubt that anyone would do e.g. direct editing of the quantization tables of a JPEG or directly insert values into a PNG scanline, rather than decode-edit-encode like 99% of most software, though my point was mdspan accomodates a wide variety of image-style data.

@thephd @vitaut It can accommodate the actual data, it cannot hold whether it's sRGB, what gamma value it is encoded as, what the channels even represent...

@dascandy42 @thephd just add another mdspan with metadata

@dascandy42 @thephd @vitaut Come on, it's just image encoding, not one of those really hard software problems like text encoding. :P