LINUX.ORG.RU

SlickEdit 2007


0

0

Вышла новая версия SlickEdit - замечательной кроссплатформенной(Linux, MacOS X, Solaris, AIX, IRIX, HP-UX, Windows) среды разработки на Java/C/C++ со множеством фичей. Из новых возможностей можно выделить:
- поддержка форматирования XML/XHTML;
- подсветка ошибок Java кода "на лету";
- новый диалог поиска членов класса;
- динамическая группировка/разгруппировка блоков кода;
- поддержка Drag&Drop под GNOME и KDE;
- поддержка языка ActionScript;
- улучшена реализация рефакторинга;

>>> Подробности

anonymous

Проверено: Shaman007 ()

Ответ на: комментарий от annoynimous

>Опции - это просто возможность пользоваться псевдонимами - одним и тем же именем для _разных_ утилит :) Это способ увеличить разноообразие. :)

разве slickedit тебя заставляет ими пользоваться? там все это можно отключить

>Это способ увеличить разноообразие. :)

угу отмазались значит

acefsm
()
Ответ на: комментарий от annoynimous

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

Вместо того чтобы раздувать тут флейм лучше скачали бы демку и посмотрели что к чему. Или религия не позволяет ? ;)

sS ★★★★★
()
Ответ на: комментарий от acefsm

> угу отмазались значит

Гуру не "отмазывается", он всегда говорит то, что считает правдой :)

> acefsm

не обижайтесь, просто у меня хорошее настроение, вот я и флужу. Не уходите в отрицание, просто прочитайте и подумайте. Вы станете богаче. A SE - пройдет, как тысячи других вещей в этом мире :)

annoynimous ★★★★★
()
Ответ на: комментарий от sS

> Вместо того чтобы раздувать тут флейм лучше скачали бы демку и посмотрели что к чему. Или религия не позволяет ? ;)

Не, эволюционная принадлежность к отряду анонимосов-гуру-во-всем не позволяет мне осквернить религию деянием скачивания и, о ужас! смотрения :)

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

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

это для вас она темная, для меня наоборот

и еще я не вижу для себя проблемы писать под тем же emacs но только для других языков

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

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

забавно получается, ага?

настоящие джедаи пишут в чем есть и не заботятся о всяких войнах vim/emacs

acefsm
()
Ответ на: комментарий от sS

>> Если этого в емаксе нет, то можно легко написать. Само по себе сворачивание кусков кода есть.

> В этом всё и дело. Всё по отдельности в разных продуктах есть. Есть даже более навороченные "изобразительные" возможности чем в SE. Просто в SE это в одном флаконе и от рождения.

Дело в том, что _мне_ сворачивание ifdef/endif не нужно. Следовательно, эта фича для меня - излишество. Пользоваться я ей не буду, а вот в цену SE её стоимость заложена :)

mv ★★★★★
()
Ответ на: комментарий от annoynimous

>не обижайтесь, просто у меня хорошее настроение, вот я и флужу. Не уходите в отрицание, просто прочитайте и подумайте. Вы станете богаче. A SE - пройдет, как тысячи других вещей в этом мире :)

я прекрасно понимаю вашу мысль

и я знаю что когда нить я больше не буду писать на этом сраном С++ -)

acefsm
()
Ответ на: комментарий от acefsm

> плять читать то умеете, я говорил в стиле таком же

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

mv ★★★★★
()
Ответ на: комментарий от acefsm

> это для вас она темная, для меня наоборот

Дарт Зидиус, ты здесь? :)

> просто использую инструменты которые предназначены и более удобны для определенной задачи

Все падаваны, вставшие на Темный путь руководствовались благими намерениями :)

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

Гуру никого не обзывает, гуру называет вещи своими именами :)

> настоящие джедаи пишут в чем есть и не заботятся о всяких войнах vim/emacs

Настоящие джедаи ничего не пишут, они растят учеников :)

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

>И между прочим, не приписывайте мне то, чего я не говорил. Я рекламирую скриптовые языки. Я говорю, что эта проблема решается поиском и выделением в _потоке_данных. А на чем Вы эту парадигму реализуете - дело Ваше :)

Отлично. Вы будете гонять 2-3Gb через поток ? ;) Сколько раз ? ;)

Угадайте c 3-х раз зачем аффтары поспроцессоров к файлу цепляют хидер ? ;)

sS ★★★★★
()
Ответ на: комментарий от acefsm

> так ну давайте уж тогд рассудительно

> значит когда emacs нагружают всякими ecb+xrefactory(за который еще заплатишь 399$) уже не комбайн?

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

mv ★★★★★
()
Ответ на: комментарий от acefsm

> так тогда получается что вы делаете себе какое то универсальное средство которое делает все и вся, так получается?

Получается, что кому-то нужно ознакомиться с теорией машин и механизмов %)

mv ★★★★★
()
Ответ на: комментарий от mv

>Дело в том, что _мне_ сворачивание ifdef/endif не нужно. Следовательно, эта фича для меня - излишество. Пользоваться я ей не буду

Как это сейчас модно говорить: "Слив засчитан" ;)

Только если что то вам не нужно это не есть минус продукта вообще ;)

Насчёт цены. Следуя вашей логике все продукты, которые стоят $ - плохи а те что >$1000 просто ужасны ?

sS ★★★★★
()
Ответ на: комментарий от sS

> Отлично. Вы будете гонять 2-3Gb через поток ? ;) Сколько раз ? ;)

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

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

Йода вас покидает. Санитары будут делать Йоде успокоительное и Йода будет спать :)

annoynimous ★★★★★
()
Ответ на: комментарий от sS

>> Дело в том, что _мне_ сворачивание ifdef/endif не нужно. Следовательно, эта фича для меня - излишество. Пользоваться я ей не буду

> Как это сейчас модно говорить: "Слив засчитан" ;)

Не по делу. Емакс _может_ сворачивать что угодно, другое дело, что его этому, возможно, нужно будет обучить. Я же не браню авторов SE за то, что там джаббера из коробки нет :)

> Только если что то вам не нужно это не есть минус продукта вообще ;)

Аналогично :))

> Насчёт цены. Следуя вашей логике все продукты, которые стоят $ - плохи а те что >$1000 просто ужасны ?

Нет, после знакомства с xrefactory (для c++) я вознамерился его честно купить, благо средства позволяют. Но т.к. я человек семейный, то вынужден считаться с мнением жены, которая не видит причины тратить $400 , по её мнению, на не понять что :))

mv ★★★★★
()
Ответ на: комментарий от annoynimous

annoynimous, вы напоминаете умственно отсталого.

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

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

ваш тезис о том что SE - кобайн, несостоятелен. он такой же комбайн как emacs, построен на языке расширения Slick-C, и если хотите, представляет из себя аналог закрытого настроенного emacsа, но который работает. закрытость это вопрос отдельный от эффективности.

про культуру и традиции. если раньше, в течении 30 лет программировали на перфокартах/лентах и фортране, и очень гордились именно перфокартами, и своим умением в них дырки делать, я что ? тоже должен "уважать" традиции ?

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

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

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

zort
()
Ответ на: комментарий от sS

неадекватные, всегда когда их припираешь к станке начинают отрицать необходимость ....

zort
()
Ответ на: комментарий от mv

>что там джаббера из коробки нет :

имеет мало отношения к кодированию

>возможно, нужно будет обучить.

ну, на brainfuck'е тоже пожно C++ парсер написать ... теоретически.

zort
()
Ответ на: комментарий от annoynimous

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

ЖЖёш камрад (C) Гоблин.

Мне уж тогда проще _сразу_ сохранить данные для каждого узла в отдельный файл .... и так 10-20 млн. раз ... то есть файлов ;)

Еще раз. Вывод солвера делается под формат _входных_ данных постпроцессора.

К слову сказать у меня солвер хранит данные в собственном внутреннем формате и уже их конвертит в эти самые 2-3Gb ascii. Проблема в том что мне совершенно не хочется еще и _полноценный_ постпроцессор писать (есть узкозаточенный неполноценный, задача которого помочь интерактивно вырезать нужное), всё равно лучше существующих вряд ли напишу. Написан простенький (по возможностям) скриптовый *nix-way-ный (cgi+shell+awk+gnuplot) частично интерактивный постпроцессор, который имеет web-морду но его _гибкость_ и _скорость_ ниже плинтуса на таких объёмах данных. На небольших (до 100Мб) со скоростью более менее. Сделан он исключительно для удалённой работы. Ибо гонять для локальной обработки туда сюда гигабайты между счётным кластером и моим локальным десктопом (рабочий ноут) который часто любит соверщать 3-4 часовые перелёты вместе со мной в командировку смысла не вижу.

sS ★★★★★
()
Ответ на: комментарий от mv

>Нет, после знакомства с xrefactory (для c++) я вознамерился его честно купить, благо средства позволяют. Но т.к. я человек семейный, то вынужден считаться с мнением жены, которая не видит причины тратить $400 , по её мнению, на не понять что :))

Так вы фрилансер ? Ну тогда так бы и говорили ;)

Я разумеется не собираюсь покупать на свои же деньги себе домой станок (ни за какие деньги) ;) Пусть этими Контора занимается ;)

sS ★★★★★
()
Ответ на: комментарий от zort

> annoynimous, вы напоминаете умственно отсталого.

Воистину чуду подобен ребенка разум :)

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

Быдлокодера сие речи есть. Никто нерадивого падавана уговаривать не будет, двери открыты :)

> то что ваши unix-вейные цепочки, это игрушки неграмотных админчегов

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

> про культуру и традиции. если раньше, в течении 30 лет программировали на перфокартах/лентах и фортране, и очень гордились именно перфокартами, и своим умением в них дырки делать, я что ? тоже должен "уважать" традиции ?

На темной стороне изобретатели велосипедов окажутся. :)

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

annoynimous - любитель перфокарт.

>Быдлокодера сие речи есть.

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

>unix лишь был примером для слабых разумом.

это вы слабый разумом. где я был против модульной расшираяемости через стандартизованные интерфейсы ? это компьютеры дорогой, и здесь как нигде, "ВСЯ САТАНА В ДЕТАЛЯХ" а не только в концепциях.

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

а вы, мне втираете про концепцию в виде "unix вей", хотя это чуть ли не самая неэффективная реализация это концепции.

самое смешное, что наш великий враг винда, а также файрфокс, построены на основе COM/XPCOM, что и является реализацией концепции "быстрых соединяющихся компонентов", и виндузятники их соединяют в Windows Scripting Host, с отсутствием потерь на парсенье текста. но закрытая природа винды, отсутствие документации, ориентация на казуалов, залажала всю идею хороших инженеров.

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

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

вы же, сказав "unix лишь был примером для слабых разумом. Иные называют их интерфейсами" , фактически сказали что COM/XPCOM рулит.

ЗЫ имхо, то что я сказал сложно переварить типичному юниксойду, поэтому даже не надеюсь на понимание.

zort
()
Ответ на: комментарий от zort

добавлю, perl и python - компонентная замена пайпам.

zort
()
Ответ на: комментарий от zort

> вы же, сказав "unix лишь был примером для слабых разумом. Иные называют их интерфейсами" , фактически сказали что COM/XPCOM рулит.

Йода не говрил такого. Интерфейсы бывают не только объектно-ориентированные, но и функциональные. Релизация программы в форме композиции функций, действующией на входные данные дает иным джедаям необозиримые преимущества. Йода видит рост интереса к функциональной парадигме. А почему? А потому, что в ней можно эффективно использовать параллелизм, поскольку функцинональная парадигма гарантирует отстутсвие побочных эффектов.

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

Йода видит потуги иных падаванов передавать в одном адресном пространстве 3-х мерные матрицы 1000х1000х1000 и преобразовывать их. А решение - генереровать их по описанию. Тяжело? Да, но только так и можно. Только таким способом удается искать собственные числа у матриц с десятком-другим миллионов столбцов (строк).

> Windows Scripting Host

это не замена bash, а скорее аналог perl и/или python. Впрочем, падаван это и сам понимает:

> добавлю, perl и python - компонентная замена пайпам.

annoynimous ★★★★★
()
Ответ на: комментарий от annoynimous

>Йода видит рост интереса к функциональной парадигме. А почему?

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

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

в ФП я разбираюсь не хуже вас. вы произносите стандартные фразы, которые ничего на практике не значат. Эксплуатировать преимущество ФЯ в параллелизме путаются уже ~30, и научных учёных это не сильно хорошо получается, к примеру бумаги по STM в haskell датированы этим и прошлым годом, и STM это параллелизм через ограничение, shared state алгоритмы будут усёравно эффективнее, и пока HPFORTRAN заруливает в этой области. надеемся на fortress, но пока эти идеи всё ещё остаются идеями. на erlang у меня тоже ответ найдется.

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

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

>А решение - генереровать их по описанию.

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

>это не замена bash, а скорее аналог perl и/или python

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

>Йода не говрил такого

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

zort
()
Ответ на: комментарий от zort

>> что там джаббера из коробки нет :

> имеет мало отношения к кодированию

Сворачивание директив препроцессора тоже

>> возможно, нужно будет обучить.

> ну, на brainfuck'е тоже пожно C++ парсер написать ... теоретически.

Т.е. вы подкоркой чуете, что от slick-c в se толку мало, поэтому экстраполируете свои страхи на elisp?

mv ★★★★★
()
Ответ на: комментарий от zort

s/в цепочку могут - вполне функциональны/в цепочку могут быть вполне функциональными/

zort
()
Ответ на: комментарий от sS

> Так вы фрилансер ? Ну тогда так бы и говорили ;)

Нет, я не фрилансер. Не понимаю, из чего такой вывод сделан :)

> Я разумеется не собираюсь покупать на свои же деньги себе домой станок (ни за какие деньги) ;) Пусть этими Контора занимается ;)

Для того, чтобы Моя контора этим занималась, мне место работы сменить надо %)

mv ★★★★★
()
Ответ на: комментарий от mv

>в цепочку могут - вполне функциональны

я не говорил что SE расширяемей емакса. я говорил что elisp медленный и C++ парсинг мозиллы закончит к 2050 году.

в SE и xref парсинг написан на с/c++, но в SE коннекшен к нему быстрее потому что обмен может происходить в быстрых структурах данных.

ты ещё еще про ecb(как то так вроде назывался) вспомни.

>Сворачивание директив препроцессора тоже

это применение гуманитарной логики - как хочу так и понимаю.

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

zort
()
Ответ на: комментарий от zort

s/в цепочку могут - вполне функциональны/Т.е. вы подкоркой чуете, что от slick-c в se толку мало/

zort
()
Ответ на: комментарий от zort

>> Сворачивание директив препроцессора тоже

> это применение гуманитарной логики - как хочу так и понимаю.

> сворачивание директив имеет отношение к языку программирования.

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

> jabber к обмену сообщениями. при этом если отделить джаббер от ide потерь в удобстве не будет, если отделить сворачивание директив, то будет точно.

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

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

mv ★★★★★
()
Ответ на: комментарий от annoynimous

Так вы не ответили на этот вопрос:

так и еще тогда получается что anjuta,kdevelop тоже для ламеров и те кто их делают 3.14здюки, так получается?

интересно очень просто -)

acefsm
()
Ответ на: комментарий от mv

>Можете назвать язык, в стандарте

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

вы сифилисом в последней стадии не больны ?

>"Я, Вася Пупкин, привык жамкать кнопки для автокомплита

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

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

zort
()
Ответ на: комментарий от mv

>> имеет мало отношения к кодированию

>Сворачивание директив препроцессора тоже

Щаз.Препроцессор (по крайней мере в C/C++) вообще-то это часть языка. В Java - внешняя сущность (расширение) но имеющая непосредственное отношение к _кодированию_

sS ★★★★★
()
Ответ на: комментарий от mv

>> Так вы фрилансер ? Ну тогда так бы и говорили ;)

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

Из необходимости покупать себе "станок" на зарплату ;)

sS ★★★★★
()
Ответ на: комментарий от mv

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

Кроссплатформенный код писали ?
Это кстати далеко не единственное применение директив препроцессора

Вот вам примерчик _маленького_ проектика:

ss@toshiba:~/Work/OpenCFD-CSP$ cat *.c* *.h* */*.c* */*.h* | grep '#' | wc -l
1926
ss@toshiba:~/Work/OpenCFD-CSP$ cat *.c* *.h* */*.c* */*.h* | grep '#if' | wc -l
462
ss@toshiba:~/Work/OpenCFD-CSP$ cat *.c* *.h* */*.c* */*.h* | grep '#else' | wc -l
204
ss@toshiba:~/Work/OpenCFD-CSP$ cat *.c* *.h* */*.c* */*.h* | grep '#define' | wc -l
624

ЗЫ: Кстати OpenMP в C/C++ реализован именно как директивы препроцессора

sS ★★★★★
()
Ответ на: комментарий от acefsm

Йода вернись!

нам нужны такие же подтверждения безграмотности как и "препроцессор к языку отношения не имеет"

zort
()
Ответ на: комментарий от zort

> нам нужны такие же подтверждения безграмотности как и "препроцессор к языку отношения не имеет"

Йода не потакает развлекающимся всуе.

И Фотографию сгенерить может Йода по ее сжатому образу. Хранить можно в десятки раз меньше. Но зашоренный падаван не хочет думать головой, он считает, что все приемы уже изучил :)

Рефакторинг - слово придуманное программистами, потому что интерфейсы их на C/C++ негибки и слишком зависимы от остальной части программы. Сила unix-way в том, что вместо рефакторинга проще и быстрее переписать все. Но падаваны слепы в своей гордыни и глумятся над маленьким Йодой :)

А Йода пользует функции, написанные на Фортране тысячи лет назад

annoynimous ★★★★★
()
Ответ на: комментарий от zort

смешно то, что и там на Slick нападали. gr_buza сыграл роль необразованного линуксойда, а los_nikos роль умственно отсталого ортодоксального, отрицающего всё, что как он думает виндовое.

zort
()
Ответ на: комментарий от annoynimous

>И Фотографию сгенерить может Йода по ее сжатому образу

то есть йода предлагает передавать фотографию от модуля к модулю,(от функции к функции, которые в разных модулях,если хотите) предварительно безпотерно сжав её, а потом разжав?

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

>Сила unix-way в том, что вместо рефакторинга проще и быстрее переписать все

сила unix-way в том что не находится дебила, который станет таким способом писать что то серьёзное, большое и дорогое. поэтому и переписать проще. Я надеюсь мозиллу, йода юникс веем на считает, а считает юниксвеем пайпы и процессы, потому что юникс вей не имеет монополизма на "расширяемость и композицию составляющих"

>Рефакторинг - слово придуманное программистами

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

>А Йода пользует функции, написанные на Фортране тысячи лет назад

это не прощает Йоде попытку, аргументировать недостатки интерфейсно-модульной архитектуры, достижениями в "неявном параллелизме ФЯ" которые ещё только исследуют.

zort
()
Ответ на: комментарий от annoynimous

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

Ударился головой мастер наш.

r ★★★★★
()

Какое все же гавно эти сликэдиты, со студиями. Кто нить тут хоть раз под ядро писал??? Распаковываешь исходники ядра находишь в ядре файлик tags ну или ctags -R. :set tags=...,/path/to/kernel/source и наслаждаемся автокомрлитом и поиском по тегам в vim. В имакс аналогично. А уж если вызовы функций завернуты в макросы, то сликэдиты ну просто мега удобный автокомплит имеют. В виме просто мегавесчи делаются добавлением трех строчек в конфиг. Короче ну вас всех...

anonymous
()
Ответ на: комментарий от anonymous

>Распаковываешь исходники ядра находишь в ядре файлик tags

Где вы такие ядра берёте ? ;)

hint: размер файла тегов для ядра, сделанных ctags примерно 70Mb

sS ★★★★★
()
Ответ на: комментарий от sS

Как ни странно с kernel.org... Хотя я делал pcaman -S ... Кстати вим в тегах для ядра ищет довольно быстро.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.