Leaderboard

Threads are dangerous in the same way that travel by car is dangerous. If you prepare well, know how to drive, follow the rules and take the appropriate precautions, then you will be in control and nothing bad happens. As always, there may be external factors that can cause problems - but that goes for code that is not executed in threads as well. That said - in this case, it sounds like the third party engine has serious flaws.

I strongly, strongly disagree. They introduce more problems that they solve in some implementations, true; but with correct usage they can make a sluggish UI fluent, a long running calculation finish in a fraction, or simply making the application do several calculations in parallel instead of serial. One word for all: they make a better experience and happier end-users. Threads are dangerous. Not evil.

Generally, no. I don't know about each and every platform but you either cannot kill unresponsive thread from the outside (application) or you can kill it but effectively doing so will also leave application in totally unstable state. So, if you need to kill the thread, you basically need to kill the application itself.

Although I am a big fan of rtti and attributes I would choose the const array[enum] of x any day as its compact to write and compile time evaluated (i.e. error if someone introduces a new enum value and forgets to specify an array value for it).

Which should not be required for a single privilege.

Well, again, they're working towards adding other language abilities, so it's not like it's been rejected on design grounds. As for security, some of the languages available with PostgreSQL come in "trusted" and "untrusted" modes. For instance, from the PostgreSQL documentation: And of course any of these other languages will need to be enabled by a system administrator. Regarding "rm -rf" or the like, the PostgreSQL database should be set up to run under its own account with very limited privileges and its own group. In PostgreSQL, only database superusers can create functions with an untrusted language. Now as for performance, there are two points. The first regards performing actions on a large volume of data.It can be far quicker to perform the action on the server, even via Python, than to move the entire body of data to the target machine and perform that action locally. The second is that other languages can allow the end user to easily perform actions that would be incredibly difficult via the inbuilt procedural SQL language, hence it's a performance enhancer. To quote from the anonymous author of "PostgreSQL Vs. MS Server": Python and R have become the dominant languages in data analysis, and machine learning which is why MS SQL Server has added support for them (along with .NET languages). Being able to use a machine learning routine or do logistic regression right on the server inlined with SQL is a really powerful feature.

if Num > 999999999 then raise Exception.Create('Can''t express more than 999,999,999 in words'); This made me giggle 🙂 Seriously though, ours is somewhat similar. It's not this sophisticated though.

We did something like this in a commercial application: it only handles numbers up to 9999 but in multiple languages if I'm not mistaken. To be completely honest, it's quicker just to write your own from scratch which will satisfy your needs rather than to look for one. The code I was talking about is about 50-100 lines in Delphi... Due to it's commercial nature I'll not be able to share sniplets, but it's basically these rules in lots of "if" statements 🙂

And what doesn't satisfy you with the NumWords v.4.6 result? (Worked fine for me)

It does. But we all know the phrase - you cook with what you have 😞

Just to illustrate the complexity of this in a different language, look at the danes that work with n times 20s and half-20s when above 50 and below 100, and they are not entirely consistent about it either. I am not a native dane, so there may be some mistakes - but this is my understanding of their classic spoken numbering. førr = forty = 40 fem og førr = five and forty = 45 half tres / femti = fifty = 3 x 20 - 10 = 50 seks og halv tres = six and fifty = 6 + (3 x 20 - 10) = 56 seksti / tres = sixty = 3 x 20 = 60 fem og seksti = five and sixty = 65 half firs / søtti = seventy = 4 x 20 - 10 = 70 åtti / firs = eighty = 4 x 20 = 80 half fems / nitti = ninety = 5 x 20 - 10 = 90 syv og halv fems = seven and ninety = 97 hundrede / fems = hundred = 5 x 20 = 100 277 = to hundrede og syv og halv firs = two hundred and seven and seventy = 200 + 7 + 70 Modern Danish does allow saying 55 = "femti fem" instead of "fem og halv tres" - i.e. more like the English spoken "fifty five", but the classic form is widely used. Modern 277 would be "to hundrede og søtti syv", like the English "two hundred and seventy seven".

Worse. 4-20-12

Well, I'd say one language = one set of of rules = one helper unit. You'll not reach 100 files, but can get close if you are ambitious enough 🙂 Plus, you need a fluent speaker of that language to help you out. I personally do not speak French, but I hear they have quite messed up way of saying numbers (like 92 is "76 and 16" or something).