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
I would like to know if there is any language that compiles to VBA, like we have coffeescript for js, less for css...
If there is not, is there something that prevents us from achieving that? Would it be a bad idea?
I guess that would help people that are used to work with more modern languages to be a LOT more productive.
What would it take to do that ? Could we reuse the coffeescript grammar and parser, but hack into the steps that generate Javascript and generate VBA instead ? A subset of VBA would be just fine.
In general, it's always possible to compile from one Turing-complete language to any other. The result might not be fast, but it's generally fairly straightforward.
So, why was Coffeescript created ex nihilo, instead of using an existing language? Integration.
Suppose, for example, that we wanted to write JS in Haskell. You could easily implement a Haskell to JavaScript compiler. Now, suppose, writing in Haskell, you wanted to pop up a dialog box on a Web page. In JS, you'd write alert("hello"), but if your H2JS compiler is correct, there won't be any alert function, because Haskell functions don't have side-effects (perhaps the whole reason that you wanted to write in Haskell was so that you could have nice guarantees like that calling functions won't pop up dialog boxes).
There are many ways that your H2JS compiler could provide this functionality, but it's not necessarily obvious which one was chosen. You can't just read JavaScript documentation to learn how to do browser-y things; you also need to read the documentation for your H2JS compiler!
On the other hand, Coffeescript is similar enough to JS that it's pretty obvious how to pop up alerts, edit the DOM, etc., just from knowing how it's done in JS.
So, it's not hard to do in a slapdash way, but, if the source language is much different from VBA, it'll likely be tricky to do the VBA-specific things that make the project useful in the first place.
Related
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 8 years ago.
Improve this question
Lua beginner here, i am looking into lua.
my question is: since an object in Lua is just a table,
new fields can be added at runtime. if I have a typo in the code, and instead of changing a field, I create a new field, won't that bring mayhem? ;)
I would only be able to figure out the bug in runtime, if I even get to that point in the program.
(of course the table concept has other benefits like meta programming without reflection, but my question is about "safety" or predictability.)
Is that the right conclusion?
Yes, that is correct.
When working with a dynamically typed language, you'll need an extensive suite of unit tests, to make sure you cover all possible scenarios and prevent the kind of mayhem you described.
If you want to protect yourself from this, I'd recommend looking at a static typed language, such as java, c# or scala, and let the compiler do the type-checking for you.
This is why Twitter moved from Ruby to Scala - as the project grows, it gets progressively harder to keep track of bugs that can only be verified at runtime using a dynamically typed language - but could be verified at compile-time by a static language compiler.
Dynamic typed languages are based on duck typing:
If it walks like a duck, and quacks like a duck, it is a duck
I prefer this version:
If it walks like a duck, and quacks like a duck, it’s probably gonna throw exceptions at runtime.
Lua gives you the mechanisms to have at least as much safety as other dynamic programming languages with baked-in object models do. See here for instance.
Errors will still happen at runtime only though, so you need a test suite with decent coverage.
There are projects to add static typing to Lua. Fabien Fleutot, who created metalua, presented his at the latest Lua Workshop. See:
his slides
a high-level overview of his work
a more formal paper about 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 8 years ago.
Improve this question
Can any language be used to program in any paradigm? For example C doesn't have classes but s it is possible to program in OOP. There are some languages (such as assembly) I can't see using OOP in.
Yes, simply due to the fact you can implement an interpreter for your $favorite $paradigm in the host language.
Practically though, this is not feasible, efficient or right.
C++ is ultimately assembly, you just have a compiler to write the assembly for you from a nicer description. So sure you can do OOP in assembly, just as you can do OOP in C; it's just that a lot of the OO concepts end up being implemented with convention and programmer discipline rather than being forced by the structure of the language, with the result that huge classes of bugs become possible that your language tools probably won't be very good at helping you find.
Similar arguments follow for most paradigm/language mismatches. Lots of object-oriented programs have been written in C this way, so it can even be a somewhat practical thing to do, not just an academic matter.
It can be a little harder when what you want is to remove restrictions rather than add them.
In purity-enforced languages such as Haskell and Mercury you can't suddenly break out object-oriented style packets-of-encapsulated-mutable-state in the middle of arbitrary pure code (at least not without using "all bets are off" features like unsafePerformIO in Haskell or promise_pure in Mercury to lie to the compiler, at which point your program may well completely fail to work unless you can wrap a pure interface around the regions in which you do this). However you can write whole programs in procedural or object-oriented style in these languages, by never leaving the mechanism they use to do IO.
Likewise, if you consider the use of duck typing in dynamic languages to be a paradigm, it's pretty painful to get something similar in languages with static typing, but you can always find a way to represent your dynamic types as data. But you again find yourself doing thing with convention and reimplementation that you would get for free if you were really using a duck typing language.
I'm pretty sure it would be hard to find a language (usable for writing general purpose programs) that can't be adapted to write code in any paradigm you like. The adaptation may not produce very efficient code (sometimes it can though; adapting C or assembly to any paradigm can usually be made pretty much as efficient as if you had a language tuned for that paradigm), and it will almost certainly be horribly inefficient in terms of programmer time.
No, not all languages can be used to program in any paradigm. However, the more popular ones - python, c++, etc all allows you to chose how you want to program. Even php is adding OO support.
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 last year.
Improve this question
I maintain Autoit project used for automated testing of swing app. Those tests have now about 70 files. It's get pretty hard to maintain all this code without following some "best practices" I'm trying to create as much functions as possible (because of duplicate code) and constants (frequent changes) bud it doesn't seem enough.
I have generally this types of functions:
Some general functions (insert text with logging, select or read from combobox.. )
Some screen specific functions (fill one form.. )
Some data/logic function - testing of app logic and data processing
Test case functions - combines previous 3 to implement some test scenario
AutoIt does not have classes => no inheritance => OOP principles are hard to aplicate ( :D clearly)
Does somebody have some experince with larger applications written in AutoIt? My opinion is, that AutoIt is for scripts < 500 lines and it wasn't good choice for this big project.
It's a shame, that AutoIt doesn't have some useful IDE.
AutoIt developers want to make sure that any functions written in AutoIt that are part of the core library (in short: UDFs) are subject to a certain code style. You can find this standard here: http://www.autoitscript.com/autoit3/udfs/UDF_Standards.htm Many programmers in the community write all AutoIt code in this standard.
On the subject of IDE. SciTE is a time-tested code editor, but as IDE it performs adequate. There are two other IDEs which are developed and maintained by the community:
A graphical debugger (F10 step next functionality) http://www.autoitscript.com/forum/topic/21834-graphical-autoit-debugger/
ISN AutoIt studio http://www.autoitscript.com/forum/topic/136766-isn-autoit-studio/
The last one is fairly new, but it looks extremely promising and it may work better for your project.
Finally, I have a note of warning. You say "OOP principles are hard to apply", but even as an OO programmer you should have a strong core idea of how to write non-OO code before you even learned OOP. Most OO languages are imperative at their core, so you should be an excellent imperative coder already. AutoIt is imperative as well.
A useful IDE will not solve your problems! But it will make them slightly easier to manage.
I don't know where you heard that AutoIt only performs well for scripts for under 500 lines, but every time you #include one of the default libraries you are adding ~10000 lines of code. If you can write proper code, you will build your own libraries without adding complexity to the rest of your code.
As AutoIt doesn't have (as you mentioned) the enabling characteristics of an OO language I think part of an answer here is to look at what AutoIt has and what paradigm best fits it. It's clear to me that AutoIt is a language meant to done using procedural programming methods. For me, it's actually a bit of fun to go back to those methods that way of thinking. My large programs end up, with an an emphasis on correctly defining computation modules, what is passed into the module (and returned). If you are severely missing OO benefits I think the next thing to focus on would be scoping -- trying to keep that as tight as possible.
As a final note, I think using the procedural programming techniques does usually end up creating a separate task of re-factoring after the functionality is up and running.
A place to start...but this was the dominant paradigm for decades
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
It seems like whenever I use the Command Pattern, it always leads to a significantly larger number of classes than when I don't use it. This seems pretty natural, given that we're executing chunks of relevant code together in separate classes. It wouldn't bother me as much if I didn't finish with 10 or 12 Command subclasses for what I might consider a small project that would have only used 6 or 7 classes otherwise. Having 19 or so classes for a usual 7 class project seems almost wrong.
Another thing that really bothers me is that testing all of those Command subclasses is a pain. I feel sluggish after I get to the last few commands, as if I'm moving slower and no longer agile.
Does this sound familiar to you? Am I doing it wrong? I just feel that I've lost my agility late in this project, and I really don't know how to continuously implement and test with the speed that I had a few days ago.
Design patterns are general templates for solving problems in a generic way. The tradeoff is exactly what you are seeing. This happens because you need to customize the generic approach. 12 command classes does not seem like a lot to me, though, personally.
With the command pattern, hopefully the commands are simple (just an execute method, right?) and hence easy to test. Also, they should be testable in isolation, i.e. you should be able to test the commands easily with little or no dependencies.
The benefit you should be seeing are two-fold:
1) You should have seen your specific, complicated approach simplified by using the pattern(s) you chose. i.e. something that was getting ugly quickly should now be more elegant.
2) Your should be going faster, due to the simplified approach and the ease of testing your individual components.
Can you make use other patterns, like composite, and use good OO design to avoid duplicating code (if you are duplicating code...)?
That doesn't seem like a lot of command classes, but I agree with you that it smells a little if they make up more than 60% of your classes. If the project is complex enough to merit the use of the command pattern, I suspect you'll find some classes begging to be split up. If not, perhaps the command pattern is overkill.
The other answers here have great suggestions for reducing the complexity of your commands, but I favor simplicity where I can find it (ala the bowling game).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Sometimes I feel I can't write a simple line of code without using an IDE (VS, NetBeans, etc.), even when I write something in Notepad or MS Word I always forget and press Ctrl+Space to use AutoComplete.
I can't remember a lot of libraries names and functions and Exceptions in the languages I am using due to the IDE's abilities and I don't know if this is a problem or not.
I want to know if there are some benefits to drop the IDE away for a while and just use a simple editor to be more strong in the language or this will make the situation worse?
When I start learning a new language, I always start by using a simple editor (mostly vi oder gedit) and switch to an IDE when the problems begin to become more complex. This way, I get a good grasp of the fundamental stuff.
If you have the time and space to stop using an IDE and do a lot of manual lookups to find out the names as you code, then you might want to consider this...
However, if you are being paid to produce code to a deadline, then keep the IDE. Knowing the names of the framework classes is nowhere near as important as knowing where to look for the information about them when you need something. These things are getting so big, that trying to hold it all in your head is not particularly feasible (unless you're Jon Skeet).
I don't see why having things auto complete detract from your knowledge on how to apply them in your work. At the end of the day it is showing you the name and parameters of the function, it's not writing your program for you. It makes you more productive in that you have to type less. You still need to know what variables to use and what functions to call. And if you can't quite recall the full name of that long function, you can type a few letters and look, saving you a trip to the reference library.
It's making your workday more productive, not detracting from your skills.