GTK+

C/C++ и "быстрая разработка" - понятия несовместимые. Так что если есть желание ускорить процесс, то стоит выбрать для ГУЙни другой язык. К примеру, Питон. Или Схему.

А по моему Python и GUI - есть суть вещи несовместимые. По крайней мере у меня ещё ни одна прога на Питоне не заработала.

Руки кривые, стало быть. ГУЙня на Питоне значительно компактнее пишется, и, главное, никаких проблем с динамическими интерфейсами.

да - подтверждаю что python отличная вещь для гуйни.

А если всетаки С???

по мне самый быстрый метод разработки GTK приложений на C - это Emacs. а для катала лейаута окошек - glade - ништяк.

Если хочешь в гамаке, стоя в ластах - то это твои проблемы, тебе придумывать, как при этом всё сделать ещё и БЫСТРО. Если придумаешь - первым будешь. Никто пока не знает, как приспособить столь кривой язык к RAD, и уж тем более к RAD в ГУЙне.

Назови прямой. OCaml не предлагать: ты сам то видел какой натив он компилит? Кроме концевой рекурсии ничего и не умеет (а это может и С). И вообще какого хера крутой функциональщик постит на "императивном" русском языке? На нем же числа Фибоначчи неудобно вычислять? P.S. Слей "элегантный" heapsort на OCaml если не трудно.

А я вообще предпочитаю все ручками писать. Не намного медленнее получается. Зато код лучше да и самому приятнее

OCaml я и не предлагаю - для гуйни интерпретатор нужен. Так что Питон, раз уж GTK+, а по хорошему и вовсе Tcl/Tk лучше всех.

Ну а нейтив у OCaml-а вполне приличный. Для тех задач, под которые язык заточен - вполне хватает, там вообще узкое место обычно в GC, а как раз GC весьма хорош.

Сортировку сейчас нарисую...

я вот могу элегантный метод сортировки реализовать на prolog:
order([],[]):-!.
order([X],[X]):-!.
order(L1 ,[X|L2]) :-
  fetchit(L1,[X|L3]),order(L3,L2).
    
fetchit([X],[X]):-!.
fetchit([H11,H12|L1],[H21,H22|L2]) :-
  fetchit([H12|L1],[T1|L2]),
  minmax(T1,H11,H21,H22).
  
minmax (X,Y,X,Y):-  X<Y,!.
minmax (X,Y,Y,X).

% :-order([9,8,7,6,5,4,3,2,1],L)  =>  L=[1,2,3,4,5,6,7,8,9]

:))))