OSDev.org

Anyone here using esoteric programming languages, for example, Brainfuck, Piet, INTERCAL, Malbolge, Arnoldc, FRACTRAN, FiM++, Shakespeare Programming Language, LOLCODE or DawnOS? I'm planning on trying these, and would like to hear of users' experiences (good or bad). Thanks.

References:

https://en.m.wikipedia.org/wiki/Esoteri ... g_language

http://esoteric.codes/blog/a-programmin ... ommand-and

I actually "use" BF as the first lesson when teaching C programming. You can explain "all" of the language in one sitting, and you will have taught...

• memory as a sequence of cells / bytes;
• source code, compiler, executable;
• separation of code and data;
• operators;
• pointers (one, actually) and dereferencing;
• input and output, with a side dish of characters encoded as numbers;
• conditionals and loops;
• what an "algorithm" is;
• the value of comments;
• ...and why the simplest of languages does not mean the simplest of programs (a.k.a. "and now on to a real language that actually makes things easy for you instead of for the compiler").

Note that I do not use the BF intro when teaching higher languages like C++, because I prefer to stay far away from pointers and in-memory representation with those for as long as possible (which is surprisingly long indeed even for C++).

Most "esoteric" languages exist for their oddity value, usually taking a certain point to the extreme -- and that point is not usefulness. (BF was designed to allow the simplest of compilers, for example.) Hence, their "value" usually does not extend much beyond the chuckle you get out of reading about them, or having written some small program in them for the bragging rights...

Others will answer this topic?

Schol-R-LEA, David Cooper, Brendan...?

Hi,

trident wrote:Others will answer this topic?

Why? Are you trying to find out which of these languages shouldn't be considered esoteric because they're in common use?

Let's talk about language efficiency. The more languages there are the harder it is for programmers to re-use existing code and communicate ideas with each other, and the more time programmers need to spend learning languages; so "more languages" means "less efficiency". On the other hand, you don't want everyone to have to use a single inefficient language either.

For this reason what you really want is to have some kind of tournament to select the best possible language that everyone must use (the winner of the tournament) and where all other languages (the losers) are banished from existence.


Cheers,

Brendan

C++ is esoteric alright and will be even more so.

I disagree with Brendan on this one, his view seems extremist to me. Sure, it's not going to help anyone to have as many languages as there are programmers and then have to keep retrainig them each time they switch to a different project.

On the other hand, there is no silver bullet either; different tools are better suited for different tasks. Do you really think it would be wise if we had only one kitchen utensil that tried to do everything? Or just one language to express music, mathematics, and prose?

Not everyone has to work on exactly the same thing and it's affordable to learn new languages at least some of the time. It's a better trade-off than having one monstrosity that tries to be a jack of all trades.

I'm not saying we don't have too many languages in use today. I'm just saying we can't have too few.

Brendan, languages have domains in which they are strong. No single language can claim to be the optimal solution in every domain. RDBMs and JVMs are written in C++, not in Python. Web frontends use JavaScript, not C++. Small pieces of process automation are written in Bash rather than Java.

And even if there would be a language that could be hammered into some crooked shape that would serve all these domains in some way or form, do you really want to "banish from existence" the development of the next version of that very language? Because that's what your suggestion would amount to. Oh no, new features, I might be confused...

Fact is, a sizeable fraction of all the work done in IT is designing domain-specific languages. That's why compiler building is such a well-researched subject in the first place.

----

If a hammer is the only tool you have, every problem starts to look like a nail...

Hi,

Solar wrote:Brendan, languages have domains in which they are strong. No single language can claim to be the optimal solution in every domain.

Sure, there's some domains (query languages that are not programming languages) where you need a language for that domain; but the idea that you want a language that is optimal for each specific use case is silly. You do not want to spend 2 years learning and gaining experience with a language just you can say "Yay, I save 2 minutes using a different language". By ignoring the retraining/re-familiarisation costs you're deluding yourself with a false definition of "optimal".

RDBMs and JVMs are written in C++, not in Python. Web frontends use JavaScript, not C++. Small pieces of process automation are written in Bash rather than Java.

No. Something will be written in C++, then rewritten in Java because people are stupid, then rewritten in Python because why not waste 3 more years, then rewritten in JavaScript because it's still not as inefficient as possible. Then someone will port it to Haskell, or Go, or Rust, or Dart, or any other stupid fad language that happens to catch a retard's eye. Then all of these "pointless rewritten because of morons" pieces of crap will get maintained separately until we reach the stage where a piece of software that could've and should've costed $100K ends up costing a total of several million $$ in retraining, rewriting and maintenance simply because clueless fools keep saying "Hey, a different language might be more optimal!".


Cheers,

Brendan

I think you are:

• ...overestimating the ability to re-use code that is not explicitly designed to be re-usable (i.e., a function library). Virtually none of the "problem solving" code I have ever seen produced in a company would be even marginally useful outside the project, except as a "how did I solve this last time?" reminder to the people directly involved. One on the issues involved being copyright. Unless, of course, someone took it upon himself to write certain components in his / her spare time to make things available to a wider audience (and keeping that from diverging takes some effort, I tell ya...)
• ...overestimating the amount of cross-language rewrites going on; the reason for re-writes usually not being "the next cool language", but the inevitable shortcomings of architecture combined with code rot / know-how deterioration, which is unrelated to language.
• ...underestimating the ability of architects to choose the (more or less) right tool for the job.
• ...somewhat on a rant here?

Brendan wrote:Sure, there's some domains (query languages that are not programming languages) where you need a language for that domain; but the idea that you want a language that is optimal for each specific use case is silly. You do not want to spend 2 years learning and gaining experience with a language just you can say "Yay, I save 2 minutes using a different language". By ignoring the retraining/re-familiarisation costs you're deluding yourself with a false definition of "optimal".

You (intentionally?) misunderstood what I was saying.

Part of my work involves writing up token patterns, rules, and sequences for a state machine that does a kind of "fuzzy" identification and comparison of address data.

Doing so in Java or C++ directly would be bothersome, not least because it would mean you'd have to re-compile after each edit to see how it affected results. You could, probably, express them in some LISP derivative, but good luck trying to find developers for that. So those state machine configurations are written in a domain-specific language that is tailored for address data, making the configurations much simpler and easier to read and maintain.

The configurations are then read, parsed, and executed in a kind of VM. The parser and the VM, as well as the server handling requests (so you would not have to load all the configurations every time a request comes in) are written in C++. Actually, the parser is written in Bison, because Boost.Spirit wasn't available yet back in the day and we didn't get around to rewriting that part to get one additional language / tool out of the picture. There is a server to it as well, so you don't have to re-load the configurations for each request. That might have been easier written in Java, I am not sure -- Boost.Asio did the trick well enough, and again saved us from adding another language to the picture.

The build is controlled by CMake, which allows us to build binaries for all the various supported platforms from one build configuration. The server, eventually, is started, monitored, and re-started if required by a couple of Bash scripts (which our system operators are familiar enough with). Windows has its own task management, and I seriously doubt they're going to "synchronize" their system with "the Unix ways" anytime soon.

I am not even going into the Vagrant / Docker build automation that we are doing right now.

As we do not want to force our end-users into writing their own client software to interface with the server, we provide a client executable which takes a job / file format description that includes the specification of the operations desired on the data -- another DSL, tailored to be approachable by the not necessarily IT-savvy people asking whether "John P. Sullivan; Baker Street 28" and "Mr. Sullivan, MD; Bakersstreet 2B" might be the same person.

And in comes Brendan and demands that we stop this heresy of using more than one language (Template DSL, C++, Bison, CMake, Bash), and instead do all the above in...

What?

So that who exactly would be less confused?

Obligatory XKCD link

Solar wrote:That might have been easier written in Java, I am not sure

You just asserted that Java has some practical value; therefore, Brendan is going to write you off as one of those fools, because he sees Java as intrinsically pointless.

(The question of whether poking fun at a moderator's foibles is less dangerous than poking a bear with a stick is left as an exercise for the readers.)

Mind you, based on this rant, I suspect that he sees any language other than the one he is designing the same way. If so, this puts him in the same category as Geri and ~ (and the late TDavis), which isn't a good look for him. I hope I am wrong on this.

(I am pretty sure I am; normally, I would say that the most irrational part of Brendan's personality is his expectation that human beings are going to behave rationally - in my experience, on the exceedingly rare occasions when that happens at all, it is by sheer coincidence - and his conviction in his own rationality. Anyone who doesn't want to go among mad people is in trouble, because we are all mad here.)

But then, I am hardly one to talk about tilting at windmills, given that my own focus is on designing just such an 'all things for all people' meta-language/compiler-building tool (rooted in the Lisp tradition, though it probably won't look much like a traditional s-expression Lisp to most client-programmers - it would, I hope, be capable of compiling code from completely different languages, including C, using suitable libraries) whose primary 'paradigm', notational programming, will be writing DSLs (with the core language also acting as 'glue' for interfacing them).

But I don't claim to be sane, nor do I anticipate that anyone other than researchers will ever find my work interesting (and even that is a long shot). I don't want others to use my stuff for any purposes other than research - by its very nature, it isn't a practical system, its a framework for testing out odd ideas which if workable might get rolled into existing systems later on. I am tempted to say that, if we are in a position where an explicitly experimental system is getting adopted as a replacement for existing professional-grade ones, then we might as well pack it in and stop using computers entirely - except that in this crazy industry, that happens all the time, as shown by the continued existence of Unix in general and Linux in particular.

Hi,

Solar wrote:Part of my work involves writing up token patterns, rules, and sequences for a state machine that does a kind of "fuzzy" identification and comparison of address data.

So, you're essentially a secretary who isn't doing any programming, who is typing data (token patterns, rules, ...) for a program written in who-knows-what, for the purpose of matching addresses from 2 different badly designed systems; and because you're a secretary and not a programmer you couldn't be bothered fixing the real problem (making sure the addresses used in both badly designed systems complied with some kind of "universal standard" when they were entered in the first place, so that addresses always match).

Solar wrote:Doing so in Java or C++ directly would be bothersome, not least because it would mean you'd have to re-compile after each edit to see how it affected results.

Nonsense. It's trivial to write a "compile then execute" program to save you the hassle of (e.g.) pressing the F7 key in your IDE to build.

Solar wrote:The configurations are then read, parsed, and executed in a kind of VM.

So "VM" is the program that reads the data files (token patterns, rules, etc).

Solar wrote:The parser and the VM, as well as the server handling requests (so you would not have to load all the configurations every time a request comes in) are written in C++. Actually, the parser is written in Bison, because Boost.Spirit wasn't available yet back in the day and we didn't get around to rewriting that part to get one additional language / tool out of the picture. There is a server to it as well, so you don't have to re-load the configurations for each request. That might have been easier written in Java, I am not sure -- Boost.Asio did the trick well enough, and again saved us from adding another language to the picture.

Wait, so there's a parse that's not built into the "VM", and a server and a server?

Solar wrote:The build is controlled by CMake,

Sure, because the tools programmers use are so crappy that they can't even do their job without an extra layer (or two) of hassle.

Solar wrote:The server, eventually, is started, monitored, and re-started if required by a couple of Bash scripts (which our system operators are familiar enough with).

Where Bash could be replaced by C++ utility with a dialog box containing a "restart" button that your system operators could click?

Solar wrote:And in comes Brendan and demands that we stop this heresy of using more than one language (Template DSL, C++, Bison, CMake, Bash), and instead do all the above in...

Well, no. Now that I suspect you're part of some "violate people's privacy to sell user's details to spammers" data matching nightmare I want you to use a lot more languages. That way when you find a real job they won't be able to find anyone that knows all of the many different languages, so whichever company you work for will be screwed.

Solar wrote:Obligatory XKCD link

The ironic thing about that specific cartoon is that the only solution is deprecation (removing standards).

Now let's put what I'm saying in context. Let's say that you have a team of 5 people and need to write a utility to compress/decompress files for some reason (mostly because it's something easily understood). For your 5 people, one only knows Python, one only knows Rust. One knows both Java and C#. One knows C and C++. One knows Haskell, Lisp and Scheme. Which language will you use (Javascript? INTERCAL? Visual Basic?), and how much time and money are you going to waste retraining how many team members?


Cheers,

Brendan

Brendan wrote:So, you're essentially a secretary who isn't doing any programming,

Uhm, correct me if I am wrong, here, but isn't your profession/livelihood in residential construction (I don't recall of that is you or a relative of yours, sorry), and programming is a hobby of yours?

Mind you, this isn't a knock about your programming skills - your knowledge and skill stand head and shoulders over that of most the people who are making US$150K per year for grinding out e-commerce websites, and honestly, I wouldn't recommend the programming 'profession' to anyone who wants to keep any sort of semblance of sanity - but it does impact how well you understand how programming actually works (or rather, doesn't work) in a corporate environment.

Trust me, I wish I could forget just how lunatic that 'profession' really is.

I can safely say that programming is the smallest part of almost any corporate IT job; as I have said before, 80% of most 'programming' jobs is talking to people, attending meetings, sending (or waiting on) email, etc. This is not inefficiency; it is doing the job right rather than trying to cowboy up a program when you don't even know what is needed. The technology, the tools, the coding - those are the easy parts.

The hardest part is usually having to choose between doing some ridiculous and self-destructive thing which someone with power over you is demanding, or leaving the job and trying to find another one where you will be in exactly the same bind. And if you think you can find a job - or even a consulting gig - where that won't be the case, then I have to ask, 'what color is the sky in your world?', because it isn't this one.

Brendan wrote:The ironic thing about that specific cartoon is that the only solution is deprecation (removing standards).

I think you have missed the point - in the Real World, deprecation is a pipedream. There is no way to force people to stop using something that mostly works, and convincing that they should do so for the promise of something that might be better (but probably isn't) is a matter of marketing, not technology.

In order to replace existing (non-)standards with a shiny new one, you have to convince people that

• the new standard is actually good (which it won't be - standards by nature are camels, and will never be useful in all cases, and usually are only useful for rigged demos),
• it is better than the standard they are already using (which runs into the previous point - while most people say that their system is following one or another standard, none of them actually are), and
• it is enough of an improvement to invest years of work and millions if not billions of dollars to change everything over.

And while that is going on, the marketing teams and evangelists for the companies and organizations promoting existing 'standards' will be talking people into thinking your system is Worse Than Hitler and that adopting it will ruin them.

And then you would need government intervention to enforce the rule that no competing standard will come up, just because someone thinks they can either improve on it, or (more likely) con people into think they have.

Competition in the market is about salesmanship, not quality, and the winner is usually the one that generates the most income for the most people. Furthermore, the majority of the billable work arises from its flaws, so without those flaws, the product won't gain interest from those who would be working with it. A truly superior tool wouldn't generate enough billable time to be viable (because it wouldn't need the armies of programmers, administrators, instructors, etc, which most 'systems' require in order to keep them kinda-sorta running one more day). Quality is not inherently competitive, and more often than not is spectacularly uncompetitive.

Or to put it another way: if a construction company were to develop a pre-fab (e.g., Fuller's geodesic domes) or on-site-fabrication (a la the '3D printed buildings' you sometime see news reports of) residential construction method that was significantly less expensive, faster, and required fewer construction workers to erect, and resulted in homes that were safer and required less maintenance, do you think that their business model would be successful? Or would the combination of outdated housing regulations, pushback from companies working in the existing methods, public uncertainty over safety and usability, and a whole host of other issues, cause them to fail long before their 'better approach' would put both their competitors and themselves out of business (which it pretty much would do, if successful, since you wouldn't need businesses specializing in that any more)?

(This isn't entirely hypothetical; this was exactly the problem Bucky Fuller had, though the 'requires less maintenance' part turned out to be wrong due to the water leakages and other problems experienced with his Stockade Building System, Dymaxion house, residential Geodomes, Fly-Eyes, and other attempts at developing pre-fab housing models (one of the first of which, the Dymaxion Deployment Unit was basically a small grain silo converted into a metal yurt). While he never did solve many of the technical issues with them, the real problems were in poor business management, resistance from both the public and governments, and the fact that it would put a lot of people out of business. Similar problems existing with Suuronen's Futuro house and the various plans for arcologies such as Arcosanti or Aquarius. The one successful company making pre-fab houses on a mass scale, Lustron, failed because of poor management - the tech was solid, though not exactly revolutionary compared to those of Fuller or Suuronen.)

Hi,

Schol-R-LEA wrote:

Brendan wrote:So, you're essentially a secretary who isn't doing any programming,

Uhm, correct me if I am wrong, here, but isn't your profession/livelihood in residential construction (I don't recall of that is you or a relative of yours, sorry), and programming is a hobby of yours?

I am/was a qualified electrician; but that's not the point I'm trying to make. My point is that there are programming languages (e.g. used to write things like word processors and spreadsheets) and there is data (e.g. files used and created by word processors and spreadsheets); and somewhere between these are various "domain specific languages" that are not programming languages and not related to anything I was talking about (and are not purely data either).

Schol-R-LEA wrote:I can safely say that programming is the smallest part of almost any corporate IT job; as I have said before, 80% of most 'programming' jobs is talking to people, attending meetings, sending (or waiting on) email, etc. This is not inefficiency; it is doing the job right rather than trying to cowboy up a program when you don't even know what is needed. The technology, the tools, the coding - those are the easy parts.

Sure, but people don't use programming languages for things like (e.g.) occupational health and safety meetings, or lunch breaks, or talking with clients, or any other part of a corporate IT job that doesn't involve using a programming language; and all of the other parts of corporate IT job that don't involve using programming languages (including the use of domain specific languages) have nothing at all to do with anything I'm talking about.

Schol-R-LEA wrote:

Brendan wrote:The ironic thing about that specific cartoon is that the only solution is deprecation (removing standards).

I think you have missed the point - in the Real World, deprecation is a pipedream. There is no way to force people to stop using something that mostly works, and convincing that they should do so for the promise of something that might be better (but probably isn't) is a matter of marketing, not technology.

Erm. Perhaps the main problem here is that people can't read. For example, I wrote "For this reason what you really want is..." and somehow the words "what you want" are being misconstrued as "what will actually happen in the real world". Note that my words were intended to get the original poster to consider the costs associated with "too many languages" and think about how these costs apply to esoteric languages (what this topic is about) that are (by definition of "esoteric") not worth learning.

Schol-R-LEA wrote:In order to replace existing (non-)standards with a shiny new one, you have to convince people that

• the new standard is actually good (which it won't be - standards by nature are camels, and will never be useful in all cases, and usually are only useful for rigged demos),
• it is better than the standard they are already using (which runs into the previous point - while most people say that their system is following one or another standard, none of them actually are), and
• it is enough of an improvement to invest years of work and millions if not billions of dollars to change everything over.

If we're going to talk about practicality; it'd be worth looking at C# (Microsoft's attempt to get programmers to shift to a specific language). For Microsoft's case, I think their motivation was to get people to use CIL and create cross-platform software, to make it easier for Microsoft to make progress in a different markets (smartphones, game consoles); and C# was merely a means to an end rather than a goal on its own. Despite this, in terms of adoption, C# was/is far more successful than the majority of new languages, and if Microsoft really wanted to push adoption (e.g. possibly so that they can go down some "all software must be written in our managed language" path like their Singularity project) they would eventually succeed (assuming a relatively standard "10+ year migration period to prevent alienation").

Of course this also depends on how you define "everyone" - e.g. "everyone that uses a specific OS" vs. "literally everyone". I mostly only care about the former (the latter includes people that eat tide pods).

Schol-R-LEA wrote:And then you would need government intervention to enforce the rule that no competing standard will come up, just because someone thinks they can either improve on it, or (more likely) con people into think they have.

Well, no. The original idea was to have many competing candidates, where the standard is whichever candidate can be proven to be better. E.g. a "language score" derived from measurements obtained using scientific methods (maybe start with a group of 100 people with no programming experience, teach them the language and get them to implement a series of projects under controlled conditions; and figure out things like the average learning time, the average time to implement things, the initial performance and number of bugs, the time to maintain/optimise, the final performance and number of bugs, etc).

Of course you wouldn't want to do this often (and risk "changing to a slightly better language each week") - you'd only want to choose a new standard language every 10 years or so (it's not like the industry is still in the "early pioneering" phase of the 1960s).


Cheers,

Brendan

Brendan wrote:

Solar wrote:Part of my work involves writing up token patterns, rules, and sequences for a state machine that does a kind of "fuzzy" identification and comparison of address data.

So, you're essentially a secretary who isn't doing any programming, who is typing data (token patterns, rules, ...) for a program written in who-knows-what, for the purpose of matching addresses from 2 different badly designed systems; and because you're a secretary and not a programmer you couldn't be bothered fixing the real problem (making sure the addresses used in both badly designed systems complied with some kind of "universal standard" when they were entered in the first place, so that addresses always match).

Being ignorant, intentionally dense, and resorting to vilification basically disqualifies you from further discussion. That's not "making a point", that's "being a ****".

1) I said "part of my work". I also maintain and improve on all the other parts I mentioned.

2) Those templates could be expressed in e.g. LISP. The controlling scripts could be expressed in e.g. Bash. They aren't, for various reasons, but they could be. The fact that they are expressed in a different language, or that this language is domain-specific, does not make them non-programms, nor does it make me a "secretary".

2b) I take exception at the derogatory way in which you used "secretary" there. Our secretaries do lots of very valuable work, which relieves the programmers from a lot of bookkeeping and red tape. Those are qualified workers in their own right; but they couldn't whip up a name analysis template any better than I could do a quarterly billing.

3) As for "fixing the real problem", you merely proved that you haven't even understood the problem domain. The systems that hold the address data are those of our customers. We support merging of data sets from different customers or sources (e.g. when company A wants to contact all of the new customers they got from the acquisition of company B). We support vetting data (e.g. when people attempt to circumvent "one per customer only" rules by using alternative spellings or mis-spellings of their name and address). We support exactly the "standardizing" of address data that you called for -- to whatever standard is used by the customer in question. We support many similar services, making us one of the market leaders in the business. When you demand "everybody" complying with "some kind of 'universal standard'", it just shows how little you have understood the real world. Those addresses have been entered into computers or filled in into paper forms by real people. Real people can't be "standardized".

3b) I take exception at the casual way with which you assume that your architectural understanding of a problem domain that has been presented to you in a much abbreviated forum posting naturally beats that of a couple of highly qualified people who've actually designed the system. To the point where you feel justified to deride those who've actually worked on the system instead of whipping up a snarky forum post. Aren't you a bit full of yourself here?

I won't go any deeper into your reply, because I don't enjoy technical discussions with people who are a **** about it.

Anyway.

Learning a language isn't the big time / cost factor. But it also does not bring you onto the same level as everybody else as far as communication is concerned.

To my experience, only about 10% of the "talk" in a project is actually language related. The rest is specific parlance of the problem domain and the libraries / packages / modules / algorithms used to model the problem.

I consider myself to be reasonably "fluent" in C++. But that isn't what allows me to do my job. I also know about Unicode, the ICU library, about Boost.Asio, and about the specific data structures used by the software I am working with. In my previous job I knew about stock markets, stocks, options, futures etc., and the data structures that software used to model those.

My expertise in C++ has been "borrowed" by another department two times this year. The first project was about triggering a bunch of PoE cameras over a network, simultaneously, and reading / saving the image data. This required familiarizing myself with the camera manufacturer's SDK; good thing I've worked with hardware SDK's before.

The second project was about optimizing some involved matrix calculations done on image data (not from the aforementioned cameras). That required familiarizing myself with OpenCV, and the mathematics involved. I've never been there, and my math skills are weak, so virtually all the optimization came from parallelizing the algorithm.

All the above are C++ projects. Even for someone fluent in everything the language standard has to offer, there would be a learning curve involved before he / she could take over those projects. There is no way any of these projects could be "standardized" as their problem domains are disjunct. There are countless more problem domains out there -- data storage and retrieval (a.k.a. "databases" / "query languages"), audio processing, process control, graph logic, ... -- the width of which far outweighs any variation in languages used.

Bottom line, changing the problem domain involves much more work than changing languages, and you cannot dream of "standardizing" problem domains. Variation is life. Cope.