實驗IDE概念

Question

我有興趣爲一個側面項目構建一個新樣式的IDE。主要是爲了消除類固醇IDE上的正常記事本。我正在尋找一些已經嘗試或者你已經看到（或不是）看起來很酷並且在IDE中有用的東西的靈感。的事情，我可以了是：

http://digitaltools.node3000.com/blog/1052-field-experimental-programming-suite

http://www.cs.brown.edu/people/acb/codebubbles_site.htm

Answer 1

安德魯·柯（原CMU，現在教授ü衝）集中了他論文對允許人們通過詢問調試「爲什麼事發生「或」他爲什麼沒有「。該項目被稱爲WhyLine，他甚至有一個Java版本。

Answer 2

跨網絡的交互代碼如何變化？因此，您對代碼進行了更改，並且更改會自動在您的夥伴機器上更新。可以爲一些有趣的開發技術。可能會導致完全混亂，但嘿！這是個主意！

編輯：我會在此擴大。處理衝突時，像SVN或TFS這樣的當前倉庫系統可能會變得很煩人。如果其他開發人員所做的更改可能會立即反映到您的系統中，可能會以某種方式進行突出顯示，那麼知道哪些內容可能會更容易理解。

此外，當我編輯一個類的某個函數並且另一個開發人員向類中添加一個函數時，真的很痛苦，因此TFS檢測到衝突，我必須手動解決它。最酷的將是獲得鎖而不是特定文件但是具體範圍的能力。所以我可以檢出一個函數並將其餘的文件打開以進行編輯！

Answer 3

我可能是一個討論這個問題的人，因爲我發現使用IDE來編程，例如在手臂上使用鉛筆編程，但是我認爲可以獲得圍欄邊緣的視角。人們想出的任何有趣或實驗性的想法仍然需要處理開發人員工具的基本需求。

IDE通常是某種類型的編輯器，調試器和編譯器。因爲這些都是工具的三個不同的部分，我會通過他們seperately運行

以下是我從一個編輯

1. 快想。我從不想等待事情加載。永遠。
2. 給我強大的方法來操縱和跳轉代碼。我不關心學習曲線，當它是我平均每天使用10小時的工具時，另一方面是我不想浪費時間去熟練使用功能不強大的工具。
3. 給我一個體面的方式來打開文件。打開的文件對話框不夠好，項目樹也不夠好。
4. 很好的支持讓很多東西同時打開。我有一個27英寸的屏幕，選項卡遠遠不夠，目前我住在分割，但它不會很難提出更好的東西。
5. 從來沒有讓我在編輯代碼時觸摸鼠標。如果你給我一個可視化設計師，那麼最好讓我在打字的時候更有效率，同時產生與我一樣靈活的代碼能夠用文字製作。我還沒有找到一個這樣做的視覺設計師，我曾經使用過的每一個都基本上降低了學習如何做事的標準，但是讓您在可維護性和靈活性方面付出了沉重的代價。如果用於嚴肅的目的（即不僅僅關注質量和不關心質量），我會考慮通過繪製圖像來編程的每一個編程示例。
6. 自動重構。我現在在使用vim，我想念的一件事是能夠從其他方法中提取方法，或者點擊按鈕來重命名某些內容，並且使用該工具的工作方式感到安全。
7. 代碼分析。我想在發生語法錯誤時看到它們，看看我是否輸入了冗餘代碼，或者看看有沒有更好的方法去做某些事情的建議。
8. 偉大的測試賽跑者。我練習TDD，而差勁的測試選手將我推上了牆，因爲它對我所做的每件事都有如此的影響力。

我想從一個調試器

1. 一個REPL。當我被視覺工作室困住時，這讓我瘋狂，而且我可能花更多時間在團隊中的其他人身上。調試器的重點在於能夠探索執行過程中發生了什麼，如果我不能輸入任意代碼並查看它的計算結果，我覺得我有一隻手綁在背後
2. 改變的能力代碼在運行，雖然有一個體面的REPL和語言，這種照顧自己
3. 在執行中前後移動的能力。
4. 速度，不要讓我等待
5. 在代碼中跳躍的好方法。如果我在第1行，並要跳轉到500線，看看是怎麼回事，我應該能夠做到這一點

我從編譯器

1. 速度，至少要在開發模式。谷歌去能夠在毫秒內在筆記本電腦上編譯500,000位loc，這正是我所說的。如果語言需要編譯，每秒鐘注意編譯器輸出只會讓你無論做什麼都更難（追蹤bug，測試功能，運行測試等）
2. 你需要某種方式來掛鉤到執行前和執行後的任意方法中，或者以更一般的方式預處理代碼文件（想想lisp reader宏）。如果你不能用語言來做，你需要能夠用編譯器
3. 良好的分析。告訴我在編譯時搞砸了哪裏，如果你之前無法捕捉它，那麼
4. 透明度。我真的不想知道它在那裏，除非我直接與它互動。

我有什麼

目前，我使用vim，這給了我1，2，3（含fuzzyfinder.vim/rails.vim），4，5，和8（含syntastic非常差vim的）。我沒有重構或代碼分析，我真的很想念它，但IMO更值得權衡。

調試，我使用ruby-debug，這真的不是很好。基本上你得到1，2（更多的原因，然後紅寶石調試），3，但多數民衆贊成它。

不要再使用編譯器（感謝上帝），但在使用7年後（至少在專業上）不使用編譯器真的強調了它們對開發過程的可怕影響。

Answer 4

Zero Button Testing是我的項目。

Answer 5

，我加進來的想法是：

TouchDevelop，實時和基於網格Continuous Integration，Formal Verification（Why3，ITI0060）