Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In any operating system, which programming language is the most oriented to perform actions, such as:
Delete files from the computer
Add files to the computer
Unzip files automatically
Having many files like 01file.jpg - 02file.jpg, rename them all automatically using regular expressions (this point is very important to me)
And many things like that, which include automating actions that are regularly very tedious to perform.
I do not need the most "appropriate" language, but the one that is generally used for these purposes.
Choice of programming language is obviously a combination of technical factors and personal tastes. However, there are many strengths to Python for doing the tasks you mention in a way that is very portable between different operating systems. The "os" module contains lots of functions for adding/removing files and directories, renaming files, etc. Similarly, the regexp module allows replacing chunks of strings using regular expressions. As for zipfiles, there's a module for that too.
Any language can do these things really, so pick one that you’d want to learn. Python comes by default with lots of libraries, I believe including zip file manipulation, so it may be easier to get going.
From your question, I've inferred that you are looking for a language that is portable and easy to use with low friction in order to perform the operations that you mentioned.
If you mostly work with UNIX-based systems such as macOS and Linux, then shell programming might be a good option, especially considering the basic tasks you require.
The advantages of using the shell is that it's very well suited for the tasks you mention, you can easily alternate between automating your tasks with a shell script or just issuing commands as needed. The syntax can be a little bit surprising for beginners, but for your purposes, you wouldn't need to learn much.
The disadvantages are that there can be small but subtle differences between Operating Systems between commands, so you would need to know about these differences if working on these different platforms was important to you. Also, while you could get a shell like bash to work on Windows, it's nowhere near as convenient as on a UNIX-based OS.
If cross-platform compatibility was very important to you, then using a higher level general-purpose language like Python might be a good option. It has the advantage of being mostly consistent across platforms and abstracting away the differences.
The disadvantage there is that you might need to install Python depending on the platform that you have and you would lose a little bit of the interactivity and flexibility that the shell provides you with. On a UNIX-based machine, you're pretty much in a shell as soon as you fire up your terminal and ready to issue commands, so there is very little friction.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
Around 15 years ago, I was writing .xll addins for Excel using the C-API, mostly for spreadsheet formulae (complex and time-consuming calcs), and written in C++ (very much my preferred language). I subsequently did a few things with C# wrappers.
After a long break, during which Excel and Visual Studio have moved on apace, I am once again looking at building an addin to use compiled code for a lengthy optimization, rather than using a VBA script. The optimization involves taking large arrays of data out of worksheets, crunching then and then writing the results back into the workbook (as I want to chart them etc later).
NB. This is for my own use, I am not planning on distributing any solution
In pseudo Excel VBA code what I'd like to have is something like this:
Dim obj as MyOptimizer
Dim rngInputData as Range
obj.SetData(rngInputData)
obj.Optimize
Dim v as vOutputData
v = obj.GetResult
I am a little bewildered by the options available (in no particular order):
code a C-style dll with a VBA xla wrapper
code a C-style dll with an Excel.DNA C# wrapper
code a COM object of some sort (though I am not sure with Visual Studio template to use)
Something else ...
A COM object has its attractions as it will hold state, and I can create an instance of my object without having to write a clunky handle-passing system. The other consideration is the amount of marshalling between different layers (I'll be using a lot of 2-D arrays, though only of doubles), and the type-checking of the inputs.
I'm looking for some guidance at this crossroads, before I go down the rabbit hole of one particular method ... then of course, I'll be back with more questions!
Thanks!
If C++ is still very much your preferred language, you should certainly consider that. It will give the the best performance possible, and leverage your knowledge of the C API. If you can afford it, I would also recommend you have a look at the XLL+ library. While expensive, I think if you look at the features you'll find it brings a lot of value.
I develop Excel-DNA and very much prefer to avoid C++ in favour of the .NET platform.
So, while biased, I think it will be an even better fit for your requirements. It is a vastly easier environment to work in compared to C++ (in my opinion - no XLOPERs!) However, there is some overhead in the marshaling and so you'd have some compromise on the performance. You don't indicate what range sizes or how fast you expect the interchange to happen. With Excel-DNA, I expect you can easily read, process and write a block of a million numbers in about a second (see my answer here: https://stackoverflow.com/a/3868370/44264). Similarly, a small block of 10 cells with numbers can be read and written more than 10,000 times in a second. Things will get a bit slower if you are working with long strings rather than numbers, but you suggest this is not the case.
While you should expect calculation code (apart from the Excel interop) to be very fast with C# and .NET, you can also talk to C libraries from .NET very efficiently. So having core calculation libraries in C and the use the P/Invoke mechanism to interact to them from .NET is a completely viable plan, and you still get the (large) benefit of a more pleasant environment for the Excel parts.
VBA and COM approaches to reading / writing with Excel will not perform quite as well as the Excel-DNA / .NET approach (which also uses the C API for this kind of thing under the hood, rather than COM). Still, when used properly the COM overhead is not terrible, and might not on its own be a showstopper for you.
I am interested in this kind of optimization approach myself, so would be happy to help if you do take the Excel-DNA approach. The best place for Excel-DNA questions is the Excel-DNA Google group.
Getting started with Excel-DNA would look like this:
Download and install the (free) Visual Studio 2019 Community Edition.
Select the Desktop .NET Development workload when installing. You don't need to check the Office options when installing for Excel-DNA add-ins.
Then make a new C# "Class Library (.NET Framework)" project. It's important at this step not to pick ".NET Standard" or ".NET Core" (long story...).
Then in your project install the "ExcelDna.AddIn" package from NuGet.
Read and follow the instructions in the readme that pops up.
Paste in the code snippet from here: https://stackoverflow.com/a/3868370/44264 press F5 and test in Excel.
After the slow Visual Studio install, it will only take a few minutes, and you'll get some idea of what's involved.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Almost all conventional languages today represent programmers intention as text source, which is then (lets say for sake of simplicity) translated to some bytecode/machine code and interpreted/executed by a VM/CPU.
There was another technique, which, for some reason, isn't that popular theese days: "freeze" the run-time of your VM and dump/serialize the environment (symbol bindings, state, code (whatever that is)) into an image, which you can then transfer, load and execute.
Consequentially, you do not "write" your code in a usual way, but you modify the environment with new symbols, while in "run-time".
I see great advantages to this technique:
Power-boosted REPL: you can introspect your code as you write it, partially evaluate it, test it directly and see the effects of your changes. Then roll back if you've messed up and do it again, or commit it to the environment finally. No need for long compile-run-debug cycle;
Some of the usual problems about dynamic languages (that they cannot be compiled, as compiler cannot reason about environments statically) are obliviated: the interpreter knows where what is located and can subsitute symbol references with static offsets and do other optimizations;
It's easier on programmer's brain: you "offload" different contextual information about the code from your head, i.e. you don't need to keep track about what your code has already done to some variable/data structure or which variable holds what: you see it directly in front of your eyes! In the usual way (writing source), programmers add new abstractions or comments to the code to clarify intents, but this can (and will) get messy.
The question is: what are disadvantages of this approach? Is there any serious critical disadvantage that I am not seeing? I know, there are some problems with it, i.e.:
try building a module system with it, that will not result in dependancy hell or serious linkage problems
security issues
try to version-control such images and enable concurrent development
But these are, IMHO, solvable with a good design.
EDIT1: concerning status "closed,primarily opinion-based". I've described two existent approaches and it is clear and obvious that one is preferred over another. Whether the reasons for that are purely "opinion-based" or there is a reasearch to back this up, is unknown to me, but even if they are opinion-based, if someone would list these reasons for such an opinion to develop, it should, actually, answer my question.
As a daily user of smalltalk, I've to say I haven't found any fundamental disadvantages and have to agree that there are lots of advantages.
It makes metaprogramming, reasoning about your program easy, and much better supports refactoring and code rewriting.
It requires/develops a different way of looking at your code, though. Smalltalk has little to offer to developers who are not interested in abstraction
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
My team is tasked with implementing Unicode in our software, which is well over a million lines of code. We support an MFC Client and a Server on Windows, AIX or Solaris with an Oracle or SQL Server database. ICU looks like a very helpful tool. What are the pros and cons of using ICU? Does ICU work as advertised without major bugs?
A data point: Our (yes, that's a disclaimer) list of users and bugs is all on our project site.
IMBO (biased):
Pros:
works as advertised, comprehensive.
Mature: 10+ years now, with a good stability policy and very active development.
Uses latest Unicode+CLDR+BCP47+other standards.
Compiles basically everywhere. C/C++/J and called by/implements python,perl,php,…
Open source, with an increasing diversity of contributors.
Comes with all needed data for the above (see below, under cons), yet customizable. (can add custom data)
Cons:
Needs better documentation (we try- anyone want to help?).
Lots of APIs- "it's too big #1" hard to know which one to use, even if it does what you want.
Used by lots of types of programs, from embedded devices, smartphones through major desktop apps through databases and operating systems and enterprise apps: So, there may be multiple ways to do something.
Comes with all needed data for the above! "it's too big #2" (see above, under pros), yet customizable. (can be trimmed down to size)
ICU is terrible: avoid if at all possible.
Despite its age, basic things in it are broken, for example in this question: Fixing regex to work around ICU/RegexKitLite bug
Time handling is broken as times are underspecified: you can't distinguish a DST from a non-DST time in a reliable way in many APIs.
It's freaking huge.
The documentation needs a lot of work. Less-used features are often unusable because there's no way to figure out the right way to use them. I spent days trying to get transliteration to work as explained and eventually gave up.
It likes to work in UTF-16, the worst of all possible worlds.
Support is unresponsive to problems.
In my experience, it's not until you're most of the way through a project that you begin to discover the insidious flaws that will take 90% of your time.
For many people, there is no alternative so you're stuck with it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Now that Apple relaxed the restrictions on developer tools/programs, I wonder what tempts developers to other languages than Apple offers by default, Objective-C, which is quite fun to program with. What missing feautures makes you not to program with it but something else?
Lack of Objective-C expertise or a large/complex code base in another language would be among common reasons.
Cross-platform coding might well be another.
I haven't done any iPhone development yet, but generally speaking, here's a few reasons:
Cross-platform development
The other language suits your coding style better
The other language is a better tool for the job
You are comfortable in the other language and don't have the time / budget / motivation to learn Objective-C
Existing libraries / codebase
Specific tools you might want to use
Testing some concepts in Objective-C can sometimes be kind of tedious to set up. Sometimes you just want to see how a single method works or play around with an object's functionality to see how it works.
Setting up a new project is somewhat tedious, and it's not always feasible to incorporate the test code in to a new project.
In this case, I do one of two things:
Keep an empty project around specifically for testing things
Drop down to the Terminal and use irb (or PyObjC) to play with the objects in Ruby or Python.
In a nutshell, the thing that's missing is the ability to use Objective-C in an interpreted manner. You have to use another language (like Ruby or Python) to do this.
I recently wrote some networking code in Python, then had to translate it into Objective-C for use on the iPad. A typical line of clear Python would become five or ten lines of busy-work C. I just work faster in higher-level lanugages; the language puts up less resistance, requires fewer forms to be filled out.
I have ported a couple of tiny language interpreters (for my own use, not for App store distribution) to the iPhone. This allows me to write short snippets of code on the road, without having to carry my Mac, and run them locally. I don't know of any small Objective C interpreters, and the language is not really designed for interactive use.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have the opportunity to take a two day class on Perl 6 with the Rakudo compiler.
I don't want to start a religious war, but is it worth my time? Is there any reason to believe that Perl 6 will be practical in the real world within the next two years? Does anyone currently use it effectively?
Update
I took the class and learned a lot. However, after day 1, my mind was a bit overwhelmed. There are tons of cool ideas in Perl 6, and it will be neat to see what filters up to other languages.
Overall the experience was a positive use of my time, though I wasn't able to absorb as much on the second day. If it were a three day class it would have been unproductive just because there is a limit to how much you can process in a short amount of time.
If I had a training opportunity like this, I'd take it. Even if it was COBOL.
I look at training opportunities as not only an opportunity to learn the highlight technology, but as an opportunity to learn new ideas, concepts, platforms, language (just to see how something else was implemented) and finally, to meet new people.
I think that any training is likely worth my time. Especially if the cost is going to be covered. In a training class, you'll often learn (or relearn) material that could be applied in your language of choice.
Note: It's probably worth me noting that I take a very academic look at software development and programming languages.
This has been answered, but I'll step in:
Rakudo Perl 6 is the de-facto implemention of Perl 6 right now. It has the most features, the biggest community and an impressive rate of development. The first "1.0" release, Rakudo Star, is planned for April 2010.
Perl 6 also runs on Parrot, which is a virtual machine already capable of running another couple dozen languages, including Python. The scope for multiple languages interacting and calling each other's modules/APIs is pretty huge.
Even if you don't plan on using Perl 6, the scope of the language is so broad, and contains so many new or borrowed-but-not-yet-mainstream paradigms, that it will have an undeniably huge effect on other scripting languages. It's worth becoming familiar with it for that reason alone.
How could learning Perl be BAD for you? Is there any cost you have to weigh against the benefit of learning (OK there is are the obvious ones of time and money, but if those aren't too bad, what else could there be to hold you back)? IMO, learning things is ALWAYS good. ;)
If you want to use any version of Perl, then Perl 5 is the way to go. I don't think anyone is using it outside of experimentation. However, Perl 6 and its Parrot VM have a lot of potential as part of a "fourth way" platform for dynamic languages between the current choices of "run it in its own VM," "run it on the JVM" and "run it on the .NET CLR."
A lot of the cleanup work on Perl 5 is being done to make Perl 6 less of a culture shock so it shouldn't hurt you if learning Perl is a goal.
If for nothing else, personally I think Perl 6 is worth learning just for its added capability to specify grammars and rules for parsing tasks. That is a great, useful feature that no other major general-purpose languages have today.