It's Not Orwell, It's Brave New World - <AUTHOR> https://www.theguardian.com/media/2017/feb/02/amusing-ourselves-to-death-neil-postman-trump-orwell-huxley <comment><USER2> >At Forbes, one contributor wrote that the book "may help explain the otherwise inexplicable".

It's only inexplicable if you live in a coastal bubble where everyone thinks the same way you do. It can't be that your values were rejected by people you deride in "flyover country" (and still not by a majority of the country). No, it must be that they've been brainwashed by television!

But somehow the purveyors of this theory have remained untouched by the corrupting influence of mass media.

<comment><USER3> Other than flat panel TV's and cell phones, a lot of people in "middle America" have gotten absolutely shit out of the last 20 - 30 years. Work's more for less and no advancement. The future is ever more uncertain. Healthcare's gone from expensive to unachievable. Illegal immigration has produced considerable downward pressure on lower-end jobs as well as non-wage benefits (illegals have no leverage with respect to benefits, and this places additional pressure on everyone else to give up on them).

My cousin's little old farm town in the middle of Nebraska has become significantly "hispanified." And while many of them are nice enough, a significant fraction are not. Regardless, it has produced a very significant, dramatic local social and cultural shift. Which many remaining voters find quite disruptive.

Republican as well as Democratic "internationalists" turned their backs on these potential voters and with varying forms of rhetoric about "the greater good."

Well, there's only so much personal sacrifice people are going to put up with.

Trump... well, whatever you think about truth and falsehood with respect to him and the people immediately around him (campaign, advisors, talking heads, opportunists, hangers-on... oh, and his family), he gave this demographic a message to vote for.

In the U.S., social cohesion has always been limited and reinforced significantly through force and intimidation rather than cooperation. But, in a politically significant while not / no longer economically and popularly dominant demographic, it wore thin enough to engender this disruption.

The "internationalists" forgot the first rule of politics and of social stability: To take care of your own. Well, they came to mis-identify "their own" in terms of their personal economic benefit as opposed to the polities they formally represented.

Having watched my own little economic sector, tech., get run over by outsourcing and ageism, I have very little sympathy for them nor for the economic friends they thought they were representing.

P.S. I'm no Trump supporter. I'm simply saying, neither am I surprised by what's happened. Except, perhaps, than he actually achieved the Presidency. The Clinton camp and the DNC can hang that one squarely around their necks.

P.P.S. I'm not particularly defending the Trump voter, either. A lot of nastiness and short-sightedness and myopic self-interest in that camp, too. Nonetheless, they are voters -- members of society -- and trying to quietly flush them down the drain was not a particularly astute political strategy.

P.P.P.S. There is also another -- and perhaps the dominant -- side to Trump support: People who believe simply that you get what you deserve. Regardless of circumstances. They are doing ok -- well, even. And that they entirely deserve credit for that. Anyone else? Not their problem. And if the other person's circumstances leave them down and out: Well, they deserve that.

Some of these people: They will take and take. I experienced this personally, this past year, trying to help one of them out of difficult straights. As their circumstances improved -- not insignificantly through considerable dint of effort on my part -- they became less grateful rather than more, and a criticism of others that I thought they were initially beginning to see past, returned in full force.

Direct kindness ultimately had no influence on their perspective _and behavior_ \-- no matter what words and attitudes they used to initially solicit and gain support.

And THIS really scares me, more than a bit. Or divests me somewhat more of my own apparently mistaken ideals.

Some of these people, are simply intractable. There is no compromise with them, no coming to a mutual understanding.

Were the "internationalists" right, simply to try to leave them behind? No -- even if they are intractable, simply ignoring them is short-sighted, in its own fashion.

Anyway, I've glued enough P.S.'s onto this comment that reflects my continuing struggle to find my own way through these set of personalities written wholesale onto our current politics.

<comment><USER4> Thank you for your writeup; it was thoughtful and well-phrased.

</comment></comment></comment><comment><USER5> Isn't this article purely an opinion piece? I don't mind, but if it is, it should be labeled as such and not passed off as investigative journalism. That being said, you could argue that its both or any number of things, for example:

news supression/distortion -> Orwell

class system of superiors/inferiors -> Brave New World

Could even possibly throw Citizen Kane into the mix but that may be a stretch.

<comment> norea-armozel So Brazil minus the ducts?

</comment></comment><comment><USER6> "the average weekly screen time for an American adult – brace yourself; this is not a typo – is 74 hours"

</comment><comment><USER7> Throughout this entire election and transition I've been wondering if Neil Postman's son is going to remind people of his father's warning in "Amusing Ourselves to Death". It's truly surreal that this detailed prediction I read years ago, written two years before I was born, has been playing out in such a spectacularly... real way. There's this feeling you get when you understand what we're in the grips of yet you also observe and experience just how overwhelmingly impossible it is for everyone to confront the same realizations in order for us to course-correct and avoid what increasingly feels like an inevitable disaster.

Neil Postman was both somewhat deterministic in his beliefs about our future and then reluctantly optimistic when pushed. In an interview he jokingly qualified his optimistic statement with "but remember I'm an American which means I'm eternally optimistic". I think he was also very struck with this feeling, that it is all so clear what is happening yet the dance continues and to warn people, to educate, to improve things in a systemic way that'd be sufficient enough in capacity to combat these omnipresent machinations is so overwhelmingly difficult and complex that one feels a bit hopeless.

In that same interview he said "..to the extent that there would be a serious conversation among Americans about these issues I think we could pull through." (Link to end of interview: [https://youtu.be/FRabb6_Gr2Y?t=27m](https://youtu.be/FRabb6_Gr2Y?t=27m))

Because this problem is so complex and deeply-entrenched in so many facets of our existence whatever course-correction can be made will have to be the result of a phenomenon which I'd describe as very much "emergent". And that phenomenon will be an amalgamation of shifts in thought and behavior spanning all facets of culture and society. You could say "organic movement" but I am not even so hopeful as to think one or a few "organic" movements would suffice. I believe the shift would have to be systemic but also cultural, only a shift in our beliefs- in what our culture deems valuable would provide enough motivation to re-center ourselves around a new definition of civic duty.

Ever since I wanted to be a web developer my dream was to start a successful startup that would allow me to then fund the development of a web technology, likely a platform of some sort, that would help solve some of these bewilderingly complex problems primarily rooted in education. I am always trying to think of how a web technology could fit into the puzzle.

However, if a the American people do not start a discussion about this problem (not one facet of the problem like "fake news" but an acknowledgement of it's deeply-entrenched, multi-faceted nature) than we cannot give it a name and fight it. We cannot begin to plan solutions if we do not first have most people on board which the fact that the problem exists in the first place.

If you've read this far maybe you too are interested in this problem and maybe a couple web developers slowly ideating and iterating over time could be a valuable contribution? Feel free to hit me up: james.checks.his.email at gmail dot com.

*edited to add link to interview.</comment>


In EU, 1 in 8 deaths linked to pollution - <AUTHOR> https://phys.org/news/2020-09-eu-deaths-linked-pollution.html <comment><USER2> Awful article. But anyway...

> In EU, 1 in 8 deaths linked to pollution

This claim based on a single quote in this paper, neither linked nor cited to the direct section

[https://www.eea.europa.eu/publications/healthy- environment-h...](https://www.eea.europa.eu/publications/healthy-environment- healthy-lives)

The article derives the headline statistic from this quote which is infact from another document:

> We are exposed to pollution in our homes, in our workplaces, in the outdoor > environment and when we eat, play, sleep, drive, walk, swim or run. In 2012, > 13 % of all deaths in the EU were attributable to the environment (WHO, > 2016a).

WHO, 2016a being this: [https://www.who.int/news-room/detail/15-03-2016-an- estimated...](https://www.who.int/news-room/detail/15-03-2016-an- estimated-12-6-million-deaths-each-year-are-attributable-to-unhealthy- environments)

The nature of the deaths at the top of the list they cite as wholly explicable by environmental factors is

        -Stroke – 2.5 million deaths annually

        -Ischaemic heart disease – 2.3 million deaths annually

        -Unintentional injuries (such as road traffic deaths) – 1.7 million deaths annually

        -Cancers – 1.7 million deaths annually

        -Chronic respiratory diseases – 1.4 million deaths annually

Which are infact almost largely related to lifestyle and obesity more so than anything else, with obvious exceptions.

This is just another pamphlet of spurious correlations designed to push policy in a certain direction with no regard for science or reality.</comment>


What Killed Smalltalk? - <AUTHOR> http://pointersgonewild.com/2015/08/20/what-killed-smalltalk/ <comment> david-given Smalltalk is a lovely, lovely language. It's _fantastically_ simple --- it's got about four syntactic elements: you can call methods, you can declare and assign variables, you can create closures (called blocks in the Smalltalk world), and you can return from methods. That's about it. There's no control flow --- you do that through passing blocks into methods. You can learn the entire language in five minutes.

Of course, learning the _library_ is another matter. But it's always depressed me that nearly forty years later, our high-tech and ultrafast dynamic languages still cannot hold a candle to Smalltalk for clarity, simplicity and usability.

(And the way that every time they invent a new feature, chances are Smalltalk had it in 1980. Better.)

<comment><USER2> I'm intrigued. Can you point to a book or guide that expands this further, is beginner friendly and not 300 pages? Thanks!

<comment> david-given Amber has a really nice interactive tutorial:

[http://amber-lang.net/learn.html](http://amber-lang.net/learn.html)

It's actually running in your browser, and the whole thing is a live coding environment in disguise. Well worth a play.

<comment><USER3> First thing I get when clicking "DoIt" in Chrome or Firefox is "Parse error on line 1 column 47 : Unexpected character null".

Edit: turns out, I should've looked more closely. You're supposed to select particular text before pressing the button. If you do this it works. Still, they might want to consider a more friendly error message ;)

<comment> david-given I think what it's trying to tell you is that you haven't selected any text inside the edit window. (I agree it's a terrible error message.)

<comment><USER4> Almost as terrible is the fact that the listed keyboard shortcut alternative to clicking DoIt (CTRL d) actually deletes, rather than executes, the selected text.

<comment><USER5> In Chrome, at least, Ctrl+Shift+D works. So might be an implementation detail.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Sigh. Nothing killed Smalltalk. It's not dead. Neither is Scheme. Yeah, both of those languages have pretty small communities, but that's viable in the Internet Age.

Heck, even Self, which nobody ever used for actual shipping software (as far as I know), still has some life in it. The latest release was last year and runs on Linux, Mac OS X. (What, no Solaris support?) [http://blog.selflanguage.org/2014/01/12/self- mallard-4-5-0-r...](http://blog.selflanguage.org/2014/01/12/self- mallard-4-5-0-released/)

Compared to Self, Smalltalk and Scheme are downright mainstream, and used in all sorts of production software.

This is important if you're planning on inventing a new programming language. The chances that you create the next Javascript or Java are slim to none. Those languages are platforms that are backed by large companies. Languages invented by enthusiastic geeks can succeed, but they don't take over the world. Even when success does come, it's after decades as niche languages with tiny communities.

If you consider Smalltalk and Scheme dead, be prepared to have your language be stillborn.

<comment><USER7> > Languages invented by enthusiastic geeks can succeed, but they don't take > over the world.

Ruby, Python, and Lua are all obvious counter-examples to the idea that enthusiastic geeks cannot create languages that are many orders of magnitude more successful than SmalllTalk and Scheme. Even CoffeeScript, if you can call it a complete language, is in the realm of that success.

The only language that has come out recently that is successful purely because of the backing of a large company is Swift.

<comment><USER6> Actually, those are the very languages I had in mind. Perl too. Yes, they have many more active developers than Smalltalk. But you know what? I was part of the Ruby community before Rails, and it was tiny. That was after it had been around for 10 years.

So I'll say it again. If you want to create a new language, go for it! But I wouldn't sneer at Smalltalk and Scheme in the process. Those communities are relatively small, but they're still huge compared to your brand-new language, and they will be for decades. And if you judge language success by innovation and influence rather than developers... well, you have even bigger shoes to fill.

<comment><USER8> > _Actually, those are the very languages I had in mind. Perl too. Yes, they > have many more active developers than Smalltalk. But you know what? I was > part of the Ruby community before Rails, and it was tiny. That was after it > had been around for 10 years._

So? Languages might take a while to catch on. Ruby has a huge community and lots of jobs now. And Python has had that even without something like Rails to dominate adoption. Perl was also huge back in the day.

As a counterexample Dart is nowhere near even Ruby pre-Rails was, even though it's from a major vendor.

And of course C, C++ etc didn't succeed because they had the backing of a major vendor, like Java or C# did.

<comment><USER9> > And of course C, C++ etc didn't succeed because they had the backing of a > major vendor, like Java or C# did

C - AT&T, UNIX vendors

C++ - Almost all C compiler vendors adopted it. CORBA and Windows Development helped it.

<comment><USER8> Having support from third party vendors is not the same as succeeding because you have the backing of a major vendor (and especially one who created you), like Java or C# or Swift.

<comment><USER9> C would have been a footnote in the history of programming languages if AT&T didn't offered the code to a few universities, whose students created the UNIX workstations like in Sun's case.

In the late 80's the language had zero value in the hobbyist world.

The few compilers that existed generated crappy code, were not even K&R compatible and only mattered to those that had access to UNIX either at work or university.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I generally like Uncle Bob, but he isn't a Smalltalker and didn't demonstrate any insight into Smalltalk's unpopularity in that talk.

Worse, this is hardly the first or only time a prominent Rubyist ignorant of Smalltalk has publicly attacked it. Sarah Mei did so in a talk two years ago, mocking it for not having any conferences of its own (ESUG, Pharo Days, and Smalltalks apparently don't count), and she and Steve Klabnik recently had fun tweeting anti-Smalltalk quips back-and-forth.

Given that most of the non-awful stuff (where "awful" means, for example, syntax too complicated to be described by a CF grammar or horrible performance) they like about Ruby was lifted directly from Smalltalk, you'd expect Rubyists to be extremely deferential and respectful towards Smalltalk and Smalltalkers, but they aren't. Instead they're arrogant and condescending despite being ignorant, validating all of the well-earned stereotypes of Rubyists.

As for why Smalltalk "died" (cf. pharo.org) I would say it was too expensive, both in licensing terms and hardware costs. You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk. Some vendors would charge (and still charge) a percentage of your revenue forever, which is insane. Then Java came along, and it was free.

Smalltalk also missed out on the open source revolution, not having viable libre implementations (Pharo, GNU) until relatively recently.

<comment><USER11> I suspect it was performance, cruft, and aesthetics that killed it more than price. After all, expensive things that get popular generally become cheaper (or have cheaper versions released).

My experience with SmallTalk was that by the time it had any chance of uptake it was already knee-deep in cruft (e.g. multiple overlapping visual class hierarchies that would be mixed and matched within projects to devastatingly awful effect).

In my experience (admittedly mostly dealing with IBM and IBM-sanctioned vendors) a typical Smalltalk demo was a program that ran 10x slower than VB on a computer with twice as much memory (and at least as good a CPU) as anyone other than a Smalltalk coder had.

And Smalltalk programs tended to look awful and not be easily fixed (because of the overlapping cruft issue).

I'm pretty sure that Rubyists are no more ignorant of Smalltalk than Smalltalkers are of Simula.

<comment><USER10> > I suspect it was performance, cruft, and aesthetics that killed it more than > price. After all, expensive things that get popular generally become cheaper > (or have cheaper versions released).

I think performance was a huge problem (I did mention it in passing). But you have to remember that just getting your hands on Smalltalk was difficult back then. There were no free versions, and the commercial versions were expensive. At least with Unix, most university workstations in the 80s had a copy, unlike VMS. The result: a proliferation of free Unix-like OSes while the less accessible VMS slowly fades into obscurity.

> I'm pretty sure that Rubyists are no more ignorant of Smalltalk than > Smalltalkers are of Simula.

I don't understand the analogy. Ruby is an unoriginal Smalltalk knock-off that compromises its purity, simplicity, and dynamicity. Rubyists should therefore express deep admiration for Smalltalk in the same way Smalltalkers do Lisp, but they don't. Simula was an ALGOL-60 derivative that had classes and co- routines; by comparison, Smalltalk was nothing short of revolutionary, yet I've never seen a Smalltalker attack it.

<comment><USER11> Given the most common mention of smalltalk is of it being the first OO language and I seldom see it corrected by people who should know better. At least Rubyiata acknowledge Smalltalk exists.

</comment></comment></comment></comment><comment> vezzy-fnord Given Maxime's background notable background in JIT and optimizing compiler research, I'm quite disappointed that her argument for Smalltalk's failure is the simplistic and routinely thrown around canard of "pragmatism".

Why condemn Smalltalk for its idealistic vision when a lot of functional languages that are so trending are just as idealistic?

(A few notes: there are implementations of Smalltalk these days which do not involve graphical environments. GNU Smalltalk is the most advanced.

The assertion that textual mediums for writing code are always superior over visually enhanced ones isn't an argument so much as a culture war. It's also self-evidently of little weight, as the benefits of having a full-fledged Smalltalk VM are immediately visible.

Furthermore, the idea of Smalltalk as the hermit kingdom that locks you in to its toolset isn't as true anymore like it was in the past. Tools like Monticello can interact reasonably well with the outside world: [https://stackoverflow.com/questions/8244502/version- control-...](https://stackoverflow.com/questions/8244502/version-control-for- smalltalk-seaside))

<comment><USER12> > the benefits of having a full-fledged Smalltalk VM are immediately visible.

I'm not so sure they are. I've personally never been able to wrap my head around how I would use any of the Smalltalk environments I've played with to create and distribute something useful to a real person, entirely due to the _necessity_ of "a full-fledged Smalltalk VM". It seems too all-or-nothing; maybe it would work well as an entire OS, but it doesn't work great at the application level.

<comment><USER13> (stupid question; I know nothing about smalltalk, but:) the necessity for a "fully fledged VM" doesn't seem to have slowed down Java adoption. Could you enlighten me as to how/why I've entirely missed the point please? :)

<comment> david-given The Java VM is like a virtual processor --- it lets you run an ordinary program that's written in Java bytecode.

The Smalltalk VM is like a machine emulator --- it runs a complete Smalltalk _system_ , complete with its own screen, GUI, multiple processes and concurrent programs, IDE, debugger, editor, etc, all mixed together. This typically all runs inside a single window, with its own windowing system.

It's a hangover from the days when Smalltalk would run on the bare metal of a computer --- it was the entire operating system.

<comment><USER14> You seem to have confused the Smalltalk VM with the Smalltalk image.

Most Smalltalk implementations have 4 pieces:

\- VM like the JVM

\- sources file

\- changes file

\- image file

No it does not _" typically all run inside a single window, with its own windowing system"_.

</comment></comment></comment></comment></comment><comment><USER15> How to determine the aliveness/deadness of a language:

1\. Work out what you want to build, and functionalities that you would require. 2\. Do a search for libraries in language X. If success, go to 3 else it is dead for you - look at another language. 3\. Look for adequate documentation and an active, helpful community. If success, go to 4 else it is dead for you - look at another language. 4\. Try building a quick and simple application. If you found it enjoyable and offers something other tools you already know don't, go to 5 else it is dead for you - look at another language. 5\. Build something more substantial. If you still find it enjoyable, go to 6 else it is dead for you - look at another language. 6\. Congratulate yourself that you have discovered an enjoyable and useful tool. And that you took the time and effort to explore the language yourself and made an informed decision, and not just read someone's opinion and went with it. You may also start to suspect most opinions are from people who never actually used the language for anything more that what you just did, or inherited a dreadful codebase.

I did all this and I found myself using Pharo about three years ago. I still am, and I enjoy it tremendously. Also, (Pharo) Smalltalk is the most alive language I have ever used.

<comment><USER16> What have you built with Pharo? (Genuine question...)

<comment><USER15> Libraries to access Pin (pin.net.au), Stripe (not yet complete), Twilio (almost complete). My own bindings to SQLite. Libraries to write Latex files. Currently writing web server proxies for accessing Australian government mandated web services. None are yet released, but I am aiming to make a commercial service out of them so they may never be open sourced.

<comment><USER17> Pin employee here, if you've built something that supports us we'd love to add it to our integrations page.

</comment></comment></comment></comment><comment><USER18> So I was interested when someone noted that apparently Pharo/Squeak stumble when it comes to unicode:

[https://www.reddit.com/r/programming/comments/3ha1gu/why_are...](https://www.reddit.com/r/programming/comments/3ha1gu/why_arent_people_using_smalltalk/cu5pf24)

...it seems like that could potentially lead people to be skeptical about an environment/language that is touted as being highly productive, with automated refactoring ease, unit testing, test driven development, and turtles-all-the- way-down, etc.

</comment><comment><USER19> I really enjoyed learning and toying around with Smalltalk and Scheme. What killed it for me was that for all the fun abstractions, they were so isolated in their own environment and disconnected from the operating system that it was not apparent how you would use them for anything real. Processing files, connecting to databases and other network resources, and interacting with the user are core practical services that need to be front and center to get new users to connect to your language, but if those elements are ghettoized into awkward libraries that don't work as elegantly as the abstract parts of the language then you aren't going to get traction, except for very specialized purposes.

</comment><comment><USER20> It always seems like languages that typically are used in an all-encompassing environment are at a disadvantage when it comes to widespread adoption compared to languages that anyone can just start using in their existing OS, with their existing GUI, editor, etc.

<comment><USER21> Visual C++? Or Visual Basic?

<comment><USER22> Are you suggesting those as counterexamples? Neither one is an example of an "all-encompassing environment."

"Visual C++" no longer exists, it's just part of Visual Studio now. When it did exist, it was merely an IDE for regular C++, not any kind of separate environment.

Visual Basic was a package including a GUI toolkit, a programming language, and an IDE for developing ordinary Windows applications. These tools were deployed and used as ordinary Windows applications. There was no separate computing environment with its own windowing system, data storage mechanisms, UI conventions, etc. And the current Visual Basic .NET isn't even that anymore; it's just another .NET language now, where you can swap out the IDE or GUI framework for whatever is available (including none at all if you like, you don't need either one to have a useful VB.NET program).

</comment></comment></comment><comment><USER23> > Not everything has to have a visual metaphor. This is again a case of > pushing some idealistic principle too far, in my opinion.

True.

But, for example, GNU Smalltalk doesn't need GUI?

[https://www.gnu.org/software/smalltalk/manual/html_node/Tuto...](https://www.gnu.org/software/smalltalk/manual/html_node/Tutorial.html)

One maintained Smalltalk implementation with GUI that can be tried:

[http://squeak.org/](http://squeak.org/)

"Squeak is an open-source Smalltalk programming system with fast execution environments for all major platforms. It features the Morphic framework, which promotes low effort graphical, interactive application development and maintenance."

For other opinions about the death of Smalltalk, there was a link to c2 resources called WhyIsSmalltalkDead on the HN just 4 days ago:

[https://news.ycombinator.com/item?id=10071681](https://news.ycombinator.com/item?id=10071681)

What I certainly agree is that the successful language has to be able to interact with as much as possible on the host system, as efficient and as flexible. Note that we still use Fortran code, for example, for numeric libraries

[https://en.wikipedia.org/wiki/LAPACK](https://en.wikipedia.org/wiki/LAPACK)

and that C easily links and calls Fortran routines.

<comment><USER24> You can run squeak in the browser: [http://bertfreudenberg.github.io/SqueakJS/](http://bertfreudenberg.github.io/SqueakJS/)

Another one is [http://pharo.org/](http://pharo.org/) (haven't tried it)

But I've worked with Squeak quite a bit in university, and the consensus generally was: The language is really nice, and a joy to use for many things. The environment is awful and makes working with it a pain, and since everything is integrated so closely there are no obvious ways around that.

</comment></comment><comment><USER25> Also see

Why is Smalltalk Dead?

[https://news.ycombinator.com/item?id=10071681](https://news.ycombinator.com/item?id=10071681)

87 points 5 days ago 61 comments ([http://c2.com/cgi/wiki?WhyIsSmalltalkDead](http://c2.com/cgi/wiki?WhyIsSmalltalkDead))

</comment><comment><USER21> Smalltalk is no more visual or tied to GUIs than C++ is. There's at least one variant, GNU Smalltalk, which doesn't have an IDE. Squeak is a rather nice IDE, though, and makes a good point in the way it blurs the boundary between programming language and operating system. We've had Lisp Machines; I think a Smalltalk machine would be cool.

You can visualize the space of programming languages as having local maxima where, if you modify the language in any way, you make it worse. I think Smalltalk occupies one such local maximum, Prolog another. Others are less clear-cut.

Of course, being good doesn't equate with being popular. Java is a Smalltalk-C hybrid and is very popular. It aimed very well at the average programmer, and hit its target.

<comment><USER26> we had Smalltalk machines. The same hardware which ran Xerox' Lisp Machine OS also ran Smalltalk. The processor microcode was different and it booted into Smalltalk on the metal.

</comment></comment><comment><USER27> Smalltalk's death had almost nothing to do with the language itself. It died for four reasons:

#1 was price, and especially requiring companies to pay royalties on the software they write with your tools,

#2 was the epic mismanagement at ParcPlace/Digitalk (including the merger of the two),

#3 is that Smalltalk was (when the web took off) pretty damn bad for writing server-side Web applications, because of the threading model and blocking IO, and

#4 concerns about security: the lack of high quality libraries for things like encryption, for one thing, and more fundamentally, the way you can do _anything_ once you're in the VM.)

The last one is the only one that's related to the tech itself. If IBM had open-sourced VisualAge when they decided to dump it, it would probably be fairly popular now.

</comment><comment><USER28> The premise that Smalltalk was driven by idealism over pragmatics is suspect. We got GUI's and personal computers and object oriented languages and IDE's because Smalltalk sliced the envelope with it's cutting edge approach. Martin's talk was more than 35 years after the first release of Smalltalk...it's older than C. A discussion about all the problems Uncle Bob avoids by not using C would be both longer and duller...his talk describes why he didn't choose Smalltalk when he replaced the pain that C++ inherited from C...that 20 years after Smalltalk was invented he found a better option funded by Sun, isn't all that surprising.

</comment><comment><USER29> The final comments about Scheme seem like a digression from the thesis. Scheme is almost the antithesis of Smalltalk, in that only an essential core language is provided.

I suppose she's arguing that "good is somewhere between Smalltalk and Scheme" but the closing came across as offtopic, as if she were surprised to find that a language famed for its minimalism was actually minimalist.

</comment><comment><USER30> > _Scheme doesn't include the most basic string routines._

Whoa, really? Racket, arguably the most popular Scheme implementation, seems to have a nice standard library with tons of implemented SRFIs. Also, it seems to be gaining popularity (albeit slowly) not only for itself but for Lisps in general.

<comment> muuh-gnu > Racket, arguably the most popular Scheme implementation

Umm, NO. Racket isnt a "Scheme implementation". Racket was a Scheme as long as they called themselves MzScheme. Then they decided that they changed too much that a complete name change was justified in order to not confuse users.

Racket isnt a "Scheme implementation" for the same reason Scheme isnt a "Lisp implementation".

<comment><USER31> From [http://racket-lang.org/new-name.html](http://racket-lang.org/new- name.html) \-- "Racket is a Scheme". The name change was about very different things than "basic scheme routines", and it would be hard to find any basic scheme implementation without any.

</comment></comment></comment><comment><USER32> I don't like the culture of killing things and saying that things are dead when they still have individuals extracting value from it. I also don't find particularly strong or appealing, the Tyranny of the Majority friendly Argumentum Ad Populum nor the Keynesian Beauty Contests as drivers for design language (actually for nothing in life and not only language design).

On the other hand, I do find interesting that the User Experience gets used on language and frameworks and tooling design.

While Smalltalk never really rocked it at UI and UX, it was good enough to inspire Steve Jobs to do the GUI of a system right (in terms of UX) on the mackintosh.

Regardless of comunity size, I still want to see what's the next thing that will create such degree of positive influence in these days and for the next decadeds.

Good luck

</comment><comment><USER33> While the article raises a few good points, I got distracted by the statements about Scheme at the end of the article. Yes r5rs might be overly minimal, but all real-world scheme implementations contain the usual basic tool functions like string parsing. The performance quoted of a minute for parsing a megabyte sized file can only mean two things: either a defunct scheme was used or the program used contained major flaws - this can happen if you are new to a language, but this is not a useful measure of the language. Even garden- variety byte code interpreters should do this in seconds.

<comment><USER18> My favorite scheme antecdote:

[http://philip.greenspun.com/bboard/q-and-a-fetch- msg?msg_id=...](http://philip.greenspun.com/bboard/q-and-a-fetch- msg?msg_id=0006XQ)

</comment></comment><comment><USER34> Although Smalltalk was early computer language from the 1970s, it could not run efficiently on most computers until the 32bit CPUs came along in the 1990s. By then the simple C language and it's OOP hybrids dominated the coding world.

Smalltalk came on the scene before computer operating systems were well developed as we know them now. Hence Smalltalk did a little bit of everything- code, GUI, OS, IDE. This an advantage in providing an unified API to all these services. However all these services are not as well developed inside Smalltalk as in the layered systems we have now.

<comment><USER35> The Apple Macintosh was released in 1984, Smalltalk ran on it fairly soon after this. The problem was that it wasn't available to the general public, only to universities.

<comment><USER14> Apparently $150 to businesses.

"Apple Team Developing Maclike Smalltalk"

[https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=P...](https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=PA28&dq=digitalk+v/mac&source=bl&ots=Bn3PgQSKCY&sig=lInMZS7XOC7cwGNfB7Cnjigluik&hl=en&sa=X&ved=0CDAQ6AEwA2oVChMIpMHs_JK9xwIViy6ICh2NVgtq#v=onepage&q=digitalk%20v%2Fmac&f=false)

<comment><USER35> Ok. My memory of it was from a bit earlier, I first saw it sometime in 1986. You would have had to add the cost of APDA membership to the $150 stated in your link. I found an OOPSLA conference report that described seeing a demo of the Apple Smalltalk+MacApp product.

I also found a flyer for Smalltalk-80 on the IBM AT for $1000 from around the same date.

<comment><USER14> I very much doubt that Smalltalk-80 was fun to use on a lowly PC-AT ;-)

This was -- USD 199.95 Smalltalk/V286 March 7, 1988.

[https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=P...](https://books.google.com/books?id=CD8EAAAAMBAJ&pg=PA25&lpg=PA25&dq=digitalk+smalltalk+v/286&source=bl&ots=jg- JNM2df5&sig=zCZ6zSeRV1zcLMT_VhaK49_YWkQ&hl=en&sa=X&ved=0CFIQ6AEwB2oVChMIh- Xi5qS9xwIVkCWICh1taQpK#v=onepage&q=digitalk%20smalltalk%20v%2F286&f=false)

<comment><USER35> Smalltalk/V (not 286) was perfectly usable on a PC of the day, I ran it on an Olivetti M24 with a paper white display.

The Smalltalk-80 flyer states that an 8MHz 286 was faster than a Xerox Dolphin and 20% of the speed of a Xerox Dorado. The painful part would have been the display, they were just using EGA (640x350) so you couldn't see much at one time. I saw a demo of this and don't remember thinking that it was too slow.

<comment><USER14> Back-in-the-day I did not consider Smalltalk/V usable, that changed with V286 :-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Wow that Robert Martin talk has not aged well. I couldn't imagine that being a talk at Rails Conf now. Good info, but it feels a bit off 6 years later.

<comment><USER37> What changed in the subsequent 6 years?

</comment></comment><comment><USER38> > For instance, Smalltalk had the ability to suspend running programs into a > saved image, and resume execution later at the saved point.

I'm curious - is this just a continuation? Or is it baked into the language, like exception handling or something? Any smalltalkers want to expound or link to relevant docs/tutorials?

<comment><USER6> Yes, it is a continuation, although it's more comprehensive than call/cc. When you save a Smalltalk image it serializes not only the call stack but the entire heap. It's rather like a core dump that can resume executing.

It's typically implemented in the VM as a primitive function kind of like posix fork(). When it returns, the entire state of the program has been saved to disk. The return value is a boolean, which tells you if you're returning from the original call, or resuming from the saved image.

Classical Smalltalk dialects didn't have continuations as a flow control construct, but they did have reified stack frames, so it was possible to implement Scheme-style continuations in a few lines of code.

</comment></comment><comment><USER39> I programed in Smalltalk-80 from 1990-1995. I used it at Morgan Stanley to build a derivative trading system that was distributed between London and NYC. It was running on networed Sun Sparcstations. Traders would collaborate on the same trading "book" across different machines. One of the big battles of getting the system installed was persuading traders to make room and to use a mouse to control the system.

St-80 was a great system and by way my favorite programming experience. I remember visiting Jim Gosling to hear about Oak (which subsequently became Java) and thinking that it was neat but a pale imitation of Smalltalk.

What "killed" Smalltak were a thousand cuts. A huge problem was the fact that hardware in those days was slow. Our production machines had a 25 Megahertz processor which had problems with the interpreted language that was also painting a GUI.

For a long time St-80 would just take 100% of the puny cpu even when there was nothing going on. Eventually there was 4-line event driven patch that cleared that up but that did not help when the program actually did some work.

For finance double-dispatch arithmetic made things worse since even a simple addition would result in a bunch of message sending that was cute and pure but slow.

The monolithic image was an issue too since shipping and delivering production code was hard. There were source control system but ultimately the image was a hug blob that had to be shipped around. Another issue was the windowing system. Smalltalk was its own universe and basically grew out of being the whole environment for a machine (e.g. Xerox Star).

There were no namespaces so it was hard to segments certain kinds of code and you'd end up fiddling with the innards of St which may have unintended consequences.

It did not integrate with the window managers of the day (e.g. Motif) and could not use native widgets so we had to try to style our widgets to look like the window manager.

I think the folks at ParcPlace were great inventors and engineers (Peter Deutsch is a god) but they were not fast enough to respond to the pressures of the market.

I wonder what would happen if Gigahertz machines were avaible for Smalltalk and if ParcPlace had managed to make their system have a decent package manager and to call native widgets.

It was also hard to find engineers since C/C++ was there flavor de jour. At Morgan Stanley there was also APL/A+/J but ultimately Java took the world over and now then Javascript which started off as an interpreted language with a lot less that St-80 but some times timing is everything. Moore's law helps too.

With all that said St-80 is still the gold standard of my programming life which included other fun systems such as Interlisp-D and NextStep.

<comment><USER14> >>For finance double-dispatch arithmetic made things worse since even a simple addition would result in a bunch of message sending that was cute and pure but slow.<<

Why would there be double-dispatch of 2 + 4 ?

Why would that require numeric coercion ?

</comment></comment><comment><USER40> My personal opinion is what killed most very good languages is the "elite" and "math" aspect of them.

By elite I mean people who thought they were so much superior to everyone else (And they were!), that they'd left the beginners and inexperienced programmers out of the discussions and decisions. But guess what, high level people who make decisions aren't always the best programmers, so C++ won because they had better sales people and were more beginners and sales friendly.

By "Math", I mean that most functional books and tutorials used to only focus on physics or maths aspect of the language, or AI.. whereas the languages who seemed to have won the war (Think Perl, PHP at the time, or Python/Ruby) were much more practical in how the language can be used to solve day-to-day pragmatic problems.

I think it's changing.. and it's really nice to see amazing concepts from LISP in the mainstream/hipsters languages..

<comment><USER8> > _so C++ won because they had better sales people and were more beginners and > sales friendly._

Actually C++ is far worse for beginners than Smalltalk (which is casually used as a teaching language to kids, as Squeek etc).

The comment about "math" and "elite" show no familiarity with Smalltalk or the environment back then.

What you say might be true for Haskell, or even CL, but it doesn't have anything to do with Smalltalk.

</comment></comment><comment><USER41> Languages thrive or die. The successful ones are those enable(d) less capable people at the time to do fashionable works as good as, or even better than the professionals. It has nothing to do with anything other than marketing strategy: find a under served market segment and empower idiots to do mediocre+ works with little efforts. In order to achieve so, language designers have to break old paradigms, simply because if they don't, the less capable people at the time just don't understand, nor capable of (otherwise, they would be professionals).

<comment><USER42> > The successful ones are those enable(d) less capable people at the time to > do fashionable works as good as, or even better than the professionals. It > has nothing to do with anything other than marketing strategy: find a under > served market segment and empower idiots to do mediocre+ works with little > efforts. In order to achieve so, language designers have to break old > paradigms, simply because if they don't, the less capable people at the time > just don't understand, nor capable of (otherwise, they would be > professionals).

Most of the (most) popular languages aren't revolutionary and they're also weak in terms of level of abstraction.

Reading your comment, one would assume that Lisp, batteries included-Schemes, Python, Ruby, Perl, Haskell, etc. are topping the charts. In reality, though, people are mostly using Java, C, C++, C# and yes... Python is very popular. It's outrun completely by languages that require far more work to do less, however.

I don't know if I'm misreading your comment, but the above seems to stand in contrast to your point. The most popular languages are the ones with a lower level of abstraction, less expressive power and that require a programmer to write/manage more to do less, meaning they make more effort for these 'mediocre+' results.

A point can be made that you think less while using these languages, but what time you don't spend on thinking is spent on writing (and then debugging) and I guess this is the 'less capable' part of your post, but this doesn't cover the fact that the languages that've enabled people to leapfrog business professionals (think Ruby + Rails being used to leapfrog professionals in web development) have almost nothing in common with the top list of used programming languages.

The most used programming languages remain and have pretty much always been languages that use C syntax and don't actually push the envelope too much. Some rankings will have PHP and JS up there with the rest of them, but these fall neatly into the fold and are about as 'lame' as the rest of the top (with JS trying to walk lately).

</comment></comment><comment><USER43> _don't perform very well (see CPython, Ruby)_

Sigh. I really wish that smart people would stop spreading myths. Ruby, at least, performs quite well. The "Ruby is slow" days are years behind us.

<comment><USER44> I'm like the biggest Ruby fan out there, but c'mon – that's just not true!

Ruby is great at many things, and it has adequate performance for many situations -'Fast Enough', as DHH said. And with liberal use of C extensions, I've used it in some high-performance scenarios where the expressiveness was more beneficial than the complexity of using extensions.

But it's really not fast – up to 100x slower than Java ([http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...](http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=java)) or 30x slower than Javascript on V8 ([http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...](http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=v8)). I know these are micro benchmarks, but they're useful for comparison.

Some of this is down to the nature of the Ruby interpreter and will improve with time (and with implementations like JRuby). Some of it is down to the highly dynamic nature of the language. The point remains though – if you need high performance for a particular task, Ruby may not be the best option.

<comment><USER45> Ruby isn't that much slower than other slow languages. But compared to the fast ones it is really really slow.

<comment><USER14> There's a chart for that --

[http://benchmarksgame.alioth.debian.org/u64/which- programs-a...](http://benchmarksgame.alioth.debian.org/u64/which-programs-are- fastest.html)

\-- but the question is always _really really slow to do what exactly?_</comment></comment></comment></comment>


Show HN: nooooo.ooo - <AUTHOR> Link: http://nooooo.ooo
Github: https://github.com/aiwebb/nooooo.ooo
This was just a dumb excuse to use the .ooo TLD.
Inspired by the wonderful http://yesno.wtf. <comment><USER2> Noooooooooooo.... I looked at your code and you are using JQuery.... there is NOOOO point for such a simple site.

p.s. I will send a link to my pals when they ask me if I want to go for a beer

<comment><AUTHOR> Yeah, I have a rapid prototyping index.html template that includes jQuery and Lodash. I literally just slapped that in and wrote four lines of code. I know it's completely unnecessary.

</comment></comment><comment><AUTHOR> Shout out to costpermille for the jQuery removal:

[https://github.com/aiwebb/nooooo.ooo/pull/1](https://github.com/aiwebb/nooooo.ooo/pull/1)

</comment><comment><USER3> Why did you use jQuery v1.11.2? How did you decide to go with that version?</comment>


Man builds house, then finds out cable Internet will cost $117k - <AUTHOR> http://arstechnica.com/business/2015/09/man-builds-house-then-finds-out-cable-internet-will-cost-117000/ <comment><USER2> we saw this like 4 months ago, where were you?</comment>


_meta - Info roundup: McAfee kills computers worldwide - <AUTHOR> http://andreyf.tumblr.com/post/538652366/info-roundup-mcafee-kills-computers-worldwide <comment><USER2> If the numbers of computers infected are true (163K for Pricewater House alone), Mcafee could easily lose considerable marketshare overnight.

</comment><comment><USER3> Also posted at:

<http://news.ycombinator.org/item?id=1282791>

<comment><AUTHOR> Sorry about that. Usually when I submit a URL that's already been submitted it just upvotes the existing submission.

I didn't intend to create a new submission, but merely upvote that existing one.</comment></comment>


Etsy sellers say their bank accounts were emptied in major billing snafu - <AUTHOR> https://boingboing.net/2019/02/17/etsy-sellers-say-their-bank-ac.html <comment><USER2> The fact that this happened on a Friday with a Monday holiday coming up smells extremely fishy to me.

Of course this is completely unfounded, but I have a gut feeling its a hack and we will be hearing more about it in the future. Most electronic heists happen at exactly these times because the banks will not reopen until following Tuesday at which time it can potentially be way too late.

One prominent example that I can think off the top of my head is the Bangladesh Bank Robbery [1], but I am sure there are more example to be found

[1] [https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery](https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery)

<comment><USER3> Here's another example

[https://krebsonsecurity.com/2018/07/hackers-breached- virgini...](https://krebsonsecurity.com/2018/07/hackers-breached-virginia- bank-twice-in-eight-months-stole-2-4m/)

>National Bank said the first breach began Saturday, May 28, 2016 and continued through the following Monday. Normally, the bank would be open on a Monday, but that particular Monday was Memorial Day, a federal holiday in the United States. The hackers used hundreds of ATMs across North America to dispense funds from customer accounts. All told, the perpetrators stole more than $569,000 in that incident.

</comment></comment><comment><USER4> Things like this are my problem with the pull style payment systems. It would be nice for online systems if you were given an invoice, and you had to tell your bank to push the money to the other party. (or confirm the pull). For recurring bills that are always under a certain amount, he was a customer can give a business some limited amount they are allowed to pull every month.

In a system where we turn over our payment information to all these companies and they can accidentally pull any kind of money from your account, it just leads to problems.

<comment><USER5> privacy.com allows creating credit cards with preset spending limits, either one-time or recurring. I use it for subscription services. (No affiliation just a happy user.)

<comment><USER6> Apparently Citi offers virtual credit cards to their users, I've been meaning to open an account for this feature alone.

Are there any fees associated with that privacy.com service?

<comment><USER7> Capital One also does but apparently it requires you install a browser extension that you give permission to spy on all webpages.

<comment><USER6> Are you sure that's not just an optional convenience thing?

</comment></comment></comment></comment></comment><comment><USER8> The article is really poorly researched. They mentioned that Etsy decided "not to cancel the transactions". What does that even mean? You can't cancel a transaction where the money has already been taken out or the account and magically expect it to return. Etsy has to push the money back into the account via a refund.

And money refunded is never considered income, so the second part of the article is completely unfounded speculation. Unless Etsy issued 1099s it doesn't matter how much money they push into the account, it doesn't mean it will be considered income.

<comment><USER9> At least with Braintree (which my company uses), you can void a cc transaction any time until it settles at midnight, with the result that the money never actually leaves the account. A preauth of this magnitude could still cause big problems for a day or so, but it'd be better than locking the money away as a credit in a totally different account (which, among other problems, somehow smacks of money laundering).

<comment><USER8> The money moved so it already settled.

<comment><USER9> Yes, by the time they addressed it. Seems hard to imagine this was the sort of thing that didn't hit their radar on the day of, though.

</comment></comment></comment></comment><comment><USER10> This is the kind of mistake that potentially kills the company. Or would if it still would be a small artist umbrella but it's now only a small portion. Because after this, a lot of small artists will pull out for sure because as you very well know 40% of Americans can't cover a $400 emergency expense so they equally can't afford to hand their financial info to a company which might just trigger such an expense. This is a problem. I liked the small artist half of etsy. Where do you get your small artist stuff now?

In a way, Feltsewfantastic's Corgi felt keychain key ring / bag charm / ornament is my support animal... etsy has brought me a lot of joy.

</comment><comment><USER11> I know that there has been a lot of internal handwringing at Etsy over changes in the culture and values of the company over the past few years.

I imagine this will be a good chance to see how much of the old Etsy still remains in the DNA and how much has gone CYA corporate.

Really hope everyone affected gets made whole. Unexpected large withdrawals that persist for days can be extremely stressful, and in some cases, affect lives for a long time afterwards.

\--

(I once had a case where a store charged me a ridiculous amount of times, over 40-50 for the same transaction, and then I was charged tons overdraft fees for every duplicate transaction. The store refunded my money but refused to pay for the overdraft fees, the bank refused to refund the overdraft fees demanding the store would pay, and meanwhile I was a 19 year old out of somewhere near $2000 for months and stonewalled by CorpStore and CorpBank.

(They eventually each agreed to cover half, which was a bit of a coup for the bank I thought)

</comment><comment><USER12> Mistakes happen, even terrible ones. They can be fixed though. The biggest issue is the fact that Etsy is stonewalling the issue and not willing to talk about it openly.

<comment><USER13> I don't think they're stonewalling the issue. They need to figure out what happened, they need to figure out who got affected, they need to figure out how to refund their money, with ACH it's slow. Friday is the worst day, banks are closed Sat, Sun and Mon (Banking holiday, President's day), their customer service lines, emails are probably flooded. Their legal team might have already taken a few calls, their PR department is working as hard as possible, their retention team is also trying hard to keep business. The dev team needs to also find a solution. They need to do all this, and their postmortem report probably needs to be reviewed by legal to reduce any future exposure.

Nothing will make the users happy till their money is refunded and that will not happen till Wednesday. Earliest day they can submit refunds will be Tuesday, it will show up on Wed. Same day ACH is not going into effect till Sep 2020.

<comment><USER14> The whole concept of a bank being "closed" and so you being unable to make a money transfer seems so quaint and last-millennium.

<comment><USER15> Exactly. This is one of the advantages that cryptocurrency has over banks.

The Etsy snafu will be repeated until people and businesses start to require crypto for business transactions.

<comment><USER16> > Exactly. This is one of the advantages that cryptocurrency has over banks.

If it were any sort of _meaningful_ advantage you'd likely see banks adapting pretty rapidly. There's nothing inherently impossible about faster bank transfers - Europe already has 24/7 nearly-instant transfers via SEPA.

> The Etsy snafu will be repeated until people and businesses start to require > crypto for business transactions.

I suspect for every _one_ Etsy snafu there's a _bunch_ of "thank goodness I could issue a chargeback" situations.

</comment></comment></comment></comment></comment><comment><USER17> It's strange how the US just can't seem to figure out sensible payment systems. Payment in the eurozone is not exactly perfect, banks being banks and all that, but this kind of thing is almost a non-problem: If there is a SEPA direct debit drawn from your account that you object you, you simply tell your bank (online banks tend to have the option in the online banking interface for every direct debit transaction) and the amount is immediately credited back to your account, with the same value date as the previous debit. It's then the problem for the payee and their bank to sort out.

<comment><USER13> It's already figured out, USA has the first mover's disadvantage, maintaining compatibility with an older system when you have many users.

<comment><USER18> So what? The SEPA shift was also a compat nightmare - even worse than in the US I'd say. 34 countries with each having their own system of bank and account IDs that all had to be rolled over into one common system, and banks now being allowed only one day of delay (which used to be up to a week for international).

The EEA covers over 500M people, way more than the US does, with way more languages. It's not impossible to do such a migration, the difference is that EU legislators were fed up with the brokenness and _forced_ the migration via regulation while the US government believes that "the market will fix everything". No it will not, the market will only deliver what is the lowest acceptable effort.

</comment></comment></comment><comment><USER19> This is just their billing system, not the way sellers are paid?

I was very active in the Etsy community back when they start planning to implement their own payment system. At the time, I perceived them to have a record of continual incompetence paired with insensitive or hostile customer service. I was very wary, along with friends of mine in the community, of something such as this occurring to me. I certainly have never trusted them with my money.

The response is typical of the vague, downplaying way I remember them handling problems way back in 2008.

"We're aware of a bill payment error affecting a small group of sellers which resulted in some cards being incorrectly charged. We don't expect this error to impact additional sellers going forward."

</comment><comment><USER20> _" People who sell crafts and other goods on Etsy, an e-commerce site focused on handmade and small-batch products, say they woke up to a nasty surprise Friday morning when thousands of dollars were withdrawn from the bank accounts and credit cards sellers are required to have on file in order to have an Etsy storefront."_

Why do sellers have to have credit cards on file?

Buyers I can understand, but sellers?

<comment><USER21> To pay the fees associated with selling.

<comment><USER22> why isn't the fee deducted from the selling price before money are wired from etsy to seller?

<comment><USER23> Traditionally buyers paid via PayPal directly to the seller's account without Etsy seeing the money. This is still a supported option for grandfathered sellers and for sellers in countries where Etsy Payments does not operate, it is called "standalone PayPal".

A couple of months ago, for those sellers that use Etsy Payments, Etsy actually switched to deducting the fees from the sales like you suggest. But that still doesn't cover the cases where buyers want a refund afterwards, or if the seller had no sales to cover the listing fees.

</comment></comment></comment></comment><comment><USER24> Why can't people just prepay a credit on the service, and the service provider could deduce fees from the credit? A lot of other services are doing that. It would solve all kind of associated issues with this these kinds of errors, like cancelled cards, overdraft fees, etc.

<comment><USER25> Why would you lend a company money, interest-free, when you could put it in a savings account, invest it, pay for something else, etc.?

<comment><USER24> Why not? I've decided to spend the money in the next few months on the service already, so the money is allocated anyway. I do it regularly. It also avoids paying the card companies' fees, because I can just wire the money.

A lot of serices are structured this way, anyway. Download services, hosting services, even marketplaces like Etsy. Really, Etsy's model sounds more like an exception from my POV. But I'm not in the US.

</comment></comment></comment><comment><USER26> Exactly why I never connect real bank accounts to Venmo or even paypal. I only trust credit card companies lol. My Venmo is built up from friends sending me when I paid for them in cash.

Also if I were to connect bank accounts, I have several buffer accounts which are low on purpose

</comment><comment> crooked-v Etsy's TOS requires mandatory arbitration, unsurprisingly, but I wonder what their reaction would be to thousands of arbitration claims over overdraft fees and other financial hardships.

</comment><comment><USER27> This seems to be simple theft. Report it as a crime.

<comment><USER28> Mens rea - Latin for "guilty mind" - is the intention to commit a crime, and must be present for many types of prosecutions.

[https://en.wikipedia.org/wiki/Mens_rea](https://en.wikipedia.org/wiki/Mens_rea)

<comment><USER20> I'm interested in how mens rea squares with the oft-cited "ignorance of the law is no excuse" (is there a Latin term for that?).

If you don't know you're breaking a law there can be no mens rea, can there?

<comment><USER29> _Mens rea_ means you intended to do the criminal thing that you did, not necessarily that you knew it was criminal. Homicide is homicide because you intended to kill someone, even if you didn't know that was a crime; if you did not intend to kill someone, you lack the _mens rea_ but may still be guilty of negligent homicide or some related crime.

Certain crimes do require knowledge of the law, like tax evasion: the tax code is assumed to be so complicated that to be guilty of criminal tax evasion it must be proven that you _knew_ you were evading taxes. Wikipedia has a summary: [https://en.wikipedia.org/wiki/Mens_rea#Ignorance_of_the_law_...](https://en.wikipedia.org/wiki/Mens_rea#Ignorance_of_the_law_and_mens_rea)

<comment><USER30> _if you did not intend to kill someone, you lack the mens rea but may still be guilty of negligent homicide_

The standard varies by jurisdiction, but it's quite common for "intended to cause non-lethal injury but accidentally killed the victim" to be treated as murder; this arises for example in the "eggshell skull rule".

Some states also have what is referred to as "constructive murder" whereby you can be convicted of murder if you commit a serious crime and someone dies, regardless of whether the possibility of a death was reasonably forseeable; in Canada this has been ruled unconstitutional on the grounds of lacking _mens rea_ but in the USA courts generally accept that having the intent to commit a serious (but non-lethal) crime meets the requirement.

<comment><USER31> The eggshell skull rule is from torts, not criminal law and it would be unconstitutional to apply it to criminal law. You're thinking of constructive murder, where the intent to commit a serious felony everyone to the intent to cause all foreseeable harms that the attempt could engender.

<comment><USER30> Different countries, different constitutions. In Canada, constructive murder was ruled unconstitutional; but if you intend to shoot someone in the leg (say, to stop them from pursuing you) the lack of intent to kill would not save you from a murder charge.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> There's not such a thing as a mistake, only lessons. Lessons learned or otherwise.

I have 1 special account for these type of things, and I keep it empty or with just enough $ to cover what is rightfully owed.

I am no genius. I have learned my lessopn (from PayPal).

<comment><USER20> You'd still be liable for overdraft charges, wouldn't you?

<comment><USER16> You can decline overdraft "protection".

<comment><USER33> Not really. I have overdraft protection disabled on my Ally account. I get fees all the time when it is overdrafted anyway. I really do want to punch the person in charge of letting accounts go negative. I would rather get denied at the POS than overdraft and suffer fees.

<comment><USER18> In Germany, we have special automated loans ("Dispokredit") for this situation. These are expensive (14% p.a.!), but as they are meant to be used only in emergencies and for a short time only, such a situation as here would not incur fees above 1€, as the interest is most often calculated daily.

<comment><USER3> Some banks in the US have this, some charge a fee to use it. It's a niche product though.

</comment></comment></comment></comment></comment></comment><comment><USER34> I'm a buyer and made a couple purchase last night on Etsy. All my credit card info was saved on checkout with no verification required to use the card. Surprised me in comparison to how Amazon or other retailers typically require the full card number be re-entered on checkout. I understand this is different but seems like a bad convenience trade off.

<comment><USER35> Amazon doesn't require re-entry of any details on checkout, at least in the US. I can click a button and immediately purchase something with minimal confirmation.

I have never had to confirm any details with Amazon as far as I can remember.

<comment><USER34> I'm in Canada and I've had to confirm details on my card. I guess outside US thing.

<comment><USER36> In the US, you do have to confirm the details on your card when you change your shipping address in Amazon, or you need to make any updates to it (i.e. cvv / exiry date). Otherwise, not so much.

Edit: Oops, just noticed that point was also posted twice in sibling comments. Oh well, third time's the charm I guess?</comment></comment></comment></comment>


What's Going On (on "Why Python, Ruby, and Javascript are Slow") - <AUTHOR> http://jmoiron.net/blog/whats-going-on/ <comment><USER3> Everyone keeps saying "Use Python and write the slow parts in C"..... except that writing GOOD (secure, correct, safe) C is really hard. That's actually the main reason why the Go authors came up with Go. Not to replace Python etc, but to replace C/C++.

I'm kind of surprised that all the "Python: let's get stuff done" people are suggesting writing a whole bunch of code in C, one of the least "Getting stuff done" languages there is.

For those who have asked what the productivity of Go is like vs. Python + C: Go is very productive. When newbies to Go say it's "verbose" they mean "I have to write out some 3 line loops that in other languages are one line". If that's the major cause of slowness in my development cycle, I'd be ecstatic.

Go is also very easy to write "correct" code in... no buffer overflows, no memory leaks, no access of random memory, no unnecessary allocations, and a very clear and defined behavior from clear, concise code.

<comment><USER4> >"I have to write out some 3 line loops that in other languages are one line"

I think every vim, emacs and decent IDE user would say "I has a text editor. Your argument is invalid."

<comment><USER5> On the flip side of this argument, code should be optimized for _reading_ , not writing. Short, idiomatic code IMHO optimizes for reading. Code like

      array.map(&:to_s)

parses instantaneously. Whereas the procedural equivalent

      strings = []
      for (element in array)
        strings.push element.to_s
      end

requires scanning through the loop to extract out the logic specific to this case. And it's easy to accidentally overlook something when mentally ignoring the "boilerplate".

Not to make a mountain out of a molehill, and not commenting on Go specifically, but the extra "cost" of this style of code adds up when the language itself gets in the way of using high-level abstractions. Methods that are three meaningful lines long are inherently more understandable than equivalent methods that are twelve. Multiply this cost across an entire class, file, and/or project, and it can have a significant impact on one's ability to grok the expected behavior.

<comment><USER6> On the flip side, I had to scratch my head on what "&:" is supposed to mean. Or perhaps it's "&" ":". I know, I'll Google it </yeahright>.

More seriously, "for ..." maps into "map", "foldl", "foldl'", "foldr" and perhaps other constructs. They do pretty much the same thing, but I don't necessarily see a real cognitive advantage of either style.

<comment><USER7> stouset is obviously not arguing that the ruby version with "&:" is immediately obvious to any programmer. The point is if you know ruby, you will understand that line a lot quicker than the second example.

<comment><USER6> What is the "fold" variant in Ruby? Maps are trivial either way, but folds are a pita in my functional programming experience.

<comment><USER8>
      [1, 2, 3, 4, 5].reduce(0, &:+) #=> 15

Which is short hand for:

      [1, 2, 3, 4, 5].reduce(0) { |memo, item| memo + item } #=> 15

<comment><USER6> Yes and no. In practice, you're going to fold into a different domain, which causes the types of the reduce function arguments to be different. Moreover, you are not going to have your reduce function conveniently in a library. You are going to have to write a loop body. At which point, choosing a block over a for loop becomes purely religious.

<comment><USER9> Different domain is fine.

        [1,2,3].reduce([], &:unshift) #=> [3,2,1]

I don't see a problem with writing a for loop, but I think it's not as composable and it can be a little harder to read. So I don't think it's purely religious but it's close to that.

<comment><USER6> Randomly searching for foldr on code.google.com

        inserts :: [(VarId,VarId)] -> Env -> Env
        inserts vvs env = foldr (\(a,b) acc -> M.insert a b acc) env vvs

or

        inserts(vvs, env) {
          for ((a, b) : vvs) {
            env = M.insert(a, b, env)
          }
          return env
        }

Pick your poison, but I'll stick with fors. Go blues!

<comment><USER9> If you want inscrutable Haskell you should go with the <$> operators :) I'd personally still rather have a

        vvs.reduce(env){|env, (a,b)| M.insert(a, b, env)}

but the for loop is perfectly readable also because it fits on a single line. I think for longer bodied reduces I might prefer a for loop actually.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Time of "Getting that shit done" and cost of long-term maintenance are two of the main reasons why people use Ruby/Python, not for the raw performance. I thought that was an old debate. And anyway, from my experience, Python has never been the cause of the slowness.. It's more about tweaking that DB query, smartly packaging the assets or using a better algorithm. (I know it's not always the case. I.e. If my program has to run in the space where bits could be randomly shifted, some additional thoughts would be needed, obviously.)

<comment><USER11> Yeah: your real bottlenecks are going to be 1) getting data out of your database and 2) sending packets across the internet. These are 100 times and 1000 times slower than your program, the 10x penalty to use ruby/python instead of C/C++/go/rust isn't going to matter.

<comment><USER12> > _Yeah: your real bottlenecks are going to be 1) getting data out of your > database and 2) sending packets across the internet. These are 100 times and > 1000 times slower than your program, the 10x penalty to use ruby/python > instead of C/C++/go/rust isn't going to matter._

Only if you're talking about the typical CRUD, website, etc program.

Why should we? People use Python for numerical analysis, scientific computing, etc. Why not let them be able to do that, while still writing in Python (instead of using libraries that delegate to C/Fortran/etc)?

And even a website can do intensive computation work. Why HAVE to write it in 2 languages?

<comment><USER13> The people who use python for numerical analysis use solutions like numpy, with which their programs spend most of their time executing optimised numeric routines.

<comment><USER14> If you can structure your program in such a way that all your inner loops are handled by BLAS/LAPACK/FFTW, then python works great.

The sad fact is you can't always do this. Then you are forced to drop down to C/C++/Fortran.

It would be great if you didn't always have to do this.

<comment><USER15> This is exactly what Numba is designed to help with. And it already works extremely well for such cases. Numba lets you have ease of use (un-typed containers) and speed (with typed-containers) in the same run-time and the same syntax. Here is are some IPython notebooks which illustrate:

<https://www.wakari.io/nb/travis/Using_Numba> <https://www.wakari.io/nb/travis/numba>

And the slides from PyCon Talk: [https://speakerdeck.com/pyconslides/numba-a- dynamic-python-c...](https://speakerdeck.com/pyconslides/numba-a-dynamic- python-compiler-for-science-by-travis-e-oliphant-jon-riehl-mark-florisson-and- siu-kwan-lam)

<comment><USER14> Numba is great for numerical expressions, but I'd be surprised if it works for trickier bits.

For example, consider the problem here:

<http://arxiv.org/abs/0903.1817>

Ultimately I needed to run a math formula on some surfels and connect an edge in a graph if the formula came out True. Following that I had to prune a bunch of edges in the graph. In 2009 (when I did it), I had to drop down to c++. (Admittedly, this was also partly due to a lack of a good python graph lib.)

I'd be very surprised if Numba is helpful with something like that - <USER2> branching and complex data structures don't seem like a great fit for it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> It's too bad that this discussion is ending up mostly in language wars, because Alex' talk was about how to improve the situation, not how to prove that your favored technology is always the right tool for the job and everybody else is wrong.

Let's say that you're doing some NLP and you want to pre-process your strings in Ruby because its easy and elegant. Idiomatically you might write something like "my_objs.map(&:to_s).map { |s| s.gsub(/\W\S/+, '') }.reject(&:blank?)" - perhaps broken up into multiple lines - but you're allocating three arrays and re-allocating every string. And in real life you're probably doing more pre- processing steps which involve additional arrays and possibly additional string re-allocations.

You could switch to gsub! which does the non-word stripping in place, but it "Performs the substitutions of String#gsub in place, returning str, or nil if no substitutions were performed", so you're adding an extra conditional. And it's going to be harder to avoid re-constructing a bunch of arrays.

There's no intrinsic reason you couldn't have basic Ruby language APIs which let you write code which chains operations just as naturally and obviously, but don't wastefully re-allocate. Think of how ActiveRecord relations defer the actual SQL execution until it's unavoidable.

(Haskell-style laziness might solve the main issue above, but I've run into analogous unavoidable-allocation problems with Haskell. If I'm depth-first searching a board game state-tree I shouldn't have to re-allocate the whole state representation at each step, but it's pretty hard to avoid while writing elegant Haskell since modifying memory in-place has side-effects.)

I don't know Go, but maybe instead of talking about why people who still use Python or Ruby are or are not stupid, we can talk about what it gets right that other languages can adapt?

</comment><comment><USER17> _"Programmers of elegant scripting languages desire similarly elegant looking code with flexible data structures even where no flexibility is in play. Some who know better will understand that technical limitations make the difference between hashes and other types of named lookups essentially nil for many popular language runtimes."_

OK, if no flexibility is in play in many usages of hashmaps, should not an intelligent interpreter/compiler be able to _detect this_ and modify the use of the hashmap accordingly? Maybe even use a different lookup system in those cases? It seems like that would be ... elegant.

The reason VMs don't need to be slow is that you don't need to treat an eval call literally, you don't always need to create a full environment to parse a twenty character string, right? But if you can get around that, should you not be able to get around hash-map's problems? Am I missing something.

<comment><USER11> Doesn't the V8 javascript engine do something like this? Where it builds C-structs instead of hashmaps if it can detect that your objects are being built in a consistent way

<comment><USER18> Yes. They call it "hidden classes": <https://developers.google.com/v8/design#prop_access>

</comment></comment></comment><comment><USER19> Since the author uses Go as a basis of comparison. I thought these benchmarks from The Computer Language Benchmarks Game might be interesting:

Go vs. Ruby: [http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=yarv)

Go vs. Python: [http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=python3)

Note: These results are from the 64-bit single core machine since it has already been updated to Go 1.1 beta 1. There is also a faster Go regex program (#7) that hopefully can be made to work again after 1.1 is released (in place of #1).

Although still using Go 1.0.X ,the recent TechEmpower benchmarks might be interesting if you have not seen them: [http://www.techempower.com/blog/2013/03/28/framework- benchma...](http://www.techempower.com/blog/2013/03/28/framework-benchmarks/) (It looks like Go 1.1 _might be_ 3x faster: <https://gist.github.com/errnoh/5320784>)

P.S. As always your own program is always the best benchmark to use, your millage may very, take your gain of salt, etc etc.

<comment><USER20> On the same site, the advantages of Go vs good dynamic language implementation like JavaScript V8 aren't so impressive:

[http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=v8)

<comment><USER21> Being 2-10x faster and using a lot less memory isn't impressive? I'm sure the Go optimizer still needs a lot of work. It's going to get much better. The V8 optimizer is great but we're probably closer to the limit of how much more can be done than with Go.

<comment><USER22> I think there's a bit of a disconnect here between people who work on applications where, say, a 25% reduction in CPU usage would be a big win, and people who don't worry about performance as long as their cluster isn't melting down.

</comment></comment></comment></comment><comment><USER23> I am sure I am just going to have this comment buried because people don't like to have Python and Ruby compared unfavorably, but I have to try to help people out.

Looks like a lot of people STILL haven't caught on to how big of a performance advantage Node.js's V8 engine gives you over Python and Ruby. Look at benchmarks like this one: [http://fengmk2.github.io/blog/2011/fibonacci/nodejs- python-p...](http://fengmk2.github.io/blog/2011/fibonacci/nodejs-python-php- ruby-lua.html)

Most of the time modern JavaScript is compiled to native code. Its much faster than you realize.

The cleanest code is a new language called CoffeeScript which compiles to JavaScript. Its more Pythonic than Python. Its the closest to pseudocode that you can get (especially if you avoid a few Rubyisms).

The best APIs available are in Node.js modules (see npmjs.org). Best meaning most advanced API design in that the modules are focused, decoupled, very straightforward. This is also by far the best design for package management and dependencies since it is very open and flexible.

On top of that, Node.js is built from the ground up to support highly concurrent input/output. It just amazes me that people haven't figured out what a big advantage Node.js and CoffeeScript provide over Python or Ruby.

I actually think that a big thing holding people back is that Node.js and CoffeeScript make things so much easier, people think its cheating, and are afraid their programmer friends will think less of them if they take advantage of something that really simplifies their jobs.

<comment><USER24> CoffeeScript is horribly... stabby? Its ambiguous syntax makes it easy to hurt yourself.

And node.js, while great, is not magic.

I would also much rather use Python's classes than do JS OOP or use CS classes. That said, I use node.js more often than Python.

<comment><USER23> How much time have you spent using CoffeeScript? It might take a week or two to get used to it. I think if you just stick with some basic stuff and write it like Python with less punctuation then it is pretty straightforward and CS classes are very straightforward, what's wrong with them?

Just leave out the outer parenthesis and put them in after that.

<comment><USER24> I've spent plenty of time with CoffeeScript, and I don't like it. It's not explicit enough, and the syntax is too permissive. It's easy to get bitten by things like omitting parentheses when calling a function, which creates hard- to-spot bugs. CoffeeScript also creates poorly performing code by default, by treating everything as an expression and returning it unless you tell it not to.

</comment></comment></comment></comment><comment><USER25> Overall nice article, it just looses a bit by focusing too much on Go vs Python issue.

1 - The are quite quite a few strong type languages with native code implementations since the mid-80's, even GC enabled, Go is not the only one.

2 - There are dynamic languages like Self, Dylan, Lisp even the young Julia that have implementations which achieve C like speeds when compiled to native code, especially when the developers make use of type annotations and use the right data structures.

Self is specially important given that the research work, in a dynamic language, ended up being the heart of Sun's JIT compiler.

<comment><USER26> Yeah I don't sympathize with ruby/python/go people. CL can be interpreted & compiled. Why the fuck is it okay to literally choose the worst options just because people don't like seeing an explicit AST?

<comment><USER27> Why specifically are these "literally the worst" options?

</comment></comment></comment><comment><USER28> I've noticed this in some code I've been refactoring at work recently (a feed generation system). It's easy in Perl to suck in a large amount of data into one array and map/grep it into another array of hashes and output filtered/formatted data in a few lines. The problem of course is that your business'/project's own growth overwhelms the algorithm as the data structure balloons. This is further compounded by libraries which are designed to accept an array as input (reinforcing the idiom causing the first problem) since you end up with thousands of additional iterations.

I refactored the code to lazy load each item in the collection and map/filter/generate the XML at the end of each node's iteration. The end result is a nice flat memory space (save for the odd leak here and there) that's about 1/10th of the original program's, at the 'expense' of only a few more lines of code.

</comment><comment><USER29> This thread has got me cracking up. I'm sure all of you are very smart, yet you all treat each other as though the other person is a stupid, incompetent programmer. It's a trend I observe everywhere in online programming communities.

<comment><USER30> But all the others are stupid, incompetent programmers. It started at MIT.

Just kidding! (sort of). But have a look at the Jargon Appendix (<http://catb.org/jargon/html/pt03.html>) - especially The Story of Mel (<http://catb.org/jargon/html/story-of-mel.html>).

</comment></comment><comment><USER31> Very interesting read.

I have only written a small amount of Go, I have been through tour.golang.org, just waiting for the right project for me to use it on.

Currently whenever a new project comes along I reach for C or Perl, hoping to find a niche between them for Go.

<comment><USER32> The feature with scripting languages compared with system languages (C, Java, etc) is that they are fast -- not to run code, but to develop functionality.

The article argued that idiomatic Go gave at least as good runtime speedup as a normal scripting language (Perl, Ruby, etc) with the (small) time critical parts rewritten in C.

But it didn't touch the important question -- is the development time for Go faster than for scripting languages with critical sections in C?

Go looks fun, but I'd personally want information on that metric before trying it on a project. [Edit: Yeah, as the article noted, Go excels re parallelization etc. I might Go for it in those use cases.]

(What I'd really want is to find a place which use Lisp, since development speed is roughly as fast as for scripting languages and there has been good compilers for decades.)

Edit: Spelling, must start going over the room for the keyboard when using the iPad.

<comment><USER33> > But it didn't touch the important question -- is the development time for Go > faster than for scripting languages with critical sections in C?

At YouTube (which is a predominantly Python shop) we use Go for some elements of our infrastructure, and I spend approximately half of my time working in each language (main project in Go, integration tests in Python). In my experience easy things (say, split and massage some strings) are more complicated/annoying in Go than in Python (and much more verbose). However, _difficult_ things usually end up being _much_ simpler in Go than in Python – especially if they involve concurrency (Python threading is a trainwreck). The difficult parts of our code consume most of our brainpower, so that's a net gain from our point of view. What is more, for some weird reason Go code seems to be less susceptible to bitrot (go fmt FTW).

<comment><USER34> Even string splitting in Go isn't that bad, frankly.

        words := strings.Split(wordList, " ")
        foo := words[0]
        if len(words) > 1 {
          bar := words[1]
        }

Where things can get a bit tedious is data conversion from byte buffers, like reading in data from disk or Redis or something. But that's no different from any other statically-typed language.

I would like to see more libraries in Go, though. Much of what's complex is there, but one of the benefits of languages like Python and Ruby is there are lots of libraries for the easy stuff, too. Having to write a data model validation library yourself is boring.

</comment></comment></comment></comment><comment><USER35> On the to garbage collect or not issue briefly mentioned at the end, the best reason to use an unmanaged language is predictability of performance. You know the GC won't step in at a critical moment. I regularly get frustrated by Eclipse becoming unresponsive for several seconds.

<comment><USER25> There are real time GCs for many languages that compile to native code.

The way Eclipse is coded is not a good example of GC performance.

</comment></comment><comment><USER36> I'm currently hitting some performance issues trying to use Python to make a naive physics engine- does anyone have any reading recommendations on best practices for python performance?

<comment><USER15> I'd love to see how Numba helps you. Give it a try: <http://numba.pydata.org>

Slide deck: [https://speakerdeck.com/pyconslides/numba-a-dynamic- python-c...](https://speakerdeck.com/pyconslides/numba-a-dynamic-python- compiler-for-science-by-travis-e-oliphant-jon-riehl-mark-florisson-and-siu- kwan-lam)

IPython notebook examples: <https://www.wakari.io/nb/travis/numba> <https://www.wakari.io/nb/travis/Using_Numba>

</comment></comment><comment><USER37> the endless debate continues...

choose two:

a. fast execution of the code on the machine

b. fast code generation by the programmer

c. fine-grained control over every aspect of the code

I know which two I'd rather have, esp in the long run.

<comment><USER15> Numba is trying to let you make a different choice for different sections of the same program so that you can do different styles of programming in code meant to be a library than you might do in other sections of code meant to be more "ocassional programmer" facing.

Some of you might find the roadmap particularly interesting. It's an open- source project eager for input from others...

<http://numba.pydata.org/numba-doc/dev/roadmap.html>

</comment></comment><comment><USER38> The video has been posted for anyone interested:

<http://vimeo.com/61044810>

</comment><comment><USER39> Wouldn't adding goland-style slices to Python be awesome?

<comment><USER40> It's not quite the same but some of the use cases (and a bunch of other stuff) would be covered by numpy arrays. You can create multiple views on the same in memory data with different start and end points and different strides.

<comment><USER41> Agreed. I think numpy arrays a rather overlooked by most python programmers. They allow all kinds of useful tricks like that that are quite handy even if you're not doing strictly numeric work.

</comment></comment></comment><comment><USER42> The biggest confusion is seeing Python/Ruby/JS as a programming languages. They are not. They are scripting languages. Something you put on top of your core code.

<comment><USER27> Does the phrase "scripting language" have any hard technical meaning or is it just another subjective label?

<comment><USER19> I've always informally thought of a scripting language as anything the executes by interpreting source code or bytecode (lacking JIT compilation).

</comment></comment></comment><comment><USER43> Both the submission and the target of the submission dismiss dynamic typing as a source of slowdowns (in the unfortunately haughty, completely unsupported manner that is too common in the industry. It is, in effect, the head-in-the- sand approach: If you don't want something to be true, simply keep saying it isn't and somehow that will become reality), yet I guess we need to define what "slow" is then, using as an example an empirical test (ASM.JS) that certainly serves better than some people waving their hands about innovations in JIT compilers.

The primary optimization that ASM.JS brings is its static type system. With that, and the obvious benefits to the code path, intensive activities can be run at 1/2 native speed, versus the 1/12th of so native speed available with dynamic typing.

Is 1/12th native speed "slow"? In most cases -- where the code is the duct- tape that glues together native code (which is the case on web servers, admin scripts, etc), no, it isn't slow at all. But from a basic optimization perspective, asm.js sure seems to indict dynamic typing if you really care about squeezing every cycle's maximal output.

<comment><USER44> No, the primary optimization asm.js brings (at least in OdinMonkey) is AOT compilation.

Fully typed code should produce the same code from IonMonkey without OdinMonkey: the problem is you have to get up to 10k calls (at least last I looked!) of a function before you get there; but once you are there it is just as good. It's the build-up, through the interpreter and the less efficient code-generators (in terms of code generated, that is; they're more efficient in terms of their own runtime), which really hurts.

<comment><USER43> _No, the primary optimization asm.js brings (at least in OdinMonkey) is AOT compilation._

But it can do that precisely because of the static typing, which loops back to exactly what I said. Looser, more dynamic language always have a cost associated with that flexibility.

<comment><USER44> Arbitrary JS can be as statically typed as asm.js is (because, well, asm.js is just a subset). There's no reason why one couldn't compile AOT something like:

      function add_and_double(a, b) {
        a = a | 0;
        b = b | 0;
        var sum = (a + b) | 0;
        return (sum + sum) | 0;
      }

Yes, it'd be trivial to fall off the AOT-compilation path (esp. without a defined subset that got AOT compilation and hence likely would differ between implementations), so static verification that you're on the AOT-compilation path is valuable (which asm.js provides), but it doesn't fundamentally alter the semantics of the language.

<comment><USER45> You seem to be saying that the AOT path requires constrained typing and a strict subset of the language semantics, which agrees with the parent's point that static type semantics matter in terms of performance.

<comment><USER44> They matter, yes. But they aren't in any way specific to asm.js — it was something that was already true in generic JS.

<comment><USER43> But it is extremely specific to asm.js -- the optimizations possible can only happen because static typing is mandated. It is absolutely a subset of JS, but JS can't make those optimizations because the guarantees aren't there.</comment></comment></comment></comment></comment></comment></comment>


50 Shades of Programming: What If Christian Grey Were a Programmer? - <AUTHOR> https://hackernoon.com/50-shades-of-programming-what-if-christian-grey-were-a-programmer-36ad195cdeac <comment><USER2> "He opened a Vim. I knew there was no exit"

LOL :-)

</comment><comment><USER3> Funny read :)</comment>


SQL Server Machine Learning Services – Internals I - <AUTHOR> http://www.nielsberglund.com/2017/03/18/microsoft-sql-server-r-services---internals-i/ <comment><AUTHOR> First post in a series about the internals of SQL Server Machine Learning Services</comment>


I fasted for 11 days, and here is what happened - <AUTHOR> https://itsyourturnblog.com/i-was-without-food-for-11-days-here-is-what-happened-7560e8625dbf <comment><USER2> [https://outline.com/eRzCyJ](https://outline.com/eRzCyJ)</comment>


Elance Hit By Security Breach - <AUTHOR> http://www.techcrunch.com/2009/07/16/elance-hit-by-security-breach/ <comment><USER2> I've mostly not been anti-techcrunch over the whole twitter thing, but the last paragraph of this article just inspires multiple levels of "what the fuck."

<comment><AUTHOR> agreed, I'd trust Google to secure their servers more than I would myself</comment></comment>


What would London look like without Freedom of Panorama? - <AUTHOR> https://blog.wikimedia.org.uk/2015/07/what-would-london-look-like-without-freedom-of-panorama-a-letter-to-meps/

<comment><USER2> To be honest, anything that removes the Shard, 122 Leadenhall and 20 Fenchurch from the skyline (even if it's just photos) is A-OK by me.

</comment><comment><USER3> Its not about photographing them, is it? Its about commercialization of said photos. So go ahead and take your holiday snaps.</comment>


SpaceX lands all 3 booster rockets for first time in history - <AUTHOR> https://www.youtube.com/watch?v=84HmJaMqBog <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=19643761](https://news.ycombinator.com/item?id=19643761)

</comment><comment><USER3> Someone else just landed four rockets. [https://i.imgur.com/S6L5A1P.jpg](https://i.imgur.com/S6L5A1P.jpg)

</comment><comment><USER4> Not gonna lie, this made me tear up.

</comment><comment><USER5> hat trick</comment>


Reviews of "A Million Random Digits" - <AUTHOR> http://www.r-bloggers.com/because-its-friday-reviews-of-random-digits/

<comment><USER2> Here's the actual page [https://www.amazon.com/Million-Random-Digits-Normal- Deviates...](https://www.amazon.com/Million-Random-Digits-Normal- Deviates/product- reviews/0833030477/ref=cm_cr_pr_top_helpful?ie=UTF8&showViewpoints=0)</comment>


In-depth Look at Data Modeling in MongoDB - <AUTHOR> http://blog.fiesta.cc/post/11319522700/walkthrough-mongodb-data-modeling

<comment><USER2> As NoSQL is gaining more relevance, this sort of practical examples are great for everyone to see and review. More, more, give me more, I say!

<comment><AUTHOR> We'll try to keep adding whatever information we can about our deployment. If you have specific questions just shoot us an email - they'll probably be good inspiration for future posts.

</comment></comment><comment><USER3> Nice article. I'd certainly like to see you go a little bit deeper still.

I'm not sure if many people are familiar with the ideas behind domain driven design (as in, the Eric Evans book), but I find that modelling your documents around your aggregate roots is a good starting point.</comment>


How to Overclock your Raspberry Pi - <AUTHOR> http://www.jeremymorgan.com/tutorials/raspberry-pi/how-to-overclock-raspberry-pi/

<comment><USER2> I really don't like these articles where the author provides a list of commands without actually understanding what some of them do. "sudo sync; sync" for instance. This is on par with copy-paste programming.

</comment><comment><USER3> Some of his articles about the RPI have been pretty basic, but this one is actually pretty good, because it shows several methods. Just editing the config and rebooting didn't work for me the first time.

<comment><USER4> I don't necessarily think it's a bad thing. After all rPI is supposed to be educational, right?

</comment></comment><comment><USER5> Backing up config.txt does not make sense. "sync" alone might be sufficient.</comment>