Atom Shell is now Electron(blog.atom.io)
blog.atom.io
Atom Shell is now Electron
http://blog.atom.io/2015/04/23/electron.html
83 comments
I'm glad to see Electron / Atom-Shell moving forwards, but I wish they'd publish a roadmap. There are things (like copy/paste) that are lacking and I'd like to know what the plans are. As it stands it's mostly a wait-and-see kind of deal, which is a bit disconcerting on big projects.
What does Electron do differently from NW? I get that one is Chromium and the other is just webkit, but what concrete, practical differences are there?
Both are Chromium.
Node Webkit has a forked version of Chromium Source with modifications (removed the event handler and replace with NodeJS one and a bunch of others). Seen at https://github.com/nwjs/chromium.src
Electron uses the Content framework and has no modifications to Chromium. Directly calling the required parts from the source (example https://github.com/atom/electron/tree/master/chromium_src/ch...).
That is the major difference, in regards to architecture. Basically in Atom you need to create the Window, and in NodeWebkit you always have a Window and you need to do stuff to that Window.
The other ones include things like backers, NodeWebkit is backed mostly by Intel, as one of their developers is who is building it. Atom is backed by Github bunch of others.
Node Webkit has a forked version of Chromium Source with modifications (removed the event handler and replace with NodeJS one and a bunch of others). Seen at https://github.com/nwjs/chromium.src
Electron uses the Content framework and has no modifications to Chromium. Directly calling the required parts from the source (example https://github.com/atom/electron/tree/master/chromium_src/ch...).
That is the major difference, in regards to architecture. Basically in Atom you need to create the Window, and in NodeWebkit you always have a Window and you need to do stuff to that Window.
The other ones include things like backers, NodeWebkit is backed mostly by Intel, as one of their developers is who is building it. Atom is backed by Github bunch of others.
There's a wiki entry for that :
https://github.com/atom/electron/blob/master/docs/developmen...
https://github.com/atom/electron/blob/master/docs/developmen...
Here's a Stack Overflow answer to that question: http://stackoverflow.com/questions/23509356/node-webkit-vs-e...
interesting to see how many things have already switched to building on electron.
Slack, Mapbox and more.
Slack, Mapbox and more.
This would interest me more if there was a good automatic build process for it (in the style of node-grunt-webkit-builder).
As it is you still have to do a bunch of the packaging manually (or design your own shell script for it), and for whatever inane reason, `npm install electron-prebuilt` only downloads the binary for your current platform, so you can't even make a replicable build process by using it as a base and using scripts that copy the different binaries.
As it is you still have to do a bunch of the packaging manually (or design your own shell script for it), and for whatever inane reason, `npm install electron-prebuilt` only downloads the binary for your current platform, so you can't even make a replicable build process by using it as a base and using scripts that copy the different binaries.
Is it suitable for WYSIWYG or a plain text & source code editor? Does it originate initially from Mozilla's Ace text editor? https://github.com/ajaxorg/ace The name changes are a bit confusing (Mozilla Bespin -> Skywriter -> Ace ->(?) Atom -> Electron).
So, it looks like there's a number of things you're confused about. First, Atom doesn't have anything to do with Mozilla's Ace or Bespin. Ace and Bespin (now Cloud 9) are tools that live on a server, which you access through a browser.
Atom is a completely separate project (started by Github, not Mozilla) to build a native text editor using web technologies. The text editor is a native application, but it exposes a Javascript API for plugins. After a while, Github realized that the infrastructure needed to make Atom work (e.g. installers, updates, notifications, etc.) could also be used by other projects, so that code was split off into "Atom Shell". It's this project that's getting renamed to "Electron".
Atom is a completely separate project (started by Github, not Mozilla) to build a native text editor using web technologies. The text editor is a native application, but it exposes a Javascript API for plugins. After a while, Github realized that the infrastructure needed to make Atom work (e.g. installers, updates, notifications, etc.) could also be used by other projects, so that code was split off into "Atom Shell". It's this project that's getting renamed to "Electron".
Atom Shell != Atom
It is the, well, shell of the Atom editor.
It is the, well, shell of the Atom editor.
Electron's / Atom Shell's homepage isn't doing a good job of explaining what it is (as someone who's unfamiliar with it). Is it a site-specific-browser implementation? It's certainly not a "shell" in the normal sense of the term.
>Electron is the cross-platform application shell we originally built for the Atom editor to handle the Chromium/Node.js event loop integration and native APIs.
Sounds pretty straightforward to me. They created APIs for Node.js to allow people to make cross-platform applications, such as Atom (a text editor).
Sounds pretty straightforward to me. They created APIs for Node.js to allow people to make cross-platform applications, such as Atom (a text editor).
Is it me, or does it sound a bit bloated:
> It now includes automatic app updates, Windows installers, crash reporting, notifications, and other useful native app features
* automatic app updates : We have distribution repositories for this. * windows installers: Doesn't window have it's own like app store now (market something?) * notifications: which we already had on all major OSs for years.
> It now includes automatic app updates, Windows installers, crash reporting, notifications, and other useful native app features
* automatic app updates : We have distribution repositories for this. * windows installers: Doesn't window have it's own like app store now (market something?) * notifications: which we already had on all major OSs for years.
Obviously you don't have to use any of those features, they won't slow your app down just by being available (maybe a tiny overhead in distributed code size, but meh).
- auto updates : primarily useful for commercial software that isn't "eligible" for, or chooses not to pay to use, commercial app stores. Or other apps that for whatever reason don't meet the criteria for public repositories and don't want the hassle (for the publisher or consumer) of using a private repo.
- Windows installers : same reasoning as above.
- Notifications : I believe its a standardised cross-platform api onto the existing system-specific notification apis, not a new notification system.
- auto updates : primarily useful for commercial software that isn't "eligible" for, or chooses not to pay to use, commercial app stores. Or other apps that for whatever reason don't meet the criteria for public repositories and don't want the hassle (for the publisher or consumer) of using a private repo.
- Windows installers : same reasoning as above.
- Notifications : I believe its a standardised cross-platform api onto the existing system-specific notification apis, not a new notification system.
Im curious about the name change. What do they stand to gain from losing all of the history of atom shell search results?
Atom Shell is no longer tied to Atom the text editor by name. It makes sense to change the name as Electron becomes more popular in projects outside of Atom.
i think it's because electron is being used to build more than just atom.
having it be that deeply associated with the other brand reduces the visibility of the project?
having it be that deeply associated with the other brand reduces the visibility of the project?
It would still be easy to find the project via google. Just googling "atom-shell" will probably get you this article, and from there a user would figure out that it's been renamed.
Because now they can write a blog post about it, which duly appears on HN's front page.
Would it be possible to combine the project with Cordova? I don't use PCs or laptops anymore because they are outdated.
Awesome, may they continue naming things after Acorn computers of the 80s.
The thing that turned me away from Atom and its' development is CoffeeScript. As someone who loves idiomatic JS, I still can't get why you'd pick a language that makes tooling and debugging a nightmare. It's also a kick in the gut to efforts to fix the shortcomings of ECMAScript like ES6 [1].
[1] https://github.com/lukehoban/es6features
[1] https://github.com/lukehoban/es6features
> It's also a kick in the gut to efforts to fix the shortcomings of ECMAScript like ES6 [1].
irony alert: Brendan Eich has said publicly that CoffeeScript was the impetus for several of the features that made it into ES-6, like fat arrows.
Without CoffeeScript, lots of people wouldn’t have known that they wanted some of the things that are in ES-6.
As it is, you don’t need CoffeeScript to develop for Atom. Which is part of the beauty of CoffeeScript. It’s interoperable with what you’re doing today.
irony alert: Brendan Eich has said publicly that CoffeeScript was the impetus for several of the features that made it into ES-6, like fat arrows.
Without CoffeeScript, lots of people wouldn’t have known that they wanted some of the things that are in ES-6.
As it is, you don’t need CoffeeScript to develop for Atom. Which is part of the beauty of CoffeeScript. It’s interoperable with what you’re doing today.
irony alert: Brendan Eich has said publicly that CoffeeScript was the impetus for several of the features that made it into ES-6, like fat arrows.
As it is, you don’t need CoffeeScript to develop for Atom. Which is part of the beauty of CoffeeScript. It’s interoperable with what you’re doing today.
Let's say the community had their way, and Atom was rewritten in JS well.
There's still a JS/V8/Chrome for a dependency. On an application where we're rendering huge walls of text - we forgo native redraw. Crucial to response time.
It's fun and time-saving for core developers to forgo the grueling work of portable, native, fast code.
But who pays the cost for the shortcuts?
> The thing that turned me away from Atom and its' development is CoffeeScript.
...
> There's still a JS/V8/Chrome for a dependency. On an application where we're rendering huge walls of text - we forgo native redraw. Crucial to response time. > What makes Atom a viable choice when there already is free, open source, native, cross-platform editors with great plugin ecosystems?
I guess maybe CoffeeScript isn't what turned you away?
...
> There's still a JS/V8/Chrome for a dependency. On an application where we're rendering huge walls of text - we forgo native redraw. Crucial to response time. > What makes Atom a viable choice when there already is free, open source, native, cross-platform editors with great plugin ecosystems?
I guess maybe CoffeeScript isn't what turned you away?
As a node developer, seeing any official, open source package in CoffeeScript is a red flag.
The sibling I made a link to a thread about CS in Atom. The creator of express.js has his take:
"Hell I had to rewrite a coffeescript driver this week because I can't have our company relying on things written by people who are unfamiliar with javascript, throwing strings, super awkward apis, lots of indirection, and stepping through the compiled source is a nightmare. It's not like I didn't want to contribute, I even tried for a while, but it's just not worth the hell, it was quicker to just rewrite the thing. Not to say all coffeescript libraries are written poorly, but regardless you're really not gaining much, just losing a lot." [1]
If you write an open source application in CoffeeScript, you're not doing the community a favor, you're doing yourself a favor. They pay the penalty.
[1] https://discuss.atom.io/t/why-coffeescript/131/8
The sibling I made a link to a thread about CS in Atom. The creator of express.js has his take:
"Hell I had to rewrite a coffeescript driver this week because I can't have our company relying on things written by people who are unfamiliar with javascript, throwing strings, super awkward apis, lots of indirection, and stepping through the compiled source is a nightmare. It's not like I didn't want to contribute, I even tried for a while, but it's just not worth the hell, it was quicker to just rewrite the thing. Not to say all coffeescript libraries are written poorly, but regardless you're really not gaining much, just losing a lot." [1]
If you write an open source application in CoffeeScript, you're not doing the community a favor, you're doing yourself a favor. They pay the penalty.
[1] https://discuss.atom.io/t/why-coffeescript/131/8
FWIW, that same creator created Jade and Stylus which are pythonic like CoffeeScript. What's wrong with HTML and CSS? I could never take his stance against CoffeeScript seriously.
I can't speak for him. I've had fellow programmers love CoffeeScript for their own personal / client projects - but they conceded that for the real deal - a public open source project should stay in JS. Otherwise, it'd scare off swaths of top tier JS coders from contributing. Atom serves as an example of this practice [1].
The smell CoffeeScript in core gives off to them - while I don't subscribe to this - is that "it's an amateur job, don't bother". You don't write open, core code in an abstracted language. That's so suspect. Personal / internal projects are OK, a few I save CS specifically for those situations.
If you look at the source of Express.js, you can see the javascript has it's own aesthetics to it. You can think of express/connect as serving exemplary of node.js code, for now.
On a topic of the CoffeeScript creator, Jeremy Ashkenas also created Backbone and Underscore. These are pretty much examples of top tier JS in the browser. The projects are known for their annotated source:
- http://underscorejs.org/docs/underscore.html
- http://documentcloud.github.com/backbone/docs/backbone.html
You can't output this kind of code with CoffeeScript. You have to let in sink in and understand the patterns (the way .extend works in underscore and how Backbone builds upon the idea to add it to objects.)
[1] https://discuss.atom.io/t/goodbye-atom-some-feedback/12301/3...
The smell CoffeeScript in core gives off to them - while I don't subscribe to this - is that "it's an amateur job, don't bother". You don't write open, core code in an abstracted language. That's so suspect. Personal / internal projects are OK, a few I save CS specifically for those situations.
If you look at the source of Express.js, you can see the javascript has it's own aesthetics to it. You can think of express/connect as serving exemplary of node.js code, for now.
On a topic of the CoffeeScript creator, Jeremy Ashkenas also created Backbone and Underscore. These are pretty much examples of top tier JS in the browser. The projects are known for their annotated source:
- http://underscorejs.org/docs/underscore.html
- http://documentcloud.github.com/backbone/docs/backbone.html
You can't output this kind of code with CoffeeScript. You have to let in sink in and understand the patterns (the way .extend works in underscore and how Backbone builds upon the idea to add it to objects.)
[1] https://discuss.atom.io/t/goodbye-atom-some-feedback/12301/3...
[deleted]
Your comment fills me with equal parts irritation and curiosity, just because it's so far from my experience. I use CoffeeScript every day, and I experience not even the mildest of tooling or debugging hiccups. And I find CoffeeScript hits such a sweet spot — some of the best bits of Ruby and Python syntax, with the first class functions and raw speed of JavaScript. Mozilla's source maps implementation is pure JS, so you can take that anywhere (e.g. I use it with JavaScriptCore on iOS). Can you elaborate on these nightmares?
I second this; though, to be fair, source maps in AtomShell have been flaky at times when selecting breakpoints with CoffeeScript. I have turned my source mapping off and debug the unminified resultant JavaScript.
You actually don't have to touch coffeescript to develop for Atom or Electron.
EDIT: here's a demo app with zero CoffeeScript: https://github.com/thom-nic/electron-demo
EDIT: here's a demo app with zero CoffeeScript: https://github.com/thom-nic/electron-demo
I agree, have an up vote. I wish this community was nice to each other, instead of telling you why your personal choice is wrong and and trying to prove that they are right. It's not about being right or wrong, because there is no right or wrong. Just tools to do the job.
Ignore the haters, they will always exist. Just keep build great stuff.
Ignore the haters, they will always exist. Just keep build great stuff.
That's like saying you won't use Rails because it's written in Ruby and not C.
Also, it's nice to work in a language that has the right features and not just all the features. I like CoffeeScript as much for what it doesn't have as for what it does have. I recently saw this piece of code:
Also, it's nice to work in a language that has the right features and not just all the features. I like CoffeeScript as much for what it doesn't have as for what it does have. I recently saw this piece of code:
new Array(26)
.map(function (item, index) {
return String.fromCharCode(65 + index);
})
const caps = new Array(26).map((item, index) => String.fromCharCode(65 + index));
Longer, harder to reason against...
const caps = new Array(26).map((item, index) => String.fromCharCode(65 + index));
const caps = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'.split('');LGTM
It is wrong. "new Array(26)" creates an Array with preallocated space for 26 elements (instead of 26 'undefined' elements, as one might expect), and calling .map() on it will return another empty array. The semantics here are particularly difficult to reason about because map is specified to not execute its callback on undefined elements.
Someone will probably chime in here with a correction, but the point is this -- JS is NOT a friendly language to deal with.
Someone will probably chime in here with a correction, but the point is this -- JS is NOT a friendly language to deal with.
It will iterate just fine, there are no values (undefined) for each `0` through `length-1`
new Array(26).length === 26; //trueSeems like it doesn't, I recently read about this gotcha so I tested it out in JSBin. Using lodash map works as expected, though.
JSBin: http://jsbin.com/vasulumeti/1/edit?js,console
StackOverflow: http://stackoverflow.com/a/5501711/211291
JSBin: http://jsbin.com/vasulumeti/1/edit?js,console
StackOverflow: http://stackoverflow.com/a/5501711/211291
Actually this code is very stupid and you're half correct. The standard built in Array methods like map or forEach don't work on implicitly defined undefined values but on explicit one they do.
For example: [1,2,3,undefined].forEach(ele => console.log(ele)) > 1 > 2 > 3 > undefined On the other hand: [1,2,3,,].forEach(ele => console.log(ele)) > 1 > 2 > 3
So, take the time you dedicate to hating JavaScript to understand the language instead of bitching here you and that stupid jerk above.
For example: [1,2,3,undefined].forEach(ele => console.log(ele)) > 1 > 2 > 3 > undefined On the other hand: [1,2,3,,].forEach(ele => console.log(ele)) > 1 > 2 > 3
So, take the time you dedicate to hating JavaScript to understand the language instead of bitching here you and that stupid jerk above.
As others have pointed out, the semantics are pretty hard to deal with. But, it's the style that I think is the really bad part of this snippet. Why would you create an array of empty elements to iterate over just to grab the index? In CoffeeScript, however, the language guides you to this solution:
[65..90].map (number) -> String.fromCharCode(number)
> Why would you create an array of empty elements to iterate over just to grab the index?
Because it's the shortest way to do it in that language.
I think something like:
Because it's the shortest way to do it in that language.
I think something like:
[A-Z].reverse
reverse([A-Z])
If you want an index, use an index:
for (1 = 65; i <= 90; i++){...}
But you can't also output an array without additional lines of code.
You still haven't realized that _your_ solution won't output anything without additional lines of code, have you?
I have, except that it's not really my solution. I was just cleaning up the example to make it more readable, as that seemed to be one of the complaints of the OP.
Unfortunately that won't work as expected, you'll need something ugly like:
Array.apply(null, Array(26)).map((_, index) => String.fromCharCode(65 + index))Idiomatic JavaScript is terrible to read. I'm not one for metalanguages but I'd be hard pressed to argue against it in this case.
That 'idiomatic' JS is but a mere illusion perpetuated by a VM written in C++. We can do this all day.
I'm developing an app using Atom/Electron and I'm pretty sure you don't need to use CoffeeScript at all. It's Node.js and a browser.
To all the sibling commenters defending the merits of CoffeeScript:
- https://discuss.atom.io/t/why-coffeescript/131
- https://meta.discourse.org/t/is-it-better-for-discourse-to-u...
- https://discuss.atom.io/t/why-coffeescript/131
- https://meta.discourse.org/t/is-it-better-for-discourse-to-u...
Translation: "more people know JavaScript than CoffeeScript, so you shouldn't bother with CoffeeScript"
More people are familiar with Notepad than vi. Does that make vi a bad choice?
More people are familiar with Notepad than vi. Does that make vi a bad choice?
> More people are familiar with Notepad than vi. Does that make vi a bad choice?
That analogy doesn't work, because editors don't have network effects, whereas programming languages do.
That analogy doesn't work, because editors don't have network effects, whereas programming languages do.
> editors don't have network effects
The 82 plugins in my current vim setup really, really beg to differ.
The 82 plugins in my current vim setup really, really beg to differ.
There's many reasons why that analogy doesn't work, and "network effect" isn't one.
Appropriate tool, appropriate job.
Appropriate tool, appropriate job.
I'd argue that Javascript is never the appropriate tool for any job, but to each his/her own :)
You guys should probably release nucleus before hooli does!
That's a seriously confusing name. I thought this was a physics story of some kind.
Additionally it's also a bad name because it's impossible to google.
Additionally it's also a bad name because it's impossible to google.
It's not any more difficult to Google than "Go", or "Python". I mean, we're talking about board games and snakes, right? :)
And those are in fact bad names. Just because they are used and popular doesn't make them good names.
I forget which language it was, but someone interviewed the creator and he said if he had to do anything different he would not have named it something so hard to google.
I forget which language it was, but someone interviewed the creator and he said if he had to do anything different he would not have named it something so hard to google.
is your standard for a bad name really "hard to google"?
Apple? C? when something gains critical mass it's really irrelevant anyway, since they become easy to google (atom shell is already a front page result for "electron").
or is the argument that they are bad names because they are not "relevant"? again.. Apple... C... if anything i'd say "electron" is super cliche and exactly the type of name i'd expect a library to have.
Apple? C? when something gains critical mass it's really irrelevant anyway, since they become easy to google (atom shell is already a front page result for "electron").
or is the argument that they are bad names because they are not "relevant"? again.. Apple... C... if anything i'd say "electron" is super cliche and exactly the type of name i'd expect a library to have.
> is your standard for a bad name really "hard to google"?
It's not the only one, but it's certainly important. Especially for more obscure projects, or things that users will have lots of question about, if you can't google it, it's not going to succeed.
> Apple? C?
Really? Those are you examples? Both of those were named before google even existed. They are very large, and hardly obscure. They don't need any help to be found.
> or is the argument that they are bad names because they are not "relevant"?
No, that's not the argument.
> if anything i'd say "electron" is super cliche and exactly the type of name i'd expect a library to have.
Maybe you expect it, but it's a terrible name.
It's not the only one, but it's certainly important. Especially for more obscure projects, or things that users will have lots of question about, if you can't google it, it's not going to succeed.
> Apple? C?
Really? Those are you examples? Both of those were named before google even existed. They are very large, and hardly obscure. They don't need any help to be found.
> or is the argument that they are bad names because they are not "relevant"?
No, that's not the argument.
> if anything i'd say "electron" is super cliche and exactly the type of name i'd expect a library to have.
Maybe you expect it, but it's a terrible name.
[deleted]
to say a name is bad because it is hard to Google is dehumanizing. the purpose of a name is not to maximize discoverability. it is a side effect. do you feel the same about band names?
"bad name" is, i'm sure you understand, in every instance, completely subjective. and your stance stands under scrutiny particularly in software, where names like this are ubiquitous.
to defend my examples, which for some reason you considered an exhaustive list, i present rails... bootstrap... backbone... react... apache... steam... chrome... express... should i keep going? even Yale's Neuron simulator is named NEURON.
my point is that your opinion seems to be the minority. which is fine, just gives you no ground to call your opinion "fact".
"bad name" is, i'm sure you understand, in every instance, completely subjective. and your stance stands under scrutiny particularly in software, where names like this are ubiquitous.
to defend my examples, which for some reason you considered an exhaustive list, i present rails... bootstrap... backbone... react... apache... steam... chrome... express... should i keep going? even Yale's Neuron simulator is named NEURON.
my point is that your opinion seems to be the minority. which is fine, just gives you no ground to call your opinion "fact".
> to say a name is bad because it is hard to Google is dehumanizing.
Hu? You are aware that programming languages are not human right? So how does one "dehumanize" something that isn't human in the first place?
> the purpose of a name is not to maximize discoverability.
Actually, yes, it is. That is the number one goal of the name of a programing language or library. If I can not easily find out more about your product then you might as well not release it.
Are you confusing the names of humans with the names of programming languages? They serve different purposes.
And just to strengthen my point, actor names are required to be unique, if the name is a duplicate they make them change it. Yes, the actual human, is required to change their name. The actor guild understands what good names are.
Of course most people do not need to be searched for, but some do.
For example politicians with good names get more votes than those with bad names. (A good name for a politician is something easy to search, easy remember, easy to spell, and hard to make jokes about.) You might not like this fact about elections, but it is nonetheless true.
> do you feel the same about band names?
Depends. Do bands need to be searched for to get additional information about them?
> to defend my examples
Wait, so you are defending your example, by giving me more examples of bad names? How does that defend anything? You are just making my point for me.
Go search for some of those names, are see how the results are a mixture of different things instead of just the topic at hand.
I guess you have never come across some obscure language, and try to get more info about it, only to have most of your search results be about entirely irrelevant things?
Once you experience that you'll understand, that yes, it's a fact, not an opinion.
Hu? You are aware that programming languages are not human right? So how does one "dehumanize" something that isn't human in the first place?
> the purpose of a name is not to maximize discoverability.
Actually, yes, it is. That is the number one goal of the name of a programing language or library. If I can not easily find out more about your product then you might as well not release it.
Are you confusing the names of humans with the names of programming languages? They serve different purposes.
And just to strengthen my point, actor names are required to be unique, if the name is a duplicate they make them change it. Yes, the actual human, is required to change their name. The actor guild understands what good names are.
Of course most people do not need to be searched for, but some do.
For example politicians with good names get more votes than those with bad names. (A good name for a politician is something easy to search, easy remember, easy to spell, and hard to make jokes about.) You might not like this fact about elections, but it is nonetheless true.
> do you feel the same about band names?
Depends. Do bands need to be searched for to get additional information about them?
> to defend my examples
Wait, so you are defending your example, by giving me more examples of bad names? How does that defend anything? You are just making my point for me.
Go search for some of those names, are see how the results are a mixture of different things instead of just the topic at hand.
I guess you have never come across some obscure language, and try to get more info about it, only to have most of your search results be about entirely irrelevant things?
Once you experience that you'll understand, that yes, it's a fact, not an opinion.
> Hu? You are aware that programming languages are not human right?
you'll have to forigve the length of my response here, it is my only defense for someone so patronizing.
> So how does one "dehumanize" something that isn't human in the first place?
you could deduce i was not referring to the dehumanization of software, i referring to the dehumanization of the art, rhyme and reason behind naming things. your notion that discoverability is "the number one goal of the name of a programing language or library" is also an opinion, and i posit that the authors of all the software i listed would consider it your opinion as well. that, or they are all incompetent.
in my previous post i tried to treat "discoverability" as a valid argument with respect to these names, but i must admit it sounds imaginary. all of the examples i provided, are by your measure are undiscoverable therefor "bad". yet somehow, everyone still finds them just fine, they are all insanely popular, Google returns the proper results on the front page, and the world keeps spinning.
> And just to strengthen my point, actor names are required to be unique, if the name is a duplicate they make them change it. Yes, the actual human, is required to change their name. The actor guild understands what good names are.
the actors guild doesn't give a shit about "good names", they give a shit about protecting actors. that is why they exist. the reason they restrict unique names is so i cannot start acting under the name Jack Nicholson, receiving undeserved credit. does USPTO require unique trademarks because they "understand good names"?
> Depends. Do bands need to be searched for to get additional information about them?
of course they do. just like a painting or song must be searched to find additional information. so band, painting, and song names are "bad" if they are hard to Google? this is what i consider dehumanizing. a name is a form of expression.
if i am naming my song, my band, or my library, i really don't care if you have trouble Googling it. i'm not naming it for you. and if my song, band, or library is of value to people, it will become discoverable despite it's name.
> Go search for some of those names, are see how the results are a mixture of different things instead of just the topic at hand.
if your query does not return the results you want, it is your responsibility as a user to refine your query. for example, if you tried to Google "meteor" with the intent to research the space rock, half the front page results will be about an irrelevant software library. by your logic, this makes "meteor" a bad name for the space rock.
> Wait, so you are defending your example, by giving me more examples of bad names? How does that defend anything? You are just making my point for me.
i am providing more "bad names" to prove my point that either you need to recalibrate your measure for "bad name", or everyone else does.
> I guess you have never come across some obscure language, and try to get more info about it, only to have most of your search results be about entirely irrelevant things?
this is a loaded question. the definition of obscure here is "hard to Google", so of course an obscure language would be hard to Google. that said, even 8 years ago i had no trouble researching the Io language, when it was harder to find on Google than it is today. this is part of my basis for calling your argument imaginary.
there are nearly infinite examples of things succeeding despite their name being initially undiscoverable, and it is impossible to prove a single case where something failed because it's name was hard to Google. why am i defending the only side of the argument that has data to support it?
you'll have to forigve the length of my response here, it is my only defense for someone so patronizing.
> So how does one "dehumanize" something that isn't human in the first place?
you could deduce i was not referring to the dehumanization of software, i referring to the dehumanization of the art, rhyme and reason behind naming things. your notion that discoverability is "the number one goal of the name of a programing language or library" is also an opinion, and i posit that the authors of all the software i listed would consider it your opinion as well. that, or they are all incompetent.
in my previous post i tried to treat "discoverability" as a valid argument with respect to these names, but i must admit it sounds imaginary. all of the examples i provided, are by your measure are undiscoverable therefor "bad". yet somehow, everyone still finds them just fine, they are all insanely popular, Google returns the proper results on the front page, and the world keeps spinning.
> And just to strengthen my point, actor names are required to be unique, if the name is a duplicate they make them change it. Yes, the actual human, is required to change their name. The actor guild understands what good names are.
the actors guild doesn't give a shit about "good names", they give a shit about protecting actors. that is why they exist. the reason they restrict unique names is so i cannot start acting under the name Jack Nicholson, receiving undeserved credit. does USPTO require unique trademarks because they "understand good names"?
> Depends. Do bands need to be searched for to get additional information about them?
of course they do. just like a painting or song must be searched to find additional information. so band, painting, and song names are "bad" if they are hard to Google? this is what i consider dehumanizing. a name is a form of expression.
if i am naming my song, my band, or my library, i really don't care if you have trouble Googling it. i'm not naming it for you. and if my song, band, or library is of value to people, it will become discoverable despite it's name.
> Go search for some of those names, are see how the results are a mixture of different things instead of just the topic at hand.
if your query does not return the results you want, it is your responsibility as a user to refine your query. for example, if you tried to Google "meteor" with the intent to research the space rock, half the front page results will be about an irrelevant software library. by your logic, this makes "meteor" a bad name for the space rock.
> Wait, so you are defending your example, by giving me more examples of bad names? How does that defend anything? You are just making my point for me.
i am providing more "bad names" to prove my point that either you need to recalibrate your measure for "bad name", or everyone else does.
> I guess you have never come across some obscure language, and try to get more info about it, only to have most of your search results be about entirely irrelevant things?
this is a loaded question. the definition of obscure here is "hard to Google", so of course an obscure language would be hard to Google. that said, even 8 years ago i had no trouble researching the Io language, when it was harder to find on Google than it is today. this is part of my basis for calling your argument imaginary.
there are nearly infinite examples of things succeeding despite their name being initially undiscoverable, and it is impossible to prove a single case where something failed because it's name was hard to Google. why am i defending the only side of the argument that has data to support it?
I had assumed this was something to do with Acorn Computers [1] whose first models were called Atom [2] and Electron [3]. Frankly I was disappointed I was looking forward to how someone could have combined these pieces of British computing history with some kind of modern shell.
[1] http://en.wikipedia.org/wiki/Acorn_Computers
[2] http://en.wikipedia.org/wiki/Acorn_Atom
[3] http://en.wikipedia.org/wiki/Acorn_Electron
[1] http://en.wikipedia.org/wiki/Acorn_Computers
[2] http://en.wikipedia.org/wiki/Acorn_Atom
[3] http://en.wikipedia.org/wiki/Acorn_Electron
Raspberry Pi [1] is probably the closest thing to an heir apparent...
[1] http://en.wikipedia.org/wiki/Raspberry_Pi
[1] http://en.wikipedia.org/wiki/Raspberry_Pi
I dunno, we're doing OK on Google with "Atom".
It seems nowadays there is no "good" name to google. Every single word in a dictionary is already being used by something else.
Which argues that good names are generally not a single dictionary word. This is like saying "nowadays there are no good passwords people can't guess: people can just try the entire dictionary in a few seconds". If you list major brands, the vast majority of them, even of really really old brands, are either made up words or phrases.
The difference is that branding is important. Ease of learning and remembering a name.
Very different to passwords, which should be computer-generated and computer-stored, you should never know your passwords.
Very different to passwords, which should be computer-generated and computer-stored, you should never know your passwords.
So call it two words. ElectronEnv, AtomEditor, AtomIDE, etc..
Then call it "Electron Shell," which would at least be more Googleable than "Electron" by itself is.
Unfortunately, an electron shell is also a widely used term in chemistry and physics: https://en.wikipedia.org/wiki/Electron_shell
No need to use words from dictionary then. '999fkk9' is usable and googlable as any other arbitrary name.
"Google" was a good name...
Wait, this article isn't about physics? boooooring