Новости IT

[• Amp]

Amp, и почему приложение с нативным интерфейсом такая больная тема? По мне так лишь бы интерфейс был удобный, а как он выглядит - дело десятое.

Удобный и быстрый. Варианты конечно бывают разные (удачные, неудачные или просто отвратительные), но основные на моей взгляд проблемы: шрифты и цветовая тема. Замыленность или несглаженность шрифтов (когда в системе сглаживание включено) режет и напрягает глаза. Если в системе выставлена темная цветовая тема (или просто нестандартная), то приложение либо вообще не вписывается в окружение, либо (что хуже) цвет текста может слиться с цветом фона - тогда вообще ничего видно не будет. Хотя нативный интерфейс от последнего может не спасти, так как некоторые любят брать цвета не из системной палитры, а тупо прописать в коде. Тут уж дело в руках.

Иногда происходят забавные вещи. Например в линуксе решили сделать глобальное меню для приложений как в маках. По-моему через d-bus решили проблему взаимодействия с десктопным окружением. Написали соответствующие патчи для gtk+ и qt. А Firefox и OpenOffice оказались в пролете.

[• dnk]

firefox и OOo в пролете потому что они сами себе велосипеды и полностью дублируют функционал графических библиотек, ни спользую системные графические библиотеки.

эти страдают также chromium, опера

[• Amp]

К слову об ужасном виде Evernote и WPF.

Хотя версия 3.5 и добавила множество отличных новых возможностей, в ней мы столкнулись с рядом проблем, которые невозможно было легко исправить: размытый шрифт, долгое время загрузки, большое потребление памяти и плохая поддержка видеокарт. Все это было обусловлено спецификой технологий, лежащих в основе 3.5 (Windows .NET и WPF), на которые мы никак не могли повлиять. В конечном итоге мы скатились к борьбе с ошибками платформы вместо работы над новыми возможностями, о которых нас просили пользователи.

В итоге мы решили начать с нуля, используя только C++, в котором мы были уверены.

http://habrahabr.ru/company/evernote/blog/106994/

[• deadlock]

Я бы еще добавил, что толстым троллингом. Потоньше надо троллить 

О, нет, сударь. Факты и только факты. Никакого троллинга.
На лицо явная троллифобия.

[• deadlock]

В основном конечно же мелочи. И 95% даже на заметит. Хотя WPF может и заметит.. во всяком случае тот ужас, который я увидел в Evernote - только слепой не увидит. Да и от внешнего "искаробочного" вида tkabber офигеет.

Тулкит по-любому использует WinAPI - битмапы с нативными контролами как-то получать надо, создавать и (возможно) регистрировать окна тоже надо. Велосипед был сказан к слову, но последние linux-версии оперы в этом плане вызывает какие-то неоднозначные чувства.
Сравнивать возможности WinAPI и Tk неразумно. Последний как бы является тулкитом. Я считаю, что для проектов со сложным графическим интерфейсом удобство определяет не парадигма и не язык, а возможности самой библиотеки (и наличие отлаженных сторонних дополнений к ней). В противном случае придется затратить очень много сил и времени, чтобы написать тривиальные вещи вроде датагрида, докинга или удобного менеджера компоновки. Например именно по этой причине я бы выбрал Qt вместо wxWidgets для "тяжелого" проекта. Разработка на MFC конечно была бы адом, с этим я согласен.

Кстати ActiveState какие ограничения накладывает на community-версию tcl и tk?

> Да и от внешнего "искаробочного" вида tkabber офигеет.
А вы попробуйте осилить поставить Tk 8.5 и подменить симлинк wish'а. Это ведь очень просто, не так ли?

>Тулкит по-любому использует WinAPI - битмапы с нативными контролами как-то получать надо, создавать и (возможно) регистрировать окна тоже надо. Велосипед был сказан к слову, но последние linux-версии оперы в этом плане вызывает какие-то неоднозначные чувства.
Нет никакой печали от того, что нужно toolkit'у и как он рендерит GUI. И слово "велосипед" тут совершенно не уместен. Программиста должно волновать лишь то, что представляет ему технология для GUI. А WinAPI в чистом своём виде - ничто. А также "ничто" и убогенькие обёрточки - WTL и MFC, ибо нет даже layout manager'ов.

> Сравнивать возможности WinAPI и Tk неразумно.
Совершенно верно. Стоит рассматривать WinAPI максимум, как низкий уровень реализации toolkit'а.

> Я считаю, что для проектов со сложным графическим интерфейсом удобство определяет не парадигма и не язык [...]
Ошибочно считаете. Язык и парадигма значит очень многое для любой задачи. Сложность семантики невозможно засунуть в API какой-нибудь там библиотеки. В частности, для разработки и прототипирования GUI неплохо подходят языки с динамической типизацией. Правда таки не всегда - в особо сложных случаях всё-таки лучшим решением будет строгая типизация.

> [...] чтобы написать тривиальные вещи вроде датагрида, докинга или удобного менеджера компоновки [...]
В нормальных технологиях это есть очень давно.

> Кстати ActiveState какие ограничения накладывает на community-версию tcl и tk?
На сколько я знаю - никаких. ActiveState продаёт лишь Komodo IDE для их любомого зоопарка. Ну и ряд тулзов, не особо значимых, - платные.

Сообщение отредактировал deadlock - Nov 6 2010, 01:42

[• deadlock]

То есть Вы серьезно считаете, что разработка UI на QT = разработка UI на С++? Интерфейс можно разработать не написав ни одной строчки кода, если конечно не требуется создавать какие-то специфические нестандартные виджеты.
Я например храню формы в *.ui, из которых *.cpp/*.h генерируются при сборке автоматически, а функционал реализован в унаследованных классах, например Form -> Form_Impl

Да, я серьёзно так считаю. А как же иначе можно считать? Вы пробовли писать на Qt не на C++? Поделитесь впечатлениями!
А вы действительно полагаете, что GUI можно геренировать автоматически используя возможности лишь Qt? (именно GUI, а не статичные тупенькие макетики нарисованные ручками).

Сообщение отредактировал deadlock - Nov 6 2010, 01:29

[• Snowm@n]

Да, я серьёзно так считаю. А как же иначе можно считать? Вы пробовли писать на Qt не на C++? Поделитесь впечатлениями!

Вы вообще что подразумеваете под "писать на QT"? Использовать QT можно и в Python, и в PHP.

А вы действительно полагаете, что GUI можно геренировать автоматически используя возможности лишь Qt? (именно GUI, а не статичные тупенькие макетики нарисованные ручками).

Что в Вашем понимании GUI? Именно, то что его нужно рисовать, а не писать.
Касательно практики применения, возможностей QT вполне хватало.
p.s. Виджеты иногда приходилось писать, но редко.

Сообщение отредактировал Snowm@n - Nov 6 2010, 06:44

--------------------

Developer -> Lead Developer -> Lead Architect -> ... ?

[• Amp]

> Да и от внешнего "искаробочного" вида tkabber офигеет.
А вы попробуйте осилить поставить Tk 8.5 и подменить симлинк wish'а. Это ведь очень просто, не так ли?

Дело не во мне - я все это могу сделать. Дело в том, что большинству пользователей tkabber известен как программа со страшным интерфейсом. Пользователей это отпугивает, а разработчики похоже даже не собираются как-то избавляться от этого ярлыка. Хотя бы скриншоты на сайте поменяли бы на более приличные. Результат - потеряли пользователей. Ну приложение за деньги не продается, поэтому видимо количество пользователей роли не играет.

Кстати я тут краем уха слышал, что у tk какие-то проблемы с двумя мониторами - диалоги вылезают по центру виртуального дисплея.

Нет никакой печали от того, что нужно toolkit'у и как он рендерит GUI. И слово "велосипед" тут совершенно не уместен. Программиста должно волновать лишь то, что представляет ему технология для GUI. А WinAPI в чистом своём виде - ничто. А также "ничто" и убогенькие обёрточки - WTL и MFC, ибо нет даже layout manager'ов.

Соглашусь. Кстати печаль есть. Буквально вчера новость - космонавт сказал, что собирается выпиливать Xorg и заменять его на Wayland. Кое-кому, если это действительно произойдет, придется переписывать код.

Ошибочно считаете. Язык и парадигма значит очень многое для любой задачи. Сложность семантики невозможно засунуть в API какой-нибудь там библиотеки. В частности, для разработки и прототипирования GUI неплохо подходят языки с динамической типизацией. Правда таки не всегда - в особо сложных случаях всё-таки лучшим решением будет строгая типизация.

Описание и прототипирование самого UI является декларативной задачей. Основная часть которой должна возлагаться в теории на дизайнеров. Прототипирование приложения уже другое дело, но мы же речь ведем об UI?

В нормальных технологиях это есть очень давно.

Это каких же?

Берем типичную задачу, которую надо реализовать под Linux. Какая-то мелкая система документооборота. Десктопное приложение, Фронтэнд к БД, отображение данных, как в виде таблиц (кэширование, сортировка, многоуровневые заголовки, агрегирование), так и в виде графиков (паи, бары, лайны..), построение отчетов по всему этому хозяйству (пусть без дизайнера отчетов, с генерацией во что-нибудь распространенное вроде pdf, xml и open document).

Какие технологии возьмем, чтобы написать это в разумные сроки?

Сообщение отредактировал Amp - Nov 6 2010, 14:00

[• deadlock]

Дело не во мне - я все это могу сделать. Дело в том, что большинству пользователей tkabber известен как программа со страшным интерфейсом. Пользователей это отпугивает, а разработчики похоже даже не собираются как-то избавляться от этого ярлыка. Хотя бы скриншоты на сайте поменяли бы на более приличные. Результат - потеряли пользователей. Ну приложение за деньги не продается, поэтому видимо количество пользователей роли не играет.

Кстати я тут краем уха слышал, что у tk какие-то проблемы с двумя мониторами - диалоги вылезают по центру виртуального дисплея.
Соглашусь. Кстати печаль есть. Буквально вчера новость - космонавт сказал, что собирается выпиливать Xorg и заменять его на Wayland. Кое-кому, если это действительно произойдет, придется переписывать код.
Описание и прототипирование самого UI является декларативной задачей. Основная часть которой должна возлагаться в теории на дизайнеров. Прототипирование приложения уже другое дело, но мы же речь ведем об UI?
Это каких же?

Берем типичную задачу, которую надо реализовать под Linux. Какая-то мелкая система документооборота. Десктопное приложение, Фронтэнд к БД, отображение данных, как в виде таблиц (кэширование, сортировка, многоуровневые заголовки, агрегирование), так и в виде графиков (паи, бары, лайны..), построение отчетов по всему этому хозяйству (пусть без дизайнера отчетов, с генерацией во что-нибудь распространенное вроде pdf, xml и open document).

Какие технологии возьмем, чтобы написать это в разумные сроки?

> Дело в том, что большинству пользователей tkabber известен как программа со страшным интерфейсом.
Ну не озадачились default'ным layout'ом разработчики. Полагали, что пользователи сами осилят настроить под себя. Tkabber вовсе не показатель технологии. Взгляните, например, на aMSN. Там всё, как вы любите.

> Кстати я тут краем уха слышал, что у tk какие-то проблемы с двумя мониторами - диалоги вылезают по центру виртуального дисплея.
Слухи это всё. Разговорчики малограмотных. Не слушайте дебилов. Просто попробуйте сами! Нет никаких проблем - диалоги вылезают там, где вы пожелаете.

> Буквально вчера новость - космонавт сказал, что собирается выпиливать Xorg и заменять его на Wayland. Кое-кому, если это действительно произойдет, придется переписывать код.
Вам не придётся, если вы не собираетесь писать на примитивах XOrg'а. Придётся разработчикам toolkit'ов или Canonical'у. Вас это не потревожит.

> Описание и прототипирование самого UI является декларативной задачей. Основная часть которой должна возлагаться в теории на дизайнеров. Прототипирование приложения уже другое дело, но мы же речь ведем об UI?
Хорошо бы, если бы всегда декларативной. Но не всегда это удаётся. Удаётся спрототипировать GUI декларативно только в статике. Когда же нужно прототипировать сложный интерфейс в динамике, скажем, на qt вам это быстро не удасться. На tcl/tk получается в разы быстрее. К тому же, если прототип получается хороший и его приняли - можно так и оставить :-) и продолжить на tcl/tk.

> Это каких же?
Элементарно.

> Берем типичную задачу, которую надо реализовать под Linux.
Так, берём. Только зачем же так мелочно - под Linux. Мы же не дурочки какие. Будем писать кроссплатформенно. Нынче прикладных программистов не печалит платформа.

> Фронтэнд к БД, [...]
TclODBC, TclMySQL, TclSQLite, etc.

> [...] отображение данных, как в виде таблиц (кэширование, сортировка, многоуровневые заголовки, агрегирование) [...]
Tablelist, TkTable.

> [...] так и в виде графиков (паи, бары, лайны..) [...]
Vu widgets, Tk canvas.

> [...] построение отчетов по всему этому хозяйству [...]
Закладываем Vu widgets на tk canvas (или рисуем на чистом canvas'е, ибо сорцов масса - можем посмотреть туда). С canvas'а геренируем PostScript, а далее, очевидно, куда угодно.

> Какие технологии возьмем, чтобы написать это в разумные сроки?
Технологии? За разумные сроки?
Tcl/Tk or XUL/JavaScript. Быстро, функционально и, при должной снаровке, - качественно.
Проект обещает стать нечто большим? А наши человеческие и временные ресурсы сильно ограничены? Но мы ведь умны? Берём технологии функциональной парадигмы и строгую типизацию - OCaml, Haskell.
В жёстком мире startup'а нет больше выбора. C++, Java и прочее - забвение и потеря времени и денег. Нет никаких шансов на выживание при выборе примитивных, многсловных технологий нигеров.

[• deadlock]

Вы вообще что подразумеваете под "писать на QT"? Использовать QT можно и в Python, и в PHP. Что в Вашем понимании GUI? Именно, то что его нужно рисовать, а не писать.
Касательно практики применения, возможностей QT вполне хватало.
p.s. Виджеты иногда приходилось писать, но редко.

> Использовать QT можно и в Python, и в PHP
Можно, но от этого плохо для здоровья. Либы с крестовыми ООП'ыми интерфейсами - плохие либы.

> Что в Вашем понимании GUI? Именно, то что его нужно рисовать, а не писать.
Нет же. Как раз таки сложные GUI можно только писать и, в некторых случаях, - генерировать. Рисовать можно только лишь тупенькие макетики.

Сообщение отредактировал deadlock - Nov 6 2010, 23:52

[• Amp]

Так, берём. Только зачем же так мелочно - под Linux. Мы же не дурочки какие. Будем писать кроссплатформенно. Нынче прикладных программистов не печалит платформа.

Ну как. Под мэйнстримовые формошлепные технологии Windows существует куча готовых компонентов. Редакторы отчетов, чарты, таблицы. Для технологий, которые обычно применяются для написания кроссплатформенного ПО подобных вещей кот наплакал. Потому что продажи аналогичных библиотек для Tk или GTK+ провалятся с треском. Причина проста и очевидна - это почти никому не нужно. Да даже кроссплатформенность здесь мало кому нужна - 1% десктопа погоды не делает.

Tablelist, TkTable.

Они реализуют базовый функционал таблицы. Сортировка, поиск, drag'n'drop настройка локалей для колонок, заголовки - все это писать ручками. Про агрегацию и думать не хочу - там придется переписывать рендерер. Это не сто, не двести и даже не тысяча строчек кода. Привет велосипедам.

Vu widgets, Tk canvas.

Хорошо хоть не gnu plot. Оба предложенных варианта предполагают написание графиков с нуля. Куча кода.

Закладываем Vu widgets на tk canvas (или рисуем на чистом canvas'е, ибо сорцов масса - можем посмотреть туда). С canvas'а геренируем PostScript, а далее, очевидно, куда угодно..

Опять бесполезный велосипедный код. Ошибки, отладка, потраченное время. Чуть сложнее проект, например, пользователи решили сами редактировать и составлять отчеты - все, ты теперь пишешь не свою уютненькую мордочку к БД, а полноценный редактор отчетов и проклинаешь все на свете.

Пока ты все это напишешь на Tcl/Tk, другие ушлые ребята все давно напишут на Java или C#, потому для этих языков уже существует стэк технологий, которые реализуют требуемый функционал. О каком удобстве речь, когда ты как мартышка в мыле пишешь вещи, которые для других платформ давно написаны, протестированы, апробированы, имеют хорошую документацию и немалое сообщество пользователей?

На сайты с дополнительными виджетам tk даже заходить страшно, скриншотов практически нет (стыдно?), а даты последних релизов некоторых библиотек нагоняют печаль. Ощущение, что действительно nobody cares. Причем уже лет эдак 10.

[• deadlock]

Ну как. Под мэйнстримовые формошлепные технологии Windows существует куча готовых компонентов. Редакторы отчетов, чарты, таблицы. Для технологий, которые обычно применяются для написания кроссплатформенного ПО подобных вещей кот наплакал. Потому что продажи аналогичных библиотек для Tk или GTK+ провалятся с треском. Причина проста и очевидна - это почти никому не нужно. Да даже кроссплатформенность здесь мало кому нужна - 1% десктопа погоды не делает.

Они реализуют базовый функционал таблицы. Сортировка, поиск, drag'n'drop настройка локалей для колонок, заголовки - все это писать ручками. Про агрегацию и думать не хочу - там придется переписывать рендерер. Это не сто, не двести и даже не тысяча строчек кода. Привет велосипедам.

Хорошо хоть не gnu plot. Оба предложенных варианта предполагают написание графиков с нуля. Куча кода.

Опять бесполезный велосипедный код. Ошибки, отладка, потраченное время. Чуть сложнее проект, например, пользователи решили сами редактировать и составлять отчеты - все, ты теперь пишешь не свою уютненькую мордочку к БД, а полноценный редактор отчетов и проклинаешь все на свете.

Пока ты все это напишешь на Tcl/Tk, другие ушлые ребята все давно напишут на Java или C#, потому для этих языков уже существует стэк технологий, которые реализуют требуемый функционал. О каком удобстве речь, когда ты как мартышка в мыле пишешь вещи, которые для других платформ давно написаны, протестированы, апробированы, имеют хорошую документацию и немалое сообщество пользователей?

На сайты с дополнительными виджетам tk даже заходить страшно, скриншотов практически нет (стыдно?), а даты последних релизов некоторых библиотек нагоняют печаль. Ощущение, что действительно nobody cares. Причем уже лет эдак 10.

> Потому что продажи аналогичных библиотек для Tk или GTK+ провалятся с треском.
Да ну? Prooflink в студию. Где и когда продавались библиотеки для Tk и GTK+ и какова степень треска при провале?

> Причина проста и очевидна - это почти никому не нужно. Да даже кроссплатформенность здесь мало кому нужна - 1% десктопа погоды не делает.
Обманываешь ведь. Кроссплатформенно нынче любое более или менее серьёзное приложение. Сегодня завязываться на конкретной платформе сверх ламеризма и низости. Все лучшие технологии, знаете-ли, позволяют писать кроссплатформенно.

> Ну как. Под мэйнстримовые формошлепные технологии Windows существует куча готовых компонентов. Редакторы отчетов, чарты, таблицы.
Чарты, таблицы? А где их сейчас нет? Расскажи мне про чарты и таблицы подробнее? В этих ваших мега технологиях какие-то особые "чарты" и "таблицы"? Приведи, пожалуйста, пример того, как ты можешь построить очень удобно какую-нибудь крутую таблицу, да такую, чтоб я просел за кучей кода и отладкой?
Редакторы отчётов? Расскажи общественности про редакторы отчётов, которые ты можешь встроить в свои приложения?
Я же поступлю следующим образом: предоставлю пользователю подавать системе на вход свои SVG-файлы с документацей о наборе полей/контролов имеющие место в отчётах. Портабельность таких "редакторов" - 100%. Трудозатраты на программирование XML стремятся к нулю.

> Они реализуют базовый функционал таблицы. Сортировка, поиск, drag'n'drop настройка локалей для колонок, заголовки - все это писать ручками.
Может стоит ознакомиться с докуменацией к API tablelist, а не вещасть откровенную ложь и вводить в заблуждение общественность? Я даже ссылку дам: tablelist.
По поводу локалей, если ты имешь ввиду интернациональные локали, то это сейчес тревожит только идиотов, ибо есть Unicode.
Поиск и агрегация действительно пишутся руками, по другому нельзя. А причина в том, что логика поиска и агрегации бывают любой сложности. Формализация агрегации может иметь место только в простейшем случае. Например, если нужно прямо отобразить результерующее множество DQL запроса к РБД. Но такая агрегация никому не нужна и посему ты также будет писать агрегатор руками. А вот написать агрегатор на ламповой жабочке или C# куда сложнее, чем на tcl. Мозолей у тебя будет больше. Я гарантирую!

> Оба предложенных варианта предполагают написание графиков с нуля. Куча кода.
Нет. На вход я буду подавать параметры графика. Ты плохо ознакомился с вариантом Vu widgets. Минимальное возможное количество кода.

> Пока ты все это напишешь на Tcl/Tk, другие ушлые ребята все давно напишут на Java или C# [...]
Нет, всё совсем не так. "Ушлые ребята" с тёмной кожей и рассудком тёмным :-) провлят сроки и в конечном итоге выпустят говно. Я же со своей маленькой командой "белых и умных ребят" выиграю конкуренцию.

> О каком удобстве речь, когда ты как мартышка в мыле пишешь вещи, которые для других платформ давно написаны, протестированы, апробированы, имеют хорошую документацию и немалое сообщество пользователей?
О "мартышках" ты будешь иметь право говорить только тогда, когда научишься разбираться в технологиях, в DSL, научишься понимать какие DSL для каких задач максимально подходящи. Когда научишься понимать разницу терминов "функционал" и "функциональность". Когда перестанешь держаться за примитивненькие технологии, которые тебе удалось частично осознать. Когда поймёшь фундаментальное отличие семантики языка от API библиотеки. Когда научишься понимать истинную цену технологии и отсекать bullshit. Ну, вообщем, когда немножко станешь похож на программиста.

> На сайты с дополнительными виджетам tk даже заходить страшно, скриншотов практически нет (стыдно?), а даты последних релизов некоторых библиотек нагоняют печаль. Ощущение, что действительно nobody cares. Причем уже лет эдак 10.

Нет не стыдно, ибо screenshot'ы есть. Просто нужно немножко осилить google. Каких библиотек даты релизов тебя смутили? Что сейчас не развиваеться в tk, что должно бы было?

[• Snowm@n]

Можно, но от этого плохо для здоровья. Либы с крестовыми ООП'ыми интерфейсами - плохие либы.

Это всего лишь Ваше ИМХО, тем более юзаются они там через обертки

Нет же. Как раз таки сложные GUI можно только писать и, в некторых случаях, - генерировать. Рисовать можно только лишь тупенькие макетики.

Пример в студию такого сложного интерфейса, что его нельзя нарисовать.

А наши человеческие и временные ресурсы сильно ограничены? Но мы ведь умны? Берём технологии функциональной парадигмы и строгую типизацию - OCaml, Haskell.

Imp, перелогинивайся уже

Редакторы отчётов? Расскажи общественности про редакторы отчётов, которые ты можешь встроить в свои приложения?

Что нибудь вроде FastReport есть в tk?

Я же поступлю следующим образом: предоставлю пользователю подавать системе на вход свои SVG-файлы с документацей о наборе полей/контролов имеющие место в отчётах. Портабельность таких "редакторов" - 100%. Трудозатраты на программирование XML стремятся к нулю.

Вы видимо мало общались с реальными пользователями. Им нужна WYSIWYG формошлепка, ни с какими SVG файлами они возится не захотят. Шлепнул, сделал preview, распечатал. Только так. А еще чаще ткнул пару чекбоксов, подкрутил, посмотрел, распечатал.

Обманываешь ведь. Кроссплатформенно нынче любое более или менее серьёзное приложение.

Технология .net кросплатформенна? Только не надо про mono, там и так все понятно. И про то что .net - отстой также не надо.
Крутые дизайнерские тулзы типа фотошопа или корела туда же, САПР.
p.s. Более-менее серьезный проект с использованием tk написанный в студию

Сообщение отредактировал Snowm@n - Nov 7 2010, 05:04

--------------------

Developer -> Lead Developer -> Lead Architect -> ... ?

[• Imp]

Imp, перелогинивайся уже 

Это не я, я запасся попкорном и наблюдаю

[• jem]

О "мартышках" ты будешь иметь право говорить только тогда, когда научишься разбираться в технологиях, в DSL, научишься понимать какие DSL для каких задач максимально подходящи. Когда научишься понимать разницу терминов "функционал" и "функциональность". Когда перестанешь держаться за примитивненькие технологии, которые тебе удалось частично осознать. Когда поймёшь фундаментальное отличие семантики языка от API библиотеки. Когда научишься понимать истинную цену технологии и отсекать bullshit. Ну, вообщем, когда немножко станешь похож на программиста.

Мне кажется, или это и вправду смахивает на луговщину? И кстати, мне интересно услышать про "фундаментальное отличие семантики языка от API библиотеки". Ибо я такое уже несколько раз встречал и либо я чего-то не понимаю, почему они в один ряд ставятся, либо это из серии про изоморфизм Карри-Ховарда.

--------------------

C, Clojure(Script), Common Lisp, ECMAScript, Haskell, Java, Lua, Perl, PL/SQL, Python, Scala, SQL, Transact-SQL.