Website Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • August 30, 2015, 11:45:20 PM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: which programming/scripting language has the largest number of functions?  (Read 2077 times)

kalos

  • Member
  • Joined in 2006
  • **
  • gravatar avatar
  • Posts: 1,369
    • View Profile
    • Donate to Member
Hello!
which programming/scripting language has the largest number of immediately available functions?
either built-in or in repositories
Thanks!

Renegade

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 12,785
  • Tell me something you don't know...
    • View Profile
    • Renegade Minds
    • Donate to Member
That's a bit of the wrong question to ask. It all depends on what you want to do.

Perl has a massive amount of software available for it. Similar with PHP. There are tons of libraries in JavaScript as well. Then again, C/C++ has a huge number of tools written for it.

And all of those languages serve different purposes that none of the others are really suitable for.

It makes more sense to ask, "I want to do X. What languages are suitable for that and what are the advantages of each?" One of the advantages for a language is having a large amount of ready-to-use code for it, like PHP or C, etc., in the form of either code or libraries.

Does that help to kind of answer what you were wondering?
Slow Down Music - Where I commit thought crimes...

Freedom is the right to be wrong, not the right to do wrong. - John Diefenbaker

kalos

  • Member
  • Joined in 2006
  • **
  • gravatar avatar
  • Posts: 1,369
    • View Profile
    • Donate to Member
okay, I want to do all the basic stuff, like text manipulation, calculations between numbers, dates, file operations, etc with as many functions as possible prebuilt, so I wont have to built my own

also, I want to interact with other GUIs (manipulate and automate them), do data binding easily, and ability to organize files

also, I want to easily create GUI

last, I want to save standalone exes and store files in them, able to take relatively big amount of data (some 10s of MB)

4wd

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,963
    • View Profile
    • Read more about this member.
    • Donate to Member
AutoIt or AutoHotkey

last, I want to save standalone exes and store files in them, able to take relatively big amount of data (some 10s of MB)

Do you mean you want the resultant executable to contain data as a resource within the executable?

ie. The data is extracted out of the executable at runtime.

And if so, static (the data will not be changed after compilation) or variable (self-modifying executable)?

kalos

  • Member
  • Joined in 2006
  • **
  • gravatar avatar
  • Posts: 1,369
    • View Profile
    • Donate to Member
- Do you mean you want the resultant executable to contain data as a resource within the executable?
yes

- static (the data will not be changed after compilation) or variable (self-modifying executable)?
variable

4wd

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,963
    • View Profile
    • Read more about this member.
    • Donate to Member
- Do you mean you want the resultant executable to contain data as a resource within the executable?
yes

This you can do with AutoIt, (I've done it), although I don't know exactly how big a resource you can embed.

Quote
- static (the data will not be changed after compilation) or variable (self-modifying executable)?
variable

This will be very hard to do using AutoIt - I don't think anyone over on the forums has done it.  The only way I can think of without recompiling each time is to directly write the changed data into a copy of the original executable but that means you'll be stuck with a fixed data size, (and who knows what else needs to be taken care of - beyond my knowledge).

The only other way of doing it that I can think of is a self-modifying, self-extracting archive which should be possible using 7zip, WinRAR, WinZIP, etc.

Is there a specific reason why the data has to be embedded within the executable?

kalos

  • Member
  • Joined in 2006
  • **
  • gravatar avatar
  • Posts: 1,369
    • View Profile
    • Donate to Member

Is there a specific reason why the data has to be embedded within the executable?


for archiving, portability, flexibility, availability, etc purposes

the documents (files) should always accompany the executable and should be immediately available

4wd

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,963
    • View Profile
    • Read more about this member.
    • Donate to Member
the documents (files) should always accompany the executable and should be immediately available

I think your best choices are either a self-repacking archive or just having the files in the same directory.

For the archive you make it self-extracting with a batch file that runs following extraction that will run your program, wait until it closes, then repack the archive with changed data.

That's the easiest way I can see of doing it but someone else probably has a better idea.

Stoic Joker

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 5,878
    • View Profile
    • www.StoicJoker.com
    • Donate to Member
the documents (files) should always accompany the executable and should be immediately available

I think your best choices are either a self-repacking archive or just having the files in the same directory.

+1 - f0dder did a great job with the self editing password storage utility fskrit, but... It requires some rather tricky shenanigans with the temp folder to pull off. I really don't think that it would be safe - which he also expressed - for a complex data storage application.

The OTF unpack/repack sounds good, but it also mandates a pristine exit to avoid data loss (eek!).

Same directory storage would also allow for much more flexible development options as you wouldn't be tied to something that offered low level system code access.

4wd

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,963
    • View Profile
    • Read more about this member.
    • Donate to Member
The OTF unpack/repack sounds good, but it also mandates a pristine exit to avoid data loss (eek!).

I wasn't going to mention that aspect because there's absolutely no way to guard against it - it's just part and parcel with the whole 'self-contained' thing.

You could bundle up the executable and it's dependant files using something like Cameyo but having your data separate in the same directory is a much better option than bundling it.

Shades

  • Member
  • Joined in 2006
  • **
  • Posts: 1,853
    • View Profile
    • Donate to Member
Cameyo isn't that great. Although for your eye the app you have 'Cameyo'ed' stores everything in the same location, it does create a VOS folder in your user's data folder with a lot of info in there. Understandable, as it will make functioning of 'cameyo'ed' applications a lot easier. However, don't be completely "fooled" by the concept that everything is really stored in one folder only.

Don't know about other, similar to Cameyo applications, so no comment there.

4wd's post above is spot on, that is the best way to go.