Programming Club

[Learning always]

Python also has semantic whitespace, which drives me bonkers. Fortunately since its the best-understood language by chatGPT, and since customGPTs run by business users like me can be given access to an integrated python code interpreter, allowing them to perform automated data analysis without having that data touch the much slower, more resource-constrained LLM, I doubt I’ll ever need to write a line of python again.

Javascript is less loathesome in my opinion but it has some problems to be sure. I myself like Ruby and would love it if duck typing wasn’t so brittle (the frequent need to coerce variables with .to_i or .to_s is indicative of a bad typing system - it would be better to either have the types be statically defined or purely dynamic).

Yes, but if you do systems programming, you won't need JS and Python.
Do you use C for systems programming?

 

[Learning always]

If we're to start a club project, what would you want to build ??

 

[The Liturgist]

Yes, but if you do systems programming, you won't need JS and Python.
Do you use C for systems programming?

For systems programming, primarily C with some use of D, which is a rather nice systems programming language that is underrated; Rust gets a lot of the attention I think D properly deserves (and before Rust stole D’s limelight, that attention was going to Go, a programming language written by Rob Pike’s group at Google, which is a good language, but among the people who tried getting into it when it was very much hyped up, it seems like most of them weren’t clever enough to take advantage of its unique features, which was also the case with the Plan 9 operating system and the conceptually related Inferno OS (which interestingly can run in a web browser as well as on bare metal, and which was intended for the Internet of Things before anyone knew what the Internet of Things was; for example, to justify its development to Bell Labs*, the Inferno developers suggested it could run on advanced desktop office phones allowing for a variety of sophisticated features, and such a phone running Inferno was sold; basically it was a landline smartphone (or technically, a wired smartphone - since IIRC it was not a PSTN phone but rather one that would either be behind a PBX or perhaps connected via some posh Centrex style service, perhaps using ISDN). Go at least has seen some use inside Google if memory serves. Also when doing actual development of embedded operating systems, which usually entails porting an existing open source operating system to a new device (although I do work with Wind River and QNX among other proprietary systems) there is often a need to work with assembler code for the platform, and when developing device drivers, sometimes one has to talk directly to the hardware in question (and since a lot of embedded real time OSes are by design, very simple, frequently they lack the facilities to help you do this that you get with a more fully featured OS like FreeBSD, NetBSD, OpenBSD, Linux, Illumos (formerly known as Solaris) or Microsoft Windows; indeed Windows has a highly developed driver framework which has become more restrictive because the massive crash that happened recently due to a buggy enterprise antivirus product, as documented in this article on ArsTechnica: Microsoft changes Windows in attempt to prevent next CrowdStrike-style catastrophe

Of course, with an embedded RTOS like eCos, there are fewer people trying to hack it, but given what such OSes are used for, security can be very high-stakes; indeed recall how the STUXNet OS was designed to infect Windows workstations in order to upload code to a Siemens industrial computer called a SCADA system that is used in many industries, but the code was specifically intended to change the RPMs in centrifuges being used by Iran’s nuclear project in such a way as to damage the centrifuges and slow down the project; many people regard the US-Israeli design to be the world’s first cyberweapon, but I rather doubt this; rather’ it was the first highly sophisticated attack of its sort which happened to be exposed, probably because getting it onto the computers in question involved, among other things, releasing the Windows malware component of it into the wild, which resulted in security professionals analyzing it and scrutinizing it and eventually the world learned of its true purpose.


*This was during an era when AT&T and then Lucent were increasingly demanding the research be aligned with immediate corporate objectives as the Labs continued their decline from an intellectual powerhouse like a combination of the RAND Corporation with MIT, a place where researchers could focus on research without needing to serve as professors. This decline is a shame, as it left the universities with a monopoly on that sort of innovation, and at its peak Bell Labs gave us much of the vital technology that enables our modern civilization, not just brilliant operating systems like UNIX or brilliant application software for various purposes, but transistors, and also many advances outside the field of telecom and computer science.

 

[The Liturgist]

If we're to start a club project, what would you want to build ??

Well, since you’re Catholic and I’m Orthodox, and a lot of members of the site are liturgical Christians, or are Christians who attend churches that use a lectionary such as the Revised Common Lectionary, I think a generic framework for managing the variable portions of worship services, ranging from appointed scripture lessons to the more sophisticated and elaborate propers of the Catholic, Orthodox and Lutheran liturgies (and also those of some Anglican churches and Ordinariate chruches which in addition to the Collect and the appointed scripture lessons, also use additional liturgical resources, some of which work with the Book of Common Prayer or the Book of Divine Worship, such as the 19th century classics Ritual Notes or the Directorum Anglicanorum, and some of which are used with the Anglican Missal, which is basically an English translation of the old Latin missal with some minor variations.

The key word here is generic - a basic building block type system which could be used by existing projects such as DivinumOfficium.com, CopticReader, the Liturgical Resources Department of the Malankara Orthodox Syrian Church, which currently has a primtive app that only displays PDFs, and the Ponomar Project which has done some automation (of these, divinumofficium.com probably has the most impressive tech, although lately they’ve also had a number of bugs, for example, the system failing to display the text of a mass on an arbitrary date in any format other than the basic low mass (so no text for a solemn mass for dates other than the present, for instance).

A basic text processing system built around managing variable text portions of a worship service, which could be changed in systems using the library either automatically based on the calendar date, or manually based on the preferences of the congregation or celebrant, since for example, the ordinary form of the Roman Missal provides four Eucharistic Prayers (plus a few additional ones for special purposes if I recall) and has several other variable portions, and the 1979 Episcopal Book of Common Prayer is the same (indeed, the 1979 BCP even followed the same sequence as the the Roman Missal in terms of the Eucharistic prayers, so the first one is the traditional Anglican Holy Communion service, the second one is, like the Roman Missal, based on the Anaphora of the Apostolic Tradition of St. Hippolytus, the third one is a variant of the Divine Liturgy of St. Basil, and the fourth one is Eucharistic Prayer no. 4 from the Roman Missal, which was intended for ecumenical celebrations of the liturgy); among more ancient liturgies, Coptic Orthodox liturgy allows for three Anaphoras (Eucharistic Prayers) to be used at the discretion of the celebrant and a large number of Fraction Prayers which are said while the priest breaks the bread, the Ethiopian Tewahedo Orthodox Church likewise provides a choice of around 14 Anaphoras, including one which is a complete, unabbreviated version of the Anaphora of the Apostolic Tradition of St. Hippolytus (documented in the third century by St. Hippolytus of Rome, but we know it was the ancient liturgy of Antioch, which later underwent revisions in wording, and the revised version is still used by the Syriac Orthodox and Maronite Catholics, but is also the basis for the Divine Liturgy of St. John Chrysostom, however, since the Ethiopians use the unrevised version and have done so since the fourth century, it is probably the oldest liturgical text in use in the world in substantially its original form); speaking of which the Syriac Orthodox Divine Liturgy has 86 Anaphoras of which decent English translations exist of around 16 of them.

Conversely, most Eastern Orthodox and Byzantine Rite Catholic (such as the Ukrainian Catholics, Ruthenian Greek Catholics, Melkite Catholics, Italo-Albanian Greek Catholics, the actual Greek Catholics of Greece, among many others) churches only use two Divine Liturgies, plus the Presanctified Liturgy, and when they use them is based on a highly prescriptive liturgical calendar which specifies absolutely everything such as the hymns to be sung at each service, what to do when two feasts such as a movable feast connected to the date of Easter and a fixed feast coincide, for example, if the Annunciation falls on the same day as Palm Sunday or even Pascha (Easter Sunday) - the latter event resulting in a particularly beautiful celebratory liturgy). There are other Eastern Orthodox and Byzantine Catholic anaphoras, such as the Divine Liturgy of St. James, which several Eastern Orthodox churches will celebrate this Thursday, the feast of St. James on the Revised Julian and Gregorian calendars, and the much less commonly used Divine Liturgy of St. Mark, a version of the ancient liturgy of Alexandria (which the Copts also celebrate) and the Divine Liturgy of St. Peter, which uses the Roman Canon, or Eucharistic Prayer 1 as its called in the Novus Ordo Missae.

Now all this complexity need not concern us, since what I propose is not an implementation but rather a toolkit designed to simplify the process of writing automated systems to handle all of the above. Indeed I have a complete set of specifications for this and was working on one before I fell ill; I’m a member of a group called LiturgyWorks which consists of various scholars, clergy and others interested in liturgies, and who have produced a number of texts which will be released into the public domain or in some cases under an open source license such as a creative commons license, but we made the decision to delay releasing them until we had an open source system which could allow for them to be used dynamically. I’ve been working on implementing that with AI, but got sidetracked with research into improving the AI system itself, for example, with biomimetic reproduction like I described above.

The difficulty level for the project is low, since its basically just a content management system adapted for handling liturgical texts, and using AI, we can make the development of it even easier by automating some of the more boring bits of code. What makes it interesting however would be in getting it to work ideally based on using an AI to generate the automation instructions from existing liturgical text books, by reading the rubrics, which would involve interfacing with an AI system (by making API calls to openAI or another provider, or alternately using an open source AI, which I would prefer - and interestingly, chatGPT will let you use it to develop training data for an open source special purpose AI such as one optimized to read rubrics and generate the appropriate text. Doing this using AI makes sense to me, because LLMs are the ultimate pattern-matching software; it’s like having a version of grep, sed, awk, m5, and all the other classic UNIX text processing tools, or equivalent tools some GNU, Linux and other developers use with GNU Emacs, but that one can converse with, in the English language or any number of other languages, even extinct languages such as Akkadian or Sumerian.

By the way my openAi Business account allows me to add people to my team which I would do for any serious contributor to this project, which would provide access to openAI’s Codex system for software development as well as the possibility of working on some of the advanced AI projects I have in mind. I’m presently already planning on adding a third seat to my account, since for various reasons I wound up using both of the two seats my business account requires as a minimum, and a third seat would allow me to let people who I’ve promised to allow see my AIs, such as my friend @Xeno.of.athens , access, and it could also be used periodically by people involved in this liturgical toolkit project.

 

[Xeno.of.athens]

you rang? ;-)

 

[Learning always]

Hello everyone. Would it be okay for me to join this club? Though I have not mastered a programming language, I desire to learn. Currently am reading a book on Python. I love to create things, so I find this all very interesting.

This story might be inspiring: Stories to Share - Friendship Court Edition

 

[Xeno.of.athens]

This story might be inspiring: Stories to Share - Friendship Court Edition

Here's something to look at, it is a python program (some people call them scripts) that Microsoft Copilot wrote for me
it will very likely be too advanced for you at this stage, but it may be useful as time goes by. self learning Python is not too hard if you use the python.org web site and its tutorials.

import hexchat

# Module metadata for HexChat plugin manager
__module_name__ = "SplitLongMessages"
__module_version__ = "1.0"
__module_description__ = "Splits long messages on word boundaries to fit IRC message size limits"

# IRC messages have a strict maximum length of 512 bytes, including metadata like sender and channel info.
# To stay well within this limit and avoid truncation or errors, we use a conservative content limit.
MAX_MESSAGE_LENGTH = 400  # This value can be adjusted for different IRC networks if needed.

def split_message(msg, max_len):
    """
    Splits a long message into smaller parts that each fit within the specified character limit.
    The split is done on word boundaries to avoid breaking words mid-way.

    Args:
        msg (str): The original message to be split.
        max_len (int): Maximum allowed length for each message part.

    Returns:
        list[str]: A list of message chunks, each within the safe length.
    """
    words = msg.split()  # Break the message into individual words
    parts = []           # List to hold the final message chunks
    current = ""         # Temporary string to build each chunk

    for word in words:
        # Check if adding the next word would exceed the limit
        if len(current) + len(word) + 1 <= max_len:
            # Add the word to the current chunk, with a space if needed
            current += (" " if current else "") + word
        else:
            # If the chunk is full, save it and start a new one
            if current:
                parts.append(current)
            current = word
    if current:
        parts.append(current)  # Add the final chunk

    return parts

def on_send(word, word_eol, userdata):
    """
    Hook function triggered when the user sends a message.
    If the message exceeds the safe length, it is split and sent in parts.

    Args:
        word (list[str]): The command and arguments as a list.
        word_eol (list[str]): The command and arguments as a list of full strings.
        userdata: Not used in this script.

    Returns:
        hexchat.EAT_NONE to allow the message through,
        hexchat.EAT_ALL to suppress the original and send split parts instead.
    """
    msg = word_eol[0]  # Full message text

    # If the message is short enough, let it pass through unchanged
    if len(msg) <= MAX_MESSAGE_LENGTH:
        return hexchat.EAT_NONE

    # Otherwise, split the message and send each part separately
    parts = split_message(msg, MAX_MESSAGE_LENGTH)
    for part in parts:
        hexchat.command("say {}".format(part))  # Send each chunk as a separate message

    return hexchat.EAT_ALL  # Prevent the original long message from being sent

# Register the hook to intercept all outgoing messages
hexchat.hook_command("", on_send)

# Print a confirmation message in the HexChat client when the script loads
hexchat.prnt("{} version {} loaded.".format(__module_name__, __module_version__))

 

[The Liturgist]

Here's something to look at, it is a python program (some people call them scripts) that Microsoft Copilot wrote for me
it will very likely be too advanced for you at this stage, but it may be useful as time goes by. self learning Python is not too hard if you use the python.org web site and its tutorials.

import hexchat

# Module metadata for HexChat plugin manager
__module_name__ = "SplitLongMessages"
__module_version__ = "1.0"
__module_description__ = "Splits long messages on word boundaries to fit IRC message size limits"

# IRC messages have a strict maximum length of 512 bytes, including metadata like sender and channel info.
# To stay well within this limit and avoid truncation or errors, we use a conservative content limit.
MAX_MESSAGE_LENGTH = 400  # This value can be adjusted for different IRC networks if needed.

def split_message(msg, max_len):
    """
    Splits a long message into smaller parts that each fit within the specified character limit.
    The split is done on word boundaries to avoid breaking words mid-way.

    Args:
        msg (str): The original message to be split.
        max_len (int): Maximum allowed length for each message part.

    Returns:
        list[str]: A list of message chunks, each within the safe length.
    """
    words = msg.split()  # Break the message into individual words
    parts = []           # List to hold the final message chunks
    current = ""         # Temporary string to build each chunk

    for word in words:
        # Check if adding the next word would exceed the limit
        if len(current) + len(word) + 1 <= max_len:
            # Add the word to the current chunk, with a space if needed
            current += (" " if current else "") + word
        else:
            # If the chunk is full, save it and start a new one
            if current:
                parts.append(current)
            current = word
    if current:
        parts.append(current)  # Add the final chunk

    return parts

def on_send(word, word_eol, userdata):
    """
    Hook function triggered when the user sends a message.
    If the message exceeds the safe length, it is split and sent in parts.

    Args:
        word (list[str]): The command and arguments as a list.
        word_eol (list[str]): The command and arguments as a list of full strings.
        userdata: Not used in this script.

    Returns:
        hexchat.EAT_NONE to allow the message through,
        hexchat.EAT_ALL to suppress the original and send split parts instead.
    """
    msg = word_eol[0]  # Full message text

    # If the message is short enough, let it pass through unchanged
    if len(msg) <= MAX_MESSAGE_LENGTH:
        return hexchat.EAT_NONE

    # Otherwise, split the message and send each part separately
    parts = split_message(msg, MAX_MESSAGE_LENGTH)
    for part in parts:
        hexchat.command("say {}".format(part))  # Send each chunk as a separate message

    return hexchat.EAT_ALL  # Prevent the original long message from being sent

# Register the hook to intercept all outgoing messages
hexchat.hook_command("", on_send)

# Print a confirmation message in the HexChat client when the script loads
hexchat.prnt("{} version {} loaded.".format(__module_name__, __module_version__))

It would be good to know which members are able to read that easily and who is not, because those who can are in a position to tackle more sophisticated projects.

By the way, my understanding is that MS is licensing parts of copilot from openAI.

Now, I myself find python extremely readable, especially compared to Perl scripts which have a tendency to self obfuscate, but aside from its problematic type system, I strongly prefer Ruby. Perhaps I just really like case statements (which we call switches in the more civilized world of C and its memory managed derivatives - the python alternative of a dispatch dictionary just isn’t pretty to me).

 

[Xeno.of.athens]

It would be good to know which members are able to read that easily and who is not, because those who can are in a position to tackle more sophisticated projects.

By the way, my understanding is that MS is licensing parts of copilot from openAI.

Now, I myself find python extremely readable, especially compared to Perl scripts which have a tendency to self obfuscate, but aside from its problematic type system, I strongly prefer Ruby. Perhaps I just really like case statements (which we call switches in the more civilized world of C and its memory managed derivatives - the python alternative of a dispatch dictionary just isn’t pretty to me).

a dispatch dictionary is a little "pythonic". But it makes sense

 

[The Liturgist]

a dispatch dictionary is a little "pythonic". But it makes sense

Indeed, like all Python. Although I would rather they had avoided the “elif” than the switch or case statement. A part of me would love to write some macros to generate python from a more sane language, which is possible, thanks to LLMs, but comversely, thanks to llms its no longer required, since an LLM, as I often like to say, is the ultimate expression of UNIX command line tools, and where I/O would become excessive, chatGPT can generate python code on the fly to “automate” its own work and then let thar do the work using the code interpreter subsystem without touching the slow AI part of the code (provided it can execute within a few minutes … anything more extensive than that and you can have it instead write code in an appropriate language to do the job for you).

 

[linux.poet]

*looks up from reading Java Server Pages textbook* Oh, wait, I actually know how to program things. I have to say my main languages of choice have been Java, HTML5/CSS3, PHP/Wordpress, XML, SQL, and whatever edition of JavaScript that I’m supposed to know. *points to Certificate of Proficiency in Web Development on the wall as a premature defense against imposter syndrome*

I learned some C and Python in college, and I have some books on C# that I could get around to reading. So questions for smarter programmers than me:

Best programming language to develop an application for Windows?
Best programming language to develop an application for Linux?

I have a pipe dream program to make that I want to be cross-platform. However, if I can develop it, it will save me thousands of hours of labor and is probably worth at least a million bucks. I need a language that will run into an exe and/or linux repo.

I think C will work, but perhaps Python and C# are better choices to save on development time? This application needs to handle text, images, and PDF files.

 

[The Liturgist]

Best programming language to develop an application for Windows?
Best programming language to develop an application for Linux?

Without wanting to seem coy, the answer depends on what you’re trying to program, because some programming languages let you write a simple program very fast, and some applications require performance or specialized libraries. For example on Linux a lot of applications can be quickly programmed by using simple shell scripts and pipelines to connect the output of existing text processing tools. For example, you can take the output of one program, pipe it through grep to match a pattern, pipe it through sed to change that pattern, and then use the > character to output this to a new file (the only place where pipelines don’t work as well is editing files in place, although with some difficulty you can use ed to edit a file in place and control it with a pipeline, but it wasn’t meant for this; another problem is without a special program to sit in the middle, pipelines won’t wait for an EOF before processing the input, but will start processing it immediately; usually this is OK, but there are some cases where you might want the full file before you start working on it. There is also the awk programming language, which is a mini programming language that runs in the shell, although by the time you are using awk, you should probably be using python (historically Perl was written to replace awk for advanced text processing in the command line, but Perl is easy to write but hard to read; Python and Ruby were both written as Perl replacements with a focus on being more user friendly, and most importantly, producing easier to read code). While I was rooting for Ruby, Python won, but then Javascript became a viable language, and Ruby remains an option.

For general purpose programming on both Windows and Linux, the broadest support right now both in terms of learning resources and library support is for Python, and you can also now write applications in Javascript, thanks to Node.JS

GUI development is possible with Python, Perl, Ruby, .NET, Java, as well as the old standard of C++. Microsoft .NET languages such as C# run on Linux; .NET first being ported by Novell as Mono, but then, Microsoft acquired it and now publishes .NET for Linux themselves. The open source .NET Microsoft publishes also runs on other major open source operating systems like FreeBSD*.

I would advise against using PHP for any further web development, since both node.js and Python are superior platforms for backend programming (and with node.js, you’re using Javascript for both your backend and front end, and the idea is you’re less likely to make a mistake programming in one language rather than two), and PHP is a brutal language, in my opinion, not one I’ve ever beeen impressed with.

If you know Java, it is still widely used and supported (the main version of Minecraft is still being developed in Java and serious players prefer it to the other versions), and Java is particularly loved for enterprise applications of various sorts, including a lot of bloated systems running on application servers that give sysadmins who have to deal with them migraines.

Also other languages like Python, Ruby, Lisp (Clojure), and Scala, the latter two being particularly nice, run on the Java Virtual Machine.

*Most of what works on Linux works on FreeBSD, and most of what works on FreeBSD works on OpenBSD, NetBSD and Illumos (Solaris); also there are a few other workable open source operating systems; GNU finally got their Hurd kernel to a usable level, and there is DragonFlyBSD which has an interesting and elegant cluster filesystem. I myself prefer FreeBSD and OpenBSD to most Linux distributions, because OpenBSD has networking software I want and the most secure web server built in; the security on OpenBSD is superb, FreeBSD on the other hand is often faster than Linux and was the second OS after Illumos/Solaris to have ZFS, and FreeBSD’s jails are better in my opinion than most Linux containers, and certainly simpler. FreeBSD’s ports system of automatic compilation of a huge library of software with dependency resolution was the inspiration for the portage system that makes Gentoo famous, except with FreeBSD you don’t have to use it as it also provides binary packages.

But the main reason I prefer the BSDs is they don’t have systemd or a few other features most of the major distros on Linux now have, with some prominent exceptions.

 

[The Liturgist]

I have a pipe dream program to make that I want to be cross-platform. However, if I can develop it, it will save me thousands of hours of labor and is probably worth at least a million bucks. I need a language that will run into an exe and/or linux repo.

How computationally intensive is the program going to be? Do you have any idea about that?

Also if you don’t want people reading your source code, you probably want a compiled language, at least at the bytecode level like Java or C#, or perhaps a full compiled language. There are several very user friendly languages that are fully memory managed and produce fast binaries; D is my favorite, but Rust and Go are also very popular, especially Rust. D I particularly like, and a friend of mine is one of the leaders of the D community and wrote several libraries for it; its almost infinitely easier than writing C++ code, and also easier than writing C code, which I have to do * a lot * for my job, developing embedded systems, many of which are running on real time operating systems (in some cases I have to use assembler, or assembler in C, but in all cases careful manual memory management is required). When I don’t have to do manual memory management, I rejoice.

However, if you don’t need the performance, or the obfuscation of your code, that a compiled language provides (and of course, compiled applications like C++, Rust, D, Objective C, Java, C# and so on, can be decompiled), if I were you, I would use Python or one of the Javascript client side options like Node.JS since you already know that.

But if you’re good at Java, you should probably just do that frankly; its probably fast enough for your program, it runs on Linux and Windows and many other platforms, its GUI output has been fully modernized and is now superb, and also, you can use other languages on the Java VM, like on the .NET VM, such as Python, Scala and Clojure, which if you learn them can speed things up. Although I should say the Java implementation of Python is not guaranteed to be compatible with the vast array of libraries people have written for Python, which are the other major reason for using Python - it has a fabulous array of boutique libraries for doing absolutely everything.

However Python programs are scripts, so unless you take special measures, people would find it easier to steal your intellectual property, but they’re going to do that anyway if your software is as good an idea as you think, which it might well be.

Another thing you should consider by the way is that these days, it is increasingly important for Windows for software to be available via Microsoft’s Windows Store, their App Store rip off. It seems probable that Windows will eventually stop allowing users to easily install software not published in that way; I believe this is already the case on some platforms, just as Apple forces you to either jailbreak your iPad and iPhone or run only software from their App Store (and even the Google based Android phone is locked down, the open source Linux kernel notwithstanding).

By the way - you should also consider whether your application could be delivered via the web, because doing that solves the problem of portability to different operating systems altogether. Its also the only way to completely block people from being able to steal your backend code - if your web server is properly secured, since the backend code on a web application is hidden from users, so unless you encode your core application logic in the front end, which obviously one should not do in your case, it would work very well.

 

[The Liturgist]

I think C will work, but perhaps Python and C# are better choices to save on development time? This application needs to handle text, images, and PDF files.

Don’t use C for that. C is not good at handling text. C is good for writing device drivers and kernel modules where memory has to be managed manually, and occasional assembler is needed to send specific bits of code to the hardware to handle device interrupts. In fact, C is notoriously unpleasant for handling text, except compared to languages that predated it, but C strings are buggy and often lead to memory leaks, buffer overflows and other problems, since any string of characters your program accepts from a file or user input, you have to allocate memory for it, and then remember to de-allocate that memory when you’re done (or else your program has a memory leak) and you also have to control the input the user makes or they can do a buffer overflow attack and use your program to hack the computer its running on, or such overflows can happen accidentally, crashing your program.

Python and C# (and Java, which you indicated you knew) are infinitely better for what you’re talking about. Python also has a very large array of image processing libraries (but Java, C# and the various Javascript platforms like Node.JS, and also Ruby, are fairly competitive).