Программирование на УКНЦ как?

[SuperMax]

Си позволяет огромное количество вольностей как в синтаксисе так и с типами в отличие от паскаля. Это и хорошо и плохо одновременно.
Поэтому исходники на Си всегда выглядят по разному (зависит от психического состояния программиста) в отличии от паскаля. Кстати где-то встречал программу прикол..
исходник из одной строки выдает двадцать восемь страниц не повторяющегося текста

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

вот у меня стек поисковой системы зеркал:
- Java
- Oracle SQL и PL/SQL
- PHP
- javascript
сейчас добавились программки на С/С++
тк все документировано - то вернуться легко и просто

[Advertiser]

[Oleg N. Cher]

Hunta, жизнь показала, что такие языки как Forth и Lisp, в которых можно на лету доопределять части самого языка, не взлетели нигде особо. У них самая ограниченная область применения. Меня до сих пор удивляет, почему на Forth'е не писали для RT-11 или, скажем, CP/M с их ограниченными ресурсами. Ведь язык очень гибкий, намного гибче Си.

Предположу, что здесь такая же ситуация, как с ПЛИС: туда можно вшить абсолютно любую систему команд; гибкость потрясающая. Но на практике тяготеют к чему-то привычному или готовому. Как в Sprinter'е или Spectrum Next к системе команд Z80. Нужен какой-то костяк, хребет, который задаст рёбра жёсткости. Это напоминает пример с дождевым червём: он очень гибкий, но прямо ходить не может. А у человека скелет зафиксирован, но зато он может прямо ходить.

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

[Hunta]

Hunta, жизнь показала, что такие языки как Forth и Lisp, в которых можно на лету доопределять части самого языка, не взлетели нигде особо

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

И примерно как с ПЛИС - нужно перестраивать мышление. Меня, честно говоря, удивляет, что я, как программист, а не железячник, всё таки достаточно быстро разобрался в разработкой под FPGA (ну как быстро - по времени, вроде как два года уже вожусь, но если учесть, что это хобби, а не работа - то не по восемь часов в день и часто даже не по восемь часов в неделю, так что - наверное всё таки быстро). Хотя основной прорыва - это примерно последние полгода - когда вылез из песочницы DE10.

И что бы втянуть народ в разработку на FPGA - пытаются создать привычные языковые средства - типа программирования для FPGA на Verilog или вообще на C.

А по мне так VHDL нормаль. Просто до какой то степени мыслить надо как железячняк, а не только программист.

Так что излишняя гибкость в языках оказалась не очень ко двору.

Кому как.

Лучше уже зафиксировать минимальный сбалансированный объём языковых средств, о чём как раз в статье по ссылке постом выше.

Может он и сбалансированный, вот только если сравнивать с коммерческими языками разработки - набить символов, прежде чем получишь результат - придётся в разы больше. Чем на том же C# или C++. Так что точно так же - удел энтузиастов.

И ещё раз - статья - рассуждения в общем, никаких примеров из Оберона. Так что уже примерно на половине стало скучно.

[Oleg N. Cher]

Про "переносить удобно" я бы поспорил. Не очень удобно. Достаточно вспомнить барьер, когда Forth стал 32-битным. 90% 16-битного кода отправилось на помойку сразу. А у Си/Паскаля ситуация с этим оказалась несколько получше даже. Парадокс.

Поспорим ещё о том, что программирование состоит не только в наборе "многабукаф"?) Я ещё давно-давно здесь на форуме приводил примеры, где на Обероне код получается в символах короче, чем на Си. Их все демонстративно проигнорили. Где-то длиннее, где-то короче. Но барьер вхождения в Оберон для неофитов почти отсутствует, если им старпёры, желающие самоутвердиться, голову не заморочат.

[MM]

Обычно на Паскале для ДВК писали штатные блондинки согласно ТЗ , например в областях :
1. Тестирование ИС на стендах
2. Софт с десятичной арифметикой, особенно плавучкой.
3. Прочий некритичный к быстродействию и объему выходного файла софт.

Соотношение качества программы на Паскале ДВК и ассемблера - примерно на полпорядка хуже по объему и быстродействию на Паскале.
При применении плавучки - сопоставимо.

[hobot]

[Oleg N. Cher]

В чистом виде подход конъюнктурщика: "а что я буду иметь с этого сейчас?". SuperMax, такие люди, как Вы, губят планету ради получения максимальной прибыли сегодня. А я думаю про отдалённые перспективы, во что надо инвестировать свои силы, чтобы получить достойный инструмент, за который не будет стыдно.

Да, сейчас Паскаль в самой интересной своей инкарнации - Free Pascal - отстаёт от разных прочих средств. Там сравнительно небольшая команда. Но всё-таки.

Си остаётся опасным языком, полным хаков. И сложность его растёт с появлением новых редакций.

- - - Добавлено - - -

И давайте прекратим спор, мы из разных миров. Это как сытый голодного не поймёт.

[SuperMax]

В чистом виде подход конъюнктурщика: "а что я буду иметь с этого сейчас?". SuperMax, такие люди, как Вы, губят планету ради получения максимальной прибыли сегодня. А я думаю про отдалённые перспективы, во что надо инвестировать свои силы, чтобы получить достойный инструмент, за который не будет стыдно.

а давайте без хамства и грязных инсинуаций ? оскорбления собеседника не делают Вам чести.

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

[Oleg N. Cher]

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

требует гигабайтов оперативной памяти там, где задача на чистом СИ обойдется мегабайтами

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

Или вот, допустим, выкатывают разработчики нового супер-Андроида новый язык, на котором предлагается всё писать под него. Язык этот ничем не примечательный, но позволяет очень круто дёргать фишки этого самого супер-Андроида. Сообщество получает плюс один язык, на котором обязательно будут писать. Вот так и плодится современный треш. Потом вокруг него образуется движняк, начинают на нём обучать, постепенно вылизывают и делают из него что-то более или менее юзабельное. Но этого всего могло бы и не быть на самом деле. Если язык ничем особо не хорош, просто делает получше что-то одно, то имеет ли он право на жизнь?

Впрочем, я вижу точку зрения: "я начинал на Васике, потом кодил на Си и Яве. Значит Васик, Си и Ява подойдут всем". И понятно, что в этой схеме Паскаля нет и быть не может. А вот я начинал с асма, а Паскаль мне нравился на всех платформах, начиная со Спека и УКНЦ.

- - - Добавлено - - -

Кстати, программа на чистом Си, занимающая мегабайты, может упасть из-за утечек памяти или обращения по неверно инициализированному указателю. И убить людей, например. Или чего-то взорвать. А на более тяжёлом, но более безопасном языке - нет. Так что тут не так всё однозначно, как Вы пытаетесь показать.

[SuperMax]

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

я не являюсь сторонником/или противником явы, я просто умею работать и с этим инструментом тоже.

Или вот, допустим, выкатывают разработчики нового супер-Андроида новый язык, на котором предлагается всё писать под него. Язык этот ничем не примечательный, но позволяет очень круто дёргать фишки этого самого супер-Андроида. Сообщество получает плюс один язык, на котором обязательно будут писать. Вот так и плодится современный треш. Потом вокруг него образуется движняк, начинают на нём обучать, постепенно вылизывают и делают из него что-то более или менее юзабельное. Но этого всего могло бы и не быть на самом деле. Если язык ничем особо не хорош, просто делает получше что-то одно, то имеет ли он право на жизнь?

это рынок.
есть задача - разработка мобильного приложения
и тут выигрывает тот кто решит эту задачу за меньшие время/деньги

я в свое время очень полюбил Clarion, ибо он позволял решать теже задачи, что решали люди на FoxPro, но значительно быстрее, функциональнее и качественнее - те мои программы летали даже на 286х (!)
а для моего магазина хватало 386й SX, причем количество наименований товара превышало 10тыс (1С на таком количестве на такой же машине очень жестко тупила). ну и поддержка сети появилась раньше.

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

Впрочем, я вижу точку зрения: "я начинал на Васике, потом кодил на Си и Яве. Значит Васик, Си и Ява подойдут всем". И понятно, что в этой схеме Паскаля нет и быть не может. А вот я начинал с асма, а Паскаль мне нравился на всех платформах, начиная со Спека и УКНЦ.

я же просил - не надо инсинуаций

и если уж говорить о моем стеке, то он сейчас
C / C++ начиная от PDP11 кончая Linux-ом и микроконтроллерами
Java
Oracle SQL / Oracle Java / Oracle PL/SQL
PHP
Javascript
Verilog HDL
HTML /CSS/HTML5

а вообще опыт шире
Basic
Focal
ассемблер PDP11
ассемблер х86
ассемблер C51
ассемблер Atmel 8bit
Pascal / Delphi
Fortran
всякие скриптовые языки
Clarion начиная CPD кончая 10-кой
FoxPro /Visual FoxPro
MSSQL SQL/T-SQL

Кстати, программа на чистом Си, занимающая мегабайты, может упасть из-за утечек памяти или обращения по неверно инициализированному указателю. И убить людей, например. Или чего-то взорвать. А на более тяжёлом, но более безопасном языке - нет. Так что тут не так всё однозначно, как Вы пытаетесь показать.

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