235 karma · joined August 16, 2013
Despite a few problems, the library is good. I will certainly use it again.
Edit: I used 2.0.0-RC1.
Because harsh expressions are usually gratuitous. Because blanket assertions are usually wrong. And, because combining both is rude.
(This applies to parts of PG's essay as well!)
For instance, did you really need to say `Whoa whoa slow down' when you began your reply? Did that add value?
It is sad - and disgusting - to see this degree of arrogance in bluntly categorising those who use (or build) PCs (and not Macs) as indulging in bullshit!
I am happy that you have found a useful computer in Mac. At the same time, though, please realise that hundreds of millions of computer users choose otherwise too. And, please do not conclude that they have time for bullshit just because of that!
Sure. However, that is secondary. The sort of mistakes that you mention can be caught during code review or unit testing, completely independently of what the actual user requirement is. This post, evidently, does not involve such a case.
> The code is doing what the programmer intended, even if that is not what the user wanted.
Your perspective appears to be inside-outward. It may be helpful during a performance appraisal, but does the business no good!
Edit: inside-out --> inside-outward.
The frame of reference for determining if something is a bug or not is the requirement specification, not design. If the design incorrectly or inadequately addresses the requirement, that is a bug as well. There isn't much point in rejoicing over the code that correctly implements an incorrect design!
Gratuitous arrogance!
Humans have feelings that are impacted by the tone and the style of the other person's communication.
We have convinced the customer that it is better to get the English version into production first, get market feedback, get some traction, and then proceed with i18n+l10n.
Also, is the implication that the merit of the tool is decided based on your personal liking/disliking for the language it is implemented in? That seems childish! If you are responsible for any decent business, dangerous!
The approach was very similar. The current versions of objects were stored in a set of tables, while old versions were stored in separate tables. In order to reduce bloat, I employed a few fairly simple compression techniques. They were reasonably good. On desktop-class machines with a Pentium processor, 256 MB of RAM and spinning hard disks, searching a million objects completed in single digit seconds.
Later, I added bit-mapped indices with dynamically self-adjusting bucket sizes that were determined based on locally-weighted densities along their respective dimensions. They reduced search time on a million objects to tens of milliseconds, with full history searched.
The obvious downside was that there was no SQL for ad hoc queries! So, a command line shell was provided with Ruby as the language, talking to a C API behind the scenes.
All in all, the system worked and scaled very well.
When it was his turn to speak, he said: ``My staff has written a wonderful script for me to read aloud. You can read it on my Website tomorrow. But now, I shall talk about good R&D, or the lack of it, in India." And he went on to deliver a very inspiring speech.
Great man!
I'm hopeful that Visual Design Group will have polished the UI/UX even better for the phone form factor, by the time the distribution becomes stable.
This generalisation is too broad (as with almost any generalisation).
In any case, I want to mention one interesting experience -- a very large financial portfolio management system that I worked on, over a decade-and-a-half ago.
The system had multiple in-coming tickers, feeding huge amounts of data. The central data structures of the computational pipeline system were immutable. Initially, there was a very haphazard system for determining when a particular piece of data was to be deemed stale. In time, formal definitions were established. However, the software was not amenable to those definitions, since shared data was not `seen' updating instantaneously.
The core was too big to be changed in any non-trivial manner, without risking the entire business.
We ended up introducing an explicit notion of time into every pipeline processor to ameliorate (not entirely solve) the situation.
Every major design decision has its own trade-offs that are specific to the problem on hand. But, those built into the foundations of the system should be made pragmatically, not by adhering to a philosophy!
Trying to keep data immutable introduces scenarios involving stale data, and a new problem to solve. I have seen interesting problems with cache coherence that were quite subtle in their manifestations.
Understanding the system-wide implications of immutable-only data is a non-trivial design task.
I have seen several start ups - invested in a few, contracted for several more - of the nature that you describe.
With the benefit of hindsight, what is there so very laudable (thanks Jane Austen) about a culture that does not have a `real business idea', but `rushes to take some investment money and build something'? When you start without a clue of what sustainable value you can provide, most of your problems are invented problems.
Another thing while we are on this topic: it is exceedingly rarely that a start up really loses out because another beat it by a few weeks. Yet, shoddy work is encouraged or condoned in the name of the necessity to move at `Internet speed'.
The `real business idea's of most start ups offer little incremental or differentiating value. The ratio of successful start ups to the unsuccessful ones speaks volumes!
Could you elaborate that, using a mainstream example, please?
> Also the specs on the parts are kind of spotty. ...
Are you referring to the moving parts of the Internet itself?
> There are layers upon layers of abstraction, and no one knows all of it. No one even knows most of it. In fact, most people don't care about any of it other than a cubic centimeter of their own few layers.
This is an invented problem. Scaling a one-off to work for the masses does not require `layers upon layers of abstraction'. Most of those layers are poor engineering backed by a lot money that is thrown at hardware and code maintenance.
One of the realisations that I had over years of `fixing crises', was that increasing numbers of `start up' programmers produce write-only code. Testing and debugging them is painful and expensive, even in the medium-term. Such code bases demonstrate a clear lack of basic engineering discipline. Nonetheless, such programmers are hailed as heroes, because they managed to cobble up a nice-looking mess in a week or two. Then, enormous amounts of effort are poured into making the mess work tolerably. It also consumes phenomenal time.
`Moon landing' projects cannot countdown and blast-off with a great `UX', and then start figuring out how an inertial navigation system should work, over the next week-end.
So, yes that page that `takes so long to load' is indeed `a miracle in proportions that are indescribable'. Only, in a mostly pathetic way!
KDE and Dolphin send the transfer into the background immediately. You can track the progress in the system tray. Meanwhile, you can begin your next operation.
Read the requirement, elaborate a little more by me in some of the comments, and see how the combinations I had to deal with quickly multiplied to cause high tedium.
Rust + Cargo.
That is one of the conjectures propounded by the Upanishads.
The problem of caste is certainly visible in multiple aspects of Indian life. However, what you say above is no longer true, even at the level of most villages (where the caste systems work stronger).
The issues of automating jobs and the resulting unemployment in a country like India, are both deeper and broader than your characterization of it.
You have, evidently, taken the least-charitable interpretation of GP's post yourself. And, right in the context of a discussion where you were the person to introduce that phrase!
In all cases, though, the devil was certainly in the details! APIs, in particular, can surprise and harass the developers.
There are two points to consider: (a) the principle underlying the hypothesis is sound vs. is not, and (b) the computational model of the hypothesis is deterministic vs. probabilistic. These two have to be considered separately when performing an evaluation/verification.
This is precisely the kind of developer arrogance that I advise against in my sessions. Catering to a segment of population, or otherwise, should be a carefully-considered `business' decision. If you are making them based on your preference for OS X (or whatever) and your laziness to install a VM, you are actively inflicting harm on your business.
It is sad to see such strongly-worded blanket statements. The author generalises his experiences with Java to entire OO. He doesn't, unfortunately, seem to realise that non-Java OO does exist.
Also, several lean Java frameworks exist, without deep class hierarchies and factories of factories.
Finally, OO is one of several possible ways to modularise and scale code and teams. FP is another. As languages like Scala have been demonstrating, it is possible to selectively blend features of both in fruitful ways.
Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.