[ruleabidinguser]

I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms.

This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.

[brlewis]

I hope you're right that this goes the way of emacs. I've been productive in emacs for 30 years, but I'm growing impatient for emacs to get a real programming language with lexical scoping like they were talking about doing with Scheme 20 years ago. Despite its lack of macros, JavaScript is arguably a better Lisp than Emacs Lisp. I've toyed with Atom a couple of times recently and am seriously thinking of switching.

[lispm]

Emacs Lisp in GNU Emacs has now lexical scoping...

[brlewis]

Oh cool how did I miss this? https://www.emacswiki.org/emacs/DynamicBindingVsLexicalBindi...

[ruleabidinguser]

See, I just don't understand why you would want to use emacs over an editor that does all the work for you. Thats why I avoid it, it seems like a big cost that I don't have to pay if I just use a different editor.

[philsnow]

How do you think an IDE "does all the work" for you? Somebody working on the editor wrote some code in C++ or Java or whatever that makes it do that, and that code is baked into the IDE.

In emacs, the only missing part is that perhaps nobody has already written the elisp that makes it do whatever task you are asking for.

emacs is a smallish program written mostly in C that defers to a scripting language for nearly everything, and it ships a bunch of code in that scripting language that does all the work of being an editor. You can look at that code using the editor itself, and you can change that code using the editor itself. It's insanely flexible and extensible; see e.g. advice [0], and most modules provide meaningful hooks for you to add your own code.

All the IDE/editor behavior is just code. If it's compiled and baked into your IDE, fixed, unchanging, then if there is any behavior you don't like, you better hope the dev included a knob that lets you tweak it, or you have a lot higher barrier to making your editor work the way you want it to.

[0] https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad...

[ruleabidinguser]

Thats exactly my point, theyve written all the various features you might have to write yourself, and theyve integrated them for you.

[philsnow]

guess it's a tradeoff. if what you want is common enough, it's quite possible it'll already have been written. if not, you may have to write elisp yourself.

but, if what you're working on is not common, maybe there isn't a (good) IDE either.

[brlewis]

Whether an editor needs to be programmable or not depends on what "all the work" is. If you're doing the same exact work as everybody else then certainly a programmable editor is overkill. If your work is different, then programming is how you tell the editor what it means to do all the work for you.

[michaelmrose]

People seem to ridiculously inflate this cost. If you are going to be using a tool for 40 hours a week 50 weeks a year for the next decade then you will be using it for 20,000 hours over the next decade.

Spending a few hours to configure it to your liking. In fact if you start atom and wait 6 seconds for it to start just once a day then twice wait 3 seconds for a new window you will in the same time frame have waited 8 hours for atom to start.

[ruleabidinguser]

Heres the thing, its a cost you pay for every single project you start and every change you make to your build system. Emacs makes it possible but hard to maneuver, by my reckoning.

There are some really giant projects where that becomes reasonable, but for me thats just not the case. And if I were going to invest time like that, I'd rather invest it into an environment which has a higher ceiling for what it can do (emacs doesnt provide fast/rich/easy autocomplete, for example)

[tree_of_item]

> This seems destined to go the way of emacs.

Hilarious. Emacs is one of the most successful programs of all time in my book. If I ever made an editor I'd pray every night that it'd be at least half as successful as Emacs.

[chickenfries]

It's a benefit if your engineers already know JavaScript, obviously.

Also, emacs is one of the most successful text editors so I'm not sure I get your comparison.

[ruleabidinguser]

I don't consider emacs successful. Succesful among fanatics, maybe, but I don't consider is valuable to a serious programmer.

Also, surely it's not that hard to switch languages? In my experience all languages are essentially the same.

[coldtea]

>In my experience all languages are essentially the same.

That's the problem: you don't seem to have enough experience.

[ruleabidinguser]

I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive?

So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week.

How much experience do you think I have? I've used plenty of languages, and I'm well aware that there are nuances.

[coldtea]

>So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week.

That's because you either used the languages superficially, or use only very similar languages, probably of the Algol family (e.g. Ruby, Python, PHP, JS, etc).

You won't get very far with Haskell "over the course of a week". Or APL. Or Idris. Or Erlang. Or Lisp -- or any other language that's not a mere Algol derivative with some different bells and whistles. And even those have their idioms, of course, that one needs much more than a week to get competent with, but, it gets worse when we expand languages to not be "mainstream Algol derivatives". One would only be using languages like Smalltalk, OcamL, Scheme, Scala, Self, etc, superficially without getting into their idioms and nuance, which wont happen in a week (and can take years to really master).

[ruleabidinguser]

Well of course you can't include languages like Haskell in the group of interchangeable languages. Incidentally I have used Haskell (and it did take more than a week). But it doesn't matter because we're talking about moving JavaScript developers to Java, or C++, or as you say, Algol-likes.

[tree_of_item]

> I dont seem to have much experience? Based on what?

Based on the fact that you think all programming languages are essentially the same. That's just a ridiculous claim and it immediately exposes you as someone who's only used a couple of Algol derivatives.

[ruleabidinguser]

2 things

1. I don't think literally all programming languages are the same

2. I have used Haskell, and am very aware of every language listed in the other replies to this comment, so you're completely wrong.

I kind of thought this community was better than this, to be honest.

[computerex]

Not useful to serious programmers? Do you feel the same way about Vim? Just because you haven't gotten used to using something, doesn't mean it's necessarily total shit. There is a reason why people have been using emacs for decades.

[ruleabidinguser]

I do actually, and I should reword that to "not useful for serious programming." VIM to me is best used for lightweight, quick and short editing tasks. THats how I use it. For any involved work, you're going to want a debugger, you're going to want automated build tools, you're going to want effortless compile/run cycles and so on..

You don't really want to implement all of that in VIM because your work won't be portable.

[scott_s]

I have all those. They're just not integrated into my editor. I use vim; it is my editor, but not my development environment. Unix is my development environment.

[ruleabidinguser]

I;ve tried that approach, and its cumbersome to remember all the different commands, flags, combinations etc. I might need for each different project and for each different task. IDEs simplify this process dramatically. Its akin to GUI v DOS in terms of usability benefits.

[computerex]

Sounds to me like you aren't familiar with Vim and the ecosystem. Plug-ins are your friends. Use a package manager like Vundle to easily install plug-ins. Not sure why you say vim isn't portable. I have my vimrc file on my github. Not only is vim available on all major platforms, it comes pre-installed on a bunch of systems. All I need is my vimrc file, Vundle and an Internet connection to customize any vim install to exactly how I want it.

[michaelmrose]

Do you really conflate suitable to your own tastes with being useful or not? Further in what profession is any tool "all the same" See the blub paradox.