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 9 years ago.
Improve this question
Can anyone please clear me about following terms in simple way
1-IDL Interface Definition Language
2-Interoperability
3-Portability
4-API
Thank you in advance
Interoperability generally just means that the system has been designed in such a way that other systems can communicate with it (either sending it information to store/process, request information from it, or both.)
An IDL is a meta-language that allows for a program (dll, etc.) to describe its inputs and outputs - it's an interface definition language because that's all it provides, an interface. Many specific implementations exist, but they're all very similar in function, most are similar in syntax, and they're ''all'' entirely declarative (they specify names of functions with inputs and outputs, but not what those functions ''do''). Often they're used specifically for calling functions via RPCs.
An API is more general than that - an IDL can specify an API, but so can a web service (SOAP or REST), or any other way for one application, dll, etc. to call functions in another. "Abstract" means just that - it's just the concept of having an interface to call a set of related functions without knowing or caring about their implementation. It's completely language independent.
Portability is a different concept - that generally means being able to compile or run your program on different platforms without a lot of work. Of course, APIs can help with that, if they abstract away platform differences. If you wanted to read images from disk into memory, for instance, you would do that very differently on Windows vs. Linux, somewhat differently on Windows 8 vs. Windows 95, and perhaps slightly differently in x64 vs. x86 versions of the same OS. If someone gave you wrappers so that you could compile or link to different files based on your platform, such that you could always call the same functions in your code and get back the same data regardless of platform, the functions themselves would be the API, the wrappers would be implementations of the API, and your code would be considered portable.
Related
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 created a web service using vb.net in IIS that selects data from database and returns a List of objects with the results.
Is it possible to read that list of objects with a program made in MAC OS X that interacts with the method of the IIS web service?
Another option is use text files, but would be more effective using objects
It's possible, but there is no out-of-the-box solution.
Your options are:
Take a look at Mono project. It's cross-platform .NET framework implementation. You can write program for MAC OS X here and it seems to be the simplest way to go. However I'm unaware of the compatibility between Mono and Microsoft's CLR so you have to check yourself.
You could also possibly run your original service under Mono in which case it would be very simple. The problem is Mono does not cover 100% of the whole .NET framework.
Introduce serialization on service side and deserialization on MAC OS side. For example if you are be able to serialize your objects to strings, you can simply deserialize them on any platform.
Theoretically you could implement your own Object deserializer directly from your existing service. But in practice it would be almost impossible. You would have to handle so many cases, cross-platform issues and much, much, much worse things. I mention this only for completeness of the list. DO NOT go this way.
Appendix:
You must realize, what your service actually sends. It actually sends just some sequence of bits. Computer must correctly parse them to reconstruct original objects. This is tightly related to what Object is in memory. It's memory image depends on the CLR implementation. Without equivalent CLR you won't be able to simply read Object from source CLR.
So your task is to ensure you are able to reconstruct the objects
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 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 4 years ago.
Improve this question
With all the key value data stores out there I have started to create an abstraction layer so that a developer does not have to be tied in to a particular store. I propose to make libraries for:
Erlang
Ruby
Java
.NET
Does anyone have any tips on how I should go about designing this API?
Thanks
First off, and as a general rule for anytime you build "pluggable" abstraction layer, build it to support at least two real implementations to start. Don't build it for just one datastore and try to make it abstracted, because you'd overlook a details that won't plug into another implementation very well. By forcing it to use two seperate implementations, you'll get closer to something that is actually flexible, but you'll have to make further changes to support a third and fourth data store.
Second, don't bother, these things already exist. Microsoft has provided a ton of these for their technologies (ODBC, ADO, ADO.NET, etc), and I'm sure Ruby/Java/etc has several as well. I understand the desire to encapsulate the already existing technology, but the more data stores you need to support, the more complexity you need to build in, and the closer you'll get to ADO.NET (or similar technologies). Companies like MS have spent a ton of money and research on solving this exact problem, and that is what they came up with.
I would strongly recommend checking out Twitter's Storehaus project - this is a key-value store abstraction layer for the JVM and written in Scala, supporting (to date) Memcache, Redis, DynamoDB, MySQL, HBase, Elasticsearch and Kafka.
Storehaus's core module defines three traits:
A read-only ReadableStore with get, getAll and close
A write-only WritableStore with put, putAll and close
A read-write Store combining both
In the Ruby ecosystem, you should check out moneta, which again provides a unified interface to key/value stores. It has a lot more features than Storehaus.
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
We're all familiar with basic ORM with relational databases: an object corresponds to a row and an attribute in that object to a column, though many ORMs add a lot of bells and whistles.
I'm wondering what other alternatives there are (besides raw access to the data). Alternatives that just work with relational databases would be great, but ones that could work with multiple types of backends besides just SQL (such as flat files, RSS, NoSQL, etc.) in a uniform manner would be even better. I'm more interested in ideas rather than specific implantations and what languages/platforms they work with, but please link to anything you think is interesting.
Your basic choices are:
Just use raw SQL.
Pick an ORM that meets your needs. Most platforms have a variety of choices. - for example the .NET platform supports LINQ, nHibernate, Entity Framework, etc.
Write your own ORM and/or data access framework.
I'm working in something more or less along the lines you have said. I think that data-store related tools have grown complex with time instead of simpler and more usable.
So, instead to add complexness, this kind of things must be as simple as:
Get something that points to the data
Use it to do something with the data (query or modify)
The thing you use to interact with the data should do some kind of (transparent) adaptation to the data-store you are working with, and done.
The translation thing may sound a bit ORM-like, but I'm speaking of something more generic:
Some kind of internal implementation to communicate with whatever you are working with (something similar to a JDBC driver, but without the need to work with SQL)
Some kind of mapping to convert data to java object (more or less like in ORM)
The implementation of these concepts I've developed is for java and you can see more of it at http://www.bryghts.com
Right now, I've only developed an engine for SQL related data-sources, but it's prepared for independence of 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 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.