![[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]
https://marketplace.visualstudio.com/items?itemName=hediet.debug-visualizer http://symbolflux.com/projects/avd https://gtoolkit.com/
---
i've heard this mentioned twice now, still haven't watched its video:
---
" Getting LSP integrated pervasively in Emacs in a way that it reliably just works and performs well out of the box, would go a long way towards making Emacs more attractive not just to new users, but to existing ones too. Imagine an experience similar to VSCode’s:
Open Emacs for the first time
Open a source code file
Emacs asks if you want it to configure itself for the programming language of that source file
Saying “yes” automatically sets up Emacs to have a modern programming environment for that programming language with smart code completion, navigation, and refactoring, rich hover information, highlighting, automatic formatting, snippets, etc. Maybe even open a side window with a buffer with a short “getting started” tutorial showing the available keybindings.Providing good out of the box support for LSP is one of the current priorities in the Neovim project. " --- " Many have created their Emacs wishlists. This is mine:
Improved single-core efficiency
Improved display efficiency and rendering engine
Leveraging preemptive parallelism
Emacs Lisp improvements
Enhanced stability
Dealing with non-text
Improved contribution and development process" https://www.youtube.com/watch?v=VADudzQGvU8 https://www.jwz.org/doc/xemacs-wishlist.html" It probably makes sense to continuously look for functionality implemented in the C core that could be replaced with focused libraries, like Neovim did by replacing almost all of their hacky, platform-specific code with libuv.
Also, would it make sense to start an Emacs Open Collective to fund work on Emacs? "
---
https://lord.io/blog/2019/text-editing-hates-you-too/
---
https://plugins.jetbrains.com/docs/intellij/psi.html
---
~
agent281 33 hours ago | link | flag | I feel like these two things together should combine to (eventually) make compiler-as-library more of a thing, which seems like an overlooked field of study. It can be useful to aid JIT, metaprogramming, powerful dynamic linking, etc. It seems very silly that this remains Dark Magic outside of anything that isn’t Lisp or Erlang.
I really like the idea of compiler as a library, particularly for a bootstrapped language. Anders Hejlsberg talked about how modern compilers have moved from a batch design to a sort of query based design to support IDEs with interactive workflows. A compiler as a library approach would be a strong basis for this.
https://www.infoq.com/news/2016/05/anders-hejlsberg-compiler/
---
" If it isn’t already, it will become a faux pas to launch a language without basic editor support. At the least this means syntax highlighting, but really includes context-sensitive autocompletion, inline diagnostics for parse and type errors, refactoring, jump-to-definition, the works. This is a trend buoyed by generic editors and standards like VS Code and the Language Server Protocol, which mean that implementers only need to expose the information rather than build an IDE.
What’s most surprising about building these tools is the deep effect they have on compiler architecture. For starters you have to open up the black box, ensuring that there are APIs for the information at each stage of the compiler. But you’ll probably also want to extend your AST to make sure it can round-trip back to readable text, preserving comments and whitespace even after programmatic edits to the tree. And make sure to use persistent data structures throughout so that multiple threads can analyse changing code robustly and efficiently. Of course, it goes with saying that your parser should be fault-tolerant, so that a single problem doesn’t bork editor support everywhere, and incremental, so it doesn’t have to re-parse everything on every edit. Remember, you’re aiming to update your entire view of the world and re-compute whatever a user needs in 100 milliseconds, before they enter a rage over editor sluggishness. "
---
"...tab completion of variable names, automatic identification of methods within scope, syntax highlighting, easily dropping breakpoints, etc. are, in my experience, wonderful improvements on productivity."
---
http://www.pathsensitive.com/2021/03/developer-tools-can-be-magic-instead.html
---
"One important property of TSan is that, when properly deployed, the data race detection does not produce false positives. This is incredibly important for tool adoption, as developers quickly lose faith in tools that produce uncertain results."
"TSan, ASan, UBSan - if you are writing code and your toolchain supports these, you should use them. Over the past 6-7+ years I've used them, I have never seen a false positive (I'm sure some have occasionally existed but they seem rare in practice)."
---
https://markodenic.com/use-console-log-like-a-pro/
---
" In recent years, we've seen more and more programming languages bundled with other tools, such as build/packaging tools, code formatters, linters, documentation generators, language servers, centralized package repositories, and more. ... We refer to programming languages with a comprehensive standard library as batteries included. I'm going to refer to programming languages with additional included tools beyond the compiler/interpreter as toolbox included. ... In addition to the Rust compiler (rustc) and the Rust standard library, the following components are all officially developed and offered as part of the Rust programming language on GitHub?:
Cargo - Rust's package manager and build system.
Clippy - A Rust linter.
rustdoc - Documentation generator for Rust projects.
rustfmt - A Rust code formatter.
rls - A Rust Language Server Protocol implementation.
crates.io - Rust's official, public package registry.
rustup - Previously mentioned Rust installer.
vscode-rust - Visual Studio Code extension adding support for Rust. (JetBrains has their own high quality extension for their IDEs, which they develop themselves.)
The Rust Programming Language Book
And many more.As an end-user, having all these tools and resources at my fingertips, maintained by the official Rust project is an absolute joy.
For the local tools, rustup ensures they are upgraded as a group, so I don't have to worry about managing them. I periodically run rustup update to ensure my Rust toolbox is up-to-date and that's all I have to do.
Contrast with say Node.js, Python, and Ruby, where the package manager is on a separate release cadence from the core language and I have to think about managing multiple tools. (Rust will likely have to cross this bridge once there are multiple implementations of Rust or multiple popular package managers. But until then, things are very simple.)
Further contrast with languages like JavaScript?/Node.js, Python, and Ruby, where tools like a code formatter, linter, and documentation generator aren't always developed under the core project umbrella. As an end-user, you have to know to seek out these additional value-add tools. Furthermore, you have to know which ones to use and how to configure them. The fragmentation also tends to yield varying levels of quality and end-user experience, to the detriment of end-users. The Rust toolbox, by contrast, feels simple and polished.
Rust's toolbox included approach enables me to follow unified practices (arguably best practices) while expending minimal effort. As a result, the following tend to be very similar across nearly every Rust project you'll run into:
Code formatting. (Nearly everyone uses rustfmt.)
Adherence to common coding and style conventions. (Nearly everyone uses clippy.)
Project documentation. (Nearly everyone uses rustdoc.)Cargo could warrant its own dedicated section. But I'll briefly touch on it here.
Cargo is Rust's official package manager and build system. With cargo, you can:
Create new Rust projects with a common project layout.
Build projects.
Run project tests.
Update project dependencies.
Generate project documentation (via rustdoc).
Install other Rust projects from source.
Publish packages to Rust package registries.As a build system, Cargo is generally a breeze to work with. Configuration files are TOML. Adding dependencies is often a 1 line addition to a Cargo.toml file. Dependencies often just work on the first try. It's not like say C/C++, where taking on a new dependency can easily consume a day or two to get it integrated in your build system and compatible with your source code base.
...
A lot of care seems to have gone into the end-user experience of the Rust toolbox.
The Rust compiler often gives extremely actionable error and warning messages. If something is wrong, it tells me why it is wrong, often pointing out exactly where in source code the problem resides, drawing carets to the source code where things went wrong. In many cases, the compiler will emit a suggested fix, which I can incorporate automatically by pressing a few keys in my IDE. Contrast this with C/C++ and even Go, which tend to have either too-terse-to-be-actionable or too-verbose-to-make-sense-of feedback. By comparison, output from other compilers often comes across as condescending, as if they are saying git gud, idiot. Rust's compiler output tends to come across as I'm sorry you had a problem: how can I help? I feel like the compiler actually cares about my [valuable] time and satisfaction. It wants to keep me in flow.
Then there's Clippy, a Rust linter maintained as part of the Rust project.
One thing I love about Clippy is - like the compiler - many of the lints contain suggestions, which I can incorporate automatically through my IDE. So many other linters just tell you what is wrong and don't seem to go the extra mile to be respectful of my time by offering to fix it for me.
Another aspect of Clippy I love is it is like having an invisible Rust mentor continuously providing constructive feedback to help me level-up my Rust. I don't know how many times I've written Rust code similarly to how I would write code in other languages and Clippy suggests a more Rustic solution. Most of the time I'm like oh, I didn't know about that: that's a much better pattern/solution than what I wrote!
Do I agree with Clippy all the time? Nope. But I do find its signal to noise ratio is exceptionally high compared to other linters I've used. "
---
https://buttondown.email/geoffreylitt/archive/starting-this-newsletter-print-debugging-byoc/
"print debugging has one critical feature that most step-based debuggers don’t have: you can see program state from multiple time steps all at once. Think about it: with print debugging, you run your program, and your terminal fills with output; you can rapidly skim up and down with your eyes to investigate what your program did as it ran. If the program ran 100 iterations of a loop, you’re seeing those 100 iterations exploded in space, all of them simultaneously visible."
---
"debugging statements stay with the program; debugging sessions are transient" via https://news.ycombinator.com/item?id=26925570
---
"
CJefferson 4 days ago [–]
Personally, I think my biggest reason for using print debugging is.. it works.
In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why.
I'm sure in each case I'm sure I could get a debugger working given enough time, but the only error I've ever had in print debugging is failing to flush output before a crash, and it's never been hard to search for "how to flush output" in whatever language I'm current using.
reply "
---
https://emacs-lsp.github.io/dap-mode/
---
https://github.com/TreeTide/underhood
search?
---
https://rust-analyzer.github.io/blog/2020/04/20/first-release.html ppl love this https://news.ycombinator.com/item?id=22995466 ---
" stuff like "look up that definition" or "find all the implementations of that method" or "go to ABC""
---
vearwhershuh on March 13, 2020 [–]
Back in the very old days I wrote Excel Apps in VBA. You could pull an entire range in as a 2d array and dump it back out the same way.
The debugging environment was better than any I have used since. You could drag the execution point anywhere, edit code in between steps, view everything. It was amazing.
IntelliJ? is pretty good now, but not like that.
---
Firadeoclus on Feb 13, 2020 [–]
Indeed, as someone who's learning a bit of APL on the side I'd love to have a tool that can "explain" a line of APL on demand, e.g. show the parse tree, name built-in functions and operators, expand trains, possibly name common idioms.
I find the concepts in APL very simple. The difficulty for me is in becoming comfortable reading it. Such a tool would make it quick and easy to confirm one's initially very tentative guesses as to what a line means, and gradually you'd come to depend less on it as you get more confident that your initial understanding is right.
kick on Feb 13, 2020 [–]
Have you seen the FinnAPL? idiom library?
https://www.finnapl.fi/idilib.htm
And not that I'd recommend using proprietary software, but something that might be helpful for you regarding naming is that Dyalog APL has a top bar with every character used in modern APL, the name of them, and (I think, I've never actually used the system) an example of how to use them.
Firadeoclus on Feb 14, 2020 [–]
Thanks for the link. Yes, I've seen other idiom libraries as well, and what I'd like to see is automatic lookup of those idioms, with a name, and optional further breakdown.
---
https://code.jsoftware.com/wiki/Vocabulary/Dissect
---
"Some simple things are missing. Notable to me: the language server can't use type specs to provide code completion, and doesn't have the refactoring actions of more advanced systems. I miss being able to rename a function without grep. "
---
"You might want to try Common Lisp sometime; so much of the base language is made up of macros without which programs would be neither pleasant to read or write, and the language itself provides facilities to ask "ok but what function(s) are actually going to get called with this data" so that even not-so-local things like e.g. transparent logging of a call's input/output become visible if you need to know."
---
https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization
---
" Some of the biggest speed increasers that I’ve adopted during my ~7 years of programming are (in no particular order):
Getting really good at using “go-to definition” in my editor. Being able to navigate around large codebases quickly and with little friction is so massively important for keeping context hot and thoughts continuous.
Learning the best things to grep for in order to navigate code quickly, as well as getting very familiar with the full-codebase search built into my editor
Auto-import code assists. I have these for Rust and Typescript and I actually dread to think about programming without them. So much time used to be wasted hunting for which file some function comes from, typing out the full path to it, etc.
Embedded linting and errors in the editor. Having to tab over to a terminal and run your compiler and then tab back to the code and cross-reference is horrible.
Code auto-formatters. I used to waste huge amounts of time laboring over exact formatting of my code. Now, I’ll type 200+ character lines for things like function signatures or complex conditionals and let the formatter handle adding newlines, spaces, etc.
Making sure that my hot-reload tools for frontend webdev are as fast as possible. Especially when doing fine-tuning stuff with styling etc., having a rapid (~500ms) hot-reload is such a massive difference-maker and it prevents me from getting fatigued of the dev process when things work smoothly.And most recently,
AI-powered code autocomplete. I started with Tabnine and now I’m quickly becoming a Github Copilot addict.
"
---
https://benjamincongdon.me/blog/2021/10/17/Features-of-Excellent-Code-Review-Tools/ https://lobste.rs/s/hfye67/features_excellent_code_review_tools
---
"
Getting really good at using “go-to definition” in my editor...I often find myself control-clicking through 5+ layers of function calls or type definitions in seconds to get to what I'm looking for.... Making extensive use of full-codebase search and learning the best things to grep for in order to navigate code quickly
Rather than manually navigating through complex directory structures or actually typing file names, I build up a collection of good search terms to use with the full-codebase search built into my editor (VS Code) to jump between different parts of the code quickly. They work like virtual bookmarks.... Using Auto-import code assists
I have these for Rust and Typescript and I actually dread to think about programming without them. So much time used to be wasted hunting for which file some function comes from, typing out the full path to it, etc. The best ones that I use have the ability to automatically locate the source file for some undefined variable, generate the import statement, and insert it automatically.... Having embedded linting and errors in the editor/IDE
Having to tab over to a terminal and look at the output of your compiler or linter and then tab back to the code and cross-reference is a big context switch in my experience. Better yet, having "quick-fix" support takes it to the next level saving you from having to even write the code yourself if it's trivial. Using code auto-formatters ... Having very fast hot-reload ... For backend development, Making sure compilation times are as low as possible ... " [9]
"
~ matklad 18 hours ago
| link | flag |
A bit surprised that neither this nor the other posts which mentions IDE talks about these features:
fuzzy search of all symbols in project. That’s the primary way to navigate across file — just type the name of the type you need.
fuzzy search of all symbols in the current file (ideally rendered like a tree widget, as in JB IDEs) — that’s the main thing to use when jumping within a file
extend region/expand selection/semantic selection (that is, selecting progressively bigger valid expressions) — that’s a universal editing tool which speeds up almost any rearrangement of code. ~
karlinfox 10 hours ago | link | flag | They do mention it, near the bottom:
I’ve gotten a lot of value from a few changes: Learning to use fuzzy-file-open, search, ripgrep, jump-to-definition, jump-to-uses, jump-to-errors etc to move around the codebase.
~
matklad 8 hours ago | link | flag | Yeah, this is what I mean: this list dodges the three things I find most valuable.
"
" Examples:
IDE tools which show errors in the editor as you type often let you fix mistakes right after typing them, while the context is still completely fresh.
I setup my editor to run tests on every save so that by the time I look at the test window they've already finished.
For some kinds of test failure I want to view the failure in a debugger. Rather than set this up each time I always run tests using rr record. Ideally I would also integrate this into the test runner so that it knows to rr replay on test failure without me having to open a new terminal."
" Setting up completions for whichever language I'm using and learning to navigate the list with keyboard shortcuts. Learning to use multiple cursors effectively for structured editing. Moving the arrow keys so I don't have to leave the home row to make small movements. ... Learning to use fuzzy-file-open, search, ripgrep, jump-to-definition, jump-to-uses, jump-to-errors etc to move around the codebase. "
-- [10]
--- https://www.lightbluetouchpaper.org/2021/11/01/trojan-source-invisible-vulnerabilities/
---
"Whenever I stray away from C#/Java world, I am amazed how bad the IDE experience is for other languages, but that's because most other languages have features which don't play well with IDEs (dynamic typing, templates, macros, anything compile time)." [11]
---
https://github.blog/2021-12-09-introducing-stack-graphs/
---
programmable debugger
https://github.com/osandov/drgn
---
---
Text Editor Authors
Pay attention to the architecture of VS Code. While electron delivers questionable user experience, the internal architecture has a lot of wisdom in it. Do orient editor’s API around presentation-agnostic high-level features. Basic IDE functionality should be a first-class extension point, it shouldn’t be re-invented by every plugin’s author. In particular, add assist/code action/💡 as a first-class UX concept already. It’s the single most important UX innovation of IDEs, which is very old at this point. Its outright ridiculous that this isn’t a standard interface across all editors.
But don’t make LSP itself a first class concept. Surprising as it might seem, VS Code knows nothing about LSP. It just provides a bunch of extension points without caring the least how they are implemented. LSP implementation then is just a library, which is used by language-specific plugins. E.g., Rust and C++ extensions for VS Code do not share the same LSP implementation at runtime, there are two copies of LSP library in memory!
---
cies 1 day ago
| parent | prev | next [–] |
Maybe we've reached the limits of the complexity we can handle in a simple text-based language and should develop future languages with IDEs in mind. IDEs can hide some of the complexity for us, and give access to it only when you are digging into the details.
pjmlp 20 hours ago
| root | parent | prev | next [–] |
Like Common Lisp, Smalltalk, SELF, Delphi, C++ Builder, Java, C#, Visual Basic,....
The problem is that most on FOSS community tend to design languages for VI/Emacs workflows.
---
https://github.com/rochus-keller/LjTools
---
https://corecursive.com/why-80-columns/ suggests that 120 columns is a reasonable default limit for formatters etc
"
My only problem with <= 80 wide (truthfully anything under ~99 or so), is that people name things worse ala “employee_number” vs “emp_num”. Which I know from “Fixing Faults in C and Java Source Code: Abbreviated vs. Full-Word Identifier Names” and What We Know We Don’t Know: Introduction to Empirical Software Engineering the science suggests that doesn’t matter, but it does matter to me. Maybe it’s just what I’m used to, but 80 line codebases are so damn dense, and generally not enjoyable to work in for myself.
This kind of goes back to the clang-format discussion you and I had over the weekend over here. "
https://lobste.rs/s/kofzic/why_still_80_columns
"I used to be an 80-column purist but I don’t care about it so much anymore. At work we mostly limit code to 100 columns and wrap comments at 80 columns. For some languages the formatter enforces the 100-column limit (clang-format) but in others it’s up the programmer (gofmt)."
---
1 point by bshanks on Aug 11, 2020
| parent | context | prev | next [–] | on: Emacs 27.1 |
If you were designing a programming language with IDE tooling in mind, what are the things that Common Lisp and Smalltalk do to better assist IDEs than Python/Ruby?
pjmlp on Aug 12, 2020
| parent | next [–] |
Anders explains it better than me,
"Anders Hejlsberg on Modern Compiler Construction"
https://www.youtube.com/watch?v=wSdV1M7n4gQ
Basically ability to see the language AST at all time, do time checking with broken code, incremental compilation, REPL and IDE editing experience is fused together.
Here is another short examples,
"7 minutes of Pharo Smalltalk for Rubyists"
https://www.youtube.com/watch?v=HOuZyOKa91o
"MountainWest? RubyConf? 2014 - But Really, You Should Learn Smalltalk"
https://www.youtube.com/watch?v=eGaKZBr0ga4
---
---
"Stickers, or live code annotations that record values as code traverses them." -- [12]
---
hex editor that writes things with the most-significant-digit on the right, eg decimal 10 is hex A0, not 0A. This fits with making everything little endian.
---
" More than "typing source" — build the workflow, a project
I go over this in this post (and IMO this is great to do even in common langs): while you can start with "open text editor, write hello world, run", if your project has any life besides an Advent of Code problem, it's really worth the hours (yes, hours) to set up a Makefile (or whatever that language's build tool) that does some of the following:
Builds incrementally
Run tests
Triggers a deploy, if applicable
Run typechecks (if using a language with a bolted-on typechecker, like dialyzer, mypy, sorbet…)
Clean directory of build artifacts
Opens or reloads an interactive shell with the definitions loaded
Runs a formatterAdditionally:
Pick someone's project/directory structure if the language doesn't do this for you already
Practice adding/removing external dependencies until you can do it easily
Practice cloning the project from scratch and being able to repro it with minimal hassleAnd set up your IDE or text editor:
Connect to a language server to find bugs while you type.
Autocomplete
Snippets if there's boilerplate in the language (e.g. gen_server modules, or a shortcut for if err != nil { return err } for Go).
Practice using "Jump to Definition/Jump to Declaration"
Practice "Find usages"
Practice a safe rename/deleteNow, all of this may not be available for your Weird Language. Part of the agony and ecstasy of writing, idk, Raku is realizing how little of this is discovered or available. Still, most languages have at least one weird nerd who has a vim plugin that's worth trying. Else, if you fall in love, you can be that weird nerd! " -- [13]
---
"powerful IDEs with features like syntax highlighting, debuggers, profilers, go to def, git integration" -- [14]
--- " autocomplete (e.g. suggesting methods that actually exist on the type of objects you are dealing with)
immediate error checking (e.g. squiggly red lines under mistakes)
code navigation (e.g. jump to definition)
refactoring (e.g. renaming a method and all uses of it)
" -- [15]
---
