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

[Lex Trotman]

On 11 June 2010 09:37, Jiří Techet <techet at gmail.com> wrote:
> 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.

I think static languages are pretty heavily used on servers too, see
the whole business computer market :-)

>
> And I'm pretty happy with python

Agree

 (ruby users have to forgive me) which
> might hopefully replace the ugly php one day

Agree, but not too hopeful

(perl will fortunately
> kill itself with infinite perl 6 development

Agree

) 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.
>

Ain't open source choice wonderful

>>
>>> 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 :-)

I hope its not bottom up :-), perhaps the comments need to be object
oriented :-)

>
>>
>>>> >> 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 don't suppose you use spirit?

>
>>
>>>
>>> (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/

Looks like a fun area to work, I used to be in Defence/Aerospace.

>
> 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.

The proofs bit is why there was a push into the functional area by the
business community up to the GFC.

>
> 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.

Totally Agree

 For web (and
> possibly simple GUI applications), a dynamic language.

Agree

For anything
> that requires good performance, C, C++.

Mostly agree, a few problem domains seem to work better in functional
languages, even good old Lisp can beat C is a few cases where lazy
evaluation saves a lot of unneeded work.  C and C++ also have to allow
for aliases which can add significant cost in some codes, or rather it
prevents some optimisations. And on big number crunching these days
they are nearly as fast as Fortran.

If your company forces you to,
> Java. If you are doomed to working under Windows, C#. For highly
> secure systems, functional languages.

But only if you trust the functional implementation :)

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.

Agree, unless the language provides a C foreign function interface.

 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.

Agree, and as a contractor I resemble that remark.

Cheers
Lex

>
> Jiri
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>