State of programming languages

[Snyder]

I can't really figure out a language featureset that would be a problem...
In C++ you can use plain arrays or STL, also you can have parameters which are references, constant references, pointers, constant pointers, pointers to constant objects, constant pointers to constant objects, would you mean that there are too many way to give a parameter in C++ and it should only have, say, references, just like in JAVA ?

Well, you just answered your own question in a way. Why do you think has Java become so popular, esp. in business applications?

 

[DemoCoder]

Dude, It's already been tried. See SCID (Source Code in Database) and Intentional Programming/Language Oriented Programming. Neither achieved any big successes in design.

 

[K.I.L.E.R]

Maybe the only way forward is to have computers read our minds?
Is this going to be possible in my lifetime?

 

[Rodéric]

Maybe the only way forward is to have computers read our minds?
Is this going to be possible in my lifetime?

Last time I checked a couple of years ago, it was taking a minute for the computer to find the word you were thinking about... not quite there yet, but even so, it wouldn't be able to understand complex structures you have in mind and make them into code, so most likely not in your lifetime if ever...

 

[K.I.L.E.R]

Maybe talk to the computer what yo write?

Last time I checked a couple of years ago, it was taking a minute for the computer to find the word you were thinking about... not quite there yet, but even so, it wouldn't be able to understand complex structures you have in mind and make them into code, so most likely not in your lifetime if ever...

 

[ERP]

If we look at the evolution widely accepted programming languages, we really haven't come that far from Fortran.

Almost all of the divergence has been from necessity (or some demonstrable productivity win), rather than for some aesthetic. I don't really see that changing going forwards, we're just not likely to see languages with radically different approaches with any real wide spread acceptance.

I personally really like the ML familly of languages, they make expressing a certain class of problem considerably easier that traditional "Fortran like" languages. But outside of academics writing compilers it's unlikely to see widespread use.

The one thing that might change this is massively parallel systems moving into the mainstream, but even there I suspect it won't be a massive divergence from where we are today.

 

[DemoCoder]

One could probably retrofit high order functions, closures, and lazy evaluation back into a C-like language. Hell, C++ is already halfway there on pure-functional types, it just needs a "super-const" which says not only can't the method mutate the object, but it can't call any other non-super-const methods.

It would be sorta the opposite of the approach Haskell and other languages took. They retrofitted imperative style into functional via monads. Imperative languages just need the equivalent of Haskell monads in reverse.

Definately, FP languages are way more expressive than imperative. Just consider coding up the Sieve of Eratosthenes in Haskell

primes = sieve [2..] where
         sieve (p:x) = p : sieve [ n | n <- x, n `mod` p > 0 ]

or with lisp-ish syntax

sieve(list) = (lazycons (lazycar list) (sieve (lazyfilter '(divisibleby (car list)) (lazycdr list))))

 

[Frank]

My major irritation with most languages: you have to fix up and install lots of stuff onto the target computer, and install your application. Something which is often very inconvenient, impossible (unless it's Microsoft rubbish), requires very big installations, and has a large impact which the network administrator won't like. I really hate it when it requires multiple updates, the right OS and service packs, runtimes and a complicated installation procedure that requires human intervention.

If I write a program as I want it to, it requires at most copying two files. Simple and convenient.

My second worst irritation is when programs simply generate a "something went wrong, call your helpdesk" error (.NET!!!), and don't give the programmer a simple way to track it.

And the third would be hard to find errors due to the stupid constucts allowed by the language. (Especially C.)

So, I'll stick with Delphi as long as I can.


Edit: and the next irritation would be simply blocking your ability to do things as you want them to (.NET!!!).

Btw, I LOVE having all sourcecode of everything available. That beats binary resources something laughable.

 

[DudeMiester]

Dude, It's already been tried. See SCID (Source Code in Database) and Intentional Programming/Language Oriented Programming. Neither achieved any big successes in design.

I've read about the latter, but no the former. In any case, just because it didn't work the first time doesn't mean it won't work. A lot of things fail the first go around.

As was stated earlier, most languages changed by necessity. In other words, don't go after the programmer's tastes, go after his boss and have him make the programmer change. There is plenty of opportunity for this with a SCID approach, just look at what's happening with Microsoft's DOC format. If the programmer's employer believes that letting their coders work in a non-convertable way will make them undesirably dependant on that prorgammer, which in many cases it does, they will make sure he or she programs with a more flexible system (i.e. this one). This whole marketing angle feeds off the business's desire to survive, which is a very powerful force. The nice thing is that the programmer doesn't even have to know. They can continue to use C++ or whatever, only using a special compiler that converts it into the database format and maybe making a few tweaks to the output. In the end, you will have code that is more understandable, changable and long lasting, in addition to a more expressive programming interface.

In fact, I'd say such a change is already occuring wheather or not you realise it. All the auto-complete and refactoring utilities out there essentially treat the code as a database. It's only a matter of time before you simply save the code in the pre-parsed format to save time. I can imagine that re-parsing the code every time you work on a 100,000+ line program would be quite slow. It should also improve compile times. Although, we'll probably need a good standard to implement this on a widespread scale first.

The biggest problem with SCID is probably getting too excited about it and making a system that overloads the programmer with crazy code-morphing and display features, but this is more a UI issue.