Mailpile: Email that protects your privacy - <AUTHOR> http://www.mailpile.is/ <comment><USER2> So this is a mail _client_ that by default deletes all the messages off of the mail server. So your privacy is still dictated by the mail server you choose to use, and then also your data integrity is 100% on you.

I'm not sure I understand how this improves privacy. It also makes things worse by making your email data more susceptible to being lost (which is different than protecting your privacy).

<comment><USER3> Unless your adversary has a time machine, deleting from the server protects your past e-mails from any server-side compromise.

That's not nothing. :-)

But you're right there are trade-offs. If you don't have good backups, you are indeed increasing the odds of data loss by managing the data yourself. That is also true of encryption of data at rest, you are increasing the odds of data loss to buy some protection against unauthorized access. There are always trade-offs.

I had grand visions for how Mailpile could help mitigate such issues by encrypting the mail and re-uploading back to an IMAP server. But I haven't gotten that written, so for now it's just an idea. Someday, I hope.

Disclaimer: I wrote Mailpile. :-D

<comment><USER3> To expand on this slightly, and illustrate:

I'm going to go out on a limb, and assert that THE most common attack performed against peoples' e-mail, is a jealous person who knows their partner's password logging on to their e-mail and reading their mail.

I know people who have done this. You probably do too.

People trust each other, people routinely tell their loved ones their passwords. And relationships routinely fall apart and trust is routinely violated.

Deleting from the server mitigates this problem and greatly reduces the window of opportunity for the attacker.

The privacy cost/benefit ratio for routinely deleting from the server probably beats every other privacy enhancing technique out there. Super simple, super effective.

Techies too often forget that privacy isn't just about the NSA, APTs and TLAs. The fact is, the people most interested in violating your privacy are the people who know you personally...

</comment></comment></comment><comment><USER4> This doesn't appear to support read receipt privacy, which is when the mail server caches tracking images on-delivery instead of on-read.

I shouldn't have to expose my email viewing habits just to get auto-displaying images in my email client.

<comment><USER3> That's an interesting idea.

I'd hesitate to implement it though, because of secondary risks. It would need to be thought through very carefully, and there are a whole bunch of abuse scenarios that would need to be avoided or mitigated.

As a rule, Mailpile does very little when it receives a mail - until the user has interacted with it, we have to assume the mail is junk and/or potentially hostile.

See the chapter on Oracles here: [https://research.checkpoint.com/cryptographic-attacks-a- guid...](https://research.checkpoint.com/cryptographic-attacks-a-guide-for- the-perplexed/) \- automatically triggering sender-controlled network access based on the contents of e-mail opens the door for such things.

This applies not only to cryptographic attacks, but also to more pedestrian exploitation of bugs in the app itself, or silly things like turning Mailpiles into DDoS attack robots.

</comment></comment><comment><USER5> It be better if it were actually a native application rather than a web 'app' that uses a local webserver instead of headless chrome. They've traded security for ease of cross platform development. That's not a great choice for software that markets itself based on those traits.

<comment><USER6> There are already scores of email clients with support for GPG, etc. However more and more people (probably an overwhelming majority nowadays) use webmail only. I suppose they're the intended target.

I myself plan to migrate all of my data to my own services at some point, I already moved away from DropBox to Nextcloud. That could be a good solution to move my family out of the evil gmail, for instance.

Now what I'd like to know is which is better of MailPile, RoundCube, Zimbra, and the many other webmails available...

<comment><USER7> Just as a heads-up, you should maybe have a look at mailcow and mail-in-a-box:

* [https://mailcow.email/](https://mailcow.email/) * [https://mailinabox.email/](https://mailinabox.email/)

which essentially provide the whole email stack in a relatively nice bundle it seems (I have not yet forced myself to migrate). I think mailpile and roundcube are just the "webmail" part of the stack.

<comment><USER8> vote for mailcow.

Have it running about half a year and am really happy about it.

If you have the time imho migrating is worth it.

You can transfer your old mails via imap to mailcow, so migrating is easy

</comment></comment></comment></comment><comment><USER9> Some of the larger threads:

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

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

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

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

</comment><comment><USER10> > Mailpile is an e-mail client! Mailpile is a search engine and a personal > webmail server (...)

Does it run on my phone?

<comment><AUTHOR> Yes, it is possible. You need to run as 'mailpile --www=0.0.0.0:33411 --wait'

and go to [https://[Local](https://\[Local) IP of Server]:33411

<comment><USER11> No, that is not running it on your phone. That is _accessing_ it on your phone.

<comment> mike-cardwell I just went to the download page and it says: "Mailpile packages are currently available for recent Debian-derived distributions, including Ubuntu. The packages are architecture-independent and should be compatible with most desktops, servers and embedded hardware (such as the Raspberry Pi). They have been tested on Debian 8, Debian 9 and Ubuntu 16.04 LTS."

So sounds like it will run on the Librem 5 at least.

</comment></comment></comment></comment><comment><USER3> I wrote [most of] Mailpile. I'll check back here now and then and try to answer any questions folks have.

</comment><comment><USER12> I like this, but it looks tricky to setup. There is an old dogma that has existed for a long time where people are advised not to run their own mail client because it's rife with show-stopping quirks that require lots of heavy Googling to fix and amend.

Interesting that their FAQ says it's easy to setup, but I don't buy it, at least from previous experience of setting up clients. (I once had to harden my VPS server rather substantially because they are juicy targets for hackers)...And I also once had to make it survive a reboot incase of too many connections were made by people trying to boot the machine offline (DDOS)

([https://www.mailpile.is/faq/#int-6](https://www.mailpile.is/faq/#int-6))

> _How hard will it be to install Mailpile?_

> _It should simply be a double-click to launch an installer on Windows, or > dragging an app to the Applications folder on the Mac._

> _On Linux we hope to provide native packages for most of the popular > distributions._

<comment><USER13> from what I've read in threads on hn, I thought there was a large chance that your email gets blocked by gmail when hosting your own mail, and that you have to worry more about availability.

I would love to host my own mail though. Am I mistaken, or does mailpile solve those for you?

<comment><USER8> As long as you use a VPS with a dedicated IP and configurer DKIM and SPF correctly gmail doesn't block you.

A easy solution for selfhosting would be mailcow.

Setup is basically a shell script which sets up the docker containers.

Backup and update is also just a shell script. Includes spamfilter and a nice webgui as well as the sogo webmail.

Mailpile is just a client, it has no bearings on the privacy.</comment></comment></comment>


Rails developers: would any of you find this useful? - <AUTHOR> http://www.scaffoldhub.org/

<comment><USER2> I think this is a great idea, but mainly because it provides a template for the best practices when implementing a particular item, like file uploading or infinite scrolling.

Given that, I'd love to see the code for these scaffolds directly on the site, with an explanation about _what_ it's doing and _why_ it's doing it that way, as well as the ability to comment on a particular implementation. I would think that type of community-driven peer-reviewed best practices for common feature implementations would be very valuable indeed.

<comment><AUTHOR> Great ideas.. thanks a lot. I thought about this sort of thing, but for now only had enough time to implement a "blog post" link on each scaffold page, allowing the author to link to more info on their blog about what the scaffold does, or how it works.

<comment><USER2> Granted my above idea would sort of overlap you with railscasts or asciicasts, however the one issue is that thoses casts go _out of date_. If your site or another site focused on _idioms_ only, and the best practice to _use_ those idioms, peer-reviewed with comments and maybe versioning, then it would easily become a go-to reference for developers, that would always contain the most up-to-date method of implementing said idiom.

For instance, you want to implement authentication. Right now the best thing you can do is head to railscasts, see what the latest screencast is for authenticaiton. Ah, november 2010. Might as well be ancient history! Perhaps there's a newer, easier, more-accepted authentication gem out there. Or maybe not! You just don't know. So what's next, maybe check some blogs, github, do some date-specific searches on google, etc.

If you or someone else had a site that basically said, "here's the current accepted practice for implementing authentication, and here's _why_ ", then that saves so much time!

<comment><AUTHOR> Yea - there's a lot of overlap with different things. Ryan's screencasts on one hand, which are amazing even when out of date, and things like <http://ruby-toolbox.com/>, which give you a list of gems to look at/choose from on the other. Plus github itself is the best place to find actual code, and is peer reviewed in the sense of watch counts, etc...

All I can hope for is that with some community involvement, ScaffoldHub might become something useful in the middle: not in depth tutorials, not a code repository, but a series of helpful working examples.

I certainly can't do it alone!

</comment></comment></comment></comment><comment><USER3> In my experience, scaffolding is a crutch for people unfamiliar with Rails. In my connections with experienced Rails devs, I've hardly ever heard of anyone who uses it.

Only time scaffolding comes up in the irc channel, forums, etc, is when beginners ask how they can make scaffolding do X, and the answer is always that you don't, scaffolding is a temporary crutch, just like the name implies. And, experienced Rails devs don't use it, not even temporarily.

So it's probably a completely useless website for experienced Rails devs, while potentially being quite helpful to beginners. An important step towards becoming well versed in Rails is to _drop_ that crutch, though. IMHO, focusing on scaffolding basically _keeps you_ from really immersing yourself in Rails.

<comment><USER4> +1 on this. I'm a Ruby contractor and never use scaffolding, and in general I tend to eschew anything that generates a lot of code.

Although, this is probably useful to those with not much Ruby/Rails experience.

<comment><USER5> I think as community is growing there are more people turning towards RoR from other technologies, because: 1\. Ruby is language of developers 2\. With Rails building application is pretty fast.

I think I have attended a session 4 years back (when I was nuby) when one guy taken user requirements and generated rails app in few hours through scaffolds (and I must tell you it was very inspiring). Though it was just a skeleton and not at all production ready, but at least gives sponsors a feel of application what they envision and in turn they provide quick feedback.

So, I think scaffolds are still useful to provide you bunch of useful files, which otherwise you write by hand.

<comment><USER6> Scaffolds are a fine way to learn the Rails conventions, but in several years of doing security assessments in the codebases of some of the world's largest Rails apps, I have never once noticed one being used. Professional Rails developers seem to shun them as a rule.

</comment></comment></comment></comment><comment><USER7> I kind of dislike scaffolds. Often they generate crap you don't need. The stuff they do generate that you need is either A) totally generic, and should be tucked away in a library somewhere, or B) needs to be customized and the scaffold didn't get you anything.

On top of that, when the scaffold changes, there's no easy way to patch you code. I think in theory what you should do is maintain a log of all of the scaffolding you did, and which commit you did them in, and that way you can just check out that commit, re-run the scaffold, and then merge that back into your tree. But I never remember to do that.

What's the benefit over a well architected library? Especially in a language like Ruby where it's so easy to write DSLs, I don't see where you'd ever want a scaffold.

<comment><USER8> > What's the benefit over a well architected library? Especially in a language > like Ruby where it's so easy to write DSLs, I don't see where you'd ever > want a scaffold.

The benefit, I think, is that scaffolds:

* generate a pile of code that you feel free to hack away at, removing and adjusting as you see fit. I don't think scaffolded code is a good candidate for patches, really. It's a shortcut that writes code for you, not a library.

* generate code that is customized to your precise needs. For example, when you scaffold something using Rails' default scaffold generator, it creates a database migration and builds the appropriate form fields based on the columns you're using in the model.

* are great for generating the kind of code you tend to write over and over. For example, we do lots of custom website development, and a common requirement is the forms for CRUD related to the entities people are managing on these websites. The problem is, the entities are always changing. For an auto dealer, the entities are vehicles, makes, models; for a real estate brokerage they are brokers and properties; etc. We would previously cut and paste code and then modify it, but then we wrote a scaffold generator that builds all the forms for us with all of the appropriate structure and CSS classes and IDs to make them look beautifully integrated.

<comment><USER7> I see. So, sort of like a sculptural "chip away everything that's not an elephant" kind of approach. That makes some sense.

I think the "custom generated code to mee your precise needs" category is exactly where I think scaffold writers are just lazy library writers. If there's a way to parameterize the scaffold experience, there's a way to create a parameterized library that "scaffolds" your code without generating a bunch of boilerplate.

On the last point: I think that makes a lot of sense, especially if you're working for clients. They want to end up with a complete, hackable site that doesn't have some weird dependency on a meta library. (like a library with meta-forms, meta-models, etc)

I guess I'm biased because I work on one big piece of software, so that kind of duplication would be heresy.

That said, if you tried to write a unified framework that let you build sites like that without a bunch of generated scaffold... you might end up building the next Rails! Isn't that where Rails came from?

</comment></comment></comment><comment><USER9> I want to expand on my previous comment and tell you HOW I found it useful. My Rails learning typically falls into two categories. I'm either reading manuals/online tutorials OR I'm digging through GitHub to see how other people put things together. Both have been powerful. So, the reason I found scaffoldhub useful was not because I wanted to clone the scaffolds and use them, but simply as another way to identify specific functionality that interests me, and then browse through the associated code on GitHub. Hope that helps!

<comment><USER10> I'm in the same boat. Useful for learning new techniques and digging into the code.

</comment></comment><comment><USER11> I think something like this really needs a rating or comment system. Would be nice to see what people thought of the code used in the scaffold you were downloading rather than having to create a scaffold and review it on your own. As the number of scaffolds grows, it would be hard to sort between clean, popular ones and ugly ones.

<comment><AUTHOR> Great suggestion - thanks! I agree if there ever were many scaffolds on the site, choosing the right one to use will become much more difficult.

</comment></comment><comment><USER12> Is the purpose of scaffolding just for learning? When I was just starting, I built a twitter clone using a scaffold in about 5 minutes and ... I learned nothing. I then spent a week coding it by hand and learned rails.

I don't think I'd ever use a scaffold in a production app though. For that, I'd ether find an appropriate gem or write the code myself.

<comment><AUTHOR> Yes, I think scaffolding is primarily a helpful learning tool... especially for learning how to wire/connect different gems, javascript libraries, etc., together into a working example. Often no single gem will provide everything you need.

But you have to take the time to learn from the example, or I agree you'll get nothing out of it.

</comment></comment><comment><USER13> I've done Rails consulting, full-time, for 5 years; I haven't used use scaffolds since probably 2006. Instead, most of my productivity gains have come from learning to use third-party gems, better understanding the framework's ever-evolving capabilities, and Texmate snippets & commands.

However, a site such as this, where popular scaffolds could be voted up to the top of a pile might produce some worthy projects.

I can imagine myself using scaffolding when using a gem for the first time, one of the more involved gems like carrierwave, uploadify, or devise. These gems can take a while to get working - you may be targeting a different version of rails than the blog post you find, or you're deploying to heroku and need some custom tweaks - the details can slow you down and make you reconsider whether to use the gem, especially if you're billing by the hour.

If, on scaffoldhub, I could find a scaffold for something quite specific ('rails 3.1 and compass on heroku' or 'devise, haml, coffeescript, simple_form') that would be really, really helpful.

I'd quickly get something working on my dev machine, which saves me frustration and gives the first charge of coding pleasure, an important component to our work. It would enable me to more liberally experiment with new libraries and coding practices.

Perhaps, also, a rake task to generate a scaffold from a working rails app. That way, a scaffold, once working, can be extended. For example, first I install the uploadify scaffold, verify that it's working both locally and in production, then I add compass and devise. I run rake scaffoldhub:snapshot rails_3.0_uploadify_compass_devise_heroku, then scaffoldhub:publish to upload my work.

I hope you continue with the project.

<comment><AUTHOR> Wow... fascinating idea about "rake scaffoldhub:snapshot"!

I really appreciate your feedback and encouragement. I definitely will continue working on scaffoldhub; probably my next step will be to open source the web site code (gem is already open) so others can help out on this. I really see this as a community resource - not a private project.

</comment></comment><comment><USER14> Yes - but one thing that is important is some sort of indication that a scaffold is "good". I use Ryan Bates' nifty generator all the time, mostly because I know it will spit out good, basic code.

Some sort of voting mechanism, or other indication of popularity/quality would be very helpful. Allowing the best practices to bubble to the top would be very helpful to rails developers in my view.

As others have said, great for beginners or to developers implementing some feature for the first time.

<comment><USER15> Also versioning or attribution would be nice, allow folks to improve or fork a scaffold, with change log.

</comment></comment><comment><USER16> Great for beginners, or people who want to hack together a quick website! Personally, I stay away from scaffolds altogether though so I don't get stuff that I don't need being generated. Also.. as I continue to develop and my website designs become more complex, I find less and less of my projects needing the cookie cutter design of a scaffold.

<comment><AUTHOR> I totally agree - however, I'm guessing even more experienced Rails developers might find scaffolding occasionally useful as a starting point... e.g. for learning how to use a certain JQuery plugin it's often hard to know even what JS files you need, where to find them, where to put them, etc.

</comment></comment><comment><USER17> I would _love_ to see this get popular. This would be such a great community resource for all levels of Rails developers.

</comment><comment><USER18> Using scaffold code makes me feel uneasy. I'd much rather see things like this extracted into a gem and accompanied with a short tutorial or screencast explaining how to use the gem rather than code that may be overkill, can't be updated easily, and will quickly become stale.

</comment><comment><AUTHOR> Thanks everyone! Great suggestions and very encouraging... I'll have to sort out priorities/what to do next and find some more spare time to work on this :)

</comment><comment><USER19> I like it; better yet, if you can host live demos (it doesn't have to real rails apps, it can just be html)

<comment><AUTHOR> Great idea; thanks! I do now have the option for each scaffold to link to a blog post somewhere... but hosting HTML demos is an interesting thought too.

</comment></comment><comment><USER20> This would have been most useful when I first starting learning Rails, but it's still useful nonetheless.

</comment><comment><USER21> Do you guys remember when people used to create MS Access applications? They let the mdb running into a shared directory and screamed around the office to gain or release lock.

This is what both rails scaffolding and django admin means to me.

</comment><comment><USER22> Your submission's title is linkbait. Please do not do that. You could have mentioned the topic of what is linked in the text.

<comment><USER23> Oh come off it. The title and URL preview clearly give enough of an impression of what this is about.

</comment></comment><comment><USER9> I just DID find it useful. Cheers!

</comment><comment><USER24> +1

</comment><comment><USER25> Useful..!!</comment>


Kongregate announces $10mm mobile publishing fund - jim-greer http://www.polygon.com/2013/2/4/3944416/gamestop-kicks-off-new-indie-mobile-game-initiative-hires-zynga-gm-to

<comment> jim-greer If anyone's interested, drop me a line - email@example.com</comment>


Embedded or web fonts for my app? - <AUTHOR>

I'm developing a web app.  The PR portion of our site that talks up the app uses embedded fonts from Typekit.  I'm wondering if I should use these same embedded fonts in the actual app itself too.  Does anyone have experience in how much this would slow down the app?  In theory, it should slow things down but I'm wondering if it's OK to have this tradeoff if the design is consistent across the site.  Anybody have any advice on this issue? <comment><USER2> As long as it works for all browsers you plan to support and the site begins rendering quickly, i.e. people don't perceive the site as slow because your fonts aren't showing up quickly enough, it should be okay.</comment>


How to reach Product-Market fit? - <AUTHOR> https://medium.com/stories-hq/north-star-product-market-fit-b35b180d7ed7 <comment><USER2> It's worth mentioning that true demand from the Market will pull the optimal product out of a capable team. Thus, having the capable team and understanding at least which markets you are operating in are critical components to the recipe for success. While it's a helpful write-up, a lot goes unsaid. Namely, that one needs to say no to a million things in order to say yes to the few great things that will make the product/company what it is. Just changing or pivoting for sake of pivoting is not exactly right, it should be done based on intuition and data, and also based on paths tread by other successful startups.</comment>


If innovation leads to success, shouldn't the stock market reflect that? - <AUTHOR> http://phildhingra.com/2010/01/innovation-vs-stockmarket.html

<comment><USER2> I don't think any long-term conclusions should be taken from the data he uses. The 2008 data basically captures the market downturn, and the 2009 data captures the recent bull market. It's not really representative of larger trends.

<comment><USER3> That's what the "vs. S&P" column is for.

<comment><USER4> Comparing returns to the S&P is way too simplistic. What if the industry that company is in did particularly well?

</comment></comment></comment><comment><USER5> it's possible that the market has already priced in their innovativeness. if this is the case, then the subsequent stock dips indicate that their innovations did not pan out.

</comment><comment><USER6> I think the explanation here is that sadly, innovation does not always lead to success for its innovators, at least not immediately. Several of the underperforming companies are doing very innovative things, but their stock price could be lagging because of internal scandal, bad timing/location, bad investments, or just the state of the economy in general (smaller luxury market, etc.). The first to market always has a significant advantage, but as history has shown (Netscape, Creative Nomad Jukebox), that advantage is not everything.

Affymetrix, for example (AFFX, -43% vs S&P) is working on making different medical treatments for different people based on genetic variations (metabolization rate, etc.). However, much of their work is still experimental, and they reported a significant negative net profit in Q4 2008 ([http://www.google.com/finance?q=NASDAQ:AFFX&fstype=ii](http://www.google.com/finance?q=NASDAQ:AFFX&fstype=ii)). They were and are a speculative investment, and their stock price reflects the market's skepticism that they will capitalize on their innovation.

That said, it almost certainly is innovation, and it will inform and inspire future scientists who may eventually make it profitable.

Additionally, many of these companies target what the UN calls "developing countries" and the stock market calls "emerging markets". These are long term investments, based on worldwide trends of previously poorer countries (BRIC) "emerging" into Western standards of living and, consequentially, becoming consumers of our shit. While these may be profitable eventually, their "innovation" may be just learning the needs of a new, poorer but still technologically literate market.

Also, some of these are just poor calls on FC's part. Nokia 2 years in a row?!? Come on.

</comment><comment><USER7> The problem is defining what we mean by innovation. In the strictest sense innovation is "the bringing of the new" An established company however is based on making money from what they do already. Then they talk about innovation because it sounds good. When we try and define an innovative established company we are not really making sense. What we really mean is "being clever at what they do already". The other issue is that share price is more determined by institutional investors rather than market performance. The whole concept is like judging the performance of a car based on the colour of its' engine.

</comment><comment><USER8> Have a look here - "The Myth of GDP and Stock Market Returns": [http://www.virtus.com/vsitemanager/Upload/Docs/6141_GDPwhite...](http://www.virtus.com/vsitemanager/Upload/Docs/6141_GDPwhitepaper.pdf) (PDF).

A few highlights: \- "GDP is analogous to sales; stock returns to corporate profits." \- "The stock market does not reflect the full economy." \- "A company's profits may be earned outside the country in which it is listed."</comment>


Vermont proposes providing broadband internet service to all state residents - <AUTHOR> https://www.burlingtonfreepress.com/story/news/2020/05/06/vermont-proposes-providing-broadband-all-state-residents/5177598002/ <comment><USER2> Hi there, I'm a part of this effort and we did learn from the Burlington Telecom fiasco. Legislation was passed in 2014 that provided for the forming of Communications Union Districts which can build municipally controlled broadband infrastructure, but can't access the municipal bond market, meaning taxpayers are never at risk. The downside of this is we have to rely on federal funding in most cases since private capital wants to make sure they have the option to take it out on the taxpayer if the debt load becomes unserviceable. Right now this is not an issue at all for us with hundreds of millions of stimulus money specifically for broadband floating around, the challenge is beating Comcast et al to the money bin. Comcast in particular is pure evil in Vermont, they signed a contract to build out a paltry 550 miles of new cable to unserved addresses over 10 years (55 miles a year) and then sued the state afterwards for infringing on their 1st amendment rights.

[https://arstechnica.com/tech-policy/2017/08/comcast-sues- ver...](https://arstechnica.com/tech-policy/2017/08/comcast-sues-vermont-to- avoid-building-550-miles-of-new-cable-lines/)

I'm with one of the largest CUDs in VT, NEK Community Broadband, which represents 27 towns in the northeast of the state. We're talking to our state government as we speak to make sure incumbent providers are held accountable if they are provided with federal money, and preferably, build our own infrastructure. The timeline for this has shrunk from 3-5 years, to 8 MONTHS by restrictions imposed on spending CARES act and other federal dollars by Jan 1. It's an exciting time!

<comment><USER3> How do these munibroadband efforts dovetail with existing local fiber companies? I get access through Waitsfield & Champlain Valley Telecom and after granted a long delay on speeds they've been pretty aggressive about fiber rollouts in the last year or two. I'm down by Monkton and have 1G fiber. It's $105 a month, which is certainly more than BTV but this isn't a dense area at all either, and even when still on DSL they've always been really pleasant to deal with. I know there have been other fiber deployments in various places one might not expect at first glance in VT too, and the mountainous terrain is both an impediment to physical rollout but also offers some opportunities for WISPs.

Definitely excited to see more progress on this at last, and Comcast is certainly awful. I hope though that'll it'll benefit from and get boosted by what is here too.

<comment><USER2> Very much so. We're looking at EC Fiber as a model of what a successful CUD looks like, and also talking to local electric distribution utilities who have unused fiber assets that we can license from them for residential use. Wireless we are very wary of here, as it is both weather and terrain dependent and provides poor speeds (usually around 14-20m) and one of the larger wireless internet providers, VTel, squandered a USDA rural broadband grant a few years ago and effectively locked the northeast region of the state out of further funding from that program.

<comment><USER3> Fair enough and thanks for the reply! I certainly didn't mean to suggests that WISPs should get any federal funding directly per se, more that one of the benefits of more fiber deployment would be more options for private higher speed "WISPs" (which could just be a techie on a hill who can put up a few cheap 400 Mbps class PtPs for some neighbors) so there might be coordination opportunities.

Per your comment elsewhere in the thread, I'd definitely like to see 100% of any NEW federal money in particular go to fiber. Even if it takes a while, every bit of incremental build out there is permanent progress, not wasted on dead end ancient copper.

Best of luck to you! I joined a vt governor's campaign back in 2010 in part because they were the only one to really focus on this issue. It's something I think could help the state significantly.

</comment></comment></comment></comment><comment><USER4> I live in Vermont and I'm tentatively excited about this. Unfortunately, our municipal internet provider in Burlington, VT was financially a disaster [1].

The tax payers put up a bunch of money. Burlington Telecom was mismanaged into defaulting on its debts causing the city's bond rating to fall to nearly junk bond status. It was sold at a loss to a private company. [2]

Very disappointing considering how awesome Burlington Telecom is. I currently pay $35 for 1G symmetrical in my apartment building.

Hopefully if this statewide project goes through, they don't repeat those mistakes.

[1] [https://vermontbiz.com/news/2019/march/13/citibank-fully- rel...](https://vermontbiz.com/news/2019/march/13/citibank-fully-releases- burlington-335-million-bt-lawsuit) (Citibank fully releases Burlington from $33.5 million BT lawsuit)

[2] [https://www.wcax.com/content/news/The-Burlington-Telecom- sag...](https://www.wcax.com/content/news/The-Burlington-Telecom-saga-and-how- we-got-to-where-we-are-455070453.html) (Burlington Telecom timeline: How did we get here?)

<comment><USER5> The same could be said about Frontier [1] and Windstream [2]. I like that Vermont keeps trying, my internet should be like my water, sewer, and similar local services: a utility. The unemployed can be trained to run fiber, and the Fed is going to keep soaking up muni bonds [3], not much to lose by trying again. Capital is cheap, treat failure as just as cheap.

It can be done [4] [5]. But you have to care. You have to build public systems and goods that are loved, because to love them is to want to provide ongoing care for them, and to invest yourself in them (financially and otherwise).

[1] [https://www.eff.org/deeplinks/2020/04/frontiers- bankruptcy-r...](https://www.eff.org/deeplinks/2020/04/frontiers-bankruptcy- reveals-cynical-choice-deny-profitable-fiber-millions) (EFF: Frontier's Bankruptcy Reveals Why Big ISPs Choose to Deny Fiber to So Much of America)

[2] [https://arstechnica.com/information- technology/2019/02/winds...](https://arstechnica.com/information- technology/2019/02/windstream-isp-with-1-million-customers-files-for- bankruptcy/) (Windstream, ISP with 1 million customers, files for bankruptcy)

[3] [https://www.cnbc.com/2020/04/27/the-fed-says-it-is- expanding...](https://www.cnbc.com/2020/04/27/the-fed-says-it-is-expanding- its-municipal-bond-buying-program.html) (CNBC: The Fed says it is expanding its municipal bond buying program)

[4] [https://muninetworks.org/communitymap](https://muninetworks.org/communitymap) (US Muni Fiber Map)

[5] [https://b4rn.org.uk/](https://b4rn.org.uk/) (England: Broadband for the Rural North)

<comment><USER6> > I like that Vermont keeps trying, my internet should be like my water, > sewer, and similar local services: a utility.

It is practically impossible to run multiple competing water and sewer pipes or other utilies. But there is no such problem with fiber. Or there could be public passive fiber operated by multiple competing ISPs.

Proper role of government is to actively encourage competition, not destroy market by subsidised public service. But it seems that US government instead actively discourage competition, which leads to bad commercial services, which leads to public preference for monopolistic government service, with all its problems well known from Europe past.

<comment><USER5> You're entitled to your opinion of course, but it has repeatedly been shown that ISPs will not make the necessary investments, and instead will over leverage with debt while milking the customer base for the most dollars they can while providing the lowest quality of service tolerable.

Private enterprise had their chance, decades even. Fool us once.

<comment><USER7> Symmetric gigabit is under $80/mo from AT&T where I live. That's not only good new infrastructure but also significantly cheaper than the old cable stuff. Maybe were the space less regulated ISPs would make a greater investment, especially were it easier to start one's own. If the WISP idea ever gets really good that would solve most of the situation.

<comment><USER8> > Maybe were the space less regulated ISPs would make a greater investment, > especially were it easier to start one's own.

I'm genuinely curious: what regulations are hampering investment? Cause it's not net neutrality (ISPs have said to their investors that it doesn't)

Seriously, the governments have taken almost a hands off approach to the internet, and it's now evident that it's not working.

<comment><USER9> The government does not take a "hands off approach to the Internet." It might seem that way, because the _federal government_ does that. But when you're talking about building physical things in specific places, that's largely the domain of cities and states, and accordingly most of the relevant regulation is at the state and local level.

State-and-local permitting is one huge morass. When I had fiber installed to my house, Comcast had to get permits to hang fiber on a utility poll. Then there were different permits for diverting traffic temporarily while hanging the fiber. Then there were other permits for trenching. The whole process took _months_. And there is a skilled worker there that has to shepard the process through the bureaucracy.

Other regulations prevent offering television service (a key revenue source) without commitments to build a certain footprint. That means you can't start an ISP with a "minimal viable product" and grow from there. You have to be willing to commit huge amounts of money up front before you see a cent of revenue.

It's very illustrative to look at the deals Google Fiber struck with municipalities, because that shows you where are the real pressure points. Two features appeared in almost every accepted proposal for a Fiber city: (1) one- shot, fast-track permitting; and (2) no build-out requirements.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I wish more states viewed it this way. I think that COVID19 has proven that Internet isn't a luxury, it's a utility that we all need. In a world with online meetings being the way to simply hang out with your friends, those with bad Internet connections are suffering more. It shouldn't be that way.

<comment><USER11> I have a coworker who basically doesn't participate in meetings. Their connection is so bad that maybe 10% of their sentences are intelligible.

<comment> frosted-flakes Some video conferencing providers allow you to call in to a meeting with a landline telephone. I know Zoom does, anyway. No video, obviously, just voice.

</comment></comment></comment><comment><USER12> I live in Longmont, Colorado, and we have cheap municipal fiber.

1Gbps, synchronous, $55/mo.

Just now:

[https://www.speedtest.net/result/9466487634.png](https://www.speedtest.net/result/9466487634.png)

Similar speeds on Netflix's fast.com.

This is what happens when monopolies have competition they can bully, but not buy.

<comment><USER13> Hello neighbor! Fort Collins, CO checking in - municipal fiber, same service / speeds BUT we do have to pay $5 more per month. Oh well. :) Looks like quite a few other cities in CO are joining us soon..

<comment><USER12> Very cool! Apparently it costs a bit more now than when I first signed up. Also, they support 10G! I'm already wiring up everything with Cat8 and I'm looking for a 10G Router and a 10G Switch.

It's been hard to find just the right one, though. Almost as hard as finding the perfect bento box.

I'm looking for a 16-port or 24-port switch, ideally they'd all be 10G, but I could compromise a little on a few being multigig. Also, I'm not really worried about PoE, I don't have anything that could use that yet, and if I ever did, I'd purchase a separate switch, and probably not 10G.

Price isn't a major concern, if I can't afford it, I'll just hold off with what I have until I can, and I've never really used a managed network interface, so I'd probably just prefer an unmanaged one.

I do need to have a separate subnet for my wireless router set in AP mode, so whatever 10G router I choose, I'd want it to be able to support that.

I've been looking into Mikrotik and Ubiquiti, and they don't seem to quite offer exactly what I'm looking for. Cisco might, but their site is... Incredibly difficult to use.

</comment></comment></comment><comment><USER14> I've been looking into buying a house and moving to Vermont. The topic of fuller, better internet coverage seems to come up every few years. So I'm a little skeptical to see it now.

I'm not sure I'd consider it a blocker to moving there, even if I'm dependent on the internet for work. I'm assuming I'll always be able to lease an office within an hour drive of the house.

I wonder how practical satellite options like Viasat are says it gets 12-100Mbps download across Vermont. That's as good as Comcast's consumer broadband gets you in Philly.

If there are any folks here who own and live on land in Vermont I'd love to ask you more about how/where you're living and working, if you wouldn't mind.

<comment><USER15> Moved to VT in early January from the Boston area, in what was by sheer chance, a _very_ timely move. We rent.

We live in a bit of an odd development/area. Think of it as a golf course community minus the golf course: under a dozen homes, low density, and private roads. We quite like it, but it's an unusual arrangement from a utilities standpoint.

We have Comcast. The other options were VTEL via satellite and cellular wireless. We struck cellular wireless from the list for reasons we're all well familiar with ("unlimited", caps, speed restrictions, cost). VTEL was going to be complicated because we have a metal roof, among other things. We're told that unofficially we can get line of sight to nearby VTEL infra, but convincing VTEL of this seemed like a lot of work while we were moving.

We got ridiculously lucky on begin able to get Comcast. The pole our cable comes off of is literally the last pole with coax on it. In this regard, I suppose I'm replying to you from the actual end of the internet. There is possibly one other house within the radius of the pole that Comcast is wiling to pull a line. That's 300' for a temp line, which they did for us because the ground was frozen and the couldn't bury a line when they did the original install. I don't know if it's longer if they can do a direct bury.

The latency and throughput aren't as good as they were in the Boston area, but it's good enough. Zoom calls tend towards blurry, but Netflix and Youtube are certainly serviceable. Instagram videos tend to pause a lot for buffering. Bad websites are apocalyptically bad. Joann.com, for example, is horrendously slow. I'm guessing they never worried too much about e-commerce until quite recently.

I'm told that the cable company put coax up to the development way back in the day, but that nobody actually subscribed, and so the line was never brought any farther in.

<comment><USER16> > I'm told that the cable company put coax up to the development way back in > the day, but that nobody actually subscribed, and so the line was never > brought any farther in.

That happens, especially if it's a lower density area.

Usually the way it goes is if the region is close to the minimum 'homes passed/mile' metric they'll do a minimum build-out, that way if there's enough interest and/or HPM goes above threshold it's not absurdly expensive to finish the buildout (and/or buildout as people actually request service.)

</comment></comment></comment><comment><USER17> Yay for Vermont, but I hope they give their plan some teeth when the big telcos (who presumably would be doing the work) inevitably do not deliver on their promises.

It would be much better if they turn it into the state-wide equivalent of municipal broadband. Maybe that's what they are thinking? The article is very light on details.

</comment><comment><USER18> My wife is a VT teacher, in secondary education. Obviously with Covid all students are being educated online. Those who do not have an online are at a quite significant disadvantage.

That is, at least until this is over broadband to all can be thought of as, in part, component of a statewide education infrastructure.

</comment><comment><USER19> Godspeed Vermont. May you have more success than your promised single-payer health care.

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

</comment><comment><USER20> Municipal internet is something we should all get behind because the internet is no longer a luxury, or a tool, it's an essential service. Imagine not having the internet in the next pandemic.

<comment><USER21> Food is also essential. Do we have municipal farms?

<comment><USER8> Kindof.

We provide massive subsidies to farmers. Then the farmers give us food.

But when we provide massive subsidies to ISPs, they don't invest; They just spend it on executive bonuses and stock buybacks.

</comment></comment></comment><comment><USER22> Growing up in Vermont wifi was so bad. Cell signal is still pretty awful in many parts of the state especially the northern kingdom.

Hope this goes through. I have friends that are still on dial up.

</comment><comment><USER23> > _That's defined as speeds of 25 megabits per second for download and 3 > megabits per second for upload._

I really wish they just considered symmetrical speeds. These bizarre asymmetric speed limits are just a made-up limitation of the Comcast era.

<comment><USER2> We're currently fighting to get this definition changed to 100/100 symmetrical, because as you say this magic number of 25/3 lets DSL in the door, which in turn means incumbent providers can continue to get federal dollars that they will refuse to spend on infrastructure. Telcos will claim their ancient 50 year old copper is capable of delivering 25/3 to an area, when in fact only the first 5 houses on a road get near that number. If you happen to be the 12th house down the road (about a mile out) you get 7/1 on a good day because the copper was strung in the late 1950s. The minimum standard having a symmetric speed requirement prevents small diameter copper from stealing money from the pot.

<comment><USER24> >We're currently fighting to get this definition changed to 100/100 symmetrical

TIL I don't have high speed internet.

<comment><USER23> I don't think anyone except fiber providers are offering more than 10 mbps upload.

Because piracy is an existential problem for Comcast (owner of NBCUniversial among others) there's incentive to keep upload SLOW.

And don't get me started on bandwidth caps. I remember doing the math and realizing I could hit my bandwidth cap in 8 minutes if my internet went the full theoretical speed.

</comment></comment></comment></comment><comment><USER25>
      Population: 623,989
      23%: 143,517
      300,000,000/143,517.47 = 2090 USD

<comment><USER26> Wow dang, I hadn't done the math on that. That's much more cost effective than I though it'd be, what a deal!

</comment></comment><comment><USER27> I'm always surprised by how bad and expensive the internet providers in the US are. Where I am (think major city in a 3rd world country), I pay about 20 USD a month for 650gb at 150mbps (up and down).

</comment><comment><USER28> Vermont has a troubled recent history with expensive, state-wide public initiatives:

[https://en.wikipedia.org/wiki/Vermont_health_care_reform#Gre...](https://en.wikipedia.org/wiki/Vermont_health_care_reform#Green_Mountain_Care)

The elimination of rent-seeking behavior from healthcare and Internet service is great, in theory. For whatever combination of reasons, the state government of Vermont and city government of Burlington have had difficulty putting this theory into practice.

</comment><comment><USER29> I'd expect the Comcast lobbyists to go into overdrive to get this decision overturned. Also, I'd expect them to file a lawsuit against the state government of VT in a similar desired outcome. This would lead to the domino effect if it were allowed to occur.

<comment><USER8> I'm curious: on what grounds would Comcast have to sue? I could understand the US government stepping in with the Commerce Clause, but I don't know of any laws that would give Comcast and friends the ability to sue.

</comment></comment><comment><USER30> To see a model of a municipal ISP succeeding, you can look at Chattanooga, TN's EPB.

</comment><comment><USER31> It's really interesting watching the natural experiments that are the northern New England states. Maine, New Hampshire and Vermont are small, essentially the same founding stock, and yet they go in such radically different directions.

</comment><comment><USER32> State wide broadband is extremely hard to do.

If you look at all the successful community broadband initiatives in the US, they are almost always at the city/county level.

</comment><comment><USER33> These latest "broadband" efforts look like just another money grab by the same incumbents (Comcast, Frontier, etc) and the same state and federal bureaucracies that have failed to deliver competition and access. Vermont should simply announce full throated support for low-orbit satellite internet, which is under active deployment from SpaceX and also development from Amazon.

<comment><USER2> Absolutely agreed that the same inefficient companies are trying to grab the federal money once again. The difference this time is we have Communications Union Districts in place in many parts of the state that have veto power over proposed broadband projects in their region.

As for LEOS internet, the elephant in the room for this technology is vulnerability to solar flares and Kessler syndrome. Long term viability of satellite super constellations is seriously in doubt.

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

</comment></comment><comment><USER34> I wonder if this will be used as an excuse to start censoring the internet just as the FCC used "public airwaves" as an excuse to censor broadcast.</comment>


Programs should be Small - <AUTHOR> http://mkhadikov.com/2012/02/02/programs-should-be-small.html

<comment><USER2> I love all these articles which are wholly ignorant of how complex software is in reality and how such advice isn't necessarily good.

Sometimes decomposition results in problems at the other end of the scale such as communication performance, data duplication, extremely nested abstractions, messaging complexity, contract and API versioning hell etc.

Getting the sweet spot between monolithic coupled blobs and fragmented latent deathtraps is an art which can't be puked out in a blog post. It takes literally years of experience and some guesswork and testing and thinking.

Ultimately, lots of small programs are just as painful as a single large one if they have to talk to each other or do IO.

<comment><USER3> Adding to that, his stated advantage of not having to limit yourself to one platform also seems opposite of my experience (i.e. keeping all on the same platform _is_ an advantage).

When you have a big system with disjoint parts written in different languages, re-use and refactoring is a pain, and redundancy is almost certain to creep in (and with redundancy often comes inconsistency).

<comment><USER2> Yes heterogeneous systems are much easier to deal with, although from experience certain systems are a pig to deal with from end to end (anything Microsoft as a rule).

Different languages are just different forms of integration and the mantra of _integration is hell_ should be in the forefront of everyone's mind, always.

<comment><AUTHOR> Depends on tools you use, I found Apache Thrift and Protobuf pretty to be sophisticated tools for integration between services.

<comment><USER2> Yet they are still entirely impractical for what we do. There is no one size fits all methodology which results in a heterogeneous communication layer. This means that you end up with technology fragmentation and therefore additional complexity.

</comment></comment></comment></comment></comment><comment><USER4> The problem is that software has a tendency to become complex. The proposed solution is to break up the software into smaller programs.

There are certainly advantages to having smaller components. It allows you to rewrite components in a different language should you want to, for example. But there are disadvantages to: smaller components means dealing with failure at a much finer granularity.

In my opinion, the reason large programs become complicated is that there has been no emphasis on simplicity. Breaking components into smaller pieces forces you to adopt robust interfaces, but there are better ways of creating simpler programs.

My personal approach is to reason about parts of a program in terms of what they mean rather than what they do. I also have a strict rule that says, "don't change the meaning of a component, create a new one". This methodology works for me.

<comment><USER5> Can you please elaborate on "reason about parts of a program in terms of what they mean rather than what they do"?

<comment><USER4> Of course.

A good example that many people are familiar with is parsing data. Compare these two approaches. You could write functions that manipulate the input and build up an output or you could create a structure that represents a grammar for the data you are parsing (perhaps by using a parser combinator library).

In the first approach, the only feasible way of reasoning about the program is operationally; when it gets to here, this function is called, causing ... . In the second approach, you can reason about the program by considering the grammar that you created. You don't need to know exactly how the parsing happens in order to understand a grammar. I argue that this is because the grammar has been given a meaning.

Parsing makes a good toy example, but this same technique of finding ways of giving meaning to components is applicable to software in the real world.

</comment></comment></comment><comment><USER6> Modular design at any scale has a natural tension between looser coupling and higher cohesion. If you split up a large code base into many small parts, each part can be simpler and looser coupling between parts may improve maintainability. On the other hand, now you must to co-ordinate those parts somehow, and making up for the loss of cohesion introduces a kind of complexity you didn't have before.

This tension exists at any scale, from a single-developer hobby project up to massive enterprise projects and OSS giants, so I challenge the original premise of this blog post that having a large code base is the root cause of the problem. Going too far in either direction can result in absurdity, whether that's "enterprise software" levels of boilerplate (too much tight coupling) or DLL hell and typical Linux package management (not enough cohesion).

</comment><comment><USER7> Microservices are not necessarily bad, but one should also be aware of the drawback of such an approach. If there is a very tight coupling between two modules, you will often find yourself having to keep making changes between 2 different modules. The typical process goes like this:

1\. While working on module 1, you realize you need something from module 2

2\. Open module 2, add new feature and publish changes

3\. Go back to module 1, test new feature and resume work

This process is fine once both modules 1 and 2 have matured but painful to deal with while the APIs are still taking shape. Hence it makes sense to keep a good abstraction between potential components and spin them off as an individual service only when they're stable enough.

</comment><comment><USER8> This is probably another way of saying Service Oriented Architectures (SOA) works best for the enterprise. They probably already know that we should have all functionality in coarse, self-contained services.

But often the plumbing required in the form of web services becomes really painful to leverage. For instance they require creating complex WSDLs and workarounds to prevent timeouts.

<comment><AUTHOR> SOA is great, people in Java EE world use it wrong.

Instead of making small isolated services they do one single gigantic WAR file.

Instead of using right tool to do the job everything is written in Java.

Instead of having services with implemented business logic they do services that convert one DTO to another.

That sucks...

</comment></comment><comment><USER9> There is value in reading pages of legacy code. Its very common to watch new hires solve an already solved problem. Too many people are allergic to reading code it seems.

Solving complex problems in the physical world usually results in complexity in the source code world.

It is always overwhelming to jump into a new gigantic code base. Talk to someone who's been on it a while and they won't have the same drowning outlook.

</comment><comment><USER10> Certainly perpetuating the illusion that all Java code is "enterprisey" and "monolithic" will get tiresome at some point, right? I sure am tired of reading such views.

<comment><USER11> That's what I think before. Until I met Grails and Groovy. Plus their friend Scala. I'm really getting high productiveness in those languages when developing web apllications. Grails for web stuffs and Scala for non web. Before them, I used to think that Java is only for enterprise and didn't like using it for my web apps even though it was the language I'm most proficient at.

</comment></comment><comment><USER12> This seems akin to the saying that "everything should be made as simple as possible, but not simpler." Well, yeah. simplifying to that point isn't exactly easy. And, worse, the act of simplifying your code to fit this description is something that is usually done after you had it working. In other words, instead of solving another customer problem, many folks spin wheels "solving" their own "problems." Even worse, often the solution is taken to that simpler place that the saying warns against.

</comment><comment><USER13> The problem I see with lots of software is that you don't have an immediate view of the scale. Suppose you're opening a random file. What do you see? Are those the atoms or the gears? You want to see the gears but there is usually no map to point you to the gears. The software is the map - yeah, right.

What are you supposed to do? Find the int main() and then make the program run in your head?

I can make an analogy with a car - I don't know every one piece of it but I can infer from the context. The scale is evident.

</comment><comment><USER14> SOA is somewhat different to the "microservice" design it seems this author is proposing. I summarised what I could find on this - ideas from James Lewis at Thoughtworks, Dan North at DRW, and Fred George at Forward - in a recent CITCON session: [http://www.citconf.com/wiki/index.php?title=Continuous_rewri...](http://www.citconf.com/wiki/index.php?title=Continuous_rewriting)

</comment><comment><USER15> Isn't this "the Unix way"? I have seen this style of small cohesive programs promoted a lot in Linux/Unix literature so the advise isn't really breaking any new ground. Look at git for instance. The advise is of course sound but it goes against the "enterprisy" way of doing things, in part because they tend to be using huge frameworks from the get go.

<comment><USER16> On the other hand, think back to the famous macro- v. micro-kernel debate. The kernel itself is huge, and the "small cohesive service" philosophy microkernel advocates ended up never really taking over the world.

<comment><USER17> That's because kernels perform differently from user software (they have more optimizations available), and a lot of big code needs that extra performance.

That's a fact that still didn't change, but user level code is getting more powerful (mainly for virtual machines), and computers are still getting faster. So, it's still too early to declare the race finished.

Anyway, none of that has any relevance to how one should organize user level code.

</comment></comment></comment><comment><USER18> Yes yes yes yes yes yes yes yes yes. This is absolutely true.

The program-to-programmer relationship deserves to be many-to-one. It's a rewarding way to do things. You solve a problem. You add value. It's Done. You may have to go back to a program later to add features, but you don't end up with massive codeballs.

When the program-to-programmer relationship is inverted and becomes one-to- many, you get the enterprise hell with no feedback cycle, terrible code, and unnecessary complexity. It's not rewarding. Problems are never solved and software is never Done. Requirements are "collected", bundled into an incoherent mess, and delivered to bored, underachieving developers who never get to see their programs actually _do_ anything.

Large problems that require more than one person need to be solved with _systems_ and given the respect that systems deserve. Single-program approaches are a denial of the complexity (that comes whenever people have to work together) and a premature optimization.

I wrote about the political degeneracy that this creates: [http://michaelochurch.wordpress.com/2012/04/13/java-shop- pol...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/) . But it's unfair to associate it with one language. It's not that Java is any more evil than C# or C++. Any company that calls itself an X Shop is doomed.

There _are_ cases where large single programs deliver value. For example, most people experience a relational database as a single entity. There are a lot of requirements (performance, persistence, transactional integrity, concurrency) that are technically very difficult to meet and all have to work together. I will also note that it has taken some very smart, very well-compensated, people _decades_ to get that stuff right. The quality of programmers who tend to stick around on corporate big-program projects is not high enough to even attempt it, though.

So why is big-program development winning? There are a couple reasons for that. First, it gives managerial dinosaurs the illusion of control. If programs are Giant Things that can be measured in importance by "headcount", then executives can direct the programming efforts... which they can't do if the programmer's job is to go off and independently solve technical problems they deem to be important. Second, big-program design gives a home to mediocre programmers who wouldn't be able to build something from scratch if their lives depended on it but who, in teams of 50, might be as effective as 0.37 good developers. It's about control and a failed attempt to commoditize programmer talent, but it doesn't actually work.

<comment><USER19> >So why is big-program development winning? There are a couple reasons for that. First, it gives managerial dinosaurs the illusion of control.

So why do larger programs 'win' in the open source world as well[1]? Pop psychology about management doesn't seem sufficient to explain the phenomenon (although I'm sure it is a good way to sell a '101 habits of highly effective managers' book or get paid to give talks about management). Large systems are large, breaking them up into smaller pieces doesn't change that, but it makes navigating the code base harder (although I assume you don't care about that since judging from your blog posts you don't think tooling is important). It makes your interfaces less malleable (can be good can be bad), and moves a lot of communication to places where the compiler can't warn you about mistakes (again, if you don't care about tooling I guess this doesn't matter… but I would argue that this is bad).

It seems to me like systems of many small separate processes is basically dynamic OOP. Everything is late bound, dynamically typed and async. It's easy to make changes and also easy to break things. You can argue that this is better for certain problems, but I don't think it's universally better, and the community seems pretty divided on the issue too: look at the popularity of Go, statically typed and building concurrency into the language rather than using the OS like in the older C world.

Aa an aside; surely the web developer community is eventually going to grow tired of talking about how terrible Java is and how $idea_of_the_moment is good because it's 'not java'? As an outsider the obsession seems extremely unhealthy, and leads you to bizarre places like arguing against automated refactoring or interactive debugging or static type systems just because those things are associated with Java. I guess to maintain credibility I also need to point out that I don't and have never used Java…

[1] Firefox/Chromium vs uzbl, gcc/llvm/clang vs pcc, gdb vs printf debugging, sqlite/mysql vs directories and plain text files, perl vs sed/awk/grep shell scripts, emacs/vim vs ed/notepad etc etc.

<comment><USER18> On the anti-Java bias, I think the issue is that there's more than one Java culture. There's the horrid commodity developer culture, but that's not the language's fault.

I'm actually a pretty big fan of static typing. You don't get static typing's main benefits in C++ or Java, though. You have to use a language like Haskell or Ocaml, or the right subset of Scala, to see the major benefits of that.

Open-source is a bit different because people choose whether they contribute to a project. The quality of code in the active open-source world is leagues above what you find in typical enterprise codeballs, because of survivor bias. No one has the authority to mandate that code be maintained by others, so the messes are cleaned up by people who actually care, not people slogging through it to keep a paycheck coming.

The big-program methodology of the corporate world is the evil. In FOSS, the major projects are an unusual set-- code-quality at a high level just not seen in the for-paycheck commodity-engineer world and large _because of_ success-- rather than the reverse. There's a survivor bias that occurs because the best projects are the only ones people pay attention to.

The corporate world is screwy because projects become large or small based on political reasons that have nothing to do with code quality. In the FOSS world, code-quality problems related to growth will be self-limiting because no one has the authority to "force" the program to grow.

<comment><USER19> I should mention that I've never worked in the corporate world, so my reaction is in that context. I can't talk about the corporate side of things since I've never experienced it.

Also yes static typing in Java does look pretty cumbersome. Personally I'm hoping that Rust takes off, I've enjoyed playing about with it over the last couple of weeks, although it has made me less happy using the more dynamic languages I normally use to do real work.

</comment></comment></comment></comment><comment><USER20> A good program is 500 lines or less.

<comment><USER21> _I type at least 60,000 characters before inserting a line break._

I joke, but I've seen some php before that was at least 600 chars before line breaks, I have no idea how they wrote it like that.

<comment><USER22> Broken 'enter' key; it's the only way I can imagine while clinging to sanity.

</comment></comment></comment><comment><USER23> Beyond complexity management, breaking a design into many small programs opens it up to a rich set of well-known and proven OS services. Things like hardware memory protection, multi-processor support, queues, mutexes, monitoring, and cross language support. I'll take Unix over some language+standard library _any day_.

<comment><USER24> and it also opens it up to a rich set of well-known problems: sharing between processes and memory management, lock issues, system-call latencies, not to mention dealing with the monolithic environments that are almost definitely changing between each instance of your program you want to run (this 'environment' includes the shell, userspace services, kernel version and features...). Decomposing a program into multiple programs isn't always a good idea, there is a very broad trade-off here that needs to be evaluated for the needs of every program.

<comment><USER25> Absolutely. But it's better from a design perspective to start as pure as possible and then make concessions when you find your back against the wall.

Most of the "it's too hard and there's too much to do!" crowd doesn't understand the benefits of working clean.

</comment></comment></comment><comment><USER26> "Open source that libraries if possible and you'll get the feedback from the peers."

Does anyone have real experience with this (open sourcing a core piece of infrastructure and finding that others have found it, used it and provided feedback)?

</comment><comment><USER27> [http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...](http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html)

</comment><comment><USER28> My current theory is that a good program should compile in less than 1 second into an executable of less than 1 megabyte.

<comment><USER24> My current theory is that this is an arbitrary one. Its really, really, really easy to cross a megabyte with statically linked libraries.

<comment><USER29> I think the grandparent intended that the size measurement exclude statically linked libraries or assets, debug symbols, and compression technologies like UPX.

It can sometimes be beneficial from a distribution/deployment standpoint to have everything in one self-contained file. But you can't conclude much about the code quality of e.g. a computer game engine based on how many megabytes of graphics, music and sound effects a particular game based on that engine uses.

<comment><USER28> The rule is not meant to be universal, and I don't say other people should adopt it, but I think it's suitable for the work that I am doing right now.

Constraints like this can really shape a piece of software, for better or for worse. My inspiration is having work with a really powerful firmware system that had a hardware constraint to fit on a 1MB flash chip, everything included, and was done so well that it looked easy. Give yourself unlimited space and it's much easier to end up with UEFI...

I suspect quite a few programs out there would have turned out better if their authors had picked a semi-arbitrary maximum value for lines of code / bytes of RAM / bytes of disk / etc.

The actual rule I'm using for now is: \- 1 second compile excluding dependencies. \- 1 minute compile including dependencies (excl C compiler). \- 1 MB executable including everything except libc and base OS.

</comment></comment></comment></comment><comment><USER30> he's talking about adding a lot of "moving parts"...</comment>


Yourbot – I am as smart as my users. Teach me something and make me smarter - <AUTHOR> http://www.yourbot.com <comment><USER2> If it meets the guidelines, this might make a good "Show HN".

Curious about the history of its development.

Guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment>


YC Demo Day Session 1 - <AUTHOR> http://techcrunch.com/2012/03/27/yc-demo-day-session-1/

<comment><USER2> Would YC even consider putting these demos up on youtube, or would that be too distracting for the participants? It would be interesting to see how rough they start out and how they progress. Perhaps even hire an in house film maker?

</comment><comment><USER3> Even reading about these second-hand, lines like "hockey-stick growth" show the prezos were quintessentially YC.

<comment><USER4> Why?

I am curious, because I've heard that expression in many other contexts.

<comment><USER3> I've seen pg lay out a very clear way for structuring prezos, and if I remember correctly one of the rules is having a hockeystick graph without and labels and then, on the next slide, doing the reveal that it's - tada! - revenue or users or something of that nature.

<comment><USER5> The term is quickly loosing it's meaning. Obvious gaming is obvious.</comment></comment></comment></comment>


Twilio's Shadow: A proxy that aids continuous deployment testing - <AUTHOR> https://github.com/twilio/shadow

<comment><USER2> Ilya Grigorik released em-proxy [1], three years ago, which carriers out a similar role [2].

[1] <https://github.com/igrigorik/em-proxy>

[2] [http://www.igvita.com/2009/04/20/ruby-proxies-for-scale- and-...](http://www.igvita.com/2009/04/20/ruby-proxies-for-scale-and- monitoring/)</comment>


MSN Messenger to end after 15 years - <AUTHOR> http://www.bbc.com/news/technology-28987797 <comment><USER2> ...and another relatively straightforward and open protocol is finally completely replaced with a heavily obfuscated proprietary one. I've worked with MSNP including writing a working client for it, and it was quite easy to do; it's mostly text-based:

[http://www.hypothetic.org/docs/msn/sitev2.0/notification/exa...](http://www.hypothetic.org/docs/msn/sitev2.0/notification/example_session.php)

As it evolved, MS made it more complex by changing many commands to be dependent on XML and SOAP, but 3rd-party clients could still reverse-engineer and keep up. There's been talk and some action on open-source Skype-protocol clients but I haven't seen anything concrete materialise - maybe if all MSNP servers shut down, the Chinese will up their action on Skype.

The interesting thing is that MSNP8 as of now is still functional (and I'm outside of China) - the servers are still up and presence/messaging works. Probably not for much longer though, sad to see it go.

<comment><USER3> MSNP may be "straightforward", but it's definitely not open and it is a horrible protocol.

At least Skype is "the devil you know". Skype would have to be reverse- engineered regardless, so at least now you no longer have to worry about MSNP.

Anything that doesn't get replaced by XMPP or an equivalently good and open protocol is pretty meh regardless.

<comment><USER2> How is MSNP "horrible", specifically? You've worked with it?

The main difference I see between MSNP and Skype is that much of MSNP could be figured out in a day just by sniffing packets, which is probably what lead to a proliferation of alternative clients and client libraries for it. The (deliberate?) complexity of Skype means that RE attempts are more difficult, so there are fewer people with the skills and inclination to do it. Hopefully there will be more focus on it now, but it's still a _huge_ effort in comparison.

Personally, I'm not too fond of XMPP either; something more similar to IRC would be my preference. But all of that doesn't matter when almost everyone you know used/uses MSNP/Skype, and from experience it's _very_ difficult to change that, so any progress toward an open-source Skype client will be great.

<comment><USER3> > How is MSNP "horrible", specifically? You've worked with it?

Yes. I'm sure you know yourself: It's very ugly at the low level, it barely supports the minimum feature set to call it an "instant messaging protocol", and let's please not forget that is is a closed, proprietary protocol regardless of how readable it is on the wire. Microsoft has full control over it and can decide at any moment to... well, for example, shut it down.

Not saying skype is _better_ , just glad to see crappy proprietary tech die out.

<comment><USER4> "Microsoft has full control over it and can decide at any moment to... well, for example, shut it down."

Not if people decide to write their own server software for it. i.e. Something that you most certainly can't do easily with Skype as it's leaps and bounds more complicated to reverse-engineer.

" _Not saying skype is better, just glad to see crappy proprietary tech die out._ " What? Let me rephrase how I re-read your sentence: "Not saying skype is better, just glad to see crappy proprietary tech get replaced by even less open and more difficult to reverse-engineer tech."

Why would you be glad about that? You're contradicting your own viewpoint about how bad "proprietary tech" is by advocating it's replacement by an even more " _proprietary_ tech"

<comment><USER3> I'm not advocating anything else than XMPP; I'm just being practical. MSNP is one less proprietary protocol to worry about.

<comment><USER5> Well from the practical perspective what happens is what zo1 wrote: "crappy proprietary tech get replaced by even less open and more difficult to reverse- engineer tech". What's more likely - former MSN users switching to XMPP or to Skype?

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> The day Messenger died for me was when all my friends moved to Facebook instead.

The halcyon days where IM was somewhat private.

Shame they took so long to bring it to mobile devices, too.

</comment><comment><USER7> Microsoft also recently killed off SkypeKit which allowed 3rd party applications to interact (text/voice) with the Skype platform on Windows. They are saying as it wasn't cross platform it wasn't a good solution however it has crippled Trillian (and others) which I used daily for Skype.

Since I find the actual Skype client to be one of the worst pieces of software ever written I've started introducing everyone to GTalk/Hangouts and so far most are changing over.

</comment><comment><USER8> I worked on a few features in MSN Messenger, and I'm sad to see it pass, but the time had come. I hadn't logged in to use it for almost five years when it was shut off in the US.

</comment><comment><USER9> Though primarily an AOLIM and Yahoo Messenger user back then, I remember when MSN Messenger's "British phase-out" occurred around 10 years ago [~2004?]. I had a couple folks from the UK in my list, and we had to go over how else to chat [AOLIM, Yahoo].

I ended up phasing myself off MSN Messenger not too long after. Still a "place in my heart" type situation.

</comment><comment><USER10> There are several people I do not have contact info for that I have fleetingly seen on my MSM account in KTP in the last year. It will be a shame if they shut off their XMPP servers, because then I have no way to reach them.

</comment><comment><USER11> I appreciated the ability to have a messenger running on the computer which would always notify me of new messages, instead of having a Facebook tab open in the web browser.

<comment><USER12> Facebook chat is just XMPP, you can use desktop clients to receive messages. Facebook themselves recommend Pidgin and Adium: [https://www.facebook.com/sitetour/chat.php](https://www.facebook.com/sitetour/chat.php)

<comment><USER13> no group chat.

</comment></comment></comment><comment><USER14> >MSN Messenger is survived by Facebook, MySpace, Twitter, Snapchat, Skype, Google+ and Instagram.

Apart from none of those are actually chat programs, except for Facebook Chat.

<comment><USER15> And Google+'s Hangouts. And Skype's IMs. And tweeting to each other can also be seen as chatting.

I'd say the biggest chance is the fact that all of them are web-centric or mobile-centric.

</comment></comment><comment> guard-of-terra It is also survived by ICQ which it tried to MS-overtake.

</comment><comment><USER16> Bye Bye MSN... no more nudge :(</comment>


Ask HN: What are your favorite startup podcasts? - <AUTHOR> Dear HN,
Lately, I have been trying to find quality startup podcasts. Besides the famous ones, it wasn't easy for me to discover new ones. Can you help me listing your favorites? How do you find them?
Thanks a lot in advance! <comment><USER2> I like this week in startups, tim feriss, stanford innovation lab, and mixergy

<comment><AUTHOR> Thank you!</comment></comment>


Try Julia - <AUTHOR> http://forio.com/julia/repl/ <comment><USER2> Fun with Julia:

        julia> 3 ** 60
        syntax: use ^ instead of **

        julia> 3 ^ 60
        -3535985420588157519

        julia> factorial(45)
        -8797348664486920192

        julia> factorial(75)
        0

        julia> 5 * 5555555555555555555
        -9115710369641325457

        julia> 5 * 55555555555555555555
        syntax: invalid numeric constant 55555555555555555555

This isn't C. The expectations have changed thanks to scripting languages. If I'm supposed to use this promising language to do calculations and manipulate data, I'd expect to be able to natively handle large numbers without overflowing.

<comment><USER3> Julia supports arbitrary precision arithmetic just fine, but you need to explicitly use it. Overflow checks don't matter in Python or Ruby where everything is relatively slow.

See also: [http://www.johnmyleswhite.com/notebook/2013/01/03/computers-...](http://www.johnmyleswhite.com/notebook/2013/01/03/computers- are-machines/)

<comment><USER2> My point wasn't that it can't be done. My point was about usability and what programmers have come to expect from a modern language. I understand that things get trickier when trying to implement arbitrary-precision arithmetic while keeping performance high.

<comment><USER3> Do you have an example of a language with arbitrary-precision overflow by default _and_ comparable performance?

<comment><USER4> > Do you have an example of a language with arbitrary-precision overflow by > default and comparable performance?

No, but that also means Julia isn't much special then either right?

Maybe it is just me but Julia positions itself as a better Python not just a better C, in that position, can you really blame people if they misunderstand and expect same "high level" behavior from it?

<comment><USER5> > _No, but that also means Julia isn 't much special then either right?_

That's a really dumb conclusion. It's special in other things it offers (from a better Matlab like language with crazy ass speed to homoiconicy and great FFI). Who said it's only special if it fulfils some specific rainbow-unicorn pipe dream?

It also doesn't read the programmer's thought -- so not special in that regard either.

> _Maybe it is just me but Julia positions itself as a better Python not just > a better C, in that position, can you really blame people if they > misunderstand and expect same "high level" behavior from it?_

Lots of people also find Go a "better Python", and Go is like assembly compared to Julia...

</comment></comment></comment></comment></comment></comment><comment><USER6> Am I crazy for feeling like Julia is the new HN darling like clojure, go, ruby, lisp, and scala before it?

It seems like in the last week it just started popping up on HN every couple days.

<comment><USER7> HN goes through phases, which I rather like. This way, we get semi-in-depth coverage of topics serially instead of always uniformly dividing our attention among all interesting projects at the same time.

</comment></comment><comment><USER8> I've been struggling with building a C++ library for astrodynamics simulations (anything involving the motion of objects in space) within my research group for the last four year. The biggest problem is that for our applications, performance-wise a lot of high-level languages just don't cut it (particularly MATLAB, which is pushed down our throat from freshman year onwards). After some deliberation (and before Python really caught my eye) I opted for C++. That unfortunately brings with it an incredibly steep learning curve for new students who typically aren't interested in programming, but just want to get to the fun space mission analysis stuff. As a result, the project has grown a lot, but interest is waning. Julia seems like the ideal blend between high- level and high-performance.

As a general question, is Julia Studio the best way to go about setting up a workflow? Or should I go with something like a Julia plugin for Sublime Text (which I believe exists). Or are there any other tools out there that make Julia dev straightforward?

<comment><USER3> Regarding workflow, the best option is IJulia ([https://github.com/JuliaLang/IJulia.jl](https://github.com/JuliaLang/IJulia.jl)) which has nice integration with plotting and useful things like LaTeX. Vi and Emacs are well-supported, and I know the Sublime tools have gotten a lot of attention from several people.

Not directly related to performance, but you might be interested in this: [https://github.com/helgee/JPLEphemeris.jl](https://github.com/helgee/JPLEphemeris.jl)

<comment><USER8> Very cool, thanks for the tips!

That JPL Ephemeris library has given me an idea. I think I might try porting over the NAIF Spice [1] toolkit to Julia. It has MATLAB, IDL, C and FORTRAN ports so I think Julia would fit right in there.

[1] [http://naif.jpl.nasa.gov/naif/](http://naif.jpl.nasa.gov/naif/)

</comment></comment></comment><comment><USER9> It's really easy to try Julia by just downloading it: [http://julialang.org/downloads/](http://julialang.org/downloads/).

I'm becoming increasingly convinced that Julia is the future of technical computing. We've just started pulling together a BioJulia team - if anyone is interested drop an email (in profile).

<comment><USER10> Honestly I'm convinced it's a lot more generally applicable than scientific computing. Much of heavy lifting I had to do in C, I can now do in Julia with nearly the same speed and efficiency. Plus, for a lot of the problems I would have chosen Python, Ruby, or even Clojure for, I could really see myself using Julia now.

<comment><USER11> +1 Besides libs and ecosystem in general, I don't see any advantage Python / Ruby / Clojure have over Julia.

<comment><USER12> Eh, in the case of Closure pervasive immutability, I don't want to write imperative code anymore. I am sure you could write in a functional style in Julia but all the code I have seen seems to rely pretty heavily on explicit stateful loops. At that seems to be a design choice not just for speed but, from what I have read elsewhere, to be familiar to Fortran and Matlab people, seems like a bad trade off to me.

<comment><USER11> Removing loops or mutability from Julia would be a terrible decision. There's nothing inherently wrong with mutability or imperative programming.

<comment><USER12> I just was answering the case for the advantage of Clojure over Julia as a general purpose language. And pervasive immutability is an advantage in that case. I agree Julia needs mutable arrays, I think for the domain it is targeting mutable arrays are a must but that should not mean that it needs big old imperative loops absolutely everywhere either.

<comment><USER11> Imperative and mutable isn't inherently wrong, even in a general purpose language like Julia.

In Clojure it's hard to write imperative code, which was one of the reasons I've left. Sometimes, imperative programming is the best way to code something. Sometimes it's best to do it in a functional way. Julia can do both.

The same is true for mutability. I understand the advantages of immutability but I think it's overhyped. Besides the obvious advantage of mutability - performance - it sometimes makes for more readable and shorter code. And what if you have some complex nested state and need to change a small part of it?

BTW - what do you mean by functional programming exactly, how does it differ from imperative programming in your view?

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> The Server version of Ubuntu or the 12.04 version does not have the add-apt- repository command. How can i add a PPA to the server without this command? Answer in [http://askubuntu.com/questions/38021/how-to-add-a-ppa-on- a-s...](http://askubuntu.com/questions/38021/how-to-add-a-ppa-on-a-server)

There are several options, I chose the one with sudo gedit /etc/apt/sources.list and

1514 sudo gedit /etc/apt/sources.list 1515 sudo apt-get update #not needed 1516 sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3D3D3ACC 1517 sudo apt-get update 1518 sudo apt-get install julia (there are broken dependencies) 1519 sudo apt-get install libopenblas-base 1520 sudo apt-get update 1521 sudo apt-get install libopenblas-base 1522 sudo apt-get install libatlas-base-dev 1523 sudo apt-get install libopenblas-base 1524 sudo apt-get install julia 1525 julia 1526 history | tail 1527 history | tail -n 20

</comment><comment><USER10> Not seeing a prompt. It might be because of the internal "POST [http://forio.com/julia/repl/sessions](http://forio.com/julia/repl/sessions) 503 (Service Unavailable)" error?

<comment><USER14> Probably got "slashdotted".

<comment><USER15> Yes, we've been slammed. We are shrinking the timeout and bring up more servers. But our capacity is not unlimited. Folks might have to come back later.

</comment></comment></comment><comment><USER16> Is round(x) broken?

        Julia's standard library includes a host of mathematical functions, in addition to the standard operators. Complex numbers are also supported, using the built-in im unit:

        round(pi)
        lcm(54, 392, 232) # least common multiple
        sqrt(square(100))
        e^(pi * im)
        log(e ^ 2) + log10(100)

        When you're ready, type "next" to continue
        julia> round(pi)
        no method round(MathConst{:π},)

<comment><USER17> round(x) only works for a few specialised types of x. help(round) tells you that it will return the same type then. Of course for a type of MathConst{:π}, that won't work. For generic types, you need to at least specify the number of digits (round(pi, 3)). (See also: methods(round))

<comment><USER18> Weird that they have round(pi) as an example.

<comment><USER19> It may have worked at some point. The language evolves pretty quickly at the moment.

</comment></comment></comment></comment><comment><USER20> Julia appears to be a perfect fit for much of what I do at work. I tried it, got very excited, and then facepalmed earlier today. Let's define two functions in the REPL:

        function foo()
          return 42
        end

        function bar()
          return foo()
        end

Evaluating bar() gives 42, just as one would expect.

Now let's redefine foo():

        function foo()
          return 69
        end

Evaluating bar() still gives 42!

Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight. Actually, oversight isn't the right word, since broken automatic compilation has been a known problem for two years: [https://github.com/JuliaLang/julia/issues/265](https://github.com/JuliaLang/julia/issues/265).

<comment><USER3> _Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight._

No one denies that this is a problem, and it will be fixed. But I disagree that it represents a fundamental flaw. For iterative development, it is a minor inconvenience, so other priorities have taken precedence. If you are redefining functions in this way in tested code, there may be bigger problems to worry about.

The Julia developers have paid fastidious attention to correctness (to the point of making a pilgrimage to visit Kahan early on). The type system is well thought-out and nice to use. Spurious crashes are almost nonexistent (and fixed within hours, without fail). The foundation is solid, but it's still a work in progress, and it will take some time to shake these sorts of features out.

<comment><USER20> I was cheering out loud when I first downloaded Julia and started working with it. The type system, multiple dispatch, so much win! I'm working on ionospheric ray tracing at my day job and would love to use Julia.

But when I can write a nine-line example that produces incorrect output—no thanks. Especially when one of the lead developers (see the linked thread) states that supporting function redefinition isn't needed for v1.0. Clearly these people are working under a very different set of priorities than me.

"The foundation is solid"—I do not think it means what you think it means.

<comment><USER5> > _Clearly these people are working under a very different set of priorities > than me._

Yes, they are pragmatists.

Plus they know that the language is the first priority, not the REPL.

</comment></comment></comment></comment><comment><USER21> You can also try Julia in your browser here: [https://cloud.sagemath.com](https://cloud.sagemath.com) However, you have to (1) make a free account, (2) create a project, (3) open project, click on "+New", click Terminal, (4) type "julia". If you create a .jl file instead of a Terminal (at +New), you'll have proper Julia syntax highlighting and indentation; you can then run that file from the terminal... (Disclaimer: I'm the founder of SageMathCloud.)

<comment><USER22> You could have had more users if your url was:

[https://cloud.sagemath.com/new/jl](https://cloud.sagemath.com/new/jl) ;-)

</comment></comment><comment><USER23> Can julia yet do the equivalent of the following Octave code:

proportion_value = x ./ sum(x)

The blocker for me with julia is translating my vectorized way of thinking into loops. I know the loops are optimized, but yuck.

<comment><USER11> Yes, this works in Julia without any changes.

</comment></comment><comment><USER13> Julia is very fast, 0.12 second, 0.60 second for sbcl (lisp)

julia>function haz(n) s = 0 for i in 1:n if i % 2 == 0 s = s+1 else s = s-1 end end s end haz (generic function with 1 method)

julia> @elapsed haz(10^8) 0.12459633

Compare with lisp sbcl on the same machine:

(defun haz(n) (let ((s 0)) (declare (optimize (speed 3) (safety 0)) (fixnum n s)) (loop for i fixnum from 1 upto n do (if (zerop (mod n 2)) (incf n) (decf n)) finally (return s))))

</comment><comment><USER24> A lot of the comments I see about Julia (and other trendy high level languages) are of the following form:

"I can do things I needed C to do before, and almost as fast"

which leads me personally to ask,

If you could do this in C before, and faster, then why are you switching?

Most people will say "because C is bad/difficult/clumsy for doing X"

which leads me to say,

why are you using C to do X?

I sincerely believe (as a computational scientist) that a combination of a high-level language for real-time interactive exploration and prototyping with a fast language like C for doing the actual gruntwork, is the best.

Attempts to combine the best of C (speed) with the best of scripting languages (easy to do things fast without having to pay attention to what you are doing) in my opinion end up merely joining the worst of both worlds rather than the best of both worlds.

Besides isn't programming about being specific? Do you really want to code stuff without having to worry about the details?

<comment><USER25> You can see it as an alternative to Matlab/R (sorta)/numpy not C.

People only ever used C when speed was crucial and depending on what you were comfortable in or what you had learned maybe Fortran for speed instead of C.

Julia is meant for scientific computing with some nice features. As I see it it is similar enought to Matlab to be easily learned by those who use Matlab but has enough goodies that it can be a viable alternative.

Programming isn't about being specific it is about accomplishing a task and many times yes you don't want to have to worry about the details as long as it works the way it should.

<comment><USER24> I agree with what you say. More and more though as I get on in my career as a scientist I realize though that the details turn out to matter, sometimes a great deal.

Anyway I'm all in favour of an open, fast MATLAB alternative

</comment></comment></comment><comment><USER26> koding.com is another way to get an interactive REPL online: [https://koding.com/Julia](https://koding.com/Julia)

<comment><USER27> oh awesome resource, thanks for the link! (looks down from overuse right now but still, cool!)

julia++, i started playing with it this weekend and i'm super pleased. i concur with another comment in this discussion that this is what i wish python had been evolving into. it gets me wondering if python is maybe being left behind compared to other dynamic languages or if it's just fad-ism at work (or me just learning more about languages and features).

</comment></comment><comment><USER28> a big white page is not really the best introduction ever (or am i missing the point/humor?)

<comment><AUTHOR> It was working, until I submitted it here. Maybe too many people Trying Julia.

<comment><USER15> Yup, we've been properly slashdotted. Attempting to bring up more servers and shrinking session timeout. But...

</comment></comment></comment><comment><USER29> Doesn't seem to work - would love to find a great resource on Julia

<comment><USER10> I've found the docs[1] to be extremely easy to follow, as a nice blend between a tutorial and a spec.

[1]: [http://docs.julialang.org/en/latest/manual/](http://docs.julialang.org/en/latest/manual/)

</comment></comment><comment><USER30> Adblock on Chrome is blocking the command prompt by default. At least on my system...

</comment><comment><USER31> After typing next about 20 times without seeing anything interesting, I quit.

</comment><comment><USER32> Everything returns:

       Undefined
       500

Is this broken?

<comment><USER15> Our Julia REPL servers been slammed. We are shrinking the timeout and bring up more servers. But our capacity is not unlimited. Folks might have to come back later. Sorry about that.

</comment></comment><comment><USER33> The pi constant didn't work for me

</comment><comment><USER34> no method round(MathConst{:π},)

<comment><USER35> +1</comment></comment>


Ruby Padding Issues with Base64 Decoding - <AUTHOR> http://blog.vidyard.com/request-signing-and-ruby-padding-issues-with

<comment><USER2> Great article!

Why is it that the encoded string needs to be divisible by four before you can decode it?

<comment><USER3> If I remember the decoding process right, it's basically just taking 4 characters at a time, multiplying by (6/8) (which is 3/4) to get 3 characters.

This doesn't make it impossible to decode less than 4 characters, but you can't tell if the shortage is due to an error (early truncation) or just the padding being stripped (the article doesn't make it clear, but = is the traditional padding character used to make the encoded text have the proper length). Obviously both encoder/decoder will need to agree on the padding style to be used if it is important that encoded text be canonical.</comment></comment>