Interesting project! May I ask why you chose ClojureScript over straight Clojure?
My understanding of ClojureScript is that it's Clojure syntax for a simple single threaded environment (probably an oversimplification), but with Golang you have a lot more reach in terms of concurrency.
Please forgive me if I haven't phrased this very well. I certainly don't mean to put a negative spin on this or anything; I'm just curious.
(OP)
I've been maintaining this repository of language Vagrantfiles for a while now, but I'd like to see the number of supported langs and number of active maintainers increase.
I think that one of the most difficult barriers to trying out a new language is the initial setup.
Some sites like golang.org and haskell.org let you play around on the homepage, but it isn't quite the same as having a working local environment.
I've been looking for something that's both useful for me personally to check out the current work available and that works as an employer. I think this is it.
It's incredibly difficult as an employer to convey exactly what the job will involve. Unless you're hiring a direct replacement of somebody you likely won't know what it is they'll be working on. Equally, as a developer, it's easy to see a job spec as a pack of lies, which they often are, and it can be hard to break into a slightly different role. A recruiter's aim is to fill the jobs their clients are paying them to fill and not to advance careers of candidates. I believe this [will] solve the problems in the current recruitment industry from the perspective of both invested parties.
I fully expect this to stir the waters of technical recruitment, so best of luck to you both.
Chris Boardman, an Olympic cyclist for GB, recently appeared on BBC News to talk about cycling safety while not wearing a helmet during his demonstrations.
He gives his reasons in this short video https://www.facebook.com/video.php?v=974497519231053&set=vb....
I certainly don't disagree with him, or with you, that there are plenty of other safety aspects to consider while cycling, but I'd always wear a helmet anyway.
You write your php to a file in the vfs, then you `require` it back out.
There's an example of it in the documentation[1] but a simple example could be:
I don't see why not. It only loads a few objects into memory so the footprint would be tiny, especially when you compare it to running WP.
If you can configure the paths these plugins write to, then you can use VFS. Unless the plugin explicitly uses `file://` or they strip the scheme, but I doubt they would.
On the surface of it, there is no real difference. You can use them both with your usual `fopen` and `file_get_contents` builtins.
I believe that the implementation is truer to the behaviour of how these builtin functions behave with a unix FS. Amongst some other subtleties, here's some examples:
- vfsStream simply ignores handle modifiers (except for +)[1]
- some effort has gone into showing where errors were triggered in userland code[2]
- node types are represented as `fstat` would see them[3] rather than using simple types[4]
vfsStream works perfectly fine, but if you want to use it more with testing file system operations; the closer you are to a true environment the better. Obviously this project isn't quite there yet, but it should be once a few issues have been ironed out.
I absolutely agree with you about applications using their own DI/IOC implementations.
The registry in this library, however, isn't meant to be a registry used outside of the internals of the library. It's an unfortunate side effect of trying to marry up object instances with PHPs static stream wrapper API.
I know PHP isn't the "coolest" of languages around, but I thought I'd just show my project I started a few years ago and never really got around to finishing.
It's been used before as part of a mustache template runtime evaluator and in test suites.
Current issues:
- Test coverage is okay but could definitely be improved (currently ~60%)
- Symlinks
- Proper support for perms/ACL
If anyone's got any feedback or wants to contribute, go ahead.
I'm not really sure what point you're making with these remarks, but it does come across as rather biased.
It is entirely possible that some of these "Adria-Richards-esque thought police" developers, as you call them, weren't very good, but labelling Rowan or the contributors as incompetent is just plain ignorant.
My counter to your comment is that if you want to hire developers who's performance is based entirely on the lines of code shipped, then that's your prerogative. I, on the other hand, prefer to hire developers who can think for themselves, who have the motivation to be creative with their work, and who like to involve themselves in other projects.
My understanding of ClojureScript is that it's Clojure syntax for a simple single threaded environment (probably an oversimplification), but with Golang you have a lot more reach in terms of concurrency.
Please forgive me if I haven't phrased this very well. I certainly don't mean to put a negative spin on this or anything; I'm just curious.