On Fri, Jun 11, 2010 at 00:17, Lex Trotman elextr@gmail.com wrote:
On 11 June 2010 02:15, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 17:48:39 +0200 Jiří Techet techet@gmail.com wrote:
I agree it helps, but are there really no successful widespread languages that didn't have corporate backing?
If success = widespread use then python and php?
It was caused by the move towards dynamic scripting languages during the internet boom. Big companies overslept and developers just took what was available. But for static languages such a boom was in the 90's on desktops where static languages are used most and the "language culture" is quite firmly established.
And I'm pretty happy with python (ruby users have to forgive me) which might hopefully replace the ugly php one day (perl will fortunately kill itself with infinite perl 6 development) so the future in the dynamic language area looks bright.
Unfortunately we're not living in the 70's or 80's, where the best had a chance, and there's a lot of software written in the mainstream
I think that's a bit pessimistic.
I too think that it is possible for the best to succeed without corporate backing, but also for "not the best" to succeed with corporate backing. I'd list C (AT&T), Java (Sun), C# (MS), Javascript (Netscape) in that category, and funny, but they all look much the same, maybe the corporate suit has been replaced by the corporate braces { }.
languages. These applications won't get rewritten just because some better language appeared (or do you plan to rewrite geany in D? :-). In the last 15 years the only successful languages were those where some big company was behind (Java, C#).
Never re-write whole applications, see KDE 4 for most of the reasons.
Well, GNOME might do something similar with GMONE Shell, which looks very scary to me in its current form. If it's too bad, I'll switch to xfce.
It's not normally a good idea to rewrite applications. But new applications could be written in a language like D or Go (obviously).
Any successful language will need to interface well with C.
True, its the common interface language between all the others.
Which brings up mixed language systems, I've seen a very successful (closed source) system that uses Python as the front end for GUI and scripting where dynamic characteristics are very helpful, and C++ as the backend for the crunching where static characteristics make for good code.
And that's the best way of doing things because every language is good for something else (see my last paragraph - yes, I'm not replying in top-down manner :-)
And it's fast. I spend one hour a day just compiling with C++ code.
A D developer says it's faster than Go at compiling, and it has templates: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&gr...
Well, it really depends if he was compiling a single file or a library
The link says: "So the go compiler compiles 120KLOC in 9.23 seconds. I got curious so I just tested dmd against Phobos (88KLOC). That takes 1.24 seconds on my laptop."
Phobos is D's standard library, and includes templates quite a bit.
with many includes. What makes the compilation of C++ slow is that it has to parse the same headers again and again every time they are included (and all the includes inside the includes). This is eliminated in go. If D uses includes, then it will be slow for big projects too.
It doesn't use includes per say, but compiler-generated .di files. C++ parsing is slow anyway because of templates.
Yeah, just try using some of the Boost libraries heavily :-(
Why do you think I spend 1 hour a day compiling ;-)
(I think both D and Go have ways to speed up compilation further).
The reason I originally said that I wouldn't get into a language discussion is because as entertaining and intellectually stimulating as such discussions are (I subscribe to LtU http://lambda-the-ultimate.org/ ) in reality most of the factors which control the selection of languages are non-technical, tool availability, programmer experience and training costs for switching, and good old fear (will I be blamed for a project failing if I try something new).
To give the discussion a Geany flavour (just for the look of it you know, so Enrico doesn't complain we are too OT ;-) this is why Geany should not impose specific workflows or prevent them, we don't know what the "next big thing" will be.
And to answer Jiri's question on a previous post, use of functional languages in anger, if you are in Europe the majority of your phone calls are handled by a functional language, Erlang, which Ericsson use to program their exchanges. Large projects, real time, high reliability, fault tolerance, concurrency ... not a bad list.
The thing I develop is this:
http://www.egos.esa.int/portal/egos-web/products/MCS/SCOS2000/
and it's good old C++ (and C++ified C) :-). And sure functional languages have many advantages - apart from other things it's much easier to prove the correctness of the program written in a functional language and many parallelism-related problems just vanish.
I don't like the discussions where people defend their "best" programming language. There is no best programming language, it depends on what you want to use the language for. For web (and possibly simple GUI applications), a dynamic language. For anything that requires good performance, C, C++. If your company forces you to, Java. If you are doomed to working under Windows, C#. For highly secure systems, functional languages. And I'm naming the widespread languages because you'll probably need some extra libraries that won't be available for the more esoteric languages. I just think that for OO languages the number of use cases is much higher than for functional languages. And most often you are not the one who makes the decision - you come to the existing messy code and just contribute to making it even messier.
Jiri