Since this is HN and most people here have written code, I compare multi-monitor setups to a text/code editor with a single panel/pane. You just don't do it! Sublime, N++, Atom, etc. all support multiple panes (split screen). Once you get coding enough you never go back to using a single pane.
Same thing with multi-monitor. As long as you are productive (unlike the author), more screen real estate is better (obviously, there are limits)
Personally, I like dual 27"s. Allows you to run 4 full size (think 8.5"x11") word docs at 100% side by side. Very nice!
What the author failed to account for is the fact that not everyone does the same type of work. As a security researcher I spend a fair amount of time watching real-time code execution while simultaneously watching & modifying network traffic. In a typical solution review I might have Wireshark running on one monitor, an HTTP editor/proxy running on another hooked to the browser, another HTTP editor/proxy running on yet another monitor hooked to the web service. That's three monitors right there. Next I'll have the browser running on a fourth monitor and possibly be reviewing code and code execution on a fifth. On the sixth and seventh monitors I'll be doing research including static code analysis with the eighth and ninth monitors dedicated to coms (chat/email) and writing up my results. I routinely switch between my multi-monitor solution and a single screen laptop and there's just simply no way I can effectively do my job on one monitor these days. I'll do "simple" reviews on my one monitor laptop and stick with the multi-monitor solution for the harder stuff.
Keep in mind that the author is Farhad "Stop Calling Me a Troll" Manjoo. He's sort of a junior version of John C Dvorak, albeit less experienced and less amusing.
The point of JSON is to have a standard way for data-interchange. Adding the complexity of "sometimes you might have quotes, sometimes not" and "you can display multi-line strings in different ways" gets away from this.
JSON is great already. I don't really see this as necessary. I could understand the comments (but use // instead of # as per Javascript comments) to increase clarity to people who don't know the original design syntax. But the others do not seem really useful.
No, the point of XML is to have a standard way for data-interchange. The point of JSON is to have a lighter and simpler way of data interchange, where the data is arrays and maps of strings and numbers. It also works well with Javascript.
If there's one thing JSON has proven it's that having a standard way for data-interchange is not very important. Having a format that's easily parse- and usable is much more important, being accessible to human inspection is a good advantage as well.
(if having a standard was important we'd all still be using XML)
I'd say that was exactly backwards. The reason JSON succeeded is precisely that it is a very, very specific standard. You may still be operating under the common misunderstanding that JSON is just "Javascript object notation", but in fact it is a carefully chosen and very rigid subset. It is actually illegal to not use double-quotes to identify a key, even though in Javascript itself often no quotes are required, and apostrophes are accepted as quotes. JSON's human-readability is a bit deceptive... it is also a very rigid format.
And it is precisely this rigidity that led to its success. There's a tons of other things that existed before JSON, and JSON won, and it's hard not to read the fact that the very looseness of its competition, which the designers of those formats perceived as strengths, were also weaknesses. Any slight little corner in a spec where there can be a divergence of opinion, there will be divergence of opinion when being implemented dozens of times. So having the spec be rigidly precise was a key advantage for JSON.
Which, incidentally, means HJSON's competition isn't JSON. This is why everyone here is talking about YAML, and the other such languages. And that's a rich, established field with probably no room for a new language to emerge.
HJSON's only hope would be to have a mode where it could be trivially compiled to real JSON, where it could work like a dialect. Unfortunately it's promise to round-trip comments wrecks that ability.
I'd say that JSON proved that having a standard for data-interchange was important, especially because as a standard it was both straightforward to implement and limited a lot of the crazy feature creep that made/makes XML annoying. It not only was a standard, it was a strictly better standard.
At the end of the day, in a data format, you need the following things:
+ Some way of associating records with keys
+ Some way of storing records in a particular order
+ Some way of nesting records within records
+ Some simple way of pathing through a record
+ Some way of delimiting the start and end of a record
+ Some way of storing numbers and strings
Anything else is gravy, and JSON managed to nail that core supporting set of features right on the head, without adding other bogus stuff.
XML picked an overly verbose way of nesting and delimiting records, as well as presenting three options for storing data: attributes, body, and CDATA sections when one would have sufficed.
The comments thing in HJSON really annoys me, because comments are not needed in an interchange format--and if you need them because you're using it as a config file format, you can just add a comment key and name your variables better. Moreover, the temptation to use comments for, say, type annotations, is huge, and an antipattern (which is why Crockford left them out).
EDIT:
For everyone talking about a "simpler" JSON...the parser for this is about twice as long as the json2 parser from Crockford, with arguably worse comments.
One could argue "But it parses JSON anyways and lets me write sloppy^H^H^H^H^H^Hfriendly JSON", but that's not the point. People complaining about having to put their keys in quotes and leave off trailing commas are also missing the point.
> The point of JSON is to have a lighter and simpler way of data interchange, where the data is arrays and maps of strings and numbers. It also works well with Javascript.
I contend there's no "point" to JSON at all. JSON is simply JavaScript (in fact, you can eval it) that was discovered could be used to send data from servers to browsers. It became a standard out of sheer convenience.
By breaking Javascript's ability to execute the code, you're eliminating an important feature of JSON. (I'll admit that nobody should be eval'ing JSON, but the fact that you can makes its existence better understood.)
No you can't, JSON is not JavaScript and eval is not capable of working on all correct JSON documents. JSON requires a JSON specific parser. So this breaks nothing, eval doesn't work now and JSON has never been JavaScript.
When JSON was first used, it was evaluated with eval. Certain issues might cause JSON not to evaluate properly (the only article I could find arguing that it's not Javascript involve Unicode issues that are rarely encountered), but it doesn't invalidate my point.
Look, you're just wrong. The only exception to "eval" is some obscure unicode bug others are mentioning. JSON is literally a JS object literal (with the additional requirement that any key be a string). There's also no reason to use eval when JSON.parse will do it safely.
No I'm not wrong and there mere fact that you mention the exception means you've conceded my point; and those aren't bugs, they're in the spec which means it was never a subset of JS.
> JSON is literally a JS object literal (with the additional requirement that any key be a string).
Which makes it not a JS object literal but a near subset with slightly different rules with unicode strings that make it not even a subset.
What spec are you looking at? http://www.ietf.org/rfc/rfc4627.txt specifically says in section 2.5 that all unicode characters are meant to be supported.
This is simply great. I can see this definitely helping expand the base of students who take on computer science or technology related fields of study. With these fields growing already, adding a package like this simply allows students to learn faster and use some of the best tools the industry offers.
While there are alternatives (Atom -> Sublime or Notepad++) for many of these services, the bundling of this all together should present students a logical next step instead of hunting around for a service right away.
I personally disagree, it removes the exploration part of learning how to code, which I believe to be vital to educating good programmers.
I see all these services listed, and all I think is "they are hooking these guys to a service oriented approach", a "pay $25 and you don't have to worry about X". Thing is, what you learn while trialling technologies is invaluable and should not be replaced by a preselected list of SaaS, many of which I would tell any beginner to stay away from.
The exploration of modern programming is a big factor keeping people out. You don't get a computer with BASIC installed anymore, or magazines that teach you programming from start to finish with code samples included.
To figure out desktop programming, you have to download a compiler and hope there is a good tutorial on some random blog which most likely gave up after part two of a five part series. To figure out web programming you need a server and a domain name and wait what language are you using but then again what framework are you using and for the love of god how do I deploy I don't even know where Ubuntu keeps the /www folder and all of the tutorials I find expect me to know what an Angular is when I just learned what a Javascript is and I worked with Codecademy so I know Javascript but not how to use it to make a web page and I know Python but I still need to know HTML, CSS, and Javascript so I give up.
>The exploration of modern programming is a big factor keeping people out.
Is that a problem? From a professional perspective, it seems ideal to not pollute the field with people who are uninterested in such things, as they would very quickly run into issues keeping their knowledge up to date. The field has been and always will be in flux.
From an amateur perspective, I think it's fine if people are dissuaded, amateurs should do things they find enjoyable. If learning about your hobby isn't enjoyable, programming will offer little utility beyond minor entertainment.
While having a multitude of choices can make choosing difficult, it can also make it very easy, just pick anything. With not preconceived notions about how you want to program, all of the popular languages and frameworks are essentially equal to you. As you actually start to program, you'll be exposed to new concepts that you may or may not like. If you don't like them, you be able to trivially search for alternatives with your newfound knowledge of knowing what you like/dislike.
>...or magazines that teach you programming from start to finish with code samples included.
There's a stupid amount of free and non-free literature for getting into programming. Searching for just about any popular language and/or framework will get you at least one book on Amazon and an amazing amount of tutorials/walkthroughs/guides/etc from Google.
This mentality jives with the common hacker refrain that everyone should learn at least some programming, that people should know more about their computers, and with the general idea the knowledge is power. We shouldn't be looking to lock people out just because we don't want amateurs or hobbyists encroaching on our turf. Hackers by definition are not professional programmers. Would you seek to ensure that only college educated programmers are allowed to use a compiler? The idea isn't that it's difficult to get into in order to keep the riff raff out, it's that people who may genuinely enjoy the craft never even start because we've made it so damn difficult to get anything done.
As for the free education, I wrote a whole section on the terrible state of teaching programming, from free blogs to Codecademy. There are many better-worded arguments saying that programming education falls short of what it should be as well.
We should be encouraging more people to program, especially if it means they can do it without a college degree. The amount of people in the world without access to a college education is appalling, but we still want them contributing. What we don't need is elitism.
Incredible synopsis of my first 3 months of programming.
You are right in that the umbrella term "programming" is incredibly daunting to a person who has never written a line of code. Everyone knows that more options does not translate to better outcome all of the time. To step into the world of programming today is to step into a dictionary of dictionaries. It's scarily awesome.
Is modern programming hard to learn, or is it more that people want to do more fancy stuff than before, and quicker? Making a java app is hard for the uninitiated, but compiling a few java classes just requires a compiler (essentially) and to memorize a few commands (or use something like Dr Java). Making a slick web app in RRails is probably pretty daunting, but writing some HTML doesn't even require a server, just a web browser.
There are a lot of interesting problems that can be tackled with simple tools (how about writing a toy compiler in C, for example). Will such things be useful? Probably not, but the learning experience is very valuable. And that's already a good outcome for someone who is only getting their feet wet.
(That said, I'm a relative beginner myself, and I'm kind of itching to make something that is actually useful, at this point. But things like learning language specific package managers, make tools, and other stuff that are needed can be taxing.)
Well that's a big thing, I think. Back in the 80's, your computer came with BASIC, ran on BASIC, and you could do things that were considered cool with just a few days of learning BASIC. You could actually do something real with BASIC. And even when I was in high school, a few days of learning Visual Basic and you had a pretty neat application to use. I don't think schools teach that anymore because it's not considered a good or pragmatic language to learn.
So now we have all this computing power and these powerful and easy to use languages and a broad distribution network and thousands of developers and teachers and applications to learn from and programming has only gotten harder. Think about that one. We've stepped back from BASIC to make programming harder. Because we expect more from our programs now, but we haven't put any effort into making it easier to do even the most simple thing.
I'm still drawing interfaces with tens of lines of code. In Visual Basic, I just drew them on the screen. In Java, I'm fighting to get things aligned or sized right or in the right order, to the point where in my Java class I took there was two weeks dedicated to getting to grips with Swing. So we abstract the hard stuff away... with more code. And though we abstract it away to make it easier, we still look down on language like Visual Basic, because real programmers don't draw their interfaces with a mouse, they do it in code with vim or emacs.
Just look at the mindset of one of the other people who responded to me. "We want to make it harder so amateurs can't do it". Fuck that shit. We have the power to make it easier but we don't.
Wholeheartedly agree. Specific to the actual trial and error, of programming, when I first started learning C++ (a long time ago), I remember the dread of running the debug. Then coming up with a small number of errors in 10's of 1000's of lines of code, and having to comb through to see where I was missing a semi-colon… I think knowing to how to code from ground up is so important. Knowing the fundamentals, and not just knowing how to manipulate someone else's platform. Once you know how to do it, you can make the choice to take shortcuts, but if you start with the shortcuts, and they become unavailable, you're up a creek… I have a web-designer friend of mine that knows how to use Wordpress CSS very well. He can manipulate and research to problem solve. But I'd put dollars to donuts that if I asked him to write a CSS or any other program for that matter from scratch, he wouldn't have the foggiest.
I know this GitHub is geared toward helping students getting ideas up, running, and selling, so toward the latter, it's invaluable, and actually quite generous. I'm still an old fuddy-duddy, and think that it's best to understand how to build the mechanism before buying it off the shelf.
My reasoning: Tesla has vehicles (for sale or in plan) in three segments: high-end sedan, CUV, and mid-range sedan. Building a coupe would fill another segment.
Also, the 2-door market has lots of models (2/4/6 series, C/E/S class, A5, CTS) that are priced high. Attracting higher income buyers to Tesla from these companies with a 2-door would be a very logical next step.
The "+" icon in the upper left corner throws an error when you are not logged in:
{"success":false,"error":{"code":1,"message":"You are not logged in."}}
For some reason I doubt this is by design.
Also, when you upload a pic for the "screenshot", there is no confirmation after the progress bar disappears. No thumbnail, no "Ok, pic uploaded!". Nothing.
Another note: no place to put hyperlinks when you create a post?!
And I cannot edit my post afterword (to add a hyperlink in the description).
It is a new feature, like Apple Wave [1]. The LG G Flex [2]already proved the flexible technology. Apple is just giving consumers the option to have a curved phone </sarcasm>
Am I the only one who doesn't really consider iOS's widgets to be actual widgets? At least on Android I can "do" something with the widget. Example: GMail or email widget....I can read through my inbox; calendar...I can see my next events. The iOS widgets just create a shortcut for me to need to open the full app.
Exactly. A much better example would be to look at what James Thompson is doing with PCalc; the notification widget is a companion calculator to the main app.
http://www.pcalc.com/iphone/index.html
I'm all for it. You learn by your own method. It is just hard for people to understand when they spent years of their lives earning a degree they can place next to their names.
That being said, formal education can teach a wider range of skills and provide guidance to understanding larger concepts.
All in all, I am self taught and respect people heavily for it.
Adding any deterrent (more, better, larger, etc.) seems to me like a "chicken or the egg" game. ATMs get stronger security, scammers develop better methods to skim. Skimmers improve, ATMs get better security. It becomes a viscous circle of who can outwit the other for a longer time and prove more successful.
Personally, I am more interested in improving security via credit card chips or contactless payment (cards or phones). Chips alone would heavily improve security due to the inherent cost (hopefully) of cracking the chip's data.
Same thing with multi-monitor. As long as you are productive (unlike the author), more screen real estate is better (obviously, there are limits)
Personally, I like dual 27"s. Allows you to run 4 full size (think 8.5"x11") word docs at 100% side by side. Very nice!