Microsoft Dynamics Programming Language ?

Joseph_Abou_Nader

Hello

Do you know which programming language will be used to develop Microsoft Dynamics...? Based on Microsoft, the .net framework will be used...but it is not specified which language? Will they continue using the native languages ( C-Side for NAV, Dex for GP ) ?

Any ideas??

Regards

Waldo

Joseph Abou Nader wrote:

Hello

Do you know which programming language will be used to develop Microsoft Dynamics...? Based on Microsoft, the .net framework will be used...but it is not specified which language? Will they continue using the native languages ( C-Side for NAV, Dex for GP ) ?

Any ideas??

Regards

First of all ... just ignore BlackTiger...

Second of all ...
As far as I know, MS hasn't confirmed that they will turn this into only one product. They are still doing much development in all environments, making it look (almost) the same. But keep in mind that even in 5.1 you'll be working in C/SIDE and writing C/AL code. Also keep in mind that all products have got its own market, and is it really an advantage to create only one product for all markets?

It's still guessing what they'll do.

What do you think about this: What if ... NAV is brought onto the .NET framework, you'll have something like a C/AL.NET (wouldn't that be great?).

The strong side of C/AL and C/SIDE is that you can write business logic in such a simple way. Why ignoring this huge advantage ... .

May be someone has got another opinion?

Joseph_Abou_Nader

Thank you

Regards

Joseph_Abou_Nader

Waldo wrote:

Joseph Abou Nader wrote:

Hello

Regards

First of all ... just ignore BlackTiger...

Second of all ...
As far as I know, MS hasn't confirmed that they will turn this into only one product. They are still doing much development in all environments, making it look (almost) the same. But keep in mind that even in 5.1 you'll be working in C/SIDE and writing C/AL code. Also keep in mind that all products have got its own market, and is it really an advantage to create only one product for all markets?

What do you think about this: What if ... NAV is brought onto the .NET framework, you'll have something like a C/AL.NET (wouldn't that be great?).

May be someone has got another opinion?

First, thank you for your reply... I appreciate it...

As for BlackTiger's nice comment...well...thank you for your sweet insult \:D/ . Any how...no problem...

But believe a year from now...I have been really into the dynamics product strategy and until now...Microsoft hasn't decided yet. The one sure thing is that they will have 4 products in one...and since they really realized the importance of every product as a stand alone system...they might keep each software with its own native language. I have programmed in C/AL and yeah I can imagine how lovely it would be to change to C/AL.net...It was like when I switched from using C++ into C#, where you have the great drop down lists.

Anyhow...till now nothing is certain...

Thank you again

Regards[/quote]

Miklos_Hollender

See, in the very-very long run it does make much sense to have different products, one scalable product is much more logical. But as J.M. Keynes said, in the really long run we are all dead so why care? What I'm implying here that as the architectures growing closer to each other (business logic in compiled .NET assemblies etc.), as the user interface concepts, approaches are growing closer etc. we might have one architecture, one product and one language in 10-12 years. But why care? Maybe in 10-12 years even our coffee machines will run Linux and only some historians will know about MS - or maybe just the opposite, maybe in 10-12 years we just open the fridge and think "Oh, all the pizza is gone!" a thought sensor will pick it up and send the order to the NAV running at the local supermarket Simply there is no point in planning for the far future in IT.

Waldo

=D>

davmac1

The output of Navision's 3 tier will be in C#, but we are not meant to touch it.
However, if we are going to learn a .net language, C# does seem to be the way to go.
BTW - I am a Navision certified master - but that does not make me the equivalent of the folks that have been doing Navision 10 plus years. It just helps us come up to speed faster.

Waldo

davmac1 wrote:

However, if we are going to learn a .net language, C# does seem to be the way to go.

To be honest, I don't expect us to go and program in C#. Again, the C/AL language and C/SIDE environment is a hell of a lot better to write business logic with. And it's a whole of a lot better to read.

ara3n

Well C# language is still going through changes such as LINQ. I'm sure they will add feature to make it an ERP language of choice.

kine

to MS vs. Linux: see http://www.novell.com/linux/microsoft/openletter.html

to Language: see http://dynamicsusers.org/blogs/singleto ... /5736.aspx

David_Singleton

Yes it was quite odd. Today for the first time I heard mentioned "The Dynamics Tool", the working name for the new Dynamics language. Great things are a foot right now.

Joseph_Abou_Nader

Miklos Hollender wrote:

Simply there is no point in planning for the far future in IT.

Hello

Well I agree with you about this, but the problem is that I am having some problems with customers asking frequently: " What will happen when all MBS products becomes one?...Are we going to move to .net? What will happen to our customizations? How are we going to upgrade?...

What if ?...

Anyhow...from the days dos was present, we have learned to adapt with everything new...So as you said " Why to worry ? " Let the new things come...till then...we will see...

Take Care

Waldo

So can we say we are evolving to some kind of ERP language, where writing business logic is as easy as it is now in NAV? (that's what I was expecting/hoping for)

Joseph_Abou_Nader

Hey guys...

I was checking the below interesting topic...niceeeee

http://www.mibuso.com/forum/viewtopic.p ... sc&start=0

Marije_Brummel

Hi,

I am at TechEd It forum helping the MS guys at the booth.

There are some differences between Boston and here. We only have one booth for all Dynamics with 2 PC's. This gave te opportunity to compare NAV and AX. We have a great AX guy helping us with this.

What you can see that it is not the C/AL code itself but the simplicity and the readability that is the key factor for succes.

If they find a way to do something in a flashy .net environment that is as easy to use as C/AL than they have my blessing and trust that it will be something good.

As for the next releases C/AL will not change!! As Miklos said, it is a waste of time to try and speculate where IT will be after that.

Waldo

Mark Brummel wrote:

If they find a way to do something in a flashy .net environment that is as easy to use as C/AL than they have my blessing and trust that it will be something good.

Amen

Mark Brummel wrote:

As for the next releases C/AL will not change!!

Mark, has this been confirmed by MS?

Marije_Brummel

For releases 5.0 and 5.1 it is official, after that not.

Waldo

Reading about the "Dynamics Tool" opens some perspective ...

Miklos_Hollender

Davmac1,

However, if we are going to learn a .net language, C# does seem to be the way to go.

Well I think it depends on what you want to use it for. If you want to do something technologically complex - go for C#. However, if you want to do only some business logic - connecting NAV to CRM, writing a POS screen for NAV so you don't have to waste NAV licences on it etc. - I say go with VB.NET because it's readability helps wasting less time on translating business rules to an abstract syntax and therefore concentrating more on the rules themselves. Also, VB.NET code is "almost" business rules in English, therefore it's easier to spot if something is not right from a business sense - because when you read the code, illogical things just stick out. For example:

VB.NET:
If Customer.Name Is Nothing OrElse Customer.Name = '' Then
   MessageBox.Show("Please enter the name!")
End If

C#:
if Customer.Name==null || Customer.Name=='' 
{
   MessageBox.Show("Please enter the name!");
} 

For example, in this case it's easier to spot something is missing (in this case, throwing an exception) from the VB.NET code because when you read it, you can concentrate on the meaning, not on the syntax.

Of course, when you need to do something "real" programming, i.e. juggling interfaces, abstract classes, delegates, properties, whatever, then go with C#, that feels more natural in that language.

Miklos_Hollender

... and I know it's completely offtopic but let me use this as an excuse to promote LISP# once again. As you probably know, all programming languages parse the syntax into a tree upon compilation or interpretation. LISP goes one step further: it itself does not really have a syntax, but it's a tree structure by itself. Therefore the source code is itself data, it can be manipulated similarly as XML can - opening up a whole new range of possibilities. Let's the usual FOR-loop as an example:

(for (= i 0) (< i 10) (++ i)
	(pr i))

What we see here is not the "syntax" for the FOR loop as in usual languages, but five functions embedded to each other. In LISP, everything is a function, or in other words, an expression with Polish notation, therefore, ( + 1 2 3 ) returns 6 - it calls the "add" function, with "+" as a short form taking three parameters. Therefore what we see here is not a syntax for the FOR loop, but rather a function called FOR that takes four parameters - all four parameters are of the type "function", because functions are considered first-class datatypes here. The FOR function evaluates the functions supplied to it as a third and fourth argument, until the function in the second argument evaluates to zero. Thus, if LISP# wouldn't have a FOR function, you could easily write it yourself. Thus, you are not stuck with the choices the language designers prepared for you but basically create your own syntax as you see fit.

Sorry for the offtopic, it's just a hobby of mine to preach LISP :-)

Joseph_Abou_Nader

hehe...

Way to go guys...this is becoming a programming topic indeed...

take care

Waldo

Miklos,

To stay a bit off topic ...

I don't know LISP#, but it seems interesting to get it to know better ... . May be in my free time ... after 6 years when my kids actually sleep at night ...

But still ... if C/SIDE wouldn't have a FOR "function" in syntax ... couldn't we put it in some kind of codeunit and write it ourselves? The only difference I see is that you have to "instantiate" your codeunit, while in LISP# you don't ... am I right?

David_Singleton

Just a follow-up. I found out that "The Dynamics Tool" is just the new internal working name for what we all know as the old "MBS Framework"

From what I gather, not a lot of people have seen it. I saw it at Tech ED 2003, in a pre-pre alpha type stage, and even then I was impressed. To compare it to C## is silly, even conceptually to think .NET and Visual Studio does not makes sense. Think more of using a Visio type program that can be used to modify work flows as if they were normal flow charts, and then just hit the compile button.

Back in 2003 I got one of the developers to do a mod for me that was simply add a new field to the customer card, and then flow it though to a Sales order, and then through to the invoice, and then print it on the invoice. He basically did this without touching the keyboard, all done with the mouse.

But again, don't expect any major changes to NAV and C/SIDE in ver 6 or 7. Lets concentrate on learning the NAV business logic, getting our customers on stable platforms, and work with them to deliver systems that will be easy to upgrade.