What is your favorite/ least favorite Programming language?

[fluffrabbit]

Go doesn't allow circular dependencies. But, like, HELLO

Haven't they ever heard of include guards, #include once, #pragma once, etc.

[Lyberta]

Only shit languages need these things and C++ fixed those with modules.

[fluffrabbit]

I fail to see a case where interdependent dependencies would not happen, and I also fail to see the relevance of next year's tech.

[drummyfish]

I thought Go was supposed to be something like new C because it is quite largely influenced by it, its creators share the dislike of C++ and one of them is Ken Thompson (these are all thing I've only read at Wikipedia though, I practically haven't seen the language).

[fluffrabbit]

Combine lots of curly braces with novel keywords like "slice" and a garbage collector, and you've basically got Go. Java was also trying to be the new C, so maybe Go is the new Java.

[DrAltaica]

MY favorite language is Multi User Forth. Though I haven't found a OO package for forth that I like so that's the only downside. Followed closely by Perl5, I've never had any trouble reading Perl5 code and if a come across something I don't already know it's obvious to me what to look up. My least favorite in C++ because there 1000 options that people can use to write programs and you need to know to understand a random program to come across and you can't google it..

{l Code}: {l Select All Code}

template<typename T>
bool from_string( const char* Str, T & Dest )
{
    // créer un flux à partir de la chaîne donnée
    std::istringstream iss( Str );
    // tenter la conversion vers Dest
    return iss >> Dest != 0;
}

which gives this on any modren compiler:
ler.h(91): error C2678: binary '!=': no operator found which takes a left-hand operand of type 'std::basic_istream<char,std::char_traits<char>>' (or there is no acceptable conversion)

How do you look that up?

[fluffrabbit]

That is some really ugly code, and it doesn't make a whole lot of sense to have a from_anything function. Functions are supposed to be input to output, not the other way around. I call it bad programming. Not that C++ is a perfect language or anything, but like JavaScript it allows for bad programmers to use it. Why discriminate?

template<typename T> means that T is a duck type. & means that T is a reference that can be modified as if it were a pointer (a bad practice but whatever).

So, from_string takes in character pointer Str and variadic reference Dest. It returns if iss >> Dest. != 0 is unnecessary because nonzero is true.

It creates a string stream from Str and "streams" it into Dest, returning whether or not it was successful. Personally, I would not separate that into a function as it thinly wraps the stream functionality that C++ comes with.

[dulsi]

@fluffrabbit: Examples of this nature are always going to be short and not very useful. DrAltaica's point is about the documentation.

@DrAltaica: I would search for istream from that I can tell that >> returns an istream. I assume what you are trying to do is determine if it succeeded. Unfortunately C++ doesn't provide that with istream. If the string "abc" and you try to read an int, you get 0 in the int and no indication that a letter was found. I find the cppreference.com and other sites to be pretty good as documenting C++. But if you don't like the language that is fine. I personally do not generally use the stream classes because I don't like the API.

[fluffrabbit]

I care so little for C++ streams that I did not check the docs for that. Good find! I guess DrAltaica found this in a project somewhere, tried to compile it, and it failed without explanation because GCC doesn't always do a great job of explaining things. Try Clang (in this case clang++) instead of g++ or $(CXX) or whatever.

[Lyberta]

My main language is C++ and I fully agree that iostreams in C++ are shit. I'm writing a proposal for better streams though. Those are binary ones, Unicode streams will come later.

[DrAltaica]

returning whether or not it was successful.

How do you know that? >> returns a ostream which I can't find anything on what number is evals to.

[DrAltaica]

ithout explanation because GCC doesn't always do a great joI care so little for C++ streams that I did not check the docs for that. Good find! I guess DrAltaica found this in a project somewhere, tried to compile it, and it failed wb of explaining things. Try Clang (in this case clang++) instead of g++ or $(CXX) or whatever.

ACtually It was Visual C

[fluffrabbit]

returning whether or not it was successful.

How do you know that? >> returns a ostream which I can't find anything on what number is evals to.

I know that because there is no other reason to return a bool from that function. The output was supposed to be a success code, properly written or not.

[fluffrabbit]

@Lyberta

C++ has text streams for a long time

Should be "C++ has had text streams for a long time"

The API still works in terms of char which means reinterpret_cast if you use std::byte in your code base.

I know reinterpret_cast is the C++ way, but a lot of people (correctly or not) use C-style casts, which have slightly higher computational complexity but take up less space on the line.

If you want to do IO in memory, you're stuck with string streams that operate using std::string. Most binary data is stored in std::vector which leads to awful performance due to unnecessary copies.

That is interesting. I try to use a chunk of memory when loading binary data from files, be it std::string or C-style allocation. I didn't know about the performance issues with std::vector. I always imagined that internally, std::vector calls realloc or something to expand its memory block, and beyond that it just casts chunks of data to a type. That's how I would do it. But yeah, I would like to see this change.

There is no agreed standard for customization points for binary IO.

What do you mean by customization points?

This is a very long document, longer than many an API feature RFC. All that explanation for a very simple feature: streaming stuff into bytes and dealing with the data properly. I hope somebody is excited enough about the C++ standard to read the whole thing and talk about it with the standards committee.

[Lyberta]

C++ has text streams for a long time

Should be "C++ has had text streams for a long time"

Umm, not sure, link to grammar explanation?

I know reinterpret_cast is the C++ way, but a lot of people (correctly or not) use C-style casts, which have slightly higher computational complexity but take up less space on the line.

People are free to shoot themselves in the foot, no kind of proposal for C++ will fix that.

If you want to do IO in memory, you're stuck with string streams that operate using std::string. Most binary data is stored in std::vector which leads to awful performance due to unnecessary copies.

That is interesting. I try to use a chunk of memory when loading binary data from files, be it std::string or C-style allocation. I didn't know about the performance issues with std::vector. I always imagined that internally, std::vector calls realloc or something to expand its memory block, and beyond that it just casts chunks of data to a type. That's how I would do it. But yeah, I would like to see this change.

Legacy text streams are pretty much hardcoded to std::string. So if you have std::vector, first you need to copy bytes from std::vector to std::string and then move that std::string into the stream. That obviously takes time. Same thing in reverse if you want to assemble network packet in memory.

There is no agreed standard for customization points for binary IO.

What do you mean by customization points?

See this. Customization points have been officially added to standard library in C++20 but you could write your own ones before. Now, the most famous one is std::ranges::begin which acts as a better version of std::begin. There is also related term "niebloid", you can see a bunch of them here. I'm still not sure what is the difference between niebloid and customization point.

In my proposal you can see that I propose std::io::read and std::io::write as new standard customization points for binary IO.

This is a very long document, longer than many an API feature RFC. All that explanation for a very simple feature: streaming stuff into bytes and dealing with the data properly. I hope somebody is excited enough about the C++ standard to read the whole thing and talk about it with the standards committee.

Niall Douglas who is the head of experimental IO group and author of LLFIO has reviewed my proposal twice and says that it is one of the possible alternatives and he can present it to WG21. So far so good.

[fluffrabbit]

Umm, not sure, link to grammar explanation?

Source: I'm an American. "has" is present-tense. Because the present has no dimension, you don't use the present tense with "for a long time", you generally qualify it with a past-tense or future-tense part, such as "C++ will continue to have text streams for a long time".

People are free to shoot themselves in the foot, no kind of proposal for C++ will fix that.

Many a programmer uses C-style casts because it's popular. Clang-tidy warns against C-style casts and reinterpret_cast equally. I have actually gone to the length of nesting two static_casts just to make clang-tidy shut up.

Legacy text streams are pretty much hardcoded to std::string. So if you have std::vector, first you need to copy bytes from std::vector to std::string and then move that std::string into the stream. That obviously takes time. Same thing in reverse if you want to assemble network packet in memory.

And my brain is now in power-saving mode. I'll take your word for it, whatever you just said.

[GunChleoc]

There is also related term "niebloid", you can see a bunch of them here. I'm still not sure what is the difference between niebloid and customization point.

I found this definition - looks like a CPO is a restricted subcategory of niebloid:

Any callable, constexpr-constructible object is colloquially known as a “niebloid,” in honor of Eric Niebler. A CPO is simply a niebloid that wraps a user-definable customization point.

Source: https://quuxplusone.github.io/blog/2019 ... onyms/#cpo

Niall Douglas who is the head of experimental IO group and author of LLFIO has reviewed my proposal twice and says that it is one of the possible alternatives and he can present it to WG21. So far so good.

Congratulations on getting that far! Having more efficient streams will certainly be a good thing

[Julius]

https://jonathanwhiting.com/writing/blog/games_in_c/

Although I think this guy isn't aware of all the work being done with idtech engines which are mostly written in plain C AFAIK.

[Lyberta]

So.......?

I mean people who don't see more than 2 feet away are free to love C. But when I was learning C++ I had a horrible book that didn't teach me standard library so I was writing "C with classes". So I had something like std::vector except it was just raw pointer and size. Sure, it is kinda easy to see how it works but working with it is so hard. I can't imagine what kind of insane code would be to replicate, say, std::map in C. In C++ we have all that insanity hidden in the standard library while in C you *have* to suffer because language is so *simple*....

Also, even as of C18, integers are still not two's complement... Yeah... Well, at least there is no overloading so there is no way to mix up types, but... Yeah, C and C++ are very different. I would really like C++ to ditch C standard library and just start fresh.

[Pesciodyphus]

My favourite programming language is C, as almost everything important is written in it, and almost everything can be done with it.
My second favourite programming language is Assembly, because everything can be done with it, and it is often combined with C in professional software.
My third favourite programming language is BASIC, because I learned programming with GW-BASIC.

My least favourite programming language is Java, because it is a) overrated and b) has the stupid design descision to make everything object oriented, even things, there this doesn't make sence at all (like system.out.printnl() )
My second least favourite programming language is C++, because it want's explicit pointer conversion. This is supposed to prevent harmful mistakes, but instead causes more harmful mistakes. Converting pointers into each other is often safe and desired. Converting between integers and pointers is often harmful. In C++ it is very easy to forget a asterisk in the typecast and convert between pointers and integers. If you convert void* to int instead of int* in C you get a warning. If you do that in C++ you need to cast to int*, and my accidently cast to int.