Вышел FreePascal 2.6.0

возможно, но он таки есть

Дык си — кроссплатформенный ассемблер, на котором писать что-то кроме кодеков или ядер никому ни во что не упёрлось.

возможно, но он таки есть

Не знаю, не видел

си — кроссплатформенный ассемблер, на котором писать что-то кроме кодеков или ядер никому ни во что не упёрлось.

ура - клоуны в топике! (ткнул палочкой) а ты про существование /usr/lib, например, знаешь?

Не знаю, не видел

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Дык си — кроссплатформенный ассемблер, на котором писать что-то кроме кодеков или ядер никому ни во что не упёрлось

Ну я бы всё-таки не стал бы считать си ассемблером, с другой стороны, вон, gtk на нём пишут - другой вопрос, что из этого получается. Фотошоп тот же раньше был на си и ассемблере - информация от непосредственных разработчиков (как сейчас не в курсе)

Это всё случилось из-за того, что у сишечки более менее вменяемый кроссязычный ABI.

gtk

Грязные извращенцы :3

Ага, «A garbage collector for C and C++»

тебя смущает, что этот gc поддерживает два ЯП?

Молодцы! Рад за Обжект Паскаль - годный ЯП! Опережающий конкурент всяким Go,D,Vala и пр.

Ну так что там с чистым си или не было?

да ты упорот, зайди еще раз по ссылке и прочитай

да ты упорот, зайди еще раз по ссылке и прочитай

Там - это в стандартах, если вы не поняли. Например, ansi или iso, что там ещё есть? Если я напишу что-то своё на си, это ведь не значит, что оно есть в си, правда?

Дык си — кроссплатформенный ассемблер

Это поделие никак не тянет на ассемблер. А его кроссплатформенность видно по тоннам препроцессорной лапши в каждом хеллоуворде.

Это всё случилось из-за того, что у сишечки более менее вменяемый кроссязычный ABI.

Это не его заслуга.

Там - это в стандартах, если вы не поняли. Например, ansi или iso, что там ещё есть? Если я напишу что-то своё на си, это ведь не значит, что оно есть в си, правда?

В стандартах этого недоязыка, на которые ты фапаешь, много чего нет, ичо?

Там - это в стандартах

то что его нет в стандарте - общеизвестный факт, как и то, что код на С без использования сторонних библиотек, без кучи препроцессорных директив под ОС и железо, и даже использования расширений компиляторов - большая редкость, но раз вы такой поборник «чистоты» - дело ваше

Обосрался - обтекай, не умеешь - впитывай

то что его нет в стандарте - общеизвестный факт, как и то, что код на С без использования сторонних библиотек, без кучи препроцессорных директив под ОС и железо, и даже использования расширений компиляторов - большая редкость, но раз вы такой поборник «чистоты» - дело ваше

Я сразу написал, что gc в c - глупость, тем, кому там может потребоваться сборщик мусора, для начала стоит навести порядок у себя в голове, а потом он уже и не потребуется - вот такая диалектика

Я сразу написал, что gc в c - глупость,

я как бы и не отрицал - но написал, что он есть

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

во многих языках «выше» С он таки оправдан и нужен, главное только эти ЯП по назначению использовать

сразу поправлюсь - не «в», а «для» С, чтоб опять не спорить на ровном месте

Ну и при чём здесь история программной индустрии?

спроси у другого анонимуса

Распространённость языка ничего не говорит о его идеологической правильности. Самый популярный азык на земле — китайский.

А вот и нет. Английский, а не китайский

Обосрался - обтекай, не умеешь - впитывай

Повторяй это по 10 раз перед тем, как начинаешь лизать свои яйца, и по 15 после того, как прекращаешь их лизать.

спроси у другого анонимуса

Он невменяем

Ты какой-то ебанутый. А ответь ка на всякий случай, сам на чем пишешь программы?

Это радует) спасибо за новость))

Ты какой-то ебанутый. А ответь ка на всякий случай, сам на чем пишешь программы?

Ему доктор запретил.

mit - не школа, а один из лучших технологических университетов.

Изучите внутреннюю структуру объектов python. Я как-то озаботился, как сделать так, чтобы при изменении свойства объектов изменялись и их отображения в БД. И тогда и изучил структуру ООП в Python немного глубже, чем это обычно требуется.

история ничему не учит, ты что!

кроме кодеков или ядер никому ни во что не упёрлось.

Ruby - кодек или ядро?
ZCAD - кодек или ядро?
NewLisp - кодек или ядро?
Hedgewars - кодек или ядро?
Poppler - кодек или ядро?

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

Гы, гы, гы! Пусть чурбаньё печётся о чистоте басурманского языка, если ему заняться нечем.

Гы, гы, гы! Пусть чурбаньё печётся о чистоте басурманского языка, если ему заняться нечем.

Признай свой фэйл и извинись; глядишь, анонимус и простит тебя.

Признай свой фэйл и извинись; глядишь, анонимус и простит тебя.

Ну нельзя же так смешить, слишком калорийный торт получается.

Ей, Hedgewars вродь на сабже писан был, не? Остальные не интересовался, но добрая половина прикладных прог особно под винду раньше на Делфях писались.

Ну нельзя же так смешить, слишком калорийный торт получается.

Тебе, клоун, можно. Разрешаю.

Остальные не интересовался, но добрая половина прикладных прог моих одноклассников особно под винду раньше на Делфях писались.

Вот так правильно.

9 страниц написали, а

«собираемые» перечисления ($SCOPEDEUNMS) ($SCOPEDENUMS)

не заметили

респект мой тебе за внимательность

Неправильные программы должны успешно компилироваться и запускаться?

А с чего ты взял, что программ неправильная? Синтаксически все ок, вот только похоже с семантикой проблемы. Но тут любой компилятор бессилен, никто еще не может по мысли прогаммиста программу слобать.

Хорошим правилом считается не игнорировать предупреждения компилятора. Если у тебя есть предупреждение — скорее всего в коде ошибка.

Что-то навроде
(for ...
...
for)
(proc name
proc [name])
выглядит очень лаконично и ненавязчиво.

Да уж пипец как ненавязчиво. При наличии операторов комментария, городить новые операторы завершения операторного блока - верх тупизма.

Проще писать (если операторные блоки большие выходят) что-то вроде этого:

for (int i=...; ...; ...) {

...

} // for i

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

for (rs.First(); !rs.Eof(); rs.Next() ) {...}

Почему мне не нравился Паскаль по сравнению с С:

• Почему в языке используются функции с переменным числом параметров, а программисту это недоступно (Write/Read)?
• Отсутствие операторов инкремента и конструкций типа +=
• Function и Procedure
• Begin End вместо {}
• Строки до 256 символов

Почему мне не нравился Delphi по сравнению с С++ (ко всем тем же из первого пункта):

• отмена необходимости разыменовывать указатель (вместо Form^. пишется Form.
• отсутствие возможности переопределять операторы
• отсутствие множественного наследования и, как следствие, дерево от TObject
• отсутствие механизмов шаблонов
• отсутствием механизма ссылок

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

Раздражала в Паскале/Delphi эта «глубокая забота» о программистах, которые могут использовать потенциально опасные инструменты неправильно. Как будто нельзя написать кривой код даже в рамках Паскалевских ограничений! Подход С/С++ мне импонирует больше - «тебе дали все, но ты за все в ответе». Нужна железная дисциплина, чтобы писать нормальный код на С/С++ (да на любом языке тоже, но тут особенно), но возможности твои не ограничены практически ничем.

С точки зрения обучения, соглашусь, что ObjectPascal - достойный инструмент. Но если они все приятные штучки С++ внедрят к себе (генерики, *=, ++, ...), то лучше уже сразу С++ учить :)

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

Множественное наследование не нужно.

Отсутствие операторов инкремента и конструкций типа +=

в fpc есть.

Строки до 256 символов

в fpc и эта проблема решена.

P.S. Проблемы с Delphi частично решены в fpc.

Отсутствие операторов инкремента и конструкций типа +=

в fpc есть

Надо же... А тут народ давеча пальцем в них тыкал. Никому нельзя верить!

Множественное наследование не нужно.

Я бы не был бы так категоричен. Множественное наследование вынуждает вас делать вещи вроде общего корня (TObject) иначе не будут работать TList и прочие шняги (которые можно генериками вроде как решить, но их в Delphi не было тогда, а теперь они неинтересны в силу отсутствия качественных улучшений по сравнению с С++). Можно, конечно, было использовать нетипизированные указатели, но тогда тяжко искать проблемы с кривыми приведениями.

Вообще не зря в Java ввели понятие интерфейсов, хотя отцы-основатели тоже окрестили множественное наследование демонским. Однако же каждый раз переписывать реализацию или делать инстанцирование, на мой взгляд, тоже костыли.

Любой программист должен быть способным выразить алгоритм на нужном ЯП в рамках его(ЯП, ну и программиста тоже:) ограничений, но все же приятнее, когда ограничений меньше :).

Отсутствие операторов инкремента и конструкций типа +=
в fpc есть.

Я понял, что в FPC это есть, но в Delphi, его не было. Потому я юзал Borland C++ Builder, а потом вообще с Виндов съехал.