Беседка для программистов, или «Бутерброд с кодом»

МОЛОТОК не виноват что им начали забивать ШУРУПЫ. Так же и не виновна болгарка, из которой попытались сделать циркулярку и ненароком четвертовали себя.

 

Вопрос ставился проще - на чем программы короче получаются. Лучше-хуже - это уже от недостатка аргументов.

 

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

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

ЗЫ: Ну а если предположить, что гипотетический хороший язык программирования должен действительно отличать баг от фичи, то нафига нужен будет такому языку программист? Жри, скажет, батенька, что дают, и не лезь со своими командами и инструкциями. Или именно это и есть голубая мечта "настоящих программистов"?

 

Верно. Поэтому оставим узкоспециализированные инструменты в тех нишах, где им и место.

 

gudleifr
Короче или быстрее, короче листинг или быстрее написаны? Для разных задач и выбор будет разным. Нобелевскую мне!!!

 

Ну дык на чём же ещё операционки пишут?

Не-а. Всегда бывают ситуации, когда хотца "быстро и грязно" налабать и запустить, - например, чтобы проверить идею раньше чем протухнет, или когда заказчик/минетжер давит на сроки... Вот тут без самоконтроля уже никак. :-)

Ни-фи-гасеньки. Хреновый - вообще не, средненький - запрещает (ну или по крайней мере матерится на) всё мало-мальски опасное (включая уборку мусора за собой и вызов не санкционированных продавцом компилятора сторонних модулей), а по-настоящему хороший - позволяет ошибки локализовать и исследовать. Если тебе (страшно, лениво, лицензия/мама/начальник не позволяет, ... - ненужное зачеркни, пропущенное допиши) исследовать свои ошибки - пиши на FoxBase, Clarion2 или Java... :-(((((
(просто к слову пришлось) Вот термиты - эти да, умные. В почти каждом термитнике есть солидно оборудованная обсерватория. Но! - ни в одном обследованном термитнике энтомологи ни разу не видели хотя бы завалященького космодрома... :-(((((((((

 

Щас во многих IDE есть такая несуразица - не дают начать сборку потому что считают, что есть ошибка. Торопитесь жить, ПОКА это ещё можно отключить!
И, кстати, впервые это говно появилось в единственно-правоверных IDE из мира free/open source. Хотя казалось бы, каждому известно, что только свободное ПО спасёт чел-че-во.

 

Можно как минимум проконтролировать отсутствие целых классов рантайм-сбоев. Те же null reference exception или деление на ноль. Продвинутые техники позволяют доказать даже отсутствие переполнений.

 

Вот это я понимаю - подход. "Вы знаете, поручик был таким фантазёром!" ((L) вдова-генеральша мотивирует отказ продать люстру - память о друге семьи поручике Ржевском) :-)))))))

 

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

А программисту, который допускает ТАКИЕ ошибки, которые за него способен выявить тупой компилятор, и ничему не научился после нескольких запорченных модулей, следует все-таки подумать о смене рода деятельности.

 

Это верно только для классов языков, не представляющих интереса с точки зрения программирования.
И не забудьте, что не бывает компиляторов (как и программ вообще) без ошибок.

 

Ну, в винде сейчас и С++, и С# присутствуют. Singularity на чистом C#, хотя это исследовательский проект.

Это вообще другой вопрос.

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

 

(резюмируя отзывы на высказывание о хороших/плохих языках) Ура, не всё программирующее человечество ещё испорчено разделением труда! :-)

 

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

 

Для языков, "не представляющих интереса с точки зрения программирования", это делается просто. А для других тоже можно сделать, хотя и сложнее. Пример для языка Ц: http://www.astree.ens.fr/

 

(мрачно) Это голубая мечта их работодателей. :-(

+65537!

---------- Сообщение добавлено в 17:01 ---------- Предыдущее сообщение размещено в 16:59 ----------

Увидел и попытался усилить. Не получилось? (смотрит на Steel Rat'а, готовый разреветься от обиды на неудачу)

 

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

 

Рыжий Тигра, усилить там можно было только предложив Java или .NET вместо С++. А ты испортил!!! Испортил мою прекрасную шутку и реветь тут должен я, а ты каяться.

---------- Сообщение добавлено в 19:05 ---------- Предыдущее сообщение размещено в 19:03 ----------

Рыжий Тигра, и, кстати, у тебя 65537 в каком типе хранится?

 

Не-а! Это делается В языкАХ, но для ПРОГРАММИСТОВ, "не представляющих..." и далее по тексту. (и гнусно заржал)

 

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