I feel that string processing is always more complex than Numbers or mathematical processing. Are our programming languages are designed this way that mathematical operations are pretty much straight forward while string operations are mostly include few methods applied to them. Or I just have a hard time with strings.

Note:Any experience and opinion are welcomed to have idea about the way our present languages handle different types of data.

Maths in itself is the language of nature similarly Strings are our formulation of information.

  • 2
    This may depend a lot on what kind of programs exactly you write (and what language you use, some languages have easier string handling like some scripting languages as Ruby). If you write say a web app you will in most cases do a lot of string processing and use more complex functionality while the maths part may be limited to some percentages or size calculations. If you write some data analytics tool or scientific software this may soon look very different. – thorsten müller Apr 23 '15 at 10:48
  • 7
    Define "complex", define "string processing", define "number processing". – Euphoric Apr 23 '15 at 10:51
  • Is car driving more complex than cooking? Please advise about the way our present cookbooks handle different types of vegetable. Driving is something that you do while sitting similarly cooking is something you do while standing. – Mike Nakis Apr 23 '15 at 16:46
  • By "String processing...complex" do you specifically mean Perl? – AK_ Apr 23 '15 at 17:25
  • In most programming languages strings are a layer of abstraction on top of numbers. So when you're processing strings, under the hood the computer translates it to numbers and processes numbers. – Pieter B Apr 24 '15 at 8:06

Executive Summary

Excluding Big-Integers, Strings that are more than one character long are inherently more complicated than numbers because they:

  • are represented as a list (or shallow tree) of multiple numbers
  • can be alphabetized
  • have case sensitivity
  • have punctuation, accents, characters, and whitespace, which all need to be treated differently
  • have character encodings which add their own complexities.
  • could use a lot of memory (if large enough).

Big-Integers could be about as complicated as all-lower-case (or all-upper-case) ASCII or EBCDIC strings.


What's a String?

A string is a list of characters. Characters are just numbers and a character encoding that gives each character a number to represent it. So a String is essentially a list of numbers.

What's a Number?

Excluding a few special-purpose computers at research facilities, every popular processor has built in integers (from 8 to 64-bits) and IEEE floating points (32- and 64-bits). Popular processors have instructions for doing simple math: +, -, /, and * on these various kinds of ints and floats. Popular programming languages have straight-forward syntax that gets compiled to these opcodes in very simple ways.

Bigger Numbers?

Many languages have a Big-Integer that stores values bigger than what fits in a hardware 64-bit integer. Like Strings, they are essentially lists of numbers. Sometimes BigInt is implemented as a String, but I hope that is rare today. Like Strings, BigInts tend to be harder to use than simple hardware-supported numbers. You can fill up memory with them, etc. As an aside, tools like Spire cleverly promote Integers to BigIntegers as appropriate.

Character Encoding

Strings used to be encoded in EBCDIC, ASCII, WinAnsi, and a bunch of other formats that came out before Unicode. With Unicode, there is UTF-8, UTF-16, UTF-32, and other ways of representing characters as one or more bytes. Some character encodings are one-way compatible with others, but most are not. ASCII has only 8-bit characters, but a String in UTF-8 is actually a shallow tree structure where each character is composed of 1-4 bytes (thank you @gnasher729). And that's just representation of a single "code point" in bytes. The logical characters themselves are sometimes composed of multiple code points (a base character plus an accent) so you have grapheme clusters to deal with (thank you @gnasher729).

Parting Thoughts

Anything can be as complicated as you want it to be. Numbers can be positive, negative, or zero (IEEE floating points can also be negative zero). They can be even, odd, prime, ratios, imaginary, irrational, transcendental, or have many other properties that have kept number theorists and set theorists busy for centuries and will continue to do so.

But character strings represent languages and you need fonts to render them, which have their own set of headaches (and licensing issues). Chinese people whose ancient family names involve characters that are not otherwise part of their roughly 10,000 character alphabet are clambering to have their names included in Unicode. There are lost languages, and arguments about whether made-up languages like Klingon need to be included in character sets. I think when you add all that, plus regular expressions, then in general, Strings are more complicated than numbers.

Probably for every string complexity issue, a great student of Math could bring up various series, sets, divergence, and other complex issues. But I think you are defining numbers as "ints, floats, and maybe Big-Integers" not as "polynomials, series, and beyond."

  • 1
    You didn't mention grapheme clusters, where multiple codepoints are combined to form an actual character. And UTF-8 never uses more than 4 characters per code point. – gnasher729 Apr 23 '15 at 22:20
  • This really diplomatically makes sense to me : ) +1 – Aura Apr 24 '15 at 7:07
  • 1
    Strictly speaking, since the set of strings is enumerable, they can't be really more complex than numbers. OP should try to implement string reverse or some other easy function in terms of big integers. This will teach him something concerning complexity of numbers vs. Strings ... – Ingo Apr 24 '15 at 9:35
  • @gnasher729 thank you for "grapheme clusters!" That adds some delightful complexity! UTF-8 uses up to 6 bytes to store a character (check the link I included). – GlenPeterson Apr 24 '15 at 11:30
  • 1
    Well, anything that processes UTF-8 in a Unicode environment will reject 5 or 6 byte codes, since they cannot be valid Unicode (four byte UTF-8 can be outside the range of Unicode as well). – gnasher729 Apr 24 '15 at 15:54

I think there are two aspects to this, and your question was not entirely clear which direction you want to take.

String operations from the perspective of the programmer can be easy depending on the language. Perl, for example, has regular expressions and other string operations baked into the language. It is trivial to transform or search strings. Other languages such as C require standard library calls which are cumbersome to use.

Under the covers, string operations are necessarily more complex than numerical operations. CPUs have built-in instructions for integer math. What does that even mean in the context of a string? Modifying strings: concatenation, truncating, etc. This cannot be done in the context of a single CPU instruction or register, making the implementation more complex.

Furthermore, what encoding does your string use? While integers have fairly standard semantics (so do floating point numbers), strings have many encodings (normally some form of Unicode or an ANSI code page). Code that operates on Unicode strings must necessarily be more complex than code that operates on numbers. How do you concatenate a UCS-2 string with a UTF-8 string? Compare them? These operations are possible, but there are now multiple steps involved: decode to get the Unicode code point, then compare or concatenate code points. When creating a new string in such a case, what is the new encoding?


In my opinion, we use numbers, don't process them. If you are doing some kind of numerical analysis (which I do often) in any language, you'll use the numbers as input for formulas, for example. This is of course not necessarily always true, but usually true.

Strings are "processed" more.

For example, you don't make a script to put numbers to lower case, or separate them in words, or take out certain parts. At least, is not that common.

So, I would say is not a language issue. Is just that numbers and strings have different uses, and are used in a different way. My two cents.

Also, I would like to make an emphasis that I think this is usually true, but not always. There have to be people who "process" numbers the way most people do strings, but is just not that common.


Its down to memory - an integer variable, for example, will occupy a set number of bytes and will never grow or shrink. A 4 byte variable remains like that and is copied around the system as-is, This means passing one into a function copies the value directly.

Strings however, occupy a variable number of bytes and this makes them fundamentally different to simply primitive types like int. If you copy a string into a function, you're really copying a reference to the start of the string rather than the entire string itself. (some programming languages then mask this to make operating on the string appear like modifying an integer, for example changes made inside the function are lost when the function exists)

This memory issue also shows in how to tell if a variable is not assigned - a string can be null for example, whereas you'd have to use a special type to represent a nullable integer (in C# for example), showing the cracks in any system that tries to manipulate strings and ints the same.

Another aspect is the complexity of strings anyway - integers do not have replace, split or trim functionality to name just 3, so strings are just more complex by their nature.

And lastly, encodings are present - how a string gets presented and what the meaning of each character is changes depending on the system or encoding used.

So yes, strings are just different to the primitive types. That's just the way things are.


This depends clearly on the programming language.

For example, when using a language focused on numeric processing (like Fortran), or when using a language like C where "String" is not an inbuild data type, or at least not implemented as seemlessly and without a concat operator like "+" or "&" and garbage collection (like in Pascal), then string processing can "feel" more complex than number processing.

However, even in old languages like Basic, or modern languages like C++, C# or Java, where strings are either a core datatype, or provided as if it was one, string processing is IMHO not more complex than dealing with any other core datatype. And this is even more true today for scripting languages like Perl or Python, which provide you with a powerful collection of string tools and functions, which make string processing very easy, once you learned those tools.

  • It is a built-in primitive type in Pascal. string is actually specified as a language keyword. – Mason Wheeler Apr 23 '15 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.