251–260 of 267 posts
Earlier quoted context omitted.
But you can already have this pretty trivially in emacs: http://puu.sh/q3hpW/2933a20e84.png
You can also render full webpages using webkit: https://www.reddit.com/r/emacs/comments/4srze9/watching_yout...
Earlier quoted context omitted.
>Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. So you prefer one written in ... C? Because C is secure by design? Coding a terminal in Rust or even Go would be awesome, I admit... >Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here. See the demo animation for a (silly yet awesome) example.…
> So you prefer one written in ... C? Because C is secure by design? You missed the point. A program that is 2,500,000 lines of code of interpreted JavaScript, and was written by some guy in a few weeks who pulled in hundreds of unaudited third party libraries, is definitely less secure than a 100,500 line C application that has been slowly developed, improved, and audited for some 25 years or more. >See the demo ani…
JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.
It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced by a linter.
JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
Most of what sucks about using JavaScript is dealing with the DOM and browser differences in DOM implementations, but that's not JavaScript, that's just dealing with multiple browser platforms. Which you don't have to do in Node or Electron.
>"JavaScript hate is so 2010" is a cheap redirect of actual criticisms
No, it was a cheap comeback at substance-free hate directed at the language. If you want to argue details, read JavaScript, The Good Parts (or watch the YouTube video of the same name), and get back to me with what parts of JavaScript are actually, objectively bad. And in order to meet the "objectively" threshold, be sure to cite studies, because otherwise it's just your opinion.
Earlier quoted context omitted.
> So you prefer one written in ... C? Because C is secure by design? You missed the point. A program that is 2,500,000 lines of code of interpreted JavaScript, and was written by some guy in a few weeks who pulled in hundreds of unaudited third party libraries, is definitely less secure than a 100,500 line C application that has been slowly developed, improved, and audited for some 25 years or more. >See the demo ani…
>JavaScript is objectively a bad language JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up. It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced…
> I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up.
Although please come back when this becomes a true statement.
Just an idea: The only windowed applications I use are a terminal (st), my text editor (Atom), and a browser (Firefox). Suppose I switched to HyperTerm, Atom, and Chromium. I would have three copies of the Chromium renderer and V8 interpreter loaded in memory. Is there a project that merges these things into a single daemon, to improve individual app startup time, save memory, and reduce the binary size from 42 MB (f…
My OS X Terminal is already slow enough with my 20 windows open... There's no way I'd switch to an even slower, bulkier implementation with the overhead of Chromium. WTF
Earlier quoted context omitted.
That's not how trademarks work.
15 U.S. Code § 1125 [0]: ... (3) Exclusions The following shall not be actionable as dilution by blurring or dilution by tarnishment under this subsection: (A) Any fair use, including a nominative or descriptive fair use, or facilitation of such fair use, of a famous mark by another person other than as a designation of source for the person’s own goods or services, including use in connection with — (i) advertising…
PS - You linked to 15 U.S.C. § 1127, but quoted 1125.
PPS - An overview of the difference between dilution and infringement: http://www.nolo.com/legal-encyclopedia/what-trademark-diluti...
Earlier quoted context omitted.
>JavaScript is objectively a bad language JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up. It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced…
I really don't feel like carrying on another JavaScript argument, so we'll just have to agree to disagree. > I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up. Although please come back when this becomes a true statement.
That sir is uncalled for.
Just an idea: The only windowed applications I use are a terminal (st), my text editor (Atom), and a browser (Firefox). Suppose I switched to HyperTerm, Atom, and Chromium. I would have three copies of the Chromium renderer and V8 interpreter loaded in memory. Is there a project that merges these things into a single daemon, to improve individual app startup time, save memory, and reduce the binary size from 42 MB (f…
Earlier quoted context omitted.
15 U.S. Code § 1125 [0]: ... (3) Exclusions The following shall not be actionable as dilution by blurring or dilution by tarnishment under this subsection: (A) Any fair use, including a nominative or descriptive fair use, or facilitation of such fair use, of a famous mark by another person other than as a designation of source for the person’s own goods or services, including use in connection with — (i) advertising…
This only covers trademark dilution which is one cause of action for trademark infringement, but not the only possible cause of action. Usually trademark dilution is argued when the products are dissimilar. In this case, they are not dissimilar. And as such, this is the regular definition of infringement and is not covered by 15 U.S.C. § 1125(c)(3). It falls distinctly under § 1125(a). PS - You linked to 15 U.S.C. §…
Here is 1125(a):
(1) Any person who, on or in connection with any goods or services, or any container for goods, *uses in commerce any word*, ...
Further, 1125(c)(3)(C) is an exclusion across the entire 1125 subsection (and yes, for dilution, which is what has been argued here).
Earlier quoted context omitted.
Hey, I have a few issues with your attitude. Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. The hard part isn't drawing characters to the screen (which is what HTML and CSS would help with), it's the VT100 parsing and logic, which can be written in...well, anything, really. I would first like to point out that the HyperTerm OSX z…
>Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. So you prefer one written in ... C? Because C is secure by design? Coding a terminal in Rust or even Go would be awesome, I admit... >Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here. See the demo animation for a (silly yet awesome) example.…
So, if Javascript hate is "so 2010," is C hate all the fashion now? If you're going to get on somebody's case for trashing a programming language than you might as well practice what you preach.
C certainly isn't secure by design, but there are plenty of demonstrably secure projects developed in C and C++ (and it's not like Node is self-bootstrapped, either). To answer your question, yes, I would prefer one written in C. Any day of the week.
> Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well.
Dragging along such a massive runtime environment is such a heavy cost for that, though. And, again...in a terminal? I'm not judging every since Electron app, right now, I'm just judging HyperTerm.
> The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to?
Honestly? Parent didn't make any. I'm just tired of people defending programming languages like they're more than just tools. It's fine to hate tools. Obviously this person's JS hate is coming from an informed place, because they've written a fair chunk of it.
Earlier quoted context omitted.
> So you prefer one written in ... C? Because C is secure by design? You missed the point. A program that is 2,500,000 lines of code of interpreted JavaScript, and was written by some guy in a few weeks who pulled in hundreds of unaudited third party libraries, is definitely less secure than a 100,500 line C application that has been slowly developed, improved, and audited for some 25 years or more. >See the demo ani…
>JavaScript is objectively a bad language JavaScript is not objectively bad. I have 30 years experience programming in probably 15 languages and both formal and informal education in language theory to back that assertion up. It's objectively not perfect, but then most languages have problems. There are a few regretful mistakes in the design, but they can be worked around by using programming style decisions enforced…
Let me be clear here: JS is not really any better or any worse than any other interpreted languages. Yeah, I can name a few language-level problems (whoever decided that Promises should silently eat exceptions was wrong), but the big problems are not unique. Things like awful numeric performance (I've done crypto in JS), horrible multithreading support (Python and Ruby have GILs so it's roughly the same thing), etc etc.
The difference is that JS/web programmers seem to be the only ones saying that things written in their language and platform of choice (JS/HTML/CSS webapps, inside or outside of Electron) are the future everybody wants. Like the ego-stroking whenever somebody posts a new Node or Electron tool that had no reason to be written in JS except that the developer just didn't want to use another language isn't weird. Like 123mb for a terminal emulator isn't ridiculous.
Javascript brings nothing to the table except that it's the only language you can use for web programming. Nothing.
The execution model is awful as well, since apparently in order to get any sort of decent performance in a webapp these days you need to maintain a shadow copy of the DOM just so you can hack around the browser's layout engine.
> JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than naive C implementations.
30 years programming experience and you want to compare an interpreted language to a naïve C implementation? Come on. Did you see the Python libuv asyncio implementation that is 2x faster than the equivalent code running in Node [0]? Python, using Node's own supporting libraries (http-parser also) is better than Node at Node's own game.
[0]: http://magic.io/blog/uvloop-blazing-fast-python-networking/