![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
"
Why are programming environments still so primitive?
In different ways, Mathematica, Genera, and Smalltalk put almost every other programming environment to shame. Atom, Sublime Edit, and Visual Studio Code are neat, but they do not represent a great improvement over TextMate? circa 2007. Emacs and Vim have advanced by even less.
Why can't I connect my editor to a running program and hover over values to see what they last were? Why isn't time-traveling debugging widely deployed? Why can't I debug a function without restarting my program? Why in the name of the good lord are REPLs still textual? Why can't I copy a URL to my editor to enable real-time collaboration with someone else? Why isn't my editor integrated with the terminal? Why doesn't autocomplete help me based on the adjacent problems others have solved? "
" >Why are programming environments still so primitive?
This guy should try working with plan9 and acme for a few months. Author, if you're reading these comments, you should install 9front, spend a weekend grokking it and becoming comfortable in a workflow there, then set up a Linux VM with vmx(3) and a 9P mount to your host system to get your Real Work done while continuing to learn about the plan9 model. Be prepared for your entire workflow to be turned on its head and to have to find creative ways out of your problems. Maybe today is one of those days where you change your life in a big way :) " [2]
ricardobeat 4 hours ago [-]
> Why can't I connect my editor to a running program and hover over values to see what they last were? Why isn't time-traveling debugging widely deployed? Why can't I debug a function without restarting my program? Why in the name of the good lord are REPLs still textual? Why can't I copy a URL to my editor to enable real-time collaboration with someone else? Why isn't my editor integrated with the terminal? Why doesn't autocomplete help me based on the adjacent problems others have solved?
I think all of these are possible already in VSCode/Atom, and especially true if you’re doing reactive UI programming for the web - time travelling, improved REPL, live debugging are all there. A very good spot to be in :)
munin 1 hour ago [-]
> Why doesn't autocomplete help me based on the adjacent problems others have solved?
Doesn't the Facebook editor / autocompleter do that? I guess it's not available to anyone outside Facebook?
> Why can't I connect my editor to a running program and hover over values to see what they last were? Why isn't time-traveling debugging widely deployed? Why can't I debug a function without restarting my program?
print debugging is extremely versatile and the market has spoken that, apparently, nothing else has the same expressive power to overhead trade-off. I have a few theories: tool usability sucks (looking at you gdb), debugging and writing code are two different disciplines so if you can stay in the same modality (writing code) to do debugging it's one less thing that changes from under you, print debugging is versatile and can apply to everything from embedded to mobile to cloud to HPC. print debugging gets a lot of scorn but (if you want an appeal to authority) if you read "Coders at Work" no "famous" programmers use debuggers, they all use(d) print debugging.
reply
melling 44 minutes ago [-]
All 15 of them?
The market has spoken, programmers want free stuff, and they’re happy doing it the old fashioned way.
Except for those who aren’t content:
[Insert videos from Bret Victor here]
Lighttable is another attempt that comes to mind:
http://www.chris-granger.com/lighttable/
reply
munin 8 minutes ago [-]
From my direct, personal, experience, it goes something like this:
"Don't you want better tools?" I'll ask
"Of course!" the programmer replies (note sometimes this is a conversation with myself) "but I don't want to pay anything for it" they caveat.
"That's no problem," I reply, "as long as it will make your life better."
"Well, that sounds good, but I also don't want to have to learn anything new."
"That..."
"Also, it has to just work from day one, if it doesn't quite work as soon as I touch it, I'll swear off it forever and go talk badly about it on twitter and hacker news."
"Ah..."
"Also, it has to work with every use case I can think of. Multi-threaded, GUI, deployed to HPC clusters running RHEL6 and also Docker containers running CoreOS?, and it should be able to help me be productive in either JavaScript? or s390 assembler. Also it should take no time to set up, and start giving me answers straightaway."
"Hm..."
"You know what, the methods I already have already satisfy all of these requirements and as a bonus, I don't have to learn anything new in order to use them. I spend enough time learning new frameworks to write software, why would I spend more time learning frameworks to debug software?"
"Because you spend more time debugging software than writing software?"
"Honestly the process of debugging, and the process of writing, have become so intertwined in my thinking, that distinction between them seems arbitrary and pointless."
"Thanks for your time."
reply
---
"autocomplete engine(!), go-to definition, hover type definition"
---
curiousDog 2 days ago [-]
I haven't been keeping up with Go much these days but is there proper debugger support now? Or is it still a half-broken experience?
reply
Groxx 2 days ago [-]
IMO: very much still half broken. Calling functions is still experimental[1] and in my experience has yet to work even once, there's no display formatting options (afaik) so you are often looking at a chunk of bytes instead of something useful (after diving several times more layers deep than other debuggers require), and you pretty often can't view memory that's in scope at another call stack location without going to that location. All of which gives you a pretty crippled experience, especially as it makes conditional breakpoints extremely limited in use.
That said, it's mostly just half, before it was like 3/4 or worse. It has improved in stability (I haven't had it randomly disconnect at all since late Go 1.9 days, but I haven't pressed it hard at all either) and GoLand?'s integration works well and is mostly fast. It just can't do anything except set breakpoints and view memory.
[1]: https://github.com/derekparker/delve/blob/master/Documentati...
reply
org3432 2 days ago [-]
If you use Goland 2018 it's pretty seamless, there are a few things missing like being able to get ptr addresses and view values in hex, and it's a little laggy compared to VS but not bad.
reply
pureadrenallen 2 days ago [-]
I've had really good luck using delve with vs code. Easy setup and good experience overall
reply
---
jimsmart 30 days ago [-]
There’s a tool called fix, it’s already part of the standard Go distribution. In the past (mostly pre 1.0, IIRC?), it’s used to apply changes to one’s codebase when migrating between Go releases that introduce incompatible changes.
zapzupnz 27 days ago [-]
Can it be used in editors, say VS Code, to provide fix-its or suggestions for improving code on a line-by-line basis? If so, that sounds great. A lot of languages are missing this in their standard distributions and devs must rely on third-party offerings.
---
matklad 17 hours ago [-]
IntelliJ? predates Roslyn. While it’s not a full compiler (doesn’t do codegen), it naturally does all the front-end bits which are required for IDEs.
Note that “incremental parsing” is a nice to have, but is not required for IDEs. What is required are lazy name resolution and lazy type inference.
reply
---
"The initial uses of IntelliCode? are conservative; it provides smarter IntelliSense? completion suggestions by knowing which suggestions are more likely to be used, based on how other projects use the same APIs."
---
"The lexing/parsing that is required for highlighting is easy to make incremental for all sane programming languages.
for LL(star) grammars, adding incrementality is completely trivial (i sent patches to ANTLR4 to do this)
for LR(k) grammars, it's more annoying but possible (tree-sitter does this)" -- [3]
---
" With VS and C#, I can hit ctrl+space and get a list of absolutely everything that's in the contextually relevant public API. So much faster than introspection. If I'm using an object initializer to instantiate something, I can hit ctrl+space inside the object initializer to get a list of all the available public properties -- no typing the names required. No having to remember the order of arguments of methods, or even their types. Autocomplete means I can usually get away with somewhere between zero and three keypresses to get exactly what I want highlighted in the intellisense. "
---
"code navigation, refactoring, and basic editing"
"easy and good-looking two-panel diff and blame"
---
"The Beef IDE supports productivity features such as autocomplete, fixits, reformatting, refactoring tools, type inspection, runtime code compilation (hot code swapping), and a built-in profiler"
---
brundolf 2 hours ago [-]
I used RLS 1.0 (through the VSCode RLS plugin) for a year or so before discovering rust-analyzer, and I just want to say, even in pre-alpha it is an astonishingly huge improvement. If you do Rust development, do not wait to upgrade. Type checks are instant. Inferred types get previewed inline, also instant. Autocomplete works as expected. Type errors are localized, which might have been my biggest frustration with the old RLS. In terms of developer experience it's like using a whole other language.
reply
What is its relationship with RLS?
Rust had a language server for quite some time now — the RLS. RLS and rust-analyzer use fundamentally different architectures for understanding Rust. RLS works by running a compiler on the whole project and dumping a huge JSON file with facts derived during the compilation process. rust-analyzer works by maintaining a persistent compiler process, which is able to analyze code on-demand as it changes. Concretely, after every keystroke RLS looks at every function body and re-typechecks it; rust-analyzer generally processes only the code in the currently opened file(s), reusing name resolution results if possible.
rust-analyzer started as an experiment and a proof-of-concept, but today it is becoming increasingly clear that:
rust-analyzer already provides a better experience than RLS for many users.
rust-analyzer is further ahead on the road towards the envisioned end-state of a fully on-demand, fully incremental Rust compiler.
---
dvdt 2 days ago [–]
I completely agree with the point about integrated REPL/IDE, and wanted to share some of the combinations I have used in the past, since it can be a concrete getting started point for those who are curious. Some of these are not literally repls, but IMO give a similar experience.
reply
---
simion314 14 hours ago [–]
>Can you please list the other 90% of must have capabilities for day to day development ?
reply
pjmlp 14 hours ago [–]
And a couple of other stuff, basically the kind of goodies one gets with Visual Studio Enterprise.
reply
---
pjmlp 11 hours ago [–]
And I consider programming languages not designed with IDE tooling in mind a design smell for the said programming language.
reply
pjmlp 11 hours ago [–]
Naturally it can, but it will always be an half baked experience, which is why languages like Python and Ruby are still miles away to replicate Common Lisp and Smalltalk development experience.
I rather prefer C++ and Java than any of those "I don't need IDE" languages.
I have been using IDE based languages since I became a Borland customer around 1991, and while XEmacs allowed me to survive without IDEs to the point that I still remember most of my way around ELisp, I don't miss those days.
reply
NateEag 7 hours ago [–]
Also worth pointing out that even static languages often have escape hatches into metaprogramming that defeat tooling.
I've seen Java codebases use reflection heavily enough to utterly confuse the IDE.
reply
simion314 5 hours ago [–]
Yes, just to add the information in case someone is wondering, for example PHP has "magic" functions , I do not use this feature but is used by ORM libraries to make it easy to access table columns. But using PHPDoc I can specify the existence of this columns and then all the warnings are gone and I can get auto-completion help(this helps a lot to improve coding speed and can catch errors if you put a type in a table column name.
This will not work for stuff that is random object from a JSON but so far I never worked with random data.
reply
---
" Why are programming environments still so primitive?
In different ways, Mathematica, Genera, and Smalltalk put almost every other programming environment to shame. Atom, Sublime Edit, and Visual Studio Code are neat, but they do not represent a great improvement over TextMate? circa 2007. Emacs and Vim have advanced by even less.
Why can't I connect my editor to a running program and hover over values to see what they last were? Why isn't time-traveling debugging widely deployed? Why can't I debug a function without restarting my program? Why in the name of the good lord are REPLs still textual? Why can't I copy a URL to my editor to enable real-time collaboration with someone else? Why isn't my editor integrated with the terminal? Why doesn't autocomplete help me based on the adjacent problems others have solved? " -- https://patrickcollison.com/questions
---
pjmlp 12 hours ago [–]
Sadly I am spoiled by Delphi, C++ Builder, VC++, D, Eiffel,...
reply
---
i havent read this yet: https://vvvvalvalval.github.io/posts/what-makes-a-good-repl.html
---
" Efficient text editing is nice. But I spend a lot of time jumping between files, looking up definitions, reading documentation, tracing through code, debugging, comparing tests and regular code, etc. Plus all of the features that you expect: (colorblind-friendly) syntax highlighting, syntax highlighting, linting, etc. This is where the package pain comes in. I don't want to figure out how to configure the cross product of "every single IDE feature that I need" and "every single language that I use." I gave up. It's too much. I want my environment to either do it by default, or install a single plugin per language and never think about it again.
I'm not sure how Emacs can get "more modern," because being modern would likely start from the premise that you'd need to allow the core innovation of IDEs. They provide a pluggable framework to get uniform behavior across every language that you use. That ship sailed in Emacs - how do you move away from 40 years of "we ship a vanilla experience and you customize your environment completely to your own liking"?
reply
rightbyte 2 hours ago [–]
I really like using Emacs but as soon as I touch a big project I need a point and click friendly IDE with refactoring/smart search support to keep my head from spinning. It would be great with some vanilla autocomplete with a language server thing that "almost just works".
reply "
---
jakear 1 day ago [–]
What's the development experience scene like for Rust GUIs? In my experience developing Electron apps there are a a couple major plusses that I'm not sure Rust can compete with, based only on my limited knowledge of the ecosystem:
reply
raphlinus 1 day ago [–]
I've talked up the strengths, you've brought up the big weaknesses. I think there is some interesting work on both of these fronts, but the developer experience situation is very primitive so far by comparison.
Compile times have been getting better. For reference, on my machine an incremental build of Runebender is 2.3s. Part of this reflects some choices we've made to use platform capabilities rather than build the entire stack ourselves.
reply
pornel 21 hours ago [–]
DevTools? is the killer feature.
I've developed a Gtk GUI in Rust recently. It wasn't bad, but I probably won't use it ever again. When I'm debugging a UI, I want to right-click it, select Inspect, and be able to tweak everything live.
DevTools? is such a force multiplier, that I'm confident I can quickly and reliably develop a whole GUI from scratch, with custom layout animations and bells and whistles using JS+CSS. I have zero confidence in doing anything in Gtk or Cocoa beyond dumping static pre-built controls in a window. The cycle of editing blindly, recompiling, and re-running is the old paradigm that I don't want to return to.
reply
---
we should be able to do stuff like this:
https://r4ds.had.co.nz/workflow-basics.html
---
" To be useful, debuggers need help from the compiler in the way of type information — but this information has been historically excruciating to extract, especially in production systems. (Or as Robert phrased it concisely years ago: “the compiler is the enemy.”) And while DWARF is the de facto standard, it is only as good as the compiler’s willingness to supply it.
Given how much debuggability can (sadly) lag development, I wasn’t really sure what I would find with respect to Rust, but I have been delighted to discover thorough DWARF support. This is especially important for Rust because it (rightfully) makes extensive use of inlining; without DWARF support to make sense of this inlining, it can be hard to make any sense of the generated assembly. ...
Gimli and Goblin
Lest I sound like I am heaping too much praise on DWARF, let me be clear that DWARF is historically acutely painful to deal with. The specification (to the degree that one can call it that) is an elaborate mess, and the format itself seems to go out of its way to inflict pain on those who would consume it. Fortunately, the Gimli crate that consumes DWARF is really good, having made it easy to build DWARF-based tooling. (I have found that whenever I am frustrated with Gimli, I am, in fact, frustrated with some strange pedantry of DWARF — which Gimli rightfully refuses to paper over.)
In addition to Gimli, I have also enjoyed using Goblin to consume ELF. ELF — in stark contrast to DWARF — is tight and crisp (and the traditional C-based tooling for ELF is quite good), but it was nice nonetheless that Goblin makes it so easy to zing through an ELF binary.
" -- [4]
https://github.com/gimli-rs/gimli
---
" Zig's compilation is lazy. Only code which is actually reachable needs to typecheck. So if you run zig test --test-filter the_one_test_i_care_about_right_now then only the code used for that test needs to typecheck. This makes it much easier to test quick changes and to incrementally refactor code. " -- [5]
---
" one of the core concepts for an IDE are references and definitions. A definition a like let foo = 92; assigns a name to an entity which can be used down a line. A reference like foo + 90 refers to some definition. When you ctrl-click on reference, you go to the definition. ... some things are both!
struct S { field: i32 }
fn process(s: S) { match s { S { field } => println!("{}", field + 2) } }
In this example, the second field is both a reference to the field: i32 definition, as well as a definition of a local variable with the name field! Similarly, in
let field = 92; let s = S { field };
field conceptually holds two references — one reference to a local variable, and one reference to a field definition.
"
---
bluejekyll 8 hours ago [–]
One of the things that made me so excited about Rust when I first used it was the capabilities of the Rustdoc system. The built in examples that are also unit tests, the ease of just using markdown... and now the linking is even simpler. It’s one of my favorite things about the language, and I think is why so many crates have such good documentation, because it’s easy to do. (and it’s tested and validated so you know it’s right!)
reply
0-_-0 7 hours ago [–]
Not directly related, but when I was learning programming back in highschool (before the Internet) what made it easy was the built in help in Turbo Pascal. You could press F1 over any function or keyword and you were given a detailed description and example of usage. Learning C later using the K&R book and Google was a huge downgrade. Even today I think that language help built into the IDE should be a basic functionality.
reply
Boulth6 4 hours ago [–]
I've seen that with Delphi. The unique factor was that the examples were not a basic call of the function but an actual real world practical sample that usually solved the problem one was looking for.
reply
geoelectric 1 hour ago [–]
I was a Delphi programmer for a few years, professionally, when it first came out in the 90s. I worked with their developer products (and for Borland directly on Delphi/Kylix/C++Builder, eventually) until the mid-2000s. I've never seen the match of Borland's docs, before or since, particularly as integrated with the IDE's coding features.
There are a number of programming languages and APIs with excellent documentation, but theirs were above and beyond.
reply
identity0 5 hours ago [–]
In vim if you press K it will bring up the man page for the word under your cursor. It was very useful when learning C, considering that most libc functions have helpful man pages.
reply
imron 2 hours ago [–]
Note for people trying this at home, vim is case sensitive.
I still regularly use this feature to look up libc and other things. You can also type 2K to go to ‘man 2’, or 3K to go to ‘man 3’ etc.
reply
JNRowe 2 minutes ago [–]
And for the sake of completeness, it is not just for man pages either. vim simply calls 'keywordprg' with the word under the cursor, so you can use whatever you feel like. Open a browser tab on your favourite documentation, display an ERD, pop open a picture of a kitten, …
Many filetype plugins come with pre-configured 'keywordprg' settings. Including some non-programming filetypes like git which will execute `git show <word>`, which is great if you're the type of person who often references commits in other commit messages.
LandR? 6 hours ago [–]
This is done quite nicely with clojuredocs being intergrated into Cursive / Intellij.
I hover over a Clojure function in INtelliJ? and I get a pop up of the clojuredocs with description and example usages for that function.
It's great and I don't know why more IDE's don't do this. Why isn't VS linked to the MSDN for C# / .NET ? SO I can get the information for that function / class / library etc straight in my IDE!
reply
trevyn 6 hours ago [–]
Bringing it back, this works great with Rust and VSCode and rust-analyzer: Any function in any crate shows its doc comment complete with markdown formatting when you hover over it.
reply
CryZe? 2 hours ago [–]
And you can assign a hotkey to open the docs in the browser for the symbol under the cursor.
reply
---
I also love that it is consistent between projects. The fact that I can just go to https://docs.rs/chrono for any public project and have a consistent interface for reading and navigating is huge.
Of course this is somewhat fickle and makes competing documentation generations harder to get started but as a user when rustdoc is really good it is a nice benifit.
reply
tasn 6 hours ago [–]
I also like Rustdoc, using markdown and the new linking improvements. It's much better than learning yet another DSL. However, there's one thing I find annoying, and that's the lack of a structure for parameters.
Following the `# Arguments:` convention is redundant (I get it's petty, but I'm annoyed every time I write it), but more than that it's error-prone and limiting. Because arguments names are just a convention that's not strictly enforced, it's not automatically checking the naming is correct, and it limits the ability of tools like cbindgen and flapigen (love them both) to transform param specific docs.
reply
Rusky 6 hours ago [–]
I've seen the argument (not sure if this factored into rustdoc's design or if it's just someone's opinion) that structured per-parameter docs tend toward useless boilerplate, e.g. "foo: a foo object," while a holistic description of the function itself is easier to make useful.
reply
steveklabnik 6 hours ago [–]
I don't know if it really factored into rustdoc's design since it was already built when I came to Rust, but when I was part of the team responsible for rustdoc, I did object to suggestions we do this on that basis.
As well as, extending the underlying language (that is, markdown) has to be done really carefully, and so being conservative with how it's done matters. This was a huge part of figuring out the design of intra-doc links in the first place.
(All of this great work is being done by others, and I don't know what their opinion on it really is, so my opinion being -1 doesn't really matter these days.)
reply
---
was mentioned by a Sourcegraph guy:
https://news.ycombinator.com/item?id=25221910
---
"The acid debugger has amazing ideas which have had vanishingly little penetration into the rest of the debugger market, and that ought to be corrected. gdb, strace, and dtrace could all be the same tool, and its core could be just hundreds of lines of code. The marraige of dtrace and acid alone would probably make an OS the most compelling choice in the market."
https://plan9.io/sys/doc/acidpaper.html
---
bpf_debug is described in:
https://lwn.net/Articles/593476/
---
"The pinnacle of interactivity was, and still is, Smalltalk. I worked in that language for a couple of years and having your system compile and run most of your tests in less than a second is addictive. It is incredible how much your performance increases on a fully interactive programming system but it takes first-hand experience to fully appreciate it... Clean live patching has at least been possible since Smalltalk-80, and Erlang/OTP upped the game a step with first class support ... The live-coding environment is 80% of what makes Smalltalk so powerful: instant feedback. Developers tend to work more and more in the debugger, even, as they progress: you write a test, have it fail with an exception, and there's the debugger with the full stack and a code pane to fill in. However, you need to let go of things like having your code in files, or (therefore) easy access to file-based version control systems, etcetera. " -- [7]
---
" Debuggers which can visualise known types of data (e.g. vectors, matrices, bitmaps etc) and display changes made to them over time. " [8]