prunebeads
Yeah, everyone can say: I am a good team player. And every HR can say: Our company provides the best working environment. Hypocrisy on either sides leads nowhere, but it seems like it's still the expected standard.
I think that a linkedin profile can be enough. And if the profile isn't publicly accessible, there might be a good reason: privacy. So why not simply ask? At least it would show that the application is being processed. Or perhaps there's an option somewhere on Linkedin which let a user directly grant access to his profile to people handling job offers when they apply, and you just rant about those not seeing that option.
If you've got both your hands busy, whichever keylock system is on your door is irrelevant. Only a voice activation system would be Ok.
Stealing phones wouldn't be an issue anymore, except for people using trivial passwords, or writing their password on the phone.
I don't program in Go btw.
> Actually, it is. There are very few programs in the world where pipe throughput is not enough.
I am very surprised by this. I always thought that programs made of threads were much faster than groups of processi, which have to communicate through OS channels, rather than a common memory space. Maybe I wasn't considering the fact that interactive programs have a lot of time to spare.
Usually, I expect my interactive programs to be snappy when I ask them something, even if I don't do it often at the CPU timescale. That's the real catch in user interaction.
There are other services that an IDE can provide:
- name completion
- list of variables in current scope
- list of visible types
- access to documentation
- code annotation
All these could be implemented in external tools, but how snappy would the interface be?
The filter paradigm of Unix is great for batch processing, but fails when used interactively, unless processi are lightened to the point of becoming almost like threads within the same process, and with the matching communication speed (inter process communication using pipes isn't really that fast compared to shared memory).
That said, maybe large scale programs are the problem to begin with. With simple, one task focused programs, source code becomes easy to maintain without resorting to the services I listed above. It's not easy to get rid of them though (consider compilers for instance).
There's another couple of issues: syntax highlighting, large scale refactoring (which is not easy either with vi or emacs atm).
However, once you get accustomed to a certain workflow, it becomes difficult to accept something new. Maybe I should give it a shot.
Rob Pike's dream setup "is a computing world where I don't have to carry at least three computers - laptop, tablet, phone, not even counting cameras and iPod and other oddments - around with me in order to function in the modern world. The world should provide me my computing environment and maintain it for me and make it available everywhere. If this were done right, my life would become much simpler and so could yours."
In this situation, there would be public phones, public computers available in sufficient quantity everywhere. Think of the necessary amount of work to install, maintain, and upgrade such a setup. In a capitalist society, there would be different brands providing access to their own solutions, and thus a lot of Blackberry, Apple, or <your favorite carrier> kiosks all over the place.
You could think that with such a scheme, costs would prohibit a rapid evolution of services, as we witness them in current business models. Would we get the iKiosks updated each year with new firmware, or the latest multitouch screens? In comparison, how much money is being poured by individuals in upgrades for their personal stuff? What is the overall cost (i.e. money that could be spent on something else).
There's the real estate issue also. How much space would be consumed by those kiosks, and how much would it cost?
It would be interesting to estimate all the pros and cons of that dream setup, and compare it with our current situation.
In most cases, people indeed want to be reachable, but is it really a good thing? In the long run, does it make the society a better place, and people better people? How can we measure the impact of the cellphone on society?
Regarding the comment inside comment system, if it were possible to have nested comments, it wouldn't be a problem anymore :). Since it's a Symfony convention, one could simply count the number of stars at the beginning of a comment line to know the meta-comment depth level. BTW, I know that you are being sarcastic here.
Anyway, this is beside the original problem. Annotations in comments are a problem, granted, but somewhat limited. It's easier and faster for a parser to look for comments and then annotations in them, rather than parse the whole PHP grammar augmented with annotations. Especially in PHP.
Quite honestly, you're the only one really able to answer your question. If you don't have much to loose, and a lot to gain, you should go for it. Being young means that you can afford to lose a bit of time in that sort of experiment, and that you probably didn't invest a lot in settling where you are. At some point later in your life, unless you are really successful (or if your job allows it), the world will expect you to settle somewhere, because it gets harder and harder to do it as one get older (think savings, relationships, building a family).
You could have pointed out all the things that are done in the C obfuscation code contests, to illustrate your point, but maybe this is silly. Also, you start your point from the spaghetti code hell that C macros let people fall into (I guess you where thinking about #ifdef conditionals), but I don't see how annotations could generate that problem. Imho, your point is flawed.
C macros are useful, and when not misleadingly used, very effective at abstracting things in order to get the important structures apparent. That is what annotations attempt to provide. Regarding PHP annotations, the problem here is that it's difficult and time consuming to parse a PHP script, whereas comments are an easy target. SensioLabs went the easy road, perhaps also in the hope that someday annotations would find their way in PHP, and people would just have to remove the comments around them to be compliant.
In your own post, you give a reason for why you think (and not feel) it is wrong, and that's the right way to do. Icky feelings aren't. Maybe people saying that it feels wrong are crossing a line too?
Some annotations are meant to affect the code, some aren't. Those who do and need to be given as pure comments need to be escaped.
Your friends don't want you to go because of the bounds you have with them, obviously, but I'm sure they'll support you if you choose to go, but remember to keep thoose bounds alive, it's essential.
Search for "french study GMO" on google. Most scientific testings on GMOs aren't done on period long enough to be significant.
A recent submission to HN based on very reliable statistics pointed out that life expectancy in the United States at birth, at age 40, at age 60, at age 65, and even at age 80 has been steadily RISING
This isn't evidence that GMOs are healthy, only that other factors are overriding GMOs effects.
since 1960, so new foodstuffs introduced since then based on GMO science so far don't seem to have net harm for the population in balance with all other social and environmental changes since then.
It doesn't mean that we should let people eat GMOs. Hard drugs (like heroin, cocain, etc) represent a minor cause of death too.
But, anyway, if you're really looking for a good language (something efficient, where you don't have to spend hours to spot a stupid bug), skip the dynamic ones altogether, and go for as much static analysis you can get.
Nowadays, it's not so clear cut price wise, but PHP took a strong advance in term of user base - look at the number of libraries, projects, and jobs (!) available in PHP, vs python or ruby.
The issues that most people focus on however are : portability to the platforms they're concerned about, performances on these platforms, richness of the ecosystem.
Game programmers cannot consider Haskell or OCaml as real alternatives to C++ for these reasons. Yet.
That said, people learning to use these languages become better programmers overall. They get a better sense of how to structure, validate their data, and avoid a lot of pitfalls. Have look at the answer made by a representative of one of the products mentioned by J.Carmack - she goes through some of the reflexes she acquired while using her product, and there's definitely an overlap with the way people code using Haskell or ML. It's not an accident that C++ is moving toward incorporating features from functional languages.
Just for these reasons alone people should learn to code with languages like that.