3 ms·

Unicon/Icon is my language of choice, mostly because failure is an option. Icon will be found at https://www2.cs.arizona.edu/icon/ https://www2.cs.arizona.edu/i

Unicon/Icon is my language of choice, mostly because failure is an option. Icon will be found at https://www2.cs.arizona.edu/icon/ https://www2.cs.arizona.edu/icon/ and Unicon (Icon's descendent) at http://unicon.org/ http://unicon.org/. It has no booleans or anything that represents booleans for that matter. Something either succeeds and produces one or more results or it fails. It has its problems (like all languages) but I find that it is easier to formulate a solution to a problem in it. I tend to use the same formulations in any other language that I might have to use. But when you can write something like every write(read()) to copy all lines from stdin to stdout or to test a number between a range with if 0 <= i <= 100 then write(i) it has its uses. SNOBOL4 is the precursor to icon and it used success and failure as well. Though I haven't written any serious SNOBOL4 code since the 80's. BUt the world is your oyster and there are many languages that you can choose from. Languages like Fortran, Simula, Squeak, any of the various LISPs, FORTH, FACTOR, there are so many and if you study and use each, you will find different ways to think about how to solve the various kinds of problems that you will come across in your career. Happy hunting.

karmakaze 7y ago
> It has no booleans [...] either succeeds and produces [...] result[s] or it fails. That's a very interesting concept. I immediately thought, what if the question was whether a certain condition exists in the data or not. The answer would be any single instance found in the data. This jives with how I always question putting booleans in database schemas. It's usually better to add a piece of data that the boolean represents like a date for when a predicate changed or an enum for the 'flavor' of true. Passing a false/true to a function gives no info unless the function name makes it clear. => booleans are a (premature) optimization.

karmakaze 7y ago

> It has no booleans [...] either succeeds and produces [...] result[s] or it fails. That's a very interesting concept. I immediately thought, what if the question was whether a certain condition exists in the data or not. The answer would be any single instance found in the data. This jives with how I always question putting booleans in database schemas. It's usually better to add a piece of data that the boolean represents like a date for when a predicate changed or an enum for the 'flavor' of true. Passing a false/true to a function gives no info unless the function name makes it clear. => booleans are a (premature) optimization.