Magic Programming Language Tutorial

76 views
Skip to first unread message

Elva Stuller

unread,
Aug 3, 2024, 5:08:11 PM8/3/24
to lgatekchettio

I have recently heard about Magic programming language from several sources and didn't recall ever hearing about it before. It was mentioned that it is a programming language from Israel.I did some googling and couldn't find much information about it. I couldn't find any code examples, and wikipedia didn't have any information on it either. I think this is the site for it =70 though I am not sure, as it mentions uniPaaS instead of magic. However other material on the site indicates that this is the new name for it.

I was interested in learning more about it from it's practitioners, rather than the company. I saw several claims on the internet that it provided really fast application development, similar to claims made by RoR proponents when it came out.

You're right my friend, Magic is the original name of the "programming language", nowadays is called UniPaaS (Uni Platform as a Service), I use it to develop some business application. Maybe is the fastest way to create an applications(data manipulation), you can create apps in just a few days, but like everything in life has its own drawbacks:

As PachinSV explained, there is a RAD once called Magic, then eDeveloper, now UniPaaS. This RAD is dedicated for database applications. Programming in this RAD does not look like anything else I know, you mostly don't write code as with usual languages, but it is nearly impossible to explain just with words. The applications are interpreted, not compiled.

As PachinSV said, when developing, you must follow UniPaaS' way of doing things. This is probably why so many people never manage to use Magic properly: if you thought like Magic before learning about it, then you will adapt to it easily; but if you have a long and successful experience using other database development tools, then often the Magic paradigm will never become natural to you. The learning curve is quite steep, you must learn a lot of things before being able to write a little application.

Previous versions stored the "code" inside a database table. The last version, UniPaas stores the code in xml files. I could send you an example, if PachinSV does not answer you before. But the files are pretty big: the smallest xml file I have in a test app is 4000 bytes, and any application is made of at least 11 files, an empty application is 7600 bytes. You must also understand that developers never use those files (they are undocumented AFAIK), they are only the storage format used internally by UniPaaS. The only way to use them is to set them up as a UniPaaS application.

I'm still an active MAGIC Developer... This is the old name used and its a completely different paradigm like some of you mentioned. I've been developing it from Magic version 8.x to eDeveloper 9.x to 10.x then renamed to UniPAAS.

The newer version is much easier to use and it is still very RAD in the sense that there is little or no code you write... a lot of the common programming tasks like IO, SQL command...etc is handled by the tool and is transparent ( so even less code to write since we use it in almost all types of applications)... Its mostly an Enterprise tool... you wouldnt use it for small application... You can download the free version to learn the paradigm... but the enterprise licenses are expensive.. you need both the development tool and the runtime license if you want to deploy... so it can be costly for small scale projects...

I enjoy it personally, especially when you have to do quick proof of concepts or a quick data migration or porting onto any db platform and bridging any existing system through a wide range of gateways they provide with the licensed version.. It is up to date with the commonly used web technology out there...like SOAP, RIA ...

It's more popular in Europe... The HQ in the States is in Irvine... we used to have 2 branches in Canada but it closed down in 2001 .... Visit the Magic User Group on Yahoo... Its a very active forum with lots of cool people who will help you out in your quest...

I Programmed with Magic for 6 years and found it to be a amazingly fast tool, easy to understand if you are a competent database programmmer because all operations are really about data manipulation. It is certainly a niche area develop in and because of this jobs are few and far between. As it is interpreted there are really no bugs to make. It will work with many databases/connections simultaneously but there is a big memory and processing hit.

It is exactly this: FAST, FAST, but expensive and rigid in what it will allow you to do. It works on a tick tack toe like matrix. Dropping in commands into the various sections determines when they are run. The middle column is run indefinitely until you break the cycle. It is like a do Until loop. If you have to do an item once you put it into this infinite loop and end it after one cycle.The first column procedures are run first, ONCE, before the infinite middle column is run. The 3rd column of commands is run after the infinite cycle, once. It is very efficient and logical once you get over the idea of an infinite loop.

Types can be specified and an associated program to present the type. Then everywhere the type is used all the settings automatically kick in. I like especially that one can write the program and 5 months later change the name of a variable and it is carried throughout the program. In fact the program does not use your name for anything. The internal name of any and all variables is hidden to the end user, so of course it is not a problem to change a name. It takes a minute to write an input program for any table. It takes a minute to write an export/import program for all the data files in the database.
Attaching to a type of database like Btrieve or SQL independent of the program itself.

I stopped using the language because they demand more for the runtime engine than I could charge for the programs I wished to run with it. Bill Gates went the opposite direction. VB is superior in control and being able to drop `10 datagridviews onto the same screen, but development is 10 times slower.

It's niche then is PROOF of concept for a program in a big company or conversion, importing, exporting for a development company. It is good for $25k programs that are database heavy and not going mobile.

Coincidentally, if you want to get an idea of what it is and how it works, I've found that comparing it to MS Access is handy. It works in much the same way from a user's or developer's perspective. Obviously what happens in the background is vastly different, but if you've ever developed a form in design view in Access, Magic will seem very familiar.

The idea is that I want to be able to make a magic system where spells can be created like software developers create programs in a programming language. Imagine you sit down, type up some code in functions that describe various sub-functionality of the spell within the magic system, then those pieces are composed together to create a working spell.

Without predefined objects defining what a spell is and does, you do not have a spell crafting programing language, you just have a programing language. Your primitives are the basic building blocks of your system that tells the end user what abilities are at his disposal. So, all the code responsible for a spell would fall inside of this system of object classes that can be bound together to make a spell. Your Primitives are used to set both the ability and limits on spells; so, if I want to include teleport spell, the primitive called teleport would include inside it not just the code for moving a character between points, but formulas for determining mana cost, cool down timers, range limits, etc.

While this is generally a good idea in programming, it is 100% essential for any system that gives an end user this much access to parts of how your game runs. In short, you will want your primitives and game engine completely isolated from your magic programming interface by an API such that making a spell means using just the primitives and interfaces that the game's developer has given you. If a fire-attack has certain properties and procedures for establishing cost and potency, you don't want users to have access to change these properties and procedures. You just want them to call and extend on them. Red-stone programming is a good example of this. It does not let you change how minecraft works, it just lets you take certain things that you can already do in the game and build procedures to do it in useful patterns.

The difference between a spell crafting system like you see in Elder Scrolls and a spell programming system would be the ability to string things together in logical and repeatable operations. Including things like logical operators (and, if, or, etc.), recursive operators (while, for, goto, etc.), and the ability to define your own variables with your spells will allow players nearly infinite access to manipulate the logic behind spell casting.

Another feature I would suggest is to make spells able to be encrypted, shared, and sold. Most players will not want to program thier own spells in this much detail, but those that do will love it, and be able to make very advanced spells this way. By letting people hide the code of thier own spells to other players, it would encourage them to sell high-end spells on the community market.

You can see that there is a lot of control here to make unique and quite intelligent spells, but no where does this say what the spells will cost to cast or let you directly manipulate the environment. So, your game interface will need to calculate and output those details for you; so, if I were to sell you these spells, your spell book might look like this:

Yes, first place I remember seeing something like that is in the magic crafting system in Elder Scrolls:Oblivion. Basically you could combine any combination of spell properties to create custom spells and the difficulty to cast the spell was based on what properties you gave it. So, you could take a fire spell and decide if you wanted it to be touch or ranged, add a blast radius if you want it to be AOE, and you could then add a DoT property if you wanted it to burn instead of do all the damage at once, etc. and all the different properties of a spell either made it more or less expensive to cast so you could balance it however you wanted it.

c80f0f1006
Reply all
Reply to author
Forward
0 new messages