C# Strings are AWESOME

[leeor_net]

Referencing this article about how ass C++ strings are, I've recently delved into C# programming and found that not only is it a really awesome language in general, its string handling is AWESOME. It handles typecasting (I believe they call it boxing and unboxing) and everything has a ToString() method attached to it. String concatenation and manipulation is very easy and isn't as verbose as it is in C/C++.

Actually I find that to generally be the case with everything in C#. It's very easy to use, you can use properties as get/set type deals (I realized making explicit get/set functions paled in comparison to using properties). It's class interface is pretty awesome and is how C++ ought to have done it. .Net is kind of cumbersome but it has a huge amount of functionality that makes building GUI apps a breeze... I was able to build a repair ticketing program for work in a day all while learning the language, MySQL connectors and .Net components at the same time.

So yeah, C# is great, C# strings are awesome... I'm not really sure I have a whole lot of negative stuff to say about C#. 

[lordpalandus]

Python has pretty good string support too. Just saying

[Vagabond]

Now you can see why I was getting my butt kicked so badly when I started programming in C++ char*/std::string after coming from a C# string background. I stopped just working intuitively like I was used to.

So many of the issues Hooman and I deal with in OP2Utility regularly are completely nonexistent problems in C#. I wander if Java is the same way, but I've never programmed in it.

Maybe we will have to do some sort of C# collaboration at some point in the future.

-Brett

[leeor_net]

Python has pretty good string support too. Just saying

Python is also garbage... so there's that.

Now you can see why I was getting my butt kicked so badly when I started programming in C++ char*/std::string after coming from a C# string background. I stopped just working intuitively like I was used to.

I now completely understand it. C strings are worse than C++ strings which are still pretty awful. Cumbersome and verbose syntax.

So many of the issues Hooman and I deal with in OP2Utility regularly are completely nonexistent problems in C#. I wander if Java is the same way, but I've never programmed in it.

C# borrows a lot from Java so it would be no surprise if it does strings in effectively the same way. I too haven't done much with it... mostly because of Oracle.

Maybe we will have to do some sort of C# collaboration at some point in the future.

I'm game!

[lordpalandus]

If you code poorly in python and use too many useless dependencies, then sure, it will be garbage. But the same can be said of any programming language, when you do the same practices.

Unless there is something else you'd like to add?

[leeor_net]

Anybody can write garbage code in any language. I'm saying the language itself is garbage.

Side note: This is not a judgement on those who use/like python, only that I personally hate the language and think that there are far better alternatives.

[lordpalandus]

How is the language garbage? I did some looking around on places like StackOverflow asking why people thought it was a garbage language, and the points those topics raised were:

1. Using indents to create code blocks instead of { }. I personally love it this way, as I no longer accidentally forget a { or a } and then have to hunt for the dastardly thing.

2. Dynamic type casting, over statically type casting. ie In python, value = 0 is an integer variable but in C++, you'd declare something like int value = 0;  I personally find this is very useful, and if the end user can't tell what value is by looking at it, they should give it a descriptive name and/or use good commenting to indicate it's purpose in a function. However, you can enforce type casting in python, such as converting a number into a string.

3. Poor performance. It is true that as an interpreted language, it will be slower to process than a compiled language. However, python does support compiling of files into bytecode, beforehand, which I believe would give it the same or slightly worse processing time as it would be in a compiled format already.

What are the issues you find with the language, leeor?

[Arklon]

How is the language garbage? I did some looking around on places like StackOverflow asking why people thought it was a garbage language, and the points those topics raised were:

1. Using indents to create code blocks instead of { }. I personally love it this way, as I no longer accidentally forget a { or a } and then have to hunt for the dastardly thing.

2. Dynamic type casting, over statically type casting. ie In python, value = 0 is an integer variable but in C++, you'd declare something like int value = 0;  I personally find this is very useful, and if the end user can't tell what value is by looking at it, they should give it a descriptive name and/or use good commenting to indicate it's purpose in a function. However, you can enforce type casting in python, such as converting a number into a string.

3. Poor performance. It is true that as an interpreted language, it will be slower to process than a compiled language. However, python does support compiling of files into bytecode, beforehand, which I believe would give it the same or slightly worse processing time as it would be in a compiled format already.

What are the issues you find with the language, leeor?

As someone who likes Python, I'd mostly share those same complaints. Although, #1 wouldn't be so bad if it didn't allow you to mix tabs and spaces, or use inconsistent indentation sizes between blocks. And #3 can be worked around using Pypy or Cython instead of CPython, using libs like numpy and numba, etc.

Though the thing that bothers me most about Python is how fast and loose they play with variables, to the point where you can't have const variables because the variable (name) can always be reassigned (even though the objects themselves can be const, like tuple or frozenset), and it can be unclear whether you're assigning vs. initializing or if re-assigning overwrites the contents of the original object.

[leeor_net]

You've already found my complaints with the language and Arklon mentioned the rest of it. I don't see any need to explain it further. I hate python and would choose just about anything else over it... even javascript /me shudders.

[Arklon]

Yeah but you like LUA so you have poor taste

... In all seriousness, I do like LUA under the hood and how small the interpreter is, especially for a language that can be compiled to bytecode, but the syntax is like a horrifically mutated version of Basic syntax, and I always hated Basic syntax to begin with. And arrays being rooted at index 1.

[leeor_net]

Well... you're not wrong. I wouldn't say I particularly 'like' lua, just that I find it much more useful and less gross.

[lordpalandus]

Ugh, LUA. First time I was introduced to that was Supreme Commander... and it doesn't interpret all that fast for a complex game like SupCom 1 is.

I made the text adventure in JavaScript... I'd rather choose any language over JavaScript, even LUA, or C++.

I do agree not being able to intersperse indents with spaces, or being free to place however much of each you want, is annoying in the code, but over time I've gotten used to it. It is however nice that you can put a long calculation on more than one space though, and indent the longer calculation without issue, however much you please. However, I find that the use of { and } just consumes way too much excess space and makes the codebase look bigger than it is, making it harder to find stuff quickly.

As for constants, adapt. If you are working with a group of people, just prefix any variables that should be a constant, in a way that everyone on the team will immediately recognize. ie CONST_value = 0. Anyone reading that would know that the variable name CONST_value should be treated like a constant. Problem Solved.



 

[Arklon]

I should join in on bashing JavaScript, but honestly, http://jsfuck.com/ really saves it from being the worst language of all time. The sheer awesomeness of the fact that the mere virtue of it being so extremely weakly typed inherently means that it automatically contains a fully-featured Brainfuck-esque language as a subset makes it one of the best languages ever.

Ugh, LUA. First time I was introduced to that was Supreme Commander... and it doesn't interpret all that fast for a complex game like SupCom 1 is.

Lua seemed plenty fast in SupCom 1 actually. If the game seemed really slow back in the day, well, there's an infuriating explanation for that. The simulation speed throttling code that was meant to make sure your CPU was keeping up was totally broken, and would invariably reduce the game speed to -10 (as in 0.1x of realtime) after 20-40 minutes. It wasn't fixed until years after the last official update when someone discovered it and made a quick and dirty hack to disable the throttling code altogether, which still isn't exactly ideal mind you, but infinitely better than 40 in game minute games taking 4-5 hours.

The other part of what made the game inefficient was the XACT sound engine is bad, made worse by the fact that Gas Powered Games didn't know what they were doing because XACT is a Microsoft product, and those are very effective at making you not know what you're doing; most sounds weren't cached into memory, they were always fetched from hard disk, and that's what causes the noticeable stutter when you click on buildings and units for example.

However, I find that the use of { and } just consumes way too much excess space and makes the codebase look bigger than it is, making it harder to find stuff quickly.

I only get bothered by this when the coding standard says { open brackets must always be on their own lines. I only like doing that after multi-line if statements or function declarations or whatever to avoid run-on indentation, but 90% of the time it just wastes lots of vertical line space.

As for constants, adapt. If you are working with a group of people, just prefix any variables that should be a constant, in a way that everyone on the team will immediately recognize. ie CONST_value = 0. Anyone reading that would know that the variable name CONST_value should be treated like a constant. Problem Solved.

That's not a solution, that's a coding convention workaround, and doesn't address the other problems of Python's variable mechanics that I mentioned - and all of these issues are directly caused by how "weak" variables are. Coding conventions around different "kinds" of variables, like class member variables vs. locals, is a good idea in any language, but that only helps you as the user of the language, not the language itself.

The other massive weakness of Python that I forgot to mention was the Global Interpreter Lock that makes it useless at multithreading. Though, as with performance issues in general, libs and extensions can get around that, like numba can disable the GIL, or use libs like stackless to add MT algorithms and such. Or use multiprocessing instead of multithreading, but that's often just worse all-around than MT for a lot of use cases, but if you don't need to share memory and aren't creating new workgroups constantly then MP isn't that bad.

[Hooman]

Pretty much any language is better than C/C++ at string handling

Though yes, C# does seem like a nicely designed language. I can see why it's popular.

I rather liked the forced indentation with Python. Back in the day I saw a lot of badly indented code, so it's nice to see indentation enforced by the language. Though I think Arklon is right in that it doesn't go far enough in terms of ensuring consistent tab/space indents and progressive indent widths. There's also a slight issue with copy/pasting code from the internet (not that you should ever do this of course), and getting messed up or inconsistent tab/space indentation.

I also liked the vertical space savings with Python. That's something I've come to appreciate about other languages. For that reason, I've switched to using line ending { in C++.

The GIL is a major pity with Python. Sometimes multithreading is much better than multiprocessing, either from an efficiency standpoint, or from a design standpoint. Ruby has a similar problem with its "green threading". I've always hated how they tried to put a positive sounding name to a negative language liability. I've also always hated that damn motto about how "Ruby programmers are happy programmers". Grr! It makes me feel like an old curmudgeon every time I read it.

I terms of static versus dynamic, I think I prefer static type checks. There are a lot of simple easy to make errors that a compiler would catch right away with a static check. When using a dynamic language like Ruby, you don't find those errors until runtime, and if your algorithm takes a few minutes to run, it's damn annoying. I've heard similar from mathematicians using something like MatLab or Maple, who would leave code running overnight, only to find the next day that they'd missed a semicolon somewhere.

JavaScript has gotten a huge facelift with the ES6 standard. It's just not the same language anymore. If you hated it before, you might want to revisit it now. Dare I say that once awful language is now actually pleasant to use. They've finally added proper modules to the language, along with const, shorthand arrow functions, rest and spread operators, object destructuring, property shorthand and computed property names, iterators, generators, promises. There is some neat new async syntax, though I think that one might be part of the next standard. They've also added a bunch of simple useful new methods that never should have been absent.

The new version of JavaScript seems to borrow a lot of stuff from functional programming. A lot of languages seem to be doing that lately, C#, D, Ruby, Python, even C++, and usually to good effect.

As for compiling to byte code, remember that Java does that, and its performance is awful! I don't think I've ever been able to use a large scale desktop app that was written in Java.

In terms of poor taste, I think Perl takes the prize.

[leeor_net]

The vertical space point for me seems to be a minor complaint and one of being nit-picky and saying that it makes the code look big and cumbersome is an outright farce. This may have been true back in the days of terminal editors (80x40 characters) but anybody doing that today is just engaged in self-flagellation. It helps that I have a 1080p display but even on my 1440x900 display I never had an issue. Besides, there are coding styles that can get around that and good IDE's do have code collapse mechanisms so again, vertical space is not a good argument.

[Hooman]

I find code collapse to be a pretty useless IDE feature. I've probably been annoyed by accidentally clicking on it more often than actually using it. I think code collapse is a symptom of bad code. You only need it if you're writing really long functions, which you generally should try to avoid. If a function is long, it's probably trying to do more than one thing, in which case it should be refactored and split. Whenever possible, I think a function should fit within one screen of text.

For reference, I still use 1366x768 resolution. It's a small travel laptop. Plus, due to the small 11 inch screen size, I tend to bump up the font size.

Though I admit you're probably right about being nit-picky. I make no pretenses that I'm not when it comes to code. 

[leeor_net]

I think code collapse is a symptom of bad code. You only need it if you're writing really long functions, which you generally should try to avoid. If a function is long, it's probably trying to do more than one thing, in which case it should be refactored and split. Whenever possible, I think a function should fit within one screen of text.

Well... you're not wrong. Though sometimes you have a necessarily long function, this is the exception rather than the rule.

[Hooman]

I split A Necessarily Long Function into its own thread. It was becoming quite a topic all on its own.

[leeor_net]

Good thinking... I was considering it myself.

[Vagabond]

When I first learned to program, I would use the #region preproccessor directive a lot to segregate my code in C#.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-region

Then as already pointed out in this thread, I realized it was better to segregate into smaller files as opposed to regions of code in huge files. So I almost never use regions now, although they may have an occasional use I suppose.

I also found myself fiddling too much with where the regions existed. I was always moving them around and rearranging the code into different regions, which I don't think was a particularly helpful use of brainpower.

Oh, I didn't mean to be too harsh on C++ std::strings. They cannot be as intuitive as C# since they must support backwards compatibility. Since newer strings do not rely on the null terminator anymore, there will always be a sort of awkward point of contention between char* and std::string that C# gets to avoid being a newer language.

[leeor_net]

Monolithic source files with your entire program in a single file is a common pitfall amongst newbies. I did the same thing when I was first programming in QBasic as well.

Granted technically speaking all programs in QBasic were a single monolithic source file but when you learned how to make subroutines QBasic was pretty good at separating them into different windows. And you could include other files but it was painful (generally speaking) and you were limited to 64KB max... of which your source file took up however much space it took up.

Yeah, it was messy, but with ASM routines we could do some pretty neat stuff.

I kinda miss that time -- felt like the wild west. Programs were way simpler.

Then again, I would trade off a bit of wasted cycles for the far better software tools we're building with now.

[Hooman]

Technically C# still has to deal with null terminated strings under the hood since the Windows API still uses them. The Windows API was originally written with C after all.


Was just going to say, QBasic didn't give you much of a choice about the monolithic program design. It did keep things nice and simple though. At any rate, at least QBasic had actual functions, rather than GOSUB, the equally evil cousin of GOTO.

But I will say, string handling in QBasic was generally more pleasant than it was in C/C++. Probably not as powerful, but certainly more pleasant.

[Angellus Mortis]

2. Dynamic type casting, over statically type casting. ie In python, value = 0 is an integer variable but in C++, you'd declare something like int value = 0;  I personally find this is very useful, and if the end user can't tell what value is by looking at it, they should give it a descriptive name and/or use good commenting to indicate it's purpose in a function. However, you can enforce type casting in python, such as converting a number into a string.

This can actually be solved with Python 3.7 via Data Classes. In Javascript this can be solved with TypeScript, which is a subset language made by Microsoft that gets compiled down to Javascript (do not even get my started on build pipelines in Javascript, they are the absolute worst thing ever).

Also, back to the original point. I have been really enjoying string formating in Python 3.6+

Code: [Select]

first_thing = 10
second_thing = 20
some_object.property = 30

print(f'First: {first_thing}, Second: {second_thing}, Third: {some_object.property }')
# outputs: First: 10, Second: 20, Third: 30

The thing that really draws me to Python is really the community. Python definitely has its flaws, just like any other language. By the relative easy of use to do most things in the language, coupled with the very very opinionated community creates an environment where their tends to be better documentation and more libraries overall to help you with most problems you need to solve without trying to completely reinvent the wheel.

[Hooman]

do not even get my started on build pipelines in Javascript, they are the absolute worst thing ever

Lol, I think I may have to agree on that one. That can be a confusing mess. Though once the tooling is setup for what you're working with, it all just works.


The Python string formatting looks rather convenient. Though I'd imagine there would be a security concern should someone gain control over the format string. They might decide to read back values that really shouldn't be printed to the end user.

I kind of like that way I saw in D, where you still pass all the values that are relevant to the format function, though you can reference them with {1}, {2}, etc. so they could be re-ordered when printed. That's important for language translations, where word order can change.

[Angellus Mortis]

I am not completely sure on the security of Python. I have not really used it for any applications that would really need to be memory hardened from attacks. I have mostly used it for Web programming and creating CLI applications for servers.

So Python is weird with string formating. The original string formatting method was very similar to how C did it.

Code: [Select]

'%s %d' % some_string, some_number

But this was decided not to be very readable, or "Pythonic", so they added a second way (~Python 2.4?)

Code: [Select]

'{} {}'.format(some_string, some_number)
'{1} {2}'.format(some_string, some_number)
'{a}, {b}'(a=some_string, b=some_number)

But this was is too verbose. It is very easy to overflow your 80 character line limit very quickly. So that is why Python 3.6 added "f-strings". All three forms of formatting are still valid, those if you do not need to support anything older than Python 3.6, I think most people always use f-strings.