sashahart

Naming projects without any collisions is really hard to do, unless you like names like 'e31239'.

I was fascinated with Brooks' proposed "head surgeon" solution to the coordination problem for large projects - basically (and forgive me if my summary butchers this a bit), instead of having 1000 programmers on one repo arguing, you have a smaller number of vertically-integrated teams with a "head surgeon" at the top of each, and it is the head surgeons who have to coordinate. (Needless to say, the "head surgeon" has to know how to code pretty well and be significantly involved in the project rather than hovering at 20,000 feet...)

I guess most people would only like to be the "head surgeon" because of the implied status (and not really knowing what it is like to be e.g. Linus Torvalds). But personally, I wouldn't mind doing a specialized job like the tools programmer or language lawyer because these are still interesting jobs allowing good forward progress to be made.

If the load of tedious work like build systems is too much, and the best we can do is either load-balance it across the team or dump it on some schmuck, maybe that just means we should try harder to break up projects into smaller units so that process doesn't completely dominate them.

Fred Brooks wrote about the organizational complexity around larger projects in one of those books many cite but nobody reads, "The Mythical Man-Month." For example, he highlighted time spent on coordination among the n parties required to meet production targets. As you add more people, you might need anything up to n*n lines of communication; in other words, you have possibly an exponential growth in meetings. So he discussed some things IBM had tried, and some possible ways to mitigate that growth in coordination events.

Bear in mind that Brooks was mostly talking about his work on OS/360 at IBM. OS/360 wasn't a doghouse. IBM wasn't a small organization. His interest in reducing meetings wasn't caused by being anti-social, or having some antipathy toward management or PMs. It was caused by an interest in shipping products on time, which programmers are held accountable to do. (Consider that the next time you feel like accusing developers of being anti-social for wanting to get work done.)

Of course Brooks was discussing an idealized version of the problem, aimed at the essentials. But reality includes a lot of kinds of organizational bloat which really aren't necessary to software production goals, they're just hard to avoid in large organizations.

Say you are building a big house, and you can't wait for one person to finish it by herself, so you have to hire and manage and pay n workers and keep the pipelines full; so you need funding up front; long story short, you make a construction company.

Everything you're doing to scale up the organization encourages "leaks."

With more funding, more self-interested contention over where it goes, more fighting over who got it for the company, etc.

With more hiring, more competition among hiring managers to build empires underneath themselves.

With more management structure, more regulation and enforcement to justify and expand the management structure.

With more decisions, more attempts to influence or take credit for those decisions, and endless arguments down to useless bikeshedding. ('what are the right approaches, methods ...')

With more people, more internal social dynamics that become ends in themselves and change how the organization is steered and how resources are allocated in ways that often are actively harmful to the organization's stated goals.

Now relative to these real-world phenomena, does it make sense for software-producing organizations to see their chief risk as letting the programmers who know about code write the requested code as they know best how to do? Or to solve that "problem" with micromanagement, creating more and more barriers and distractions (and morale drains, and reasons to leave) for programmers?

I built a pretty comprehensive database of text editors and IDEs (with a ton of data on each one) and then exposed a subset of that data from this little one-page webapp, in order to help people find a tool worth learning for things like programming or system administration tasks. There's no commercial motive in any of this, it was just something I thought was needed.

What you see is not a curated list, in the sense that it contains a lot of stuff I would never use. But my eyeballs have been on everything in the database, a lot of manual work was involved.

Nor is it a listing of every editor which ever existed (for example, the platforms included are limited, especially I haven't included phone apps or e.g. MS-DOS editors; I don't include websites which purport to be text editors, and I try to avoid linking projects which their authors declared dead, and some which looked to me like possible scams or malware drops). And it doesn't include everything I gathered, just data for which I had reasonable coverage across editors (a lot of things you'd want to know are amazingly hard to find out for more than a few editors).

If you want programmatic access to the data, just use the JSON file, it isn't close to everything I have but it's enough if you find the app isn't giving you the kind of query power you want or something.

It looks like there is a lot of demand for --make/--remove options to vex so I will do those (and that should nearly approach the end of the new features I will do on vex).

Probably good to do some error checking on the arguments to mkvirtualenv and rmvirtualenv (sleepily hitting enter too early, etc.)

You aren't, I do it all the time. But it does get slightly tedious to type out the whole path. (when switching virtualenvs frequently, unlike your use case)

What I use that is analogous to your single virtualenv sourced at shell startup, is pip install --user. I tend to use that for command line tools like style checkers.

I did not know about invewrapper, thanks. pew is another decent name.

edit: after looking at the doc, my impression is that invewrapper seems to follow virtualenvwrapper's design more closely with a large number of subcommands with names similar to virtualenvwrapper's, most of virtualenvwrapper's options and features (except hooks and maybe some of the project stuff). I would describe the options as "comprehensive." I specifically wanted something with a dramatically simpler interface and feature set.

invewrapper also seems primarily or only intended to run a shell. I get personal use out of running arbitrary commands under vex as if it were sudo or something.

It is an improvement not to modify the current environment and couple tightly to specific shells either way, though.

One thing I do envy is the PowerShell prompt ;)

Awesome, thank you for trying this. Please make a github issue or email me if you have any suggestions informed by the experience :)

edit: That one feature reminded me of Kenneth Reitz's autoenv (https://github.com/kennethreitz/autoenv).

I can't do anything to futz with cd, but it could be possible to reverse that and cd to a project directory when a virtualenv is activated, I am just not sure yet mechanically the right way to choose which one. Worth considering.

I do sometimes, more as a matter of muscle memory than volition. I'm going to make a try to use your tool as a replacement for a while and see if I can generate any issues for you :)

However, I still would like to eventually unbreak pydoc for users who might have bad habits like I do.

The issue is that virtualenv itself had an opportunity to fix this (with multiple patches submitted IIRC) and they decided to punt by implementing it as yet another shell function. So for me to unpunt without coupling to the shell, I pretty much have to dump a script into bin/. I guess maybe not that many people use pydoc anyway?

Ah, discovering it from the directory. I considered this in analogy with the way vagrant works.

Yes, there CAN be a way :) but would you do me a favor and write a spec for how you want that to work and jam that in a github issue? https://github.com/sashahart/vex/issues

Fully agreed, and the README for vex suggests this if you are worried about overhead from the wrapper especially for non-interactive purposes where you are repeatedly incurring python startup.

What is truly horrible is that I wrote my shell function, named it ave, thought it was a great name and then months later (edit: after I released vex) realized you had written a package named ave. Oh well.. :)

This is also worth checking out if you just want 'workon' type functionality without the fuss.

This is based on my personal experience with tools for using virtualenv.

virtualenvwrapper is very powerful with all kinds of hooks but I just never used all that power and needed things like speed more. virtualenvwrapper provided a lazy loader but that would have various problems from time to time as you'll see on the issue tracker.

So then for a long time I just ran 'virtualenv' and source wherever/bin/activate and found that I really didn't miss virtualenvwrapper all that much, which was a surprise because everyone finds 'workon' invaluable, a position I do understand.

Later my wife taught herself virtualenv and then wrote like 5 lines of shell to do the same thing as virtualenvwrapper (the classic environment-modifying thing) which I found hilarious, and I wrote a version of that in zsh with a little more error checking to make me happy and just jammed it in my dotfiles. Then after some months of using that I decided this is nice enough to publish so I worked on rewriting it as portable shell functions with more error checking and was going to put it on PyPI.

Toward the end of writing that I was feeling pretty finished, when some last detail that I forget made me hacked off about modifying the current shell environment, so on a lark I wrote a prototype of the new idea of only modifying a spawned process's environment in about an hour (most of which was learning further about portable shell) and once it was working I looked at implementing more error checking for all the weird conditions that may arise in shell and I said, you know what, I have no reason not to do this in Python and totally cut the dependency on which shell is being used, who is going to use this without Python anyway?

Then I ended up figuring out how to do prompts and completion and pretty much had a publishable project, which was surprising.

It's still faster to directly run the virtualenv's Python or to use your own small shell function but while YMMV, for my uses virtualenvwrapper is a lot of code I will never use and I use vex every day.

Highlights of my todos: pydoc still doesn't work (the reasons for this are lame) and probably it will be nice to implement --make/--remove to substitute mkvirtualenv/rmvirtualenv (which would also let me dump a pydoc script in virtualenv's bin/ or Script\ dir to fix that problem...)

I'm curious about 'field helpers,' can you point to a page or briefly describe the difference?

No one wants to be the person who implements an elaborate system for recognizing cat butts.

I think it's more like a descendant of Artillery and a sibling of Scorched Earth and Worms.

And Dawkins was probably an atheist when he was young too. So what?

I have never made a generalized claim about all scientists so you are beating a straw man. I have mentioned a certain pattern which you will see recurring if you have any significant awareness of the famous scientists in a particular field... that pattern is not "getting into politics" but rather "moving well beyond the scientific area where they made their name"

There are many editors which will do the job, it is a matter of taste. If you break your terminal by some obscure action, then fix it rather than choosing your entire toolchain around the premise that you will be spending significant time in a broken terminal.

I appreciate historical respect for the tool but this falls short of showing it to be indispensable to everybody.

I think my underlying point is that it's fine to learn ed, but if the problem is that you are borking your terminal then there are actually ways around that. These days it should almost never happen that you are sitting around tolerating a broken terminal. This is not an efficient use of time. The actual modern use cases for ed are not very common. If you want to learn it just for kicks or because you think it's cool then that is another thing.

Chomsky isn't going to get a lot of power from anything at this point, he hit his stride politically some time ago. If you have read Chomsky's work from early academic stuff up through today, one unifying characteristic is that he is very good at polemics and very apt to it. That style is so much a part of him that it is completely unsurprising that he would use it even on something apparently strange like the invention of email. It's just a long term character trait.

Chomsky is old in the same sense that Dawkins is old and many others are old, namely that they are retired famous scientists who made their name a long time ago and now mostly focus on other topics.

You said he was a linguist. I said that he hasn't done a lot in linguistics for many years now, which is true. I wasn't picking on Chomsky for being political.

Even much of his work in linguistics was polemics - the famous review of Verbal Behavior is pure polemics.

edit: and in interviews Chomsky has said that he felt a lot of this work had an essentially political purpose - talking about some nexus between Continental-style rationalism and opposition to totalitarianism, with which he associated the behaviorists

You don't seem to understand what I said.

Dawkins is another example of the old scientist pattern - many successful and famous scientists do the work they're academically known for early, then shift into topics outside of their original area. It's quite natural.

The link was from fans of Chomsky's and simply illustrates that he has shifted his attention away from linguistics for many decades now. This is not uncommon in science and it isn't some kind of slam on Chomsky.

I don't have to be grateful to Chomsky for expressing his opinion, that's his right. I don't know what the Vietnam war has to do with the invention of email.

edit: nor did I ever say anything to run interference for the Vietnam War. Or Pol Pot, or Hugo Chavez...

Chomsky is being a polemicist, which has always been his greatest skill.

He has been off on politics rather than linguistics for some time now. E.g. check out http://www.chomsky.info/articles.htm (this is a similar pattern to many old scientists)

On many systems you should be able to unbork the terminal with 'reset' or 'tput reset'. Then you do not need ed ;)

There is plentiful demand for 'effective government,' and a total lack of consensus on what it means.

In politics, 'effective' really means 'does what I want.' When there is a lot of conflict about what people want, the government is not 'effective' because (A) deadlock is frustrating and (B) yelling louder is a way to get more and intimidate the opposition.

A government is less like a "singular intelligent self-modifying system" and more like a war on controlled burn.

What is the actual use case for a "self-modifying singular intelligence"? Define the problem you are trying to solve (as an actual task, not nebulous stuff about beliefs) and I reckon you will find more success.

There is a one nice way around the intractable problems of maintaining a huge model of the world: don't. Rodney Brooks' famous saying: "the world is its own best representation." And it isn't necessary or usually even helpful to translate all incoming data into some propositional model. Again: what is your use case? If you are just trying to satisfy some essentialist intuition of what it means to be intelligent and what 'must be' inside minds, then you will be lucky to ever get anything meaningful done.

If you want to write an agent to do something without ongoing guidance, and you have not thought out the task from the beginning to get a specific algorithm, do not start by making a monolithic program that makes lots of vague high-level decisions like "how much reality" based on abstruse constructions of data. Start with the data which is always available, processed minimally, and see how little you can do. Implement walking before you implement steering and implement steering before you implement path-finding.

You are looking for work. While someone should take interest, maybe nobody will take you seriously or find it easy to hire you, because of your age (sorry, I've been there).If you do contract work, be careful to get the agreement in writing.

The key thing for the long term will be to aggressively seek cool internships every year you are in college and (unless you have a better specific idea) get a comp sci degree at some place which is known and has a culture and setting that suits you. That shouldn't be any real problem, if you want to do it.

If this is what you love, there's nothing wrong with doing it at any age. If the job thing doesn't turn up, just take on fun projects using new tools and produce SMALL publishable units. This gives you something to show and more experience with the whole circle of software life.

If you have a lot more time than money, you may be able to engineer your secret project to be able to start on a leaner budget. Don't be too discouraged if things don't work or you screw up.

You have a good start and you have access to advice which I wish I had. Take advantage of it. The beer, LSD and girls will wait. Good luck.