What 5G Will Mean for You - <AUTHOR> http://www.nytimes.com/2016/02/22/technology/what-5g-will-mean-for-you.html <comment><USER3> Personally, I'm just hoping that 3G will eventually make it to England. That seems more realistic, though I don't doubt that the Bay Area will be happily basking in this 5G niceness by the time it happens.

I just got back from 3 months in Southeast Asia, and it's just baffling to me how I could get fast data to my phone in virtually unlimited quantities, out in the sticks of rural Cambodia, for five dollars. But coming back to England, my town of 25,000 people has neither working DSL nor cellular data.

I keep a 3G router in the desk drawer to battle the bi-weekly half-day outages that BT routinely delivers, but that also will happily drop down to 300 baud if anybody else in town decides to use the internet at the same time.

It is certainly solvable. But the monopoly internet supplier doesn't seem to have it as a priority to supply internet.

<comment><USER4> Curious - which town are you in? I have 4g and 200mbs-1 fttp and I live in a field in the middle of suffolk.

<comment><USER3> The North. Kendal, specifically.

One day Virgin will route a cable our way, and life will be good. Until then we're stuck with BT and their 200 year old copper (and a few cell towers without enough power to drill through the stone buildings in town, let alone the little hills around it).

<comment><USER5> Maybe Kendal should come together and investigate building your own [http://b4rn.org.uk/](http://b4rn.org.uk/)

Actually you're right on the edge of the coverage area, why not contact them and see what it would take to extend it.

</comment></comment></comment></comment><comment><USER6> 4G definitions are still largely being fought over, and you're gonna try and jam "5G" down my throat?

The entire article is complete speculation, and the sad part is that they don't even talk about the cooler ideas they're coming up with for the specification.

For anyone wondering about 5G I think the coolest thing they've discussed so far is breaking down the different use cases (people in home, people traveling on trains, vs working in an office building) because these put completely different types of strain on a network. They're trying to come up with sub specifications to encompass more types of network use cases rather than thinking "xG is for cellular phones" it'll be more like 5Gx is spectrum/protocol for home internet, 5Gy is the spectrum/protocol the phone uses. Although from a marketing prospective this will sound like "Bring 5G to your home."

Honestly I'm surprised that didn't happen with 4G, I know there are things like Clearwire (I think they were bought by sprint?) but it wasn't a huge move from physical infrastructure.

For some more realistic info on what's happening:

[https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0....](https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf)

EDIT:

On a small note, this is "finalized" pdf but in reality it will change when implementation occurs.

<comment><USER7> This is totally wishful thinking. No one in industry has a slightest idea what 5G will be. We keep throwing fancy terms like eNodeB virtualization and then we have a reality check - LTE userplane cannot be virtualized due latency and performance reasons (LTE PHY on x86 - yeah, right...).

Same goes to those mm waves with beamforming - no DSP (IP core) can handle it now and even soon. You need to stick with very expensive FPGAs. Besides that there is WiGig coming and you can offload traffic from LTE to Wifi - <USER2> in those mm wave small cells seems rather pointless.

Beside that you can get those multi-Gbps with new Rel13 LTE carrier aggregation (up 32 CC).

<comment><USER8> It is possible to do compliant LTE phy on x86, of course it is not so energy efficient. Also x86 + fpga SoC is coming soon and could be interesting for that kind of purpose. Though I don't think baseband virtualisation will be something big in the near future.

And LTE CC is not the necessarily a good way to get multi-Gbps due to radio complexity.

<comment><USER7> I have seen such projects - real LTE PHY algorithms are much more complex than stuff in 3GPP. You can write something 3GPP compliant in some simplified cases, but it would be totally useless in real network.

Secondly you don't really want to use FPGA for majority DSP processing in LTE PHY. Design cycles on FPGA are too slow and HLS techniques are still not trusted. Beside that x86+fpga are some kind of specialized stuff - you could just put a PCIe accelerator with some major wireless SoC.

<comment><USER8> Modern x86 is quite competent as DSP using AVX. I think you are exaggerating. I have worked with LTE baseband as well, but admittedly never done an x86 LTE PHY. pCell claims to be doing quite complex network mimo LTE stuff on x86, still mostly vaporware though.

Regarding FPGA, of course you don't do the complete implementation in it, you accelerate the low level stuff, FFTs, coding, etc, as are already done in all baseband dsps.

<comment><USER7> Yep, AVX is nice, but still it is far from current DSP chips. I ported a subset of PHY to real AVX2 CPU and AVX512 sim. It is (sometimes) comparable to c6x (which is a crap DSP) if you take (much) higher clock into account, but comparing to current DSP IP cores it is a joke.

</comment></comment></comment></comment></comment></comment><comment><USER9> > Driverless cars with extremely fast response times

Seems like relying on low network latency for critical safety features is designing a fundamentally flawed system.

Is this really how driverless cars are being made or is the author just pulling things from his ass

<comment><USER10> Surely it's the latter. Driverless cars that rely on Internet access would not be feasible, for obvious reasons.

Driverless cars will likely eventually communicate via some peer-to-peer wireless technology, but I would assume that would use a different set of protocols than our mobile phones do.

<comment><USER8> Even LTE is including Vehicle 2 Vehicle (v2v) communication and Vehicle 2 infrastructure (v2x) and so will whatever 5g becomes of course (5g will be the continued evolution of LTE + mmwave physical layer basically)

</comment></comment></comment><comment><USER11> > What 5G Will Mean for You

Absolutely nothing for the next 20 years, seeing how my carrier just started deploying LTE (50 MBit, that is, not 300 MBit) at eye-watering costs ($20 a month for 5 gigabytes!).

<comment><USER12> Switch to T-Mobile. Unlimited data + LTE.

<comment><USER13> As a happy T-mobile customer, I do understand that limited coverage makes it unfeasible for many. For example, I live in rural New England and cannot reliably get signal (even for SMS) in certain towns nearby. I've never gotten signal in Vermont.

<comment><USER12> In major cities - I've found it's better than AT&T was for me.

Still a problem when I end up back in Indiana from time to time, but most of my time is in the cities or international (where they have free data + texting included in the plan).

</comment></comment></comment></comment><comment><USER14> It seems like it will just mean you can hit your data cap faster.

<comment><USER15> Agreed. I've got 4G at the moment and it's plenty fast, since I can only use it for moderate surfing/etc since I'd otherwise hit my monthly cap in a week. If I had super fast 5G, I could accidentally burn through my cap in a day.

<comment><USER16> I had a prepaid Telstra SIM in Australia. I speedtested 130 MBit/s on their LTE network. On prepaid, data costs a bit over AU$8/GB. So you can burn through 8 dollars in a minute.

</comment></comment></comment><comment><USER17> > With 5G, downloading feature-length movies could take less than five > seconds.

> With 4G, downloading feature-length movies could take as long as eight > minutes.

Am I wrong in thinking that an operator would prefer to keep their antenna busy for only 5 seconds instead of for 8 minutes? If this is the case, if they have enough bandwidth to the antenna, they should try to move people to 5G quickly.

But you still need 90 minutes to watch the movie and you probably reach the monthly cap with only a few movies, so maybe this is not the main use case for 5G. The reduced latency to 1 ms is much more interesting.

<comment><USER18> What's a monthly cap?

<comment><USER19> It's that small hat that you're supposed to change every 30 days.

</comment></comment></comment><comment><USER20> The development of the 5g standard and it's deployment is something to look forward to, but one issue that remains is data caps.

We need to remember that the vast majority of people access the Internet primarily through mobile devices and broadband penetration is very low in developing nations.

So even though people have access to high speed internet though mobile networks, data caps act as a hindrance to utilize the service effectively.

The issue that needs to be addressed immediately is making unlimited data available at low costs.

<comment><USER21> > The issue that needs to be addressed immediately is making unlimited data > available at low costs.

Unless you can make radio spectrum unlimited (you can't), data caps and/or throttling are going to be a reality for the foreseeable future.

</comment></comment><comment><USER22> > With 5G, downloading feature-length movies could take less than five > seconds. With 4G, downloading feature-length movies could take as long as > eight minutes.

But will it move everybody back to download versus streaming. Be interested to know how much of streaming start time is network time to first byte versus authenticate/authorise/check geo-fence admin activities? So would be slightly faster start time and may be less likely to degrade. However, streaming operators if they switch to download are going to have to deal with sending bytes that are never watched. Would be interesting to know how much is downloaded from Amazon Video that is never watched.

> These machines will have to communicate almost in real time with everything > around them to avoid cyclists and other obstacles. That can happen only if > carriers offer one-millisecond latency, something that may become a > lifesaver if autonomous cars become a reality.

Will only be possible if there is a guaranteed quality of service. Would be interesting to see how your EULA/T&C of mobile service are written/rewritten to cover life critical usage scenarios.

> ability to go online no matter where they are, forcing operators to extend > their networks to practically every corner of a country.

What sort of frequencies are available to 5G and how will that propagate compared to other options?

<comment><USER23> > However, streaming operators if they switch to download are going to have to > deal with sending bytes that are never watched.

Each day that goes by will make streaming operators care less. A gigabyte costs a fraction of a penny to transmit at current IP transit prices.

</comment></comment><comment><USER24> > negotiations are expected to persist until at least 2019, so 5G cellphone > networks will not become widespread in the United States or elsewhere until > well into the next decade.

Worth noting that Nokia and NTT DoCoMo will be making efforts to get an outdoor 5G network in place in time for the 2020 Tokyo Olympics.

3/2/15: _The companies said they have achieved super-fast data transmission speeds of higher than 2 gigabits per second in a joint indoor trial using Nokia Networks ' radio technology operating in the 70 gigahertz spectrum band._ [1]

Nokia demonstrated 5G on their commercially available Airscale base station at MWC this year. [2]

[1] [http://www.reuters.com/article/us-telecoms-mwc-ntt-docomo- id...](http://www.reuters.com/article/us-telecoms-mwc-ntt-docomo- idUSKBN0LY0FD20150302)

[2] [http://networks.nokia.com/news-events/press-room/press- relea...](http://networks.nokia.com/news-events/press-room/press- releases/nokia-is-first-to-run-5g-on-a-commercially-available-base-station- mwc16)

</comment><comment><USER25> It won't matter much because there's not much you could do with 5G that you can't do with 3/4G. Internet connection speed is rarely a bottleneck for casual usage now (browsing, watching steaming videos, chatting etc.) For IoT it won't matter too, because for most telemetry/control means even <3G was ok and WiFi/Bluetooth/ZigBee is still preferable solution as all these xG modems cost way too much. To sum up, unless we start steaming virtual reality, I really don't see many benefits of 5G for few/several years to come.

<comment><USER26> That is very wrong. There is for instance a lot you can do with 4G that was not possible with 3G. With 3G the more devices the worst the throughput for all. LTE time slices and runs qos for all devices so it does not degrade with increasing device count. However there is a general linit in the the cell which is hard to raise making it uninteresting as a replacement for fiber. Future standards want to remedy this.

<comment><USER25> I agree that there a lot of technological advances and infrastructure will be much more efficient and robust, but I assume this article was what 5G means for _me_ , not my carrier. Currently (good) carriers solve congestion problem by installing more and smaller cells which is costly solution and that's why their drive to 5G is understandable.

<comment><USER26> > but I assume this article was what 5G means for me

Why would that not be for "you"? When LTE rolled out in my country my usage pattern shifted. I paid up for higher/unlimited data allowance and can truly work remotely now unhindered. That includes data and latency critical tasks.

</comment></comment></comment></comment><comment><USER27> You'll be able to burn through your monthly data cap in seconds rather than the hours that it takes with LTE. Progress!

</comment><comment><USER28> Is 5G becoming a spec by some standards body or will it be the same marketing- only type of term 4G was?

</comment><comment><USER29> I'm quite happy with existing speeds. The problem is data caps.</comment>


Evolution of the Cameraphone: From Sharp J-SH04 to Nokia 808 Pureview - <AUTHOR> http://www.hoista.net/post/18437919296/evolution-of-the-cameraphone-from-sharp-j-sh04-to

<comment><AUTHOR> Let me know if you think I've missed out any 'groundbreaking' camera phones. Yes, I know there isn't an iPhone there, because from a Camera-Phone perspective, the camera has not been anything special.... the Apps have, but the camera itself hasn't</comment>


Ask HN: What are some best dev blogs to follow? - <AUTHOR> <comment><USER2> These older threads list some blog aggregation websites, dev.to seems popular lately. Personally I subscribe to a couple of language specific [https://cooperpress.com/publications/#newsletters](https://cooperpress.com/publications/#newsletters) newsletters.

"Ask HN: What are your favourite developer blogs?" [https://news.ycombinator.com/item?id=15154903](https://news.ycombinator.com/item?id=15154903)

"Ask HN: What are some good technology blogs to follow?" [https://news.ycombinator.com/item?id=13849430](https://news.ycombinator.com/item?id=13849430)

<comment><AUTHOR> Thank you so much.</comment></comment>


Ask HN: How to switch from software engineering to sales - <AUTHOR> I have worked as a software engineer for over a decade. I have always been fascinated by the sales process. Any suggestions on how to switch?
My big problem is that I have only limited sales experience. I have done some non-profit fundraising. And I taught programming classes for a year, which I sold with some success.
How can I acquire the kind of sales experience that would make me get hired into enterprise sales?
Are startups a good place to try? Or should I aim for larger companies?
Any tips or suggestions would be great. Thanks! <comment><USER2> One other thing, my motivation for doing that kind of work is basically the same as yours: Fascination with the sales process.

Truth is, that process can be approached technically. There is more of a science to it than one would believe at first glance.

For those who do that, the rewards can be significant. One example is qualification. Work smart, not hard. Opportunity costs on poorly qualified deals is huge! Often, the fall back is just to entertain a ton of deals and hope for good numbers.

A technical approach to this will yield dividends. Good qualification requires a keen understanding of the prospect, their ability to buy, their willingness to buy and what their value perception is as opposed to what they are telling you it is. Their process is critical too. A poor selection process can have a major league impact on the overall potential for success.

Critical analysis of these things will focus you and your team onto closable deals more of the time.

It's been a lot of fun, and I really do enjoy the more complex, high risk, high reward scenarios. When you are part of, or are leading a great team, it's all kick ass great!

The other place I've found I really enjoy is competitive analysis. Competing products overlap, and or offer different approaches to value. How people see that value is complicated, and the competitive analysis can yield very high value information useful to your team, you as a sales person for qualification, and the product managers seeking to maximize the product.

<comment><AUTHOR> @ddingus Thanks! These are all great.

I am definitely interested in sales more than pre-sales. I want to qualify leads and work smart instead of building proof-of-concepts for badly qualified leads.

The question is how do I get started in this.

Do you have any suggestions for how to find VARs?

<comment><USER2> What tools do you use, or have familiarity with, or are interested in?

Follow those back to the vendors, and then from the vendor, find out who is in their channel sales organization.

Have lunch with the regional managers and basically pitch them on what you want to do. They will either see potential or not, and if they do, they will have some of their partners in mind and hook you up for a follow on discussion.

That dialog will tell you a lot.

You can also go to the VAR directly. Many enterprise B2B software houses have a direct sales force for larger accounts and a channel sales force for smaller accounts. (vars)

For a given kind of enterprise software, there are also services typically associated with them. You can do sales on both, or one or the other. Services through their organization are targeted toward the larger or major accounts. VAR organizations are more oriented on smaller or growth type accounts.

What you need is a keen interest in the software or service, ideally some experience using it, relevant industry experience, or willingness to do all of the above. The more you lack, the less you will get to start, but you can also get in and learn a lot too.

I got my start in CAD. I love mechanical CAD, am really good at it, have a lot of direct, applied industry experience, and enjoy the sales process immensely. I do not do it full time at the moment, contracting instead, but that's also due to a career shift into management that I'm doing personally.

That was a fairly easy path. Perhaps you've got some similar experiences to leverage.

You may have to either:

1\. Take a modest sales position to get some experience. That might mean inside sales, cold calling, etc... Those are considered foundation type things and they demonstrate your character as a hunter, farmer, etc...

2\. Do some pre-sales to participate in deals and work your way up to sales.

3\. Take much higher risk, like commission only sales, where their investment is low, and you can make it instead.

</comment></comment></comment><comment><USER2> I have a few suggestions.

First, I am technical with lots of experience in manufacturing, systems, software (CAD) and some programming. (mostly low level / embedded type programming) Just for context.

Do you have people skills? I got them from the performing arts and various other activities in my life. Basically, if you have a personality and can just engage people, you may be well suited for sales.

Secondly, will you close? This is the qualifier. Lots of technical people will support the sales process, but are reluctant to close. Asking for the business can be extremely difficult for some people.

Based on that qualifier, you may consider pre-sales, which is basically supporting sales people by defining the value proposition, technical proof of concept, discovery, demonstrations, competetive (fun), etc...

Or, you might consider sales and lead others to do your pre-sales support.

If you think you are the latter, you could do very well in enterprise sales as you have technical qualifications that really help you directly understand the deal, it's worth, viability, etc... You can also get some credibility strictly sales only people often find more difficult to establish, though the good ones do establish it by selling their team as well as the software solution.

Suggestions:

1\. Consider a VAR. Many VAR type organizations aren't always the best places to work longer term, but they are also more willing to take risks on good people wanting to get into sales. Many are technically hungry and or wanting to improve on their close rates with better / more sales people.

You could approach a VAR for either pre-sales, or sales and perhaps accompany an existing team to learn the ropes. From there, you would get your number and start hunting! Or, you find you are more pre-sales oriented, and join a team and start helping put deals together.

2\. With no direct sales experience, you might also consider applying at an enterprise company for pre-sales. This is a more formalized environment, and you will get a lot of exposure to the sales process, network with sales people, and maybe get some opportunities to close deals.

Good pre-sales people can be hard to find. If you are personable and able to communicate complex concepts to people successfully, you probably won't have much trouble.

Startups are a mixed bag, compared to established B2B enterprise companies. Risk is higher, but so is the excitement level.

One thing you need to consider is risk / reward. Many technical people are risk adverse and prefer consistent income. If this is you, target pre-sales.

On the other hand, if you are fairly secure taking some risk, sales can pay very, very well.

Good luck. Have fun!</comment>


AirPods and the Three Stages of Apple Criticism - <AUTHOR> https://medium.com/@ReThinkReviews/airpods-and-the-three-stages-of-apple-criticism-fed70b84e435 <comment><USER2> How about one stage of Apple (and numerous other tech) criticism instead: I hate sluggish things.

AirPods are sluggish.

That is, they introduce worst-in-class latency of about 1/3 of a second[1].

Why do I care? Because making music is nauseating when you press a key, and the sound doesn't come right away. Even latency as low as 1/100 of a second is felt[2] - that's about the standard for acceptable latency.

Rhythm games are likely out of question too (unless the devs took care to measure and compensate for this latency).

When iProducts came out, there was a huge emphasis of them being a creation tool for artists and musicians. AirPods show that, sadly, this is no longer the emphasis.

In general, latency of all kinds plagues all the products we use, to the point where Apple IIe was more responsive than today's juggernauts[3].

But as for AirPods in particular - they _are_ a flawed product. Good for you if your use case is not affected by the flaws.

[1] [https://stephencoyle.net/AirPods](https://stephencoyle.net/AirPods)

[2] [https://www.soundonsound.com/sound-advice/q-how-much- latency...](https://www.soundonsound.com/sound-advice/q-how-much-latency- acceptable-virtual-piano)

[3] [https://www.extremetech.com/computing/261148-modern- computer...](https://www.extremetech.com/computing/261148-modern-computers- struggle-match-input-latency-apple-iie)

</comment><comment><USER3> I'll be the first to admit I never thought I would buy them. Way over priced I said. So I bought some standard bluetooth headphones on amazon for 30$ and they worked well but eventually the weight of their connecting strap started to bother me.

After another amazon binge, I decide to go light and try a 4 start knockoff product that seemed like they would do the trick. At first, they were great, the second song was good too and then low battery. After a full charge, the best I ever got was 1 hour. I only got to use them for a few weeks because one day the entire innards came out with the charging cable for one of the KnockoffPods.

So having the iWatch, which has does wonders for my health, I gave in and purchased the most expensive Easter egg I've ever seen. But from the moment I put them on you could tell why they are worth the price.

First, the battery life is excellent and the idea to add a battery pack into the storage case was great.

Second, the ability for the headphones to sense when they are in your ear is a nice touch and the tap for siri is convenient too.

However the think I like the most is that with the iwatch3 and airpods, I can still have my phone capabilities with me without all the distractions of the iphone.</comment>


Casting a $20M Mirror for the World's Largest Telescope [video] - <AUTHOR> https://spectrum.ieee.org/video/aerospace/astrophysics/casting-a-20-million-mirror-for-the-worlds-largest-telescope <comment><USER2> Fun fact, this facility is underneath the football stadium at Arizona University.

Tom Scott recently posted a guest video from the Active Galactic Videos YouTube channel about this process.

[https://www.youtube.com/watch?v=BP9HNVuGb-g](https://www.youtube.com/watch?v=BP9HNVuGb-g)

<comment><USER3> And if you're ever in Tuscon you can visit the facility, they do tours: [https://mirrorlab.arizona.edu/tours](https://mirrorlab.arizona.edu/tours) (Also recommend visiting Kitt Peak and doing one of their night observing programs.)

<comment><USER4> The Kitt Peak program I did was a great experience. It's in the middle of a desert wilderness, so get there early for incredible views and a sunset. We got a tour of many of the telescopes. Bring lots of warm clothes because it is quite cold and windy after the sun goes down. And then at the end, for one more bit of excitement, you drive down the (steep, winding) mountain road without headlights--just following the brake lights of the person in front of you.

</comment></comment></comment><comment><USER5> I have always place diamond turning and aerospace composites part/tooling very high on my list of high stakes manufacturing.

The process that this mirror goes through, just redefined high stakes for me.

Think about it, if somebody or something makes an error with any significance. Bolt wasn't secured, sensor calibration was off, etc. The entire project is derailed by years. Just getting new material, will take at least a year based on the video.

In aerospace, usually it's alot of money to scrap a part. But then you call up your supplier, and they can make another one "quickly".

With this, you have no wiggle. At all.

I'm curious how they manage risk/failure modes on their team/facility/machines with a project so critical.

Especially since the entire project has a QTY output of less than 10 over a few years.

<comment><USER6> You think the manufacturing is high stakes?

They ship all the equipment for telescopes together on the same ship, because if you lose the mirror you're basically fucked anyway. You're at the mercy of the interstate, the shiphyards, the ship, the seas, the canals, the other shipyards, the other highways, the roads, the drivers, and a bunch of other things.

Manufacturing is important, but it's a lab environment. Getting the stuff where it needs to go is the messy bit.

This even goes into the design. The reason all the telescopes above La Serena are curiously near 8.4M wide is because there's a tunnel which is about 9M wide.

</comment></comment><comment><USER7> My workplace includes a small optics shop where they polish optics that are roughly 2 or 3 inches in diameter. Even in such a modest little shop, the process is just fascinating. The whole shop runs in slow motion, and there is a high level of skill and judgment necessary to make and test the optics while at the same time maintaining the condition of the abrasives and tooling.

Optical manufacturing processes are a wonderful mixture of old and new. Many of the basic techniques are centuries old, but have been updated with sophisticated laser measurements and computer controls.

</comment><comment><USER8> The timescales involved in the manufacture of this mirror are amazing. I love the way this guy just casually states things like:

"we then cool the glass ... for a few months"

"the mirror will sit for the next year while we machine the back surface flat"

"that final polishing process ... takes about 18 months"

It's kind of mind blowing for it to take so long to make a single object.

<comment><USER9> >"that final polishing process ... takes about 18 months"

That's a lot faster than it used to be. The 200 inch mirror at Mt Palomar took 13 years to grind and polish. I guess they have greatly improved the technology.

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

</comment></comment><comment><USER10> And here I'm sitting with my 8" Schmidt Camera and 12" Newton … the amount of engineering that goes into this is incredible. It's not just the mirror, which is of course important, but also having a mount that can precisely track at the sidereal rate with all the mirrors on it. And then, judging by the image, they'll also do Laser Adaptive Optics to correct for atmospheric seeing artifacts, which means adjusting the mirrors and/or camera at a very high rate and /very/ precisely. It basically works by painting and artificial star in the sky with a high powered laser, and by measuring the difference between where it should be and where it actually is, you can then adjust the optical train to compensate. And, then there's the issue with temperature compensation, collimation (looks like a Gregorian-type design), and of course the cameras themselves. For the cameras I'm assuming the illuminated field is quite large, so either this means a HUGE CCD, or stapling several together with all sorts of noise artifacts involved. Very exciting. Very hard.

</comment><comment><USER11> For those wondering _why do they have to go to Chile?_ , I presume it's for the same reason as given here for the ELT (extremely large telescope, to be completed in 2024): The location was chosen because of its high percentage of cloudless nights and low light pollution [1] and (notably but with a lower weight of importance) the temperature is cold enough that there will not be differences in temperature between the interior and exterior of the telescope which could cause the rays of light to defract (ever so) slightly [2].

[1] [https://newatlas.com/extremely-large-telescope- construction-...](https://newatlas.com/extremely-large-telescope-construction- begins/49747/) [2] [https://astronomy.stackexchange.com/a/21413](https://astronomy.stackexchange.com/a/21413)

<comment><USER12> My Mrs is an astrophysicist and has been to Chile about 10 or so times over the last 8 years. She says the Atacama desert is ideal because of Chiles political stability as well as stability of the atmosphere. A high and dry western coastline is good for great "seeing" conditions because highly stable sea air is less prone to fluctuations in temperature which is the bane of any astronomer (this is what creates twinkling of stars). As it happens she was working on the data reduction pipeline for an instrument with adaptive optics (AO) on the Gemini South telescope. AO helps reduce atmospheric disturbances even further so they are now getting better results than Hubble from a ground based telescope.

<comment><USER13> The same goes for South California mountains, especially if you're into solar imaging (the Big Bear Solar Observatory is there for a reason).

</comment></comment></comment><comment><USER14> So if a crack did develop in the glass as it was cooling or some other flaw appeared that would make it unusable, could the glass be broken up and be remelted or has its chemistry changed such that it won't meet its specs any longer?

</comment><comment><USER15> Found a longer video on Youtube. [https://www.youtube.com/watch?v=2GufF3pfIyA](https://www.youtube.com/watch?v=2GufF3pfIyA)

</comment><comment><USER16> Here's another video about the mirror's construction: [https://www.youtube.com/watch?v=BP9HNVuGb-g](https://www.youtube.com/watch?v=BP9HNVuGb-g)

</comment><comment><USER17> Given that we're talking about telescopes under construction, the largest one will be EELT, no?

<comment><AUTHOR> You are right. Based on an image in this article [1], the EELT would be the largest optical telescope, once completed in 2022, two years after the GMT, if the dates are correct.

And in the battle for superlatives, the cancelled OLT would have been the largest of them all.

[1] [https://medium.com/starts-with-a-bang/worlds-largest- telesco...](https://medium.com/starts-with-a-bang/worlds-largest-telescope- will-revolutionize-the-future-of-astronomy-d31386b92605)

<comment><USER18> I love the way telescopes are named.

Can't wait for the "JFCTABT".

</comment></comment></comment><comment><USER19> It would be good to know what off-axis or on-axis means in the context of telescope mirrors.

<comment><USER20> [https://en.wikipedia.org/wiki/Reflecting_telescope#Off- axis_...](https://en.wikipedia.org/wiki/Reflecting_telescope#Off-axis_designs)

</comment></comment><comment><USER21> 1nm precision of the curve and 20nm for surface irregularities. That's incredible. Wouldn't just thermal expansion cause it to deviate from the 1nm precision? What about dust, precipitation just bacteria creating a film on the surface.

<comment><USER22> Yes, the "nanometer level" is local flatness not the position. The mirror itself is only polished ~20nm flat. It is temperature controlled and made of a low expansion ceramic (zerodur?), but still bent by active optics to make the focus of "guide star" perfect (and to deal with any high altitude atmospheric "seeing" artifacts).

<comment><USER23> _It is temperature controlled and made of a low expansion ceramic (zerodur?) [...]_

Borosilicate glass. I also don't think they control the temperatures of the mirrors but I am not sure about that.

 _[...] but still bent by active optics to make the focus of "guide star" perfect (and to deal with any high altitude atmospheric "seeing" artifacts)._

For the GMT atmospheric compensation happens at the secondary mirrors. The primary mirrors are still active to maintain the optical alignment but slowly - less than 1 Hz - as compared to atmospheric compensation in the kHz range and I guess this also compensates for thermal expansion.

<comment><USER24> > I also don't think they control the temperatures of the mirrors but I am not > sure about that.

I know they typically air-condition telescopes during the day to keep the mirror at the anticipated nighttime air temperature, to avoid convection currents caused by a warm mirror. That requirement would seem to preclude controlling the temperature to a specific value, I think.

</comment></comment></comment></comment><comment><USER25> If anyone is interested in reading about a large telescope project from start to finish, I highly recommend this book: "The Perfect Machine: Building the Palomar Telescope". The project started in the 1920s, but the Palomar telescope (now called the Hale telescope) is still in active use.

If anyone knows of a comparably comprehensive account of a more modern telescope, I would love to hear about it.

</comment><comment><USER26> > more than 17 kilograms of special glass

That's not very much glass for such a large area, that would make it just a very thin layer... is this correct?

<comment><USER27> The Youtube video says 17,481.45 kg of glass. Maybe the IEEE article meant to say 17 metric tons.

<comment><USER28> I never understood why , and . where used as separators... They look so similar especially in hand writing.

I would propose 17'481.45 kg.

<comment><USER29> That would be the weirdest reason to move to Switzerland or Liechtenstein.

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

</comment></comment></comment></comment><comment><USER30> Holy shit, this is awesome.

</comment><comment><USER31> Once these mirrors are mounted and put to work in the telescope, what's the process for cleaning dust off the things?

<comment><USER32> Each mirror is actually coated on site and periodically when the performance gets bad enough the mirror is removed and taken back to the coating facility where it's cleaned, which actually removes all the aluminium coating the mirror then it's recoated and put back into service.

[https://www.space.com/37730-how-to-clean-very-large- telescop...](https://www.space.com/37730-how-to-clean-very-large-telescope- mirror-video.html)

</comment></comment><comment><USER33> Imagine having to invent new technology just to be able to create a module for your next programming project.

<comment><USER34> So just a normal day for a JS developer then?

</comment></comment><comment><USER35> Why does it matter if the raw glass has imperfections if it's going to be melted?

<comment><USER32> An imperfection in that would mean there was some problem with the creation of the glass probably some impurity which would cause issues with the thermal expansion properties. If the mirror doesn't expand evenly or as expected it'd ruin the focus which would make the mirror pretty much useless.

</comment></comment><comment><USER36> Apparently this telescope will have a focal length of 18,200 mm (18 meters).

That's pretty big.

<comment><USER37> I really like this group photo

[http://www.gmto.org/gallery/mirror- lab/#/lightbox&slide=48](http://www.gmto.org/gallery/mirror- lab/#/lightbox&slide=48)

From here

[http://www.gmto.org/gallery/mirror-lab/](http://www.gmto.org/gallery/mirror- lab/)

<comment><USER38> A great photo. Here's the not-quite-so-big (6.5m) multi-element JWST mirror: [https://www.flickr.com/photos/nasawebbtelescope/26602405532/...](https://www.flickr.com/photos/nasawebbtelescope/26602405532/in/album-72157629134274763/)

</comment></comment></comment><comment><USER39> My brother made some of the instrumentation for one of the earlier telescopes in Chile at the NOAO in Tucson.</comment>


Implement with types, not your brain (2019) - <AUTHOR> https://reasonablypolymorphic.com/blog/typeholes/index.html <comment><USER2> [https://news.ycombinator.com/item?id=20278496](https://news.ycombinator.com/item?id=20278496)

</comment><comment><USER3> This way of writing Haskell, from my experience, results in write-only code. While it's nice that the compiler helped you figure out which obscure operators to use for your code to actually compile, it sucks for the next person trying to find the bug in your code. And just because the types check out doesn't mean it's free from bugs.

Code is also meant to be read and reasoned about by humans, not just by the compiler.

<comment><USER4> Rich Hickey once said something (with regards to TDD) like, "We have guard rails on highways, but that doesn't mean we just take our hands off the wheel because the rails will keep us on the road. Guard rails don't know where we actually want to go. We drive the car where we're trying to go, and the rails are only there for when things go wrong."

I think a version of this applies to static types as well. Even under normal circumstances, I've noticed at times my own thoughts getting lazy when refactoring statically-typed code. I don't "load" as much of the program into my brain as I would otherwise; I just change the part I want to change and then fairly thoughtlessly fix all the type errors. I don't think this is a good thing. The OP takes this to an absolute extreme.

Static types are there to document and to catch bugs early; they cannot be used as a complete verification that your code is correct, much less a _generative_ tool for writing logic where "you're not entirely sure how" it works.

<comment><USER5> > Static types are there to document and to catch bugs early; they cannot be > used as a complete verification that your code is correct, much less a > generative tool for writing logic where "you're not entirely sure how" it > works.

You might be surprised to learn that this is not only possible but something research is definitely working towards.

In a language like Agda, for example, when there is enough type information available the compiler can fill in the holes for you with the obviously correct implementation.

The idea behind program synthesis drives this even further. Using type level specifications we can automatically derive the programs that meet those specifications. This is useful because the language of types is much more concise than the language of terms. For sufficiently difficult problems it's much easier for humans to reason about complexity in higher-level specifications. Let the computer generate the code!

It's still early on for this kind of technology but projects like Synquid[0] are making good headway.

Dependent-type theory also forms the basis of interactive theorem proving in Coq and Lean[1]. We use something like holes as the basis of proofs. Haskell's typed holes are quite a bit more loose but to me it feels very similar to working with such a system. I propose to Haskell there there exists an expression that satisfies a particular type and then I use the typed holes to fill in my obligations to provide a proof. The hole is my goal and the available objects in scope are my terms. It is a very effective tool for solving hard problems.

[0] [https://www.csail.mit.edu/research/synquid-synthesis- liquid-...](https://www.csail.mit.edu/research/synquid-synthesis-liquid-types)

[1] [https://leanprover.github.io/](https://leanprover.github.io/)

 _update_ : Links

<comment><USER6> I do wonder whether there is any reason to believe that generating code from types would ever be easier than writing the code directly. More specifically, I wonder if this:

> This is useful because the language of types is much more concise than the > language of terms.

actually holds with sufficiently complex types. For example, would the fully- specified type for quicksort actually be shorter than quicksort?

I don't know that there is any reason to believe so. The best we may be able to hope for is that we'll have less work to do for formal verification, since instead of writing both the proofs and the code, we may be able to only write the proofs and have the code for free. However, given that writing the proofs is, at least currently, much, much harder than writing just the code, I'm not sure this type of development would make more than a dent in the software engineering world.

<comment><USER5> Let's consider an algorithm that shares state among multiple concurrent threads of execution without coordinating work through a lock.

What is the probability that an expert software engineer could write a correct implementation of this algorithm, I wonder? As their colleague will we be able to review that code and notice if it contains an error? What are the sufficient parameters for an acceptable solution: _should it run with 8 threads and 2 state variables?_

I don't think we'll see these tools and practices become wide spread but I do see the cost of using them is coming down. I also see the number of cases where systems that aren't safety critical are never the less causing harm to property and people. It's possible that at this intersection we'll see the adoption grow: bringing down the cost of writing software that handles higher degrees of liability could be a useful tool to have.

<comment><USER6> I'm not sure what you are refering to as "these techniques" \- are you referring to full formal specification with dependent types?

If so, then I think the answer so far is: even though few senior SEs could write correct implementations of that algorithm, there are definitely many more than the number of people who can write non-trivial software with complex dependent types in a decent amount of time.

Of course, you can write code in Idris or Agda and be productive, but not if you want to do stuff like actually proving that your sort function produces a sorted permutation of original list and other similar somewhat rich tight bounds.

The more you want to express in your types, the more complex your program becomes. A very nice example is how you would implement matrix multiplication in regular ways (with matrices of numbers) versus how much more work you need to add if you want to track physical quantities (with proper support for different physical quantities for each value in the matrix). It's easy to say {{1, 2}, {3, 4}} can be multiplied by {{5, 6}, {7, 8}}, but much harder to say if {{1m, 2kg}, {3N, 4Pa}} can be multiplied by {{5m, 6N}, {7Pa, 4kg}}.

<comment><USER5> I think it's harder to find an error in a program than in a proof. At least for proofs that can be verified automatically by a computer. And that scales with the difficulty of the problem. A proof that a program copies files from one place to another is not interesting. However a proof that your algorithm can safely share state without a lock is.

My point here is _not_ that dependent type theory is going to take over the industry and we should all learn to write proofs!

It's more that we _can_ if we want to. Writing a proof with tactics in Lean feels a lot like programming with typed holes in Haskell (it's harder but the experience is similar). With training a motivated programmer can write proofs that verify their designs which provide a strong guarantee of correctness.

Whether types are more expressive than programs... I think they are? That seems to be the whole point of Synquid: you can express complex constraints and proofs in your types that enable it to derive the program for you. Is that _easier_ than simply writing the program?

I think one should consider that writing the _correct_ program is harder. And where getting it right matters a lot I hope that synthesis will one day allow us to derive those programs from their specifications (or at least the parts that matter the most). It would save a lot of the burden of proving that the program we wrote implements the specifications.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> As a non-Haskell-er, this article is impossible to follow. I have tried to learn Haskell a few times, always unsuccessfully. Haskell code is filled with so many Haskell-specific things. I realize the goal isn't to be an 'easy' language, but jeez.

Aside from the horrendous variable naming, I'm having trouble understanding what the author actually accomplished, and why it's necessary for a tool like this to exist in the first place.

Can anyone translate the problem into a more simplified, non-Haskell-specific version?

> jonk :: (a -> b) -> ((a -> Int) -> Int) -> ((b -> Int) -> Int)

I have no idea what this line means.

To me, it looks like he wants to write a transformer that matches a specific signature, and he uses a tool that tells him which functions can fit the 'hole' he has in the code, based on types. If I'm correct (I'm assuming I'm not), how is this different than intellisense in an IDE that tells you a list of type-valid functions/variables? Why is this a necessary part of the Haskell coding process? My first instinct is that this demonstrates a problem with the language, if something like this is necessary.

Appreciate anyone that tries to explain. I know most of my assumptions are probably wrong.

<comment><USER8> > I have tried to learn Haskell a few times, always unsuccessfully

I suspect that people wanting to learn Haskell actually want to learn a statically typed functional programming language. And if you also want that language suitable to everyday problems, the kind of things you are dealing with at work, then Haskell is probably not the best one to start with.

I love how Scott Wlaschin presents statically typed functional programming languages as straightforward and pragmatic solutions to everyday problems:

[https://www.youtube.com/watch?v=PLFl95c-IiU](https://www.youtube.com/watch?v=PLFl95c-IiU)

[https://pragprog.com/book/swdddf/domain-modeling-made- functi...](https://pragprog.com/book/swdddf/domain-modeling-made-functional)

Once you're comfortable with that (and the way it is presented here really isn't very complex) then Haskell becomes a lot easier to understand.

But Haskell is very distracting because it is much more expressive and complex than than ML dialects for example, so it will be a big learning curve before someone is comfortable reading someone else's Haskell code. For other statically typed functional programming languages (f.i. OCaml/ReasonML, F#, Elm) that is not the case.

</comment></comment><comment><USER9> This article is a great example of how FP is currently being ruined in the same way OOP was ruined in late 80s. The paradigm had a lot of great ideas, but it became so popular so quickly that people began to fetishize its terminology and tools, while completely forgetting what those tools were meant to accomplish.

<comment><USER10> What are the tools "meant to accomplish" exactly?

I've deployed production code built with the exactly techniques in the article. it's doable and in my experience easy (modulo the large learning curve - pay it once, pay it forever)

The (very simple all things considered!) top-level type signature of `Sem (State s ': r) a -> S.StateT s (Sem r) a` is also something I've used in production (different library of the same sort)

<comment><USER11> I wonder which fraction of the code actually benefits from these techniques though. Certainly I become suspicious from the fact that examples like in this article always tend to be of a very narrow, specific kind.

In my experience, every worthwhile piece of code outside of certain libraries has enough of what you might call "business logic" that these theoretically clean approaches no longer apply to. This has been true across lots of domains, from games, to CRUD, to compilers, to combinatorial optimization algorithms.

I'd go on to argue that the interesting core of all those problem domains was precisely in the areas that _couldn 't_ be solved using cute techniques like OP's.

</comment></comment></comment><comment><USER12> I think a lot of people are missing the point of the article. People are complaining about the complexity of the function or similar, which is basically brushing off that some problem domains just are complex.

Putting this into context, the author is demonstrating a function from his effect system library called Polysemy[0], which is a both complex concept and a complex problem to solve.

To achieve this with his library, some complicated plumbing is necessary, and one of those functions happen to be `hoistStateIntoStateT`. The author's point is then summarised perfectly by:

> Gee, that's complicated! I must be really smart to have written such a > function, right? > Wrong! I just have a trick!

The author shows how you can, when posed with just knowing the type you want to achieve, more or less generate/infer the implementation from that.

This is a common situation when stitching functions or parts of your program together, where you have an `A` and want to transform it into a `B`, given the functions you have available.

[0] [https://github.com/polysemy- research/polysemy](https://github.com/polysemy-research/polysemy)

<comment><USER13> > The author shows how you can, when posed with just knowing the type you want > to achieve, more or less generate/infer the implementation from that.

All this means is that, with a robust enough type system, determining the correct type is exactly as complex as determining the correct implementation.

In some cases, in some languages, expressing the solution in the language of types may be more intuitive than and help guide the language of implementation, but, because they are essentially encoding each other, that's not only as subjective as any question of what is intuitive must be, but also an artifact of the particular type language and implementation language. In a different implementation language, the problem may be as (or more!) intuitive as it is in the type language in use.

</comment></comment><comment><USER14> This is one of those journeyman techniques that takes a lot of trial and error before you realize how helpful it is. Thanks so much for sharing your hard earned insight. I do get that people are complaining because the example is artificial and leads to a lot of complexity. I get why you did an artificial example, to show how universal and powerful the technique is. I think complaints in the comment section are inevitable.

</comment><comment><USER15> This is an extreme example of something I've found to be quite common: programming "types first". For another example, I recently read a tutorial on parsing that started by defining `abstract class AstNode`, followed by multiple concrete derived classes. Only after ~100 lines was there any actual parsing logic.

My approach would be the opposite - start with the logic, using built-in types, and _maybe_ refactor to use custom classes later. Perhaps there are downsides to this approach, but it's how I think about solving the problem. I've found this style of programming is easiest in languages that have powerful, flexible built-in types, which seem to be best provided by dynamically-typed languages.

<comment><USER16> > My approach would be the opposite - start with the logic, using built-in > types, and maybe refactor to use custom classes later.

That's how you discover what abstract logic you need. And then you implement that logic types first, because it's abstract, so the types are both enough to describe the functionality and much easier to reason about. And you go and refactor your old code by following the types (or the type errors, if you are more in the let the computer do the work mood).

But I have no idea how to do that in dynamically typed languages. AFAIK, they hinder refactoring as much as they can.

</comment></comment><comment><USER17> The article does a very good job of illustrating why you should never program this way, if you read between the lines. More precisely, here is the damming piece of evidence:

> Finally we're finished! A little experimentation will convince you that this > zoop thing we just wrote is in fact just foldr! Pretty impressive for just > blindly filling in holes, no?

Yes, that's pretty impressive. Instead of just using foldr, you've reimplemented it, and don't even know that! We also have no idea whether this code we've stumbled into is equivalent to foldr in terms of performance. If I knew you write code like this, I would feel compelled during code review to squeeze my brain to try to see whether there is some library function that does what you just did.

Also, it's absurd to claim that these implementations are the only possible ones and that they are correct, when all you have is the pretty weak type system of base Haskell (even though it is probably the strongest type system in regular use!).

Sure, for a->a there is a single possible implementation, but as soon as you have a list, for example, among your parameters, there are now arbitrarily many possible implementations, which differ either in meaning or in performance characteristics.

<comment><USER18> > a->a

Even there, it's not true, right? It's been a while since I learned / used Haskell, but I think something that transforms a { name: 'bob' } to a { name: 'sally' } would fit that bill, right? So, there are many implementations which meet the type signature, but you'd be pretty surprised if your `identity` function did this.

<comment><USER19>
      f :: a -> a

can only be satisfied by the function _identity_ because there are no constraints on the type ( _a_ ). _identity_ is the lowest common denominator function that can transform an object of any type to another object of the same type.

If you added a constraint on _a_ , for instance:

      f :: Num a => a -> a

Now _f_ can be almost any function which can transform a numeric type back to the same numeric type. [0] describes _class Num_. So _f_ , with this constraint, can now be _negate_ , _abs_ , _signum_ , or something which combined the first parameter with itself using one of the operators, and so on.

By removing constraints on the type itself, Haskell necessarily restricts the set of operations that can be performed.

[0] [https://hackage.haskell.org/package/base-220.127.116.11/docs/Prelu...](https://hackage.haskell.org/package/base-220.127.116.11/docs/Prelude.html#t:Num)

</comment></comment></comment><comment><USER20> > I'm not going to say that blindly filling in type holes always works, but > I'd say maybe 95% of the time?

I must do a very different type of programming. In my world, I'd say this might work maybe 20% of the time, max.

[Edit: Others on this thread (lkitching and weevie, at least) say that the difference is that the types must be "sufficiently polymorphic". My types almost never are. I suspect that the difference is, the more polymorphic the types, the fewer details of what can be done with each type, and therefore the fewer the options on the ways they can be combined. For example, if my function takes two ints, I can add, subtract, multiply, divide, take the remainder, etc. I can't use this technique to guide that. But if I'm passed in two "a"s, I probably need to be passed in the function to use to combine them as well (they may not _have_ a "+"). Then it's pretty clear - I'm passed in two "a"s, and a function that takes two "a"s and returns an a, and there's really only one way to combine those parts.]

</comment><comment><USER21> >One question you might have is "what the heck does it mean for a type to be correct?" Good question! It means your type should be as polymorphic as possible.

There's a mathematical sense in which this is correct, but I disagree for practical software. Yes, there's only one function of type (forall a. a -> a), so you can't screw it up if you have a type checker, while you can easily screw up a function of type (BizLogicType -> BizLogicType) since there are going to be many of those. But when reading code, the most polymorphic version of a function struggles from the same problem that using "x" as a variable name does. It's the type level version of the difference between ( x = f(g) ) and ( numBooks = countBooks(library) ).

</comment><comment><USER22> Takeaway - haskell programmers will be replaced by machines first, js devs probably last. /s

</comment><comment><USER23> If anyone can tell me what does functions does, I'll rewrite them in JavaScript.

<comment><USER24> > Finally we're finished! A little experimentation will convince you that this > zoop thing we just wrote is in fact just foldr

        zoop _   b []       = b
        zoop abb b (a : as) = abb a $ zoop abb b as

It's difficult to understand the function because the author deliberately named everything just based on their type to show off this method of autocomplete. This is what the function would look like with the same names as ramda's ReduceRight:

        reduceRight _  acc [] = acc
        reduceRight fn acc (head : tail) =
            fn head $ reduceRight fn acc tail

[https://ramdajs.com/docs/#reduceRight](https://ramdajs.com/docs/#reduceRight)

<comment><USER23> JavaScript already have the reduceRight method on the Array.prototype. But here it is anyway as promised:

        function reduceRight(arr, value, reduceFunc) {
            if(typeof value == "function" && reduceFunc == undefined) {
                reduceFunc = value;
                value = 0;
            }

            for(var i=arr.length; i--; i<-1) {
                value = reduceFunc(value, arr[i]);
            }

            return value;
        }

        assert( reduceRight([1,2,3], (a,b)=>a+b) , 6);
        assert( reduceRight([1,2,3], 1, (a,b)=>a+b) , 7);

<comment><USER23> Next iteration looks like this. Note that I added another test when I made the update to the function.

        function reduceRight(arr, value, reduceFunc) {
            if(typeof value == "function" && reduceFunc == undefined) {
                reduceFunc = value;
                value = arr.pop();
            }

            for(var i=arr.length; i--; i<-1) {
                value = reduceFunc(value, arr[i]);
            }

            return value;
        }

        assert( reduceRight([1,2,3], (a,b)=>a+b) , 6);
        assert( reduceRight([1,2,3], 1, (a,b)=>a+b) , 7);
        assert( reduceRight([1,2,3], (a,b)=>a-b) , 0);

</comment></comment></comment></comment><comment><USER25> hoistStateIntoStateT

The function name means nothing, and the implementation is hard to follow.

<comment><USER10> Are you familiar with Haskell? Or just a programmer in general?

The name doesn't mean nothing. Either you're a Haskeller not familiar with monad transformer idioms, or you're not a Haskeller just shouting your uninformed opinion.

Hoist means something very specific in the monad transformer world, and it really helps explain what this does. And the "StateToStateT" also is pretty literal (and in the types.)

I'd actually argue this name is boring & completely derived from the types.

<comment><USER3> I agree with you here that this does make sense from the point of view of even an intermediate Haskeller.

However, I also do think that the jargon in Haskell is extremely daunting. I think it's the only language I've used where easily most of the function names you see relate not to your business logic, but abstract types. There's some obvious things like 'map' and 'fold', but the deeper your get into complex types the more it looks like total gibberish (and you end up with lift, bind, hoist, not to mention obscure operators if you're in that sort of codebase). And while most other languages out there are at least somewhat approachable by experienced engineers new to that particular language, Haskell code will basically be ungrokable black magic until you spend a few months full time learning it.

And the worst part is that there's so many styles of Haskell - even if you're experienced, sometimes when jumping into a foreigh codebase you'll be suddenly struck by comonods or some other PL-theory-heavy library you never used before. And that just sucks when you're trying to debug a production bug. To me it basically feels like you're never 'done' learning Haskell.

<comment><USER10> > And the worst part is that there's so many styles of Haskell - even if > you're experienced, sometimes when jumping into a foreigh codebase you'll be > suddenly struck by comonods or some other PL-theory-heavy library you never > used before. And that just sucks when you're trying to debug a production > bug. To me it basically feels like you're never 'done' learning Haskell.

It is true that you have to constantly be learning new idioms, (e)DSLs, libraries, types, etc in Haskell. But in my experience, it isn't so bad.

I was at a job with a production Haskell codebase that many senior engineers deemed unsalvageable and were trying to replace in parallel (I don't know if they ever did tbh.) We had production bugs and I had to debug them (I was on the team supporting the production service.) Instead of wincing at how "ugly" and awkward the code was, I just used techniques like the ones in this blog post. I immediately was able to make an impact in the correctness, availability, and performance of the production service, along with the extensibility and ergonomics of the codebase. All because I got my hands dirty instead of wishing things were perfect. It really wasn't hard at all.

<comment><USER26> Hey - I thought Haskell forces you write code without bugs! :)

<comment><USER10> Didn't we all at some point :)

</comment></comment></comment></comment></comment></comment><comment><USER27> I learned some Haskell, and even wrote a couple of small programs and simple pull requests in it. However, I still wouldn't be able to effectively read and maintain such code at a reasonable pace.

There are many reasons to love Haskell. The static typing, prevention of bugs, the whole ethos of "doing things the right way", the beauty of abstractions. But I don't think that I would be able to be really productive in it in a reasonably sized project. And code written in this blog post illustrates this very well.

<comment><USER16> You shouldn't get downvotes, that's certainly a very common impression to get after writing small programs.

But the ethos of the language is not "doing things the right way", it's "do it first, make it right while it grows". The biggest point of the language is on refactoring.

</comment></comment><comment><USER28> Does F# offer this 'type hole' thing?

I admit I still like to let a type instance and then fill in its members with calculated values, database reads etc. but since I'm nice and C#rrupted I don't do it the idiomatic/right way, whatever that way is, I let a mutable type instance then modify and return it to whoever called the function.

</comment><comment><USER29> > _(\\(s ', m') -> fmap swap_

I understand beauty is in the eye of the beholder, but this code, along with much of the Haskell code I've ever read, looks horrendous. Why overuse non- alpha characters? Nested parens take mental time to unwrap, and backslashes have a lot of meaning outside of a language.

<comment><USER30> I'd much rather have nested parens than "all the parens taken away" and having to remember and then mentally calculate the precedence order for a bunch of obscure operators, which is what I tend to see in a lot of Haskell code. No doubt it becomes natural after persevering for a while....

</comment></comment><comment><USER31> For newcomers, the problem is exactly that they don't understand the type system. That's where soft documentation like examples would help a lot. I don't see why they would need to be mutually exclusive.

</comment><comment><USER32> I don't understand single thing in that code. Should it be so difficult for person from OOPs background?

Disclaimer: Never coded in FP. But this looks hard to understand what it does first place.

Anyway Nevermind.

<comment><USER33> It doesn't seem to be meant to be easy for someone who isn't familiar with Haskell syntax, if that's what you mean. It doesn't seem like it would be _too_ bad for someone who knows a dialect of ML. Maybe with the addition of a couple hints. I think, though, that, if it were written to be digestible for someone who's only familiar with OOP, it would quickly expand from being a blog post to being a small book.

<comment><USER32> It seems that there are prerequisites for learning FP. Damn! :(

</comment></comment></comment><comment><USER34> Or, as it was put back in the 80s (and probably earlier), "Strong typing is for people with weak memories."

[https://multicians.org/thvv/realprogs.html](https://multicians.org/thvv/realprogs.html)

<comment><USER20> Yeah, but back then, I didn't think I had a weak memory. The intervening decades proved to me that my memory is in fact weak.

</comment></comment><comment><USER35> No thanks. I like my domain model flexible and at run-time. You'll be better off in the long run.

(Imagining having data for type A(v1) and type A(v2), for example)

If you do static domain modeling, your world remains static. That's not real.

</comment><comment><USER36> Going from the signature to the code took me less time than scrolling through this article.

I'm not sure asking the compiler to babysit you every turn of the road is a good idea.

</comment><comment><USER37> I can't get pass the poor variables naming, though.

<comment><USER12> That's typically the case when dealing with very abstract functions:

        zoop :: (a -> b -> b) -> b -> [a] -> b
        zoop _   b []       = b
        zoop abb b (a : as) = abb a $ zoop abb b as

Can barely be more precise than that, except for `zoop`, but that is obviously meant to be considered irrelevant to the point of the article.

You will probably run into this in Haskell more than other languages though, because you can write a lot of general and abstract code in Haskell. In most other languages you cannot abstract over the types (higher-kinded types needed), and many still even lack polymorphism.

</comment></comment><comment><USER38> I think having a "complicated" type system like Haskell's is a good thing, because it lets you model data in your program accurately, and more importantly, lets you offload work from your brain to the compiler.

One question: How well do languages like Haskell work for code with side effects, though? Say I want to write a CRUD web API. How easy is it to work with network requests and database operations, for example, in Haskell?

</comment><comment><USER39> I get what you're saying, but defining a method from only a type signature, and then finding that it can be implemented by only caring about types, isn't much of an accomplishment. Of course you can define it by filling "type holes"—the method isn't real, so there's nothing it can or would do apart from the types matching up.

<comment><USER10> What are you saying? The function at the top of this blog post does do real things.

This method is real. You can't literally write all your Haskell this way, but I turn my brain off and play type tetris as a nontrivial part of my workflow pretty often. I rarely _only_ do that, but it's nice to not have to exert conscious mental energy and instead use tetris-like muscle/visual memory to make progress towards a goal.

<comment><USER39> I'm talking about the `jonk :: (a -> b) -> ((a -> Int) -> Int) -> ((b -> Int) -> Int)` extended example that you work through.

Or take the haskell filter function: `filter :: (a -> Bool) -> [a] -> [a]`. Some googling says that there's no opposite function for filter, but it's present in a lot of languages, so let's pretend there is. The signature would be the same: `filterNot :: (a -> Bool) -> [a] -> [a]`. Just looking at the types, filling type holes, wouldn't distinguish those two functions—the difference isn't in the types, but in their behavior.

<comment><USER10> That's true (and mostly is due to the concrete nature of Bool) but even so, parametricity does help a lot implementing that function. `forall a.` cuts down on possible implementations, but you still gotta program sometimes :)

In a more dependently-typed language, we can write something like this

        f1 :: (p :: a -> Bool) -> [a] -> [a `suchThat` p a]
        f2 :: (p :: a -> Bool) -> [a] -> [a `suchThat` not (p a)]

and that would make it so f1 couldn't be filterNot and f2 couldn't be filter.

And we get the added benefit of giving the caller of our function the proof that the elements have passed that predicate (maybe they can make use of that downstream)

But even in this case, there's nothing stopping you from just always returning an empty list. Not all theorems come for free!</comment></comment></comment></comment>


A Neural Network That Can Explain It's Inferences - <AUTHOR> https://arxiv.org/abs/1803.05268 <comment><AUTHOR> Here's an article that explains the methodology and model of the paper. The system was developed by MIT researchers and is called "Transparency by Design network (TbD-Net)":

[https://towardsdatascience.com/transparent-reasoning-how- mit...](https://towardsdatascience.com/transparent-reasoning-how-mit-builds- neural-networks-that-can-explain-themselves-3aea291cd9cc)</comment>


A 'slow catastrophe' unfolds as the golden age of antibiotics comes to an end - <AUTHOR> http://www.latimes.com/science/sciencenow/la-sci-antibiotic-resistance-20160711-snap-story.html <comment><USER2> So there are two issues that are touched on here, which are not really expanded enough.

1) farmers everywhere are allowed to use last line/new antibiotics routinely in food production. This is utterly fucking stupid. Whats more brain dead is that its not just china its US and canada. (possibly the EU.) It could be stopped by the FDA withdrawing the license. but no. Too much money.

2) over subscription in private health.

I once listened to a co-worker phone up the Doctor and ask to have "the same antibiotics I had last time for that cold" and get it[1]. She had the fucking snuffles. No consultation, not even bothering to figure out if its even got a hint of bacterial infection.

A placebo would have been more effective. It wouldn't have given her the shits either. Paracetamol is what was needed, as its the only thing that would have made her feel better.

Seriously. yes I know that the customer is always right, but don't fucking dish out drugs like sweets. My old age, and my children's health are dependent on those drugs.

[1] yes this was in the USA, santa monica to be precise. Yes I'm british. However the prevalence of prescription medication abuse and deaths is a massive fucking warning. Something is horridly wrong with the US's health care system.

What surprises me is with the levels of litigation against doctors, this hasn't seemed to trigger any change in behaviour.

Disclosure: I live with a doctor.

<comment><USER3> _1) farmers everywhere are allowed to use last line /new antibiotics routinely in food production. This is utterly fucking stupid._

Basically, it's exactly the worst thing you can possibly do, with regards to what the theory of evolution by natural selection tells us. Then add in what we know about bacteria exchanging genetic material, and it's like we're _trying_ to inactivate all of our antibiotics on purpose.

<comment><USER4> >Basically, it's exactly the worst thing you can possibly do, with regards to what the theory of evolution by natural selection tells us.

from the half-full glass POV we are just speeding up the natural selection of bacteria resistant humans (it has been going for millenia and got, probably only temporary, delayed for the last 80 years). Also, as a side effect, it can help solve (at least temporarily) the overpopulation issue until the much more smart (wrt. health and Earth resources usage) humans evolve. Basic dialectics at work.

<comment><USER5> Having antibiotic failure as the method for arresting the massive human population (7B people) would require carnage that makes World War II (~70M deaths) pale in comparison, even if you correct for the lower global population of the day.

<comment><USER6> Disease has typically killed more than wars. The Spanish Flu epidemic of 1918 killed 50-100 million people, several percent of the total world population. By comparison, total military and civilian dealths in WWI were about 16 million.

<comment><USER5> Oh, I agree - I just used WWII as it's a more commonly-understood datapoint. The Spanish Flu epidemic only took a couple of years as well, as opposed to the half-decade of WWII.

</comment></comment></comment></comment></comment></comment><comment><USER7> Articles like this urge me to stop reading pop science journalism altogether.

What is not mentioned is a new class of antibiotics discovered in 2015 ([https://en.wikipedia.org/wiki/Teixobactin](https://en.wikipedia.org/wiki/Teixobactin)) which is a big deal in that it can be used instead of antibiotics resistance to which has been acquired by bacteria during this "golden age" and as microbes evolve extremely fast, within an observable timeframe they will lose resistance to the old classes allowing those to be used again. So effectively shelving will work.

Another point is that other new methods of searching for new drugs are being researched ([http://www.theverge.com/2016/5/18/11686268/new-antibiotic- dr...](http://www.theverge.com/2016/5/18/11686268/new-antibiotic-drug- candidates-resistance-harvard-macrolide)) and the future is not at all gloomy.

<comment><USER8> Teixobactin is cool, but if it's only active against gram positives, it's never going to work against most of the bacteria listed in the article: E. coli, Salmonella, Klebsiella, N. gonorrhoeae, etc. Most of the terrible new drug resistance genes are showing up in gram negatives.

Sure, new methods of finding antibiotics are in the works, although the article you link has plenty of experts recommending caution about their potential. The bigger point is that in 2016 there is a looooooong road from antibiotic "candidate" to FDA-approved drug. That road involves decades of trials and costs billions of dollars per approved drug.

The larger problem is that there is little if any incentive for pharma companies to invest in antibiotics compared to traditional blockbuster drugs that are supposed to be taken chronically (and therefore have better ROI). It's the same reason little R&D goes into making new vaccines. It doesn't matter how many candidates are found if they can't make it to market in a timely fashion (the point of the CDC bar graph), and this is what the "slow catastrophe" really is. It is not that scientists will never figure out new ways to kill bacteria.

<comment><USER9> I used to work at an antibiotic discovery startup.

I used to joke that there were _so many_ groups with a Gram+ antibiotic drug discovery program going that my parents were probably running one out of their cellar.

Gram- are tough.

<comment><USER10> An antibiotic discovery startup, eh?

That's freaking fascinating, I'm in bioinformatics myself, I'd love to hear more about this- I wasn't aware that an antibiotic discovery startup was/is/could be a thing at all- If you can tell me anything more or put me on the right track to reading more about your old employer in that space or whatnot, I'd appreciate it! :)

<comment><USER9> I'd rather not mention my recent employer.

But these startups do exist: look up Achaogen (achaogen.com) and Tetraphase (tphase.com).

Cubist Pharmaceuticals was a big antibiotic developer that was recently purchased by Merck. Cubist itself bought another startup called Trius Pharmaceuticals, which had developed a newly marketed antibiotic.

So, there _is_ $$ to be made in antibiotic drug development, but as many people on this thread have pointed out, there is _more_ $$$$ to be made in other therapeutic areas (e.g., oncology).

</comment></comment></comment></comment></comment><comment><USER11> This is to be expected. The big issue is that it is not worth it for a pharmaceutical company to develop new antibiotics. The initial cost is high. Then, if it is successful, the antibiotic will only be given as a last resort, thus reducing the number of doses. In addition, unlike chronic conditions such as diabetes or high blood pressure, severe bacterial infection is usually time limited - the patient will either get better or they will die. In either case, they do not continue to need the antibiotic. Thus, to recoup costs, the pharmaceutical company will have to sell it at low volume/high prices. Of course, if they do that, the press starts blaming them for the high cost of the medication and it is a PR disaster (see Sovaldi) even though everyone is strictly better off due to their selling the antibiotic even at a higher price. In the end, it is better for their reputation and their bottom line not to develop these antibiotics. Thus, mainly because we do not have aggressive new development of antibiotics for these severe infections, we have these articles claiming the end of the antibiotic age.

<comment><USER12> And in response to that, the pharmaceutical companies will sell the antibiotic in high volumes to the livestock industry. Thus increasing profits... forever!

<comment> loup-vaillant With the nice side effect that this will spur more resistances, hence more reasons to develop new drugs, that they can sell at higher prices, driving profits even upper.

It's nice to get paid to solve a problem you created in the first place.

</comment></comment></comment><comment><USER13> This is a public health crisis that needs urgent attention. Governments should step in with huge funding to NIH and pharma to accelerate R&D, and offer incentives to invest heavily in antibiotic development (extended patent terms for antibiotics, tax-free repatriation for antibiotic R&D funds, whatever it takes).

The current free market approach is completely failing this. It's not particularly profitable to invest many years in a drug people only need to take once to cure a disease when compared to developing a drug people need to take for 5-10+ years to manage a disease.

Phage therapy should be further developed as well, which has been proven to work against some resistant strains.

<comment><USER14> >The current free market approach is completely failing this. It's not particularly profitable to invest many years in a drug people only need to take once to cure a disease when compared to developing a drug people need to take for 5-10+ years to manage a disease.

Why couldn't their payment scheme be identical even if it's a one time dose? Instead of $1000 per year for a drug you need to buy every year for ten years, make it so it has an up front cost of $12,000 or whatever with a ten year payment plan available for people who don't have that kind of cash on hand. This suggestion obviously inspired by the real world good that is a one time purchase that people make all the time: houses.

<comment><USER15> Martin Shkreli approves.

But to elaborate, aside from the obvious ethical implications, there are also practical differences. You are usually not forced out-of-the-blue to buy a house, no matter if you can afford it or have just bought a house last month. Also, houses can be sold, so people have ways to back out of a purchase when they realize they cannot pay back the loan. None of this works for drugs.

Trying to apply the same logic to drugs would make the the debt problem of medical bills even worse than it already is. It would also lead to a strong inequality in medical care.

<comment><USER14> Isn't Martin Shkreli notorious for hiking prices on drugs, not for pioneering new payment models for drugs? My post was about how if a company had a drug which it had development cost $X for, it could recoup X + p from the consumer _even if_ the drug is a one time dose rather than an ongoing treatment. How much p profit they make is a separate question and anyways is sort of orthogonal to the question of whether they pay per month or once.

</comment></comment></comment></comment><comment><USER16> Bacteriophage therapy?

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

<comment><USER17> I always wonder why this is never mentioned in these articles. If I recall correctly, this approach is quite popular in Russia.

<comment><USER18> There are considerable problems with it. It's popular in Russia because they didn't have access to antibiotics in large quantities.

<comment><USER17> Can you elaborate on what the problems are? I haven't read much on it, but it sounded very promising.

</comment></comment></comment></comment><comment><USER19> > The economics of drug development are partly to blame.

> To offset the millions of dollars they pour into research, clinical trials > and the FDA approval process, pharmaceutical companies aim to develop > blockbuster drugs, said Dr. Anthony Fauci, director of the National > Institute for Allergies and Infectious Diseases. An ideal candidate would be > used by millions of people every day for the rest of their lives, like pills > to keep cholesterol or blood pressure in check.

> Antibiotics won't pay the freight. They should be prescribed sparingly and > only used for about a week.

Hmmm. Natural selection of humans, in an environment partly controlled by Pharma.

Pharma needs lots of patients that consume a drug every day for life. (I take three of them, plus an arguable fourth.) People who take one or more of these drugs are valuable. Such people who live longer lives are more valuable.

By not discovering low revenue new antibiotics and making them available, what we're left with is people who take daily drugs for life, and somehow survive or avoid bacterial infection.

I want to believe that no one in Pharma has thought of this.

</comment><comment><USER20> "Researchers haven't identified a new class of antibiotic medication since 1987."

Teixobactin is 2015 and is probably a member of a new class of antibiotics.

<comment><USER21> Teixobactin unfortunately isn't helpful to us. We really really need something that works against gram negatives at the moment.

Also note that retrospective studies have shown that first observed resistance to an antibiotic appears about six months after it is introduced. We are producing new antibiotic families far slower than this rate.

</comment></comment><comment><USER22> When an organism develops resistance it usually makes an evolutionary trade- off. This ironically might make them susceptible to older style antibiotics who have been phased out. However retesting these antibiotics are not really being done extensively due to there being little financial benefit.

[http://jac.oxfordjournals.org/content/70/8/2177.full](http://jac.oxfordjournals.org/content/70/8/2177.full)

My experience with kids is that here in Spain they are using older antibiotics now to preserve the newer ones for serious infections trying to limit evolutionary pressure on the bacteria.

</comment><comment><USER23> Microorganisms have been able to cope with each other for damn near a billion years using toxin-antitoxin systems. People are exploring these as negative selection systems. Traditionally, antibiotics are used. [http://nar.oxfordjournals.org/content/early/2015/03/23/nar.g...](http://nar.oxfordjournals.org/content/early/2015/03/23/nar.gkv248.short)

There is probably a huge array of such things out there. They are unlikely to be as broad-spectrum as traditional antibiotics, but with research we should be able to find ones to apply to the right situations.

At the same time as this crisis unfolds, our ability to know exactly what someone is infected with improves. Soon sequencing of bacterial infections will be the first step in patient triage. This will help us apply precisely the right toxin to rid the body of the problematic type(s) of bacteria.

</comment><comment><USER24> Antibiotics resistance is getting stronger, probably because people eat a lot of meat which is full of antibiotics. Because they feed animals with antibiotics to grow faster and bigger. People should really think what food they put in their body and less about some magic pill.

</comment><comment><USER25> Seems like this is time to research how antibiotic resistance is jumping species. I feel like we could take advantage of unauthenticated exchange of information and inject weaknesses instead.

<comment><AUTHOR> Basically, when bacteria discover a gene that works, they share it with others. As far as I know, this does not readily lend itself to a human counterattack of some similar approach. The solution will likely come from some other avenue.

<comment><USER23> They don't find it works then share. They are randomly sharing, and sometimes it works. Bacterial sex.

<comment><AUTHOR> You have to live to share. So, the distinction is essentially immaterial. They find something that works, they live, they share randomly for kicks with other bacteria they picked up at the bar, those bacteria become resistant, rinse and repeat.

</comment></comment></comment></comment><comment><USER19> Are we using the older meds much, like penicillin? I wonder if bacteria eventually lose their resistance to older meds with lack of exposure.

<comment><USER26> In general antibiotic resistance is lost when it doesn't confer an advantage. In some cases resistance to antibiotics costs cells energy they'd much rather be spending on other things. When the antibiotic is gone, cells without the energy tax can outcompete ones that do and divide quicker. The population then reverts to sensitive cells again.

Even in a hypothetical case where a random enzyme mutation confers resistance with no real obvious cost or side effect to the cell, unless there is specific environmental pressure to keep that mutation, it can easily revert in subsequent generations.</comment></comment>


Deep in Italy, One Man's Surrealist Mini-City Sleeps - <AUTHOR> http://www.messynessychic.com/2018/07/25/move-over-dali-he-made-his-mind-a-mini-city-and-its-a-fairytale-into-the-woods-italys-sleeping-surrealist-castle/ <comment><USER2> Looks like a setting for a Myst game.</comment>


V8+: Node.js Native Extensions in C - <AUTHOR> https://github.com/wesolows/v8plus

<comment><USER2> The FAQ, is hilarious.</comment>