The issue is the one of random drops for real money. It’s easy to see that has a gambling element to it.
438 karma · joined July 31, 2011
The issue is the one of random drops for real money. It’s easy to see that has a gambling element to it.
I bought some nail scissors from their website a few years ago when hunting around for something better than they sell in Boots in the UK high street - I marvelled at their comparative quality - I even posted to my FB page to recommend them.
I feel sad and wistful also, to see the decline of the company, which seemed inherently artisanal.
More sheet-pressed tat from China, less handmade steel, alas.
It is unhealthy.
That's interesting in as much as it reveals her shamelessness, I don't see on what basis you call that "bad writing".
Secondly, article titles are not always chosen by the column author, but by the editorial team - if you don't like an article title - you are sometimes more exact to call it bad editorial.
Carreyou workes for WSJ, Vanity Fair is owned by Conde Nast, and his book is published by Double Day.
I don't see where you see some kind of implied promotional exercise, given all of these corporate entities have distinct, non-overlapping ownership.
I lost my interest in being their customer. They did offer my a 1yr subscription for free, but by then I had wasted hours trying to get a new install to work and had lost my goodwill with the product.
It would seem to me that he aced his interview - he certainly sold the story!
I don't mean to imply sales is unethical btw, I know ethical sales people - but the fact they couldn't filter the prospective candidate on actual skills or knowledge, and only filtered the candidate for fabrication, seems to indicate they are hiring for people of a certain background.
The fact he gamed that is quite impressive, but it also speaks a lot about whatever the hiring criteria is.
A null value means something in that context. I don't see how it means nothing.
If I have a tail-recursive function, I probably do not need null. But if I have a loop which may run 0 or more times, and need to catch the absence of runs, I need to model a None result.
In that instance, the null has semantic meaning. I can use an algebraic type of course, but for the task I am doing, that may not be practical.
Saying that null logically doesn't exist is not true if my context is the Linux kernel. The unqualified statement of such seems to be overly categorical, to me.
I do like your analogy with NoSQL, I think it's an excellent point. Nullability in a JSON document for instance is better modelled with absence - however, with a language which is compile-time type-checked, those absent values may need to be present in materialised classes as nullable values (options if you like) - unless you're dictionaries all the way down like Python.
If one cares to make the analysis, one could say that it's messy encoding of the None of the maybe monad, e.g. at the call site you need to do some reasoning, but it effectively encodes Some / None.
It simply does not communicate anything to me to hear someone say "logically-speaking, there is no such thing as null" - such a statement really does appear to be word games. It has no explanatory power, and it cannot ever be categorically true.
I was hired into one $100m+ greenfield project (silly money by a silly investor) where the novice technical management wanted everything done "perfect" - no room for compromise.
Project failed, and 600 people that were hired over the 18 months were then all fired.
Every piece of data was to be event-sourcing, every data transaction on a global message queue (Kafka), the ultimate pure event sourcing model.
The big expenses with event sourcing are up-front design of protocols, backward compatibility of protocol changes (if you got it wrong), and problematic structuring of coordinated queries (using coordinators.)
Trivial stuff like serialisation starts to become 30%+ of your development cost.
The simplest example we had, for instance, is the creation of a new user on sign up.
But the Authentication module was not the same as the personalisation module.
So we had authentication creation, then personalisation module need to learn about the user and create the personalisation defaults, as a coordinated, distributed query.
All with Kafka. The next thing here is you discover you need RPC and not Pub/Sub. So you end up seeing confused developers bending the architecture out of shape, doing RPC over pub/sub - which looks like a dog's dinner.
My general view of event-sourcing is "do it in the small" for specific problems where you need it.
If you think it's the silver bullet, then please read Fred Brooks again, and stop pushing your golden solution to all things on us all, please.
BTW, you don't need a fancy framework to keep time-versioned histories in a relational database (I realise RDBMS doesn't scale for all systems, but it does for many.) You just need to design your schema well, and preferably, make your writes go through stored procedures which transactionally maintain history and current schemas.
I'm not saying Rust doesn't have it's sweet spot - but I can't see that as a general purpose language. (Likewise Haskell and Scala - that's just my opinion though :))
I can't see Rust competing on similar merits. Swift however (like Kotlin to which it is extremely similar) seem to be in the right sweet spot in terms of languages designed for usability, with a lot of useful f.p. constructs.
People that don’t have jobs working with data, who are not technical or mathematical, aren’t going to know.
I do hope macOS get onboard next year also...
Even though I know all the ins and outs of AWS, I really like this product for simple projects.
(I have no affiliation with Amazon)
I've written a lot of multithreaded C++, I did quite a lot back starting about 1994 for around 10+ years, a lot of middle-tier application code on Windows NT in particular (back in the day when it was all 3-tier architectures - now we'd call them services) - it's totally fine if you know what you are doing.
Work is usually organised in mutex-protected queues, worker threads consume from these queues, results placed a protected data structure, and receivers poll and sleep, waiting for the result.
Other tricks to remember are to establish a hierarchy of mutexes - if you have to take several locks, they must be done in order, and unlocked in reverse order, this should guarantee an absence of deadlocks. A second trick - a way to guarantee locks are released and bugs of non-release of mutexes do not occur, as well as the correct order of releases, is to strictly follow an RAII pattern, where destructors of stack-based lock objects, unlock your mutexes as you exit stack frames.
Of course, in later periods, you started to see formal recognition of these design patterns, in Java and C# libraries which had WorkerPools, Java and it's lock() primitive, but these design patterns were prevalent in my code at the time, because it was the only obvious and simple way to use multi-threading in a conceptually simple manner. KISS...
Nothing particularly hellish about any of it - but I remember it was not a development task for all developers, and without common libraries in the period (this is pre-STL), you had to work a lot of it out for oneself.
I do remember in the period you would get grandiose commentary from some public developers who would proclaim such things as, "it is impossible to have confidence in/write a bug-free threaded program."
I always felt that said more about the developer than multithreading though.
The very subheading "The catastrophic fire that killed at least 80 in London was the inevitable byproduct of an ideology that vilified the poor" is so extravagant, that I felt the best criticism of it was that it was clearly political writing, and not reportage.
The causes of Grenfell, as other commenters note in this article, are complex:
1) dated fire regulations poorly applied
2) some errors in judgement of perceived risk I would posit - just the same as there is lowered perceived risk of ruin in financial bubbles - there has clearly been cognitive errors in the understanding of the risk of this cladding and general understanding of fire risk. For instance, it's the case this cladding has also been widely applied in Australia, and post-Grenfell they are hurrying to take it down. I don't conclude Australia is in the grip of "an ideology that villified the poor" in using this cladding, rather, cognitive errors in the perception of risk have occurred.
3) the council's economic behaviour - they were squeezing costs on refurbishment costs, a cost control exercise was also participated in by the housing body for the building, many of whom are not Tories, and some of which were nominees from the resident's association
Thus, saying it is "the byproduct of an ideology which vilified the poor", and then quoting housing policy of the last 20 years, referencing modern affordability issues (irrelevant to the history of construction and maintenance of Grenfell), throwing in "Cameron", "Thatcher", "New Labour" - all of whom post-date the shoddy and cheap construction of this one-tower-well building - just appears to be the far-left grinding their same-old axes.
Rather than debate the article point by point, which other commenters do, it strikes me that the more interesting observation to make is that the author speaks with an underlying voice. While my comment may appear to be an appeal to ridicule, to me, Stalinists are hopeless to debate, as are most people with fixed ideological positions. McDonnell and Corbyn whom are the only politicians paid respect in this article, whom were very vocal supporters of Chavez and Maduro for tearing down the state, and also have a long history with Stalin.
Thus my entirely reasonable guess they have a rather specific political affiliation.
In retrospect however, I was frustrated with these languages because I was wanting it to be something it wasn't. To my mind, the loss of that feature meant that programs were less expressive - particularly in large codebases - I had to read methods to work out if something was being modified or not.
To complain here about Go lacking immutability and constness features seems to be the same as complaining that it is missing in Python, Ruby or JavaScript. It's a fact that constness isn't a feature of these languages, if you want these features, use a different language.
const std::map<int, int> constMap = { {1,1}, {2,2 } };
Or take a const map copy-constructed from from a non-const map, if you wish.How is this not immutable data, and "only provides a read-only view"?
It is linguistically guaranteed to be non-mutating - const-casts excepted of course.
All languages that are constructing const data types on the fly are putting them in a writeable pages in memory, after all.
It's a non-topic really, compensation for winning an award, it's bizarre he plays it up like this.
There can be budgeting for specific desk profits in the relative bonus pools decided in IT, but bonus makes up a smaller percentage of developer total comp generally unless you are approaching management.
If you are desk dev and hack Excel and Access for the front office that can help your case in regards bonuses, but this isn't true software development of course.
If you look at the serious pieces of infra inside the front offices for pricing and risk however, there are some smart people that have done some good software.
Quite often however those projects are degraded as stewardship of these projects is inconsistent, and long tenure is not always there, so you don't get continuity in terms of engineering talent.
Frequently this is due to the fact that IT is treated as a cost rather than an enabler of profit, and salary increases do not keep pace with the market worth of fulltime employees - leading to job hopping.
For the non-managerial part of the financial developer's career, it is often a better trade to be an independent contractor on a good daily rate with tax breaks, than take the chance upon fluctuating market conditions and bonuses.
As software developer bonuses are not tied to material outcomes like the front office but are generally more qualitatively judged, this leads to insecurity.
The developers that hang around for many years and end up being the stewards of these good systems that slowly rot, are quite often the ones that are incurious about contracting or moving, or have no better options.
We are routinely picking the top few percentile from the best colleges - the banks don't lack talent - but what they lack is management with good engineering discipline, and good projects sometimes turn bad.
For the professional developer who is actually skilled, this provides unbounded opportunities - it is often easier to make a really big impact with relatively little effort by pruning an overrun garden than rebuilding a very large amount of function points from scratch.
Finally, it is incorrect to say that version control systems are not used. Simply not the case.