Time to rethink that VSCode install

Afghanistan was always a Muslim country with its own standards for dress code... Just read up about that on Wikipedia before making outlandish claims like that, please.
From Wikipedia:
The various conquests and periods in both the Indian and Iranian cultural spheres[4][5] made the area a center for, Buddhism, Hinduism, Zoroastrianism and later Islam throughout history.[6]

You may be talking about the modern state of Afghanistan, which itself wasn’t always there but the Afghans are an ancient culture. As for miniskirts, see
The last king of Afghanistan had modernized the country considerably where such self-expression was allowed. Things went downhill fast once he was deposed. Until then one could even travel through it on the Hippie Trail in a car from Europe to India. BTW, I could’ve given the example of Iran as well.
 
I can still remember my Mum telling me "now put it back together!" after I'd dismantled the old radio when I was about 7 😄.
I did the same at age 10-11 and broke the radio while “putting it back together”! That is when my father took the radio and me to our local radio repair shop and told the owner to repair the radio and teach me a few things about electronics! With his help I built my first crystal radio. I am all for ”looking under the hood” to understand things.
 
For one generation, line oriented editors like ed were good enough. For the present generation of programmers who got used to IDEs, editors may be limiting...
Fascinating article on the history of unix text editors, and specifically on the origins of vi/vim.


It's true that people were stuck with 'ed' for a few years after unix was first released, until Bill Joy's first version of vi in 1976. I can remember being forced to use 'ed' on an ancient PDP8 in the physics lab at uni because they didn't have a vi port for it. But it's worth remembering that the population of unix users back then was very small, for the first few years at least it was only used internally within a fairly small group inside bell labs. Really as soon as unix was released to universities the number of users grew rapidly and the demand for a full screen editor became overwhelming, resulting in vi. Meanwhile James Gosling made the first port of emacs to unix a few years later in 1981 ( https://www.emacswiki.org/emacs/EmacsHistory ). So we got screen editors pretty soon after unix was released to a wider audience; people didn't stay stuck with 'ed' for very long. Since that time, vi/emacs have been the mainstay in unix text editing, so they have stood the test of time, which amazingly is the last 45-50 years. Of course if you go back to the 50's and 60's, perhaps that was a time when line editors were more common, particularly before VDU's became common and people were using teletypes; screen editors were impractical for devices like teletypes for obvious reasons.

It's also the case that IDE's go back a lot further than might appear at first glance. Turbo pascal, first released in 1983, was arguably the first (albeit basic) IDE I used, but I'm sure there were earlier examples. It had all the core features - integrated make, single keypress compile, integrated debugger and run, that are still present in modern IDE's. That was a great system for beginners, I learnt pascal using that. Soon after that we had turbo C and the VB explosion, and MS visual C (before visual C++). So the IDE concept has been around for a long time too. If you check out this video of someone writing hello world on TP, you'll notice it has many of the features you will recognise from modern IDE's:-

View: https://www.youtube.com/watch?v=0ZQCXXhXq6Q

So I think these two general types of tools, screen text editors and IDE's, have co-existed for a long time and will continue to do so, rather than it being a generational thing. I personally have used lots of different editors, and IDE's, while I've been programming. I think the use of line editors was more tied to the hardware in the days before VDU's, ie teletypes; once VDU's became available, either as micros or terminals, screen editors have been the norm, whether standalone or embedded within an IDE.

Of course we might now be reaching a stage where some software, at least, is just so complex that it can't be built without an IDE helping you to do the job, although persionally I hope that is not the case.
 
The problem with all these IDEs is they are a crutch that hides a lot of the details of what's really happening. You never learn properly how to drive the compiler from the command line, how to run all the other tools in the compiler toolchain, how the linkage editor works, the assembler, the makefiles, you only understand the debugger as it is presented to you inside the IDE, and the code completion features mean you don't need to learn things like function signatures, it provides you with a list of parameters to fill in, so you don't make the mental effort to remember. So you might say, what's wrong with that, it helps me get my work done faster, the boss likes it (because they told him I could get it done faster and won't need training), and I don't need to learn so much stuff?

What's wrong with that is you become DEPENDENT on the tool, it limits both your learning and understanding, and when the tool isn't there, or not flexible enough to do what you need, or has bugs, the crutches are taken away and you then find you are struggling. Of course that suits the IDE vendors fine because it keeps you coming back for updates to their tool and giving them more money in the process. It's called user lock-in.
First of all the idea that the 74% of developers who use vscode came from Visual Studio like kdpersen said is crazy to me. I don't know a single person who has ever touched Visual Studio.

Secondly while I do agree with you in principal I don't think that's an entirely valid point for vscode.
Though it can automatically run build commands or integrate a debugger, these things do still have to be configured by the user.
VSCode isn't specific to any language it doesn't know what a C compiler is.

I personally do quite a bit of development on vscode but I rarely use the build-in build commands or debugger.
To me it's just an editor with proper LSP support, file manager, built-in terminals etc.

You're also looking at this with a C/C++ perspective.
But remember that this is an editor to fit all, and if we again point to the stackoverflow hardware survey only about 22% of people write C/C++.
Modern build tools (like cargo) are much much simpler.
The days of autotools are over.

I agree with your point in the realm of jetbarins/intellij IDEs.
I work at an IT school and our software development department loves pushing these tools unto people but the students often get completely dependent on them.
But that's honestly what those tools are designed for, they need you to depend on them so that they can charge you or your boss 200 euro's a year.
 
A friend of mine, a brilliant programmer, loves IDEs and is very productive using them. Another friend, equally good, uses emacs. Yet another friend, even more productive and successful in many areas used vi. And so on. What matters far more than the tools you use is how you use your brain. Learning to use it better will have a much bigger impact all around!
 
Too bad that lisp machines didn’t have someone like Ken Thompson to strip LMs down to an absolute minimum and make them run on cheap hardware. Instead their start was with MIT guys had plenty of computing resource. They too didn’t quite see ”the attack of killer micros” coming. The market for anything that couldn’t run on cheap commodity hardware kept getting smaller and smaller. My (untested) belief is that passing s-expressions around instead of text steams (as in shell programming) or binary structs and values (as in syscall or library APIs) or json or xml, would’ve been the “right” compromise for flexibility & efficiency. Now we are stuck with python, shell scripts and programs written in brittle, mediocre languages with limited flexibility and poor security. [All in my humble opinion, of course!]
 
Yes. Imagine GPUs running lisp code in massive parallel contexts. Able to draw everything as vector elements, just like the display postscript of the Next.
 
I've been using FreeBSD since version 4.2 but I was never a coder. Now that I did pick that up as a hobby, the occasional stint with nano just doesn't cut it. I installed VSCode as that integrates with rust-analyzer and offers me a live view on my boo-boo's as I type them. I'm open to learning an alternative, as VSCode is a steaming pile of.. well.. steam and it's a miracle that it even runs at all. Ideally I'd like to learn something that runs from a remote shell as well. The Vi/Emacs..ermm.. debate.. has been going on for a while so to say, but neither feel exactly discoverable to me. I'm open to doing some initial configuration of course, but not all too happy with undiscoverable keyboard shortcuts that first need me to read a book on the editor and then spend months training muscle memory.
 
I don't know a single person who has ever touched Visual Studio.
Me, too, I used Visual Studio when I was in college. I knew about the basic dev/compilation stack, but I quickly got lost in the buttons. And I had to compile OpenGL code. Opening a template was fine, but compiling and creating a package that can be submitted as a homework assignment that gets evaluated against a set of checkboxes - that was a pain the entire time. It was a huge relief for me that my other classes relied on UNIX (Sun Solaris) to do homework...
Yes. Imagine GPUs running lisp code in massive parallel contexts. Able to draw everything as vector elements, just like the display postscript of the Next.
I would not put it past NVidia/AMD to have API's like that - just dig deep enough, and play with it. 😏
 
The Vi/Emacs..ermm.. debate.. has been going on for a while so to say, but neither feel exactly discoverable to me. I'm open to doing some initial configuration of course, but not all too happy with undiscoverable keyboard shortcuts that first need me to read a book on the editor and then spend months training muscle memory.

Emacs in X11 mode has GUI menus to bridge the transition to a certain degree.
 
Did any of the lisp hardware efforts achieve long-term commercial success? Is anyone making those kind of machines nowadays? Maybe in defence or NSA type applications (or supercomputing?), if not business computing?

Nah. The source code for Symbolics Lisp machines, which were the most successful, is in the hands of a person who doesn't do anything with it and doesn't like Open Source.

I have little doubt that the US government has Symbolics applications that they keep alive with the card-based machines or the emulator on DEC Alpha.

The NSA apparently really likes AllegroGraph.
 
I did find this; it appears there's a software simulation of the symbolics box called open genera, which comes from symbolics. I tracked down their website here:
http://www.symbolics-dks.com/ which talks about running it on a dec alpha unix box... :)

Someone put up a video of running open genera under linux on virtual box here. Almost at the end of the video they show you what I assume is the symbolics startup page. And there is this page https://archives.loomcom.com/genera/genera-install.html

View: https://www.youtube.com/watch?v=12USa3gU_oU
 

Attachments

  • 2024-06-15-21:45:00_2560x1600.png
    2024-06-15-21:45:00_2560x1600.png
    246.6 KB · Views: 4
I did find this; it appears there's a software simulation of the symbolics box called open genera, which comes from symbolics. I tracked down their website here:
http://www.symbolics-dks.com/ which talks about running it on a dec alpha unix box... :)

Someone put up a video of running open genera under linux on virtual box here. Almost at the end of the video they show you what I assume is the symbolics startup page. And there is this page https://archives.loomcom.com/genera/genera-install.html

View: https://www.youtube.com/watch?v=12USa3gU_oU

Right. The problem is that there is no "clear and clean" way to get your claws on any of that.

I wish that people made more demos about what the heck all the fuzz was about.
 
bvdw78 For C/C++ the best full-blown IDE on FreeBSD (from the ones in ports) for me turned out to be quite unexpectedly QtCreator. A quick search turns up some tutorials on how to configure it to use Rust, I have no idea if it's useful in that capacity. It's actually a pretty lightweight yet powerful IDE for console applications or libs built with CMake, I still haven't written a Qt application and wouldn't turn to anything else anymore (except Kate as a lightweight editor for e.g. shell scripts etc).
 
bvdw78 For C/C++ the best full-blown IDE on FreeBSD (from the ones in ports) for me turned out to be quite unexpectedly QtCreator.
I tried QtCreator once (two years ago), but the lldb-debugger integration did not work. Not much point in using an IDE when the debugger does not work …
 
Back
Top