Язык программирования (Отписываем :)F)

[Jaanq]

люблю с/с++, очень красивый язык перл, уважаю
не люблю ява-программистов - они в большенстве своем не понимают, что вообще делают, представление даже о таких вещах как стек или куча у них отсутствует...

[izen.fire]

не люблю ява-программистов - они в большенстве своем не понимают, что вообще делают, представление даже о таких вещах как стек или куча у них отсутствует...

Стэк — это класс java.util.Stack (параметризованный контейнер-дженерик в Java 5.0). Вот из JavaDoc цитата:

The Stack class represents a last-in-first-out (LIFO) stack of objects. It extends class Vector with five operations that allow a vector to be treated as a stack. The usual push and pop operations are provided, as well as a method to peek at the top item on the stack, a method to test for whether the stack is empty, and a method to search the stack for an item and discover how far it is from the top.

When a stack is first created, it contains no items.

A more complete and consistent set of LIFO stack operations is provided by the Deque interface and its implementations, which should be used in preference to this class. For example:

Deque<Integer> stack = new ArrayDeque<Integer>();

Since:
JDK1.0

То есть метафоры Стэк, Очередь, Дека и другие были в библиотеке языка с 1995 года (с момента опубликования), а вы говорите, что java-программисты не разбираются в этом.

В C++ вместо дженериков есть шаблоны (templates), но они завязаны на RTTI и позднее связывание кода. Дженерики java проверяются на этапе компиляции на соответствие типов, что быстрее, и исключает ошибки времени выполнения явного и неявного преобразования типов в C++.

А ещё в java существует стандартный API коллекций (Java Collections Framework). И иерархии классов для многопоточного программирования (пакеты java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks), что вместе со встроенными возможностями языка по работе с потоками имеет серьёзные преимущества в скорости написания и отладки безопасного (в отличие от C++) кода.

Насчёт кучи вы тоже погорячились — любой объект инстанцируется на куче. Бездумное использование генераций объектов (без реюзинга существующих) и надежда на умный сборщик мусора приводит начинающих явщиков (закончивших сишников) к плачевному результату: память "течёт". Не в том смысле, что она теряется операционной системой, а в том, что java-приложение начинает требовать всё больше и больше для своей работы из-за большого количества ненужных, но связаных с основной программой объектов (отдельные кластеры/графы брошенных объектов GCC всё ещё может убрать, но связанные с основным кодом — нет). Как результат: полное непонимание происходящего и списание распухания требований к ресурсам на язык и технологию Java. Это — типичная черта сишников, привыкших вручную убирать "мусор", но в Java никаких инструментов для таких нет, а смелое полагание на GCC приводит к плачевному результату.

[warp]

приплюснутый люблю, но огорчает что он runtime зависимый и ось на нём не напишешь сходу. по мимо "написание оси на с++" из возрастных болезней болею асмом.

[watashiwa_daredeska]

Вы не выбрали пункт, за который хотите проголосовать. Вернитесь назад и выберите один из пунктов голосования, которому хотите отдать свой голос

Почему нет пункта "против всех"? Но если уж что-то выбирать, то Lisp будет на первом месте, а C++ -- на последнем.

[watashiwa_daredeska]

В C++ вместо дженериков есть шаблоны (templates), но они завязаны на RTTI и позднее связывание кода. Дженерики java проверяются на этапе компиляции на соответствие типов, что быстрее, и исключает ошибки времени выполнения явного и неявного преобразования типов в C++.

Это кто вам такую чушь сказал? Плюсовые шаблоны самые что ни на есть compile-time и ни на какую RTTI не завязаны. Более, чем жабские дженерики. Шаблоны инстанциируются (какое русское слово для этого ужасного термина есть?), и в результате получается несколько реализаций -- по одному на каждый набор шаблонных параметров, каждая реализация настолько же эффективна, как если бы эти параметры были подставлены вручную. В жаве же инстанс один, который реально работает с Object и немного теряет в производительности из-за приведений типов в runtime. Хотя соответствие типов -- да, проверяется в compile time.

А ещё в java существует стандартный API коллекций (Java Collections Framework).

STL

И иерархии классов для многопоточного программирования (пакеты java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks),

boost, хоть и не стандартный де-юре, но настолько популярный, что можно считать стандартом де-факто (часть будет в стандартной библиотеке C++-0x).

что вместе со встроенными возможностями языка по работе с потоками имеет серьёзные преимущества в скорости написания и отладки безопасного (в отличие от C++) кода.

Встроенные средства -- это synchronized что-ли? Фигня это в плане написания безопасного многопоточного кода. Вот настоящий message passing, как в Erlang, действительно дает серьезные преимущества.

Насчёт кучи вы тоже погорячились

Я думаю, Jaanq имел в виду структуру данных heap.

[izen.fire]

watashiwa_daredeska: Шаблоны инстанциируются (какое русское слово для этого ужасного термина есть?), и в результате получается несколько реализаций -- по одному на каждый набор шаблонных параметров, каждая реализация настолько же эффективна, как если бы эти параметры были подставлены вручную. В жаве же инстанс один, который реально работает с Object и немного теряет в производительности из-за приведений типов в runtime. Хотя соответствие типов -- да, проверяется в compile time.

В Java "оборачивание" дженериков в контейнеры производится компилятором. Ну, да, создаются несколько дополнительных классов, чтобы обеспечить "совместимость" байткода со стилем JVM/target=1.4 (где вообще нет обобщённых типов) — байткод в .class-файлах вообще лишён информации о каких бы то ни было дженериках, "автобоксинге" и прочего синтаксического сахара исходников, появившегося в Java 5.0. В этом смысле .class-файлы разработчики Java называют "очищенными".

Шаблоны в C++ для безопасного использования в/из чужих бинарных библиотек(ах) требуют проверки типов на этапе выполнения программистом.
Дженерики — проверяются на этапе компиляции компилятором, .class-файлы, полученные в результате компиляции "с дженениками", готовы для безопасного использования в сторонних приложениях. Исходники не нужны.

watashiwa_daredeska: STL

Вы путаете библиотеку шаблонов (STL) с работающим кодом (JCF).

watashiwa_daredeska: boost, хоть и не стандартный де-юре, но настолько популярный, что можно считать стандартом де-факто (часть будет в стандартной библиотеке C++-0x).

"Будет или уже есть?" — риторический вопрос.

watashiwa_daredeska: Встроенные средства -- это synchronized что-ли? Фигня это в плане написания безопасного многопоточного кода. Вот настоящий message passing, как в Erlang, действительно дает серьезные преимущества.

Встроенные стредства — примитивы синхронизации (мониторы объектов, методы синхронизации и протокол их работы), а не "synchronized".

[watashiwa_daredeska]

Отвечу с примером: http://pastebin.com/m55285629

Шаблоны в C++ для безопасного использования в/из чужих бинарных библиотек(ах) требуют проверки типов на этапе выполнения программистом.

Открою вам большой секрет: шаблонов в бинарных библиотеках не бывает. И никакой проверки программистом на этапе выполнения не надо.

Не так? Покажите в моем примере такую проверку и шаблон из бинарной библиотеки. Или приведите свой пример.

Исходники не нужны.

Именно поэтому жабские дженерики менее эффективны.

Вы путаете библиотеку шаблонов (STL) с работающим кодом (JCF).

А шаблоны это по вашему не работающий код? Класс vector в моем примере не работает или он не из STL? Алгоритмы copy и transform в моем примере не работают или они не из STL?

"Будет или уже есть?" — риторический вопрос.

Стандарт де-факто немногим хуже стандарта де-юре. Если решается поставленная задача -- не все ли равно? Я, конечно понимаю, есть педанты, которые могут заявить, что GUI на C++ делать невозможно, т.к. в стандарте этого нет.

Встроенные стредства — примитивы синхронизации (мониторы объектов, методы синхронизации и протокол их работы), а не "synchronized".

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

[kosteel]

А я очень любвиобильный, мне все по своему нравятся, как в том анекдоте:

- Сэм, - спросил лорд своего слугу, - какие лошади вам больше всего нравятся, белые или воронные?
- Видите ли, сэр, когда я скачу на белой, то мечтаю о воронной, а когда на воронной, то мечтаю о белой.
- А какие женщины вам больше нравятся, блондинки или брюнетки?
- Видите ли, сэр...
- Ладно, я понял вас, Сэм, можете не продолжать.

[Mars803]

Мои два самых любимых:
1. LUA
2. PHP

[.snif]

Программирую на PHP, кодил на дельфе года полтора назад, потом забросил. Сейчас баш учу

[altwazar]

Пробовал питон, php, java, c, c++. Везде своих заморочек хватает.
Когда пишу на одном языке часто думаю о том, как эта часть бы хорошо получилась в другом.

[Naruto-kun]

Люблю с/c++, bash, perl. В последнее время на работе правда приходится чаще работать с bash. А вот java не взлюбил с первого с ней знакомства.

[izen.fire]

Да уж. Java не для слабых.

[Cra3y]

Люблю C за "низкоуровневость",
С++ - за шаблоны,
Perl - за регулярные выражения,
Bash - как средство сборки частей написанных на C, C++ и Perl в единое целое )

[drBatty]

Да уж. Java не для слабых.

скорее наоборот ИМХО.
вот что вправду не для слабых - С++, его можно изучать годами, да так и не понять

[altwazar]

Да уж. Java не для слабых.

скорее наоборот ИМХО.
вот что вправду не для слабых - С++, его можно изучать годами, да так и не понять :(

Ява простая и понятная. Пока дело до jsp не доходит :)

[PBPROG]

Кодю на PureBasic.
Он простой и API знать не надо.

[ekkl]

На винде немного занимался программированием. Пробовал бейсики, в т.ч. Purebasic.
Вотос в том, есть ли в демке VisualDesinger?
В виндвой версии, по-моему был.
Устанавливать не пробовал, просто распаковал и запускал среду - нет.
Или нужно ставить?

[pcodr]

use perl or die

[PBPROG]

есть ли в демке VisualDesinger?

В демке есть, но только в версии компилятора под Windows, а под Linux он отсутствует даже в полной версии.

На оф. форуме есть тема, где обсуждается версии VisualDesinger под Windows и Linux http://forums.purebasic.com/english/viewtopic.php?t=30885

Вот архив с версией под Windows http://users.skynet.be/berikco/visual%20designer.zip
А вот под Linux http://users.skynet.be/berikco/visual%20designer.tar.gz

[mix1m]

голосовал за java, хотя "кормлюсь" PL/SQL (кто его не включил в опрос? )

[ekkl]

use perl or die

а в перле можно создавать окна?
Я думал, что перл еэто что-то пита ПХП для серверных сценариев только.
А компилятор для создания исполняемых файлов?

[drBatty]

а в перле можно создавать окна?
Я думал, что перл еэто что-то пита ПХП для серверных сценариев только.
А компилятор для создания исполняемых файлов?

ну я окна успешно и в sh создаю...
а перловка, это ИМХО что-то такое... ну не знаю, не рыба, не мясо... вроде как и повыше скриптов, да и по лучше, и регулярные выражения удобные... Но на нормальный Язык вроде С++ - не тянет... На любителя, и/или на некоторый узкий круг задач... ИМХО

[ekkl]

ну я окна успешно и в sh создаю..
А примерчик можно? Желательно в кнопкой

На бейсике кодировал в основном, немного на ассемблере.
Немного адаптируюсь к линуху -- продолжу ПХП юзать (сайт доделывать)
Ну а перл не знаю. На сколько он схож с ПХП и бейсиком? Может действительно стоит.
Суппер - пуппер навороченого не нужно. Так до 1000 строк.....

На оф. форуме есть тема, где обсуждается версии VisualDesinger под Windows и Linux http://forums.purebasic.com/english/viewtopic.php?t=30885
Вот архив с версией под Windows http://users.skynet.be/berikco/visual%20designer.zip
А вот под Linux http://users.skynet.be/berikco/visual%20designer.tar.gz

Или что-то со мной, или линухом. Но дизайнер глючит до невозможного. Приходится руками код править. Чепуху пишет. Два раза одно и то же окно создает.
Дальше НЕВОЗМОЖНО писать кирилицей. Это особенность линуксовой версии? Или у меня руки кривые?

Может стоит попробовать какой-нить линуховый бейсик? Типа Hbasic или что-то похожее.

[drBatty]

А примерчик можно?

man xmessage
man gmessage

Нужна прога - если зашли как root, отсылает мне сообщение

[ekkl]

Работает

[pcodr]

use perl or die

а в перле можно создавать окна?
Я думал, что перл еэто что-то пита ПХП для серверных сценариев только.
А компилятор для создания исполняемых файлов?

Конечно можно. Perl -- универсальный язык программирования.
В частности для создания окон есть биндинги библиотек Qt3, GTK+, wxwidgets, Tk и еще несколько экзотических.
Кстати и на PHP тоже можно писать оконные приложения, я вот тут по учебным нуждам забацал кой чего на php с окнами.

Ну а перл не знаю. На сколько он схож с ПХП и бейсиком? Может действительно стоит.

На PHP Perl похож, точнее это PHP похож на Perl Но в отличии от PHP Perl более локоничен и интересен, что временами не добавляет понятности. Ну а один из главных плюсов Perl'a это конечно его репозиторий с модулями -- cpan.org. Так что рекомендую к изучению.

[ekkl]

Надо будет попробовать.
Пока пробую разораться с бейсиками
1) GamBas - похоже не компилятор, созданные приложения открываются с помощью виртуальной машины
2) Hbasic - не могу поставить. configure, make все в норма
make install пишет что не требует обновления и ничего никуда не копируется. В папке исходников создается файл hbasic при запуске выскакивает ошибка KDE.
Неужели нет НОРМАЛЬНОГО Васика под линух?

[iso]

python, C, bash

[ekkl]

python, C, bash

Пардрн, это бейсики?
------------
Я так и не понял, есть ли компилятор для перла, или он совершенно не нужен?