Show HN: Free online programming courses in new tab, everyday - <AUTHOR> https://chrome.google.com/webstore/detail/quickcode-free-online-pro/nnigpbiaggiephcndokoaongeefpbdcj?hl=en <comment><AUTHOR> Quick Code is a place to discover free online programming courses. New courses surface every day on the site.

Sometimes, these courses are free for a limited time and you have higher chances of missing them.

With this chrome extension, you will get updates of new courses as soon as they publish on the site. It shows new courses in the new tab.

You can look for courses of different programming languages directly from the new tab.

You will receive notifications about new courses so you never miss the new free courses.</comment>


Basic security precautions for non-profits and journalists (2017) - <AUTHOR> https://techsolidarity.org/resources/basic_security.htm <comment><USER2> Previous HN post of this article and discussion from February 2017 with a wealth of advice and comments:

[https://news.ycombinator.com/item?id=13622684](https://news.ycombinator.com/item?id=13622684)

</comment><comment><USER3> > Don't store sensitive information in cloud services like Evernote or > Dropbox.

Good advice but distinguishing when the cloud is involved is getting harder, even for technical people.

<comment><USER4> They recommend (in another article on congressional campaigns) using Google Drive over Evernote or Dropbox.

How about iCloud Drive? Trustworthy/secure as Google Drive?

</comment></comment><comment><USER5> Don't use Android... do use Gmail?

<comment><USER6> That's right.

It's not about avoiding Google. Google does excellent security work. It's about using the most secure products in each category. An Android phone can be made asymptotically as secure as an iPhone, but only by an expert.

<comment><USER7> Buy a Pixel, set a secure passcode. There you go.

<comment><USER6> No, that's wishful. The Pixels are the most secure Android phones you can buy, but they are not natively as secure as an iPhone.

But: if it helps put a dumb argument to rest, consider that in the populations being trained, "Android phone" means "phone from an insane variety of vendors, most of whom are not competent to sell or maintain a secure phone".

<comment><USER8> Pixels are the #1 pick for security, but not with it's default ROM installed. [https://copperhead.co/](https://copperhead.co/) is a seriously hardened ROM without google play services and simply having security as a #1 priority.

<comment><USER6> I don't even know where to start with this but let's just stipulate that when I said "experts can get an Android phone asymptotically as secure as an iPhone", I meant stuff like "people can pick very specific models and then install an entire custom operating system on the phone". I don't _actually_ agree with what you're saying, but the argument will be unproductive, and I think we're close enough that my point stands.

</comment></comment></comment></comment></comment></comment><comment><USER9> Why iPhone instead of Android?

</comment><comment><USER10> Couple of odd points

\- Don't use your fingerprint to lock/unlock devices.

(presumably because you can be unconscious, and still unlock your phone?)

But the stand out one for me was

If you have a Windows laptop, uninstall any antivirus products except for Windows Defender (from Microsoft).

I am assuming this means that they don't trust Symantec? Who might be installing backdoors? How verified is this threat? And should we tell every major bank / finance house / government who seem to have AV everywhere.

<comment><USER6> This is an example of what makes it so hard to communicate security advice to laypeople: nerds come out of the woodwork trying to reconstruct and critique the advice from first principles, and going off on all sorts of weird tangents.

So: no, _nobody_ serious trusts Symantec. But not because they're "installing backdoors"; it's because their software is complicated, embedded deep into the guts of the operating system, is historically full of bugs, and doesn't actually solve the problem it purports to solve.

<comment><USER10> OK. I should have been ... clearer - what I meant was if not using AV is good advice, why is that and why do so many many corporates ignore that advice?

The why is AV untrustworthy you covered, but why do so many people keep using it?

Edit: I could take a guess but not now :-)

<comment><USER11> If you really need to open an attachment, it's best to open it on Google Drive, in the cloud. Let them deal with any virus issues.

</comment></comment></comment></comment><comment><USER8> Lists like these are dangerous as they should be tailored per situation/person.

On most occasions i have experience with it's usually best for the operative to behave like the generic tech-moron he/she is in order to NOT stand out of the crowd / raise attention. When something sensitive is about to commence, stick the TAILS usb stick in the laptop & go. Microwave the USB stick when done. But as in my first alinea; advice like this should be tailored at all times.

<comment><USER2> Security has trade offs that need to be carefully weighed for each situation before some appropriate decisions are taken (with the benefit of knowledge).

But a big hurdle here is that the target audience has a critical need to have very good protective measures in place but is also at the same time very likely not to know about the trade offs or how to weigh the trade offs or even have a relatively good understanding of the basis of the trade offs. Hence the need for generic advice that could be easier to follow for most people while providing a better set of protections than the status quo (with the status quo being not even considering the security part and making assumptions based solely on habit and convenience).

Anyone who has taken some of this advice to heart and still is unsure would usually find a way to ask people who know better for tailored advice.

<comment><USER8> For a general statement I agree with you. I find it even a good thing to teach everyone, not just journalists, basic data hygiene. The target audience set however is far from general. They are journalists and non-profits. Such entities have adversaries such as [https://en.wikipedia.org/wiki/Tailored_Access_Operations](https://en.wikipedia.org/wiki/Tailored_Access_Operations) haunting them. Even most well trained security professionals are far from qualified enough to deal with such actors. In other words, people should be honest with the journalists and tell them they are not competent enough to assess or commit trade offs. On most occassions, knowing you are not secure is the best security you can get as it alters your behaviour accordingly.

</comment></comment></comment><comment><USER12> The list says to use an iPhone instead of a laptop, I presume because the iPhone has hardware encryption coming from the Secure Enclave. But newer MacBook Pros from Apple, and even the iMac Pro, feature the T2 chip to achieve the same result as the Secure Enclave with regards to encryption.

I guess my point is this list is deeply flawed because it explains none of its decision-making process. Journalists aren't idiots. Tell them why they should not use a laptop.

<comment><USER6> Trained a lot of journalists, have you? A lot of them asked you about the chipsets in the machines they were using?

For what it's worth: no, the important difference between a Macbook and an iPhone isn't the SEP.

<comment><USER12> What is so different from physical access to an unlocked iPhone than an unlocked Mac? You're screwed either way, no?

<comment><USER13> Yes, if someone has physical access to an unlocked iphone or mac you're screwed. The author's idea might rather be about the OS, the main difference between an iphone and a mac (or pc for that matter) is the os. Hence the recommandation for a chromebook.

I suppose the author assumes that on ios a random website is less likely to have access to your files (articles).

So this might be more about protection from attackers who don't have physical access to the device.</comment></comment></comment></comment>


Show HN: ExcelJSON – Convert CSV and TSV To/from JSON Easily - <AUTHOR> http://exceljson.com <comment><AUTHOR> Good idea. I will add the feature soon in upcoming versions. Thanks for the feedback.

</comment><comment><USER2> I think the idea is good and could be useful.

I'd like to test it but have no CSV available.

Why not support URL? Like here:

[https://news.ycombinator.com/item?id=13274331](https://news.ycombinator.com/item?id=13274331)</comment>


Ask HN: boardgames or (and not) card games? - <AUTHOR> I love card games—which will here be defined as any of the thousands of folk games that can be played with a somewhat standardized (according to region) deck of playing cards. And I know that there's a lot of geeks out there of different stripes that are avid poker players. I've even met a couple (terrifying) alpha male hackers and stock-optioned developer types who play Bridge at the highest levels with their scary hacker brains.
But in a general sense I don't see a lot of interest in the wider world of card games and that confuses me. It would seem to be perfectly suited to the Hacker Mind: thousands of different systems, made up of the same or similar parts, each with their own logic. Certain techniques are isomorphic across every family and sub-family.
I know tons of hackers love board games—which have always left me cold in general. I have tried my hand at, say, Carcassonne and Starfarers of Catan, and I can see how there's more _play_ involved than something like Chutes and Ladders, but board games still seem so much more removed and arbitrary than card games. Not to mention more expensive, and more dependent on specific materials.
So, are there any hackers out there who think that card games in general are a worthy field of interest? And for those of you who love board games and not card games, why so? <comment><USER2> I don't make much distinction between board and card games. I'm not as well versed in the standard-deck-of-playing-cards games, but my gaming group frequently convenes for Spades (Bridge's not quite as smart younger sibling).

A lot more of this question might be finding games that chellenge you in the right way, and which go well with your gaming group.

Personally, I dislike most of the Catan games, and most games with dice involved. On the other hand, if Caylus, Brass, Tigris and Euphrates, or Dominion hit the table, I'm set.

All of those games provide multiple avenues to victory and multiple methods of player interaction. Additionally, they require a high amount of intellectual work (not quite so much with Dominion) and a healthy balance between strategy and tactics. Finally, all of those games reward experience, and make for extremely satisfying matches when matched up with someone of equivalent skill, with little to no randomness that can't be balanced out somewhere. Finally, I like that while there are certain modes of thinking which carry over sometimes, by and large each game requires a different type of problem-solving (Caylus's manipulation of resources and linearity; Brass's manipulation of networks and income; Dominion's manipulation of probability and the transitions from opening to mid-game to end-game; and so on).

(Side note: you might enjoy Dominion, as it hits the sweet spot between board and card game, and does not rely on "theme" a single bit).

As a more general note: both card and board games (as broad as those categories are) can provide a lot of enjoyment, or not very much. I think it's a matter of fairly assessing one's motivations for playing (both in general and on a given day) and the tolerances/temperances of the gaming group.

</comment><comment><USER3> I used to love Chess, but haven't played it much since I became hooked on Go. I find Go interesting both as a player and as a programmer because of the depth of strategy and the challenges of making a computer play well.

Bridge is also interesting, but tends to be played mostly by old people. I never knew card games involved much strategy until I tried Bridge. The partnership aspect of it has its rewards and challenges. I disliked learning all of the bidding conventions and the seemingly arbitrary rules surrounding bidding. I prefer games where luck is minimized and there is a wide range of skill levels between beginners and experts.

</comment><comment><AUTHOR> I seem to be hearing from a few of you that you might not be as familiar with that sort of card game as I had assumed. Which makes sense; the days that every family spent most of its free time in card play are long gone. And if War and Poker were the only examples I'd ever seen of a card game, I'm sure I'd have totally lost interest as well. Maybe what's needed is a little education. I think there's a lot of people who would find a lot of different games awfully compelling, especially once we get past Poker (Stud and Hold 'Em Poker don't actually, you'll notice, contain any card play; you don't _do_ anything with the cards, you just issue a series of bets about the hand you've been dealt).

</comment><comment><USER4> Texas Hold'em is a logical and difficult game. So is Chess. I enjoy both games.

War is pretty simplistic. So is Chutes and Ladders (simplistic meaning less choice and more dependent on luck. There is also less need for strategy. Of course, chess has virtually no luck variable, unless you include the randomness of the opponent's choice.)

It really depends on the game and the people playing it.

</comment><comment><USER5> Card games is a rather broad umbrella term. Do you mean card games like Poker, or Magic: The Gathering? Or something experimental like Rejection Therapy?

Just trying to figure out what your after. I never play Poker (I find it boring, and I don't gamble) but I'm fascinated by social experiments like Rejection Therapy.

<comment><AUTHOR> My 'which will here be defined' was an attempt to describe the set of games like poker, bridge, whist, war, 66, skat. Conventional folk games played with one of only few sets of conventional decks.

</comment></comment><comment><USER6> I know this will be a strange demand, but I would like to hear about board or card games which one can play alone and are freely available. By freely available I mean I can download it and just print the boards and cards to play.</comment>


Ask HN: Which Programming Language has best way of managing dependencies? - <AUTHOR> <comment><USER2> Golang / go mods.

It uses Minimum Version Selection to avoid lockfiles and is part of getting to 100% reproducible builds. The code base for mods is impressive too, so much thought around security.

</comment><comment><USER3> Node.js seems to have a very good ecosystem. Compared to say python, I come across very few problems with dependency locking and setting up on multiple devices

</comment><comment><USER4> I would guess assembly language since it uses the machine's instructions.

I think for the higher languages it depends. A lot of IDEs make dependencies easier manage than the language on it's own.</comment>


IRC is dead. Long live IRC. - <AUTHOR> http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-irc/

<comment><USER2> I owe so much to IRC. I learn a huge amount of things _everyday_ just having discussions on the various channels in freenode. The company firewall is no more an obstacle, thanks to <http://webchat.freenode.net/> . I often have collegues coming with questions whose answer I ignore, and I redirect them to #python, #perl, #bash, #bzr, #git, #algorithms, #html5, #jquery, #go-nuts, ##C++-general, #debian ... I made a few of them fellow addicts! I came to think that the answer to wathever question I can have is just a

      /msg alis list *<whatever topic>*

from me.</comment>


This Article Does Not Exist - <AUTHOR> https://thisarticledoesnotexist.com/ <comment><USER2> It's really interesting to see how far it gets with such limited information. For example:

>ACM signed letter opposing open access (newsroom.publishers.org)

>The American Country Music Association and the R & B and Gospel Music Association signed a letter of support to congressional leaders this week, speaking out against efforts to combat open access by forcing radio and cable operators to carry full-length music videos.

<comment><USER3> Thats great, but it reads about 10% better than a markov process generating related words, which of course is about freshmen English level writing.

Most of the article cannot be parsed with all the mild non sequitors.

</comment></comment><comment><USER4> > Every 30 minutes, the application will grab the top headlines from Reddit or > Hacker News and have the Transformer dream up each article from scratch.

And here I was impressed how realistic the headlines are.

<comment><USER5> I kept thinking well that headline's a bit weird hmm. I guess it's not that good yet.

</comment></comment><comment><USER6> Yikes, this kind of stuff is going to make black-hat SEO even worse.</comment>


With Tesla Entering Market, Hopes for Home Batteries Grow - <AUTHOR> http://www.nytimes.com/2015/05/14/business/international/with-tesla-entering-market-hopes-for-home-batteries-grow.html?mabReward=CTM <comment><USER2> Elon is amazing human being. Solar City, Tesla, SpaceX and now the home energy market. It's trendy (and expensive), but at the end of the day I think it can help to draw more attention to the space and environmental consciousness. Hopefully it's not just a fad...</comment>


The Tragedy of the Common Lisp, Or, Why Large Languages Explode - <AUTHOR> https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks <comment><USER2> One cool thing about Lisp is that you can easily embed new languages in it, and those languages can be small and beautiful. For example, I have a Python- esque FOR macro that uses an iterator protocol, and a universal binding macro that subsumes all of Common Lisp's binding constructs (LET, LET*, LABELS, FLET, MULTIPLE-VALUE-BIND, etc.) So for me, Common Lisp has actually shrunk without losing any functionality. This is not possible in languages without macros. Such languages are indeed doomed to either grow forever, or change in non-backwards-compatible ways (e.g. Python3). But with macros you can shrink a language as well as grow it. This is one of the reasons Common Lisp continues to thrive.

[UPDATE]: You can find my code here: [https://github.com/rongarret/ergolib](https://github.com/rongarret/ergolib)

Also, I forgot to mention another language-shrinker included in that library: REF. REF is a universal de-referencer that subsumes NTH, ELT, SLOT-VALUE, GETHASH and probably a few other things that I can't remember right now. It also lets you build abstract associative maps (a.k.a. dictionaries) with interchangeable implementations (see the DICTIONARY module), which lets you get rid of ASSOC and GETF.

<comment><USER3> I don't know Lisp, so correct me if I am wrong. The whole idea of embedding your own language sound pretty much the same as a growing the language, except that you are doing it yourself, in a non standard way.

<comment><USER2> If you build one new feature that subsumes N>1 old features then you're effectively shrinking the language because you never need to use those N old features any more. You can then support legacy code with macros that compile the old features into the new feature. At that point you've actually shrunk the language. You can even have those legacy support macros give compile-time warnings that the old, now-deprecated feature is being used and that the code ought to be changed. In fact, you can even easily write tools that will do this translation automatically. So yes, you really can shrink the language.

<comment><USER4> That sounds cool, but I have a deep-seated conviction that programming language design and implementation should be done by someone smarter than me.

<comment><USER5> Yet you're designing your language whenever you write a function.

<comment><USER6> I am ashamed to say that I only had this incredibly important insight very recently, after 20 years or so of programming .

I think it is one of those leveling up moments - a thing that once you know allows you to write better code at all times.

</comment></comment></comment></comment></comment></comment><comment><USER7> There is a great book about Lisp from Christian Queinnec titled "Lisp in Small Pieces" or LISP. Here is a little excerpt from it.

"There are subjects treated here that can be appreciated only if you make an effort proportional to their innate difficulty. To harken back to something like the language of courtly love in medieval France, there are certain objects of our affection that reveal their beauty and charm only when we make a chivalrous but determined assault on their defenses; they remain impregnable if we don't lay siege to the fortress of their inherent complexity. In that respect, the study of programming languages is a discipline that demands the mastery of tools, such as the lambda calculus and denotational semantics. While the design of this book will gradually take you from one topic to another in an orderly and logical way, it can't eliminate all effort on your part."

Lisp has some of the best literature around of any programming language. Anybody who really cares about craft of programming should make use of wisdom therein.

<comment><USER8> seeing this comment on HN, made my PG, a Lisp book author, is amusing. I have to admit that while I don't do Lisp day-to-day probably my favorite Lisp book(s) were written by him. The practical hacker in me prefers Python, Java and C.

But the elegant hacker in me? Prefers Lisp. And PG captured that in his writing.

<comment><USER9> IDK where the elegant but impractical (as it was a trade off). CL is a practical language. Consider loop, format, multiple values or the standard methd combination in CL.

While the only practical thing about python is that it has more libraries. Nevermind the fact that python scope is misdesigned even in Python 3!

</comment></comment></comment><comment><USER10> It was painful watching Common Lisp happen; too many competing interests, and commercial stakes. Unfortunately languages went a different direction. (I also mourn Smalltalk's "loss", but Java had much more money coming into it.)

Lisp50 went into this somewhat ([http://www.nhplace.com/kent/Papers/cl-untold- story.html](http://www.nhplace.com/kent/Papers/cl-untold-story.html)) and, unrelated, was a freakin' awesome good time. I sat next to Guy Steele for one talk but was too in awe to even say anything.

(Anecdote about same: I IMed a friend and said "I'm sitting next to Guy Steele" and he replied "Cool, ask him who Guy Steele is." Damn kids.

<comment><USER11> I really did not enjoy Lisp50. I was surprised to discover such a disconnect between the old-school and new-school Lispers. Guy Steele and co really didn't seem to have any interest at all in what people have done with Common Lisp these past 20 years or so. That is a pity because I had always really valued the perceived continuity of the Lisp community.

<comment><USER10> I think Clojure's reception was great--the oldies, overall, were very positive.

<comment><USER11> Agreed. That was classy. But that is also a sign of them having no interest in the modern Common Lisp community :).

<comment><USER10> I read it differently; I think they thought it was an interesting direction, but only that, another direction. The oldbies are pretty CL-oriented, although obviously many of them have moved on (e.g., Fortress for GLS).

</comment></comment></comment></comment></comment><comment><USER12> Though the 1994 ANSI standard is 1153 pages, Common Lisp somehow doesn't feel large. A lot of it is library pieces that can be understood more or less on their own and work independently. Somehow you can know the language well, without reading 1153 pages cover to cover. If you see anything in someone's code which is standard, but which you don't know well (or at all), it's not going to throw you a big curve ball.

C is a "small" language and is pushing 700 pages now.

Projects written using small languages tend to use lots of extensions. So do projects in larger languages, too; they use some subset of the core language, probably a small one, and then other libs which address problems not covered in the language at all.

How big is Perl? How much of CPAN should be included in that measurement? If the answer is "none", how realistic is that? Do you know Perl if you don't know any CPAN module?

How about Scheme? The base standard is small. But then there are SRFI's. It seems disingenuous not to count htem. And then there are implementations and their environments and extensions, which projects depend on. What better represents "Scheme size"? The R6RS document, or some measure of the size of, say, Racket?

<comment><USER13> I think the post was more about syntax, not standard library. Functions and methods are reasonable easy to lookup, syntax much less so.

Also try googling for some unknown syntax.

<comment><USER12> > _I think the post was more about syntax, not standard library_

If that is so, it has no point.

The bulk of the 1153 pages of the Common Lisp standard is in fact describing a standard library, so if the definition of "large language" is one that has a large core syntax, excluding standard library, then it's a small language, in fact.

Most of the syntax of a typical Lisp dialect (Common Lisp included) takes the form of a standard library. If you seen an unfamiliar syntax, it consists of a form with an unfamiliar symbol in the leftmost position:

       (unfamiliar-symbol ... stuff (you (do not)) understand)

You search your help resources for "unfamiliar-symbol".

The lexical syntax ("read syntax" in Lisp terms) is quite very small. It consists of elements like what constitutes a symbol token, what numeric and other constants look like, and other such elements. Stuff like:

      #(this is a vector)
      #c(3.0 4.0) ;; complex number 3.0i + 4.0.
      `(quasi ,quote)
      '(quoted list)
      package::symbol

</comment></comment></comment><comment><USER14> In the case of Java it is not that Java is a "large language", it is that to get anything useful done with Java you need to know about Maven and Spring and Log4J and Apache Commons Logging and SLF4J (because if you're using a lot of libraries surely all of those will be in use.)

That is, it is the complexity of the ecosystem, not of the language.

<comment><USER15> When I was learning Java recently in anticipation of a job programming Java - I was surprised by this reality. The core of Java is remarkably simple to learn - there's not really all that much to it.

The complexity is indeed in all of the libraries and build frameworks and well intentioned but silly HammerFactoryFactoryFactoryFactories.

<comment><USER16> I think the case can be made that Java was _too_ simple. It's inability to express very much within itself is what led to explosion of external tools to make it "better", or indeed, "work".

I think it was deliberately designed as a simple language to be used by large groups of people in simple ways, but actually failed so epically at that goal because of being _too_ simple that it actually destroyed the entire idea of building a language deliberately for large corporate use. (Note that it has grown a lot since then; it had to.) Go's the first language I've seen since Java try for that niche. I've said it before: In the short term Go may be stealing from Python and Node, but in the long term, Java's the one that needs to be worried about Go.

Edit: Literally six minutes later, my feeds produce for me: [http://www.businessinsider.com/google-go-update-from- jason-b...](http://www.businessinsider.com/google-go-update-from-jason- burberel-2015-6)

<comment><USER17> > In the short term Go may be stealing from Python and Node, but in the long > term

Go is a niche language.As a niche language it will perform well in its niche, but it will never be as big as Java or C#. Go total lack of expressiveness makes it unfit for a wide range of applications.

Java is rigid, but I think version 8 makes it more enjoyable. But it will not make all the terrible java core apis and framework go away.They are still here.

<comment><USER5> Java was also a niche language. People never learn unfortunately.

</comment></comment></comment></comment></comment><comment><USER18> I think lisp could benefit from a small core and building out a standard library. You could pack all the features it _needs_ (packaging, lexical/dynamic scoping (defvar), let/lambda, defun/defmacro, multiple values (via values, multiple-value-call), setf (w/ setf expansion), simple arithmetic, declare/declaim/proclaim, maybe a few more) into the core and have standard libraries: cl.bind (multiple-value-..., defparameter, etc), cl.math (sin, cos, etc), cl.clos, cl.collections (arrays, hash tables), cl.io, etc etc.

I think this would clean things up a lot, still preserve the spec (aside from documenting what's in which libs), and make things more approachable.

Shoving everything into the "common-lisp" package _works_ but it's cumbersome and you have to have the _entire language_ sitting there to use anything.

<comment><USER19> I don't have the exact quote/source right here handy, but I believe that was Guy Steele's intention with Scheme.

<comment><USER20> He gave a brilliant talk about it: "Growing a Language"[1].

The idea is to make languages that _grow_ —ones that provide a small, uniform core that can be extended by the user. Ideally, these extensions feel like first-class citizens: things added by users should feel on par with built-in language features.

It's still one of the best technical talks I've ever come across.

[1]: [https://www.youtube.com/watch?v=_ahvzDzKdB0](https://www.youtube.com/watch?v=_ahvzDzKdB0)

<comment><USER21> He even humorously implied that a growing language shrinks, by replacing many specific constructs with a single general one.

</comment></comment></comment></comment><comment><USER22> I'm glad someone said this. I'm an occasional JavaScript programmer, and I looked over ES6 last night and was surprised by how large it's become. And I learned that ES7 is already on the way.

That said, most of the features seem nice, and many are borrowed from stable languages like Python, so perhaps it's not too much. I'll have to try it and see.

It made me wonder what Crockford is up to, and what he thinks of this.

[https://github.com/lukehoban/es6features](https://github.com/lukehoban/es6features)

[http://es6-features.org/](http://es6-features.org/)

<comment><USER23> Yeah, I share the linked author's opinion of ES6 -- it's good stuff, but it's also a dangerous direction.

Part of me thinks that maybe what's needed is an updated version of "use strict" \-- "use es6" or whatever -- that would let you use the new features, but also prevent you from using some deprecated features, to keep the surface of the language somewhat smaller even as new stuff gets added.

<comment><USER24> That was seriously considered some years back and thrown out as likely to cause poor adoption and poor intermingling of language features.

[http://www.2ality.com/2014/12/one- javascript.html](http://www.2ality.com/2014/12/one-javascript.html)

</comment></comment></comment><comment><USER25> The plan for Common Lisp originally was to have a "core" and a standard library. From Daniel Weinreb's blog post "Complaints I'm Seeing About Common Lisp":

        It's just too big. Actually, the real problem is that the core of the language is not cleanly separated from the built-in libraries.  The Common Lisp designers had originally intended to do this separation, but there wasn't time enough.

[https://web.archive.org/web/20100706204555/http://danweinreb...](https://web.archive.org/web/20100706204555/http://danweinreb.org/blog/complaints- im-seeing-about-common-lisp)

(Daniel Weinreb was, among other things, one the designers of Common Lisp.)

Zach Beane has some more information on this at [https://xach.livejournal.com/319717.html](https://xach.livejournal.com/319717.html)

EDIT: "time enough", in the quote, may seem strange; after all, work began in 1984 and the standard was finalized in 1994. But remember that many stakeholders were companies with jobs to do, and they had to assign employees to the design/standardization work at real costs for said companies.

</comment><comment><USER26> I like the author's remarks and philosophy about keeping JavaScript small, but I thought the opening was remarkably uncharitable. The specific person and the specific feature are quite irrelevant to the point he's making here.

I am left with some admiration for his goals, but also a great deal of trepidation about ever suggesting anything or even talking about JavScript.next. Will I be the next one called out by name if I make the mistake of asking whether traits might be a good addition to JavaScript?

<comment><USER27> For what it's worth - the authors know each other from before and knowing both parties Mark did not intend to mean any offense.

<comment><USER26> I came back to note that Mark has subsequently clarified that he meant absolutely no slight against Kyle. He is a gentleman.

</comment></comment></comment><comment><USER28> Interestingly hardly anybody uses Algol, Smalltalk, Pascal and early Scheme anymore, while people still use Common Lisp. Perhaps "being small and beautiful" is actually a bad thing for a programming language?

</comment><comment><USER29> I didn't realize that Scheme had become bloated. I haven't looked at it in years, and thought it was still the basic language described in SICP.

<comment><USER30> See now the R7RS which is split into a small and large standard (the latter still in progress). R6RS was largely ignored by the community, and there wasn't huge growth prior to it.

</comment></comment><comment><USER31> Common Lisp actually has a core of a mere thirteen "special operators". You can think of everything else as standard library.

</comment><comment><USER32> ECMAScript 6 is a shame, there's a lot of stuff added which is unnecessary.

"let" is unnecessary. JS now has two kinds of variable scoping! "var"'s hoisting is annoying, sure, but we don't need two kinds of variable scope. If you want to scope something to a block, you can just use an IIFE.

"class" is unnecessary at best. JavaScript has a bunch of ways of constructing objects to choose from, and that's not a problem. Why lock users into one paradigm, and obscure what's actually happening underneath? This will just confuse people when they have to deal with code that doesn't use "class" syntax or the OOP model it presents.

Object property shorthand is confusing. Why the hell is {bar} equivalent to {bar: bar}? Isn't that a set literal (Python, math)? Why isn't there the colon, if it's an object? What the hell? Try explaining that to newcomers.

Computed property names looks weird and is misleading. You'd logically expect {[1+1]:2} to be an object with an Array (coërced to string?) key, because [] is an Array literal. But instead it means "compute this expression". In which case, why isn't it ()? That's what you'd intuitively expect. I've tried to use () before and was surprised it didn't work, even.

Method properties, e.g. { foo(a,b) { ... } }, are unnecessary given => functions.

All that being said, I think ES6 has some quite positive additions. Maps, sets, tail-call elimination, =>, modules and symbols are all very important and useful features JavaScript really needed.

<comment><USER33> >If you want to scope something to a block, you can just use an IIFE.

Now try doing that in a loop that you want to break out of. Edit: To save you the trouble - [https://github.com/babel/babel/issues/644](https://github.com/babel/babel/issues/644)

>"class" is unnecessary at best. ... Why lock users into one paradigm?

It canonicalizes one of the popular ways of doing classes (the other being the same but without `new`).

>Why the hell is {bar} equivalent to {bar: bar}? Isn't that a set literal (Python, math)?

{ ... } in JS has never meant set literals. It does however mean objects (dictionary literals) which is also how Python uses it.

>You'd logically expect {[1+1]:2} to be an object with an Array (coërced to string?) key, because [] is an Array literal.

[] has also always been used to index objects and arrays, so using it when generating the object with keys and values follows as an extension of that.

>Method properties, e.g. { foo(a,b) { ... } }, are unnecessary given => functions.

Arrow functions capture lexical this, which method properties do not. Compare `({ x: 5, foo() { return this.x; } }).foo()` with `({ x: 5, foo: () => this.x }).foo()` Arrow functions also do not have an arguments object.

<comment><USER32> > Now try doing that in a loop that you want to break out of.

Fair point, although this can be worked around. Though it begs the question of why you need block scoping anyway. If you have a function large enough to need it, you should probably break it down into smaller functions, and compose them.

> It canonicalizes one of the popular ways of doing classes

But there are other popular ways, and this way new users will have the underlying details hidden from them, meaning they'll encounter problems later. It's also potentially misleading.

> { ... } in JS has never meant set literals.

Yes, but it's never been { a, b } - there's always been a colon. Python also uses {} for dictionaries, but _with colons_. Having { a } magically use the variable's name as a key name, and also use the variable's value, is unintuitive. { a, b } in another language would be an array (C, C++) or a set literal (Python, mathematics). Nobody would expect it to do what it does here in ES6.

> [] has also always been used to index objects and arrays, so using it when > generating the object with keys and values follows as an extension of that.

I suppose that makes some sense, but we don't use [] for string keys in literals.

> Arrow functions capture lexical this, which method properties do not.

Oh, right, good point.

</comment></comment></comment><comment><USER34> The common fallacy about simple languages.

Yes the language might be simple to understand, but then the result is the complexity lands in the shoulders of developers and an ever increasing library of workarounds to compensate for missing features.

Hence why every simple language that achieves mainstream use, ends up becoming like the ones it intended to replace.

</comment><comment><USER35> My prespective could be very wrong but isn't this a sort of quality is in the eye of the beholder issue. I get building a silo isn't very beneficial to another. But isn't building monolithic library just as destructive. I don't think anything is perfect even if it's perfectly executed.

</comment><comment><USER36> Here's a title for a rebuttal in case anybody wants to write it. ;)

The Tragedy of ISLISP, Or, Why Small Languages Implode

</comment><comment><USER37> Whenever I encounter people arguing about Python3 I am reminded that I still miss Python1.

</comment><comment><USER38> Python also suffering in this regard. It has moved from being "a language that fits in your head" to a language where very few people on the planet know most of what's in it.

</comment><comment><USER39> You hear this "safe subset" thing about the syntax rich languages all the time and I really don't get it. I really do use all of C++. There are some pseudo deprecated bits and some extremely esoteric bits I don't hit, but beyond that I do wind up jogging most pieces of the language and standard library. Pretty much the same with my usage of perl. I've never written a source filter or a format, but otherwise I use a lot of the "niche" features regularly to great effect.

This whole sentiment comes from people who work on large rotating teams with enough inexperienced people, I guess? Sorry, learning a language properly takes a couple years or more. The features aren't wrong or bad, your team just doesn't know the tools well enough. You can't play modal jazz with the big boys until you can do your scales. I guess have fun doing your pop medleys with "simple" languages.

</comment><comment><USER40> The Arc language (which runs this site) is a remarkable attempt to "fix" what went wrong with CL. It lacks a decent runtime and native code compiler (it offloads everything to mzscheme, the way clojure did to JRE) but it is already more than a proof of concept.

The problem is that there is no more DoD or other grants for creating new Lisps anymore (particularly due to Java mass hysteria and prevalence of packer's mentality).

BTW, making something similar to SBCL (everything written in itself, except for a tiny kernel written in C) for Arc (a core language, without the kitchen sink syndrome) is of moderate difficulty compared to meaningless piling up of more and more of Java crap.</comment>


GitLab Enterprise Edition price change - <AUTHOR> https://about.gitlab.com/2016/03/21/gitlab-enterprise-edition-price-change/ <comment><USER2> Gitlab is really gunning for it. Some awesome sounding upcoming features[1]:

1\. Gitlab container registry

2\. Gitlab deploy

3\. Gitlab pipeline[2]

5\. Automatically squash before merge

6\. More expressive build matrix

Also shipping octotree as part of gitlab[3] - this was in response to a Reddit comment!

I'm really excited for the next few versions :)

1\. [https://about.gitlab.com/direction/](https://about.gitlab.com/direction/)

2\. [https://gitlab.com/gitlab-org/gitlab- ce/uploads/b2704189b606...](https://gitlab.com/gitlab-org/gitlab- ce/uploads/b2704189b6067c1adf3c32f6611a3f6c/Screen_Shot_2016-01-14_at_15.44.24.png)

3\. [https://gitlab.com/gitlab-org/gitlab- ce/issues/13723](https://gitlab.com/gitlab-org/gitlab-ce/issues/13723)

<comment><USER3> Thanks! Good to hear you're excited about the near future!

New release is going up in a few hours with the first bits of GitLab Deploy and some other cool stuff!

<comment><USER4> Thanks for building an amazing product! Lots of exciting things to look forward to. I've been using Gitlab for our company's projects and it has worked out great so far.

</comment></comment></comment><comment><USER5> Meta comment: this is an excellent price change announcement. SaaS providers should pay attention to this. It's never easy to please everyone with changes to price, and the announcement is quite upfront on the changes being made, why they're being made, and some examples of what the change looks like in practical terms (including the negative changes).

Well done GitLab.

<comment><USER6> Thank you very much. We value being transparent, and direct [https://about.gitlab.com/handbook/#values](https://about.gitlab.com/handbook/#values) I'm very proud that our sales and marketing teams also live by these values and are upfront about the reasons behind and the effects of the price change. I've shared your positive comment to encourage everyone to keep this up.

</comment></comment><comment><USER7> It's good to see this new pricing model. It's pretty obvious, a lot of the really hard problems that Enterprise would want solved, are being developed by commercially driven ventures. And by going this route, GitLab makes themselves WAY more attractive for these 3rd party vendors, to want to develop for GitLab.

Atlassian, with their Marketplace ([https://marketplace.atlassian.com/](https://marketplace.atlassian.com/)), clearly spelt out how they could make you (3rd party vendor) money, if you developed for Bitbucket. GitLab, until this recent price change, never had one.

Plus this makes sense. GitLab's greatest value, is its foot in the door for Enterprise, and this is good first step to leveraging it.

<comment><USER8> Actually the most things in the Marketplace for Bitbucket Server are pretty useless. Jenkins Integration is really bad compared to Gitlab, CI integration in Bitbucket Server is pretty bad, except for Bamboo..

<comment><USER6> Glad to hear you like the Jenkins integration in GitLab, most of the work was done by volunteers in [https://wiki.jenkins- ci.org/display/JENKINS/GitLab+Plugin](https://wiki.jenkins- ci.org/display/JENKINS/GitLab+Plugin)

In case you're interested some of our thoughts regarding plugin marketplaces from [https://about.gitlab.com/direction/#vision](https://about.gitlab.com/direction/#vision)

"Because GitLab is open source the enhancements can become part of the codebase instead of being external. This ensures the automated tests for all functionality are continually run, ensuring that plugins always work. It also ensures GitLab can continue to evolve with it's plugins instead of being bound to a plugin API that is hard to change and that resists refactoring. This ensures we have many years of quality code and great monthly releases ahead of us."

"That doesn't mean we'll never do a marketplace, in fact this is the way GitLab.com will be free forever."

<comment><USER8> @sytse a marketplace is mostly a excuse for not delivering features, so I'm glad you don't have one yet.

<comment><USER6> Haha, made my day :)

</comment></comment></comment></comment></comment><comment><USER9> > We want to charge more for 24/7 support.

I really appreciate their honesty, rather than rewording that to avoid admitting the truth.

<comment><USER6> Thanks, glad to hear that.

</comment></comment><comment><USER10> I like their honesty: We want to charge more for 24/7 support.

</comment><comment><USER11> Now that's good news (for me, at least).

I never paid to use GitLab because I'm using it for a private use and could not afford to pay for 10 licences when I only needed one. Seems like I have no excuses any more :)

<comment><USER8> The same goes for me and my company (which is actually at a team of 5)

<comment><USER12> Ever consider just going OS? Took me about an hour to set up gogs ([https://gogs.io/](https://gogs.io/))

<comment><USER13> GitLab CE is Open Source too and should at least be feature-equivalent to gogs. (gogs is still a great project!)

</comment></comment></comment></comment><comment><USER14> $39/user/year is indeed affordable for small teams. I'm using bitbucket and github these days. Now if gitlab can run on smaller VPS instances I will be totally sold. That is, if I'm a small team, why do I need 2GB-memory etc to run gitlab? which costs more monthly, how about 512MB memory with one-core for a small team? Can it be optimized further?

<comment><USER6> If you want to use GitLab as a service please consider GitLab.com [https://about.gitlab.com/gitlab-com/](https://about.gitlab.com/gitlab-com/) it has unlimited public/private repositories and collaborators.

</comment></comment><comment><AUTHOR> I think it's great they are dropping the price for smaller teams, but there will be some huge price increases for some companies. The examples they give all include the 50% discount so the 100 user with support will actually end up costing $13,800 instead of the $4,900 that they would be currently paying after the initial discount ends.

<comment><USER15> Premium Support, regular support comes with GitLab EE by the looks of it. You technically still get support without paying for Premium Support, you're just not "top priority."

Update Disclaimer: I don't work for GitLab, I'm just assuming based on what the pricing page states.

<comment><USER3> That's correct. Any customer can reach out to us at any time, with any frequency and will always get an answer as soon as possible.

The difference is 24/7 emergency support, which is a line that will literally wake up our engineers (in the off chance that no one is available) in cases of emergency.

With premium support you also get a dedicated engineer, which helps if you have a more complex setup; Training; Live upgrade assistance and HA support.

</comment></comment></comment><comment><USER16> After spending two minutes clicking around my free account, I couldn't see either how I'd upgrade to a paid account or why I'd want to. Seems like an important usability issue.

<comment><USER3> On GitLab.com? We're not offering paid upgrades there (you can only pay for support, $9.99 p/u/year [0].

Most of our customers run GitLab on their own servers, for which you have to pay if you want to run Enterprise Edition. You'd be prompted for a license key and the means to get one.

It might be a good idea to do this differently in the future, but we're not keen on running anything else than default GitLab EE on GitLab.com.

[0]: [https://about.gitlab.com/gitlab-com/](https://about.gitlab.com/gitlab- com/)

<comment><USER17> There are FOSS projects that would like to host with you but won't because "Take advantage of all the benefits of GitLab EE" is a requirement on gitlab.com instead of something you can elect to use.

I'm not one of those people, by the way, but I do understand the frustration of seeing someone handing out cheese and crackers, and after stepping up to ask for "no cheese, thanks", being told they _must_ take it with cheese.

<comment><USER6> We understand the dilemma. For us it is important to be able to run all the EE features at scale so we can troubleshoot problems on an environment we have access to. You can use GitLab.com without using the EE features, but you can't disable the features. We thought about disabling or marking the features but this seemed too complex. For a list of the differences please see [https://about.gitlab.com/features/#compare](https://about.gitlab.com/features/#compare)

</comment></comment></comment></comment><comment><USER18> This is awesome! If only you had made this change about a yr ago we would be running Gitlab instead of Stash/Bitbucket. The new pricing plan will put you guys ahead of both GitHub Enterprise and Bitbucket Server.</comment>


PHP Annotations Are a Horrible Idea - <AUTHOR> http://theunraveler.com/blog/2012/php-annotations-are-a-horrible-idea/ <comment><USER4> This is pure horse pucky.

First of all PHP isn't about elegance and I find it a teeth grinding experience when people complain about it not being so. PHP is about getting stuff done.

He doesn't offer one good valid technical reason why not to use comments for meta-programming PHP other than "it just feels wrong" and an "icky feeling" which is entirely subjective. "Reliance on Yet Another Library"? C'mon.

The fact that you can even parse out comments with the reflection API lends, to me, that meta-programming is a-ok.

Also, his alternatives are kind of weak. Here's an annotation:

        /**
         * @Column(type="string", length=32, unique=true, nullable=false)
         */
        protected $username;

And here's his proposed alternative:

        class User
        {
            public static $mapping = array(
                'username' => array(
                    'type' => 'string',
                    'length' => 32,
                    'unique' => true,
                    'nullable' => function() {
                        // Some logic to determine value.
                    }
                )
            );
        }

I'll take the first one because I have other shit I need to do.

<comment><USER5> I think this is quite a good technical reason:

        Because code comments should never be necessary for a script to function properly.

In which other language do you see comment is necessary to make the code function properly?

<comment><USER6> Its a syntax problem then ? what if the annotation wasn't inside comments would that make it ok ?

<comment><USER7> A lot of this boils down to PHP's feeble "array" declarator. Take a page from JavaScript and make it easy.

<comment><USER8> As of PHP 5.4 you can use [] to define arrays. It saves some typing, and is less noisy on the eyes I guess.

<comment><USER7> That's exactly the way it should be. Hopefully this will become the standard before long.

</comment></comment></comment></comment></comment></comment><comment><USER9> Annotations are not required to use either of those libraries. Doctrine allows mapping information to be defined in XML or YAML files. For Symfony, the @Template annotation is not part of the core at all: it is part of the SensioFrameworkExtraBundle, which can be turned off easily. The normal way to render a template is:

        return $this->render("MyBundle:Controller:template.html.php", array(...));

That said, it would be easy enough to add the static variable-based mapping information to Doctrine as a metadata driver, and create a version of SensioFrameworkExtraBundle that does the same for its annotations.

</comment><comment><USER10> > the PHP community is now officially so desperate for better metaprogramming > capabilities that it is attempting to do so using code comments

This says it all ... and to be honest, from an ease point of view I like using annotations but as with most parts of PHP it's the implementation that sucks (or the lack of implementation)

Over 2 years ago a RFC has been filed for native php annotations and I must say that I like the idea of annotations being part of the actual language and not relying on Inflection on comments (wtf?) to attach metadata to classes, propeties or methods. Just too bad nobody can get their act together and get it implemented in the core. <https://wiki.php.net/rfc/annotations>

<comment><USER11> That somebody could be you!

<comment><USER10> Problem is not finding someone to implement it, problem is getting the core devs on one line concerning the syntax/implementations. There have been numerous suggestions but none were deemed good enough, and maybe for good enough reasons I might add.

[http://marc.info/?l=php- internals&m=130496081925265&...](http://marc.info/?l=php- internals&m=130496081925265&w=2)

</comment></comment></comment><comment><USER12> "Without the special @Template comment, Symfony does not know where to find the template file."

First off, this is completely false. With symfony2 the action needs to return a Response object. This annotation isn't required and the team I work with, we rarely use this.

It's very useful for when you are just adding a page that contains no real business logic.

"Doctrine 2 does the same thing when declaring object properties based on database table columns1:"

Oh look, there's a footnote.

"Fortunately, Doctrine also allows you to declare property metadata using PHP, YAML, or XML"

What?

"Because code comments should never be necessary for a script to function properly"

So your points are that we need @Template annotation to be able to render a template, which is FALSE, and you state the same with with Doctrine2 which you point out there are other ways to do it.

All your points for "DX Regressions" are completely wrong.

Unless I am using a special plugin with my IDE it's not going to link "AcmeBlogBundle:Post" to src/Acme/BlogBundle/Entity/Post.php. Most of what you point out is complete bullshit. What do I gain to hope by using var_dump() on an annotation? I know that in a Doctrine Entity that the column type is a string.

Articles and posts like this drive me banana's with the complete lack of understanding what you're writing about.

<comment><AUTHOR> > First off, this is completely false. With symfony2 the action needs to > return a Response object. This annotation isn't required and the team I work > with, we rarely use this.

Correct. But if you want use the form where you just return an array of variables to use inside your template, and have Symfony smartly located the template for you, you have to use an annotation. See [http://stackoverflow.com/questions/12922827/symfony-2-php- te...](http://stackoverflow.com/questions/12922827/symfony-2-php-templates- autoloading) for an example.

> and you state the same with with Doctrine2 which you point out there are > other ways to do it.

Yes, there are other BETTER ways to do it. Making comment-based annotations available as one of the ways pretty much guarantees that people will use it, and that seems like a bad idea to me. Just remove them so no one is able to choose the bad practice.

> All your points for "DX Regressions" are completely wrong.

Uhh, OK? How about comment folding in text editors? Would you, as a developer, be happy if you encountered some code that made heavy use of annotations for critical application logic? I wouldn't--this is what I mean by DX.

> What do I gain to hope by using var_dump() on an annotation?

The same thing you gain by var_dump()ing any variable--an understand of what's happening under the hood.

<comment><USER12> > Correct. But if you want use the form where you just return an array of > variables to use inside your template, and have Symfony smartly located the > template for you, you have to use an annotation. See > [http://stackoverflow.com/questions/12922827/symfony-2-php- > te...](http://stackoverflow.com/questions/12922827/symfony-2-php-te..). for > an example.

Your point is that this is required, it's not. Using annotations is optional. The user you point to in the example wanted to use the annotations and wanted to use php templates.

The FACT is that in Symfony2, your Action MUST return a Response object. Using annotations is an easy way to get around this.

> Yes, there are other BETTER ways to do it. Making comment-based annotations > available as one of the ways pretty much guarantees that people will use it, > and that seems like a bad idea to me. Just remove them so no one is able to > choose the bad practice.

Why is this a bad practice? Everything I need to now is right there in the annotation. I know that it's a string, integer, or anything else. I don't need to open up another file to check.

> Uhh, OK? How about comment folding in text editors? Would you, as a > developer, be happy if you encountered some code that made heavy use of > annotations for critical application logic? I wouldn't--this is what I mean > by DX.

... You can't unfold them? You mean to tell me that having an editor that folds comments is bad design for the software that uses annotations? I'm trying to figure out this critical application logic you speak of. If I'm using annotations to describe a column that is a "string" type and has a length of "32" then what is the difference of it's in a yml or xml file? I enjoy being able to tell that as well as what relationships there are.

> The same thing you gain by var_dump()ing any variable--an understand of > what's happening under the hood.

Again, why are you trying to var_dump something that has no value in using a var_dump on? An example of using var_dump and it being useful is "var_dump($user->getSomeRandomCrap())". It tells me what is returned by that method. Is an object or something else returned. WHY DO NEED to var_dump "@Column(type="string", length=32)"? I know the property should be a string and should be a max of 32 characters long?

</comment></comment></comment><comment><USER13> Closures inside property initializations inside the class body don't work. Not even in an array.

So this code throws up a "Parse error: syntax error, unexpected 'function' (T_FUNCTION)"

        class User
        {
            public static $mapping = array(
                'username' => array(
                    'type' => 'string',
                    'length' => 32,
                    'unique' => true,
                    'nullable' => function() {
                        // Some logic to determine value.
                    }
                )
            );
        }

<comment><USER14> Came here to post the same thing. I don't know if it has been fixed in 5.4, though.

<comment><USER15> Nope, the parser seems to be pretty brittle around this. Someone who knows more about the internals can probably explain why this works:

      class User
      {
          public $mapping = array(
              'username' => array(
                  'type' => 'string',
                  'length' => 32,
                  'unique' => true,
              )
          );

          public function __construct()
          {
          	$this->mapping['nullable'] = function() { echo "test"; };
          	$this->mapping['nullable']();
          }
      }

      $user = new User();

And this doesn't:

      class User
      {
          public static $mapping = array(
              'username' => array(
                  'type' => 'string',
                  'length' => 32,
                  'unique' => true,
              )
          );

          public static function set()
      	{
      		self::$mapping['nullable'] = function() { echo "test"; };
      		self::$mapping['nullable']();
      	}
      }

      User::set();

<comment><USER16> I used to be interested in helping fix PHP, but I gave up.

The reason is because Rasmus and a few others seem to think that using the syntax definition to do your type checking for you is a good idea, and that the hundreds of possible cases they didn't think of, don't matter.

</comment></comment></comment></comment><comment><USER17> Couldn't agree more. Every time I use annotations I feel dirty...

Programmers who talk so much about code separation, clean modular structure etc are the same ones are willing to use annotations. What got into them?

Disclaimer: I like code to be elegant. And practical. This is PHP we're talking about, but no need to do more bad choices...

</comment><comment><USER18> This could be solved if annotations were supported syntax. This works well in other languages (e.g. decorators in Python and annotations in Java)

<comment><USER19> And before annotations were added in java, the exact same hack was used for annotations. The alternative was to have separate configuration and mapping files which was _painful_. And then, you had libraries which did not have in- comment annotations and intermediate ones which compiled in-comment annotations to the original libraries's mapping files. Oh the fun we had.

</comment></comment><comment><USER20> Agreed. A comment is an explanation about some part of the program. Not the program itself. Its meant to be ignored by the computer. Putting logic in the comments is just downright stupid. Its one of those overly "clever" things "smart" people do to make their code be _cutting edge_. Nope. As good as Symfony is, my main issue comes down to design decisions as this one. Its just dumb. Having logic in comments its like putting beer in baby formula, just in case I run out of beer. Shit doesnt make sense.

</comment><comment><USER21> I've just ported java's bean vaidation to PHP using annotations in comments, and I strongly disagree.

Point by point:

1\. dx regressions

I've designed the annotation system so that if developers misdeclare them an exception is thrown. Unit tests will fail, and the software will not run. Someone checking in code that fails to such a degree deserves what's coming to them. That covers php -l. Var_dump and debug_backtrace are irrelevant to my use case, and I use proper breakpoints and watches anyway (phpstorm + zend debugger). I don't even understand the point he's trying to make about IDE linking. Which leaves the argument about comment folding, which I think has some merit, if you think comments shouldn't be read, which I don't.

2\. Readability

Nonsense. Learning an API always requires getting used to its idiosyncracies. His proposal to use static variables looks less readable to me.

3\. Reliance on another library

Yes, that's kind of the point.

4\. Icky feeling

Aha, bingo. The author came in with the opposite bias of myself and drew an according conclusion.

To conclude: the use of annotations in comments is not better or worse than alternatives, it's all in the eye of the beholder.

</comment><comment><USER22> Somewhat related, I recently made a simple type annotation library and checker for Python 3...

<https://github.com/williame/obiwan>

Static type checking for Python yeah!

</comment><comment><USER23> First of all, annotations are nothing new. They have been around in Java for years, and it was emulated because it had advantages that really don't need to be regurgitated by me. If they weren't a good idea, they wouldn't have lead to a formal adoption inside the language.

Secondly, in both Symfony2 and Doctrine2, annotations are an OPTION. You use them if you want to use them, and if you don't want to, you can use traditional configuration files. It doesn't seem that the author has done anything with either Symfony2 or Doctrine2, or he would have understood that. As someone who used Symfony1, ZF1, Propel and Doctrine, I would not go back to the old way of doing things, even if I was offered good money to do so (as happened just last week in fact).

Most people who actively use these components LOVE annotations, because they allow you to keep the configuration close to the code, and reduce verbosity.

They drive code generation, and reduce the amount of code that has to be written to get a specific job done. So if there's a problem debugging, is it really about annotations, or about code generation, and if we can't have code generation (facepalm) then I suppose we shouldn't have template systems like smarty or twig, simply because "debugging is harder" and editors have more work to do.

If it's not the author's cup of tea, nobody is forcing anyone to use these capabilities. Needless to say, I couldn't disagree with the premise of this article more. @jawngee already provided a simple salient example.

</comment><comment><USER11> What's in the annotation is configuration, not application logic. As such there's no real difference between putting configuration into YML, XML and annotation comments.

In response to your 4 specific criticisms: 1\. (DX regressions) - in theory yes, in practice the frameworks are good at this. The annotations compile down to PHP which you can look at directly, and you get exceptions if there is something wrong with the annotation. 2\. (Decreased readability) - <USER2> POV. I find it easier, because the relevant configuration is next to the code to which it applies. It also prevents crufty out-of-date comments floating around. 3\. (Yet another library) - Yep. No answer there. 4\. (Icky feeling) - I get far more icky feelings out of seeing 30 lines of custom written 'setup code'. Annotations help to prevent that.

<comment><USER24> It violates the "I don't need to look inside comments for sources of bugs" rule I'm quite fond of.

I've defended PHP for some time now, but this is getting ridiculous.

Isn't PHP embedded inside markup? Wouldn't it be simpler to do something like:

?> < ... XML GOES HERE ... > <?php

and not violate any expectations?

<comment><USER25> no that's bad really.

The best way to write PHP for the web is like any language: php echos or prints shit, that's it.

The way you're showing is that of the total noob trying to implement some php inside their evil dreamweaver website.

Besides, if you're handling markup (in the web context) on the server side, you've already failed, as most markup should only be generated client-side, diminishing server-load and bandwidth consumed while greatly improving cacheability.

<comment><USER24> I strongly disagree. Echoing well-formated HTML is much harder than simply tagging around it, and what's the benefit of echoing it? You like escaping characters?

<comment><USER25> You didn't read the whole post.

1) your js should be echoing the HTML and getting data through JSON ajax

2) echo and print both work in command line, are explicit and work exactly as any language, whereas peppering your shit with php tags looks like shit and a maintenance nightmare.

If you have trouble escaping characters, you should consider the single quote, it's known to rock the boat.

Additionally, "'.$var.'" is the best, fastest, cleanest no surprise approach to inserting variables in markup, leaving double quotes just fine and dandy inside your markup.

And then, I'm pretty sure I'd rather have a string with 100% warranty of no execution or interpretation (that's single quote versus double quote for me) than any kind of dirty markup polluting my source code.

On the same subject, there is no valid reason for having naked markup inside your PHP, or between PHP tags because you're just begging for problems.

And I would expect multiple PHP tags to cause some minimal parsing overhead too.

Either way this matters not because the only sane way to use PHP in a web application is echo json_encode($return); or header(file) + readfile

And even then the second example is only there because javascript can't be arsed to support file creation/download (i.e. server -> blob.gz -> js -> would you like to dload this shit ?)

</comment></comment></comment></comment></comment><comment><USER26> Seriously, what sort of argument is this... (Allow me to paraphrase) "PHP doesn't have annotations, so instead it has hacked up comments that stand in for annotations. I find these ugly because it's abusing comments/etc therefore the idea of having a non-ugly real implementation that removes most of my objections is a bad idea"

\--EDIT I may have slightly not realised it was just comment annotations that were the problem here rather than annotations as a whole.... HOLD FIRE.

<comment><AUTHOR> I added an update to the article. I wasn't aware of the RFC to make annotations a language feature when I wrote the article. The article is specifically referring to annotations implemented as code comments.

Sorry for the confusion, and thanks for your comment.

</comment></comment><comment><USER27> I fail to see how an array makes debugging say a routing directive easier. The issue is generally incorrect names or values which will not be aided by a backtrace or a var_dump - you know the value in either scenario. You will still have to dive into the parser and understand what it's looking for to resolve your problem or delve into XDebug.

In the situations when knowing the value of something does not help, I do not see why annotations wouldn't be superior.

<comment><AUTHOR> At least you would know if your array contains a syntax error. With an annotation, you would have no way of knowing that aside from what the annotation parser spits out.

</comment></comment><comment><USER28> I found this very ironic.

I see PHP Annotations as a hack for comments. That said, I found very ironic someone giving a rant of a hack in hacker news. Just saying.. :)

<comment><USER29> There are hacks and then there are crutches.

</comment></comment><comment><USER30> I completely agree with you, but I would use something like this - <http://pastebin.com/embed_iframe.php?i=U4Fmm0t6>

I don't think that just an array quite make it as a real alternative but a definition builder called from a method seems more appropriate. Also I would seperate model definition from model repository.

</comment><comment><USER31> Having used both doctrine and used a format of array mappings, I prefer the doctrine way of using annotations.

However I do also acknowledge that putting important information into comments can be somewhat dangerous. Doctrine does support storing metadata in yaml and xml files too, but in that case you need to ensure that changes to your model class get reflected in the mapping file.

</comment><comment><USER32> Annotations (or decorators) are good idea as it is — they are very popular in Python. The bad part is that they are implemented horribly — as comment which are later parsed.

This should be implemented in PHP core or at least someone should write extension for it. That would solve implementation problems and add new, good feature to PHP language.

</comment><comment><USER33> You don't _need_ to use annotations with Symfony2. You can use yaml or xml configs if you want.

I have a big project written with Symfony2 - not a single annotation to be found.

</comment><comment><USER34> DX - As in Developer Experience? That's a first for me.

</comment><comment><USER35> Comments should be comments only, but your code in "alternative" is very dirty. Static(!) public(!) property is violation of encapsulation.

<comment><AUTHOR> I don't understand how. It's a static property because it applies to all object of the class, not an individual object (i.e. an individual object shouldn't be able to change it).

And how is making the property public a bad idea? The configuration system that parses it will need to read the property, no? And a method like getUsername() should be reserved for actually getting the value of that field, not its config.

<comment><USER35> "It's a static property because it applies to all object of the class, not an individual object"

Why? if you will have 3 databases, each will have same password?

"And how is making the property public a bad idea?"

Because it's breaks encapsulation.

Also, there is two kind of "class" usages in PHP: as Object and as Structure. If your class is just Structure (contain no methods at all), then, of course, public properties is what we need. But when your class is an Object, which should have instances, API, then keep all properties encapsulated.

</comment></comment></comment><comment><USER36> For me a lot of the fun in PHP in the last few years has been balls-to-the- walls metaprogramming.

</comment><comment><USER37> PHP Is a Horrible Idea - <USER3>

</comment><comment><USER25> That article misses the point:

PHP OO is a HORRIBLE IDEA. if you're doing OO PHP, shoot your other foot right now and go learn PHP before using it java-style.

Why is it that every time somebody on HN explains that a technology is not suitable for a use case, it gets downvoted by fans of said technology ?

<comment><AUTHOR> Why is PHP OO a horrible idea?

<comment><USER25> PHP OO is broken in many ways (of which you can find a list in the blog post "php a fractal of bad design"

PHP is naturally (due to it's C libs) non-OO and will thus only implement OO "that" far.

Lastly, OO is not a silver bullet and is best used _only_ in front-end, and languages that were designed with it in mind.

<comment><USER38> Well, OOP in PHP seems to work rather well for thousands of large projects out in the wild - making your argument invalid.

<comment><USER25> Well, smoking cigarettes seems to work rather well for millions of successful people out in the wild - making your argument invalid.

It IS possible to make "business good" software in brainfuck, that's just not a reason to call it "not broken".

See, this is about science, logic, and whether or not a feature is properly supported by a language, not about whether or not somebody managed to build and sell a solution while using that feature.

</comment></comment></comment></comment></comment><comment><USER39>
      while (true)
         read("http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/");</comment>


Fly offspring can resemble mother's previous sexual partner - <AUTHOR> http://www.smh.com.au/technology/sci-tech/ghosts-of-mothers-sexual-past-show-up-in-fly-offspring-study-shows-20141001-10onn3.html

<comment><AUTHOR> Linked to that article since it's linked directly by the University of New South Wales

[http://newsroom.unsw.edu.au/news/science/semen-secrets- how-p...](http://newsroom.unsw.edu.au/news/science/semen-secrets-how-previous- sexual-partner-can-influence-another-male%E2%80%99s-offspring)

Otherwise, see what one could achieve by leaving out the flies in the headline altogether, leave it to the Brits:

 _Your baby looks like your ex? This research is scarier than Alien_ [http://www.theguardian.com/commentisfree/2014/oct/02/baby- lo...](http://www.theguardian.com/commentisfree/2014/oct/02/baby-looks-like- ex-research)

 _Could previous lovers influence appearance of future children?_ [http://www.telegraph.co.uk/science/science- news/11133203/Cou...](http://www.telegraph.co.uk/science/science- news/11133203/Could-previous-lovers-influence-appearance-of-future- children.html)

So I guess we just made it half-way through the science news cycle: [http://www.phdcomics.com/comics/archive.php?comicid=1174](http://www.phdcomics.com/comics/archive.php?comicid=1174)

</comment><comment><USER2> Article abstract and (paywalled?) full text here: [http://onlinelibrary.wiley.com/doi/10.1111/ele.12373/abstrac...](http://onlinelibrary.wiley.com/doi/10.1111/ele.12373/abstract)

Interesting if it holds up and is widely applicable. Spontaneously it strikes me that it might have important consequences for female promiscuity.

<comment><USER3> Potentially dangerously negative consequences: [http://en.wikipedia.org/wiki/Telegony_(pregnancy)](http://en.wikipedia.org/wiki/Telegony_\(pregnancy\)) (although this article badly needs a rewrite, I assume the external references are legit).

<comment><USER4> Yeah, that wikiperida is sketch.

"According to Encyclopedia Britannica, telegony is now classed as superstition.[3]"

</comment></comment></comment><comment><USER5> This is more amazing than the title makes it sound. This isn't talking about the "Father" of the fly, but a sperm that entered the egg after it was fertilized. Non-genetic inheritance... very interesting. I hope it can be replicated.

<comment><USER6> Is that what it says? It seemed to suggest that young eggs could be contaminated by a sperm long before they are eventually fertilized.

It's unclear to me what 'contaminated' means here, but I'm not a biologist.

</comment></comment><comment><USER7> I read this as "that offspring is fly."

</comment><comment><USER8> Double-edged sword. On the one hand, I'm only going to marry a virgin now. On the other hand, there might already be kids walking around out there who resemble me.

<comment><USER8> lol ok I guess I deserved that.

More seriously, I love research like this that challenges existing understanding. Of course, if it holds true for humans this certainly opens up a Pandora's Box of sorts (which is what I was aiming for in the above comment).</comment></comment>


Birds use cigarette butts to line nests - <AUTHOR> http://www.bbc.co.uk/news/uk-scotland-edinburgh-east-fife-20607413

<comment><AUTHOR> I find this facinating that birds are somehow able to detect the chemical compounds needed to kill mites and adapt. Questions it raises are many. Was this learned thru trial or error or are they able to sence the needed chemicals to keep mites and bugs at bay.

Either way this certainly defines the term Hacker if this was done by humans. With that don't forget to put out some bread and nuts for our fellow avian hackers during the winter.

</comment><comment><USER2> Take that, hippie environmentalists concerned about "second hand smoke"! YOU'RE KILLING THE BIRDS!</comment>


Opera will use Blink - <AUTHOR> http://www.brucelawson.co.uk/2013/hello-blink/ <comment><USER2> I used to use Opera for many years, and IMHO it was almost always the best browser around feature and speed-wise. The only thing holding it back was the rendering engine.

I ended up making the switch to Chrome when Opera 12 came out and was too buggy for my taste (it was the last straw). It took a while to make Chrome feel Opera-ish, but I still miss Opera from time to time, you know, because of the little things.

One thing I wish Chrome had is the ability to select hyperlinks. Opera would let you click and hold the mouse cursor anywhere on a hyperlinked text and select it. If you try the same in Chrome, it will try to drag & drop the link instead of starting a selection. In fact, sometimes it gets really tricky to try to select hyperlinked text.

<comment><USER3> You might already know this, but Chrome automatically selects hyperlinked text when you right-click it. You're not able to select a part of it, but if you want to copy just the text, all of it, you can right-click any link, and then choose "Copy", right under "Copy link address".

</comment></comment><comment><USER4> _Vendor prefixes were like Morrissey's solo career: on paper, a good idea – but in reality, a horrible mess._

Best line of that blog post :)

<comment><USER5> It's a ridiculous example of "good on paper, not in reality."

All of his albums are good or better, almost all the albums sold well – and the more recent ones like You Are the Quarry are superb. Oh, and he's great to see live solo.

How about almost any rock band reforming? A great idea on paper and almost always a terrible idea. Smashing Pumpkins?

(How about _the Euro_ if you want a good example?)

<comment><USER6> The Euro was a mistake on paper. It held out pretty well in the first few years compared to that.

</comment></comment></comment><comment><USER7> This is quickly turning into the tech version of Game of Thrones.

</comment><comment><USER8> I, somehow, missed the news about the new Blink rendering engine and thought this was about Opera supporting the <blink> tag. Phew.

<comment><USER9> So, by moving to Blink, Opera loses <blink>.

I guess those nostalgic for the 90s shall have to rely on Firefox, inheritor of Netscape's mantle.

</comment></comment><comment><USER10> Opera's rendering was never the worst thing about it. The thing I always hated about it was its clunky bizarre UI.

<comment><USER11> Funny, its UI was always my #1 reason for using it. MDI + ability to completely hide tabs and Ctrl-Tab through them + Vim keybind scheme = fast workflow and maximized screen real estate.

Even to this day no other browser can match it, though Chrome/ium with a Vim plugin comes close.

<comment><USER12> Erhm, have you tried vimperator/pentadactyl? You know, one of the projects that _started_ this whole "let's bake Vim into the browser"-craze? (They didn't exactly start it, I think, but they sure made it popular.) I can distinctly remember a couple of years ago when I switched _from_ Opera to Firefox precisely because of Vimperator, because it was impossible to replicate the experience fully within Opera. It is still impossible today: Pentadactyl (Vimperator's successor) is much more fully-featured than anything you can do in any other browser, because of Firefox' approach to plugins.

<comment><USER13> You can bind any action to any key you like in Opera, how did you fail to implement a vim-like keybinding scheme then?

<comment><USER12> It's not the binds. It's all of it, including stuff like buffer lists, programmability, marks (marks are _so_ _bloody_ important to me when reading long web pages. I'm seriously, seriously angered by the fact that PDF readers don't have them, and I might, one of these days, scratch my own itch and go hack them into evince or so.)

Opera doesn't even have a concept of marks. Never mind marks across browser windows, tabs, or even pages you don't have open. Also, I love the minimalistic interface: you only see a small status bar, and (optionally) a tab bar. You can even hide everything. You can't do that with Opera (at all.)

</comment></comment></comment></comment></comment><comment><USER14> Everyone is picking their sides in this battle it seems.

I wonder what chrome for iOS is going to use (given that it's more just a wrapper around UIWebView with some chrome like features).

<comment><USER15> Chrome for iOS will be forced to use WebKit as its rendering engine due to Apple's strict policies.

</comment></comment><comment><USER16> what will decide Opera fates is it's monetization strategy.

for browsers, that's the biggest difference (after quality of product)

Google, the monetization is selling the user. So you get features like no- referrer removed (3 or 4 times) from the chromium project by google commits.

if opera also monetize by selling the user, it will have no chance. at all. On the other hand, selling software or showing ads are also not viable. So i'm very curious to what they are going to do.

btw, what is the current business model of opera to begin with?! do they live only on licensing opera mobile for phone manufacturers?

Edit: the answer for the question at the end is Yes. [http://my.opera.com/chooseopera/blog/2011/01/03/how-does- ope...](http://my.opera.com/chooseopera/blog/2011/01/03/how-does-opera-make- money-aka-our-most-asked-question-ever)

<comment><USER17> >Google, the monetization is selling the user. So you get features like no- referrer removed (3 or 4 times) from the chromium project by google commits.

Do you have a source for that? I'd like to read more about it!

<comment><USER16> search for stackexchange questions on how to change/disable referrer on chrome. you will see several accepted answers of things that do not work anymore. just be sure to search for some years ago.

from top of my mind, the command line option. the chorme:network-setting(sic) thing. the compile option flag

also, everytime i mention it people ask for source (on this forum where hardly there's time for any discussion!) and once i collected all the commits, but it's on my hell-banned account @gcb. feel free to dig that comment out if you like.

</comment></comment></comment><comment><USER18> My heart sank a little for Opera on reading this news; so it's good to know Opera was in on the secret. If not when they made the decision to adopt WebKit, then at least some point before the Blink news dropped.

</comment><comment><USER19> _"Our ambition is to contribute Opera's browser engine expertise to Blink, ranging from the implementation of new web standards to improvements in existing code."_

 _"Our ambition is to contribute Opera's browser engine expertise to WebKit, ranging from the implementation of new web standards to improvements in existing code."_

 _"Our ambition is to contribute Opera's browser engine expertise to Gecko, ranging from the implementation of new web standards to improvements in existing code."_

Funny how adaptable these are. If you can't decide, just abstract away.

<comment><USER20> If you can't beat 'em, join 'em.

<comment><USER21> cant beat the system ? go with the flow.

</comment></comment></comment><comment><USER22> As a long time Opera user, I'm really looking forward to their switch.

</comment><comment><USER23> Does this mean that Opera wont get sandboxing and "tab isolation"?

My understanding was one of the reasons Google forked as to rip out the webkit2 versions of those things, in favor of their own, which are fairly tightly tied to Chrome.

So either Opera is going to be more "chromey" or...they are going to reimplement those parts? Maybe they already have them (I am not that familiar with Opera these days)?

<comment><USER24> If something is in Chromium, it will be in Opera. It's as simple as that. And Chromium has tab isolation.

<comment><USER23> You didn't really answer _any_ of my questions. (EDIT: I guess you did actually answer the first one. Thanks.) You certainly aren't required to, but still.. did you only read the first sentence I wrote?

<comment><USER25> Opera have said from the beginning that they are dropping Presto and switching to the chromium toolkit. New Opera is effectively a thick skin on top of Chromium. The world miss reported it as them switching to WebKit, which is true but not the layer they are taking it at. It's no surprise that they are following google with Blink.

<comment><USER23> Ah. Thanks for the clarification!

</comment></comment></comment></comment></comment><comment><USER26> So this is a fork of webkit? Does Safari get stuck with some incompatible because different engine? Apple can/will join blink too? How will it display the >blink< taglement? It's like Google are saying, "thanks for all the stuff you did on khtml, now we'll take it from here bub."

</comment><comment><USER27> Looks like Opera is lining itself up for a little acquisition.

<comment><USER28> More like obsoletion by not differentiating and competing against Google's spyware browser chrome. Instead they opt for a weak and lazy approach, it's just a matter of time now.</comment></comment>


The "Evil Bit" Security Flag in the IPv4 Header - <AUTHOR> https://www.ietf.org/rfc/rfc3514.txt <comment><USER2> In case it's not obvious to everyone, this was written as an April Fools' Day prank (note the date on the RFC).

If you liked this one, there are several others:

[https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C...](https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments)</comment>


AMQP for PostgreSQL - <AUTHOR> http://lethargy.org/~jesus/writes/amqp-for-postgresql <comment><USER2> PostgreSQL has always been a feature heavy rdbms, but I read this particular capability as a sign that 2010 is going to be a year where a lot of OS shops are going to start trying out PG. Especially with MySQL's future still up in the air</comment>


F*** You, I Quit – Hiring Is Broken - <AUTHOR> https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-broken-bb8f3a48d324#.2hi5s1kd9 <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=11579757](https://news.ycombinator.com/item?id=11579757).

<comment><USER3> Hmm, I think the title change loses the feeling of frustration.

<comment><USER2> It does do that, but long experience has taught us that HN is better when titles don't vent feelings of frustration.

That doesn't mean that we don't share the feeling. I've felt the same way about tech job interviews for years, and one of my life goals is never to endure one again, at either end.

</comment></comment></comment><comment><USER4> Software developers are not dancing monkeys and should not be treated as such.

Do software sales reps get told to "sell me this shampoo" during an interview? Do they have to whiteboard the structure of an e-mail campaign? No. Because it's no indication of whether or not they can identify and build a relationship with a person at an enterprise that has purchasing power.

If you are putting someone through a coding exercise, it should be simply to query the basics - does this person write readable code. Does this person make comments or use logging?

Anything beyond that and you are looking for good candidates to fail, especially if you are trying to make them do it on the spot in front of an audience.

"Read this file, reverse the strings, and output the results to another file" \- people can go months without reading/writing files in a given language and how many times in your professional life did you ever have to reverse a string?

"Explain the difference between a quick sort and a merge sort?" Who cares except when you are reviewing existing code and you look it up to see if there's an optimization to be made for your particular use case?

Being a good software developer takes a lot more than can be determined from a white boarding or code writing exercise. It takes good critical thinking. It takes the ability to work on a detail item while maintaining a view of the big picture pragmatically. It takes the ability to teach and communicate across technical boundaries. It takes the ability to identify, estimate LOE of, and prioritize tasks. It takes so much more than you can glean from an exercise flawed at the outset.

Look at the code bases for just about any existing software project public or private and you'll see code that was written by someone who would have done things differently if given a chance. Even when given autonomy over a project and an endless timeline we don't do things perfectly. Why should anybody be expected to write something perfect during an interview?

Developer interviews should be friendly and curious. You have to get along with the new hire, and that developer will have to succeed in your environment. Find the best person who meets those two basic requirements and who knows about the specific area where your existing shortcomings are, and you have a winner.

<comment><USER5> I do agree with you on all the rest of the points, but just to say I started out in software and IT sales (but now much happier in a very different field) and I have absolutely been asked to both sell interviewers pens and random products and to have lots of imaginary phone conversations.

Funnily enough, anywhere that asked me to do that turned out to be a pretty rubbish place to work...

</comment></comment><comment><USER6> Previous discussion is here: [https://news.ycombinator.com/item?id=11579757](https://news.ycombinator.com/item?id=11579757)

</comment><comment><USER7> BFS may not feel very relevant for front end development, but second time the author encountered it in an interview should have been a clue that it's worth learning.

The world is full of not-entirely-relevant systems that you need to master to succeed. Tech interviewing is just another one of them. The good news is that once you know what they're looking for (and yes, there are books) it can be studied in a straightforward way.

Think of it as a standardized test, with all the associated virtues (consistency) and faults (dehumanization).

<comment><USER8> > Think of it as a standardized test, with all the associated virtues > (consistency) and faults (dehumanization).

Except that it's not standardized _at all_.

<comment><USER7> Obviously, your mileage may vary. But at least at large companies (e.g., Google) the CS fundamentals you need to know to pass a coding interview are indeed pretty standard, and well described in books such as "Cracking the Coding Interview".

BFS is absolutely on that list. Yes, I had to relearn it in preparation for my Google interview, but it was something I was ready for when it came up. And I would claim I'm a better software engineer for it -- graph search and data structures are topics that come up in lots of different contexts and for which understanding the basics can indeed make a big impact on your code.

The list of these fundamentals is not that long, and the fact that it exists is a big part of the reason why coding bootcamps have been so successful.

</comment></comment></comment><comment><USER9> So we have all these posts saying how it is so hard to find developers, and half the posts saying hiring is broken.

Maybe the best time to do one of these interviews is right after taking your algorithms final. I think I got 120 on that thing, but I would have a hard time recalling what BFS and DFS did without reviewing it.

<comment><USER10> Seriously? You can't figure out what Depth-First Search and Breadth-First Search do just from hearing their _names_?

<comment><USER10> You're given a starting node in a linked data structure and you want to visit, collect, or search all of the nodes that it can reach, and do so without duplication. If you can solve that problem correctly, you've just used or re- invented one of DFS or BFS, and could come up with the other one after a moment of thought about the order in which you visit the nodes. These are not magic spells that you have to go to Hogwarts to memorize; they're the two obvious approaches to solving a really straight-forward problem statement.

</comment></comment></comment><comment><USER11> I understand the author's frustration but this sounds like sour grapes. Sure, the interview questions that Google, Facebook, Amazon, Microsoft and pretty much every big tech company asks are hard and abstract. But it shouldn't be a surprise. As the author mentions, there's numerous books on programming interview questions. Every software engineer I know will spend a lot of time studying common interview questions like maze solving before interviewing for jobs.

You can argue the process is flawed, but what's the point of applying to these jobs without preparing and just hoping you would get a different outcome? The flip side is that these hard interviews makes programmers that can pass them scarce, which drives up salaries.

</comment><comment><USER12> I dunno... it's frustrating, but really, you can learn some valuable stuff during those few hours.

I have had some interviews that certainly haven't been positive, but they have been instructive or rewarding in some way. Not necessarily even relating to code. It teaches you something about them, the industry, and more importantly, about yourself.

</comment><comment><USER13> the interviewers (software engineers) just make sure that relevant people don't get hired. It's just a job security gimmick I guess.

</comment><comment><USER10> Hiring is broken? The hiring process seems to have worked successfully in this case by preventing a bunch of companies from getting into a bad match.

</comment><comment><USER14> Tell the Interviewer

Quiz != Interview</comment>