Leapfrogging the IDE | Hacker News Reader

Leapfrogging the IDE

amasad.me

65 pointsamasad94 comments

A couple of observations:

- Something like Light Table would probably seem like a step up for repl.it users, instead of a step down.

- It can take a long time to reach the point where it feels like there's a big payoff from using IDEs and similar tool.

Now, I definitely see the value of being able to do something like set a breakpoint in Visual Studio, step through a bit of code and observer local values changing, and then step backward, change the value of some variables or even edit my code a bit, and then step forward again to observe how my changes impacted the execution of the code. But when you're just learning, it's hard to even know that this kind of time travel debugging and live editing is even possible, and even when you know it's possible, it can be difficult to envision how you'd want to use it until you have more experience.

I think for someone not familiar with repl.it and just reading this might get the impression that we are anti-IDE features. That is not at all the point. In fact we think Code Intellisense is essential. We start a Language Server for many of the languages that we support: https://repl.it/blog/intel

That's a fair point!

I suppose I don't see Intellisense as something that's IDE specific anymore. It's available in plenty of editors that aren't IDEs, and I think that's a very good thing. The line is pretty blurry sometimes, too. For example, I don't think it would be inaccurate to call VS Code just and editor, even if it doesn't have any many features as Visual Studio.

For me, the some of the big wins with heavyweight IDEs are things like built-in debuggers(which I know repl.it has), heap snapshots, CPU and memory use profiling over time, and other tools along those lines.

So I definitely wouldn't want anyone to think repl.it is opposed to IDE features; I think you've already implemented the IDE features that will provide the biggest wins for your users.

And so I don't come across as someone who jsut loves big, complex tools: I agree with what you've written in the past about envionments like Smalltalk and Lisp Machines. I think we've forgotten about a lot of innovation that we could be making better use of. I think we've forgotten about some of the best parts of Hypercard, too. And even VB6.

I think part of the problem is your home page, because it doesn't say anything about what your product is, or what it does, or what your mission is, or how it helps me.

I went to the bottom of the page to find the "about" link, which had a 1 line mission statement that doesn't say much, and a bunch of employee pictures.

I still don't know what it is you do, other than your name which implies a repl, which most languages have already.

Which problem?

I see a lot of Chesterton’s fence/self fulfillment around text editor folks.

I don’t care if you use a text editor but I do care if you make design and process decisions that mute or erode the power of IDEs.

There are ways to organize code and modules such that you have to have a mental model of the entire system because they sabotage the static analysis that IDEs build much of their functionality off of. Don’t do that and we’re fine. Do that and we have a problem.

I can answer the question why switch if the limited online one is sufficient; it’s because the developer is working less efficiently and is unaware of the impact on productivity and code quality.

I’ve seen this many times, variable renamed done with text replace or by hand, inconsistent formatting and headers, silly bugs that an ide could catch as you type get committed, switching between screens to test their code constantly. Ignorance isn’t bliss, it’s just new developers aren’t getting the wisdom and expirence of the past and are repeating past mistakes instead of improving on the solutions.

From experience using atom to develop some perl integration scripts for ecommerce I found the variable completion and knowledge of perl very good.

The trouble is these enterprise dev tools assume you have bleeding edge hardware.

Back when I developed in Oracle we had to have special pc builds and then spend over £2000 on memory and more again to buy a 20inch monitor just to get it to work!- and it still crashed every 15 minutes

However quake came out at the same time and the 20 inchers where amazing to play networked games on.

Point being, if your computer isn’t doing the work then the human is, which has the most expensive compute cycles.

I also had to use JDeveloper.

I’ve been coding for 20 years. You are correct that some people would speed up in an IDE but it’s more complicated than that. Many people are slowed down by their IDE.

I see IDEs largely as a symptom of the complexity sickness in software development. Companies take a strategy of letting complexity grow to the point where it can’t be controlled. IDEs and other tools for managing massive complexity emerge, because you need such tools to work in codebasses that have become a hurricane of complexity.

There is another path, where you choose to use simpler tools and adapt your plans to fit the tools. This is how the Amish work and they are able to do incredible works and be highly productive.

So, yes. You can try to become like “iron man”, wrapped in tools of immense complexity to match the tasks you set yourself to.

Or you can be like a Japanese carpenter and study and think and refine so that you can do only small tasks, with simple tools, and see miraculous detail emerge from the compounding interest of consistent daily practice.

There are features in PyCharm that I have found so, so useful, that I refuse to write Python in anything else.

When Julia and Rust get support that good I’ll never have to use a text editor + plugins again; and I will be very pleased (even though the Rust sublime text plugin is very nice).

The Japanese carpenter has wisdom that allows him to to judge the right level of complexity vs simplicity. But the new generation of developers don’t have that, it’s just ordinary ignorance and is why someone was asking in the article.

Best comment in the whole thread, thanks. Yes, the current tools are just a symptom of the complexity

Coming from an enterprise background and having used Eclipse and IntelliJ for many years, I am honestly puzzled by the current trend in IDEs such as VS Code, Atom, etc. given their lack of fully features refactoring support, code search which goes beyond just simple text search, native understanding of classes, interfaces, method signatures etc.

I have tried all of the above 'modern' editors and almost immediately find tooling i'd assume is part of every IDE (i.e. code formatting, import organization/cleanup) but wasn't

Amongst the current crop of engineers, there seems to be a stigma against even trying Eclipse or IntelliJ. I kind of feel like junior engineers are missing out on discovering some much more powerful tooling and forming their own opinions.

Ranges from language to language.

For example, VS Code pulls TypeScript definitions of your JavaScript dependencies and thus has superior intellisense.

Also, the plugin ecosystem uses JavaScript, so it tends to be more cutting edge, especially if you're working on a JavaScript project (i.e. same language as plugins). For example, VS Code and Atom had Prettier code-formatting when IDEA didn't. And they sometimes have the best support for newer languages like Elm.

I'd be wary of painting people as junior developers just because they don't use your preferred IDE.

No, I meant literally junior developers who join organizations fresh and are immediately steered towards VS Code, Atom, Sublime by their organization and not even provided Eclipse/IntelliJ as an option.

I tend to toggle back and forth between Intellij and Sublime. This is almost entirely because Intellij feels slower and less responsive. My Sublime setup gets me 90% of the way to Intellij.

I wish Intellij was as snappy as Sublime. I wish it was as intuitively keyboard driven as Sublime. I wish the community around Intellij was half as helpful as the Sublime one when it comes to plugins, extension, customization.

I try all the popular editors (Sublime, VS Code, and Atom) every few months, because I would LOVE to replace IntelliJ IDEA for this very reason. That said, I always come back to it because the intelligence and refactoring features are vastly superior to those of any other editor I have used. If I could have the best of both worlds, I would switch in a heartbeat, but I just haven't found that to be the case yet—though I'm hopeful that other editors will catch up soon.

In VS Code especially, the level of support in the IDE very much depends on the language. For example, TypeScript has code search like Find All References that goes beyond text search, it understands classes, methods and interfaces, it supports code formatting and import organisation/cleanup.

It doesn't have as much refactoring support as eg Resharper, but it has the basics covered and honestly - even when I was using Resharper, well over 90% of the refactoring I did was renaming variables, which VS Code has covered.

I think part of the trend of IDEs losing favor is that for years they controlled the build. I think that build environments have changed so much in the past 3 years or so that having the IDE control it outright has quickly become untenable. Sure, for some languages, like Java or C# I think it still makes sense to use a full-IDE. But for JS and Typescript, where you might run webpack or node or chrome or docker, the concept of an IDE understanding and providing an intuitive notion of how to run that code, is becoming harder and harder to match user expectations.

Outside of the JS/TS realm? I don't know, I can imagine Jupyter and other notebook technologies really taking off too. I don't really see those as writing programs, however, I see that more as an exercise in data preparation that can be used in some other long-running API or otherwise.

Going a little beyond too - I am seeing more and more shops (including ours) that are adopting an ALL JS/TS approach and leveraging React, GraphQL on top of Node. I think the reason is that we're collectively deciding on reducing our code knowledge footprint. Companies are favoring fewer languages because JS/TS is "good enough" now to handle the backend of something major, it begs the question on why we should use Java or something similar for our APIs. We are also finding places where we can write something on the front end, and magically also run it on the backend for doing some similar operations.

I disagree. Webstorm provides all of the tools you need to customize your build, you don't have to use them at all but they're there when you need it.

Webstorm integrates with popular build tools like Webpack and Gulp, and adds support for more tooling all of the time through plugins.

There is really no reason to use another IDE for JS/TS unless you can't afford its very reasonable price.

Webstorm is essentially the only IDE that makes any sense for doing JS/TS work. Visual Studio is an unbelievable dog when you throw more than trivial amounts of JS code at it, to a degree that I cannot really understand, especially the apparently enormous resources that have been thrown at the problem in recent years. I routinely see VS splutter and die on smallish front-end projects when it runs like butter on six-figure LOC .NET and C++ solutions with dozens and dozens of projects.

I run Webstorm in VM environments with 2-4GB RAM and 2-3 vCPUs and for the most part it's pretty smooth even with image editing programs and multiple browsers open.

IDE's tend to work best for people who work full time on a few projects and make complex edits. Then it's worth setting up the IDE properly, indexing the project, maintaining the IDE configuration, and learning the shortcuts.

But if you are jumping into a lot of different projects that were written by a lot of different teams, and making tiny, local edits, configuring an IDE properly for each new project is a pain. Startup time on a new project is more important than advanced refactoring. It's hard to beat an editor for opening a file or directory you've never seen before and making a quick edit. You can be done before a more powerful IDE has even finished indexing the source code.

The newer editors are gradually getting more IDE features without losing fast startup, so I find them appealing even with a lot of experience with IntelliJ.

     > It's hard to beat an editor for opening a file or directory you've never seen before and making a quick edit. You can be done before a more powerful IDE has even finished indexing the source code.

I can't imagine this _ever_ being the case. Setup of an IDE is trivial compared to wrapping one's head around the first time look at a new project. I mean, you're talking about cracking open a new project you've never seen, making an edit and "being done" in a matter of a few minutes !

This is perhaps doable if you're talking about assembly-line-cookie-cutter projects, or maybe you're talking about super-geniuses? It takes me a minimum of hours to days before I'm ready to "make a quick edit" on a project I've never seen.

Plus, per-project IDE configuration should be extremely minimal—maybe 15-20 minutes at most?—so I can't imagine that ever being a bottleneck for a new project.

If you're correctly automating and using templates, setting up the base for a new project shouldn't take more than 5-10 minutes.

One of my first jobs was writing PHP when editors only had syntax highlighting support for the language. I learned to write, debug, and refactor in Vim and 15 years later I’ve continued to do the same for Java, C, C++, JS, etc. Projects with 10s of KLOC (one of them might be 100s).

It’s a different state of mind from IDE users. Not better or worse, just different. I’d hate to be stuck in IntelliJ all day, but most of my colleagues love it. As long as we’re all productive, to each their own.

That said, I’m a polyglot, so learning specific IDEs and plugins for all of the different languages and DSLs I use throughout the week sounds miserable to me).

I learned to code in Jupyter notebooks. I can't wrap my head around an editor or IDE, I build programs by writing small snippets of code, with all my variables loaded. When it does what I want I move to the next cell. Eventually I'll paste it all into a text editor do some final debugging and that's it. It is very annoying though when I want to start on an old program. I think I should try Spyder or something soon.

A quick edit might be something shallow like changing a config setting, editing a template, or maybe fixing a bug where you have the stack trace and it's a one-line change. You can find the file to edit based on a search, make a quick patch, run tests, and send it for review by someone who understands the project better. Deep understanding is not required.

> Amongst the current crop of engineers, there seems to be a stigma against even trying Eclipse or IntelliJ. I kind of feel like junior engineers are missing out on discovering some much more powerful tooling and forming their own opinions.

For me it's the text editing features that these IDEs lack. I'm definitely giving up advanced language integration, but I (and many) make the choice to do this for more powerful and/or preferred text capabilities.

Vim, Emacs, Kakoune being my main examples. Not just a "vim mode" - I've never used one of those that was even remotely useful for me, heh.

The jetbrains editors are amazing, if you learn the keystrokes. I see few bother to explore/learn them though... I haven't found an editor that matches the features.

My main prob with jetbrains is project setup sucks, and the support for quick editing an arbitrary file is awkward. so for quick editing of a file I end up in atom or vim. I'm currently trying to get vs code's editor to be as similar as possible to intellij as possible. it looks like code's editor is pretty solid and full featured.

What are some text-editing features that you find IntelliJ lacking?

It's more about the style of editing. Ie, right now I massively prefer Kakoune style editing. I choose that over Vim, despite Vim having much wider support.

When compared to Vim, it's not about one specific "feature" that vim lacks, it's Vim, it has just about everything - it's about my editing UX, and vastly preferring how Kakoune does it.

Now would I choose IntelliJ if it could perfectly replicate how Kakoune does editing? Without a doubt I'd choose IntelliJ. Yet I massively doubt that's even possible.

Fwiw, I've been dying to use a GUI editor, but I cannot give up first class implementation of my text editing methodology of choice, be it vim, Kakoune, etc. It's not about "is it possible to do X", it's possible to do nearly everything in Notepad.

Can personally confirm, I tried learning .Net Core by starting a MVC project on my Mac with VS Code, and after a few months of pain I found Rider which works on both my Windows and Mac machines, and works much better.

As far as I'm concerned, either go whole hog with an IDE or stick with lightweight editors like Sublime/Vim/Emacs and rely on CLI tools to find errors.

I never got an IDE to properly work with a C project. Even vendor provided IDEs tend to break in many subtle ways.

There are just too many opaque things going on, everything is slow and if you don't sick to the workflow intended by the authors of the IDE, everything is lost.

I feel like if the language has not been designed with an IDE in mind, it's hard to get the integration right.

Plugins make this somewhat usable, and they usually mean that it's easier to get some of the features for smaller languages. A lot of small languages only have plugins for Emacs, Vim, Atom, and VSCode. Sure, if you're doing Java, Eclipse is great. But if you're doing Nim or Idris or something else small...

Coming from a background of using emacs & vi, I actually feel the exact same way about Eclipse, IntelliJ, Atom, SublimeText & all the like. It's odd to me to have such painful extensibility & so few tools to let me actually automate tasks, and so many layers of complexity to get in my way.

I feel that engineers who don't try out emacs & vi really are missing out on some amazingly powerful tooling (more so emacs than vi — but vi lives within a Unix shell in much the same way that emacs's text-editing capabilities live within emacs-the-OS).

I actually wonder about this too. At my previous job, nobody was using IntelliJ despite developing in Scala and Java. The code base was complex, not using an IDE had a noticeable effect on the kind of code people were writing. The code was much less cohesive, and looked more like a series of scripts than well architected.

I've been using WebStorm and find myself using more and more VSCode which seems to be catching up. The three key differences for me are 1) licensing (working in different environments and can not always bring my own tooling or get tooling for the team fast enough to make it worth my while). 2) State: VSCode may not have a in depth model of what is going on but I can point it anywhere and get immediately some level of productivity. 3) Language agnostic. I often don't even know what I will encounter when I start out.

Working longer on a larger code base I would prefer a specialized IDE like WebStorm hands down but that seems not to happen so frequently.

JetBrains offers a ~ $200/year subscription license that gives you all of their tools, for exactly that scenario, IE: I need python on this project, ruby on that one, etc. As a professional developer, $200/year is just a small business write-off and totally worth the money to have one set of tools that I can bring to bear on any project. So, you might check that out to overcome your licensing concern, if you prefer WebStorm et. al over VSCode.

Just checked, for individuals the "All Products Pack" is $250/yr. and for Organizations/Corporate use is $650/yr./user

Maybe I got a "repeat buyer" discount or something then. Either way - even at $650/year it's just the cost of doing business / immediately deducted from your taxes.

For me it’s 99% about performance. IntelliJ is dog slow. I simply won’t accept an application with that level of cruft to run on my machine 24/7. Give me a simple text editor.

Also, if you have so many instances of a name in your codebase that you need automated tools to change it, and you haven’t already split that code out of the repo into a well named and stable library, I consider that a code smell. You’re building your house on jelly.

In the rare case I end up in that spot, I can use sed.

Intellij can be made faster by: Using SSD Stuffing jdk on ramdisk Disabling inspectors you do not need

> "I have one file called index.js"

Say it all really. Online coding tools may be fine for beginners, but think it would be next to impossible to do my work with one.

Ultimately the best dev environment is one you have full control over. Even if it's X forwarding over SSH, at least you know you've configured the tools on the remote system.

I have to agree, I mean sure PyCharm can be complicated, but it has so many things that a beginner doesn't need and doesn't understand that to me doesn't even seem fair to put them on the same plane. Sure, you write code in both of them, but they don't really serve the same purpose.

What if all the features of an IDE existed for online coding tools? I actually maintain a list of these tools[0] and several of them are very close to the native experience.

In particular, CodeSandbox has come a long way by basically running VS Code in the browser.

[0]: https://github.com/styfle/awesome-online-ide

They still would not be nearly as fast. When I'm working with projects consisting of hundreds of files measuring hundreds of lines each, I need an IDE that's capable of using the full performance of my workstation

That's true, especially for client-side based online IDEs. At Repl.it we have a hybrid approach where a lot of the IDE-like functions like code intellisense run on the server: https://repl.it/blog/intel

A counter-argument to this is that all files you need are stored in 'the cloud' and performing searches/indexing/refactoring would happen _faster_ than on your workstation because it can take advantage of a lot more 'cloud' resources.

My work computer is 8 cores, 32gb and a GPU; why do you imagine that a hosted instance somewhere running the web server is going to do a better or faster job than my local computer? Hell, even my laptop is going to do a better job than a cloud server.

Not 'a hosted instance' or 'a cloud server', but many. An arbitrary amount. Personal anecdote: Local full builds for me take 28-30 minutes. When I farm it out to our infrastructure in AWS it takes 9 minutes.

Well, I actually do all my professional work inside (neo)vim.

I even use to have a remote instance for developing and testing... I can definitely do all my work in a simple (multiplexed) terminal, whenever it is online or offline.

Of course, given a stable connection.

Where did you get this from? The blog you're reading this on is built and hosted on Repl.it (https://amasad.me/__repl) and it's source is 50 files and if you count node_modules that's thousands of files.

The bottom image, its a Reddit screenshot.

Yeah they're describing their current issue, doesn't mean that's all he needs or all that it provides.

I don't know if this counts as the same thing, but I've recently started a Rails-based project on Google Cloud, using the cloud shell and its built-in editor. This is great because I don't have to futz around with a Vagrant environment or (worse) a straight Rails dev environment on my Mac, and I can do full-strength software development from the little Chromebook I like to carry around.

A Chromebook plus a 100% cloud-based dev environment is a great way to work without having to radically rethink How Software Works.

Just to be clear, what you carry around and enjoy using so much is essentially a wireless terminal to a mainframe.

Is that a Bad Thing? The alternative is to carry a snowflake environment around with me.

You can make the environment less of a snowflake.

Nix, to automate software installs and per-directory (per-git repo) environments. NixOS, to do the same for your OS.

Gradle, for automated IDEA setup. Or check the config into git. Cachix, to ensure your build artifacts remain available.

These problems are solvable, and the solutions already exist.

Well, yeah. But it's still a snowflake, a dev environment with build/deployment configuration and needs that are significantly different from production cloud environments. And it requires a lot of setup, and a lot of knowledge to do it well (which I actually have). Writing a bunch of automation to hide the fact that I'm working on a snowflake is not the same as not working on a snowflake.

Or, I can do my development in the cloud, in an environment explicitly more similar than my desktop environment. Other than aesthetics, I don't see why this is a Bad Thing. It's making my setup easier and more consistent, and it's making my development environment portable to whatever system I want to work from, rather than binding it to a piece of hardware.

Ah, memories of those DG/UX X Windows terminals accessed for the very first time in 1994 and VT 100 green phosphor telnet terminals, followed by the freedom of having Slackware 2.0 on my PC a year later....

Thank Dog it isn't 1995 anymore.

(Memories from the same era - hand-rolling TCP stream protocols in lexx and yacc, because XML didn't exist and http was a toy)

It is ironic how we rejoiced with the freedom from the mainframe just for the current generation to go happily back to it.

Especially since absolutely nothing has changed from then to now

My hardware and OSes of choice state otherwise.

I see no argument here made about hosted services like Repl.it that doesn't also apply to a simple ol' terminal emulator, or other forms of development environments. I feel like the real topic here is that there are effective developer environments on the web which can be accessed regardless of walled garden app stores.

I'm trepidatious however, since I'm not a huge fan on relying on external services in general. "I can't code because the server's down" doesn't seem acceptable to me. There is a very real problem with mobile development environments though, a solution I'd like to see start with the phone manufacturers.

I've never heard of repl.it, but the concept reminds me of a project that uses a Javascript REPL/IDE to try to make embedded development more approachable called 'Espruino':

https://www.espruino.com/ide/

It's nice for learning, because you can get the immediate feedback of a terminal with physical hardware. It is extremely limiting in that you can only have one file open in the IDE though, so it is unfortunately difficult to justify for anything other than teaching or toy projects.

I think the basic idea is sound. If all you're after is learning to program and running little toy programs, then web based REPLs are a great choice.

My primary development environment is vim combined with CLI commands (and some wrapping with vim plugins to simplify the workflow). However, when I want to play around with something in Go to figure out how it works I will often go to The Go Playground (https://play.golang.org/) and play around there.

However, as soon as I'm done (and maybe shared my findings with a peer, which I can't do as easily with my local vim + CLI environment) I'm back to my regular development environment because very little that I work on is trivial enough to stay in Go Playground.

All that said, I've seen plenty of developers who seem to get by sticking to the basic feature level of Notepad. Whatever works for you.

It sounds like users are trying to get back to working with a system image.

I have trouble labeling it "post-IDE". Depending on whether you consider Smalltalk/Lisp machines to be "IDEs", it's either "original IDE", or "pre-IDE".

I think the Lisp community invented tools that, had they been successful, would've altered the course of history with regards to devtools. I wrote an essay on this: https://amasad.me/disintegrated

I've read the comments here, and perhaps due to my job not being purely software development, I have a different impression of Repl.It. I'm much more of an infrastructure guy than a developer, (DevOps? So overused) and I'm not overly ashamed to admit I learned to code with Powershell, mostly via their integrated scripting environment. Trying to make the switch from ISE to pure Python was extremely difficult for me, because I was so deep into the REPL style, and I just wasn't prepared to have things obfuscated and invisible. I wanted to re-run specific lines of code, and determine variable values on the fly, so I could adjust if needed.

Eventually, I learned Ruby (and abused Pry for a long time) "correctly" and I"m re-learning Python the proper way now (and abusing pdb), mostly with VS Code, but there are some very large gaps that are easily filled with a good REPL, so I find myself popping over to Repl.it to test out some snippet that isn't doing what I expect. Perhaps there is an IDE setup that would do what I want while enabling me to be more productive, but learning a (usually lightly documented) tool, full of various assumptions, while trying to learn the actual language, AND get useful work done, is not an ideal combination.

amasad, I enjoyed the perspective of your article. I agree an engineer with many years of experience is going to have different expectations to someone who is entering the profession today. I think it's similar to my perspective on the iPad – I find it interesting but limited because my experience and mental model of computing is very different to someone who is growing up with an iPad in hand.

I work on the Web IDE at GitLab (among other things) which we built after we noticed that there were a few situations in our day to day work on GitLab where we didn't need a full local development environment, like updating documentation or addressing simple review comments. It doesn't replace a local IDE from me yet, but it is helpful and we hope we can make it more useful in more situations where local IDEs have shortcomings. I think the effort and maintenance of a local development environment is also a cost that is frequently overlooked – reinstalling dependencies is a headache that disappears in an automated ephemeral environment like repl.it or where we're heading at GitLab.

But that seems like it's just an iteration on the status quo rather than leap frogging to a post-IDE world. I think the idea of online interactive development can go so much further. Maybe we can integrate interactive editors/terminals/previews with our planning and code review tools so that experimentation and exploration are easier and happen in line in the discussions we have planning the next feature to build. I put a few dot points down on this line of thinking last week https://gitlab.com/groups/gitlab-org/-/epics/533 but I'd be interested to hear some of your more concrete ideas of what a post-IDE world might look like.

> But that seems like it's just an iteration on the status quo rather than leap frogging to a post-IDE world.

I think the fact that you'd have a globally accessible, pay-as-you-go, zero-setup, multiplayer programming tools is surely a different beast from the IDE. However, it does go further than this and most of the innovation to this end aren't coming from us but from our users and how they (an)use the system. I can try to predict what the post-IDE world looks like, but it's better to discover it.

In theory, this makes sense. But I'll be cautiously optimistic about this. We've had this sort of "app is always running and changes are seen live" technology with Visual Basic since a long, long time ago. But that mode of development is hardly the norm across the wide spectrum of developers.

Next time, please disclose the fact that you are the founder of the product you are promoting.

So I know you wanted to frame this as IDE vs. REPL, but most IDEs have REPL built in (I think every Python IDE can open Jupyter notebooks no problem), and the additional features just depend on context. Like, scientific computing with Python, R or Matlab? You'll probably profit a lot from using RStudio, Spyder or, well, Matlab. Huge projects with lots of data and many files... why go through the pain of a html-based file management system if you can have as many text-editors and IDEs installed as you like... I mean, the choice you frame just isn't really a relevant question.

Instead, this is clearly a marketing article for your own product. You specifically ask the question in your article, why would anyone install an IDE locally, instead of using your product.

The answer seems very obvious to me: Only very few people can actually use an online interface, such as your product, in actual production.

For me, for example, it would be a non-starter. Not only do I work with sensitive data that I can't just upload to somewhere else, I am also often on the road and simply do not have guaranteed internet. So I'll need a local IDE anyway. Another reason is that the actual computing infrastructure is located, and protected, in a local network. So I couldn't even run my code directly. How much computing power do you actually provide? What if I actually generate large output files? Where do they go? Like, do you just send me gigabyte sized files over the tubes constantly? Do I have to download thousands of files from that terrible web-interface? How do you deal with changes in massive datasets? How do you deal with those data that need to stay local?

The whole article is just weird. The use-case for local IDEs is pretty clear, and I think the people who actually have to use some local solution is, and will be, larger than those who just casually write their code in your datasets. Most people would literally get fired for using your product as you suggest.

In fact I think the major use-case for your product is education and learning, specifically where you code in several languages. Like, you quote some kid asking why one would like to learn an IDE if repl.it is so cool and good. Well, that kid is obviously learning and not leapfrogging anything. Sooner or later, he/she will be coding in a company on a larger project and then all of the above applies.

I also like the irony of repl.it stating its support for Open Source, while apparently not being OpenSource itself.

the 60s/70s had already better tools for dial-in on mainframes.

How is repl.it different from a bunch of other web IDEs that came and went without leaving a mark?

This doesn't necessarily translate to production-level programming, but I used to teach computer science to middle and high school students. I originally used Cloud9, and had to walk students through the process of setting up a Github account, going through and setting up a proper dev environment, ensuring that their file space was showing and walk them through the run server commands. Very heavy stuff and ate into valuable time every class.

With repl.it, it was simply a matter of typing out a bitly link and hitting enter and everything was set up and ready to go.

TL;DR:

Repl.it member (amasad, see note) wants to promote Repl.it by saying that more people are using Repl.it and thus it is the modern stuff because modern is having "no IDE, just a modern repl" and etc. So "modern, 2018" is basically having what Lisp developers have had since the early '80s.

* https://repl.it/site/about

> what Lisp developers have had since the early '80s

We absolutely did not have a globally, network-accessible terminal with pay-as-you-go computer time.

I have no experience or interest in repl.it, but I think you're understating things somewhat.

The article seems to be saying that the advantages of repl.it are the advantages of a REPL-based development platform, not remote access:

> With programmers growing up today being used to instant and interactive programming like Repl.it, Jupyter Notebooks, serverless compute, and others, it doesn't seem so outlandish to imagine a post-IDE world.

Lisp Machines and Xerox PARC workstations had network access.

In fact, parts of Ethernet protocol were researched at Xerox.

Access, but usually they were not serving their IDE to the outside and there was only one active user per machine.

True, but you could have document parts which were actually remote, no?

sure, but how is this related to a global system where you login and get your IDE from? With a Lispm you already have your IDE locally running.

Ah ok.

What you did have was Symbolics, and I think this still falls somewhat short of that experience.

I wrote another essay on how Lisp got a lot of things right but we ended up where we are today because Unix, aka the New Jersey approach, aka worse is better approach, had won over: https://amasad.me/disintegrated

I think this is too much interpreting into it and the specific, and very different, views of people like Alan Kay and Richard Gabriel. Alan was a visionary who actually thought a lot about making programming and computing accessible - even to children. In the Lisp/AI community SOME were working on similar things (Minsky influenced LOGO for example). Richard Gabriel was running a Lisp vendor, which addressed the UNIX market with a higher-end Lisp development and delivery tool: Lucid Common Lisp. You'd shell out $20k and often much more for a machine and a LCL license. Customers were wealthy companies and government - the usual Lisp/AI customers who also wanted to deploy stuff efficiently.

> See the Lisp community practiced the Right Thing software philosophy which was also know as "The MIT Approach" and they were also known as "LISP Hackers".

A typical mistake is to believe that there is a single homogenous Lisp community, a single approach or a single philosophy. In fact the Lisp community was and is extremely diverse. If you look at the LISP hackers, their approach wasn't actually to do the 'right thing' (whatever that is), but to tackle interesting problems and having fun solving it. The Lisp Hackers at MIT (and other places like Stanford) were working for government labs swimming in money and people like Marvin Minsky provided a fantastic playground for them - which then clashed with the 'real world' when DARPA wanted to commercialize the research results it funded, to move the technology in to the field of military usage (also doing technology transfer into other application areas like civilian logistics). If you've ever looked at the Lisp Machine code, you see that it is full of interesting ideas, but the actual implementation is extremely diverse and grown over time. Often complex, under-documented, sketchy - not surprising since much of that was research prototypes and only some was developed for actual commercial markets. The 'MIT Approach' was creating baroque style designs. Is it the 'right thing' to have a language standard telling how to print integers as roman numbers?

Thus 'the right thing' might not be what you think - I think it is more 'image' than reality.

> The destiny of computers is to become interactive intellectual amplifiers for everyone in the world pervasively networked worldwide

That was Alan Kay's vision, not the vision of the Lisp community. Kay's vision was personal computing - and not the crippled version of Apple, IBM and others. Much of the Lisp community was working on AI and related. Which had much different visions and Lisp for them was a tool - they loved or hated. Lisp/AI developers think of it as 'AI assembler' - a low-level language implementing much higher-level languages ( https://en.wikipedia.org/wiki/Fifth-generation_programming_l... ). When no effective systems were available to be used as powerful development environments for small and medium-sized research groups - they invented their own networked / interactive development system using the technology they knew best: Lisp. They hacked up development environments and even operating systems. But it was not necessary to keep them, once similar platforms were available from the market. With Lucid CL one could develop and deploy a complex Lisp application on a UNIX workstation and were not bound to a Lisp Machine - which was still more expensive, used special hardware/software and was less general as a computing platform. Lucid CL was quite successful in its niche for a while - but Gabriel then tried to make that technology slightly more mainstream by addressing C++ developers with a sophisticated development environment - sophisticated, and expensive. This tool was then sinking the company. But, anyway, much of the commercial AI development moved to C++ - for example most of the image/signal processing stuff.

Parts of the Lisp community shared different parts of the Kay vision: OOP as basic computing paradigm (Flavors, Object Lisp, CLOS, ...) , accessible programming (LOGO as an educational Lisp dialect), intellectual amplifiers (AI assistants) - but where Kay developed an integrated vision (Smalltalk and especially Smalltalk 80), the Lisp community was walking in all directions at the same time and this created literally hundreds of different implementations. Simple languages like Scheme were implemented a zillion times - but only sometimes with an environment like that of Smalltalk 80.

The Lisp community addressed both medium and high-end needs. Something like Interlisp-D (developed right next to Alan Kay - but as a development tool for Lisp/AI software and not addressing programming for children and similar) was a very unique programming tool, but its user base wasn't large and more towards the higher end of development - most of it still in AI. There was no attempt to make that thing popular in a wider way by for example selling it to a larger audience. It was eventually commercialized, but Xerox quit the market with the first signs of the AI winter in the 80s. Its actual and practical impact was and is also very limited, since only very few living developers have really seen it and almost no one has an idea what to do with it or even how to use it. It's basically lost art. I saw them in the end 80s when they were on they way out.

I doubt that from hundred authors of advocacy articles has even one used something like Interlisp-D or Lucid CL to develop or ship software. I know only very few people who have actually started it, even much less having seen it on a Xerox Lisp Machine. So much of it is based on some old people telling about it and very few have ever checked out how much of what they hear is actually true and how useful that stuff actually is. One reason for it: it's no longer available.

The 'worse is better' paper was slightly misaddressed at the Lisp users - since they were not after the operating system and base development tool market (like UNIX and C was) and were not married to a particular system or environment. They used Lisp on mainframes in the 60s/70s, on minicomputers in the 70s/80s, on personal workstations (even developing their own) in the end 70s / 80s and personal computers from the 80s onwards - unfortunately Lisp never really arrived at mobile systems - though it participated in an early attempt (transferring a lot of technology to the early Apple Newton - or what it was called before it was brought to the market - projects). The main Lisp influence on what we see as web technology, was the early influence on Javascript.

Reply on news.ycombinator.com