Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

Post reply on HN
Print view View original

651–660 of 698 posts

Re: The Era of Visual Studio Code

#651

Post by gimboland »

happymellon wrote: post #625
gimboland wrote: post #520

Earlier quoted context omitted.

You may change your mind if you plug your MBP into an external 4K display and try to use a scaled resolution: https://youtrack.jetbrains.com/issue/JBR-526 — don't get me wrong, I love PyCharm too for all the reasons spoken about in this thread, but this issue (which has been open for five years now) has made me attempt to jump ship to VSCode for my python work several times. I _do_ always come back to PyCharm... so f…

This is completely not restricted to IntelliJ/PyCharm. The MBP i7 is terrible for this, and I get thermal throttling all the time when I use 4k external screens and anything remotely that seems like work.

OK, but (for example) my experience is that I only experience this as a problem with PyCharm — it literally becomes unusable; VSCode (say) is fine.

Re: The Era of Visual Studio Code

#652

Post by dheera »

Almad wrote: post #591
dheera wrote: post #357

Earlier quoted context omitted.

Yeah I mean it should be as basic as class MyApp extends AndroidApp { void main() { Document.write("hello world"); Document.write(" blah "); } } javac it, adb sideload the .class file (or .jar file), and you should be done for the day. Unfortunately the bare minimum is way way way more complicated than this. Weird XML files, infestations of manifests (generate them automatically from 'ls' and 'grep' damnit), Gradle f…

> Gradle files (worst abomination of a build system ever) Ant? Maven?

Ugh. Why can't we just make javac [STAR].java work? Tarball the resulting .class files, make sure to have one called Main.class that is the entrypoint, GPG sign the tarball and you should be ready to distribute.

Yeah I know it doesn't work like this now, but the designers of the entire Java/Android ecosystem should have designed it to be that simple.

The moment you get any of these build systems involved you instantly lose all hopes of DRY coding. Excerpts from an Ant build.xml file:
I see "HelloWorld" repeated 3 times. MASSIVE fail. I'd rather no build system than deal with this level of repetitiveness. It's bad enough that Java requires the file name == class name which is already a case of repetition (that design decision is fine with me but then files should start with "class {" and not "class Foo {")

Re: The Era of Visual Studio Code

#653

Post by mixmastamyk »

no_wizard wrote: post #389
mixmastamyk wrote: post #280

Earlier quoted context omitted.

Geany plus Makefile with automated functions. Build keys can be assigned to avoid Window switching. What walls were you hitting? Disclaimer, I have used Pycharm on a really big work project but most of the time, don't.

Admittedly a lot of it is around things like built in documentation, viewing source code from inside modules (I’m a frontend software engineer so inside node_modules for instance) and the ability to simply let the IDE handle certain things with refactoring components or generating boilerplate. I found I repeated myself less and improved my productivity this way

Yep, I set up aliases and scripts for similar needs.

Re: The Era of Visual Studio Code

#654

Post by marcus_holmes »

higerordermap wrote: post #553
marcus_holmes wrote: post #547

I'm stuck. I'm writing Go and VueJS. I tried Goland but it was too Java-y and too complex - there are thousands of settings. 4 different search options. 5 different methods of getting to the declaration for a function (and I'm never sure which one I should be using). I ended up spending more time messing with the editor than writing code, and there were too many incidents where I accidentally triggered a feature with…

I bind shortcut keys in vim to common ones, something like this: :map ^Q :wq^M It works good enough for me. I use vim keybindings also but this is sometimes useful.

like I said, I love Vim. If we could change every other editor to be like Vim, then the world would be a better place.

But we can't, and my muscle memory isn't refined enough to hit "ciw" in Vim to edit the current word, and not in any other editor. Especially web input controls, that tend to react badly to hitting ESC halfway through an edit :(

Re: The Era of Visual Studio Code

#655

Post by marcus_holmes »

varbhat wrote: post #609
marcus_holmes wrote: post #547

I'm stuck. I'm writing Go and VueJS. I tried Goland but it was too Java-y and too complex - there are thousands of settings. 4 different search options. 5 different methods of getting to the declaration for a function (and I'm never sure which one I should be using). I ended up spending more time messing with the editor than writing code, and there were too many incidents where I accidentally triggered a feature with…

Try https://github.com/visualfc/liteide for Golang. Also,you can try emacs.

hehe, another vote for Emacs... Message received.

I'll check out liteide - I like the idea of an ide written in Go, that I can possibly contribute to ;)

Re: The Era of Visual Studio Code

#656

Post by shadofx »

derefr wrote: post #642
mdekkers wrote: post #449

Earlier quoted context omitted.

> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. Ah, like a jackhammer? One of those huge ones attached to a digger they use to break open the roads? It’s a right-tool-for-the-job kind of thing. Some roads can be mended with a shovel. Some need a jackhammer. If you limit your development t…

A jackhammer is like a codegen tool, or maybe a code formatter: it “writes” or “edits” a lot of code for you, quickly, but it’s not doing programming per se. You can’t use a jackhammer to put together the pieces of a lacquered cigar box, faster . You can’t use a jackhammer to build much of anything, really. (But I should note that a jackhammer also doesn’t required a powered exoskeleton to wield. The power is instead…

>The money that had been spent on that RAIDed NVMe storage, could have been much-better spent on just adding more RAM to the system.

It is organizationally costly to upgrade the human brain to increase RAM. Much cheaper to increase HDD storage through rote memorization and even more cheaper to access External storage on StackOverflow. That is where Verbosity helps, to signal when to stream certain Paradigms into your active memory, and keywords to use when searching for answers online.

A 4mb Language can't run on a 3mb brain, so the efficiency it offers at compressing your mental model is useless. But if you have a 1mb Language kernel that dynamically streams 1mb of Paradigms at a time, and then uses the last 1mb to work on the code, then you are capable of functioning.

Re: The Era of Visual Studio Code

#657

Post by TeMPOraL »

paulryanrogers wrote: post #615
atilaneves wrote: post #603

Earlier quoted context omitted.

I think you missed the point where they mentioned you can change any and all keybindings in Emacs.

Right but that requires learning Emacs well enough to change bindings. Then all the other tweaks one makes to a tool like text expansions, macros, and learning differences in find-replace, refactoring, and autocomplete.

There's no more learning required for changing Emacs keybindings than in other IDEs. If you don't want to go the scripting way, you can use the Customize interface, which is Emacs's equivalent of Settings dialog in most other software. Hell, unlike most software, Customize interface gives you a choice between applying changes temporarily and permanently, so you can try things out and if you mess up, just restart the editor.

(Under the hood, stuff you change via Customize gets serialized into a file called custom.el. But you don't have to know that to use it.)

Re: The Era of Visual Studio Code

#659

Post by oblio »

diffeomorphism wrote: post #596
oblio wrote: post #568

Earlier quoted context omitted.

There is a comment right above yours that contradicts you: https://news.ycombinator.com/item?id=24561943

That comment doesn't contradict the post at all. If anything it supports that statement and then goes on to mentions that high latency connections are problematic.

High latency connections are a fact of life. If Emacs Tramp, for which development was started in 1998, when high latency connection were a lot more common, still has issues with high latency connections, that's not a glowing reference for its architecture.

Especially since it seems VSCode manages those connections better.

It's ok to admit your favorite tech has flaws, everything has them.

Re: The Era of Visual Studio Code

#660

Post by aschatten »

sangnoir wrote: post #388
aschatten wrote: post #291

Earlier quoted context omitted.

(disclaimer: I am an IntelliJ fanboy) > From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it as knowledge is scattered in many places and not always up to date. I don't know if you are talking about IntelliJ or VCS, but IntelliJ can quickly start an empty project. And you don't to spend time to figure out how things work.…

I'm a fanboy of both JetBrains and VSC. In the many years I've used JetBrains IDE variants (IntelliJ, Webstorm & Pycharm), I was never able to get rid of the frequent project re-indexing that slows everything down and makes the fans go crazy; you'd think they would cache that info and write it to disk.

They introduced recently an interesting feature: https://blog.jetbrains.com/idea/2020/07/shared-indexes-plugi... that might help with indexing of some shared libraries. I have not experience with this feature, but it looks promising.

Frequent re-indexing sucks and and times it slows you down. But I see it as a direct price to pay for intelligent autocomplete, search, refactoring, etc.

It also eats a lot of memory :(

Post reply on HN