skysight-inc/HackerNews huggingface dataset:
How do you reconcile that point of view with articles like http://www.nytimes.com/2012/01/29/us/bay-area-technology-pro... (which appeared on Hacker News not too long ago if memory serves)?

Very few companies, particularly those in the Valley, seem interested in hiring older workers. Does that not indicate there is little perceived value in years of experience beyond a certain point (say, 5, as the original article suggests)?
For the sake of context, the original source of that quote is essentially an advertisement for Squeak. It raises some interesting ideas, and Smalltalk is definitely a system to know.

http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeri...

But as an argument for one paradigm vs. another it doesn't really stand up, because the essay takes its own conclusion (that large systems would be easier to maintain if they were more like Squeak) as a major premise. Him being one of the inventors of the platform, I don't think we can just take his word for it. At a minimum, what we'd really want to see is a large successful enterprise system built on Smalltalk to serve as an instructive example. To my knowledge no such system exists, so we can't really take the paper, insightful as it is, as much more than hopeful musing.

That said, the "bind really late" approach has seen a lot of success. Just not quite so pervasively as the "in all aspects" that Kay advocates in the paper. Nowadays, the standard way to build large systems is to build completely independent modules and couple them on fluid interfaces. Text streams in Unix, REST APIs, and even SOAP are clear examples. What we don't see, though, is a whole lot of reason to think that the languages and run-times on which these modules run must also support late binding and hot-swapping of code at the micro scale, or that we're really suffering for lack of it.
Not saying he isn't sincere I'm saying it's a common misunderstanding that the improved refactoring and compiler errors are that valuable, that they alone can support a strong argument for static vs. dynamic.

There are generally very few situations where you have a single method from a single class sprinkled across an entire codebase for a good reason. That always indicates high coupling and design problems. There are even fewer reasons to rename a well designed method. Constant renaming and high-coupling are bad habits that seem to be commonplace when working in strictly static languages and yet they are known to be bad habits even there. At least dynamic languages discourage these anti-patterns. Not to belittle your friend, I found myself falling into these traps constantly when working in C#.

Honestly, what I'm saying is that these problems just are not nearly as significant in say, Ruby, as they are often made out to be by static typing proponents. It's a bit disingenuous to point to these trivialities as reasons why static > dynamic. If it were true then there would be little benefit in dynamic languages. Clearly there is.
Many good editors/IDEs will do this for you fairly reliably. Komodo and Sublime Text both support this for PHP/JS at a minimum, as an example.
The real trick here is that Teller hasn't revealed anything new about the secrets of magic. One of the dirty secrets is that a magician does her best work with a willing audience.

People want to be amazed. All magic requires misdirection, sure, but the audience is usually in a frame of mind that's willing to suspend disbelief for a moment long enough for the magician to exploit it. Think about how a street magician works a group: "Would you like to see a magic trick?"

I know one magician who sets the frame of mind of his audience by doing something so ludicrous it attracts a crowd. He sits outside a fast food joint eating lunch and pulls an amazingly large straw out of the bag. It's more clever than "would you like to see a trick," but the effect is the same.

I've always been amazed how great magicians can take a relatively simple trick, like a forced card (which always offers an audience member a choice, but the card is always predetermined). Magicians do the sleight of hand right in front of a crowd of people, in plain sight, but nobody notices. Because they don't want to notice. They've allowed their minds to wander for a moment, which is why magicians rarely repeat tricks with the same audience and when they do, its usually a variation of the first that combines another trick (Teller's #5).

One of my favorite card tricks is a classic. Select a card and put it back in the middle of the deck. It keeps rising to the top of the deck every time you stick it in the middle. The reality is that you never actually get to put your card in the middle of the deck. You may have selected initially your card, but everything after that is controlled, down to how the magician makes you hold your card when it's handed back to you. My favorite way to start the trick is with a mental magic joke: Tell the subject to think of a card. Then flip over the top card in the deck, which is almost never the card, but would be pretty cool if it was. Then I pull their card out of the deck and begin controlling it through the routine. The whole point is to keep people off balance and to allow them to have what they truly want: entertainment.

Teller's story about the Cub Scouts is funny to me because I've found that children of a certain age (around 8-15 or so) are simply unwilling to get into the mindset.

Books are filled with advice for how to deal with members of the audience who are unwilling. They usually involve some kind of ridicule of the skeptics for the benefit of the rest of the audience (Teller's #2).
Monkey controls robot hand through brain implants
Clearly this guy is a quintessential .NET developer that built crappy e-commerce sites. If that's his thing and what he considers "programming" he deserves to fall by the wayside by 60.

I started out building crappy e-commerce sites in PHP, but I never once considered it "programming" in the way that I wanted to be a programmer. It was an entry point.

On the other side of this argument is my 60-something employer who only gave up Fortran for C when his colleagues locked him in a room with a C manual for days. He is a programmer and the tool he uses doesn't define what he is capable of. He churns out some genius code.
Thank you, that is really constructive! I do agree with you on using ByteStrings everywhere (some laziness on my part). Calling it Data.Map is a typo, I will update it right away!

I was not aware of the benefits of fromListWith, gonna look into it right away.
I'd be careful about finding a "co-founder" half-hazardously. I've experienced a number of partnerships and they more often than not - end badly.

Workload is hard to share even if you have similar skill sets because you'll have different goals. You might be looking to build a company and he might be looking to sell.

Other issues i've dealt with is miscommunication. It's hard to be brutally open and straightforward with a stranger but its absolutely necessary because it always leads to GIANT problems when you're not honest to the point of being offensive.
Wow! it's amazing that a monkey can actually do that.
My guess is that they want to work them hard and pay them less and they know that older guys and gals won't accept those working conditions. They throw quantity and eagerness at problems. Not that younger programmers aren't good (they are) they just have less experience. I fear many younger technologists are abused. I see a lot burn-out. It's sad to see their desire and eagerness die.

Edit: I'll add that I've seen young men (mid 20s) who have the cynicism and bitterness of much older men. That, to me, is sad. It shouldn't be like this.
Correction: Difficulty is not necessarily a property of a problem, but can also be caused by a poor choice of representation.

I agree that modern technology may help provide better representations, but in the case of most of abstract mathematics, I am not convinced it currently does, or even that it can. There is some truth in the statement "a picture lies more than a thousand words"
More realistically, you could probably say that text subsidizes voice...
Exactly, the author seems to think that every programming technology is isolated from all others. To the contrary, there is a huge amount of crossover between technologies even as separated as .NET and Haskell.

He also says that 60-year-olds are less enthusiastic about learning new tech. Granted I'm even less qualified than him to judge how 60-year-olds think, but the way I see it, if a 60-year-old doesn't want to learn (or feels incapable of doing so efficiently) it's because he stopped learning at some point in his life. It's like exercise, a 70-year old who has gone to the gym two days a week for most of their life will be completely capable of exercising like they always have. If a programmer constantly makes an effort to stay on the cutting edge, they'll have no problems staying there no matter what their age.
He's also wrong-headed about the fields he cites as "unchanging". Yes, lawyers still cite Blackstone, but the law is changing all the time nonetheless. Computer programming has similar foundational material (sorting, searching, you name it -- almost nothing in Knuth is "out of date"). Business has changed radically in recent years. Even accountants have to retrain themselves constantly; the Internal Revenue Code changes every single year (sometimes dramatically), rules of accounting change, new requirements like Sarbanes-Oxley come into play.

Sometimes accountants don't get much respect, but I have to admire anyone who can gobble the Internal Revenue Code every year and come up with procedures that (usually) don't get any of their clients fined or jailed and (ideally) don't cause them to go bankrupt.
For the more mathematically inclined, there's a really nice little book, "The Computer as Crucible" by Borwein and Devlin, about experimental math. It makes a really convincing case, that I think couldn't have been made 15 years ago, that computers really have something essential to contribute to mathematics now. I think Borwein has written a number of articles about the same, and Devlin had a column in the AMS Notices about computer math.
I've fallen in love with hybrid systems like Common Lisp. SBCL is dynamically typed, but type inferred and I have the option of adding type declarations to help the compiler out. It's a different way of thinking, you're working on a living system, instead of treating your program as a monolithic block that the compiler has to prove satisfies some static constrain, you work on chunks(functions, classes, etc.) that you compile and test immediately while your program is running, and if you screw up, the system is there to help you figure out what went wrong and fix it, without killing your process. Wetter or not this type of incremental development is better or not for some definition of better, I feel it fits the way I think better. Maybe somebody with a different way of thinking will actually perform worse in such an environment, thats my theory at least. I know I'm faster(and much less annoyed at my compiler) this way.
> Not that different from using Coffescript

It is pretty different from using CoffeeScript. CoffeeScript produces output you wouldn't mind having to work with if you had to switch to JS. PyJamas produces a tangled mess that won't play nice with other JS libraries.

> or the Closure Compiler.

Yeah, don't do that either.
It was an interesting choice of ages. We had a conversation at work about something like this not too long ago. It ended up boiling down to this, "The difference between an engineer with 5 years experience and an engineer with 10 years experience is significantly greater than that between an engineer with 10 years experience and an engineer with 25 years experience."

Since presumably an engineer(or programmer) who is 27 has 5 years experience there is a world of difference between a 27 year old and a 60 year old. Now compare the 60 year old to a 35 year old. The choice would not be so obvious.
I think you'll be hard pressed to find any ISP that doesn't oversell (at least to consumers - business connections are a different issue). In fact, it'd be extremely inefficient to have all that reserved bandwidth when only an extremely small slice is being used at any time, not to mention that the prices would probably go up ten fold or more.

Overselling is not a problem if the ISP manages it well (keeping a decent window to account for expect and some unexpected growth) and don't punish their users if they use what was promised.
Why do you think ad networks can’t survive without targeting? Missing third party cookies doesn’t even mean that all targeting is impossible.
"Make the secret a lot more trouble than the trick seems worth. You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest. My partner, Penn, and I once produced 500 live cockroaches from a top hat on the desk of talk-show host David Letterman. To prepare this took weeks. We hired an entomologist who provided slow-moving, camera-friendly cockroaches (the kind from under your stove don’t hang around for close-ups) and taught us to pick the bugs up without screaming like preadolescent girls. Then we built a secret compartment out of foam-core (one of the few materials cockroaches can’t cling to) and worked out a devious routine for sneaking the compartment into the hat. More trouble than the trick was worth? To you, probably. But not to magicians."

Does anyone else see a strong isomorphism between that and the advice Seth Godin usually gives? It definitely seems like something an entrepreneur or marketer could learn from - like a way to delight people.
It is very easy to say that it would had been a great decision to stay with Apple but who knows what will happen in future. Judging the right path in the past is very much easier than to create the future. Right?
Free iPhone Wallpaper Downlaod
provided free Free Wallpaper Downlaod,iPhone Wallpaper,iPhone 4s Wallpaper,Free Google android Wallpaper Downlaodipod itouch backgrounds on the internet.you can preview wallpaper in virtual iphone if you have installed flashplayer.
http://www.osspace.net/free-wallpaper/iphone-free-wallpaper.html
You've started with a fallacy here. No one is getting paid to push smalltalk. Even if that was the case, my association with a thing, doesn't make my support of it wrong by definition. Smalltalk obviously should be expected to embodies Alan's opinion on this. That it does, should come as no surprise, and one can safely assume he would have the same opinion regardless of having written a language based on it or not.

To be honest it doesn't seem that you are arguing against this concept that strongly, you're just not overly sold on it. I agree it's good to be sceptical, just as I'm sceptical there is all that much value in static typing in most cases. Having used a statically typed language for years, I've personally found the value to be little and the cognitive friction to be high.
Looking for some side work
Me: Web application developer, tons of experience in python, php, NoSQL, devops. Looking to buy my wife a macbook, only about halfway there - unfortunately most of my salary goes into paying off debts from our wedding.

You: Have a project you've been looking to finance, want to get your ideas into the wild. I'm used to quick prototyping of web applications, and can turn your idea into a site you can show off on HN by next weekend :)

Email me at willworkformacbook@gmail.com or leave a comment here! If you'd prefer to hire me for the price of a 13" macbook, i won't complain!
Agreed. But they do embody the strict static typing philosophy which I do acknowledge is clearly a straw man of the authors point of view.
Rails - core extensions - Array
If long term experience had real value in our industry, wouldn't most companies accept that while an older and more experienced person is more "particular" about their work conditions, it is worth the hassle to accommodate them because of the additional value they can bring? But that doesn't seem to happen.

Or, in other words, companies continue to demonstrate they see little value in experience and the author of the article is bang on when talking about the temporal nature of knowledge capital and the absence of prestige in IT.
I don't see how that is related to static typing. With Python for instance, code completion works great using Pydev+Eclipse or Pycharm.
Batey Don Pedro Hotel is located in natural setting on Peninsula de Zapata – one of the most important ecosystems in Cuba and the largest swamp reserve in the Caribbean. Hotel is ideal place for resting, bird watching and fishing. Resembles typical farm house in the area from where you can hire bicycles, go for horse riding and enjoy a meal at the restaurant.
"you're going to be behind the 'cool kids' that spent the last 4-5 years learning every new language that popped up"

Why? 90% of those languages will either fall out of fashion or have very small cult followings. Wouldn't your time be better spent refining your craft with tools you will actually use.
Offical site (requires TOR to be installed):
http://tag3ulp55xczs3pn.onion/cgi-bin/ssi/index.shtml

Webified link (doesn't require TOR):
http://tag3ulp55xczs3pn.onion.to/cgi-bin/ssi/index.shtml
Apple, Proview iPad Trademark Dispute Involves Some Unusual Tactics Experts Say
Healthcare Startups Providing Much-Needed Disruption
Typography Deconstructed
I liked the hackfwd as well.
It has been my experience that when working on a large team using a dynamic language that these issues actually appear quite frequently.
WingIDE (my Python editor of choice) has fantastic support for this, as well as an excellent integrated debugger.
After 10 years of programming almost exclusively in dynamic languages I'm very much enjoying the refactoring abilities of modern IDEs when I'm doing native mobile development. I rarely have to change a method across an entire code base, but the ability to rename a method or package name in half a dozen files with a single key press is indisputably not only a productivity boost but an encouragement to more extensive refactoring.

More generally, the ability of modern IDEs to manipulate code structurally, and not just texturally, has been eye opening for me.
I recently learned enough Standard ML to be dangerous, and I gained enough of an appreciation of ML-style static / type inferred languages to see where the author is coming from. I even agree to some level.

But, in practice, some dynamic languages just don't seem to suffer from hidden type bugs. One of those is Clojure. Instead of packing everything into complicated types, you are mostly working with maps and sequences of maps--just raw data--with higher order functions. There isn't a lot of room for type bugs. Additionally, without any input from the developer, Clojure does some type-inference all on its own. You can enable warn-on-reflection such that the Clojure compiler will tell you anywhere in the code where it's going to have to use reflection to figure out how to invoke a Java method or property on an object. You can fix them with type hints such that you get performance on par with statically typed Java.

Clojure protects you from name typos you might see in other dynamic languages and accidentally clobbering existing variables through the fact that most variables are really not variable at all. You bind a value once in a lexical scope and it can't be mutated. That's more of a benefit of functional languages and lexically scoped languages, than statically typed ones.

It may boil down to a matter of taste, but I don't see the need for fancy refactoring tools like "method extraction" in a language like Clojure. The methods already don't live in classes, so they hardly need to be extracted from them :). If you rename a method in Clojure, the compiler _will_ complain in all the places where you are trying to call a method that no longer exists.
John King Wins Truck Series Race at Daytona
The rookie John King went on to win the Truck Series race by just wrecking the leader by few minutes. Out of the three attempts at a green-white-checkered finish, King turned the leader Johnny Sauter around on the second attempts and won the race at Daytona International Speedway on Friday night
To call linking to a copyrighted work piracy is a stretch.
Are these virus-free?
Hollywood’s Monetization Strategy Relies on Global Internet Access | Bombtune
Very good points. I was initially enamored by the glamor of dynamic typing and to some extent I still like the concept of not having to declare anything. It's like driving on the Autobahn without any speed limitations. However, since I hav en't done large scale software development using dynamic typing, I haven't faced bugs that are mentioned in this article. It takes a lot of discipline to reduce debugging costs in a dynamic typed language and I agree to the author's point that why deal with enforcing such discipline when you can simply use a statically typed language.

+1 to the refactoring example.
The integer overflow bug? It depends on the quality of the test. It makes sense to test with the same types you intend to use in production, and to cover a wide range of values within each type (the array [1,2,3] for example would not be a good test for 64-bit integers.)

And static typing would not necessarily catch this bug anyway. A C++ template or a polymorphic Haskell function would fail in exactly the same way. What is called for here is argument conversion (A C function or java method declared with double arguments would convert its arguments automatically, but no reason you cannot convert explicitly in a dynamic language.)
Note this is from around 1998. And it seems heavily grammar based.

Things might have changed, since the hardware has become more powerful, and some statistical techniques have proven pretty good at Named-Entity recognition.
I would not necessarily expect my client application to invoke these functions automatically. It can be very helpful writing client apps when there is a human making these decisions.

One of the primary benefits of HATEOAS is state management of your resources becomes easier. My client does not need to burden itself with interrogating the state of the resource, knowing available business functions and when they should be invoked, knowing the location of these business functions, etc. This is managed on the server via API and the client can stick to "following the links."

e.g.
"Create Blog Post" is a REL that I have discovered at application root. After invoking this function and creating the post, I receive a 201 with a post resource that looks like below:

PostResource, SomeData, Link -> "/Modify Blog Post", Link -> "/Delete Blog Post", etc.

In the above example, my client application can display the links it is given and as a user I will modify or delete the post by simply selecting these functions. The client app is acting as a state machine for my user, and they are given the option to transition to various states based on the links returned with each response from the API.

There are many other benefits to HATEOAS, of course, one of which is it allows your application/api to grow and change over time (maybe I want to change a non-core URI down the road?)...this can be done without a lot of pain points by leveraging HATEOAS.

TLDR: HATEOAS constrained APIs are meant to provide direction (in the form of links) to consumers. This can lead to lightweight client agents that do not need to worry about application state.
I want the data from my Polar heart rate monitor.