Guys... Girls, I'm working on a project which I think could be enhanced by implementing a Domain Specific Language for defining a set of rules and/or conditions for some type of work-flow.
I want to get a firm grasp on the subject, fundamentals, best practices, etc. specially how to implement them somehow with Java.
What do you suggest?
First I would recommend reading chapter 9 (Notation) of The Practice of Programming by Kernighan and Pike.
When you have done that, come back here with specific questions on how to map the concepts in that chapter to specific designs for the problems you want to solve.
The basic pattern is to write an interpreter that is passed a 'command' argument, and possibly an 'environment' argument and executes the command (in the environment). You then have the option of writing a parser, that takes a 'script' string and converts it into a valid 'command' object (ie. an external-DSL); or you provide a library to help users build the 'command' object explicitly in the same language you are using (internal-DSL).
Kernighan and Pike do a good job of showing both how trivial and how complex an interpreter can be. If you want more depth, then I would suggest reading The Essentials of Programming Languages by Daniel Friedman et al. Which builds at least one different interpreter per chapter, and demonstrates how to implement features such as variables, functions, scopes, objects, classes, static-typing, and continuations.
However I would suggest trying your hand at a trivial DSL first, otherwise it's all just theory—a book is much more interesting when it is made relevant and practical by your previous experience.
As others have commented, Java really isn't a great choice for creating a DSL. Scala, Clojure, Groovy, Ruby/JRuby would all be great choices. However, considering you were thinking about using Java, I think Groovy or Scala seem like the most natural choices. The learning curve for java developers is quite gradual for both languages. Here are some links that will get you started:
Groovy for Domain-Specific Languages (Book)
DSLs - A powerful Scala feature
DSL Composition Techniques in Scala
Once I used openArchitectureware to define and use a DSL. oAW is a plugin to eclipse and now part of the eclipse modeling framework, but of course it can be used outside EMF too.
I liked it because it was fairly easy to define a DSL and oAW will automatically generate an editor with syntacx highlighting and error checking for the DSL.
And it provides a template engine that is pretty comfortable if you plan to use documents written in your DSL to autogenerate Java, XML or other files.
(I've linked the old oAW URL because the page still provides some details and all links to the eclipse project pages)
Just an addition to #Recurse. I'm actually doing the regex example in chapter 9 he was referring to and it didn't work until I changed a line in the main function:
if (grep(argv[1], f, argc>3 ? argv[i] : NULL) > 0)
should really be:
if (grep(argv[1], f, argc>2 ? argv[i] : NULL) > 0)
notice the argc>2. It worked for me after that. Wasn't on the books errata (which is not surprising given it's age).
Yeah, this is a dense but treasure trove of a book so I have to say I agree with #Recurse. Honestly, it's a time sensitive book for the student (I probably would have been confused a couple of years ago).
Related
In my search for this answer I have already read the following StackOverflow post.
Definition of a Java Container
My issue (lack of understanding ) at this point as a beginner is also learning the esoteric vocabulary. Therefore, even excellent examples often make little or no sense.
For this question please create an answer for the very, very, green beginner.
The actual question:
For the "Definition of a Java Container" give a tangible example, preferably using the NetBeans project tree, of what a Java Container is. A screen-shot would be very helpful for us extremely visual learners.
For example, if I were trying to answer the question "what is a container file" to a computer 101 student, I would probably not say something like this:"A container or wrapper format is a metafile format whose specification describes how different elements of data and metadata coexist in a computer file.
Rather, I would answer like this: "A container file is a ZIP file, MP3 or MP4 file. The reason it is called a container is that it actually contains many other files - much like a directory."
UPDATE
I found this Wikipedia article that I believe begins a decent explanation.
https://en.wikipedia.org/wiki/Container_%28abstract_data_type%29
For example, according to the above article, a simple example of a "container" in a programming language is an array. In object oriented programming languages fancier arrays such a Lists and Maps are also containers. However, for any beginning programmer reading this post, containers are also Classes that form a chain of inheritance (experts correct my terminology if I am wrong).
For beginners, if you do not know what inheritance is then go study that. There is another Wikipedia article to read.This whole article is describing "containers" in Java.
https://en.wikipedia.org/wiki/Java_collections_framework
To give the sort of example I was originally asking for, if you have NetBeans then go do this:
Create a new class, then inside of it create a new method, as shown below:
package InformationStorage;
public class MyClass {
public void MyMethod(){
}
}
Now, inside the method type the command "System", and then type a period. Like this:
["Screen shot from NetBeans"][3]
Notice the list of methods and other stuff included within "System". If you choose one (for example "out" as in System.out.), then when you type the period after "out" more sub-options appear, and so on.You will eventually end with something like "System.out.println();"
This is an example of Container Classes.
Frustrated-Me this question is posed just like your name haha. Anyway I will answer. There is allot of programming jargon that will not make sense to a beginner, I wouldn't worry about it at beginner stage. So yes there is a container which is the same as say a Collection (List,Map,Set...Array is maybe one too), which just contains other data members.
But then this term is used in another way in Java and other programming languages and frameworks.
What is a container in this sense? Well I guess I would say it's complicated thing that does allot of stuff for you in layman terms. You see, something like programming a website is very complex, and Java as a programming language can be considered verbose by some, this makes for a very difficult time for a developer. So there are all these fancy frameworks, for instance: Spring which may all share some similar concepts such as dependency injection, aspect orientated programming or whatever ever else. Even if you don't know what those things are they are just ways to help the programmer develop a complicated piece of software.
These concepts are often implemented in something that may be called a container. Basically you put your POJO (instances of a java class) in this container, and the container adds functionality to what you have done, via DI, or aspect orientated programing or something else. Usually these containers are built on design patterns such as the proxy or cake or MVC ect.
One might be able to say that a container in this sense does more than just storing your objects/data, but adds additional functionality to make your life easier.
So for the summer I decided that I may as well start learning algorithms before school starts. I've been told that the class is fairly fast paced, and that algorithms isn't something you should take lightly (I have a tendency to do this with all the course work during the semester lol).
The book we're going to use is this Algorithms (4th Edition).
Anyway, this is my problem.
I'm almost third way through the book, but I just realized what I was doing. For example, I would read and re-read the sections I don't quite understand. Then if I feel confident enough, I would try to reproduce the same algorithm in java from my head. But by doing this, my code looks almost exactly like the ones in the book..in java.
I can't say I'm just memorizing code after code--I do understand the concepts and they help me code these algorithms--but I feel like I'll only be able to implement these algorithms in java. I should note that I only know java at the moment.
tldr: I'm learning algorithms as if I'm learning to play the guitar--repetition after repetition. But by doing so I feel like I'm being more fixated that I'll only able to implement these in java. How exactly would you learn algorithms if the book you're using is language-specific?
Thanks in advance.
Don't Confuse Yourself
You're studying Java, so write them in Java. Especially if Java is your first language. Don't confuse yourself for now, as you are trying to learn 2 things at once: how to progam in Java, and how to progam. You're learning both a new language and a way of thinking. Don't do too much but adding another language to the sauce for now.
Diversify
Later on, or if you feel confident enough that you can take on another language simultaneously, then it would obviously be beneficial to learn another one and try to replicate the algorithms without looking at the book.
Reproduce and Extend
What we could recommend you is to look for derivates of the algorithms. Known variants, that have been documented, and where you could just read the description of the variant so you can try to implement it from the "base" version, without needing to read the book.
For instance, if your book introduced you to a linked list, you should be able to come up with the algorithm for a doubly-linked list or a circular linked list without reading more than a description of the desired outcome. Or there's something about the original concepts that you clearly misunderstood.
Try First, Read-On Later
I'd recommend you actually even try to implement the algorithms described in your book before they show them to you. The point of seeing Sedgewick's algorithm is to see a canonical implementation, which is considered a standard blueprint. If you just read the section leading up to the implementation (which hopefully is displayed first), then just sit down with the book, and try to figure out how you could do that. If you can't do that at all, then you're too far ahead in your book and should backtrack and start again from scratch.
Thing about algorithms, they're essentially language-agnostic. There's really nothing stopping you from doing Sedgewick's examples in C, Python or some other language.
If you really don't know any other languages, concentrate on Java. Sure, its a bit repetitious, but those bits will stick in your head in a good way and come test time, you'll be glad for the information.
You're in an interesting position right now, since the kind of thinking required to write programs is very different from normal thinking. Add to that the fact you're learning a whole new language with a different syntax, punctuation and the like. Practice really does make perfect, since there are many bits and pieces to remember.
Oh, if you want practice with algorithms, try out project euler, code kata and other challenge sites. These little challenges can help you familiarize yourself with the language as well as get comfortable with the type of thinking required.
First, congrats on taking your first steps on learning how to code. I would say that you are already ahead of your peers by starting to look ahead during the summer.
As far as your fears on only being able to implement algorithms in Java, you have already demonstrated that it will not be a problem for you. It sounds like you are passionate enough to get started early so you should have no problem implementing a solution in multiple languages. Additionally most of the languages with C/C++ (Java and C# to name a few) like syntax will be similar enough that you will be able to translate your knowledge seamlessly.
The best advice that I can give is to CODE, CODE, CODE!! Don't just read about the algorithms actually implement them.
You don't say how well you know the mathematics behind the algorithms. That will be key in determining your facility with the code.
Sedgewick's books are very good. I'd feel free to pick some and check out other books as well, like "Numerical Recipes" and "Numerical Methods That Work". See if another point of view can clarify for you.
If you don't feel like you're getting enough out of copying Java, see if you can translate them into another language, maybe Python or purely functional alternative. If you can do that, you'll know you've got it.
I would either try to learn another language to verify that you can actually port it to another language (javascript would be my vote because it is simple and useful on the front and backend) or write the algorithms out in pseudocode since that is more language agnostic. Most languages will have the code look pretty similar. The only thing to be very careful about is when you are relying on some aspect of the language (such as generics or iterators in java) which you may not be able to use in another language and that could leave a gap in your understanding.
Another way to verify that you actually understand the algorithm is to make slight changes in the problem and make sure that you can adjust the algorithm to still work. For example if it is a sorting algorithm then try to sort by several different attributes rather than just one, if it is a graph algorithm make the graph a digraph and see how things should change.
I'm learning algorithms as if I'm learning to play the
guitar--repetition after repetition.
Then you are not learning algorithms. You are learning repetition. Two different things. The usage of a programming language by an algorithms book is a secondary factor. It is just a vehicle of instruction, an implementation detail.
What you should be focusing is on understanding the structure, logic and mathematical characteristics of an algorithm (and possibly the data structure(s) associated with it.)
That's what your focus should be.
But by doing so I feel like I'm being more fixated that I'll only able
to implement these in java.
But that is because you are focusing on just how the algorithm is being coded (in Java in this particular case.) You are focusing on an implementation detail.
When you learn to drive, you don't focus on how you learn to drive a Honda Civic or a Nissan Maxima. You learn the essence of what driving is, the rules of thumbs, the necessary precautions and the laws governing driving a vehicle.
Same with learning algorithms. You don't learn "Algorithms in Java" no more than "Algorithms in Haskell". You learn Algorithms first and foremost, the vehicle (sans very specialized cases) is secondary.
You should be focusing on what the algorithm does, how and why. Questions like "how/why does it work?" and most importantly *"what are the performance characteristics?", those are the things you should be focusing on.
Every good algorithms book (Sedgewick's included) carry that message. That's what you should focus on. How you get to that re-focusing, that's a function of one's personal learning strategies.
How exactly would you learn algorithms if the book you're using is language-specific?
By not focusing on the language. Focus on the structure, focus on the data structures involved, the invariants, pre-conditions and post-conditions. Understand asymptotic behavior described in Big-O (or Big-Omicron), Little-O/Little-Omicron and Omega notations.
You are learning algorithms, not programming in Java via coding algorithms.
If you can't do this mental leap, it means you do not have sufficient practice or abstract analysis. It is not an insult, but an observation and an advice. Coding, the usage of a programming language is typically secondary to the mathematical analysis of computing, the focus of Computer Science (of which Algorithms is a part thereof.)
NOTE I've done Java for over 10 years, and though I like it for work, I strongly believe it is a poor tool for learning programming or CS topics.
One is better served by learning Algorithms with either A) a procedural, systems-level programming language like C or Ada, or a high-level pseudo-assembler simulator, or B) a functional language like Lisp or Haskell.
Object-Oriented features in pure/pseudo-pure OO languages simply get in the way.
Algorithms are mathematical structures with a nature descriptive of the how (operationally) and/or the what (mathematically). The former is perfectly suited for procedural programming, the later for functional programming.
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've been a Java developer for several years now. Lately there's been quite the buzz over Groovy. I checked it out and it looks interesting and all, but I'm not seeing any inherent "wow factor" to it; meaning, I'm not seeing any intrinsic value to begin developing in it.
Now, I'm positive that I'm just not seeing the forest through the trees here. So, I ask the SO community at large: how would learning Groovy behoove any Java developer? What features/capabilities/etc. does it do (or do better) than plain ole' Java?
Things in the software world don't take off like wildfire without a reason. I'm sure Groovy has all sorts of nifty little (and big) capabilities that make it a must-know; I'm just not "getting" it. Thanks in advance.
In my opinion, some of the biggest adventages Groovy has over Java are:
terser code thanks to overloaded operators and simplified property access. Instead of writing
if (obj1.getBar().equals(obj2.getBaz())) {
obj3.setFoo("equal");
}
you can write
if (obj1.bar == obj2.baz) {
obj3.foo = "equal"
}
which I consider much more readable.
inline notation for Maps and Lists. Instead of
Map attributes = new HashMap();
attributes.put("color", "red");
attributes.put("width", 1);
you can write
def attributes = [color: "red", width: 1]
useful extensions to standard libraries. For example, you can read files and webpages like this:
def fileContents = new File('readme.txt').text
def pageContents = new URL('readme.txt').text
syntactic sugar for initializing properties - for example,
MyClass myObject = new MyClass();
myObject.setFoo("bar");
myObject.setBaz(23);
can be replaced by
def myObject = new MyClass(foo: "bar", baz: 23)
'safe' dereferencing - if (str != null) {return str.toUppercase();} else {return null;} becomes return str?.toUppercase()
Regular Expressions look nicer
Closures allow you to write code in 'functional' style, and make writing things like event listeners way easier
... since no one pitched in so far, I'd suggest looking at the Grooy mailing list. Similar questions pop up from time to time regarding Grails as well. Those are great communities of people who at some point or another faced the same type of questions.
I'll add another, since I don't see it explicitly mentioned.
For me, while terseness is nice on its own, it isn't the main point.
Whatever code you write, Java will always look like Java, and it will never read like the problem you're solving--it will read like Java, solving your problem.
I want the reverse: I want my code to read like the problem I'm solving, written in [insert language here].
Groovy is more expressive, more malleable than Java. It can look like what I'm trying to do. Canonical examples of this include internal DSLs. One I've used frequently is easyb, which is just Groovy code, but sounds like what I'm doing when I read it out loud. There are a bunch more examples, but easyb is an easy sell.
Also not mentioned are the AST transformations allowing cool compile-time tricks. You can play similar games in Java with things like AspectJ, but it's not as "baked in". Things like #Delegate, #Singleton, etc. are just plain handy.
For me, a language needs to be malleable, deformable, flexible: Java is not. Java has an impoverished model of abstraction making it frustrating to work with--the amount of extra work, writ both small and large throughout the language, is mind-boggling at times.
You're kinda late to the party. Groovy saw its dawn about 4 years ago when people fed up with Java's ridiculous verboseness were ready to give up performance in the sake of code reduction and Groovy was providing them with exactly that in a very familiar syntax. But now that it's been there for a while it gets dragged by its past as much as every language does and some not best design decisions are there to stay as much as I'm pretty sure are its performance issues. This basically was the reason of emergence of Groovy++, the whole existance of which suggests that there are some problems with its predecessor. And in fact Groovy++ addresses a lot of issues of its predecessor, but it also has its own problems: the main one being that it's basically driven only by the devotion of a one man - Alex Tkachman that is, - and no funding, so you should see all the risks involved.
Nowadays that more and more strong rivals appear (Kotlin, Ceylon) it becomes obvious to me that Groovy has already passed even its zenith - even its core team is trembling (you should see their discussions on Grumpy mode). This was the reason for me to start gradually leaving this technology in preference to Scala and to look forward to forthcoming Kotlin which both are great projects but take some effort for a "Java mind" to switch to, but are definitely worth it.
Updates due to hypercritical response:
Design mistakes:
Restricting syntax for Java paste-in compatibility, while a seemingly neat feature in practice turned out to be not used at all, 'cuz migrating Java code to Groovy is generally a bad idea for the same performance reasons. But this resulted in inheritance of some Java's ridiculousness like not being able to define a variable of the name used in the outer context
While keeping some of Java's bad practices they got rid of some of its good features too, like code blocks demarked with curly braces in preference to closures. The issue solved much neater in Scala
Dynamic typing was mainly chosen because decent type inferring was hard to realize - that was basically the reason for Groovy's creator to later state that he would have never bothered creating it if he knew about Scala back then.
Googling for "groovy performance" will give you enough results. Here is one: http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html
I never stated that Groovy++ is the same project as core Groovy.
I would like you to know that I once was a huge fan of Groovy and was developing in it exclusively for 2 straight years. Moving on to a new language was a very hard step for me to take. But since I know Groovy's every corner, I know its core team and its tendencies you should understand that I know what I'm doing when I'm recommending not to consider Groovy as an alternative to Java.
First of all, I have a very superficial knowledge of SAP. According to my understanding, they provide a number of industry specific solutions. The concept seems very interesting and I work on something similar for banking industry. The biggest challenge we face is how to adapt our products for different clients. Many concepts are quite similar across enterprises, but there are always some client-specific requirements that have to be resolved through configuration and customization. Often this requires reimplementing and developing customer specific features.
I wonder how efficient in this sense SAP products are. How much effort has to be spent in order to adapt the product so it satisfies specific customer needs? What are the mechanisms used (configuration, programming etc)? How would this compare to developing custom solution from scratch? Are they capable of leveraging and promoting best practices?
Disclaimer: I'm talking about the ABAP-based part of SAP software only.
Disclaimer 2, ref PATRYs response: HR is quite a bit different from the rest of the SAP/ABAP world. I do feel rather competent as a general-purpose ABAP developer, but HR programming is so far off my personal beacon that I've never even tried to understand what they're doing there. %-|
According to my understanding, they provide a number of industry specific solutions.
They do - but be careful when comparing your own programs to these solutions. For example, IS-H (SAP for Healthcare) started off as an extension of the SD (Sales & Distribution) system, but has become very much more since then. While you could technically use all of the techniques they use for their IS, you really should ask a competent technical consultant before you do - there are an awful lot of pits to avoid.
The concept seems very interesting and I work on something similar for banking industry.
Note that a SAP for Banking IS already exists. See here for the documentation.
The biggest challenge we face is how to adapt our products for different clients.
I'd rather rephrase this as "The biggest challenge is to know where the product is likely to be adapted and to structurally prepare the product for adaption." The adaption techniques are well researched and easily employed once you know where the customer is likely to deviate from your idea of the perfect solution.
How much effort has to be spent in
order to adapt the product so it
satisfies specific customer needs?
That obviously depends on the deviation of the customer's needs from the standard path - but that won't help you. With a SAP-based system, you always have three choices. You can try to customize the system within its limits. Customizing basically means tweaking settings (think configuration tables, tens of thousands of them) and adding stuff (program fragments, forms, ...) in places that are intended to do so. Technology - see below.
Sometimes customizing isn't enough - you can develop things additionally. A very frequent requirement is some additional reporting tool. With the SAP system, you get the entire development environment delivered - the very same tools that all the standard applications were written with. Your programs can peacefully coexist with the standard programs and even use common routines and data. Of course you can really screw things up, but show me a real programming environment where you can't.
The third option is to modify the standard implementations. Modifications are like a really sharp two-edged kitchen knife - you might be able to cook really cool things in half of the time required by others, but you might hurt yourself really badly if you don't know what you're doing. Even if you don't really intend to modify the standard programs, it's very comforting to know that you could and that you have full access to the coding.
(Note that this is about the application programs only - you have no chance whatsoever to tweak the kernel, but fortunately, that's rarely necessary.)
What are the mechanisms used (configuration, programming etc)?
Configurations is mostly about configuration tables with more or less sophisticated dialog applications. For the programming part of customizing, there's the extension framework - see http://help.sap.com/saphelp_nw70ehp1/helpdata/en/35/f9934257a5c86ae10000000a155106/frameset.htm for details. It's basically a controlled version of dependency injection. As a solution developer, you have to anticipate the extension points, define the interface that has to be implemented by the customer code and then embed the call in your code. As a project developer, you have to create an implementation that adheres to the interface and activate it. The basic runtime system takes care of glueing the two programs together, you don't have to worry about that.
How would this compare to developing custom solution from scratch?
IMHO this depends on how much of the solution is the same for all customers and how much of it has to be adapted. It's really hard to be more specific without knowing more about what you want to do.
I can only speak for the Human Resource component, but this is a component where there is a lot of difference between customers, based on a common need.
First, most of the time you set the value for a group, and then associate the object (person, location...) with a group depending on one or two values. This is akin to an indirection, and allow for great flexibility, as you can change the association for a given location without changing the others. in a few case, there is a 3 level indirection...
Second, there is a lot of customization that is nearly programming. Payroll or administrative operations are first class example of this. In the later cas, you get a table with the operation (hiring for example), the event (creation, modification...) a code for the action (I for test, F to call a function, O for a standard operation) and a text field describing the parameters of a function ("C P0001, begda, endda" to create a structure P001 with default values).
Third, you can also use such a table to indicate a function or class (ABAP-OO), that will be dynamically called. You get a developer to create this function or class, and then indicate this in the table. This is a method to replace a functionality by another one, or extend it. This is used extensively in the ESS/MSS.
Last, there is also extension point or file that you can modify. this is nearly the same as the previous one, except that you don't need to indicate the change : the file is always used (ZXPADU01/02 for HR modification of infotype)
hope this help
Guillaume PATRY
I recently got into Java. I have a background in dynamic languages and I'm finally figuring out why people complain about Java's verbosity. Are there any class libraries out there that address this issue? I'd much rather type something like String text = someClass.stdin() instead of the 8 or so lines it takes to get user input in Java.
In Java 5:
import java.util.Scanner;
...
System.out.print("Enter your name: ");
String userName = new Scanner(System.in).nextLine();
Or, in Java 6:
String userName = System.console().readLine("Enter your name: ");
Some of the Apache Commons libraries (particularly Lang, IO and Collections) are designed to hide the verbosity of certain core Java APIs. The verbosity of the Java language, however, we're all stuck with.
Sure there are several JPython, JRuby, Clojure, Scala...
Google has also released a number of libraries that complement sections of the standard library, like the collections library. Guice is also a nice lightweight DI framework that, IMHO, is easier to learn that spring.
The standard library is so large I don't think you'll find a single library that replaces everything. You're best bet is to look for libraries that solve individual problems (i.e. I don't like the Collections API, I need an object pool, etc.)
I'd be interested in seeing these 8 lines to get user input in Java.
I personally think that Java's verbosity becomes an asset as your program becomes larger. Unlike C and C++, everything is done in a more object oriented way. You get the object representing your output, then you issue an operation on it, and so on. Much easier to understand and maintain in the long run.
Is this as quick as a nice printf() here and there? No. Is it as convenient as scripting in Python? Of course not. But that's part of the cost of using a language like Java, just like the lack of Lambdas is annoying.
As an engineer your role is to pick the best tool for the job. I do most of my coding in Java, and some in Python, accepting the tradeoffs of each.
While you can't change the language, you could use libraries that simplify some operations (e.g., Google's or Apache's IO libraries). You could also write your own classes for the things that annoy you the most.
I also think you're confusing the verbosity of the language and of the standard library. The library contains a lot of stuff, most of it you'll never need. I find the existing division fairly straightforward and have never found myself in areas I didn't care about.
If you really can't stand Java, you might want to use hybrid languages like Scala.
I'm a big fan of leaning on my IDE's live templating features. (IntelliJ IDEA) I can't remember the last time I spelled out StringBuffer or System.out.println("...").