What does it mean, exactly? It’s basically the diminutive form of belligerent. Someone who’s scrappy manages to be both threatening and undignified at the same time. Which seems to me exactly what one would want to be, in any kind of work. If you’re not threatening, you’re probably not doing anything new, and dignity is merely a sort of plaque.
(via pg)
Want something to blow up? Tell the world about it on a Tuesday morning. Avoids the Monday avalanche people face and gives you the rest of the week to get play.
Want something to fade away? Tell the world about it on a Friday afternoon. It’ll fade into the weekend.
Obvious, but had you thought about it?
(via 37signals)
Here is a copy of Joe’s post on r6rs-discuss:
What’s the point of a Scheme standard? I can think of a number of uses. A guideline for new Scheme implementations. A touchstone to distinguish a “real” implementation from a wanna-be. A reference point for academic papers so they don’t need to devote an appendix to describing the semantics of their language. A “weighty tome” that adds gravitas to one’s bookshelf. The reference for nitpicking language lawyers. A wishlist of features that would be nice to have. But I think the most important thing for a Scheme standard to be is this: An agreement between language implementors and programmers that specifies the minimum functionality that an implementor is expected to provide and the maximum functionality that a programmer can assume is available from any system that claims to meet the standard. Naturally, any implementation can provide more functionality than is prescribed, and no one expects any particular program to use all possible functionality.
Additional functionality is the way the language has evolved. The different implementations would add extra features for various reasons. Since these features were developed independently, there were often incompatible. Some of the differences were simply idiosyncratic, others, however, were caused by deliberate decisions about design. When a feature proved its utility, the programmers would put pressure on the implementations to add the feature. When a useful feature was incompatible between different implementations, an effort was made to reconcile the incompatibilities. In the early days, this could be accomplished by getting all the implementors in the same room and letting them argue. This isn’t practical anymore.
The reason I put together my spreadsheet of Scheme implementations was not so that I could argue that any one is better than another. My purpose was altogether different. I wanted to get an idea of what subset of Scheme implementations are likely to affect or be affected by a new standard. Most of these Scheme implementations are at least R5RS compatible, and all of them extend the language in various ways. Some of these extensions are quite common across a large number of implementations.
If every Scheme implementation implemented an extension to the language in the same way with the same semantics, I can hardly there being much opposition to declaring this to be a standard feature. It would be a de-facto standard and it would require zero effort on the part of implementors if it became a de jure standard. On the other hand, if no Scheme implementation implemented a particular extension (say, for example, SRFI-49), there shouldn’t be an enormous outcry if the feature were omitted from the standard. The issue becomes more complicated when a feature is available in only a subset of the implementations.
Let’s take a particular example: SRFI-8 (special form receive for multiple values), is available in 21 implementations. The SRFI is trivially implemented with an R5RS syntax-rules macro. It seems to me that this would be a prime candidate for inclusion in an upcoming standard. It would require very little work on the part of implementors (unless, of course, they did not support multiple values at all or did not have syntax-rules), and the aesthetic issue (introducing a trivial special form) is fairly minor.
SRFI-36, on the other hand, is only available in three implementations. It defines a hierarchy of I/O exceptions. It would be non-trivial to add this to an implementation that had no exception hierarchies, or to one that had incompatible exceptions. It would be a poor candidate for inclusion.
What about something like SRFI-23? Here’s where things get tricky. There are only seventeen implementations that support SRFI-23, but included in those seventeen are PLT Scheme, MIT Scheme, Gambit, Gauche, Chicken, SCM, SISC, and Scheme48. It’s not universal, but it is very widespread. Or what about SRFI-48? It is available in Larceny, Scheme48, partly in Kawa, STKlos, PLT Scheme, Iron Scheme, and S7. If you use MIT Scheme, Gambit, Gauche, Chicken, SCM or SISC, you’re out of luck.
The tiers that I had published previously were not there because of my preferences. They were there as a rough guide to determine how much support is needed or given for a particular feature set. Your new special form may be the niftiest hack since McCarthy’s amb, but if you can’t get buy-in from PLT, MIT, Gauche, Guile, Gambit, Chicken, Scheme48, and SCM, it just cannot be called a standard. Alternatively, if the “Top Ten” buy into your ideas (whatever the “Top Ten” might be), then it will probably be one of the less supported implementations that will have to admit that they do not adhere to the standard.
So which Schemes are the leaders of the pack?
A few days ago my friend and I were talking about the software development market and how as you pass multiples of 10 years of age you tend to face “new concerns” at work. For example, when you turn 30 you get promoted to lead developer, when you turn 40 you get promoted to manager, when you turn 50 you get to keep your job, and when you turn 60 you are asked to leave. This might be a regional occurrence; but it can’t really be that uncommon (Note: I am not in this situation, which I believe to be an exception to the norm).
In every case, said developer is always competing for his own job. What does it take to keep it? How many years does it take to be a good [insert language here] developer. Say it takes 4 years to get “good enough” at Java; what do you have up on a recent college grad with 4 years experience who is willing to work twice as hard for half the prices as you? Think about it from an employer’s perspective; what is the dollar amount that they would place on experience? The answer to that question largely depends on the employer and potential employee, and in particular the former’s needs and the latter’s negotiation skills.
Whatever the case, isn’t there a question lurking at the back of their mind as they read the resume of a developer with 12 years of Java experience, a question something like “If it takes 4 years to get really good at Java, what did you do with the other 8 years?”. While the 4 year number is totally arbitrary and there is a lot more that goes into being a good developer than just programming; I have wondered things like this about both myself and other developers. In that amount of time you could easily attain a degree in some related, interesting field that would add a lot to your repertoire of expertise.
Without too much effort; one could earn a masters degree by attending night school for about 4 years. That is only one class per semester. In retrospect, I could have earned a masters in English Literature two times over by now, yet I have not. Who does this though? It is not considered to be normal; or maybe I am hanging out with the wrong crowd?
Perhaps it is too expensive to justify in terms of dollars or time? I guess I am just left wondering, what have I really been learning? Has it been of any significance? Has it been challenging and truly beneficial? How many programming languages do I need to learn until I have gotten the 80% that I really need?
How would the world look if we were expected to learn something significantly new every 4-8 years? I think that it would look very, very interesting.
What are you doing with your time? Are you challenging your brain? Are you really learning something new and challenging, or is it just more of the same?
The word ‘want’ is a verb that, when used with an object, indicates their desire or interest in said object. For example “I want dinner”, or “I want to be happy”. In order to achieve that object, one must take some ordered steps. For example if ‘I want dinner’ some logical steps might be to go to the market, buy some vegatables and rice, cook them, and finally eat them. When the steps are anything but trivial, most of us get lazy. The result of the laziness is that when we start to follow the steps we simply say something to the effect of “I don’t want to”. For example “I want to be healthy, but I don’t want to exercise”. It is easy to get try to follow the ‘tough love’ approach on yourself or your friends in cases like this; but that virtually never works. What if, instead, we redefined ‘want’ to indicate not only the objects that we wish to attain, but also the means by which we will attain them?
Perhaps in doing so, it would explain to our brains that pleasure can be had not only in the fruits of our effort, but also in our effort alone?
You are not beneath anyone. And there is no task that is beneath you.
— Eddie Dotson
(via latimes)
It might be interesting for groups who promote agile software development practices to start introducing transparency, gently and slowly, simply by including a single number on their web page: the percentage of their projects that are successfully building, and nothing more.
foof explains why here.
the Steampunk genre possess a look of craftsmanship and cobbling. It’s an aesthetic that invites the touch of the human hand and it encourages engagement and foster curiosity and play.
