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
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 7 years ago.
Improve this question
I am about to start working on my master project which is processing images that are captured by an iOS application. My supervisor gave me the option to either develop the application with Swift or Objective C. I have searched online about which of them is better in terms of image processing and I still could not determine which one is better. Therefore, what would you suggest?
You can do everything with Swift, that you can do with Objective-C, but Swift offers additional advantages.
Swift has a simpler but more powerful syntax. You only need to maintain single source files, instead of interface/implementation pairs. Swift has better ways of dealing with errors and optional properties. Most importantly, for your image processing app, the compiler will optimize Swift code to run faster than Objective-C.
As with Cocoa objects, any pre-existing Objective-C image processing frameworks you might wish to use, can be called from Swift with no problem — so, you can "mix and match" as desired.
The only reason I can think of why you might wish to choose Objective-C over Swift, would be if time were of the essence and you were already totally up to speed with Objective-C, and had no time to learn Swift.
Any answer to your question will contain a fair amount of opinion and you need to weigh up the pros'n'cons yourself and make a decision - there is no right or wrong answer here.
which of them is better in terms of image processing
Neither. You'll also probably be using existing frameworks a fair amount and writing C-level (as in the language) code and that will work out much the same in either language.
I am about to start working on my master project
Go with which you are most comfortable with, you want to be able to concentrate on the topic of your Masters and not spend time learning a language/paradigm you are unfamiliar with.
Consider that Swift is still in a state of flux, Swift 3 is expected sometime in 2016 and it will change things - Apple have made it clear that (at least the first versions of) Swift is not yet stable and code may be broken by updates. This doesn't mean you shouldn't use Swift, but if you do try to stick with the same version during your Masters and resist any temptation to upgrade.
HTH, and may your Masters go well.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to understand the difference between imperative and declarative paradigms, because I have to classify Visual Basic. NET in the different paradigms. Beyond object-oriented, I guess it's also imperative or declarative. If someone could help me explaining how I realized I would appreciate
Imperative code is procedural: do this, then this, then that, then the other, in that order. It's very precise and specific in what you want. Most languages that we use for building end-user applications are imperative languages, including VB.Net. Language structures that indicate an imperative language include if blocks, loops, and variable assignments.
Declarative code just describes the result you want the system to provide, but can leave some actual implementation details up to the system. The canonical example of a declarative language is SQL (though it has some imperative features as well). You could also consider document markup languages to be declarative. Language structures that indicate a declarative language include set-based operations and markup templates.
Here's the trick: while VB.Net would traditionally be considered imperative, as of the introduction of LINQ back in 2008, VB.Net also has significant declarative features that a smart programmer will take advantage of. These features allow you to write VB.Net code that looks a lot like SQL.
I classify CSharp/VB as Multi-paradigm. They are imperative (IF,FOR,WHILE), declarative (LINQ) object-oriented and functional(Lambda). I think that in today landscape there are no more pure languages, they have a bunch of bits of several paradigms.
"The idea of a multiparadigm language is to provide a framework in which programmers can work in a variety of styles, freely intermixing constructs from different paradigms" http://en.wikipedia.org/wiki/Timothy_Budd
VB.NET never required LINQ to be considered declarative. In my understanding, declarative means that a programming language can speak English, i.e. business logic is written exactly as requirements say. The actual implementation may vary. This is called domain driven design (DDD) in some schools of thought.
For this matter, any object oriented language can be seen as declarative. Which does not take away its imperative functions - those are used to make it as declarative as you want it. And this is power behind properly implemented OO concepts, with a concrete task in mind.
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.
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 9 years ago.
Improve this question
Has anyone here given the Fantom programming language a whirl? (pun intended).
My first impression:
I like the ability to have the code run on either the .NET or Java VM.
The syntax is nice and clean and does not try anything fancy.
I have a belief that "the library is the language" and the developers of Fan believe that their USP is their APIs:
But getting a language to run on both Java and .NET is the easy part - in fact there are many solutions to this problem. The hard part is getting portable APIs. Fan provides a set of APIs which abstract away the Java and .NET APIs. We actually consider this one of Fan's primary benefits, because it gives us a chance to develop a suite of system APIs that are elegant and easy to use compared to the Java and .NET counter parts.
Any other thoughts, first impressions, pros and cons?
It looks very inspired by Ruby. It says that it's RESTful but I don't see how exactly. Compare with boo, which is more mature yet similar in many ways (its syntax is Python inspired, though).
The design decisions to keep generics and namespaces very limited are questionable.
I think their explanation sums it up:
"The primary reason we created Fan is
to write software that can seamlessly
run on both the Java VM and the .NET
CLR. The reality is that many software
organizations are committed to one or
the other of these platforms."
It doesn't look better than all other non-JVM/.NET languages. In the absence of any information about them (their blog is just an error page), I see no reason why they would necessarily get this righter than others. Every language starts out fairly elegant for the set of things it was designed for (though I see some awkwardness in the little Fan code I looked at just now) -- the real question is how well it scales to completely new things, and we simply don't know that yet.
But if your organization has a rule that "everything must run on our VM", then it may be an acceptable compromise for you.
You're giving up an awful lot just for VM independence. For example, yours is the first Fan question here on SO -- a couple orders of magnitude fewer than Lisp.
For what problem is Fan the best solution? Python and Ruby can already run on both VMs (or neither), have big communities and big libraries, and seem to be about the same level of abstraction, but are far more mature.
I have never heard of Fan until a couple of weeks ago. From the web site, it is about one year old so still pretty young and unproven. There are a couple of interesting points however: First the language is tackling the problem of concurrency by providing an actor model (similar to erlang) and by supporting immutable objects. Second, the object follows the example of Scala with type inference. Type inference allows the programmer to omit type declarations but have it computed by the compiler providing the advantage of short and cleaner code as in a dynamically type language while preserving the efficiency of a statically type language. And last, it seems like a very fast language, nearly as fast as Java and really close or beating the second fastest language on the JM: scala. Benchmark showing the performance can be found at http://www.slideshare.net/michael.galpin/performance-comparisons-of-dynamic-languages-on-the-java-virtual-machine?type=powerpoint.
This is very interesting.
Java (or C#) was created in order to eliminate Platform dependency by creating a JVM (or CLR) that will compile the code into a specific machine code at run time.
Now , There is a languege which is Virtual Machine independent? umm .... what the hell?!?!
Again , this is a very interesting topic , That might be the future...:) going to one universal single languege
I think it looks like a great language feature-wise, but I'm not sure how useful it is. I don't think it is all that useful to target .NET and JVM. Java is already cross-platform, and .NET is too, with Mono. By targeting two VMs, you have to use only the APIs that are available on both. You can't use any of the great native APIs that are available for Java and .NET. I can't imagine that their API is anywhere near as complete as either Java's of .NET's.