What new product can they offer? What new ideas do they have? Is there any sign of the originality that was on display 10 years ago?
129 karma · joined December 22, 2014
We would look very closely at a Python 2.8, if it existed.
"The very fact that no sabotage has taken place to date is a disturbing and confirming indication that such action will be taken."
— General John L. DeWitt, head of the U.S. Army’s Western Defense Command
Back in 2007, if you wanted to add some simple visual effects to your CRUD app, then jQuery was like a gift from God. But nowadays, given the complex systems that people are building, jQuery has less to offer. It never had an opinion about managing state, so it leaves the core question of building a large app to other frameworks, and those frameworks have various built-in ways of updating the DOM, so the ease-of-use offered by jQuery is no longer such a noticeable advantage.
But oddly, this doesn't describe HN, because another aspect of the moderation is in favor of blandness, for the sake of avoiding flamewars. In college I was taught that good writing entailed taking strong positions, but the moderation here sometimes sees strong positions as being the same as flaming.
"I am Muslim, born in Massachusetts. I love my faith. Muslims in the US are very scared. Both my mom and wife wear the hijab, so I'm always worried they'll be attacked in the street. Even in the Bay Area it's a concern. Of course I encourage them to continue; it's important not to be affected. A few years ago, my mom and sister were at a farmers' market in Boston, what seems like a liberal setting. A big guy ran up and called them terrorists, started spitting at them. My 60 year old mom and 20 year old sister were really intimidated. My sister cried for the rest of the day. People stood by and watched. I give them the benefit of the doubt; they were taken off guard. We have to be aware of our surroundings and be ready to act. It takes mental preparation, so you don't end up reacting like a deer in the headlights."
I am worried what happens to a diverse country, such as the USA, when it elects a leadership that is vocally anti-immigrant. We are about to find out. All of us need to do what we can to minimize the kind of bigotry that might escalate under anti-immigrant leadership.
For those who want to consider arguments against Java's style of strict typing, 2 things I would recommend include "Agility & Robustness: Clojure spec, by Stuart Halloway":
https://www.youtube.com/watch?v=VNTQ-M_uSo8
He offers a chart that shows the strengths and weaknesses of strict typing versus unit tests versus the run-time checks offered by Spec. It's worth a look.
The discussions around gradual typing have been interesting, but to see how far the limits of this can be pushed, I would suggest everyone check out the Qi/Shen programming language:
https://en.wikipedia.org/wiki/Qi_(programming_language)
"Qi makes use of the logical notation of sequent calculus to define types. This type notation, under Qi’s interpretation, is actually a Turing complete language in its own right. This notation allows Qi to assign extensible type systems to Common Lisp libraries and is thought of as an extremely powerful feature of the language."
This next quote is from someone who has spent a long time experimenting with different Lisps:
"Qi (and its successor Shen) really push the limits of what we might call a Fluchtpunkt Lisp. I suspect it requires a categorization of its own. A few years ago I was looking for a Lisp to dive into and my searching uncovered two extremely interesting options: Clojure and Qi. I eventually went with Clojure, but in the intervening time I’ve managed to spend quality time with Qi and I love what I’ve seen so far. Qi’s confluence of features, including an optional type system (actually, its type system might be more accurately classified as “skinnable”), pattern matching, and an embedded logic engine based on Prolog, make it a very compelling choice indeed."
http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/
Mark Taver, who created Shen, posted a comment and then turned it into an essay here:
"The underlined sentence is a compact summary of the reluctance that programmers often feel in migrating to statically typed languages – that they are losing something, a degree of freedom that the writer identifies as hampering creativity. Is this true? I will argue, to a degree – yes. A type checker for a functional language is in essence, an inference engine; that is to say, it is the machine embodiment of some formal system of proof. What we know, and have known since Godel's incompleteness proof [9] [11], is that the human ability to recognise truth transcends our ability to capture it formally. In computing terms our ability to recognise something as correct predates and can transcend our attempt to formalise the logic of our program. Type checkers are not smarter than human programmers, they are simply faster and more reliable, and our willingness to be subjugated to them arises from a motivation to ensure our programs work. That said, not all type checkers are equal. The more rudimentary and limited our formal system, the more we may have to compromise on our natural coding impulses. A powerful type system and inference engine can mitigate the constraints placed on what Racketnoob terms our creativity. At the same time a sophisticated system makes more demands of the programmer in terms of understanding. ...That said, not all type checkers are equal. The more rudimentary and limited our formal system, the more we may have to compromise on our natural coding impulses. A powerful type system and inference engine can mitigate the constraints placed on what Racketnoob terms our creativity. At the same time a sophisticated system makes more demands of the programmer in terms of understanding. The invitation of adding types was thus taken up by myself, and the journey to making this program type secure in Shen emphasises the conclusion in this paragraph"
http://www.shenlanguage.org/library/shenpaper.pdf
I'm only quoting two favorites of mine, but of course I could post a hundred examples, all making a similar point. Java's style of strict typing is both weak and incomplete, and yet overly rigid at the same time. It's worth noting how many other strategies exist, that deliver more robustness, with greater flexibility.
The timeline for economic damage (from global warming) is fairly long. Even in the worst-case scenario, the Earth as we know it is still recognizable for the next 50 years, and all of the seasons and climate patterns remain roughly the same. The major changes will tend to show 50 to a 100 years from now.
Also, I'd like to point out that the increasing acidity of the oceans is a much worse problem, in the long-term, than the warming of the atmosphere. Carbon washes out of the atmosphere, and ends up as acid in the oceans. At current trends, in less than 100 years the oceans will be more acidic than at any point since the Cambrian Revolution. It is not clear that life in the oceans can survive with those levels of acidity (other than organisms that live in volcanic vents and love acid).
https://www.google.com/search?q=Algorithms+Jeff+Erickson+sit...
Part of the "This isn't fun anymore" feeling for me comes from the way the Web has consolidated to a handful of companies (Google, Facebook, Apple, Microsoft...) and what we are being given is what they find profitable.
The loudest voices in the room are those corporations. I'd like to live in a world where the loudest voices shaping our technologies are science fiction writers who are thinking hard about what might actually be useful or fun.
---------------------
"[C]onsider two indistinguishable workers, you and your clone. By definition, you/clone have the same gender, ethnicity, years of schooling, family background, skills, etc. In 2006 you/clone graduated with identical academic records from the same university and obtained identical job offers from Facebook and MySpace. Not knowing any more about the future than the analysts who valued Facebook and MySpace roughly equally in the mid-2000s, you/clone flipped coins to decide which offer to accept: heads – Facebook; tails – MySpace. Clone’s coin came up heads. Yours came up tails. Ten years later, Clone is in the catbird’s seat in the job market — high pay, stock options, a secure future. You struggle. Back to university? Send job search letters to close friends? Ask distant acquaintances to help? The you/clone thought experiment may seem extreme, but recent research that I have conducted with colleagues finds that the earnings of workers with near-clone similarity in attributes diverged so much by the place they worked that rising inequality in pay among employers has become the major factor in the trend rise in inequality. ... The labor market has been dominated by economic forces that pull the wages of firms further apart from each other, motivating our analysis of the role of employers in increasing inequality."
Just so I'm clear, I'm saying I find this interesting because in many cases we are talking about the same people who were alive in 1989. In the USA you can say "Oh, that generation believed in those things, but those currently alive don't believe in these things." (I don't agree with that statement, but you could make that argument.) Whereas in Poland, it's in many cases the same people who fought for a more open system who are now tolerating the drift towards a more authoritarian system.
To me, the story isn't about "overwhelmingly mindless" voters, its about voters who are angry with the failure of the system. That is, they are mindful of how the system has failed. They may not know what the answer is, but they are angry, and they are willing to elect politicians who seem to mirror their anger. It might be a bad strategy to vote for someone simply because they appear to reflect your anger, but I think I can understand the motivation, and it is not quite the same as being mindless.
"ideally they'll have been programming since before college"
Lot's of people get into computer programming as a second career. Rich Hickey, who created the Clojure language, studied music when he was in college. Later, when he was working at a music studio, he got serious about writing code in C++, and from that experience he developed his opinions about the flaws of object oriented programming, and the possible benefits of immutable data.
Your remark says a lot about the hunger for stereotypes in the tech industry. As if everyone is suppose to follow the same path to a career in computer programming.
"Take any behavior seen in all humans, ie. not something that is due to local culture, and place that behaviour in the kind of tribal group that we lived in during most of evolution. Then ask the question 'what would be the consequence of this behaviour?' "
But if the goal is to figure out why things actually are the way they are, rigorous agent based modeling would be a much better way to proceed.
Also, all notions of human happiness were also shaped by human evolution, so the whole essay is nonsense. If evolution shaped our understanding of happiness, then evolution does not, in any simplistic way, explain why me might do things that go against happiness.
We can easily list cool stuff that happened over the last 100 years: radio, television, cell phones, the Internet.
We can easily list bad stuff that happened over the last 100 years: environmental degradation, global warming, the increase in the percentage of income spent on transportation, difficulties in raising children.
What do we get when we subtract the bad stuff from the good stuff? Until we have good metrics for doing that, we are like the CFO who confuses gross revenue with net profit.
Your point about polio is bizarre, as it was never the dominant factor in childhood mortality. The steepest decline in childhood mortality was during the period from 1850 to 1900.
You are expanding upon my example without explaining it. My point remains: has the standard of living gone up? If people could do productive work at the age of 10, but now they have to wait till they are 25, then what metric do you use to prove that the standard of living has gone up? If you want to argue that leisure has expanded, can you prove that the expansion of leisure is entirely experienced as a positive thing? Are young men happier now that they can't find good paying work till they are in their late 20s, rather than finding such work in their late teens?
It remains true that it was easier to raise children 100 years ago than it is now. Is there a metric that shows this as a decline in the standard of living?
My point is that there is a lot that is left out of these metrics. A simplistic look at median wage and the Consumer Price Index suggests that the male median wage peaked in 1973 and family income peaked in 1999. But if you were to measure those factors that are specific to raising a family, the decline in the standard of living, for families, would show up earlier than 1999.
As to the "half the children died" argument, the steepest part of the decline in childhood death was 1850 to 1900. Of the 16 children my great grandmother gave birth to, 15 lived till at least their 18th birthday.
You are confusing money with wealth (stuff people want). The money would come from the government, which can simply print it.
Take a hypothetical situation where robots cause the total amount of wealth (stuff) created, in one year, to increase by 100%. Now assume the government prints enough money to increase the total amount of money by 100%. In this case, wealth has increased by 100%, and money has increased by 100%, so people's ability to get stuff has increased 100%, with 0% inflation.
In the real world, things never work out so cleanly, but the above offers a simplified model of what could happen.
If you were to also track the social changes that have increased the scrutiny on mothers (and parents as a unit), the question would arise if real, meaningful family income actually peaked in 1999. Perhaps it was in decline a long time before that?
I was in kindergarten in 1972. I grew up in an affluent, white neighborhood in the suburbs. At that time, it was thought normal that the children should walk to school on their own. The school was exactly 1 mile away. My parents kissed me goodbye at the door of our house, then I joined up with my friends, and we walked to school. Yes, we were 5 years old.
Any parent who does this nowadays will be arrested, but at the time it seemed safe because everyone did it. I never walked to school alone, I always walked with my classmates. I'm told that Japan is still somewhat like this, but obviously the USA has changed.
But then Facebook went down the same path, first promoting its API, then largely giving up on any attempt to monetize it.
And before that, way back in 2006, I tried to build a business that would rely on Technorati's API, which they briefly promoted, then gave up on.
There are a lot of companies that make money by selling information via an API. And there is tremendous competition for ad dollars. These 2 facts would lead me to expect more companies might try to make money from their APIs. But what happened in Twitter's case?
"A large class of errors are caught, earlier in the development process, closer to the location where they are introduced."
I would re-state this as:
"A large class of errors are introduced, which otherwise would not exist."
Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to endless errors, elsewhere in the code. Given JSON whose structure changes (because you draw from an API which leaves out fields if they don't have data for that field) your only option is to cast to Object, and then you have to guess your way forward, figuring out what the Object might be.
Consider the Salesforce clone of Java, Apex, which I have had to work in this month.
The if() statements here are the same one's that I would have to write in Ruby or Python or PHP, but meanwhile I've had to do a bunch of other, useless work:
public Object deserializeJson(String sandi_data) {
System.debug(sandi_data);
Object objResponse = JSON.deserializeUntyped(sandi_data);
if (objResponse instanceof Map<String, Object>) {
Map<String, Object> mapResponse = (Map<String, Object>)objResponse;
List<Object> dataList = (List<Object>)mapResponse.get('data');
if(dataList == null) {
String err = 'The Sandi API field for data was null';
System.debug(err);
ApexPages.Message msgErr = new ApexPages.Message(ApexPages.Severity.ERROR, err);
ApexPages.addmessage(msgErr);
return null;
} else if (dataList.isEmpty()) {
String err = 'The Sandi API field for data was empty';
System.debug(err);
ApexPages.Message msgErr = new ApexPages.Message(ApexPages.Severity.ERROR, err);
ApexPages.addmessage(msgErr);
return null;
} else {
System.debug('dataList:');
System.debug(dataList);
return dataList;
}
}
return sandi_data;
}
List<Object> dataList = (List<Object>)deserializeJson(sandi_data);
for(Integer i=0; i < dataList.size(); i++) {
Map<String, Object> dataMap = (Map<String, Object>)dataList[i];
System.debug('dataMap:');
System.debug(dataMap);
String response = fetchCompany(dataMap);
SearchResult__c profile = saveProfileResult(response);
cr.add(profile);
}
Again, some of the if() statements need to be made in Ruby or Python or PHP, but the rest of it is just pure bloat. Verbose, unneeded and unhelpful.
In a dynamic language I could simply work with a deeply nested data structure of maps and lists, and I'd handle the casting at the very end of the process. In a dynamic language, I could treat everything as a string till the very end, and then cast to integers or dates or floats or strings as needed. In a dynamic language, I could write the code faster, with less errors, and with less code.
Static typing does not live up to its promises.
[ Edit to add ]
We have no control over the API that we draw from. We are drawing from the API of a different company. I wish they didn't use JSON. If they have to use JSON, I wish they at least enforced a consistent schema. But they don't. And that is why static type checking fails: because the real world is chaotic, and when you have to interact with that real world, you are often forced to do so dynamically, because of the mistakes that other companies have made. The real world is dynamic.
The idea that you can know an external API perfectly is a fantasy. The real world is messy. The real world does not always conform to a strict schema.
The notion that An External API Is Reliable is as stupid as the notion The Network Is Reliable:
https://blog.fogcreek.com/eight-fallacies-of-distributed-com...
[[ Further edit to add ]]
the_af wrote:
"Using dynamic typing will just hide the problems under the rug, and they will explode in your face later on. Static typing just made those problems explicit."
What I wrote was:
"In a dynamic language I could simply work with a deeply nested data structure of maps and lists, and I'd handle the casting at the very end of the process"
I'll simplify this: there are 3 times when we can enforce a schema:
1.) when the API call returns with a string
2.) on every line, scattered through dozens of functions
3.) at the end, when I have the data that I want
In my original comment, I advocated for #3. Here are the reasons I don't like the first 2 options:
#1 - the external API is bloated, so writing a schema for the whole thing would be difficult to justify in terms of business. We only need a tiny slice of the data.
#2 - having casting discovery information scattered through dozens of functions makes the code brittle and refactoring difficult.
With Ruby or Python or PHP or any dynamic language I have the option of #3: grab the data, cast everything as a string, grab the tiny sliver of data I actually need, and then enforce the schema on that tiny sliver. This is the data that I can cast to integers, floats, dates, etc -- whatever is actually needed.
In static-type languages such as Java, I'm forced to go with either #1 or #2, and they are both bad options.
About this, from tigershark:
"it is only the usage of an awful JSON library in a not so nice language"
Bad JSON is part of the real world. If your static-type language can not handle bad JSON, then it can not handle the real world. That is my point: static-type checking is too academic, too pure, for the real world.
As to "not so nice language", you are engaging in the No True Scotsman fallacy, which goes like this: no True statically typed language would be this bad! But following the No True Scotsman illogic, the rest of your unstated assumptions amount to: It's only the statically typed languages that most programmers actually use that are this bad! But somewhere there is a statically-typed language of such unbelievable purity, it overcomes all of these problems!