Здравствуйте, fmiracle, Вы писали:

F>А туы уверен что он тебе нужен, а не что ты просто не понимаешь как правильно использовать имеющийся?

Исследования, к которым я хотел бы приступить, уже ведутся — разумеется. за рубежом.
На супер-компьютере.
Не ислючено, что он не нужен, если удастся получить гениальные аналитические решения.
Но НАДЕЯТЬСЯ на это нельзя.

F>И уверен ли ты что созданный суперкомпьютер сможшь правильно использовать?

Я же его сам под себя и разрабатываю.
Вот смогут ли другие — это действительно нужно обсуждать.

F>Или там будет аппаратная защита от неправильного использования?

Конкретно, какого использования (каких ошибок)?
За контроль типов данных меня здесь уже критиковали.

Здравствуйте, computer20, Вы писали:

C>Цель проекта в том, чтобы позволить специалисту/там в прикладной области создать информационную систему не нанимая программиста.

Мечта. Старая как мир, по-детски наивная и абсолютно несбыточная. Примеров "мощных универсальных систем, не требующих программирования" было предостаточно, на вскидку вспоминается следующее:

— Gupta SQL Windows (кто-то из RSDN его недавно вспоминал) — где он сейчас?
— Deplhi — программистский RAD tool, а один хрен близок к подыханию.
— Flash — эти оказались умнее и эволюционировали (под давлением обстоятельств) к серьезному сложному языку.
— 1С — не так давно здесь писали что они тоже эволюционируют в сторону нормального программирования (в v8 нормальный sql-подобный язык запросов).

Здравствуйте, computer20, Вы писали:

C>Исследования, к которым я хотел бы приступить, уже ведутся — разумеется. за рубежом.
C>На супер-компьютере.
C>Не ислючено, что он не нужен, если удастся получить гениальные аналитические решения.
C>Но НАДЕЯТЬСЯ на это нельзя.
А банальный кластер из кучи дешовых писюков тебе не подойдет? Или вобще grid?
И вобще что за задача?

C>Конкретно, какого использования (каких ошибок)?
C>За контроль типов данных меня здесь уже критиковали.
Правильно нефиг перекладывать на железо то что может и должен делать компилятор. Болие того у компилятора это получится гораздо лучше. Гланое обеспечить строгую статическую типизацию и контроль границ массивов. Причем это должно быть невозможно обойти.

Здравствуйте, computer20, Вы писали:

C>ОС управляет загрузкой кэшей, при необходимости может переместить процесс в соседний процессор (кстати, процесс невозможно переместить в произвольный процессор — только в соседний, а вот например через один — уже нельзя).
А зачем такие ограничения?
Например в моей модели процесс может переместиться не то что на соседний процессор но и на другую машину с другим типом процессора. При это абсолютно прозрачно и без потери связей.
Единственные процессы которые не могут покинуть машину это демоны работающие с устройствами ввода/вывода конкретной машины и возможно какието системные сервисы.

C>В hardware-ных технологиях также необходимо понять, что ПОВТОРЕНИЕ ПАРАДИГМЫ результата не даст — какие бы талантливые проектировщики не работали в рамках старой парадигмы.
Не согласен.
Скажем переход с С++ на немерле дает огромный прирост производительности программиста.
И это еще далеко не придел.
А то что не программист сможет создавать сложные информационные системы я не верю.

C>Например в software-ных технологиях (я писал об этом на http://html60.chat.ru) я объясняю это награмождением средств:
Посмотрел. Дальше тега multi читать не стал.
Ибо это решение очень не гибко.
Часто бывает нужно проверить входные данные.
Показать/спрятать поля в зависимости от значений не одного, а нескольких полей и тп.
Короче AJAX рулит.

C>Зависимость от внешнего мира оборачивается низкой обороно-способностью — как и при монокультуре в сельском хозяйстве.
Те ты предлагаешь чтобы каждый делал все но плохо вместо того чтобы делать одно но хорошо?
Извини но это человечество уже проходило. Гдето в районе каменного века.

>>Не будут хирурги сами точить скальпели никогда.
C>Это ортодоксальность.
Это объективная реальность.
Ну не хотят люди заниматься раблотой не по профилю.

ЗЫ Убери с сайтов надпись "Дорогой друг" раздражает.

Hi computer20


>>>Ну не пользователь же будет ее писать!
c>А главное — она ОДНА И ТА ЖЕ независимо от количества процессоров.

Насчет процессоров пусть так и будет. А вот насчет задач это ОС как быть? Будет она универсальная или специализированная (для каждой предметной области своя)?

>>Ты серьезно считаешь, что это реально?

c>Да. Ты меня навел на мысль — разработать модель такой ОС.

Лучше не надо.

>>это будет специализированная ОС, которую надо будет писать для каждой предметной области.

c>>Нет.

То есть универсальная ОС. Значит софт будет специализированный?

c>ОС управляет загрузкой кэшей, при необходимости может переместить процесс в соседний процессор

Что такое "загрузка кэшей"?

c>(кстати, процесс невозможно переместить в произвольный процессор — только в соседний,
c>а вот например через один — уже нельзя).

Почему? Какое объективное препятствие есть для этого?


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

c>Инженеры.
c>Я же не предлагаю врачам процессор разрабатывать — только из них собрать.

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

>>А кто разработал технологии сборки? Опять инженеры?

c>См. предыдущий ответ.

См. выше также.

>>И причем для каждой модели разрабатывают новые технологические карты сборки.

c>Российские мужики такими сложными понятиями не оперируют — они смотрят на рынке нужную деталь,
лежат под машинами.

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

>>Собрали модель из готовых материалов? Или все делали с нуля (добывали уран, делали оборудование для обогащения, обогащали уран, делали все комплектующие)? Что-то мне подсказывает, что им дали все готовое. То есть они сделали очень маленкую часть, а все остальное делали другие профессионалы.

c>При сборке из комплектующих:
c>1. исчезает само существо эксперимента
c>2. не требуется 3 лет

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

c>Детали мне не известны.
c>По видимому делящийся материал получили в готовом виде (т.к. это сегодня единственный камень
c>предкновения перед повсеместным изготовлением бомб).
c>Остальное, видимо, сами.

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

>>Вот, например, практические все медицинские знания доступны.
>>Например, все могут спокойно прочесть как лечить переломы, инфаркты миокарда и прочее. Но почему все идут к врачу когда сломают ногу или руку или в случае инфаркта миокарда.

c>Потому что НЕ существует Малогаборитного Портативного Регенератора-Лечителя и
c>НЕ существует инструкции к нему (второе по причине первого ).
c>Тогда бы лечение требовало МАЛО усилий, и, если бы он не использовался,
c>можно было бы ставить вопрос о причинах этого (побочные эффекты, национальная культура, пр.)

Какие же причины несуществования такого замечательного прибора видишь? Я вижу пока лишь одну объективную причину. Это что разные болезни лечаться по разному. Даже одна и та же болезнь у разных людей лечиться тоже по разному. Найди общее в лечении ангины и перелома бедренной кости?

c>Подобную метафору я разбирал применительно к производству веществ.

Неудачная метафора.

>>Да потому что одних теоретических знаний недостаточно, нужна еще большая практика.

c>Соотносим два объекта метафоры — и какие же знания нужны, чтобы воткруть шину в шину
c>в baf-процессоре.

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

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

c>Причина — средства разработки излишне усложнены.

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

c>Писал уже об этом неоднократно: и в теме computer20, и в теме html60.
c>Указывал, какие промежуточные части, использование которых не оправдано, нужно выбросить.

c>Повторю, раз вы не читаете:

Остальное пропускаем. Читал. Еще раз внимательно перечитал. Ничего кроме потока слов не увидел. Объясни на пальцах, как твое предложение поможет врачам писать программы.


>>Вот раньше были простые токарные, фрезерные и прочие станки. Потом появились станки с ЧПУ. И требования к работникам

c>Не увеличились и не уменьшились — они изменились.

Они изменились в сторону повышения.

c>Одна плохо решенная проблема (низкая производительность труда в мех.обработке) была заменена
c>другой плохо решенной проблемой (порождением информационного продукта).

Предложи лучшее решение.

>>Опять требования к работникам таких станков только повысились

c>Не могли бы вы сказать, какие к ним предъясляюся требования.
c>Ну там: создать 3D-модель, сделать поправку на тепловое расширение заготовки,
c>выбрать скорость резца (чтобы не сломать резец и не точить долго).
c>Продолжите список.

Есть приятель, который уже черт знает сколько лет разрабатывает и внедряет САПР для авиастроения. Их САПР позволяет сразу делать прогу для станков с ЧПУ. Так в разговоре с ним он и обломал меня (я тоже раньше думал, что за станками с ЧПУ может работать полный дибил). Оказалось, что наоборот, знаний и навыков надо больше чем при работе за обычным станком. Правда знания и навыки при этом тоже другие.

c>>Теория сравнительных преимуществ: врач продает программисту свой труд, программист врачу свой.
>>И что плохо в таком подходе?

c>Зависимость от внешнего мира оборачивается низкой обороно-способностью —
c>как и при монокультуре в сельском хозяйстве.

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

>>ты предлагаешь, чтобы врачи писали программы, а программисты — лечили себя?

c>При наличии новых Инструментов.

c>Вообще есть такая наука — науковедение (science of science).
c>В СССР и России ее понятно не было и уже не будет.
c>Революция — это почти (а это действительно очень сильное "почти") всегда появление нового инструмента.

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

c>>>Профессионалы тут не причем! Причина — отсутствие ЛЕГКИХ портативных средств затачивания скальпелей. Появятся такие — не нужны будут твои профессионалы по заточке.
>>Не будут хирурги сами точить скальпели никогда.

c>Это ортодоксальность.

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

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

c>1. Не верно — большинство крутит сами.

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

c>2. Неотъемлемое условие для обращения в сервис — наличие "свободных" денег.

Немного не так. За время пока механики крутят гайки он заработает больше чем заплатит за это.

Случай хобби я не рассматриваю.

--
С Уважением

Hi computer20

>>зачем обычному чайнику [прикладному специалисту] супер-компьтер?

c>Простите, но это хы-хы вопрос.
c>Для исследований.

Ну-ну. Если деньги есть на исследования, то и на обработку данных будут деньги. А если прикладной специалист будет это делать дома, то ему хватит выше крыши и нынешних компов.

>>кто будет рахрабатывать это супер-компьютер?

c>Некорректно: разные части выпускают разные производители.
c>Они же их и разрабатывают.
c>Процы выпускают Intel, Motorola, etc (ну, ни мне вам рассказывать),
c>винты выпускают ...

>>кто будет производить комплектующие для сборки этого супер-компьютера?

c>См. ответ на предыдущий вопрос.
c>Старые фирмы. Возможно появятся новые.

Чтобы начали производить то, что ты предлагаешь, то надо чтобы твоя архитектура стала популярной. Она станет популярной если будет достаточный спрос. Чтобы спрос был надо, чтобы был накоплен критическое кол-во софта. Даже если следовать твоему утверждению, что прикладной софт будут писать пользователи (что очень сомнительно), то надо инстументарий для разработки. Его могут написать только программисты. А они будут писать его только если платформа популярна или им хорошо заплатят или это надо им для собственных нужд. Первый и третий варианты отбрасываем. Значит надо много денег. У тебя их нет. Остаются компании готовые вложить много денег на это. Тут тоже два варианта. Деньги вложат только если платформа популярна или ты убедишь компании в перспективности твоего подхода. Первое отбрасываем. А убедить тебе не получается ни одного даже на этом форуме. Что же говорить о том, что получиться убедить спецов.

>>что пудет писать ОС и софт для этого супер-каомпьтера?

c>Прикладной специалист.

ОК. Предположим что так. Каждую предметную область грубо говоря можно представить как набор понятий и языка для манипуляций этими понятиями. Ты предложил спроецировать понятия на таблицы БД (это получается, что компьютер уже должен содержать СУДБ?). Положим, что программисты могут написать транслятор/компилятор языка предметной области (кстати, а почему это они должны делать?). Но кто будет разрабатывать структуру таблиц БД? И кол-во языков программирования будет не просто большим, а огромным.
В результате получается, что основную задачу опять решают как и сейчас программисты. И не кажется ли тебе, что это все в комплексе будет гораздо дороже чем сейчас?

--
С Уважением

Здравствуйте, FR, Вы писали:

FR>Очень даже было

Тут ИМХО разговор уже пошел в стиле "я не видел, значит этого нет", "у меня не получается, значит это слишком сложно", "я только что задумался, значит никто о таком еще не думал" и т.п.

Hello, creatman!
You wrote on Fri, 09 Feb 2007 06:49:48 GMT:

c> Посмотрите на идею создания языка Java и JVM. Одна из
c> причин, на сколько я помню, была по возможности упростить работу
c> по созданию мультиплатформенных приложений. Уже прошло более 10
c> лет, но разработка приложений стала ничуть не проще

Разработка мультиплатформенных приложений или приложений как таковых? Ты уж определись.
Не вижу никаких особых проблем с разработкой мультиплатформенных приложений на Java. Они работают на массе платформ.

Погружение в маразм.

Разборки, разборки, разборки....


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

А вот за "Все идеи отдадим буржуям" не согласен. Это нужно делать в нашей стране.


Хотел бы сам создать процессор(но это крайне сложно)

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

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


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

Здравствуйте, MikelSV, Вы писали:

MSV>Хотел бы сам создать процессор(но это крайне сложно)

С точки зрения материального обеспечения ты даже не представляешь насколько это просто. Эмуляторов цифровых схем хватает (где брать лицензии, надеюсь, не нужно объяснять ). Если очень хочется именно реальную железку — кит с Xilinx даже в топовом варианте стоит порядка тысячи баксов.

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, creatman, Вы писали:

C>Здравствуйте, creatman, Вы писали:

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

C>>i286 asm,С, HTML,XML/XSL, SQL,PL/SQL, остальным много времени не уделил (php,perl, bison,flex, C++, fortran,MPI).
C>>По одним чуть больше десяти лет, по другим чуть меньше.
C>>Сталкивался и с некоторыми другими вещами, на всегда ПРИНЦИПИАЛЬНО избегал глюкал: js, java, flash.

C>В схемотехнике — вообще нет.

C>По образованию — физик.

C>Текущая должность — программист.

>>Это будет очень важно, если вы хотите двигать свою идею дальше форума.

C>К сожалению да.
C>Люди не мыслят концептуальными понятиями — они либо верят, либо не верят.
C>Либо "нутрят" авторитет, либо нет.
C>К мышлению это не имеет никакого отношения.

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

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, fmiracle, Вы писали:

>>главное в программировании — это не язык на котором программируешь

C>До тех пор, пока программируешь именно на языке.
C>Все языки лежат в рамках одной парадигмы, и будут давать примерно одинаковые социальные "результаты"

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

C>---другие темы

>>>КАКОЙ ФАКТОР Java-ы увеличивает количество сил и времени, необходимых для того, чтобы стать
C>специалистом, до такого значения, которое необходимо для С++?
>>Вот-вот-вот. У тебя нет понимания этого очень важного вопроса

C>Я с вами осторожный (научно осторожный) последовательный диспут веду, а не в мордобое участвую.
C>Надеюсь, что и вы будите вести себя также.

>>Программировать на Java наверное на порядок ПРОЩЕ [выделено мною, computer20] чем на С++ — управление памятью, ПРОЩЕ [выделено мною, computer20] синтаксис, больше проверок компилятора и т.д. и т.п.

C>Не взялся бы утверждать это однозначно.

Можно вот в этом месте конкретнее? Всетаки хочется понять ваш уровень понимаю того о чем вы говорите.
Чем вам не нравится это утверждение? Как я понял у вас нет опыта ни в C++ ни в Java. Какже вы можете об этом рассуждать? Естественно если у вас нет достаточного опыта в обоих приведенных языках, то они вам будут казаться одинаково сложными. Но любой программист Си++, который попробует писать код на Java поймет различия в сторону упрощения в первые 10 минут.

>>Потому что главное в программировании — ...
C>Глубокое понимание функционирования компьютера и программ.

C>Несколько странно: проще — и требует ...

Ничего странного тут нет. Как вам уже говорили не раз — кривые руки языком не исправишь. Я уже упоминал о том, что упрощения языка имеет две стороны медали: светлая — упрощает жизнь хорошему программисту, темная — плодит большое кол-во бесталковых программистов, купившихся на простоту языка, но почемуто забывших подучить теорию Computer Science.

Здравствуйте, creatman, Вы писали:

C>Здравствуйте, computer20, Вы писали:

C>>Здравствуйте, creatman, Вы писали:

C>>Здравствуйте, creatman, Вы писали:

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

C>>>i286 asm,С, HTML,XML/XSL, SQL,PL/SQL, остальным много времени не уделил (php,perl, bison,flex, C++, fortran,MPI).
C>>>По одним чуть больше десяти лет, по другим чуть меньше.

C>>>Сталкивался и с некоторыми другими вещами, на всегда ПРИНЦИПИАЛЬНО избегал глюкал: js, java, flash.

Ну вот и зря что избегали, поэтому и не понимаете разницу между C++ и Java. И как второе упрощает жизнь разработчикам. И также не знаете как flash и js упрощает жизнь web разработчикам и разработчикам игр.

C>>В схемотехнике — вообще нет.

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

C>>По образованию — физик.

C>>Текущая должность — программист.

А где опыт в областях: Общение с клиентами, UI development, Психология? Извините, конечно, но уткуда вам знать что нужно врачам? Пока ваш расчет на врачей любителей воляться под автомобилем и собирать его из комплектующих или врачей любителей разрабатывать информационные системы, не имеет под собой никакой перспективы, как экономической так и технологической.

Здравствуйте, computer20, Вы писали:

C>Здравствуйте, ambel-vlad, Вы писали:

c>>Меня самого подвозил врач, который собрал копейку, варил ее.
c>>Собрал из комплектухи — не сам же он сталь варил, в прокатном цехе стоял и т.д.
>>Сколько таких врачей? 1-2 на миллион населения? Не показатель. Вот я, например, люблю летать (управлять) на самолетах. Но я прекрасно понимаю, что никогда не буду управлять Боингами или Эйрбасами. Потому что это только мое хобби.

C>1. из ТОЙ (крупно блочной) комплектухи собрали бы несравненно более многие
C>2. все время нужно отслеживать какое существует подобие между сборкой легковушки и сборкой
C> компьютера (например сегодня из матери, проца, памяти, винта).
C> Второе легче первого, т.е. сравниваемые процессы не подобны (по сложности).

Да дейстиветельно, возьмем простую операцию: добавить память к компьютеру. Необходимо: открыть крышку корпуса, вставить память в слот. закрыть крышку корпуса. Элементарно! Сколько вы знаете врачей которые делают такую операцию самостоятельно? Я вот знаю некоторых, которые даже для этого вызывают на дом специалиста. Не говоря уже о больницах. Давайте теперь возьмем операцию — сборка компьютера из комплектующих — гораздо проще сборки автомобиля: сколько врачей соберут его сами и сколько по вашему для этого воспользуются услугами специалистов?

Решил потратить всетаки свое время и почитать работу, вот некоторые коменты:

C>Две методологии

C>Компьютер существует для обработки данных — это банально.

Это очевидно!

C>Но данные образуют из себя сложные структуры (деревья, графы). И как следствие развилось две семантики, две методологии работы с данными.

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

Пример с OpenGL абсолютно тут не к чему. Вы знакомы с OpenGL? Вы знакомы с понятием машина состояний? Тоесть первая методология работы с данными, как я понимаю, получается машина состояний? Не понимаю а причем тут нагромождение функций? Пишите на C# и у вас будет нагромождение классов и методов, если угодно. Теперь по поводу ячеек: вы знакомы с двоичным исчислением? Никто не игнорирует тот факт что данные имеют сложную структуру, просто люди работают с данными на разных уровнях. Если вы с трудом разбираетесь в OpenGL, посмотрите в сторону DirectX, там другой (ООП) подход. И заметьте, никто уже последние лет 20 не работает с ячейками и данные описываются сложными структурными типами, советую вам как автору почитать про эволюцию ЯП.


C>Вторая методология исходит из того, что переменные бывают семантически разные, и данные — это прежде всего взаимосвязи. Именно этим подходом человек пользуется, пока не садится писать программу. Он берет листочек бумажки и чертит объекты и связи между ними, указывает, что должно произойти, если изменить часть какого-то объекта. Что мешает применить это в кремнии? Только косность мышления.

Почитайте литературу по схематехнике и поймете, почему в кремнии так и никак иначе. И про двоичное исчисление тоже.

Вы путаете представление данных и работу с этими данными. Кому какая разница как реализованно это в кремнии? Нравится вам рисовать, открывайте Rational Rose, Visio и рисуйте ваши данные сколько вашей душе угодно.

P.S. А где-же функциональный подход работы с данными?

Далее читаю..

Базовый формат
C>Нужен формат файлов базы данных, удобный для воплощения в кремнии. Будем называть его BAF (BAse Format).

Никакой информации... Кому нужен? Зачем нужен? Как это связано с описанными выше методологиями?

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

А если не размещать? Причем тут вобще дыры? Из чего вдруг следует что файл это массив однотипных структур и как это связано с методологиями разработки ПО и врачами?

C> Такая концепция удобна и для обработки традиционными языками программирования. В одних языках, например Pascal, объявляют "file of struct", в других, как в C, загружают файл в память и ссылаются на структуру по ее индексу (очень полезна при этом функция "mmap"). Записи могут быть удалены из таблицы, и места их расположения пригодны для размещения новых записей. Пустые места (далее мы будем называть их дырами) резонно организовать в список (каждая дыра содержит физический адрес следующей). Пусть первая структура каждого файла (далее — первая дыра) не содержит запись таблицы, а хранит указатель на голову списка. Подобное решение дает еще одно преимущество: отсчет номеров записей начинается с единицы, а не нуля, что более естественно для человека. бла-бла-бла.....


И что нового вы тут хотели сообщить? Вся глава про базовый формат посвящена теории организации данных СУБД? Вы свою придумали или в книгах по теории СУБД взяли? если да то в каких? Вобщем дальше читать не стал, еслибы это была ваша дипломная работа то смело можно ставить 2-ку

Здравствуйте, ambel-vlad, Вы писали:

>То есть чем минималистичнее язык тем он лучше? Я правильно тебя понял?

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

Вы вырываете язык из системы — ведь не язык же самоцель, и не программа самоцель.
Самоцель — моделирование (как, например, в моем случае).
Эта задача как система может состоять из совершенно разных компонент с разным их балансом.

c>>Записи в таблицы заносяться любым СКОЛЬ УГОДНО примитивным языком программирования,
c>>являющимся частью всеобщей школьной грамотности.
>>Ты уверен, что врач может знать этот язык программирования?
c>Не "этот", а любой.
>Что значит любой?

Я прелагаю использовать самые примитивные возможности C, Pascal, etc.

>Человек делающий что-то как хобби в 99% будет делать гораздо хуже чем профессионал.

Я предлагаю изменить не человека, а потребность.

c>Специфика предметной области переносится на схему БД.
>На схему БД ты максимум можешь перенести только понятия [!] предметной области. Но чтобы ими оперировать [!] этими понятиями необходим язык

если "язык" не равно "понятие",
то речь может идте только о процессе обработки понятий, выработке новых знаний

c>Я собираюсь оставить от языков самую малость.
>Опиши эту самую малость.

file of struct
a->b

>А для каждой предметной области этот язык свой

неверно — понятия свои, но операторы их обработки одни и те же — 5 шт.:
аналогия, метафора, экземплификация, приведение типичного элемента, построение систематики. Для последних двух операций лучше названий пока, насколько я знаю, не придумали

>Если ты с этим не согласен, то попробуй при помощи медицинских терминов описать процессы в ядерном реакторе.

Это высказывание о понятиях (а не языке) не подкрепляет предыдущего высказывания (которое о языке).

Вы привели терминологическую путаницу.

Кроме того, здесь давно закончилась аналогия с языком программирования.
Я уже писал о метафорах:
метафора — создание свойств у второго объекта [точнее порождение нового объекта] путем
буквального или приблизительного копирования свойств первого объекта
(создаваемые свойства второго объекта изначально отсутствуют).
Пример:
Земля движется ограничено (по окружности) под действием тяготения —
также и монарх должен быть ограничен конституцией [реальный исторический пример аргументации].
Создаются новые свойства монархии [точнее создается новый объект — конституционная монархия].

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

Здравствуйте, ambel-vlad, Вы писали:

>Ты пробовал перекомпилировать 32-битный код на компиляторе с поддержкой 64 бит только для платформы х86?

Нет.
Ты видимо пробовал — на какие трудности ты ссылаешься?

>Не смогут чайники писать проги сами. Почему они сейчас не пишут сами? И причин для изменения существующей реальности пока не видно. Если ты такие причины знаешь — озвучь, пожалуйста.

Написать алгоритм (на языке программирования) и написать программу —
две разные вещи.
Например, все входные данные в расчетных программах я пишу прямо в исходнике —
за то время, пока я напишу пользовательский интерфейс коллеги меня обскачут.
А в исследовательской работе (в отличие от офисной, типа сайта университета и т.п.)
алгоритмы приходится постоянно модифицировать, исследовать.
Прикладной специалист лабуду делает из интерфейса, а не из алгоритма.

"Не смогут" и "не пишут" находится в разных условиях: после появления новой архитектуры и до нее.

Написание прог прикладными специалистами не является массовым явлением,
т.к. средства разработки чрезвычайно сложные: выразительные возможности выражают [ ]
не семантически важные преобразования (что необходимо прикладникам),
а строение инструмента (архитектуру).

"Например в software-ных технологиях (я писал об этом в теме про
http://html60.chat.ru) я объясняю это награмождением средств:
Переход от тегов к интерпретируемым текстам — что это, как не разрыв непрерывности!?
Переход от тегов к скомпилированным вставкам — что это, как не разрыв непрерывности!?

Вставка прокладки на PHP,
единственной задачей которой является вызов библиотеку работы с базой — зачем?
Я уже не говорю о том, что Apache надо проинсталлировать, настроить — зачем?
И это все время, время, время ... силы, силы, силы ...
Не только увеличивается "затрата людей", но "затрата машин" (увеличивается нагрузка на аппаратуру).

И все почему??

Потому что боги, принимающие решение, могут только собирать конструктор из кубиков.
Все попытки, о которых вы говорите, сохраняют эту ПАРАДИГМУ.
Типичным примером такого провола является denwer (dklab.ru)"

>кто реализует их [языки программирования] для твоей платформы?

Уже писал:
сегодняшние производители языков и поклонники конкретных языков.

>вряд ли программисты начнут что-то делать на твоей платформе пока она не станет популярной

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

>И что ты будешь делать на нем такое, чего не можешь сейчас?

Не скажу.

Здравствуйте, ambel-vlad, Вы писали:

c>Хочу довести языки до крайних рудиментов.
>До какой степени? Странно, сейчас наоборот стараются увеличить выразительность языка.

См.
http://www.rsdn.ru/Forum/?mid=2344087

Автор: ambel-vlad
Дата: 09.02.07

http://www.rsdn.ru/Forum/?mid=2344073

Автор: ambel-vlad
Дата: 09.02.07

>предметная область это не только понятия, но и язык манипулирования этими понятиями.

Нет аналогии между языком манипулирования понятиями и языком манипулирования данными.
Я уже писал об этом, говоря про 5 операторов.

Здравствуйте, FR, Вы писали:

C>Вообще есть такая наука — науковедение (science of science).
C>В СССР и России ее понятно не было и уже не будет.
>Очень даже было

Я знаю всего несколько человек.
О массовом применении, или хотя бы массовой известности, речь не шла — и до сих пор не идет.
Хотя на сайте МГУ появилось понятие "индекс цитирования".