<div dir="ltr">Strings are really just streams of bytes.<div><br></div><div>Streams of bytes are the ubiquitous data representation format. It can represent anything you like. The problem is that with the vast generality comes lack of precision. In order to handle the string, you need to interpret its contents. You that with a spectrum of string manipulation techniques: splitting, converting to other types, regular expression matching, LALR(1) parsing and so on. The goal is to take the stream of bytes into some deeper structure which you can manipulate in the program. Squint your eyes enough, and all programs are string processing.</div><div><br></div><div>Once you start realizing everything is basically a variant of string processing, you see why it must be hard to build a good solution for. Your solution is at some end of the spectrum, which makes it excellent for handling some problems, but makes it hard to handle others. Very general solutions to the processing problem (LALR(1) parsers, etc) are not the easiest to get going on smaller problems.</div><div><br></div><div>Hence most processing is complicated because it requires you to pick the right kind of data processing abstraction in addition to solving the problem itself.</div><div><br></div><div>Natural text is hard because there is very little formal structure in it. So you have to use approximative methods, Machine Learning, etc. Context Free text is easier to manage, but few people do it correctly and write a parser for it. Rather, they tend to try to work directly on the string (jokingly called "stringly typed programming").</div><div><br></div><div>Is Erlang bad at string processing? Yes and no. OCaml processes strings much faster than Erlang in the common case because it is a compiled language and can run directly as machine code. OTOH, if you have to look at every byte in a data stream, chances are you are bound not by the CPU time, but the time it takes to get data close to the CPU from DRAM. As for the API availability, it all depends on how good you are at using functional programming I guess. I rarely feel I lack certain API functions in Erlang when handling strings. I'd be keen to look into woes you've had in the past with things that were unwieldy to handle.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 12, 2017 at 2:50 AM Steve Davis <<a href="mailto:steven.charles.davis@gmail.com">steven.charles.davis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
You would think that, by now, computer science would have a decent answer to how to deal with text.<br class="gmail_msg">
<br class="gmail_msg">
All answers (from anyplace anyblog anylist) I have heard so far basically… suck.<br class="gmail_msg">
<br class="gmail_msg">
Why is that? What are the missing ingredients to a real solution?<br class="gmail_msg">
<br class="gmail_msg">
The word “string” for me has long been a dirty word.<br class="gmail_msg">
<br class="gmail_msg">
/s<br class="gmail_msg">
<br class="gmail_msg">
(Political aside: *spits on all that “emoji” crap* :-) )<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
erlang-questions mailing list<br class="gmail_msg">
<a href="mailto:erlang-questions@erlang.org" class="gmail_msg" target="_blank">erlang-questions@erlang.org</a><br class="gmail_msg">
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" class="gmail_msg" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br class="gmail_msg">
</blockquote></div>