Munich confirms switch to Windows 10 - <AUTHOR> https://www.techrepublic.com/article/end-of-an-open-source-era-linux-pioneer-munich-confirms-switch-to-windows-10/ <comment><USER2> I'm all for FLOSS solutions and love Linux and many of the things that are freely available to us. I wouldn't trade Linux for Windows for any sort of development work.

However, I'll be the first to admit that MS Office simply blows Libre Office out of the water. I'm very good with Excel and Calc, but I'm many times slower with Calc. The hotkeys, variety of equations, and simple features simply aren't available in Calc. I know that if I'm say 3x slower, the cost associated with that across a year and across a team is going to outweigh the MS subscription.

There is nothing wrong with ceding the crown to the better product.

<comment><USER3> I've used MS Office, Libreoffice and Google Apps and find them all equally appalling. Terrible, clumsy, complicated, inaccurate UI, unusable version control, ugly output. (Compared to git + emacs + TeX/docbook/perldoc/HTML/plain text).

<comment><USER4> Oh, I always come to HN and hold my breathe not to see comments like this...

Do you think that someone who has never touched computer except for Facebook, MS Office and emailing should know Lisp and UNIX environment?

</comment></comment></comment><comment><USER5> Just a small information that's missing from the discussion: I'm sure this decision doesn't have anything to do with Microsoft (a major taxpayer) moving its German offices from the suburbs (Unterschleißheim) to Munich proper in 2016 ([https://mspoweruser.com/microsoft-germany-moves-into-a- new-h...](https://mspoweruser.com/microsoft-germany-moves-into-a-new- headquarters/))...

<comment><USER6> Munich should have switched to ChromeOS/ChromiumOS or Android or RedHat/CentOS or Ubuntu on thin clients, as the software is anyway usually web based in the cloud/intranet. But neither Google nor RedHat or Ubuntu are known to lobby.

@sz4kerto:

> ChromeOS proprietary

Why you pick this one of a list of many? ChromiumOS is open source, as is Android, as is RedHat or Ubuntu. But Windows is proprietary.

> Google spends a lot on lobbying, by the way, afaik more than what Microsoft > is spending.

Really? Source please. The question is how much do they all spend lobbying for an OS? How much do they spend lobbying in Munich? (hint German HQ got relocated to Munich) You read like a employee.

<comment><USER7> Why do you reply by editing your original comment, instead of using the "reply"-function?

<comment><USER6> Here is why - even if I risk more downvotes or getting flagged down:

If someone flags your comment on HN, you can only post about 4 comments per day and news submit feature is "practically" disabled - HN displays a "slow down, don't submit so fast" Error message which of course makes little sense. Also your comments will start with a lower/negative value behind the scene, you will find your posts on the bottom even if it says 1 votes, and other comments with negative value may be above yours.

There is a lot of monitoring by companies contracted obviously by $$ going on, to shape PR and public opinion. Be it employees, fanboys, or paid PR drones, it doesn't matter, they are quite toxic to the community at large I would say. I would wish more moderation in regard, and the removal of the downvote- and flag-functionality for everyone (but moderators).

<comment><USER7> Okay, I understand. I agree that the Hacker News comment system isn't optimal. Downvotes shouldn't hide a comment. Unpopular opinions shouldn't be suppressed. I'm not sure how the flag-functionality works, but if it can hide a comment without moderator input, then I'm all for replacing it with a "report"-function. Too many times one sees throwaway accounts being used for expressing possibly unpopular thoughts. I can only imagine how many comments weren't written, because somebody was afraid of downvotes and losing the good standing of his account. Personally I too have started writing a couple comments and not posted them in the end, because I was afraid of downvotes and the associated consequences. Having to think like that doesn't exactly help to make HN a diverse and interesting place.

</comment></comment></comment></comment></comment><comment><USER8> For those who want a longer read, the LWN article earlier this month was fantastic

[https://lwn.net/Articles/737818/](https://lwn.net/Articles/737818/)

</comment><comment><USER9> Even the giants can die. And as they do, their willingness to help you export your data from their proprietary formats and products will decrease at a rate faster than the neccessity of doing so. Properitary software is a short sighted choice, and probably one made by people with greased pockets.

It's difficult to get funding to work on open source software. Governments are a natural source, but time and time again bribery fucks everything up.

<comment><USER10> Would it be wrong to say that Microsoft is "too big to fail", similar to some banks? I'd expect governments to actually try and save Microsoft precisely because of this situation.

<comment><USER11> > Would it be wrong to say that Microsoft is "too big to fail", similar to > some banks? I'd expect governments to actually try and save Microsoft > precisely because of this situation.

It doesn't really work like that. If Microsoft fails, it will be slow. You don't go from 90% installed base to 0% installed base overnight. There is no point at which they still have enough customers to be too big to fail but don't have enough to continue operating.

But as businesses transition to something else, they have to pay the transition cost. Which is a lot higher when changing market conditions force you to transition unexpectedly than when you have the foresight to plan and get ahead of the curve.

</comment></comment></comment><comment><USER12> They switch back to Windows in a time of total vendor lock-in in the office software space. In the time when they started their Linux project, one really could switch from Office 2003 to Staroffice/Openoffice. But now, in the days of cloud and absolute technical domination of Office 365, this is a bit sad to see.

<comment><USER13> Office 365 is affordable, well-supported, easy to use, and updated frequently. It does what businesses and governments want. Their formats are well- supported. The software is also very stable and very mature. Other than ideology, there are few reasons not to use Office 365.

<comment><USER14> One reason not to use it is because it makes German government dependent on a foreign company. Another reason not to use it is because it's a cloud product and shouldn't be used to store private data about German citizens. Another reason not to use it is because the FOSS alternatives are free.

<comment><USER15> There is still real cost to using FOSS software.

Training employees.

Maintaining the environment by addressing bugs.

Securing the environment.

Plus compatibility with proprietary formats isn't 100%.

I'd still choose FOSS for many kinds of environments but it's not free.

<comment><USER16> All of those enumerated costs apply equally to proprietary software as well.

<comment><USER17> they apply to proprietary software. they most certainly do not apply _equally_. it's a lot easier (and therefore cheaper) to find staff to support windows than it is to find staff to support linux.

<comment><USER16> I would certainly be interested in some concrete numbers.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Background : I am IT for 25 years, run Linux on all servers (pro and home), develop open source.

I tried to use Linux desktop at least 5 times over the last years (again a few days ago on the home shared laptop).

It is ok-ish when I use the browser and IDEs (vcs, pycharm) but anything else is horrendous. I looked for an equivalent of ShareX, I felt like I was 25 again.

Linux desktop is on for the 86% if the train which only uses a browser ("Internet") but I doubt anything more specialized is reasonable. Not that Linux desktop is bad (though it is not good either), it's because there are no ports of that specialized software.

If someone is fully (apps, I mean) html5 then why not.

<comment><USER19> Gaming is also covered, with 2500+ commercial games available on Steam only.

The KDE applications Kdevelop, Kdenlive and Krita has improved a lot the latest 1-2 years, providing a pretty great IDE, video editing and also painting application.

3D animation, modeling and texturing isn't too shabby either, with Maya, Houdini, Blender and 3D-Coat.

For ShareX, there are many alternatives for grabbing screenshots. A direct clone is ShareNix (video: [http://www.hnng.moe/f/3CI](http://www.hnng.moe/f/3CI))

If ShareX is what's stopping you, I think that you're mainly stuck with a Windows desktop habit.

<comment><USER20> Regarding gaming: it doesn't matter how many games are there, what matters is WHICH GAMES.

Playing games is a social activity after all, especially for teenagers. If all of your Windows-using friends are playing Assassin's Creed: Origins, and you can't because there isn't a Linux version of it then those 2500+ games on Steam do not really matter to you.

<comment><USER21> CS:GO is there and IMO it has often been more performant there than on Windows :-)

While CS:GO might not be your thing it should be proof that the sitiation is improving.

<comment><USER22> I'd consider a switch for gaming if Linux had more games than windows, and the graphics drivers were more performant on Linux.

90% of the game library or 95% of game performance Will _not_ do it.

Until then, having a windows license even if only for gaming is a no brainer.

</comment></comment></comment></comment></comment><comment><USER23> I wonder about the telemetry... or have they decided that the available methods of disabling it are sufficient? I remember hearing that a lot of Germans were wary of Win10 specifically because of that.

<comment><USER24> If you have Windows 10 Enterprise edition, all telemetry can be disabled. Most people don't talk about that much because at $500 a seat... well, most people don't buy Enterprise edition. (Of course, organizations of certain sizes, government institutions, etc. may have better pricing options available to them as well.)

Also, bear in mind, if you're an organization with a proper modern firewall solution, you can detect and block unwanted network traffic at the edges of your network as well.

<comment><USER25> > If you have Windows 10 Enterprise edition, all telemetry can be disabled.

I remember reading that this common belief is wrong, but unfortunately I don't remember where/who claimed that. Did it recently change, perhaps?

<comment><USER23> That might be this: [https://xato.net/windows-spying-and-a-twitter- rant-19203babb...](https://xato.net/windows-spying-and-a-twitter- rant-19203babb2e7)

It's so confusing to disable that a (admittedly self-proclaimed, but still) "security expert" got it wrong several times, and even after that it still continued sending data to Microsoft. It reminds me of the same scummy tricks used by spyware/adware in the past e.g. "do not disable for the best user experience", double-negative wording, etc.

I believe it's still (deliberately) really easy to pirate/crack Windows, so I could get the Enterprise edition if I wanted --- but I wouldn't want it even if it was legally free, just like all sorts of other malware and unwanted software.

<comment><USER24> No doubt that it's easy to mess up Group Policies. He's not wrong in that you have to very clearly read each one's description because different policies expect you to do different things sometimes to do the same things. That's definitely not new to Windows 10, and arguably just bad design on Microsoft's part; there appears to be no standardized design pattern to how GPOs should function across the whole Windows team.

But it is still entirely possible to disable all telemetry with it.

<comment><USER26> Even with Enterprise edition it is very difficult to disable all telemetry. The lowest official setting for telemetry is "security" which still sends data to Microsoft (see [https://docs.microsoft.com/en- us/windows/configuration/confi...](https://docs.microsoft.com/en- us/windows/configuration/configure-windows-telemetry-in-your- organization?f=255&MSPPError=-2147217396)).

There are, however, a number of hacks that can trim that down even further. But being hacks they aren't guaranteed to always work--things frequently change.

Since writing the article mentioned a couple comments up I have tried completely ripping out all telemetry components from the install CD, which seems to be the most effective option. Tools such as Blackbird ([http://www.getblackbird.net/](http://www.getblackbird.net/)) also are quite effective. Nonetheless, monitoring traffic still shows connections to Microsoft-controlled servers. There are so many ways Microsoft (and therefore possible governments) can gather--or at least infer--information about your system.

To completely protect yourself would require manually monitoring, selecting, and installing updates, manually updating certificate revocation lists, constantly watching for new settings (including firewall and hosts entries) that must be addressed, etc.

So no, it is not possible to completely disable all forms of Windows 10 telemetry without also committing to an unreasonable amount of work.

</comment></comment></comment></comment></comment></comment><comment><USER27> Also: what is the Linux equivalent of Active Directory / Windows domain? How do you centrally manage workstations? (push software updates, configure firewall rules and other access policies, etc.)

<comment><USER25> > what is the Linux equivalent of Active Directory / Windows domain?

LDAP

> How do you centrally manage workstations?

SSH

This is how my school does it: there is a system user with an ssh key which they use for pushing updates and such (e.g. recently fail2ban was installed on all computers), and we can all log into any system using LDAP.

<comment><USER28> Active directory isn't equivalent to a basic LDAP directory not even close.

To have similar functionality you need a commercial directory solution.

Same goes for remote management SSH is how you connect to machines remotely not how you manage them.

Automation of Linux desktop again requires either a commercial product or a huge development undertaking.

The problem with Linux on the desktop is that if you get out of the Microsoft ecosystem you need products to centrally manage users, workstations, configuration and patch management and all of these usually require you to go for other enterprise solutions even if they are OpenSource in their core but still commercial in practice.

</comment></comment></comment><comment><USER29> Hello. I am a linux lover. I have choosen ubuntu gnome because IMHO, it is the closer to desktop linux and I do not want to spend my life tuning my system. Recently there was some automatic updates and now the chrome scrollbar jumps crazy. I am pretty sure this will be fixed in a couple of days (weeks), but all these little glitches are becoming tiring. Since release 16.04, I have stopped advising people to migrate to linux. I see discutions about removing the features that count for me (network transparency, remote display, GPL license, ...). As a tax payer, I really want my administration to stop giving money to compagnies that work against my freedom. I feel very sad about it but Munich is probably reverting to Microsoft for sensible reasons and not for politic.

<comment><USER30> I feel that you are portraying Ubuntu as representing all of Linux, and maybe it does to you, but this is far from the truth.

<comment><USER29> At work, I have just migrated to RHEL 7. With RHEL 7.3, there was a problem with gedit (impossible to resize). This ought to be solved in 7.4. In 7.4 most of the applications crash because GTK does not check correctly the values returned by the RandR extension (which is broken in my version of exceed). The current workarounds are either to use xming or deactivate extension RandR (unrealistic in our case because many people use laptop). The package bash- completion is installed by default. It causes so many issues that we decided to mandate its removal in all installations.

</comment></comment></comment><comment><USER31> Recent related articles:

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

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

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

</comment><comment><USER32> Does anyone know if the amount they'll be paying in Microsoft licensing is (or will be) public?

It would be interesting to see if they're getting an unusually good deal. Though I suppose there might be ways to hide that if they wanted to.

</comment><comment><USER33> Imagine if Munich had put the same amount into improving the upstream software instead.

Politicians never fail to disappoint, feels like.

That said, I often can't replace Windows due to legacy applications.

Regarding MS Office, some people buy iPhone. These people also seem to need their Microsoft Office.

<comment><USER34> Microsoft Office apps are available for iPhone - [https://itunes.apple.com/gb/developer/microsoft- corporation/...](https://itunes.apple.com/gb/developer/microsoft- corporation/id298856275)</comment></comment>


How lazy writers and Wikipedia create and spread fake "facts" - <AUTHOR> https://news3lv.com/around-the-web/the-case-of-an-iconic-watch-how-wikipedia-and-writers-create-false-facts-from-thin-air <comment><USER2> Lol literally fake news, was this story reported by someone not familiar with wikipedia? Wikipedia being an open source encyclopedia is obviously subjected to margin of error so to speak. The point is that info can be built and it's done voluntarily over time on many 'items of interest'.

Fear mongering on sources heh, well you can go to many science related pages and at the least find sources from reviews which can be from very credible sources such as the NIH.

This is a weird troglodytic shitting on wikipedia.</comment>


Show HN: Note_space: organize your thoughts locally, not in the cloud - <AUTHOR> http://www.kylla.info <comment><AUTHOR> There are a lot of note-taking programs, and I've looked at most of them, but I couldn't find one that met all of these criteria: 1) runs as a local program, not on an internet server. 2) uses a relatively simple design, without overly-complicated features. 3) shows a grid-like display, not a list- like display. 4) is free, and open source. 5) runs on Windows, Mac and Linux, but is light-weight and portable. To get all this, I made this program, which is available for download at www.kylla.info.</comment>


NanoScroller.js - An easy-to-use jQuery scrollbar that looks like Lion's. - <AUTHOR> http://jamesflorentino.com/jquery.nanoscroller/ <comment><USER2> Too many custom scrollbar projects (including this one) make the mistake of overriding everything helpful the browser does for you and then imperfectly reimplementing it.

The best technical approach is to make the scrollable element naturally scrollable with overflow: auto, and then put it inside a viewport element (overflow: hidden) narrow enough to cut off the scrollbar (there are plugins that can help you figure out exactly how wide the host's OS's scrollbars are).

Then, you're free to listen for scroll events and overlay your own custom scroller UI.

<comment><USER3> Thanks! That seems pretty useful. Will include that in my next commit.

<comment><USER4> I implemented something similar here: <https://github.com/joevennix/jScrollie>

I agree that it is best to let the browser handle the scrolling mechanics. Then you simply hide the original scrollbar by having an embedded div hold the content with a width thats about 40px or so bigger than the outer, fixed width div ( and overflow: scroll-y ).

</comment></comment></comment><comment><USER5> It doesn't seem to respect Lion's reverse scrolling which makes this a tough usability sell (among other reasons).

<comment><USER6> scrolling direction should depend on your mouse scrolling setting, not the website settings

</comment></comment><comment><USER7> I created a similar project a few weeks ago, with the difference that it preserves native scrolling: <http://learnboost.github.com/antiscroll>

<comment><USER8> Your is more usable, I can scroll with my mouse wheel, but I cannot click on the scroll bar's empty area and "jump" down a section.

</comment></comment><comment><USER9> I thought we got rid of custom scrollbars back in 2000

<comment><USER10> The difference between these custom scrollbars is that (in modern browsers) they are still scrollbars that work exactly like other scrollbars and only look different.

<comment><USER9> Except they don't, try using the arrow keys to navigate in the scrollable DIV. Not working for me (Firefox latest stable). It also scrolls ridiculously slowly using the mouse wheel. So we're actually going backwards in functionality.

Fuck the design if it's unusable.

</comment></comment></comment><comment><USER11> Why are we messing with things I already knew?

You're the website, _you_ deliver me content, _I_ decide what to do with it. Don't take really long ways around to force me to do things your way, use semantic HTML and CSS, use the default scroll bars, let me pick a user-agent that makes scroll-bars the way I want. I don't want to use OSX Lion scroll bars because I think mac's are lame, but now I have no choice.

<comment><USER3> The custom scrollbar is actually meant for scrollable div layers. (e.g. logs for chat-based applications). I needed a way to get rid of the thick native scrollbar skin for a javascript-dev project to match the overall design. Hence, why I came up with it.

<comment><USER12> I'm really glad your wrote this. It's just the solution I'm looking for. Uber- geeks will always complain about custom scroll bars, but the rest of society appreciates the clean design.

<comment><USER13> That's not about uber-geeks. It's simply about usability. And the rest of the society will not complain about the failing usability but it will notice it.

</comment></comment></comment></comment><comment><USER14> Doesn't respect native scroll speed - way too slow on FF/WinXP.

</comment><comment><USER15> "looks like Lion's" - I'm supposed to want this?

</comment><comment><USER13> Please take a look at this: <http://www.useit.com/alertbox/9605.html>

Section "Violating Design Conventions".

This is exactly why you shouldn't implement/use other scrollbars and similar things which change the behaviour of standard design practices.

</comment><comment><USER16> I've also made my own scrollbar for a project, so I have enhanced super vision to see the edge cases:

1) scrollbar disappears on drag when the mouse moves out of the container. To fix you need to have a flag when the scrollbar is dragging and not call fadeout when true.

2) convenient UI feature: scrollbar can appear on hover, then disappear if user hasn't moved mouse, and reappear on mousemove. This is done in Facebook for example. This is accomplished by setting and clearing timeouts.

(also, the bot left container for the scrollbar doesn't have a rounded corner)

otherwise great job!

</comment><comment><USER17> I don't understand what all this pseudo-innovation in scroll bar technology is accomplishing. I first saw it in google wave, which _drastically_ changed the way that scroll bars behaved, and the way I had to interact with them. More recently, I've upgraded Ubuntu and now Unity has funky, unintuitive scroll bars. What is the holy grail of scroll bar usability, and is this getting us any closer? I'm not really feeling the advantages.

Edit: as per slig's comment, a lot of tools in google's latest design refresh are using terrible scroll bars, too.

<comment><USER18> Holy grail == hold down a button and drag.

Many web browsers already have this functionality (sort of) with middle-click.

Forcing the user to navigate to some tiny on-screen affordance which takes up screen real estate is a terrible design (except in the special case where the scroll bar is at the extreme edge of the screen).

Mobile web browsers seem to get this right. Touch the element you want to scroll & drag it; an overlay pops up to show your relative location. Intuitive, easy, and doesn't take up screen real estate.

Scroll wheels (especially Kensington's beautiful "Orbit" scroll rings on their trackballs) are pretty close to the mark too.

</comment></comment><comment><USER19> James, great work and thanks for effort to make it even better.

Now for all people that cry about cross browser difference, you ought to put you energy at criticizing developers that create browsers that are not compatible with w3c standards.

I for one do not want to see same boring scrollbars until I die. Let's be realistic, browser scrollbars haven't changed in the past 20 years (except the option to change colors and that was wow back in the day). It's about time that they do.

Oh and, IE should be banned forever :)

</comment><comment><USER20> How am I supposed to know something is scrollable if the scroll bar is hidden unless I'm hovering over it with my mouse? What if I'm using the keyboard?

</comment><comment><USER21> I'm still waiting for a custom scrollbar that reacts to natural scroll speed. This and all other JS based scrollbars scroll much too fast in Safari.

<comment><USER22> too fast? It's waaay too slow in linux firefox.. Horrible

<comment><USER21> Exactly my point. It's inconsistent from browser to browser. It's not tied to the OS in any way.

</comment></comment></comment><comment><USER23> The scroll direction is backwards in IE9.

<comment><USER24> Same on Chrome 16.0.912.41 beta-m

Edit: Just updated to 16.0.912.59 beta-m (newest on this channel), still working in reverse. OS: XP.

</comment></comment><comment><USER3> Hi I'm James. The one who did the plugin. It isn't fully finished yet, it was something I did in my spare time. But I wanted to get it up asap so I could hear people's feedback. Thanks for your inputs so far.

</comment><comment><USER25> I like this attempt better because it works with the arrow keys: <https://github.com/nikolaydyankov/lionbars>

</comment><comment><USER26> This breaks Vimium, it would be nice if it didn't do that.

</comment><comment><USER27> Nicely done. Isn't it going to be better if you hide the scrollbar when you are not actually scrolling? Like Facebook does for their chat and ticker bars.

</comment><comment><USER28> this one has been doing the job for us <http://rocha.la/jQuery-slimScroll>

</comment><comment><USER29> Looks nice, middle button scrolling doesn't work though.

</comment><comment><USER30> fails on IE7 & 8, should fallback to os widgets at least

</comment><comment><USER31> Needs more jQuery.</comment>


A Faster Internet (DNS) - <AUTHOR> http://www.afasterinternet.com/

<comment><AUTHOR> One concern I have is the potential privacy aspect of this.

From the how it works page:

"If using OpenDNS or Google Public DNS, your complete IP address will not be embedded. Instead, the DNS server will only include enough information for the CDN to know your general location. For instance, if your IP address is 22.214.171.124, the DNS server will only expose the first three octets, so 67 – 215 – 80 instead of 67 – 215 – 80 – 23. A reasonable analogy would be only showing the prefix of your phone number in caller ID. If your number was 415-555-1234 then only 415-555-XXXX would appear in the Caller ID. Not enough to identify you, but enough for the receiving party to know the area code and prefix of the caller."

For a Class C, this is just 253 addresses to test which is trivial. Given the disturbing actions of ongoing governmental monitoring in say Iran, I'm not sure if people understand that by adopting the "faster DNS" that they are leaking more information now.

Maybe there should be a way to signal an opt-out.</comment>


Whistleblowers Beware: Apps Like Whisper and Secret Will Rat You Out  - <AUTHOR> http://www.wired.com/2014/05/whistleblowers-beware/

<comment><USER2> I am not a big fan of these apps. The more I use it, the worse I feel as I see what people say about people I care about</comment>


On WebKit Security Updates - <AUTHOR> https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ <comment><USER2> Devices with old WebKit versions are fun. A lot of hacks used for homebrew on the Nintendo 3DS have relied on unpatched WebKit bugs. Vendors never update their WebKit versions, and Nintendo is no exception.

</comment><comment><USER3> Its kind of sad that text and image documents today are so complicated that security vulnerabilities in software that reads them are considered inevitable.

<comment><USER4> Complexity is inevitable. The problem (well, one of the largest problems) is that we have collectively failed to come up with effective mitigations for these basic memory safety issues (other than sandboxing). At best we don't invest enough in effective solutions; at worst we incorrectly convince ourselves that "good programmers" never create exploitable security vulnerabilities.

Just look at the list: [http://webkitgtk.org/security/WSA-2015-0002.html](http://webkitgtk.org/security/WSA-2015-0002.html) "Memory corruption and application crash" appears more times than I can count.

<comment><USER5> Sandboxing is great. Isolate certain functionality in a separate process, sandbox it with OS-provided solutions like seccomp-bpf or capsicum, make it terminate on a violation, design its API to be idempotent so you can just restart the process on failure. Have rlimits on process memory usage. There are technical solutions and development processes to write better, more secure software.

The problem is of course that software has to be designed for this, it's not something that can easily be slapped on as an afterthought. It demands more of the design, and that's not easy to motivate in most organisations. Forcing the developer to take security into consideration would be better, but the root of the problem is that most organisations don't consider security that important, even if they say they do.

<comment><USER6> It'd be much, much nicer if we could just use memory safe languages all the time, everywhere. Sandboxing is ultimately a kludge: a recognition that our tools are so dangerous that failure is not just a possibility but an inevitability. It comes at a huge cost in developer productivity, code complexity and sometimes runtime performance suffers too.

pcwalton works on Rust, I believe. A rendering engine written in a memory-safe style is something humanity just needs to build and I applaud Mozilla in at least starting down that long road with Servo.

That said, HTML5 has sprawled to the point that it appears (to me) essentially unimplementable from scratch unless you are Google, Microsoft or Apple. That seems like a problem. If web servers indicated what HTML features a page they were serving needed, it'd let browsers pick different rendering engines on the fly, but of course ... malicious web pages would simply always ask for the least secure engine. There doesn't seem to be a good workaround for that. It's the downside of trying to force the web into being an app platform.

It's also unclear to me how the balance between safe and unsafe code works out in Rust. Looking at Servo it appears that unsafe code is used all over the place including in very core parts:

[https://github.com/servo/servo/search?utf8=%E2%9C%93&q=unsaf...](https://github.com/servo/servo/search?utf8=%E2%9C%93&q=unsafe+filetype%3Arust&type=Code)

My guess is that Rust's memory model simply requires unsafe code more often than a traditional GCd range checked language does. A part of me wishes the Java guys would hurry up and get value types done already (it's years away), as combined with a lot of the auto-vectorisation optimisations being added at the moment by Intel it feels like at that point a performance competitive rendering engine written in entirely memory safe code would become realistic. Perhaps it even already is, unfortunately none of the above mentioned companies are interested in trying and nobody else can afford HTML5.

This line of thought is how I ended up concluding we need an entirely new mobile code oriented app platform.

<comment><USER4> > Looking at Servo it appears that unsafe code is used all over the place > including in very core parts:

That's a very misleading characterization. It's less than 1% of the code. And it _should_ be in core parts: those are the parts that are carefully audited and the parts that safe abstractions are built around.

We need unsafe primarily for the FFI layer, just as you do in any language. Bindings to a JIT would be no less safe in Java. You just have to write "unsafe" to call FFI functions in Rust, because we want to make it easier to audit that code.

> combined with a lot of the auto-vectorisation optimisations being added at > the moment by Intel it feels like at that point a performance competitive > rendering engine written in entirely memory safe code would become realistic

Any compiler developer will tell you that pinning your hopes on autovectorization is a lost cause. And you need a lot more than SIMD to write a competitive browser engine. (SIMD isn't the reason we write unsafe.) What I'd like to know is how you propose to write a JIT in safe code, without trusting that the JIT is implemented correctly. There _are_ ways to potentially do that in theory (proof carrying code), but they're way beyond anything you've mentioned.

<comment><USER6> It may be less than 1% of the code by lines, but it's a large codebase. My point was that simply searching for the word "unsafe" in the code threw up 21 pages of results. That's not a rarely used feature.

By "core code" I meant the first results are things like layout code, a file called string_list.rs, string_multimap.rs etc. That doesn't sound like stuff at the edges to me.

 _Any compiler developer will tell you that pinning your hopes on autovectorization is a lost cause_

I didn't mean that's the only thing that's needed, I think value types would be by far the biggest needle-mover there. But there's quite a lot of auto- vectorisation going on in the latest JIT compilers, a surprising amount (some of it not released yet).

 _What I 'd like to know is how you propose to write a JIT in safe code, without trusting that the JIT is implemented correctly_

Obviously if you're compiling code, the compiler has to generate safe outputs. But take a look at how the Graal/Truffle frameworks do it. Graal is a JIT compiler implemented entirely in Java. It generates machine code that's then handed off to the JVM for execution. Truffle sits on top and uses aggressive partial evaluation to convert AST interpreters for dynamic scripting languages into JIT compilers automatically. They have a Javascript implementation that's comparable to V8 in speed, and you can interop with it through safe APIs. Again, the entire compiler/JIT stack is written entirely in a safe language: eventually the CPU jumps to the result, but the code itself is all written in a safe way.

<comment><USER4> I wrote the layout code you're talking about. There is no unsafe in the layout algorithms, just in the work-stealing deque and the logic to share DOM nodes over to the layout thread. You can think of both as low-level generic memory management primitives, essentially as a GC. We do _not_ allow the layout logic to be unsafe.

As for string lists and such, those are core collections. Again, those are low-level primitives and relatively easy to prove safe. We should be migrating more of that code to the safe language, but it never causes problems in practice. That's because the "build simple abstractions out of unsafe primitives and keep the complicated code safe" approach _works_. (We have empirical evidence that it works, you know. There are incredibly few segfaults in Servo relative to any other browser engine we've worked on.)

I am convinced that writing in Java would not make the browser any safer. All you'd do is to move some unsafe code from the engine to HotSpot. The only real effect it would have is that the word "unsafe" would not appear as often in the code.

> It generates machine code that's then handed off to the JVM for execution.

And there is absolutely no difference between that and what Servo/SpiderMonkey does, because you're trusting the millions of lines of code in HotSpot. Servo is just being explicit about the lack of safety when touching the JIT.

</comment></comment></comment></comment></comment></comment></comment><comment> ryan-c Many of the obscure WebKit browsers do not validate certificates on subresources, which allows MitM attackers to replace third party scripts with malicious ones. Some of them do this without even any UI indication that there is a problem. I have a test page here: [https://rya.nc/https- script.html](https://rya.nc/https-script.html)

</comment><comment><USER7> "WebKit does have a Linux sandbox, but it's not any good, so it's (rightly) disabled by default."

I'd love to know more about why, that seems mad in 2016.

<comment><USER8> Disabling a broken feature, or not fixing it?

The latter is easily explained: Webkit (especially on Linux) is woefully short of manpower now that Google et. al. have pulled out of it.

I'll call myself lucky if WebkitGTK doesn't crash on any of the Alexa top 100 any more.

<comment><USER9> Just in time for Emacs, XWidget support and Webkit embedded in Emacs then.

And here I thought we'd finally get a quality browser-engine for our OS. Seems we'll have to wait some more :)

<comment><USER8> Chromium Embedded Framework (used by e.g. Qt, Android, and browsers like Vivaldi) is okay, and Servo (Mozilla's new rendering engine in Rust) is aiming to be API compatible to it.

Seems it's where we're headed for now.

</comment></comment></comment></comment><comment><USER10> > Web engines are full of security vulnerabilities, like buffer overflows, > null pointer dereferences, and use-after-frees.

Off-topic to the issue at hand, but I am curious: would Servo[1], the browser engine written in Rust be having lesser (chances of) issues like this? I have written very little Rust, but it seems that the above issues are extremely unlikely to occur with Rust.

[1]: [https://servo.org/](https://servo.org/)

<comment><USER11> Never underestimate what misguided cleverness can do. Heartbleed, the most famous of these issues in the last few years, would have not occurred on systems like OpenBSD, were it not for its developers' quest for optimization in their malloc wrapper.

I've seen buffer overflows in Java, too. It's immune to writing past the end of the arrays, but it's not immune to, say, smart programmers using one large array to hold multiple buffers that they manually manage, because who knows when the GC kicks in and wrecks havoc. Python may be immune to use-after- frees, but the OpenGL bindings that it calls through the FFI aren't.

To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it.

Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is.

<comment><USER12> > and languages like Rust don't make it less likely to err

It doesn't make the person less likely to err overall, but it makes it less likely that those errors get compiled and released.

<comment><USER11> It makes it less likely that _those errors that we 're familiar with from C_ get compiled and released. There's no debate there. It's all those errors that we're _not_ familiar with from C that it won't do anything against.

Not to mention errors stemming from our own arrogance and short-sightedness, which no language can ever protect us against.

<comment><USER13> If it makes it less likely that some errors get out, and doesn't do anything against other errors, then overall it makes it less likely that errors get out.

<comment><USER11> What makes you think that it does not introduce any additional errors?

<comment><USER13> What makes you think that it does?

<comment><USER11> The course of programming so far.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Interesting. I have one major disagreement. This:

"This seems to me like a good reason for application maintainers to carefully test the updates"

Doesn't seem remotely feasible. Every security release should be manually QA'd by the distribution? If they are already worried enough not to take such updates, I doubt they have the manpower to cover everything not covered by integration tests (a lot?).

<comment><USER15> Well, there are 100s of thousands of tests checked into various repos. WebKit has > 45k tests and there are open test suites for many web apis. Of course it's work to get some testing infrastructure setup but once setup it's mostly automated?

I supposed not, it just adds something else that needs to be maintained :P

<comment><USER16> One would hope that whoever committed the patches already ran those tests, so the bugs that get through will mostly be ones that the tests couldn't catch - for example, issues with applications that integrate WebKitGTK+ not functioning properly with the new version. Incidentally, GTK+ as a whole has a terrible record when it comes to backwards-compatibility these days.

And as the post makes clear, the security upgrades doesn't even help that much because the original WebKitGTK+ API isn't receiving them anymore and moving to the new API requires massive changes that distros certainly can't ship in an update to a stable release. Apparently they gave applications "a full year to upgrade", which is shorter than the lifespan of distro releases and not realistic given that it requires upgrading to GTK+ 3 and more major changes on top of that. Just the GTK+ 3 switch alone is a multi-year project for complex software, and not helped by the fact they keep breaking their API in new versions. Case in point: [https://bugzilla.gnome.org/show_bug.cgi?id=757503](https://bugzilla.gnome.org/show_bug.cgi?id=757503)

</comment></comment></comment><comment><USER17> Why is this so bad? Because the WebKit security group doesn't let new members in.

Its a self perpetuating cycle.</comment>


Third Normal Form and Ultimate Truth - <AUTHOR> http://emptysquare.net/blog/third-normal-form-and-ultimate-truth?__utm_source=twitter <comment><USER2> >Data at the scale that the largest websites handle doesn't work that way.

Which accounts for a small minority of databases compared to the whole; ergo, why you find introductory SQL courses structured the way they are.

"Performance" comes in many flavors. Reliability of data is on the top of a lot of company's priority list. It's not the end of the world, the end of someone's job, or the end of someone's service contract if a Facebook user doesn't get a message on time or at all.</comment>


Code Golf site which is able to judge your code in 40 langs  - <AUTHOR> http://www.spoj.pl/SHORTEN

<comment><AUTHOR> The list of available problems is here: <http://www.spoj.pl/SHORTEN/problems/main/></comment>


iPhone Web share hits record 0.48% - <AUTHOR> http://apple20.blogs.fortune.cnn.com/2008/08/31/iphone-web-share-hits-record-048/ <comment><USER2> Browsing the web on the iphone is a very nice experience compared to any other small form factor device I've tried (Palm Pilot Tungsten T3, PSP, other cell phones via WAP, and the Blackberry).

It's the clever use of multi-touch to make a small screen truly a window into a larger 'page' of information that makes the iPhone so good at this.

<comment><USER3> Yep, the experience is very close to what you get on the desktop — especially with the ability to click on anything you want directly. I use it all the time — however, I wish Safari would stop crashing :/

<comment><USER4> It's something that I hope (and trust) Apple will fix. That said, I don't use it very often, so its crashing isn't a constant annoyance. And it's still superior to every other mobile phone.

.48 is pretty impressive after slightly over a year. I'd like to see when and where it peaks.

</comment></comment></comment><comment><USER5> Isn't that like 1/3 the web share of linux...

Wow.

</comment><comment><USER6> What the... why is iPhone traffic share so much higher on Tuesdays and Wednesdays?

</comment><comment><USER7> 58% in a month! I think it's not just the share, but iPhone's increasing a mobile web user population. There's still a small number of people browsing web on mobile. The connection speed on mobile is so slow, and the mobile browser cannot load web pages designed for PC browsers or doesn't provide rich usability for it.

But iPhone user can enjoy browse PC websites everywhere with high speed connection. I think more and more people will use internet on iPhone frequently as they get used to it, and wonder if there'll be some users browsing Internet more on iPhone than PC in the future.</comment>


The Unreasonable Effectiveness of Dynamic Typing for Practical Programs - <AUTHOR> http://games.greggman.com/game/dynamic-typing-static-typing/ <comment><USER3> I used to be a huge dynamic languages fan, with python being my favorite language over the majority of my career. Then I worked on a large python project of ~100k LOC with a team of ten. That's when I realized that writing code faster isn't the problem. Reading it is, making changes to code someone else wrote is, and refactoring across dozens of modules is a problem. Static languages help a lot with all three. I still love dynamic languages for small tasks, but I'd rather use a static language like Go which still keeps much of the dynamic feel, and helps catch my mistakes at compile time. I actually just set it to watch the project directory for changes and recompile automatically in a terminal on another screen (actually to run the unit tests, which includes compiling.) That's constant feedback and comparable to dynamic languages speed for edit-compile-test runs. But the best part is the unit tests. They run so much faster with Go that I don't get distracted waiting for them to finish, and that keeps me in the zone and much more productive.

<comment><USER4> Agreed. I often find that most people who are very enthusiastic about dynamic typing have only seen it in action on solo or small projects.

Add complexity or people and dynamic typing quickly crumbles.

<comment><USER5> I made this point in an earlier comment, but I'm a firm believer that if the speed at which you can physically type code is the bottleneck, then you are going to eventually have much bigger problems. Hastily written code will require more time to fix than it will cost you to slow down and think about a good design, regardless of language.

<comment><USER6> If you can code quickly, then the effort required to refactor previously written bad code is lower. I.e it is not that you can type faster that matters, it is that you can fit more change iterations in the same time frame. And many times multiple change iterations are required because you can't see beforehand whether a particular refactoring will be a net positive or negative.

<comment><USER7> Strongly typed languages beat dynamic languages hands down for refactoring. The ability to know immediately what broke without having to run all your code paths dominates any time savings gained by typing faster.

I'm a fan of strongly typed languages with good type inference (and therefore less typing), but even in verbose languages like Java this is true about refactoring.

</comment></comment></comment></comment></comment><comment><USER8> Having worked with (and sometimes implemented) different flavors of both static and dynamic languages over the course of my 20+ years in programming, I still feel a little guilty about not coming down on one extreme side like most of my colleagues.

I do like the fact that static typing gives me more confidence when refactoring things, and I do appreciate the speedier execution, but at the same time when programming in a dynamic languages I only rarely run into bugs that could have been avoided by a (moderately strict) type system.

To me, the best feature of dynamically-typed languages are dynamic container objects (JS object literals, PHP arrays, Lua tables, Lisp/Scheme lists), because instead of having every single container be a purpose-built one-off abstraction that is often not even completely inspectable, much less extendable, I can just have one standard structure for any data.

In the end though, both paradigms are tools to be used appropriately. While there is a great deal of problems that can be solved with either of them, they clearly each have strengths and weaknesses to be understood within the context of the program's purpose.

<comment><USER9> _To me, the best feature of dynamically-typed languages are dynamic container objects (JS object literals, PHP arrays, Lua tables, Lisp /Scheme lists), because instead of having every single container be a purpose-built one-off abstraction that is often not even completely inspectable, much less extendable, I can just have one standard structure for any data._

This is perfectly possible in static languages as well.

<comment><USER8> It depends on the language and it depends on how it's idiomatically used. In theory, you can make capability claims about most languages interchangeably, but the question is if the language really affords it or not. For example, I would say that Rust's _enum_ gives you a lot of this capability easily, whereas C/C++ usually does not - _union_ s and explicit casting not withstanding. But I do fully acknowledge you could make that claim for almost any language, and be technically correct.

<comment><USER9> Sure. I just mean that if you want to have that feature in your language, static typing will not prevent you.

In practice almost no mainstream static language does this though.

</comment></comment></comment></comment><comment><USER10> Dan Luu covers a ton of literature here[0]. The take away is that all of the major studies are flawed in pretty serious ways. Enough that you can't draw strong conclusions.

[0] [http://danluu.com/empirical-pl/](http://danluu.com/empirical-pl/)

<comment><USER5> The study the OP references (from the original talk) seems suspect to me; in particular, the fact that the researcher created both a static and a dynamic version of his own language. Generalizations about the time required to "get stuff done" in _all_ (or even _most_ ) statically/dynamically typed languages feel unwarranted. And then there are statements like this:

"he found [that] it took less time to find [type] errors than it did to write the type safe code in the first place."

Maybe that's an indication that his homegrown statically typed language was a crappy language, rather than exposing some fundamental truth about statically typed languages in general?

<comment><USER11> > Maybe that's an indication that his homegrown [...] language was a crappy > language, rather than exposing some fundamental truth about [...] languages > in general?

Can you come around and make this same argument any time someone makes a blanket statement about static languages being unconditionally better than dynamic ones?

<comment><USER5> I guess what I was hoping to emphasize is that the number of variables involved in trying to quantify something like this make it difficult (probably impossible) to have an accurate comparison -- even more so when attempting to generalize the results of those comparisons to larger categories of programming languages.

</comment></comment></comment></comment><comment><USER12> This is why I think gradual typing with structural types is the Right Way, and will be what all modern programming languages move towards (like how we don't have to worry about manual memory management anymore).

Javascript with Flow, or TypeScript is a great example of this. Perl6 is using gradual typing.

The key thing is that there are times where you want the inflexibility of static typing, and there are times where you want the benefits of dynamic typing. Structural types also remove dependencies because the function defines the _structure_ of the type it expects, and not a specific reference.

Also, I think github repos (and the person's tests) are heavily heavily bias towards individual projects. There's a massive difference between something only one person works on, and something that an entire team is developing over the course of years (as team members come and go).

<comment><USER13> > benefits of dynamic typing

What, specifically?

<comment><USER12> Speed, specifically when doing some quick prototyping/exploration.

<comment><USER13> Why is a dynamic language quicker for prototyping and exploration?

</comment></comment></comment></comment><comment><USER14> While I appreciate the sentiment of settling debates with data, you have to actually measure the right things. That statistic that says that only 2% of bugs would be prevented by static types? That's based on the assumption that everything that would be a type error in a statically typed language manifests as an exception in Python. But that's obviously not even close to being true. The really annoying bugs that type systems prevent are far more insidious than that. For example Python will happily let you use the greater-than operator on an int and a function. So if you accidentally write `f < 10` instead of `f() < 10`, you will not get a type error, but your program will have a bug that manifests in your program logic going wrong and leading to wrong results somewhere down the line.

I've analysed all bug tickets for a Python system at a previous job for several months, tracking how many of our bugs would have been prevented by a Haskell-style type system. This isn't very scientific either, but for my sample it was somewhere between 70%-90% depending on your interpretation. I'm not saying this generalises to all projects, but I can definitely say that the 2%-number is hilariously wrong.

</comment><comment><USER15> I would think that the increased productivity of Python over C++ has more to do with Python being a higher level language than static typing per-se.

I'm translating some Python into C++ right now for performance reasons. Manual memory management, lack of list comprehensions, and many other things are making it slower to write than the Python was but having to specify types is really the least of it. The extra visual noise often makes the code less readable but that isn't true of all static languages.

</comment><comment><USER16> It's good to see hard data on this. I hope more people will publish similar research in the future. I've done a lot of work with both statically and dynamically typed languages and I've always known that dynamically languages were more productive.

I've often made comments on HN suggesting my preference for dynamically typed languages and these comments often got downvoted - This surprised me because I thought that my view was the consensus.

To be fair, I think the rise of the web and in particular of the JSON format for APIs and the use of typeless NoSQL databases have favored dynamically typed languages. JSON objects have no type, so when you write statically typed code, you have to add logic to cast everything into concrete types instead of accepting the data as provided. If you use a NoSQL database, you will get dynamic typing in the storage layer as well so you won't have to worry about types anymore... In such a scenario, you can enforce the consistency of various parts of your data as much or as little as you like.

<comment><USER17> I believe that dynamic languages make initial development faster, and maintenance more expensive. In particular with static types it is much easier to launch into a refactor and depend on the type system to tell you about dependencies that you forgot about. Similar refactors are scarier.

That said, I personally prefer working in dynamic languages. It is more fun for me. But I don't think it is necessarily the right choice for all employers.

</comment></comment><comment><USER18> This seems littered with potential fallacies to me, but I'm only basing that off the summary of the video. It isn't really useful to lump all statically- typed languages into one bucket since some have confusing compiler messages and some don't. Same with counting "type errors" of dynamic languages, it seems the definition of "type errors" would entirely depend on how exhaustive the hypothetical static type system would be. Also, it's kind of weird (and I've seen this before from other dynamic type enthusiasts) to imply that unit tests are only for dynamically typed code - we use them in statically-typed languages too!

I generally hold the point of view that dynamically typed languages are great for prototyping and when you are in the "build fast and break stuff" phase, and that statically typed languages are better for when correctness and maintenance matter more. It's generally mapped my career path as I've moved from being a freelancer for small clients to a contractor/consultant for large clients. One basic indication for when you might want to consider pulling more statically-typed languages into your stack is when you start running into those really confusing run-time bugs/behaviors that are really hard to track down.

<comment><USER19> Entirely anecdotally, I found that in the same amount of time I can write down more functionality in a (toy) Haskell program than in a (toy) Python program. Partly this is because finding trivial errors becomes easier (despite cryptic compiler messages), partly because the language and standard library often let you express algorithms in fewer words. (Due to this, without a strict type system and type inference, Haskell code would likely become brittle far faster than Python code.)

<comment><USER18> It's a good point because I think a lot of the static-vs-dynamic typing discussion gets confused by the functional-vs-imperative discussion.

</comment></comment></comment><comment><USER20> This 'Unreasonable Effectiveness' naming scheme has really started to be abused, ha? I mean this really just points out that dynamic languages are somewhat faster to work with than static languages - hardly 'Unreasonable'. I think as a rule large project/codebase -> static typing is nice, but for fast scripting/problem solving dynamic is clearly the way to go (hardly original). I don't think the cited data here provides a good argument against that - <USER2> study involved a quick problem (several hours), and the bug breakdown does not convince me that having type checking does not prevent many bugs in the long term. The final point about anti-modularity is just weird given OOP and all. Still, some interesting data.

<comment><USER21> Unreasonable Effectiveness Considered Harmful.

</comment></comment><comment><USER22> Good to see some effort put into making a case in the debate (for either side). I drank the Haskell koolaid pretty hard a few years back, and I wanted to believe that all the anecdotes people used to support the language had to be true. You're more productive because of all the compiler can do for you, you're safer, you're more correct, etc... My experience after some time was that significant effort was spent with me serving the type system, rather than it serving me. The article's statements are in line with the lessons I've learned, and I'm not going to feel bad about throwing about such an anecdote around on a message board...but more to the point, I feel GOOd that some people are taking strides to make this conversation less anecdotal.

</comment><comment><USER23> That first datapoint... at worst, programs took 60000 seconds to write. That's 1000 minutes. That's just under 17 hours, or two days. In that time, it took less time for the programmer to catch type errors than for the programmer to write the static typing to catch the errors. I can buy that.

Now make the code base 10,000,000 lines. Maintain it for two decades with dozens of programmers. Now how relevant is that 2-days-at-the-worst datapoint?

</comment><comment><USER24> He's doing experiments with programming in the small, probably with students as subjects. Not useful. Typing is most valuable for enforcing consistency within large programs, or between software components from different sources, where a change in one part may break other parts. If he wants to experiment with this, he should have groups of three or four students independently write parts of a program, then integrate them.

There's convergence on when to declare types. As I mentioned in a previous post, the trend is toward declaring function parameter types, but inferring the types of local variables. Go and Rust take this route. C++ now supports it with "auto". Even Python is considering adding optional function parameter type declarations.

<comment><USER25> Inferred types are still considered static in most cases

</comment></comment><comment><USER26> I would love to get a report from someone with a lot of Erlang experience.

Erlang is a great example of an industry oriented dynamically typed programming language.

But... they recently, maybe more 5 years ago now, went to a lot of trouble to integrate a really nice static type system into it. They also had a type analyser, dialyser, for a long time before that.

The impression I had was that some significant number of people experienced some dynamic typing pain and a lot of effort was put into reducing this by strengthening the type system.

I am just a part time Erlang hacker, so I will keep out of this debate. But I would love to hear from anyone who experienced this in a professional development environment.

</comment><comment><USER27> I know everyone has their preference here so it doesn't help to just talk about anecdotes.

That said, the author really doesn't seem to take note of the largest benefit of type safety: Self-documentation.

Looking at someone else's source code with type hints gives you so much more of an idea of what's going on and what sorts of parameters any given function might take. With static types, that documentation is guaranteed to be right.

Dynamic languages also encourage the use of clever reflection in ways that make your code unreadable to someone who has limited scope of context.

For me, I'd rather be using a lib created in a static language.

</comment><comment><USER28> I'm glad to see this... I've felt for many years now that I'm far more productive in dynamic languages than static ones. I always really liked C#, but since I started using node.js more, I find I get a lot more done, when I use modules and functional patterns, I tend to avoid a lot of the bugs I get in C#/Java with simpler code that's easier to understand... Unit tests become only slightly more interesting as I have to use proxyquire to override the request system for the module I'm testing, but in the end the actual code is easier to reason with. Also, DI/IoC is mostly un-necessary, which is a huge painful issue when debugging .Net code (and would presume Java is similar).

It does take a bit of discipline to keep things smaller/modular and not do too much in any single file/module.. but overall the code comes out more reliably. It works very well for front end systems, and direct services they work with... farther back, using another systems language may be a better option.

</comment><comment><USER23> > Another point he made is that writing static types is often gross and > unmaintainable whereas writing unit tests not.

I suppose they _can_ become "gross and unmaintainable", if you do it badly. And I'm sure some people do it badly, but... really? That sounds like someone didn't know how to use static types. (Yeah, I know, No True Scotsman...)

</comment><comment><USER29> I was about to comment about my personal experience, but realized the irony before posting. I won't say I'm convinced either way, but it's great to see some data enter the conversation.

<comment><USER30> Your irony meter is more sensitive than a large number of commenters who's responses are variants of "no, because... anecdote!"

I agree, it is interesting to see data, though I struggle to design a study in my head for how to really show this either way. But... anecdote... it does amuse me how various languages claim to improve development time/safety/bug rates/cost, (OOP, Types, Functional, etc). But these big claims are not quite born out by companies investing in those languages wiping the floor with their competitors. If there really was a significant difference, I'd expect evolution to take its course.

<comment><USER31> Attempting to argue with ideology is a self-defeating proposition.

In the presence of 'belief' there is no room for reason.

Which reminds me. I haven't seen Dogma in a while. Metatron is also one of my favorite roles played by alan Rickman. I guess I found my plans for this evening.

</comment></comment></comment><comment><USER9> One of his slides says that C++ and Java is equally productive, but less productive than C. Are we supposed to believe that OO is a net negative but automatic memory management makes no difference?

</comment><comment><USER32> Did his statically typed language include reasonable type inference? Because if not, then of course it took longer to write static types.

If so, then, well, that's interesting. I'm not sure I'm ready to take the training wheels off for myself, but maybe worth some thought?

<comment><USER33> The earlier parts of the talk generalize out to advanced languages like F#, Ocaml. but the "data" part of the talk assume static languages are completely represented by C++, Java and C#. It was pretty disappointing.

</comment></comment><comment><USER34> I've been a lot of programming in both lately (Clojure and Objective-C), and did a ton of Java earlier in my career, and I find I like both. The biggest pain point for me in Clojure is the inability to easily refactor.

To overcome the limitation that the machine can't help as much when using a dynamic language, I've found that writing good unit tests with solid coverage gets me pretty far, and shortens the feedback loop when I break something.

But yeah, I sure do miss the right-click and 'rename' feature from Eclipse and Xcode when writing Clojure.

</comment><comment><USER35> I've used both dynamic and statically typed languges, and also dabbled in some of the more flexible static languages like Haskell and Scala. While I personally prefer statically typed languages, I find Perl 6's gradual typing to take an interesting approach. Perl 6's type checker operates differently on functions and methods: functions, roles, and private methods are checked at compile time, but public methods are checked at run time. As Jonathan Worthington wrote in a presentation on Perl 6's approach, lexical scoping is "your language" but a public method call is "the object's language": "it's for the receiving object to decide how to dispatch the method," which might be familiar to people who have used Smalltalk. This approach also allows easy interoperability with libraries from dynamic languages, such as using Perl 5 or Python code in Perl 6.

I'm very interested to see how this approach works out in practice. Slides for Jonathan's "Getting Beyond Static vs Dynamic" can be found here: [http://jnthn.net/papers/2015-fosdem-static- dynamic.pdf](http://jnthn.net/papers/2015-fosdem-static-dynamic.pdf)

</comment><comment><USER36> Are we really still referring to Prechelt's work 16 years later (more really, it took that group a long time to assemble their data)?

[https://page.mi.fu- berlin.de/prechelt/Biblio/jccpprt_compute...](https://page.mi.fu- berlin.de/prechelt/Biblio/jccpprt_computer2000.pdf)

This study has been cited over and over despite nearly universal criticism for stacking the deck in favor of dynamic typing.

</comment><comment><USER37> (working full-time on JavaScript code for last 4 years)

TL;DR good dynamic codebase is possible, but not when you throw _too many devs_ at it (particularly _junior devs_ ) and only when you set the very high quality bars. Otherwise, in finite time the codebase will converge to a big pile of mess.

IMO the big dynamic-language codebase with multiple people working on it can only survive with extensive test suite, lots of mock data available, automated quality tooling (jshint etc) and proper code review in place. All of those are well-known best practices, but they require good developers and certain discipline.

In particular, when the app retrieves lots of data from a server, it's easy to get lost when the frontend app doesn't even know what data it operates on, it just knows it gets "some JSON". In old-school java world you'd have this mapped into a bean and you'd at least know what you work on.

Previous project I worked on was an inherited poor JS codebase with lots of unrefactorable magic happening inside, multiple event buses and what not. Since JS is a very dynamic and very permissive language, someone can abuse some language constructs to make it very hard to reason about the code.

In a pathological extreme you may get "everything is an object" codebase but no idea what keys each object has. Bonus points if the code is passing some JSON around and adding some keys to that object in an ad-hoc manner, scattered along many functions. No tests and no mocks meant that to learn that, you'd have to run the app and put breakpoints. But, the same variable might have had totally different type of data inside depending on how some if-elses executed. Most of our bugs were due to some objects not having some keys (sometimes) for some reason etc.

<comment><USER31> So, if you want to slice off an object and name it just use ES6 classes.

        class NameMe {
          constructor (obj) {
            for (var prop in obj) this[prop] = obj[prop];
          }
        }

This literally just spits out a named object with an identical structure to the object it's being created with.

If you want to make all keys visible and guarantee no exceptions are thrown when a key isn't set, just define default values.

        class NameMe {
          string = '';
          number = 0;
          bool = false;
          array = [];
          object = {};

          constructor (obj) {
            for (var prop in obj) this[prop] = obj[prop];
          }
        }

You could always _gasp_ initialize everything to null if you're concerned about the defaults screwing up application logic. That's how static type systems address initialization by default anyway.

Want to enforce specific types? Add setter methods that include validation checks. Do I need to continue?

None of these characteristics are difficult to define in Javascript. Structuring data in a manner that's easy to reason about is no more difficult in Javascript than it is in any typed language. Even before the introduction of classes you could achieve the same using prototypes.

If the code you've encountered was difficult to reason about, it's because the devs who wrote it suck at writing code that's easy to reason about. Self- documenting code is a naming problem not a type theory problem.

Any code base, whether static or dynamic should contain an extensive collection of mock data and unit tests to verify common cases and check for breaking edge cases. Unless the project is a one-off fire-and-forget implementation. In which case; who cares, maintenance is somebody else's problem (I'm not stating this is a good ides, just what usually happens in practice).

\----

Bonus: How about a couple of cases that 'literally can't even' be done in statically typed OOP languages.

Extending existing objects:

Sure, you can use object inheritance but that requires explicitly defining a class that represents the new structure. Except that now creates a deeply coupled relationship between the child and parent classes. Which will inevitably become a maintenance issue if the business logic ever changes. Say hello to technical debt.

Proof: Why do all of the collection classes in Java inherit from vector?

You can accomplish the same in JS in any object (class based or not) using .extend() (provided by most 3rd party frameworks). Which essentially does a deep copy of all the object properties. No deep coupling between objects, no technical debt incurred.

Multiple Inheritance:

I'm surprised nobody in the OOP community talks about this anymore.

Since OOP relationships between objects only point to the external interfaces (ie class definition) rather than reference the underlying data, there needs to be a system to represent those relationships.

Multiple inheritance was cast off as not technically feasible due to the possibility of users creating circular references. Ala 'the diamond problem.'

The solution. Branch everything off of a central 'god object' and represent all relationships between classes as a directed acyclic graph.

This is an artificial constraint that only applies to OOP. That not only makes it unnecessarily painful to reason about the structure of class definitions, but it makes it impossible to pass data to adjacent leaves in the DAG without some form of external global state (ie the singleton pattern).

In JS it's very easy to use multiple inheritance. Just create an object and add data from as many other objects as you want using .bind(). Done with an object but still need to maintain it's state? return a new function that maintains a reference to it's enclosing function. Ie use it as a closure.

Stop for a second to consider. The .bind() method, which is crucial to adding functional-like aspects to an imperative programming language, is physically not possible in OOP. The closest equivalent is to pass in ref/out params as arguments into the constructor (ie creating more deep links to external classes).

</comment></comment><comment><USER38> My personal experience with a large project which I started in Python and later moved to Haskell: I did indeed get things done quickly in Python and had majority of the problem solved. Then I had few nasty bugs which made me change/refactor the code and thats where my problem started. I quickly realized refactoring a huge codebase in Python was really difficult. Maybe there is a better way to organize my python code, I do not know. Then I moved to Haskell (partly because of the excellent Parsec library which made things very simpler compared to the yacc style PLY I was using in Python). Initially, the fix-compile-execute cycle was really painful, but I soon realized how I could figure out some functional bugs (not type bugs) just by reasoning about the types. The compiler too helped in some cases with valid type conversion errors. I would have caught such issues in python only if I had a very large test suite which covers this corner case. Nevertheless, I am happy with the move and my love for static typing is only going up everyday.

</comment><comment><USER39> I wonder if the results would be the same had they compared a more advanced statically typed language with type inference like an ML or even go.

<comment><USER32> I just (more or less) duplicated your comment somewhere...jinx.

</comment></comment><comment><USER5> A lot of points being made seem to focus on how quickly one is able to write code, and how dynamically typed languages are better since "you can write code faster!". If the speed at which you are physically able to write your code is the bottleneck , you are going to have problems regardless of whether your language is dynamically typed or statically typed.

</comment><comment><USER40> Does he mention performance? (I havent watched the whole video) That would be the biggest reason to go for C++, say, for me, as a game programmer. Also (once again) this is a very webapp developer orienteted talk, stuff like "stringly typed programming" and "all we do is put string in http requests" ignores all non webapp devs.

</comment><comment><USER41> This does not take into account the fact that IDEs provide massive amount of help for statically typed languages and marginal to no help for dynamically typed ones.

For instance, every IDE I have tried fails miserably on Python. Javascript is even worse, even with a very smart tool like Idea.

</comment><comment><USER42> Interesting - the primary point that devs spend more time with the type- safetyness than they would fixing the few type bugs they'd have made matches my impressions.

That said, when it comes to tests there are definitely times I miss having strong typing.

I recall one poster several years ago remarking with surprise when he discovered that not everyone agreed with him on what was most important to optimize: dev time or run time.

In my world, devs are massively overworked/overneeded, so anything to reduce dev time that doesn't cripple the product sounds like a good thing. Different markets will have different needs, but I've found a number of devs that consider run time vastly more important regardless of market.

</comment><comment><USER43> Lies, damned lies, and statistics.

If you want to argue that most hip dynamic languages will allow faster development than most hip static languages in many situations? Sure, I'll buy that. E.g. jumping from C++ to Ruby for a bit was, for many of the projects I worked on, a major productivity boost.

But I buy it because it's got enough weasel words, and it's focused on the languages in practice rather than the actual language attribute. Because I can think of clear and concrete examples where adding static typing helped: E.g. using Typescript to add static typing information to existing Javascript. This massively improved my speed in picking up new APIs via judicious abuse of Intellisense. And typescript as I'm using it is doing very little more than just adding static type information - much closer to purely comparing static vs dynamic typing than any combination of languages I can spot on these charts.

The article's statistics doesn't measure the productivity difference of static typing vs dynamic typing - it measures _certain statically typed languages_ vs _certain dynamically typed languages_ (among a million other caveats.) C++ vs Python? The biggest difference there isn't static vs dynamic - the former is weighed down by some of the most cumbersome explicit type annotation in existence (when explicit type info isn't fundamental to static typing at all). Worse, it has the nastiest grammar causing horrible build times, an absolutely insane dependency system, and a standard so absolutely rife with implementation defined, unspecified, and undefined behavior that it doesn't even define the size of it's common integer types. And I've yet to meet a C++ codebase that doesn't use it's common integer types.

The article also dismisses type errors too lightly, IMO. "Out of 670,000 issues only 3 percent were type errors (errors a static typed language would have caught)". But does this include such things as SQL injections, where SQL Data was mistakenly treated as SQL Commands? While most APIs don't leverage the type system to differentiate these in a way that will cause errors (be it at runtime _or_ build time), I do consider this a type error, one that _could_ be caught with type system. Unfortunately, handling the single vanilla string type you typically get tends to take precedence over creating such a type separation...

</comment><comment><USER4> > People believe static typing catches bugs. People believe static typing > helps document code. People believe static typing makes IDEs work better and > therefore save time, etc. BUT … those are all just beliefs not backed up by > any data

Yeah... no. It's backed up by data. Mathematics, even.

Types enable safe automatic refactorings. Without types, refactorings can break your code if not supervised by humans.

<comment><USER44> It's not that it can make just IDEs 'work better'. The compiler can work better with a great static type system. Haskell, for instance, is mind blowing.

Perhaps the problem is that static typing is confused with how some languages implement it. It can, and has, been implemented such that it dramatically improves compilation, correctness, static analysis and documentation without making code horrendously verbose.

<comment><USER45> > Haskell, for instance, is mind blowing.

Mind blowing is the amount of output and obscurity of the error message you get from the type checker. It's harder to understand the error message than to debug the program if compiled "unsafely".

<comment><USER46> It's a threshold I guess. My formal proof teacher said he thinks in type checking unification all the time. To him a program is a proof tree construction.

With time the way I approach code is also much more and abstract. You look at diagonal invariants more than code itself.

</comment></comment></comment></comment><comment><USER47> Considering the examples use C,C++,Java as the statically typed languages didn't impress me. There are far better languages. Also, performance of the solution will be worse in dynamic languages.

</comment><comment><USER48> > This first slide is from a research paper where the researcher wrote his own > language and make both a statically typed and dynamically typed version then > got a bunch of people to solve programming problems in it. The results were > that the people using the dynamic version of the language got stuff done > much quicker.

Does this first plot control for notions of quality and extensibility of the different solutions? A faster-to-develop but sloppier solution in a dynamic language which requires more painful investment to refactor for future use cases should not necessarily be viewed as better. If you are only saving short term time at the expense of much more long-term time, then whether it is a net win for you depends on your discount function.

> What was most interesting was that he tracked how much time was spent > debugging type errors. In other words errors that the statically typed > language would have caught. What he found was it took less time to find > those errors than it did to write the type safe code in the first place.

For which developers, and with what level of experience with static typing? This was true for me 3 months after I started learning Haskell. Now I have > 8 years of Python experience and less than 2 years experience with Haskell and the type system demonstrably speeds me up. Way, way faster to use Haskell's type system first than to use Python's type system and trace backs to debug type errors later. (I still like and use Python a lot -- just sayin.)

> The guy giving the talk, Robert Smallshire, did his own research where he > scanned github, 1.7 million repos, 3.6 million issue to get some data. What > he found was that there were very few type error based issues for dynamic > languages.

> So for example take python. Out of 670,000 issues only 3 percent were type > errors (errors a static typed language would have caught)

This strikes me as one of the most problematic parts of the post. To me this just seems to be evidence that in Python, at least, TypeError is more common when you are using something interactively, and you can resolve the issue for yourself (because it generally directly means _you_ are using it wrong, and it's _not_ the library's fault).

This also resonates with my experience with Pandas on GitHub. Early on there was a lot of TypeError stuff with index-related issues, but once the bulk of that work became mature, index errors were then a signal of a novice user who needed to change the user code, and not at all an indication of a library problem worthy of opening a GitHub issue.

It seems totally reasonable to me to hypothesize that the types of problems worthy of becoming GitHub issues are not usually TypeError. But TypeError might still be a huge proportion of all of the errors encountered out in the wild.

Further, there's also some selection effects here for users who actually post things to GitHub. When I worked in quant finance, and everything was in Python, it was an hourly occurrence for hugely important parts of the system to hit type errors, and they were all incredibly painful to fix in the legacy code. This was just accepted as a way of life, and because the invest staff weren't incentivized to care much about code, they usually just hacked their own work arounds, and would never have dreamt of actually opening a GitHub issue about type errors (that would be way too slow of a dev cycle for them, which is why the state of the code was so poor in the first place!)

> His point there is that all that static boilerplate you write to make a > statically typed language happy, all of it is only catching 2% of your bugs.

This is absolutely false and not a valid generalization of the presented data. For one, a major claim of static typing proponents is that by writing with static typing, it eliminates bugs from ever being introduced, and allows you to use a compiler workflow to verifiably remove entire classes of bugs. When you run some bit of Python and it does not produce a TypeError -- that doesn't mean the code is free of errors. It might just mean you got lucky that the data or the user selections or whatever didn't happen to hit the TypeError corner case. With a static language, you _know_ that certain classes of errors are not even possible -- not just that they didn't happen to occur this one time, but that they _cannot_ occur. This is _very_ different.

Further, another claim of static typing proponents is that the _design process_ of code with static also leads to fewer bugs because the mandate for static types forces you to clarify befuddled design ideas before the program will work. The benefit of this is murkier, for sure, but it's still something that can't be addressed by this particular data.

> Some other study compared reliability across languages and found no > significant differences. In other words neither static nor dynamic languages > did better at reliability.

It's interesting to me that that chart doesn't include any functional languages. Let's try it again with a pure functional language and see, and then also compare, say, Clojure with Haskell. If it keeps on robustly bearing out the same trend, then I might start to question my current beliefs on defect rates in dynamic, imperative languages.

> Part of that was reflected in size of code. Dynamic languages need less > code.

This again is relative to the ability of a developer and also relative to different types of tasks. However, it's not really fair to compare languages like C, where brevity of syntax was not too big of a language design priority, with a language like Python, where brevity of syntax is sometimes militant (just try talking with "Pythonistas" on Stack Overflow about why one-liner- ness is really not that useful). And also, at least part of the result is fixed for you: static typing at the very least requires the extra type annotations -- although here again you could try against something like Haskell where you have very powerful type inference. I would be extremely surprised if, for equivalently experienced developers, Haskell programs were not consistently shorter than Python programs.

> He points out for example when he's in python he misses the auto completion > and yet he's still more productive in python than C#

Try Jedi in emacs (or whatever the equivalent must be in vim). Although, I for one hate IDEs (get off my lawn) and I also hate autocompletion and editor utilities that jump to function or class definitions. I've never noticed a significant speed up from these, except possibly when I am merely reading code from a large codebase that is brand new to me. But I have often experienced huge slowdowns from the features getting in my way.

> Another point he made is that writing static types is often gross and > unmaintainable whereas writing unit tests not.

See Haskell. Also, writing unit tests can be a nightmare in OO and imperative settings, where you need some inscrutable cascade of mocked architecture to be able to test things. This is where something like Haskell's QuickCheck can make life a lot easier. I'm sure you could cook up something like that in Python too. But I strongly believe that writing unit tests in Python is way uglier and more frustrating than writing type annotations in Haskell.

<comment><USER48> continued ...

> Static types are also anti-modular. You have some library that exports say a > Person (name, age ..). Any code that uses that data needs to see the > definition for Person. They're now tightly coupled. I'm probably not > explaining this point well. Watch the video around 48:20.

This seems just wrong to me. You can declare structs as static in C and provide public helper functions that internally create data types, apply other static functions to them, and the produce results from them. In Haskell, it's very common to avoid exporting value constructors for data types, and to instead provide helper functions that allow for the implementations to remain hidden from anyone using the module. Modularity really has nothing at all to do with the dynamic vs. static typing debate.

I'll also throw one more downside of dynamic typing into the ring -- you sometimes will see really poor attempts to use so-called "defensive programming." In Python this is an especially bad code smell -- you'll see a huge block of assert statements right at the top of a function definition, in which all kinds of type properties and invariants of the arguments are asserted, so that TypeError can be raised immediately.

For one, in a dynamic typing setting, it's probably better if that stuff is the burden of the caller rather than the callee, in the spirit of a function "doing one thing and doing it well" it shouldn't also have to carry around all of its own type and invariant assertions. Notice that in a static language though, this isn't a problem and even is a huge benefit because it doesn't require the huge, human-error-laden block of asserts to achieve it. Just a nice, simple static typing annotation and then the _compiler_ will deal with it.

Related to this, and as a final point, we should also need to give more "severity" to dynamic typing exceptions that occur at run time due to type errors. For example, in the financial job I mentioned before, it would be common place for an analyst to submit a very large batch processing job to the internal job manager. Some of these jobs took > 48 hours to compute and the output would mutate databases and so on.

So when someone set it running on Friday evening and expected there to be results in a database on Monday, imagine how awful it was to see that a TypeError had occurred and that not only did your manually created assertions fail to capture it, but also, there was no way of proving it couldn't happen without just running your code -- so you burnt maybe 30 hours of computational effort just to be told that upon hitting a certain point in the code, here's a TypeError.

This kind of error, which is categorically eliminated from possibility in a well-written static language program, should count for way, way more than a simple and stupid "oh I tried to call the API function with a list instead of a tuple, whoops my bad, let me just arrow-up in IPython and do it again" Type Error (though it's not clear to me that several of the referenced data in the post would make this distinction or penalize these types of errors more).

<comment><USER11> > You can declare structs as static in C and provide public helper functions > that internally create data types, apply other static functions to them, and > the produce results from them.

You can do that, with training and careful effort. But it was a design flaw that you have to do it manually, and that it isn't mandatory and trivial for even beginners to do. At the time C was "designed," this wasn't necessarily known to be important. We have no excuse today. But languages which do this wrong by default are still popular.

> In Haskell, it's very common to avoid exporting value constructors for data > types, and to instead provide helper functions that allow for the > implementations to remain hidden from anyone using the module.

In general, if calls require knowledge of type information at the call site, and the type needs to change for any reason (which becomes more likely as type annotation reaches further into program semantics) then all the call sites will need to be updated, or there will be an error. In any published library, this means backward compatibility is completely broken and everyone else's code needs to change.

This is a misdesign in C and in a number of "statically typed" languages which crib from it.

> you'll see a huge block of assert statements right at the top of a function > definition,

I almost never see this. The only time I see it is when a dogmatic true believer in the ideology of static typing writes Python. People can do stupid things in any language.

> this isn't a problem and even is a huge benefit because it doesn't require > the huge, human-error-laden block of asserts to achieve it.

Humans are still required to provide type information, which means they can still make errors. Even better, correcting these errors often affects the interface at call sites, which means the fix has to break backward compatibility.

> so you burnt maybe 30 hours of computational effort just to be told that > upon hitting a certain point in the code, here's a TypeError.

You were not reasoning correctly about your code. Proper testing should have been your safety net, but you weren't testing properly. If you are even vaguely trained and you are even vaguely trying, writing code which emits TypeError in production takes some doing.

The number of shops which never have problems in production is vanishingly small in ANY language.

It sounds to me like you got started in Python, and are identifying beginner's mistakes with the language itself.

<comment><USER48> > In general, if calls require knowledge of type information at the call site, > and the type needs to change for any reason (which becomes more likely as > type annotation reaches further into program semantics) then all the call > sites will need to be updated, or there will be an error. In any published > library, this means backward compatibility is completely broken and everyone > else's code needs to change.

Notice I said you avoid exporting the _value_ constructors. You're still free to export or not export the data type itself as you wish, allowing users to reference the type in type annotations while still not letting them ever construct their own value of the type except through helper functions.

This achieves even better modularity, because then in the implementation file, you can change what happens with the _value_ constructors however you want, and you can service backward compatibility to your heart's content without ever requiring the _users_ of the data type to even be aware that anything is changing.

Maybe you are referring to something else, but I am referring to data type and value constructors in Haskell. The data type itself is a distinct semantic construct in Haskell from the constructors of values of that data type, and they can have different privacy properties.

> I almost never see this.

Well, I've seen it over and over in production critical code in three different organizations ... so our anecdotes disagree.

> Humans are still required to provide type information, which means they can > still make errors. Even better, correcting these errors often affects the > interface at call sites, which means the fix has to break backward > compatibility.

It depends on the language. In Haskell for example, you could just make a type union, one for allowing passage of the old-style interface and one for the new, corrected version. It's very easy to do, still has the upsides of type checking, and doesn't break backward compatibility.

> You were not reasoning correctly about your code. Proper testing should have > been your safety net,

Except you missed the relevant test case, whereas a tool like QuickCheck would have had a better shot at discovering a corner case that humans couldn't have anticipated.

> It sounds to me like you got started in Python, and are identifying > beginner's mistakes with the language itself.

I'm not sure what you're referring to. The code I was working with was written by a mix of many Python developers. Some were core committers to the Python language itself; some were data analysts who didn't want to be programming.

I can say that I haven't had significant front-end experience in Python. But I've touched a lot of most other major areas, particularly in very low-level NumPy code, LLVM stuff with both Numba and llvmlite, pandas, Excel tools, and many different database technologies and ORMs.

I will say though, that in the projects where we switched from pure Python over to statically-typed Cython, it cleared up tons and tons of our issues, many of them almost over night.

Rather than me finding beginner mistakes in Python, it seems to me like you worked on one single system that suffered a lot of issues with backward compatibility, and you're generalizing that backward compatibility experience to other areas where you're less familiar (like solving the same backward compatibility stuff in Haskell).</comment></comment></comment></comment>


How do avatars have sex? - <AUTHOR> http://news.bbc.co.uk/2/hi/uk_news/magazine/7729207.stm

<comment><USER2> by putting on a robe and wizard hat?</comment>


A pill to dampen memories stirs hope and worry - <AUTHOR> http://nautil.us/issue/15/turbulence/if-trauma-victims-forget-what-is-lost-to-society?utm_source=tss&utm_medium=desktop&utm_campaign=linkfrom

<comment><USER2> That's how Wool (the post-apocalyptic novel) starts...

</comment><comment><USER3> Beta blockers are also used by some performing musicians to dampen their nerves.

[http://ethanwiner.com/betablox.html](http://ethanwiner.com/betablox.html)

</comment><comment><USER4> So it does what alcohol has been used to accomplish for centuries, except maybe there's a trade-off in certain side effects?

<comment><USER5> There were a couple of articles just few days ago how alcohol may actually improve memory. Blackouts are different matter but they affect short term memory only anyway.

<comment><USER6> May help with memory 'may' being key and only low amounts with low alcohol content of 2.5% and so far only it's only been studied using rats.

People who drink regularly drink too much alcohol and people who rarely or don't drink won't drink enough since the study said it had to be every day at low amounts.

</comment></comment></comment><comment><USER7> Gleemonex

</comment><comment><USER8> So its dronabinol?</comment>