614 karma · joined February 25, 2009
For those that argue that tags aren't hierarchical filing systems, consider that '/Documents/Theses/TagsVsHierarchies' is the same as tagging 'TagsVsHierarchies' with 'Documents' and 'Theses'. It's turtles all the way down.
If you insist: the absence of a microkernel implementation, regardless of its technical feasibility, means we are all losers of "the kernel battle".
CLOS-like systems can be built on structs with the racket/generic module and Typed Racket makes multimethods trivial.
And user interface widget libraries, which are all about I/O. Even Racket's widget toolkit leverages the superb racket/class encapsulation mechanism.
I understand your sarcasm, but 'good design' is an aesthetic, not a metric.
[edit: on second thoughts, I think I may have over-simplified things. Is 'good design' purely quantifiable?]
http://planet.plt-scheme.org/package-source/krhari/pfds.plt/...
It's a bit mind-bending, but from this simple foundation comes the power to easily create and assimilate ever higher-level abstractions (which is what programming is really all about). Parts of a program can be used as a template for creating other parts as needed. You can assemble these parts and shape the language into something very specific for the problem you are solving.
Other languages come part-way, but don't fully embrace this concept (code=data) because it has a cost: it seems difficult to learn because it requires a change in thinking; it seems difficult to write (and read) because you're directly encoding a data structure and it all looks a bit 'samey'. Where other languages have 'shapes' in their code that give the trained eye an indication of what the code is expressing (such as for...do loops and indentation), lisp code has one shape: a tree [1].
I don't know if I've reached beyond your understanding. I haven't meant to, but the takeaway should be this: lisp programs are self-aware and can operate on themselves because a lisp program is just data like any other. This makes it easy for the interpreter/compiler (hence 'lisp in x lines of code'), but more difficult for the programmer (at first). As with all things, practice and familiarity overcome these initial difficulties. It is worth it.
> Scheme's syntax-case is far more subtle and complicated than any one thing in Lisp.
While syntax-case seems complicated at first because it involves a similar mind-bending to that first time when you learned about lambda, it is my number one power tool that keeps me coming back to scheme (the other being a small 'surface area' that I can keep in my head without having to keep skipping between library documentation and code).
On the plus side, this is a great opportunity for some clever PR spin provided you are savvy enough to out-manoeuvre your competitors. Also, depending whether you are the plucky upstart or the entrenched power in your space, your competitors have just validated your business model and your company's worth.
There's a whole bunch of tools groping awkardly in a single direction here:
1. Give a graph to the computer
2. The computer makes the graph a reality
The problem is in determining whether the dependencies of a node in the graph are satisfied. Make does this by comparing file times. All the other 'graph resolving systems' you mentioned do something different. Obviously the solution is to abstract the dependency test from the graph itself. Then all these systems become pretty much the same.
Why is Apple losing its shine after Steve Jobs?Or you could just be honest and tell them what you're currently earning. They still have to make you an offer, and you're free to reject it. I don't think telling potential employers your current salary is losing 'the hand', or if it is, you have plenty of opportunity during the negotiation of your offer to get it back.
But really, if your potential employer has a simple go/no-go flag on some salary threshold, then you can be sure you don't want to work there--especially because your co-workers there have (like yourself) won a race to the bottom.
Social media use in Indonesia predicts Facebook's decline
QED
Actually, if you're reading the original linked article, you should also be reading Andy's series on V8.
[1] http://wingolog.org/archives/2012/06/27/inside-javascriptcor...
[1] http://en.wikipedia.org/wiki/Portable_Executable#.NET.2C_met...
I myself have neither the grit nor the will to endure what you must have suffered, but I recognise this amazing achievement. As another poster has said, you deserve your $29 a month for your effort. I take my hat off to you sir.
When I hear the phrase 'fire anyone who has architect in their title', here's what I hear in my internal monologue: Yes! Fire all the architects! Front line engineers know what every other development group is doing and can integrate their systems in a pinch! They are also across the application security requirements recently mandated in government regulation and can implement that too! No-one needs company-wide frameworks, because each development unit's home-grown libraries are good enough. Systems design? Pfft, overrated. Just check it in and break things, it's called 'agile'.
I apologise if my internal monologue sounds shrill, but your advice to 'fire all the architects' sounds similar to advice from developers to 'fire all the marketing department'.
edit: I am not an architect, this is not a defensive rant.
Here is their own summary of problems with this approach (from the article):
* Not all users have a suitable email service (requires IMAP to support the
“read it if you feel like it” model).
* Servers tamper with messages as a normal part of existing infrastructure
(especially mailing lists and spam filters).
* Basic IMAP does not provide the full gamut of features required (some mail
servers don't support all IMAP verbs).
* Mail systems may have standard protocols, but individual implementations
may have different performance characteristics.