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.
I wrote a simple genetic algorithm to evolve the string "helloworld". I wrote it twice. The first time was written using classes. And the second time was written using just functions where the entire state of the genetic world is passed from one function to the next...to mimic the data flow paradigm. Surprisingly, the code worked well for both the implementations. However, I managed to get it working only after painstakingly removing each and every bug, which was quite a laborious process.
And I asked myself.. there has got to be a better way. Write the code using classes was comparatively difficult than writing the same code using simple functions and I believe writing the same code visually, using something like labview for example would be a lot more easier than writing it only using simple functions.
To that extent, I read about data flow programming and visual programming and quite frankly it seems like it is more natural and intuitive to program in a visual, data oriented manner than in a statement-wise manner, which is what most programming languages enable us to do today. My question is.. if this is the case, why hasn't data flow, visual programming like "labview" become the standard?
I do not believe that data-flow / "Visual Programming" has nearly the performance of well-designed code.
Text-based code can express far more complex and subtle data structures and flows than anything graphical. It gives programmers detailed control over what gets copied, what gets accessed, and precise control over sequences of steps. I have a hard time seeing how data-flow could be that expressive.
Ultimately, data-flow /visual programming can only describe things that are already known. Text-programming (for lack of a better term) actually lets you express more. Programmers can create entirely new data structures and algorithms that simply haven't been represented visually yet.
It is dangerous to use a single problem as the basis for how programming languages should be designed. I'm not sure how the data-flow paradigm would improve GUI framework design, for instance.
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 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).
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.
I started in High School learning java and python and I guess I just always learned OOP and nothing else my question is What are the other programming paradigms or types of programming languages beside OOP?
"Opposite" isn't really a good way of putting it. What's the "opposite" of Democracy? OOP is a a paradigm -- a way of viewing the problem of programming.
The four main coding paradigms are:
functional (viewing programs as mathematical formulas)
imperative (programs are series of instructions for the computer)
logical (model information and the relationship between that information), and
OOP (Model objects and how it interacts with other data)
http://www.cs.aau.dk/~normark/prog3-03/html/notes/paradigms_themes-paradigm-overview-section.html#paradigms_logic-paradigm-overview_title_1
Logical is the most different by far and you have to jump through a lot of hoops to solve some problems in logical programming. The other three all solve the same problems, but the approaches are different.
Procedural Programming is one of the other forms used.
http://en.wikipedia.org/wiki/Procedural_programming
There is no such thing. OOP is a concept built on top of procedural programming, there is no opposite rather there is a choice of writing in OO or not.
These answers are all wrong ... and that is a VERY good question ... and the answer is .... "AOP" - i.e. an "Algorithmic Oriented Programming" entirely based on the "algorithm" being at the very centre of the concept - in an AOP the "data" or an "object" or "objects"are simply "passed to the algorithm" - i.e. THE ALGORITHM IS ENTIRELY KING (it "knows" what to do with the data) - the data carries around "nothing".
In fact "we" (at Inferix) think OOP is a blind alley!
AOP is a much better model of reality - OOP is fine for "images on screens" and "data processing" but it cannot encapsulate intelligence - because "relationships and dynamics and intelligence" are not at it's core!
So we think that "AI Entities" (coming soon) will use only AOP!
Practically speaking Algol60, Coral66 and Inferix-MTR are examples of AOP languages - Algol60 became Pascal and Ada and the likes - and these just became more and more OOP (e.g. Delphi)!
The start of "typing" of values marked the end of AOP!
However: MTR is still a strictly AOP language (but unfortunately at present it is designed for AI entities to use and not humans).
You could think of an AOP as a language that strictly "prohibits" the typing of data elements and is only concerned with "values" of "signals".
There are several but i would say Functional Programming is the most opposite.
http://en.wikipedia.org/wiki/Functional_programming