As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a bunch of C code accessing database (Oracle, DB2 and Sybase) through Embedded SQL : the base code is the same, but with three different precompilers, three sort of executables are built, one for each database/platform.
I works perfectly fine, but we need now migrate to a solution using ODBC access.
The problem is : what tools / api can be used ? A direct way seems to write a custom precompiler (or modify an existent) to wrap all SQL and host variables calls to calls on an ODBC connection.
Can somebody recommend tools for that task or api to keep it simple ?
Or is it a simpler way, another approach ?
Thank you
As is usual for such situations, there are likely no off shelf answers; people's codebases always have a number of surprise in them, and the combination prevents a COTs tool from ever being economical for individual situations.
What you want is a program transformation system (PTS), with a C front end, that can be customized to parse embedded SQL. Such tools can apply source-to-source rewrite rules ("if you see this pattern, then replace it by that pattern") to solve the problem.
These tools require some pretty technical effort to configure. In your case, you'd have to adjust a C front end to handle embedded SQL; that's typically not in C parsers. (How is it that you can process this stuff in its current form?) You'll have trouble with the C preprocessor, because people do abusive things with it that really violate a parsers nested-structures-view of the universe. Then you'll have to write and test the rules.
This effort is a sunk cost to be traded against the effort of doing the work by hand or some more ad hoc scripting (e.g., Perl) that partially does the job leaving you to clean it up. Our experience is that it is not worth the trouble below 100K SLOC, and that you have no chance of manual/ad hoc remediation above 1M SLOC, and in between your mileage will vary.
At these intermediate sizes, you can agonize over the tradeoffs; that costs energy and time, too. Sometimes its just better to bite the bullet and do it any way you can an clean it up.
Our DMS Software Reengineering Toolkit is one of these PTS. It has a customizable C parser and preprocessor, precisely to help deal with these configuration troubles. The other PTSs mentioned in the Wikipedia article, do not, I beleive, have any serious C parser associated with them. (I'm the guy behind DMS).
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a relatively complex set of VB6 forms and classes that need conversion to VB.NET. The classes are complex across COM boundaries, supplying interfaces and events, and sinking events from other COM classes.
None of the classes marshal variant or other complex data types across COM boundaries, so I don't need to try and do anything really difficult with the interfaces.
Are there any tools available, free or commercial, which can automate that, given a copy of VS2010 and a wallet full of money for utilities, but not consulting services?
Please see a question I asked once similar to this here: VB6 code upgrade. Look at the answer from Olivier Jacot-Descombes who talks about the tool available in Visual Studio.
I would suggest rewriting the code as in my experience it is time well spent.
I had a similar task to do and for me the simplest way was to upgrade the VB6 code to .Net using the wizard in Visual Studio 2005. Then upgrade the project to Visual Studio 2010 and then use a refactoring tool to extract the interfaces.
No need for expensive third party tools although you'll still have to manually check all the interfaces to make sure nothing has been missed out.
Spend the money on VB Migration Partner or Artinsoft VB Upgrade Companion and let the tool convert the code as well as extracting the interfaces.
You obviously need to parse the VB6 code, and extract name and type definitions. There aren't a lot of robust VB6 parsers around.
We have one of them, built on top of our reengineering tool foundation, DMS. You can get these as products, and configure them for your purposes. The VB6 front end provides parsing to full ASTs with all details; DMS provides additional machinery useful for building symbol tables, doing type analysis, and support data flow analysis, which is likely what you'll need if you want to know which interfaces use which. This isn't any easy task, as these pieces of machinery are fairly complex (due that the fact that real programming languages such as VB6 are complex); most people are more interested in services to just make a migration happen but situations vary. See VB6 migration tools. (I'm the CTO behind DMS).
You can always write a Perl script to try and extract this information. This will likely get it right 70% of the time; your energy will be spent in trying to figure which 70% is correct, how to patch the other 30%. If your system is pretty small, this might be easier.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am going to develop an application for OS X and I need some scripting engine for it.
The purpose of the scripts is to receive a text on their input (HTML file in most cases), parse it in some way and return the data to my app. These scripts should be easily editable by the users, therefore they should have some common used syntax like C or pascal.
Can you suggest some lightweight solution for this?
Thanks!
PS. I am new to OS X development, trying to switch from Windows...
Two suggestions:
Javascript, try the V8 engine. http://code.google.com/p/v8/ Very popular, likely familiar syntax to many.
Lua. http://www.lua.org Extremely lightweight and simple to connect. If your script editors write scripts for World of Warcraft, for example, they will know Lua.
In general AppleScript/Automator actions are easy for the end user to work with since the technology includes a GUI for building scripts without much programming knowledge. For experienced developers used to other languages, they can be a bit too friendly/loose and have a somewhat different syntax (more like plain English). The good thing is that they can also call other languages as needed, so a developer familiar with Perl or whatever could incorporate that into an AppleScript or Automator action.
Since you're talking about parsing text, Perl itself would be a good solution - again there's some difference in syntax, but the scripts can be rather compact and the basics of parsing aren't too difficult to learn. I haven't personally incorporated Perl into an OS X app, I've just used it on the command line, so I don't know if there are any pitfalls to that approach.
One additional advantage to AppleScript is that you can make your application itself scriptable so that users could automate the functions of your application into a larger workflow.
I would suggest downloading the free TextWrangler application by Bare Bones Software, or a similar developer's text editor, to see how they incorporate scripting into the application. This may give you additional insight into your approach.
LUA seems to be a good choice.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've read a blog post called Blogging with Noir, and I was honestly surprised that the author uses java.jdbc instead of libraries like Korma which I found surprising. What are the advantages of writing SQL queries in your code instead of letting tools do it for you?
I guess it is for the usual reasons that you might choose to use an API directly in Clojure rather than use a wrapper:
Existing knowledge: you already know the JDBC well and know that it will get the job done, why spend time learning a new abstraction unless there is a clear advantage?
Uncertainty - does the library have all the features you need? Will it continue to be maintained and implement new features in the future?
Stability - the wrapper may not yet be mature, so you run the risk of your code having to change if breaking changes occur / bugs are discovered.
Completeness - the wrapper may not (yet) encapsulate all of the functionality of the original API that you need
Overhead - sometimes extra layers of abstraction add a performance overhead that you don't need/want
Extra dependency - adds complexity to your build, and conceptual overhead in terms of the number of abstractions you need to keep in your head.
Ultimately it's a trade-off - the above are reasons that you might want to use the underlying API, but there are equally good reasons that you may choose to use the wrapper:
More idiomatic - a wrapper library is likely to give you much cleaner, more elegant code than a Java-based API (particularly if the Java API is imperative/stateful). You have to admit that Korma is pretty elegant!
More composable - Clojure wrappers tend to adopt a functional style, which leads to easy composability with other clojure code / libraries.
New features - often Clojure wrappers add extra functionality that the original API does not posess (for example, look at the data binding functionality added on top of Swing by Seesaw)
Korma IMO isn't nearly ready to be used as a full replacement for SQL. It's definitely handy, but right now a lot of my queries have (raw "...") snippets in them, and for more complicated stuff all the main querying is done inside SQL views which are then selected on via korma.
The main alternative, ClojureQL, doesn't even work with Clojure 1.3+
In short, it's hard to abstract SQL, and Korma - even though it tries to be minimal, meaning you still have to understand SQL pretty well to use it - isn't finished.
I can think about two reasons:
Almost everybody knows SQL, almost nobody knows Korma
This is a guess, because I do not know Korma myself, but raw SQL is sometimes suitable or even necessary if you want to do something specific like features that are only present in a particular database
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
my development style brings me to write a lot of throw-away "assisting" code,
whether for automatic generation of code parts, semi-automated testing, and generally to build dummies, prototypes or temporary "sparring partners" for the main development; I know I'm not the only one...
since I frequently work both under windows and Unicies, I'd like to non-exclusively focus on a single "swiss army knife" tool that can work in both the environments with limited differences, that would allow me to do usual stuff like text parsing, db access, sockets, nontrivial filesystem and process manipulation
until now under unix I've used a bit of perl and massive amounts of shell scripts, but the latter are a bit limited and perl... despite being very capable and having modules for an incredible array of duties, sincerely I find it too "hostile" for me for something that goes beyond 100 lines of code.
what would you suggest?
scripting is not a requirement, it would be ok to use more static-styled languages IF it makes development faster (getting programs to actually do their work and possibly in a human readable state) and if it doesn't become nightmarish to handle errors/exception and to adapt to dynamic environments (e.g. I don't like to hardwire data /db table structure in my code, especially by hand).
I've been intrigued by python, ruby, but maybe groovy (with its ability to access the huge class library and his compact syntax) or something else is better suited
thanks a lot in advance!
(meanwhile, on a completely different note, scala looks really tempting just for the cleanliness of it, but that's - probably - a completely different story, unless you tell me the opposite...?)
Python is arguably one of the best choices. Its biggest benefit is that it has a huge built-in library for doing all sorts of stuff. It is also mature, very cross-platform, actively developed, and has many support options (mailing lists, newsgroups, etc).
In addition, it has a built-in GUI toolkit (tkinter) for those times when you need to write a quick GUI to get input from a user or display output from a running process. And if you don't like tkinter, there are other cross-platform GUI toolkits available.
I suggest Python.
For me it has a sweet spot of good libraries, documentation, community, cross-platform functionality, and ease of writing/reading.
It fills a similar niche to Perl's, but if you find Perl to be 'hostile' for longer scripts, you will probably like Python, especially when compared to Ruby, which feels more Perl-y, IMHO.
As an aside, all of these are quite easy to just try out - why not do that?
Then you can decide for yourself instead of trusting the questionable wisdom of an online forum (:
I think that Python and Ruby are your best bets, depending on exactly how you think and code.
I personally find Python EXTREMELY readable and its syntax is highly intuitive. I've heard Python described as "pseudo-code plus colons."
On the other hand, once you get around its slightly bizarre syntax, Ruby makes for high-speed development. It's built around DRY principles and convention-before-configuration, which is great for rapid prototyping.
There are other languages--especially Haskell and the Lisp dialects--that can make for super-rapid prototyping, but they don't have as large a supportive community, so there's a shortage in library and discussion supply.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
The advantages of ORM are pretty clear. But I noticed that some companies prefer to build their own home made ORM. Why?
There are only two arguments that I can possibly see for ever hand-rolling your ORM (and these have happened to me in the past, which forced me to write my own):
The company refuses to use Open Source software because of liabilities they assume might creep into their application.
The company refuses to spend money on a commercial ORM.
Any other argument (like the quality of Entity Framework is too poor for us to use it) is completely moot. No matter how bad Entity Framework (or whatever other ORM you may be referring to) is, you're not going to come close to the robustness and reliability by hand rolling your own.
As O/R mappers are very complex pieces of software, writing your own which goes beyond the typical datareader wrapper and pre-fab SQL query executor will take a lot of time (think 6+ months full time at least). That's not the biggest problem. The biggest problem is that once you go with your own O/R mapper, you have to maintain it for the rest of the time the application using it is in production. Which can be a long time. Make no mistake, maintaining an O/R mapper yourself is not a simple task: you have to re-invent every trick O/R mapper developers already know about and have solved themselves.
Last but not least: doing this yourself should not be done on a billable contract. After all, you're writing infrastructure code which is already available elsewhere.
I know I'm biased (I wrote LLBLGen Pro), but I also am one of the few people in this industry who has written a full O/R mapper framework and knows what it takes to get a decent one up and running with good performance and a great feature set.
Simply do the math: if it takes 1000$ to get an o/r mapper framework license (or less) and you can get started right away with the application of your customer, how many hours do you get for that 1000$ so you can built the O/R mapper without costing the company any money? And maintain it? No way you can do it for that money.
If you have an in-house database that has evolved to have a bad schema, it can be simpler to write your own ORM layer than try and get an out of the box solution to play nice with it.
In my opinion, ORMs are specialized and purposed to solve typical problems. If you want some more generic solution (e.g. for much more complex queries) or just different functionality you can either modify existing solution (what for various reasons often isn't the best choice) or create your own.
ORMs also limit you by forcing you to use their conventions and accept their limitations.