Language of the future.

Hobbes

The Corinthian wrote: »

It's not a language. OT at best TBH.

Two systems talking to each other and understanding what they are saying would be classed as a language.

The question is the language of the future. One where you don't have to worry about what the other system is built on is the one most likely to win.

The Corinthian

Hobbes wrote: »

Two systems talking to each other and understanding what they are saying would be classed as a language.

Silly me, and there was I thinking that the OP and everyone else were talking about programming languages.

Is an API now a language btw?

cousin_borat

There can be any number of languages, once they are based on open standards and interoperable that is fine. Web services are the current de facto way to communicate, as are API's but that is not relevant as such. As to programming languages of the future DSL's/Meta programming are the way forward.

The Corinthian

cousin_borat wrote: »

There can be any number of languages, once they are based on open standards and interoperable that is fine.

What do you mean by 'open standards'?

Web services are the current de facto way to communicate, as are API's but that is not relevant as such.

Web services are basically API's.

Mutant_Fruit

cousin_borat wrote: »

Web services are the current de facto way to communicate, as are API's but that is not relevant as such. As to programming languages of the future DSL's/Meta programming are the way forward.

You can communicate via webservices, but what that really means is you are both using XML over HTTP on each end. Neither of those are programming languages, therefore 'webservices' cannot be classified as a 'langauage'.

An 'API' is not a 'de facto way to communicate' either. A programs 'API' is just the name given to all the public methods/functions exposed by a program that other programs can call.

DSL's are quite unlikely to ever become mainstream simply because of their nature. A DSL is a Domain Specific Language, i.e. a language suitable for a very specific task. Therefore it won't be mainstream as it won't be useful for a wide range of tasks like C, C++, C# and Java are. Neither can 'meta programming' be considered a language either.

The question is the language of the future. One where you don't have to worry about what the other system is built on is the one most likely to win.

That's a pretty loaded statement. That would only happen if everything compiled directly to the same native code layout and exposed all methods/functions in the same way (for example c++ can expose stuff in a C- like way by using extern C). Managed languages such as Java or C# simply can't do this because they don't compile to native and they require a VM to run. This hasn't stopped both of those languages from doing extremely well.

I think you'll always have to worry about what language the other system is built on. That's not going to go away. There will always be a 'next great thing' which people will want to use which won't be 100% compatible with the previous generation of stuff.

For example, C# can directly invoke methods from C programs, but C can't directly invoke C#.

cousin_borat

The Corinthian wrote: »

What do you mean by 'open standards'?

I use the term open standards from its common use atm in the context of service oriented architecture. Some examples of open standards being TCP, IP, XML OASIS format for B2B document exchange and ODF, Java, the list goes on

Web services are basically API's.

Thanks for pointing that out.

cousin_borat

Mutant_Fruit wrote: »

You can communicate via webservices, but what that really means is you are both using XML over HTTP on each end. Neither of those are programming languages, therefore 'webservices' cannot be classified as a 'langauage'.

Hi Mutant fruit, I don't believe I said anything different. Also Web Services are not always limited to just SOAP.

Mutant_Fruit wrote: »

An 'API' is not a 'de facto way to communicate' either. A programs 'API' is just the name given to all the public methods/functions exposed by a program that other programs can call.

I used the incorrect nomenclature (communicate). An API is the de facto way to expose the functionality by a program..

DSL's are quite unlikely to ever become mainstream simply because of their nature. A DSL is a Domain Specific Language, i.e. a language suitable for a very specific task. Therefore it won't be mainstream as it won't be useful for a wide range of tasks like C, C++, C# and Java are. Neither can 'meta programming' be considered a language either.

I guess what I'm trying to say is that very often the problem with software is that programmers think through the prism of the particular language. Be it Java, C#, etc to solve the problem.

Programming languages of the future such as DSL's are the future. Why? Because Subject matter experts and Domain experts are the people who really understand a particular system. Therefore giving them the ability to program in DSL's makes alot more sense than programmers who at best will have an OK grasp of the domain in question.

Talking about particular languages misses the point as far as I can tell. There will be any number of DSL's and these will be used by the subject matter experts in those particular verticals.

For example, C# can directly invoke methods from C programs, but C can't directly invoke C#.

Well that is the point of creating WSDL's where all the calling program is concerned about is the contract with the other system. It should not care what the implementation is that implements whatever the WSDL says the function/method does.

Again I'd recommend reading the Simonyi article. Also Martin Fowler is doing some interesting work in the "intentional" programming languages referred to in the article.

Hobbes

The Corinthian wrote: »

Silly me, and there was I thinking that the OP and everyone else were talking about programming languages.

The point is that with Web Services it won't matter what the language of the future will be in as all the systems will be able to talk to each other fine. Someone can write a system in .NET and someone else can use that system in PHP or even intermix between .NET, PHP, Java, C++, Python, LotusScript or any other host of languages.

I'm surprised you didn't mention seeing as your the one watching the market behavior and it is going in the direction of SOA.

Web services are basically API's.

Go look up what WSDL stands for then.

The Corinthian

Hobbes wrote: »

The point is that with Web Services it won't matter what the language of the future will be in as all the systems will be able to talk to each other fine. Someone can write a system in .NET and someone else can use that system in PHP or even intermix between .NET, PHP, Java, C++, Python, LotusScript or any other host of languages.

I'm surprised you didn't mention seeing as your the one watching the market behavior and it is going in the direction of SOA.

Crap. To begin with you simply proffered Web services without any qualification when you originally brought it up.

Secondly, simply because Web services may become the overriding architecture in many Web applications, does not mean that the languages that are using it will be equally capable or popular.

Go look up what WSDL stands for then.

I bet you think XML is a programming language too.

sobriquet

cousin_borat wrote: »

Programming languages of the future such as DSL's are the future. Why? Because Subject matter experts and Domain experts are the people who really understand a particular system. Therefore giving them the ability to program in DSL's makes alot more sense than programmers who at best will have an OK grasp of the domain in question.

I'd have to agree with Mutant_Fruit here, I can't see DSLs taking off to that extent at all. Programmers have had to develop solutions for problems in domains completely outside their area of expertise since year dot. (When was that, back in the 80s'? :P) There's nothing new here, and the idea that you could have a system that allows non-programmer experts to develop fully functional solutions to problems through some domain restricted language is just as old.

Some languages will be more suited to specific tasks, Fortan for numerical work for example. At the same time, it's an incredibly rare program that gets smaller over time; specs grow and users demand features outside the original boundaries. Having a DSL in that case will likely bite you in the arse then. VMs might solve this problem to a degree, imagine something like a Sudoku solver, with the front end written in C# and the solver itself written in Prolog targetted to the CLR. The VM here would make the interoperability easier.

Mutant_Fruit

cousin_borat wrote: »

Well that is the point of creating WSDL's where all the calling program is concerned about is the contract with the other system. It should not care what the implementation is that implements whatever the WSDL says the function/method does.

Amazingly enough, that's what C does. It exposes it's methods based on a particular specification (consider it a WSDL of sorts, using your terminology). No other system cares about the implementation of the actual C library in question. The implementation can change, all other programs interacting with it don't care. They'll all work fine. All that matters is that the 'contract' (the public API which is described by the library) does not change.

WSDL just takes this idea from C and fits it on top of the web service model. That's all.

Anyway, i think this has pretty much reached the end of any useful discussion. WSDL is a Web Service Description Language. Not a programming language.

cousin_borat

Hobbes wrote: »

The point is that with Web Services it won't matter what the language of the future will be in as all the systems will be able to talk to each other fine.

Just because it's easier to build composite B2B and A2A applications does not mean the underlying programming languages is less relevant. This does not negate the need for improved and more expressive programming languages.

The truth plain and simple is that most programs are badly written or at best sub-optimal. This thread is losing sight of the fact that the question posted by the original poster is where are programming languages going. How can they be improved to in turn improve the standard of coding? Should they evolve so that the role of programmer who takes a set of requirements and then implements them is gone?

Fow the record I think the programming language of the future should be Prolog

The Corinthian

It’s actually quite interesting to see what happens to programming languages over time. Whether a language is the most beautiful construct in the World or not is irrelevant to whether it will ultimately get used. Really it comes down to the market and even luck.

Off the top of my head here’s my 2 cent on a few examples I’ve seen evolve over the years:

ASP. Before anyone points it out, I know it’s not actually a language, but it does make an interesting case study. The original version was a bit of a damp squib due to general flakiness and that MS didn’t put all that many resources into it. By ASP 2.0, it has improved and (importantly) it was one of the first Web development languages to be easy to get into (thanks to MS’s ability to build good IDE’s at the time and that there was already a large pool of VB developers out there). By 1999 it had become so popular that SUN rejigged their offering to bring out JSP’s as an easier development alternative to servlets. Subsequently being phased out by ASP.NET, but (like VB and COBOL) likely to be knocking around for decades to come.

PHP. As much as I love this language, I do think it’s on the decline as the ease of entry for a developer to pick it up and it’s low cost have also in many respects become its long term downfall. To begin with it has a terrible reputation for bad coding (due to the endless number of cut ‘n paste developers throwing up sites) and due to its low cost it’s considered a SME technology and no number of metrics will convince a big corporation (with some exceptions) to use it. As a result you have a huge number of cheap developers in a limited market – leading them all to skill up on more profitable technologies and so we will likely see a slow decline in its use.

One thing to add that was key to PHP’s success was MySQL. I doubt it would have been anywhere as popular without it.

dotNet. Again a framework. Very well marketed by MS and finally (a few service packs later) pretty stable it has managed to put up a fair bit of the enterprise market while Sun wasn’t looking. As with PHP and MySQL, improvements in SQL Server greatly helped its popularity. An interesting thing to note is that C# developers get paid a fair bit more than VB.Net ones – even though it all compiles to the same bytecode.

Ruby. This was around for years – long before Rails. Of course when Rails appeared everyone ran around spouting hype about it until they realized that no one was actually using it (hosting being a particular issue). You hear a lot less hype about it nowadays. ‘Nuff said.

J2ME. Java had a major advantage when entering the mobile market in that it ran off a VM while everyone else was very much dependant on the OS. This meant that it was able to get onto a far greater range of devices that Symbian or ME based applications could not touch, making it commercially far more viable.

In short, when talking about the ‘language of the future’ it’s important to bare in mind that what really makes it a success or failure is the market and all those, often accidental, factors that influence it. The rest is bearded, sandal-wearing wankology.

Hobbes

The Corinthian wrote: »

Crap. To begin with you simply proffered Web services without any qualification when you originally brought it up.

Actually you were asking if an API was a language. I pointed out WSDL is a language. I never said it was a programming language. You made that claim I did.

However its system is what will basically denote the pointlessness of the language of the future. When all languages can talk to each other easily, then there is no dominant language.

The examples you showed above is a clear case that it wouldn't matter which was written. As they could all talk to each other easily via Web Services. So it won't matter if the shop is in .NET, I can just as easily create an application to slot in and work.

Also your comment on "Market" was a bit of a cop-out earlier. You give out about people having to watch the market and then don't even mention where the market was going.

Ruby. This was around for years – long before Rails. Of course when Rails appeared everyone ran around spouting hype about it until they realized that no one was actually using it (hosting being a particular issue). You hear a lot less hype about it nowadays. ‘Nuff said.

Just because you don't hear the hype doesn't mean it is not being used. It is one of the reasons even though I don't use .NET at all I refuse to slate it. Until I have professional experience in the language, I don't see how my opinion would be viable. I do know that there is work out there for it.

As for RoR, it is still used quite a lot. I know of three large scale applications in work that use it. But because it is a Web UI, no one would notice it. Is it a good language or not? I don't know. I do know commercially RoR has only existed for 2 years. I also know that there is work out there for RoR developers.

The rest is bearded, sandal-wearing wankology.

Right, because people who work in the industry can't form a professional opinion. :rolleyes:

Hobbes

cousin_borat wrote: »

Just because it's easier to build composite B2B and A2A applications does not mean the underlying programming languages is less relevant. This does not negate the need for improved and more expressive programming languages.

Your correct. However having a holy grail of a language is unlikely to happen. Most of the "market" is on maintaining legacy systems. So if one did appear it is unlikely the "market" would move to it. A language that allows you to easily move a legacy system to new hardware/OS/Programming language will be the underlying feature of a programming language of the future.

WSDL just takes this idea from C and fits it on top of the web service model. That's all.

It's a wee bit more complicated then that but that would be an accurate description in its most simple form.

The Corinthian

Hobbes wrote: »

Actually you were asking if an API was a language. I pointed out WSDL is a language. I never said it was a programming language. You made that claim I did.

Then you should know that an API is not a language, programming or otherwise. WSDL is a language for defining an API.

However its system is what will basically denote the pointlessness of the language of the future. When all languages can talk to each other easily, then there is no dominant language.

Rubbish. We've had a system for allowing all languages to talk to each other for years. It's called TCP/IP.

The Internet has encouraged different platforms to communicate for a long time, yet this has not stopped some languages (and frameworks) becoming more popular than others. Web services won't stop this either.

Also your comment on "Market" was a bit of a cop-out earlier. You give out about people having to watch the market and then don't even mention where the market was going.

In my previous post I suggested a number of things I would predict with regard to a number of the languages/frameworks I cited. As for where the "Market" is going as a whole, I'll leave that to gubu's such as yourself.

Just because you don't hear the hype doesn't mean it is not being used.

Of course it's being used, however the drop in hype is indicative of a loss of interest in the technology in general. After all VB and COBOL are still used (a lot more than Ruby), but that hardly makes them a language of the future.

Right, because people who work in the industry can't form a professional opinion. :rolleyes:

If there is something that the IT industry is not short of is opinions. Now whether these are grounded in reality is another matter. After all, I'm still waiting for Linux to replace Windows as the most popular desktop OS.

Mutant_Fruit

Either way, you have to realise that your webservices are not talking to each other via WSDL.

They're talking to each other over:
A) TCP/IP
HTTP
C) Soap/XML
[ D) WSDL ]
In that order.

WSDL doesn't really feature in that list. I just added it at the end because it's WSDL that specifies the XML/Soap content/format.

Red Alert

My general language lineup:

MATLAB - I don't know if we're technically going to call it a language but it's a very powerful language, but with a few quirks. Pretty much 90% of my work would be done using it. It can lead to bad habits, and often I think encourages a copy and paste attitude rather than forcing you to encapsulate functional blocks. Inbuilt extras like plotting seal the deal.

Python - for some reason I avoided it until very recently. At the moment I'm using it for some 'glue' stuff but I'm really impressed with it. Pretty much replacing perl for scripting I used to use perl for. If used as a 'technical computing' environment like MATLAB can encourage poor practice. First stop now for any self-contained programs I write.

C - Best language for teaching programming I think. It's very easy to move off it onto something like C++ (OOO), Java (OOO and more) whilst still putting in the learning necessary to play with hardware and try out things like assembly. Also you can play with things like threads, and you've to think about your memory usage.

Fortran - Beautiful language for maths, I thought it was dead and got a bundle of code from a guy all in Fortran. I find the auto vectorize and auto parallelize great, and best of all they're expressed simply.

On top of that I've written some database heavy stuff in PHP, and have a good few 'glue' scripts in Perl. From the above I'd definitely say that it all depends on what you're using them for - there's no one language that applies especially when you move outside software as a product e.g. into numerical computing etc.

Cantab.

Red Alert wrote: »

Fortran - Beautiful language for maths, I thought it was dead and got a bundle of code from a guy all in Fortran. I find the auto vectorize and auto parallelize great, and best of all they're expressed simply.

Fortran is great -- still lots of research to be done in auto-parallelization. It's all very fine for dual-cores and quad-cores, but getting compilers to get programs running on 16-, 256-, 1000-core chips is an area of huge research.

Fortran is a very clean language and a great basis for multi-processor development. The popularity of Intel's Fortran compiler is growing steadily and there are some really cool visual multi-core tools coming out too.

Agree about MATLAB -- excellent tool for rapidly simulating ideas. But when it comes to hard-core number-crunching and representing complex phenomenon, it breaks down terribly and a more "first-principles" language (often C++) needs to be used.

Of course the market will be the primary driver of the "language of the future". My money's on Intel multi-core processors and Fortran.

Hobbes

The Corinthian wrote: »

Then you should know that an API is not a language, programming or otherwise. WSDL is a language for defining an API.

Like I said WSDL is a language, but not a programming language. Thanks for pointing out exactly what I said.

Rubbish. We've had a system for allowing all languages to talk to each other for years. It's called TCP/IP.

TCPIP is a transport protocol. It tells you nothing about how you should talk to the other systems applications or even how to find the related API you want to access.

Mutant Fruit explains it a lot better. Although (b) can also be SMTP and (c) can be CORBA, RMI, etc.

Web services won't stop this either.

I don't think you fully understand what SOA is.

The Corinthian

Hobbes wrote: »

Like I said WSDL is a language, but not a programming language. Thanks for pointing out exactly what I said.

Stop trying to squirm out of this one. In a thread on programming languages of the future you began to talk about Web Services, which is essentially just an API, and then decided to backtrack by raising WSDL which is simply the definition language for that API.

TCPIP is a transport protocol. It tells you nothing about how you should talk to the other systems applications or even how to find the related API you want to access.

TCP/IP has been used for years to allow Web applications to talk to each other and has not stopped some languages becoming much more popular than others which pretty much knocks your initial premise that such communication would lead to languages being less important.

I don't think you fully understand what SOA is.

I think it's obvious from this thread that I do and that you are actually the one who appears to have a fuzzy grasp on development principles.

Hobbes

The Corinthian wrote: »

In a thread on programming languages of the future you began to talk about Web Services,

Correct! Programming languages that allow the ability to interact using web services will be classed as the programming languages of the future IMHO.

Just because your going into what web services are or aren't doesn't detract from that.

TCP/IP has been used for years to allow Web applications to talk to each

*Sigh*

Mutant Fruit has already explained why your mistaken in your explanation.

To put it in layman terms, it would be like me saying "Phones have been used for years to allow people to talk to each other". If it is an Italian customer speaking to a Chinese company. In this case the phone (TCP/IP) is useless to what your trying to accomplish. The Chinese receptionist can't speak Italian and doesn't know what you want or what department.

That is what Web Services addresses. It keeps the OS/Programming language abstract so you can slot in/out applications/hardware and still have them understand each other without any underlying code changes to existing systems.

I think it's obvious from this thread that I do.

I think your comments regarding TCP/IP means you need to read up a bit more on what it is.

Mutant_Fruit

Hobbes wrote: »

Correct! Programming languages that allow the ability to interact using web services will be classed as the programming languages of the future IMHO.

In that case every programming language that supports sockets is classed as 'the programming language of the future'. All you need is a socket to use webservices.

Hobbes

Mutant_Fruit wrote: »

In that case every programming language that supports sockets is classed as 'the programming language of the future'. All you need is a socket to use webservices.

Your language has to be able to support web services. By your definition you would be correct in the broadest sense that the person would have to code their own WS handler. Most of the recent languages do this automatically for you. For example Lotusscript I only need point it to the WSDL file and my code can talk to the webservice. I don't need to know anything about what xml is going in/out or what server I am pointing to as I just write my stuff in lotusscript objects.

eg.

dim stub as MyWebService
  dim i as UserInfo
  Set i = stub.getUserInfo("Joe Bloggs")

In this case the MyWebService + UserInfo classes are built automatically by just having the lotusscript read a WSDL file.

But where a market that is built on maintaining more then writing new stuff any system that allows you to chop and change with ease will be a language of the future. Managed code was a way to do something along these lines.

The Corinthian

Hobbes wrote: »

I think your comments regarding TCP/IP means you need to read up a bit more on what it is.

It think what is evident from both Mutant_Fruit's and my replies that you have a very poor understanding of the subject yourself.

The Corinthian

Hobbes wrote: »

Your language has to be able to support web services.

Any language that has socket support effectively will support Web services.

What you mean is that a language should be high level enough that you don't have to write your own libraries to support Web services. In this regard most if not all languages designed to work with the Internet already have wrappers for Web services. We had the same evolution with language support of XML a few years ago.

However there is and will continue to be factors that come into play that will cause some languages to have a greater adoption rate or not than how easy it is to use Web services out of the box. That TCP/IP has been used for years to do bespoke "Web services" has not changed the fact that some have risen and some have fallen - Web services will make little or no difference to this.

As for the relevance of WSDL being a language...

Hobbes

The Corinthian wrote: »

Any language that has socket support effectively will support Web services.

There is world of difference between able to talk using web services (which is what you are describing) and your language actively supporting web services.

It goes beyond just wrappers as you describe. I really recommend you actually read up on what you are trying to talk about.

It think what is evident from both Mutant_Fruit's and my replies that you have a very poor understanding of the subject yourself.

Working with web services for almost two years now in Java and Domino and currently studying for my SCDJWS. How about yourself?

So which is why if a language fully supports web services it means the developer gets the language they like, the people paying for the product get a system that they aren't going to be locked into systems they will be paying large amounts of money to maintain when the language/OS/hardware goes out of date or they need to change vendors.

The Corinthian

Hobbes wrote: »

There is world of difference between able to talk using web services (which is what you are describing) and your language actively supporting web services.

It goes beyond just wrappers as you describe. I really recommend you actually read up on what you are trying to talk about.

Please tell us what that 'World of difference' is that would cause us to all jump onto one language rather than another.

Actually, given that active support for popular technologies, XML in the past being an example, tends to be introduced in most if not all relevant languages within a short number of years, please explain the relevance of your argument at all?

Working with web services for almost two years now in Java and Domino and currently studying for my SCDJWS. How about yourself?

I've been working with Web services since about 2002 and pre-Web service protocols since about 1998, so you'll forgive me if I don't take your own experience too seriously after reading what you've posted.

You've repeatedly tried to put forward the argument that Web services were in some way 'the language of the future' despite the fact that they are not actually a language and that in the past similar support for useful functionality has not saved unpopular languages or stopped popular ones from adopting that support in time.

The question is ultimately about the programming language of the future. Discussing Web services is of at best limited relevance to this and I am surprised that someone with your alleged experience would put so much weight on them.

AARRRGH

Concurrency is the way forward. Have a look at Erlang.

Note as this has turned into a my dick is bigger than your dick debate, I've been a programmer since 1995.

ianhobo

I started by learning LOGO and Basic in about 1989
Does that count as being a programmer?