[Geany-devel] OT replace c++ - Re: project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

Jiří Techet techet at xxxxx
Thu Jun 10 23:37:25 UTC 2010

On Fri, Jun 11, 2010 at 00:17, Lex Trotman <elextr at gmail.com> wrote:
> On 11 June 2010 02:15, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
>> On Thu, 10 Jun 2010 17:48:39 +0200
>> Jiří Techet <techet at 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

>> 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&group=digitalmars.D&artnum=108831
>>> 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:


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.


More information about the Devel mailing list