One problem in a project with Domain Driven Design:
In discussions about the domain model, many terms of the Ubiquitous Language (UL) are used in German by the team members (all German speakers) , whereas the English version is used within the analysis model and the code model.
What is good practise to handle this issue? Should we force us to use the English term in discussions also, or is it ok to translate the term for modeling and implementation?
I've also worked in multiple, german DDD projects.
In my experience, the team usually automatically starts to use the english terms as soon as there have been first discussions and a first implementation. It helps if you maintain an up-to-date glossary of the german terms and their english counterparts especially to help new team members.
I think UL is just another language, like german or english are. The point is that it has to be spoken and understood by all team members. And it has to be used every where, discussions, documents, diagrams, source code, ...
You cannot use a german term in discussions and its english translated term in source code.
Working in Germany, I was involved in a banking project once where the Team (all Germans) decided to use English to write code, on the off chance that some offshore team might also later be involved.
A couple of months later we already struggled with our English dictionary. We noticed that we (and the business people) would have no problems with the German words, but we ourselves did not always knew the correct translations in the code. Some concepts (like legal terms, etc.) don't even always have a correct translation.
It got even worse. As some offshore colleagues were involved, they started asking for the German words behind some things in the code, because they could google the German words, but not always the English ones. (Might be caused by our bad translations to English...)
Having gone through all of that, I would take whatever the "source" language is into the code. If the source material (requirements, legal framework, business team, etc.) is in German, then German.
The only argument against using German is that it looks and sounds really funny and strange. Oh, and Unicode support is a must. Class "Überweisungsvorlage" vs. CashTransferTemplate.
I know of another Team which combined English verbs in methods with German concepts, like "createÜberweisungsvorlage", because German verbs are quirky and do not lend themselves to short and uniform conventions.
Summary: You decide, and good luck :)
Use whichever language your domain experts use. If many, ask them to choose the one that defines the domain best.
The best language can be different from one subdomain/Bounded Context to another.
Related
I am working on a graduation project related to "Aspect extraction (AE)".
I'm pretty confused about POS taging, syntax tree, grammar rules, and other low-level NLP stuff. I need a reference that teaches me these things in detail, so if any of you know I hope you don't mind me?
I know my question is not about programming directly and this may not agree with the site, but I really need to.
This is not an easy one! I assume that you are trying to understand the underlying 'why' and 'what', so, if I were you I would start with the one and only "Speech and Language Processing" by Daniel Jurafsky and James H. Martin. They have a whole section (Section 17 in my Second edition) on the representation of meaning, and state representation, with a whole subsection on Aspect.
In addition to that, the book will also help you understand various existing approaches to POS-tagging and the other topics you mentioned above, and, the book is available online for free! There is even the draft of the 3rd edition out there.
Additionally, after reading the chapters above, you can check out how other people do aspect extraction here
I need to extract people names from documents in German (not my native). After a bit of search, I've found GATE framework which seems to support English, German and many other languages. The accuracy for English is quite decent, but it's unacceptable for German (see screenshots).
Here are the PRs:
And a chunk of highlighted people names:
A friend of mine says that none of these is a person name, so I wonder if I misconfigured something. Do I need to specify the language somehow?
Solution: Install the Language: German plugin and use it. The accuracy is still poor though, at least for my case.
Most programming code, I imagine is written in English. But I'm curious how people are handling the issue of naming herein. A lot of programming is done within some bussiness domain, usually with well established terms for certain procedures, items.
I'm from Denmark for instance, and something I work a lot with has a term called "indblikskode", which sort of translates to "insight code". So, do I use the line "string indblikskode = ..." in the C# code for some web service related to this? Or do I try to use a translation, such as "insightcode"? The bussiness I'm in isn't even consistent in its language, for instance using the term "organisatorisk enhed" (organizatorical unit), but just as often using the abbreviation "OU", which is obviously abbreviated from the English.
How do other people handle this naming issue, while keeping consistent, and sane (in everything from simple variable names in your code, to database tables, to server names)?
Duplicates:
Should identifiers and comments be always in English or in the native language of the application and developers?
Do you use another language instead of English?
I can only speak for myself, but I always translate terms into English when naming classes and variables, and it's one of our unwritten best coding practices to do so as well. You never know when you might need to hand off development to cheaper labour abroad or the expert expat consultant in town.
The problem with non-English naming of classes and functions is, that you invariably going to end up with macaronic pidgin. Keywords are in English, naming conventions (like for example getters/setters) are also English, same for standard names for design patterns.
You're going to end up with stuff like:
OrganisatoriskEnhedFactory::getInstance()->getIndblikskode();
See my question and answer here.
Basically it depends on your organization and the application. If your company, developers and customers all speak the same native language and you expect it to stay that way, then it would be extremely counter-productive to have everyone become a part-time translator as well. Considerable productivity loss for a purely hypothetical future advantage. YAGNI.
If it's a large international company, or if there are concrete plans to expand internationally or have some work done offshore, it's a different matter, of course.
Having worked in Switzerland (German side ie Zurich) and lived in Germany for a time I can tell you that I've yet to see an environment where the code isn't in English. Sure the application may well be in German (but many professional environemtns are English-speaking anyway) but the code (I've seen) is pretty much all English.
It's hard to write code in other languages. For one thing, the APIs are (nearly) all in English. Java uses JavaBeans naming for example so you have to use set and get anyway and "getGeburtstag" just doesn't have quite the same ring to it as "getDateOfBirth".
Other countries may vary for this has been my experience from the Germanic countries.
We're usually using established English terms (our business domain usually has English terms), but if I can't figure out any suitable term, I could as well use Finnish. Heck, even our comments in code are in mixed languages...
Of course the sensible approach depends largely on whether the source code will ever be used outside the building. In a small shop it's not such a big deal.
I'm working in a company in Austria (so we're talking German) and we are programming in English (variable names, domain objects, GUIs). Makes it a bit more cumbersome, because you have to find the English translations and you have to translate the GUI before releasing the program. I'm not really sure if all the names are really correct.
In contrast in the former company I was working for programmed strictly in German. This was pretty nice (altough German words tend to be longer than English words). After some years the company wanted to use the same program in the USA, so English-speaking programers had to use the same codebase. after this everything got pretty inconsistent- variables, database fields.. in both languages (the English speaking team members didn't talk German).
My experience is that it is easier to handle internationalization in the early beginning (you are forced to do it when you write the program in English) of an application, because it is no big fun localizing a 10000 LOC application. The advantage of writing in another language is that you see instantly what is localized and what is not - altough it's work you have to take in account for that.
To the untranslatable words: we hadn't expierienced that yet - altough it was some work finding the English phrase for "intra-community deliveries" (that's an EU thing). But if that would happen I'm pretty sure we would use the German word.
I live and work in Germany but write English code only. It makes things easier. You can post your code on the net if you want to ask questions or want to publish tutorials about your work.
Also the code looks more "professional" for me.
I also live in and work in Germany for now and we mostly use English except for some old comments in German. I think non-English comments are generally very bad idea since you'll have to spend time trying to understand it (and understand correctly). Although both German and English are not my native languages, code written in anything other than English seems to be bizarre.
You'll never know who would be working on your code the next day. So you should use the universal IT language.
P.S. Since I do not like non-English languages in my development environment, I made a local administrator quite angry when I refused that my PC be installed with German Windows, German Office and German Visual Studio. It took many hours to download the English versions just for me.
Though I think it is good one day to install a language pack or just a different copy of the same software just to learn the terminology. SQL Management Studio in French makes me really excited, just as when I tried to switch Skype to Spanish.
Though at our company all people are non-native english speakers we try hard to write our documentation, code and comments in english, pretty much everything except user-related stuff, of course. This is ok as long as business terms are translateable and not too specific to the domain. But once the business terms get too specific, either there is no adquate translation for them or the translation just sounds silly and meaningless.
This leads to a awful language-mix when writing code.
What is your experience on this topic? Do you avoid silly names in code by all means or do you just live with it?
I think that trying to keep everything in English when all developers and users have a common non-English native language is not only useless but actually harmful. Domain terms are just the most obvious example.
IMO all domain terms should stay in the native language, as should documentation and comments. This allows developers to concentrate on the code's logic rather than translation issues. It may look silly to have a mix of two languages in the code, even within single method names, but IMO it's not really a problem and better than making a great effort to have everything in English when nobody actually benefits from it.
Of course, this only applies in the described scenario. If you're a department of a large international company, or planning to expand your market internationally, or your native language has not very many speakers, then it's a different matter.
I've no experience with this as I am a native English speaker. However when the domain is complex, Extreme Programming suggests that you use a metaphor that programmers and customers are comfortable with.
This could be applied in your situation.
We have exactly the same problem in our company. We try to write the code and examples in English, but we often find unsolvable situations where direct common names in our native language have no direct or unknown translation or equivalence. So from my point of view, it is almost impossible to avoid mixing languages (will actually Spanglish be the language of the future despite my will?).
Basically it is a matter of two things:
Insufficient general English language knowledge.
Not everybody is perfectionist enough to spend some seconds to find out on Internet how to correctly say something, so what first comes to mind goes to code.
The effects of these are:
Comments can not be ununderstandable by native English speakers (because the used words do not exist or sentences are a literal translation from source language).
Incorrect translations full of false friends or invented words. A typical example of this would be using "actual" word for "current" meaning since it is what "actual" means in Spanish.
The actual solution to this is try to correct this is to attack the source of the problem:
English tranining courses (included applied technical English) should be a must in the company, so every worker could reach a minimun acceptable level of English knowledge.
Force the not-so-perfectionist people to follow some rules of coding by defining a stylesheet of code or even better have a QA department that enforces the quality of code, grammar of comments and readability included.
On my reading spree, I stumbled upon something called Intentional Programming.
I understood it somewhat, but I not fully. If anyone can explain it in better detail, please do. Is it being used in any real application?
You got me started on this one...
Looks like C. Simonyi wanted to step to the next level of abstraction from High level languages. Reduce the dependency of customers on developers to make every change.. in code (cryptic for people not in development).
So he invents this new product called IP, which has a WYSIWYG type GUI editor to create a domain specific model. (i.e. IP has a GUI to create the building blocks for your app.. LISP allowed you to create the meta/building blocks but not in a way that domain experts could easily do it.)
Like the models in UML, the promise is that you can auto-generate the corresponding source code at the "push of a button". So the domain experts can tweak the model in the future and press the Bake button to deliver the next version of the app.
It seems to utilise DSLs however with the added benefit that multiple user-created DSLs can talk with each other via a built-in IP mechanism... which means the finance model and sales model can interact and reuse blocks as needed. As with DSLs, you get the benefit of code that conveys developer intent rather than appeases implementation language constraints.
The idea being to give greater control to the BA and domain experts who actually know what's needed...
Update:
Real world use looks like 'not yet'.. although Simonyi believes 'absolutely in the long term'.
Short Story: MS squished IP in favor of .Net framework, Simonyi left MS and formed his own company 'Intentional Software'.. with the contract that he could use the IP ideas but he would have to rewrite his working proto from the ground up.. (that should slow him down). It's still Work-In-Progress I think.. and being written in C# (to boot)
Sources:
Anything you can do, I can do meta by Scott Rosenberg, MIT Tech Review (2007)
To think till yesterday.. I didn't know a thing about this. Investigative reporter signing off. Going back to day job :)
It's the opposite of what happens when I come home at 2am after a pub crawl and fire up the laptop "just to check my email real quick, hon."
Then, the next day, when I peel open one eye and find my way to the bathroom at the crack of noon, I start brushing my teeth and realize, toothpaste dribbling out of my mouth, that last night I made 4 SVN commits, closed 3 bugs, and figured out how to solve the starvation problem on our distributed locking protocol. And I have no idea how the hell any of it works, anymore.
Or maybe it's what workmad3 said.
It appears to be a method of programming that allows the programmer to expand what is actually in the language to more closely follow their original intent, rather than forcing the programmers intent into the constrained syntax of the language.
It explicitly mentions LISP as a language that supports this, so I'd suggest you read up on this great language :) LISP Macros are exactly what are described in the article, allowing you to indefinitely expand the language to cover almost anything you would care to express. (A fairly common outcome of large LISP systems is that you end up with a domain specific language that is very good for writing specific applications, i.e. writing a word processor ends up with a word processor specific language).
For your last part, yes LISP (and thus Intentional Programming) is used in some projects. Paul Graham is a great proponent of LISP, and other examples of it include the original Crash Bandicoot (a game object creation system was created in LISP for this, including a LISP PlayStation compiler)
I have a slightly different understanding of Intentional Programming (as a more general term, not just what Charles Simonyi is doing). It is closely linked to fluent interfaces and can be achieved, with various degrees of difficulty, in modern Object Orientated languages.
Some of these concepts come from Domain Driven Design (in fact the term "fluent interface" has been popularised by Eric Evans, the author of "the" blue book - Domain Driven Design: Tacking Complexity in the Heart of Software).
The aim is to make business layer code readable by a non-programmer (i.e. a business person). This can be achieved by class and method names that explicitly state the intent of the operation. In my opinion, being explicit and being intentional produces highly readable and maintainable code.
Consider the two examples below that achieve the same thing - creating an order for a customer with 10% discount and adding a couple of products to it.
//C#, Normal version
Customer customer = CustomerService.Get(23);
Order order = new Order();
//What is 0.1? Need to look at Discount property to understand
order.Discount = 0.1;
order.Customer = customer;
//What's 34?
Product product = ProductService.Get(34);
//Do we really care about Order stores OrderLines?
order.OrderLines.Add(new OrderLine(product, 1));
Product product2 = ProductService.Get(54);
order.OrderLines.Add(new OrderLine(product2, 2)); //What's 2?
Order.Submit();
//C#, Fluent version
//byId is named parameter, states that this method looks up customer by Id
ICustomerForOrderCreation customer =
CustomerService.GetCustomerForOrderCreation(byId: 23);
//Explicit method to create a discount order and explicit percentage
Order order = customer.CreateDiscountOrder(10.Percent())
.WithProduct(ProductService.Get(byId: 34))
.WithProduct(ProductService.Get(byId: 54))
.WithQuantity(2); //Explicit quantity
Order.Submit();
By changing your programming style slightly, you are able to communicate your intent more clearly and reduce the amount of having to look at code elsewhere to understand what's going on.
Seems to me like yet another fad of software engineering. We've seen thousands of them already: meta programming, generative programming, visual programming, and so on. For a short time they get very fashionable, people use it everywhere, and then they invariably go back to old ways of creating software.
Why? Frederick Brooks has already answered this question over 20 years ago: there's No Single Silver Bullet to kill the werewolf...
Intentional Programming is encoding your intent, or goals. Thus it is Goal-Oriented Programming or Planning. Step up to manangement.
It's where you intend to program, you don't just accidently do it. ;)