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
I'm building a card game called Tijari (uses 40 Spanish cards deck, quite similar to Bridge) as an Expert System. This is all part of my doctoral thesis.
I'm having a hard time finding a good balance between Prolog code and Java code, what would go where and why. The game must let human players play against the AI as well as against each other, so you can have a team of (Human + AI) vs (AI + AI) or (Human + Human) vs (Human + Human) or anything in between.
While Prolog is defined as being about facts and rules, most uses I see of it are not really what you would call logic programming but actually awkward programming trying to implement sometimes complex algorithms under the constraints and intricacies of the language: shuffles, search and complex list operations. Why?
There are some uses of Prolog that a language like Java cannot provide easily like when it comes to deduction based on existing rules and facts and the ability to query for information, still, I generally cannot seem to be able to justify its use.
Is it the fact that it encodes domain knowledge in logic? Well, any real-world Prolog program seems harder to read than plain Java code because of backtracking, cuts and recursion.
Is it the fact that it doesn't require a software developer to encode domain knowledge, just a domain expert? Well not really, you would still need a domain expert who is well versed in Prolog.
Is it the fact that you can easily modify the rules and facts without needing recompilation? Well, any scripting language can offer that really.
Is it the fact that it can easily evolve as domain knowledge evolves? Well, I believe that domain knowledge doesn't evolve that much for it to be a problem, and when it does, software follows, that is why it has always been.
I honestly have a hard time justifying the use of Prolog as the only language in which an Expert System (and here a game) must be built, and when it's not, when you end up using a combination of Java and Prolog, where should the line be?
Thanks
I think your question is a very good and legitimate question, and I am also quite certain that it will soon be closed as many other interesting and worthwhile Prolog questions already have been.
Therefore, I try to rush in an answer while that is still possible.
First, I would like to point out that many Prolog programs are currently indeed still more awkward than they could be. One of the reasons for this is that the existing teaching material is sometimes decades behind the current state of the language. As a result, many very important declarative features that have become widely available in many systems in the past few years and decades are simple not known by a large fraction of Prolog programmers. With these features, many Prolog programs become a lot less awkward.
One important difference between the two languages is in my experience: In comparison to programming in Prolog, writing Java code is extremely inconvenient. The reason becomes immediately obvious after your first few serious Prolog programs: In Java, you consistently feel at least one step too far removed from the actual task. You cannot simply write down the terms, state, knowledge etc. No, you instead have to first write down a meta-description of the knowledge itself (in the form of classes, types, interfaces), and only then can you talk about what you actually want. But that's not all: The description of both the actual knowledge and its properties is extremely low-level. For example, you cannot conveniently reason about things symbolically via pattern matching.
The benefits of this quite indirect programming style that Java inherently necessitates are in my view very questionable. At least I have yet to see a Java program where I could with a straight face say: "Yes, Java was a great choice for this project." By comparison, I have seen many Prolog programs where Prolog definitely was a great choice for the project.
There are many more differences that make programming in Prolog vastly more convenient than programming in Java. For example:
Prolog code is easy to parse, change and analyse by other Prolog programs, allowing for some very cool shortcuts
Prolog code is very easy to test interactively using the toplevel
Prolog code can often be used in several directions, leading to shorter programs
very importantly, it is extremely easy to formulate extensive test cases using comparatively simple Prolog queries which generate a vast number of tests on backtracking.
These are only a few examples I'd like to mention. Overall, I think that if you regard Java as a "general purpose" programming language, then Prolog definitely also falls into that category. At least I have yet to see a project where someone said "It would be so great if only we could use Java for this task!" I've heard this phrase about Prolog several times already.
Related
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 11 years ago.
Improve this question
I've forked this question from a similar question I made in a comment I made to one of the many great answers I recieved. I was originally asking about AST macros, which mostly provoked very detailed and thoughtful responses from Lispers. Thanks.
Lazy Evaluation vs Macros
The question I made in a comment was whether project-specific DSLs are actually a good idea. Of course, this is completely subjective -- After all, when you are writing in a really expressive language, where do you draw the line between an expressive API and an actual DSL? For example, I think what most Rubyists call 'DSLs' are actually just well-designed APIs and nothing more.
Note that I say project-specific APIs. I don't think many will argue against using regular expressions or SQL where it makes sense to do so.
But despite this, I think we can all draw a vauge, hazy line between an API and a DSL. Of course they're both really APIs, but whatever.
On one extreme you have Lisp, where DSLs seem to be actively encouraged via macros. On the other you have the likes of Java where DSLs are pretty much impossible.
Proponents of DSLs would argue that they increase flexibility, expressiveness, and increase consistency (for example, a custom number object using the same operators as the language's own numbers).
Detractors would say that they can lead to sub-languages that nobody except the DSL writer knows, kills the point of having different programming languages in the first place, and leads to code nobody can understand because the way of interfacing with API is different.
I gotta say, I agree with both sides in many ways. Some Java APIs are just plain nasty due to the lack of expressiveness. Despite this, I can generally always work out what's going on without reading the documentation -- Which can't be said about custom DSLs in the slightest. Maybe DSL proponents argue that you should always read API documentation. I disagree, but I also digress.
But let's look at some of the big languages at the moment. C# and Java, namely. Neither of them really 'do' DSLs, yet they're massively popular. Is this precisely because they don't allow things like DSLs, allowing mediocre coders to churn out code that's still comprehensible?
Is the fact that DSLs allow mediocre coders to produce impenetrable garbage the reason why Lisp is not used as much as it should be, despite what a DSL can look like in the right hands?
There are of course arguments in favor of DSLs and against them, and there's of course a vague line between "a library" or "an API" and "a DSL". That part you've covered well in the question, so I'll avoid those subjective points and focus on just the question of whether they're a liability.
A good project to consider for this is Racket which puts language construction as its main feature. It's easy to slap up a language for any definition of "a language": DSL or not, made up from near scratch via an interpreter or (more commonly) done via macros that define the new language and possibly a parser for a different syntax. As a result, the Racket source tree has a bunch of languages -- some of them have fundamentally different execution semantics. Some examples:
Lazy Racket is what you'd expect the name to mean,
Typed Racket is a statically typed language,
Scribble is a language for writing documentation and other prose,
Slideshow is a language for writing ... slideshows,
RackLog/DataLog are languages that are even more different in both semantics and syntax.
In fact, making up languages is so easy in Racket, that you easily slap up a language even if it's something that fits a very limited use, or even just a single one. For example, we have such "small languages" that are used to create our web pages, decide which files are included in distributed installers, and many many more. See this tutorial for a description of how to come up with a language.
It's true that there's a fine line between a useful DSL that many people can use and one that only one person uses -- but still, the kind of abstractions that you can get when you define a language rather than a library are substantial, to the point that it's a useful concept even when it's a "one-man's language". One hard problem in this are is considering interoperability -- Racket allows each module to be written in it's own language, which brings up issues of what happens when several of these modules are supposed to talk to each other. For example, how does evaluation proceeds when there's interaction of functions in the lazy language and in the default one; or how does the typed make sure that it can interact with the default untyped language and still get the usual benefits of a statically typed language.
DSLs are widely used in Java. Just not 'internal' DSLs. Lisp has, unlike Java, several ways to alter the language syntax and semantics without writing a new external language. In Java, most DSLs are either external (often based on XML) or implemented with a pre-processor.
If you write a new programming language, also a domain-specific programming language, you need to:
specify it
document it
test it
make it robust
make it debuggable
make it efficient
... and more
Lisp is no magic bullet to do all that for you. What Lisp gives you is to include one or more DSLs directly into the language and it allows you to reuse or alter the Lisp facilities to implement parts of your new language.
Lisp had in its history a lot of languages implemented on top of it. Many of them were just research languages without too much effort to follow software engineering practices. Some of these languages had more effort put into them - for example because they were part of a product.
If you develop a language for your project, you need to make sure that you follow good software engineering practices and you have the resources to do so.
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
We're developing a system which can be best described as a layer above social networking. It's extremely data heavy, would involve a huge user base, data base would be beefy basically, but it wouldn't involve complex computations. The most complexity would involve fast retrieval of data. Now, we have programmers who're comfortable with JAVA as well as PHP. The front end is nailed - Javascript, HTML, CSS. But we're having a huge debate on what to go with for the back end. We consulted numerous blogs and forums and have a consensus on the pluses and minuses. To sum it up, people say that it's a pain to host Java but it's extremely scalable, whereas PHP is fast and easy to host, but not entirely OO or sturdy. We're still not able to reach a decision. For a system like ours, does it even matter what we go with? Because at the end, it's the performance boosters that matter.... or am I entirely wrong in thinking that? Any input will be appreciated. Thanks in advance!
Java and PHP are both valid choices for developing a web backend. Personally I would choose Java (I'm an OO guy), but the decision for you should be more about what your developers are more comfortable with.
Forcing developers to adapt to a technology which they are resisting will cause problems for management and is likely to even upset the outcome of the project. I would not invest in a project knowing that the developers were not happy with the technology being used - it is too much of a risk.
I would prefer PHP because of the amount of help you can get (if you are ever stuck). It is also very adaptable, and has many CMS systems available.
I agree that for a system like yours, the language does not even matter. Retrieving the data efficiently is what matters, and there are umpteen solutions to help you with that.
So then you should choose the language your team is most comfortable with, and helps you code in a safe way (read: tdd).
For me, from the choice you give me, that would be java, as i don't know any tdd solutions for php (doesn't mean they are not there).
I would be so bold as to suggest an alternative: use ruby and Ruby on Rails. At least, that is the switch I made, and i have never been happier. But that is personal, and you and your team should be willing to learn a new platform (and i can imagine it would defeat the whole purpose).
To rephrase: according to what you told us, the language does not matter. Choose the language and toolset where your team is most comfortable with.
If it's huge data base plus massive read-write in real-time much like apps layered on Twitter feeds and Facebook, you are probably going to be more worried about how fast and efficiently you can retrieve data from database. There are tools to do so, in both, Java and PHP, so you are not going to be worried much what you start with.
I would suggest to with one you have more suitable tools and APIs to develop on. So, to answer your questions:
For a system like ours, does it even matter what we go with?
It does not matter what you choose. At least, when starting it is premature to decide what's the best. I've seen pretty efficient system on Java. So, I am inclined towards Java.
Because at the end, it's the performance boosters that matter.... or am I entirely wrong in thinking that?
Performance boost will come with faster data-retrieval and ability to handle large request load. Java scales pretty well. But there are high performance sites build on PHP.
I would say, it's a good idea to evaluate what makes you to do less work in getting your app done and go with that. In massive load situations, you might have to tweak things in either of the cases.
You should design your system to scale well with the number of users. You will find CPU/memory is relatively cheap these days so using a bit more cpu/memory is not as big a problem as it used to me.
I would say if you can use Java or PHP, you should consider using Java AND PHP. This way you can take advantage of the best of both languages.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm versed in Java, and starting to experiment with Groovy.
Because the two are integrated so well, I find myself writing in Java whatever I can because it's so easy. What specific tips can you offer that would speedup my work with Groovy?
Meaning - in what areas do groovy excel over java, and where should I stick to Java?
Some of the main things I like groovy for:
testing is probably the biggest win. The ability to change behavior at runtime and mock out methods is one of the greatest things about groovy. Convert your test suites to groovy now!
use the builders. Groovy builders have so much more expressiveness than traditional java. In particular, the MarkupBuilder for embedded snippets of XML or HTML is 1000s of times nicer to use than vanilla java
GPars if you're doing any sort of concurrent programming or threading
Also see Hidden features of Groovy and Why would one use Groovy over Java (note: was "removed from Stack Overflow for reasons of moderation").
Where I'd stick with java:
any place where speed really matters, stick with java. You still pay a high cost in performance for groovy's dynamic nature.
The problem with Groovy.
Groovy is a write-easy, but maintenance-nightmare. In my opinion, it should not be used in large projects. Inheriting somebody else's (or your own) code can be problematic, because very often you have no clue of the type of a variable, so you have your due diligence to find out, or use assertions to guarantee the incoming type to a method.
Groovy is a weak-typed language. The type of a variable is frequently ignored, or "conveniently" cast automatically, which leads to many bugs and slower performance.
Even the bests IDE's are lacking, because the practically typeless variables of the language. In many cases the compile just can't know what is the type of a variable. Even if you declare the type of a variable (which helps the editor to make suggestions), many programmers forget to define the variables type.
It has interesting ideas that I would love to see in Java, but stay away from it if your Groovy code will require more than a thousand lines.
* The answers in a nutshell *
Summarizing, here are the answers to both questions:
What specific tips can you offer that
would speedup my work with Groovy?
Use it only for small stuff. Otherwise, you will incur in technical-debt (see the Wikipedia). So far I'm in similar situation. Unit testing, using the console to test pieces of code, etc., are things that will speed up your development, since it's so easy to learn and use. Be sure to master closures, collections, and looping, and to understand what Java features are not available in Groovy.
Don't use pure Groovy for complex or large applications. In the long term the maintenance will slow you down.
Meaning - in what areas do groovy
excel over java, and where should I
stick to Java?
In a large or critical project you need to keep yourself disciplined and use dependable tools. It's like building a house: I are build a doll house, Groovy is fine :-) ... if it's not perfect, it's no biggie. If you build your own house or something bigger with little tolerance for error, you need to use quality tools and materials of better quality that don't let you oversee potential problems (Java, for example).
In any case, Groovy is like duck tape: some here and there may do no harm.
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'm in the process of putting together a year long PRACTICAL course (not academic) to produce Java programmers who can be productive from day 1. I've found that often computer science university graduates know all about the Fourier transformation, but as interesting as that may be, doesn't help me integrate them onto real life projects.
Apart from obvious programming I have thought of a number of other topics
Testing
Continuous integration
Source control
What to do if you have a problem (e.g. this site)
Agile and other methodologies
Documentation
If you can think of any others please let me know.
debugging techniques
The theory that's probably necessary:
How to sort an array with something that's not O(n^2)
The very basic data structures; array, list, tree, stack, queue, heap are the first to mind.
If not how to write them, then absolutely why you'd use a tree over a list over an array, or vice-versa.
The practical knowledge that's also necessary:
The book The Pragmatic Programmer covers most of what you're asking here.
Eclipse. How to work a debugger. How to work a profiler.
Ant.
Some basic web framework; Struts, Spring, etc.
Apache Commons, JAXB, a SOAP library, a REST library.
How to read bad, uncommented code. How to refactor it bit by bit to be maintainable.
What a good comment is.
HTML, CSS, JavaScript, JQuery, in that order.
Validators (W3C), formatters (Jalopy), checkers (PMD, FindBugs).
How to use a piece of Bug Tracking software; how to write a good bug description, how to explain what you've done to fix it, and how to handle user expectations.
Actually, that deserves it's own line; how to handle user expectations and conflicting timelines and goals.
You need to teach them how to:
Read other people's code for comprehension
Work within a legacy code base (the steps, from reading to building to running tests to modifying)
In addition to what you have, working in teams on a mid-size project. This will also (hopefully) help them see the benefits of source control, testing, and documentation.
Another answer mentioned debuggers. In the same respect, I would also give an overview of profilers.
One thing I wish my professors covered more in my programming courses was using IDEs effectively. My professors mentioned that we should check out Eclipse, but never really taught us how to use it to its full potential. Even now I frequently find new features of my frequently used IDEs that save me a LOT of time doing trivial tasks.
Once you get past the skillset needed to be a coder, I think the next step is learning to code smarter and not harder.
Code reviews.
Receiving and giving code reviews is not very easy and quite often people get annoyed quite easily, especially the one whose code is being reviewed. But it is very useful to be forced to take on criticism and to explain your decisions. For the reviewer it requires you to read other people's code and to be able to point out the problems in it and of course to describe why you think the developer has done something wrong.
I'd dedicate a fair chunk of time to UML and pseudocode design. Writing a quick spec or even a few lines of pseudocode takes some practice and has tons of benefits.
Another thing I'd recommend is build procedure. While this stuff varies from place to place, a primer on things like Ant, continuous integration, etc would be great.
Sounds like you want to teach software engineering more than Java. You have covered most of the main topics however, I would suggest the following as well:
Software Architecture: There is design and then there is architecture. Understanding how different components will/should interact in a project is important
Requirements gathering: Getting the actual spec from the "business owners" is a valuable skill. Too many people think that actual requirements for a project will just be given to them.
JDBC/Databases: You have to touch on databases if they are going to be useful on day 1.
MVC: I don't think it is important to go through all design patterns however, it is definitely worth mentioning MVC. It is an incredibly important pattern for Web development and really can be applied to most anything.
1 year is not a lot of time to turn someone into a software engineer. There is a lot of practical experience that has to be developed and generally speaking, that is why a Bachelors is 3-4 years.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I have to write a prototype app for an engineering company. Most of the work is calculating various engineering properties (I'm talking pipes and real things here, not software engineering).
However, there will also have to be a GUI for:
parameter entry
displaying results
some basic diagramming
The calculation work at the moment doesn't involve complex math elements (no matrices at the moment), just logs, square roots, relatively simple formulae. Later I will have to do some:
curve fitting
numerical approximation
I was wondering if Java has been used for real world engineering apps?
Are there libraries available for this sort of thing?
Or am I better off writing in MatLab and then connecting to the code through Java?
Also open to other languages (although we are a Java shop).
I have some experience of both Matlab and of Java for scientific/engineering type codes. Yes, Java is used for real-world scientific and engineering codes, and yes there are libraries available. You can certainly do what you want using either so I'm not sure that you could sensibly distinguish between the two on the sole basis of your current requirements. I'd ask myself the following questions:
How good am I at programming advanced mathematical operations? Operations such as function minimisation, differential equation solvers, matrix algebra. If the answer is not very then lean towards Matlab which will provide all of these out-of-the-box (though you may need additional toolboxes). If you opt for Java, make sure you are very comfortable with floating-point arithmetic and dealing with the sorts of errors which occur when you use it.
Do I want to code everything in Java, everything in Matlab, or am I happy to use both and to wrestle with, say, a Java GUI on a Matlab engine ? I think you can do much better (in a vague sense) GUIs with Java than with Matlab, but Matlab's GUI facilities are good enough for most of its users that the added complexity of integrating Matlab with Java is not worth tackling. But then many Matlab users are not software engineers.
What speed of development do I need for the prototype work ? If you were equally skilled in Java and in Matlab then I'd guess that you could do it quicker in Matlab, because the numeric stuff is already provided, you could concentrate on the GUI. But if you are a skilled Java programmer coming newly to Matlab you might decide to stick with what you know.
How will I develop and deploy the production app if the prototype is successful ? If Matlab doesn't fit your deployment ideas then learning it and forgetting it may not be rewarding.
Finally, since you solicit other language recommendations: forget Java, forget Matlab, forget Python, forget R, use Mathematica, it's way more fun and very powerful.
This sounds like a job for Matlab: you don't give any reason not to use it. There's some code for evaluating Matlab expressions from Java: http://www.cs.virginia.edu/~whitehouse/matlab/JavaMatlab.html
I have done some work where I had to reimplement Matlab code in Java so it is certainly possible. The Java code can end up being quite verbose compared to the Matlab original due to Matlab being able to operate directly on matrices/arrays etc.
Some math libraries that you might want to look at to see if they support the functionality you are looking for:
Commons Math
Colt
JSci
I guess that Java would be a good choice, even though it is not considered a typical language for rapid application development.
Pros:
versatile GUI toolkit for desktop applications in standard library (Swing),
(relatively) cross-platform,
great libraries, e.g. from Apache; a great math library to look at would be colt; for charts and diagrams, you may like jfreechart ..
Cons:
"not so rapid" prototyping capabilities
Further reading:
Technical Java: Applications for Science and Engineering
Python has several decent GUI toolkits as well as NumPy, and is easy and fun to write in.
This depends mainly on how easy it will be in your environment to include the mathlab or other math engine in your product. If this is easy, I would suggest to use mathlab, but if not, e.g. you have licensing issues or deployment issues, you are probably better of just using plain Java code.
You may also want to consider R language.
I would do a search for software that's written to do piping calculations. This problem has been done. (As you've noted, the calculations need not be difficult.) At a minimum I'd recommend that you know what's available to you, how much it would cost, and where the break even point was for development costs.
A commercial product will have one huge advantage over anything you'll write: It will have a larger user community that's been banging on it and finding bugs for a longer period of time than your prototype. That's worth something as well.
What's your opportunity cost? What else could you have done with the development time that would drive more revenue?
Don't forget numpy or scipy. Both allow you to call fast matrix libraries from Python.