jdrek1

Fair enough, I can see that this is something which can easily throw you off if it isn't part of your normal workflow.

Honest question, why? If you properly format your code then it's indented anyway so Python is basically just replacing `{` with `:` and then not having a `}`. Python is the least problematic of all the languages enforcing some style things. Go insisting on Google's stupid styleguide is just dumb, Lisp having the parentheses on the wrong positions and ignoring the fact that there is more than one bracket type available is dumb, all the languages with `END` blocks are dumb because `{ ... }` is much shorter and cleaner, ... . Python has its annoyances too but indentation really isn't a problem - it's there already anyway.

Copy initialization does not mean that the copy constructor is called. It is the correct term for an expression `T a = ...;`, which can often result in the copy constructor being called but does not have to. In this case it's mandatory copy elision from a prvalue, which leads to only one constructor being called.

You should absolutely not use or recommend that site. It's stuck on incomplete C++14 at best and also contains some pretty bad code. learncpp.com is a much better tutorial and cppreference.com is a much better reference. The only thing cplusplus.com is good at is polluting search results.

You could also use VS Code's remote (over SSH) ability.

I recommend using the American keyboard layout if you're doing anything remotely programming related, otherwise all the special characters are just way too annoying (even though personally there's also a few of those in the American layout that are suboptimal, but a keyboard only has so much space...).

If you frequently find yourself needing German (or other European) symbols like ä then you can also look into using EurKEY [1] which is basically the American layout but gives you easy access to the "umlauts".

[1] https://eurkey.steffen.bruentjen.eu/

> electronvolts (10⁻¹⁹ J) in nuclear physics

CERN is at TeV ranges so yes, even in different units we use high prefixes. Might not come up in your every day small talk but they are used.

> (Edit, that's not possible in c++)

Mind expanding on that? Because what that readme there shows is absolutely possible in C++, I have used a similar system for dealing with natural units.

Ups, yes. I had it switched originally but then for some reason switched it again. Apparently commenting late at night is not a good idea.

Correlation != causation

Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one.

For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors and people just went with it. The people earning more are doing so because those are the seniors who have given up on common sense and just go with the flow of the masses who are unable to grasp "tabs for indentation, spaces for alignment" yet insist on keeping alignment so the (terrible) compromise is just using spaces. And I strongly question whether "alignment" is worth anything, in almost all cases it's just useless and in the rest you're drawing ASCII diagrams in the comments which doesn't affect your code at all.

Also see the top answer at https://www.reddit.com/r/programming/comments/8tyg4l/why_do_...

Just use uBO like everyone else, there's not a single ad on that page visible for me.

Shared ownership is a rare case, so in general using shared_ptr should already raise some suspicion. And in this case there is no reason any of the shared_ptr'ed things in the code need to be on the heap so no reason to even have a pointer in the first place.

Code like this is effectively what you get when you have someone that doesn't know how to write C++ but writes it anyway and uses pointers everywhere because they either read that C++ is pointer heavy (it's not) or have learned C++ through some course that is actually a course on algorithms and only uses C"++" as example language and is hence at best showing shitty C with iostream and classes straight out the 1980s. Then those people find the (correct) advice of using smart pointers instead of (owning!!!) raw pointers and just put shared_ptr everywhere without thinking about if there actually is a shared ownership to be expressed and/or if the heap allocation is even needed.

That may be true but uMatrix' UX is unmatched - the matrix UI allows for granular control while achieving the same in uBO is significantly harder.

Scientific simulations. Meson as the build system, vcpkg as package manager.

Also using it for hobby projects like a custom shell. Modern C++ is a great language and while I'm also using other languages like Rust for hobby projects I still feel the most comfortable writing C++.

Have you considered that people might actually like that syntax style? Also there's a massive benefit to familiarity, you can easily read code in most languages without knowing them because they look similar. There's a reason most people don't like to write (((((((((lisp)))))))). There's nothing wrong with exploring new things but right now all you do is ranting about the syntax without giving any examples of things that are "bad" and honestly it makes you sound a bit like one of those designers redesigning everything just for the sake of redesigning.

> And even ; to end the line.

Why do people even hate ; ? It gives you better error messages and it's no different from using . to end a sentence in spoken languages.

> Use Whitespace

When you make whitespace important the only thing you gain is that it forces people to format their code (see Python) but it also often leads to idiotic decisions (e.g. Nim not allowing tabs which are simply superior to spaces, there is literally not one reason to ever indent with spaces). C++ and co have the right idea, the only thing whitespace should do is separate tokens then people can format the code as they see fit.

> Try unicode glyphs for different syntactic functions

Now sure Unicode stuff can make things more readable in some cases but the big problem of Unicode is how you input those things. Your keyboard is basically ASCII, that leaves you with some workarounds like ALT codes or Julia's LaTeX conversion stuff. And those things are not supported on every platform/editor. Not to mention that for some things you need to install a new font or whatever.

> try to approximate natural language

What would you like to see? I don't see what you'd gain from that except mostly making things more verbose. Spoken languages are quite different from programming languages. As soon as you have a large block of instructions (aka a program) you naturally resort to some kind of structuring (e.g. making a list that someone else has to check from the top) and that will pretty much look like pseudo code already. Sure you'd do something like `list.add(foo)` instead of "Add foo to the list" but that's just because the former is much easier to parse and encode into rules for the computer.

- Subnautica

- The Talos Principle

- Portal (1/2)

> arbitrary file I/O. I can take my compile time data and write a python script to put it in a std::array, but I shouldn’t have to.

There's a proposal for that https://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1040r6...

> non-fixed-sized containers, ie vector

You can already use them in a constexpr context, you just can't leave it yet. So creating a vector on compile time and then using it on runtime is sadly not working right now but I think that's being worked on as well.

Final Fantasy Tactics Advanced like game but with a procedurally generated infinite map and some sort of re-skilling mechanic so that you don't have to constantly swap jobs before leveling just to minmax the early game where you don't have access to all jobs yet. Also adding co-op multiplayer so one can play with friends.

> you're wasting too much time on looting.

But that's the most fun part of Apex ;)

The problem is they only need to win once. What we really need is an immutable section in the EU constitution that anyone who tries to take away basic privacy rights like this is immediately tried for crimes against humanity and sent to prison for the rest of their lives.

Nobody said it's impossible, it's just generally not an issue if you write normal code (read: stop treating C++ as C, they are completely different languages). There's only very little difference in how much you need to think about lifetimes and stuff between Rust and modern C++, it's far from being "hard". Sure Rust holds your hands a bit more in those regards but you can also just turn on address sanitizer and friends and then you have a very similar experience.

Practice, lots of practice. Doesn't really matter what kind of program you write as long as you write code. Can be assignments from your university, can be online puzzles like advent of code, can be a program that sends you reminders to kiss your wife, can be the 984397594th minecraft clone, or whatever else you want. Basically if you have a problem that can be solved by coding, do that.

Unless you're manually implementing data structures or something similar you basically never need to manage your memory manually in modern C++. std::vector takes care of most your needs and smart pointers exist for the few cases where it doesn't. There's not really a lot of difference to Rust there except that OOB access is a panic in Rust and (most likely) a segfault in C++ but you can trivially enable that checking by putting the STL in debug mode.

C++'s problem is that most people never learn it properly and think "C/C++" is a thing because most courses/tutorials are stuck in the 90s and effectively teach shitty C with classes and iostream. Rust is great and has really nice features which I'd like to have in C++ too (like pattern matching) but memory safety is really not an issue in proper modern C++. I'm aware that this is a bit of a "you're just holding it wrong" but pretty much all languages have things you shouldn't do anymore once they evolve, it's just more obvious in the one with strong backwards compatibility requirements to the ancient language created before all the modern research into language design.

Works perfectly fine for me on FF with uBO and all scripts blocked. Apparently that "Sorry, ..." comes from a cookie popup which I don't even see so seems like you need stronger blocking in your browser.

> That isn't true, you need parentheses for procs with no arguments, else it's interpreted as a proc pointer. Try `echo` vs `echo()`.

My bad, I meant 0 argument member functions (or rather 0 additional argument functions, apart from the this pointer). So `foo: Foo` and then `i = foo.len()` directly shows me that I'm calling a function, `i = foo.len` looks like I just access a member variable. len is obviously not the best example but I still don't think hiding the fact that a function is being called is a good idea at all.

> It's used for declaring variables of an object. `type Foo = object` and `var foo: Foo`.

Good point, I didn't consider that. So far never came up in my code but I can see that it sometimes can be useful to do something like that.

> So it's not uncommon or weird. Just programming languages are overly restrictive.

Natural languages have been case sensitive long before programming languages existed. Again, I'm not saying it's a bad feature - on the contrary, definitely appealing in some case - it's just not what we're used to and hence a bit "weird".

I'll admit that it's much easier in languages that are not whitespace sensitive but imho it's not an unsolvable problem for the ones that are and software from 50 years ago not handling things correctly is not an argument if you ask me. I know it bothers me more than it probably should and likely more than the average person but at the end of the day such things have an influence on people. Everyone has some things they just prefer and imo forcing everyone to use one specific style is always a worse solution than using tools like code formatters and letting people have their way.

> That's one part of it, yes. I include UFCS in that as well.

Oh yeah, UFCS is pretty nice. Though I don't like the extra step Nim takes of dropping parentheses for 0 argument functions, I'd very much like to see if I'm calling a function or not. Sure for things like the size of an array it doesn't really matter but the call could be expensive. This is mostly for reading code though, obviously in my own code I'd never drop them.

> Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.

I'd argue that it's still weird because the first letter is still case sensitive and I"m coming from a case sensitive language but being able to use foreign code in your own style is very appealing. I can't think of any good reason why anyone would deliberately have two different functions with the same name in different cases anyway, the closest example I can think of would be T and t for temperature and time but you can also just type those words out, more expressive anyway.

Exactly, as long as it's readable and consistent I don't care what style other people write their code in, all I ask is that they and the compiler give me the same freedom and Nim and Go don't do that.

> It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code.

I assume you're talking about the partial case insensitivity of Nim? I find that a bit weird tbh but I can see the appeal, you no longer would have things like a dependency doing weird things like all caps function names and forcing you to have that in your code.

Guido van Rossum also seems to prefer tabs but was held back by the community [1]. But even if he changed his mind since then those reasons are incredibly weak if you ask me, they basically boil down to "some software 50 years ago was pure shit" and that's not a valid reason. Tabs are simply the superior/right tool for indentation. You might want to see a tab 8 chars wide and I want 4 but we both see the loop body indented one level. With spaces enforced one of us would not see the code as they'd like it to be and while that might seem like pure preference on surface the simple truth is that preferences matter (see the recent thread about the ideal font for reading speed - it's different for everyone) and tabs provide the freedom while spaces don't. And in some cases they matter even more, for example I've worked with someone who was visually impaired and pretty much needed a tab size of 0 to be able to work, he wouldn't be able to do that with spaces.

The only argument that ever comes from spaces people is "alignment" and while I personally think that most if not all of the things people try to align don't get any benefit from that alignment whatsoever nobody advoces for tabs only, you can still always use spaces if you really really really need to align something. Some people messing that up is really not a reason to straightup ban the superior way, you could just train those people better. If you want to align stuff, go ahead. The thing that matters is that if I don't care about your alignment while you do and we both have different tab width preferences then with tabs we both get what we want while with spaces only you would.

Also while this was mostly about tabs vs spaces, those are not the only aspects of a style and the main point was that an enforced style will always upset some people. People simply work differently and intentionally preventing them from using whatever they like is pretty close to malicious if you ask me and in the best case still disrespectful. Some people work better in light mode, some prefer a complete rainbow IDE, some prefer to use raw vi, etc. Or for a better analogy, maybe someone codes much better while listening to loud death metal or whatever. Obviously in an office that would annoy other people but the solution is not to ban developers from listening to music completely but rather to make them use headphones in such cases so that other people are not affected. For code style I might work better with a certain one and you with a different style and that's okay, we just come up with some compromise style that the code is converted to before committing. Languages that enforce a certain style simply don't have this freedom.

Now in whitespace sensitive languages like Python if (and only if) you want to align stuff then yeah things can go boom. But it also is not an unsolvable problem, if the code is all spaces then it just works, if the code is all tabs with no "alignment" then it just works, and if you use tabs with some spaces because you want aligned stuff that can pretty much be checked by the parser. Error if a space is found before a tab, error if a line has more than one tab more than the previous one, etc. I don't think sidestepping this problem is worth alienating people.

[1] https://legacy.python.org/search/hypermail/python-1994q2/020...

The ecosystem might be small but as you said it can grow and I think there's enough people out there willing to give a new language a try if it seems appealing enough, it's quite common to try a new language for Advent of Code for example.

That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces). Same goes for Go which enforces the opening brace on same line style. The people writing those languages can have whatever style they like for their code, but forcing me to use it is very off-putting to say the least. I get that this is probably a minor issue for most people but I can't deal with change that well and things like this are super annoying, especially since there is not one single reason for forcing a certain style on everyone.

I'm aware that `#? replace(sub = "\t", by = " ")` works, but it's a hack and I'd have to inject it everywhere, not a good solution. But at least it's better than Go in this regard.

And so does Meson. I don't think the xmake author spent a lot of time using other build systems (in fact their short paragraph about Meson demonstrates that they clearly never did use that, using vcpkg with Meson is like 0 effort), it's pretty trivial to simply install a library with "vcpkg/conan install whateverlib" and then use it in your build system via the standard "find_package" (CMake)/"dependency" (Meson) mechanism of adding dependencies.

> In addition, there is another problem, that is, we need to additionally call the vcpkg install [packages] command to install this package. > > Each of these links requires an additional exploration process for users, and it is impossible to achieve real one-click compilation.

And personally I don't think that this "real one-click compilation" should be a goal. On the contrary, I think the current process is pretty much exactly how it should work - first you install your dependencies via your package manager, then you can inspect/vet/whatever them if you want, and then you let your build system build.