Pirate Act: what the law says and how it threatens pirate radio stations - <AUTHOR> https://www.theverge.com/2019/11/26/20978243/pirate-act-radio-stations-law-legislation-fcc-haitian-dj-joan-martinez <comment><USER2> There is an interesting story about the high power side of broadcasting. There was a station in the US, WLW that was 500 kW. This one station reached almost the entire country. The FCC finally limited the maximum power to 50 kW. Mexico had no such restriction, so "border blasters" appeared- high power stations on the boarder transmitting into the US. They ran ads, made money and had huge audiences. Most famous is Wolfman Jack on XERF.

[http://www.ominous-valve.com/xerf.html](http://www.ominous- valve.com/xerf.html)

[http://www.theradiohistorian.org/xer/xer.html](http://www.theradiohistorian.org/xer/xer.html)

[http://www.ominous-valve.com/wlw.html](http://www.ominous-valve.com/wlw.html)

Anyway for low power community radio, the situation is ridiculous. Some part of the FM dial should just be reserved for low power self-regulated radio. The rules are the way they are to protect incumbents and the same thing is happening on the internet. A recent example is when the David Pakman youtube show got dinged by CNN and NBC because he was rebroadcasting CSPAN.

[https://www.youtube.com/watch?v=Z43JMffa1x0](https://www.youtube.com/watch?v=Z43JMffa1x0)

<comment><USER3> The Reply All episode where they get into some of the history of XERA and John Brinkley is pretty great. [https://gimletmedia.com/shows/reply- all/dvhexl](https://gimletmedia.com/shows/reply-all/dvhexl)

<comment><USER2> There is a documentary about the "doctor":

[https://www.youtube.com/watch?v=HkMXDVBnrv4](https://www.youtube.com/watch?v=HkMXDVBnrv4)

Goat glands, oh boy..

</comment></comment></comment><comment><USER4> Back in the day I listened to a pirate station that broadcast out of Arizona. Similar to what the article mentioned, that station was run by people who were passionate about music, camping, and what was going on with respect to the National Forest service and the BLM with respect to public lands.

Objectively, they met all the mission requirements that the FCC at the time said they stood for, use of the common air waves for the public good. Their 'crime' was that while they operated a great station the lack of regulatory control meant they were 'at risk' of doing something "bad." They eventually got shut down, the world was not a 'better place' for it.

<comment><USER5> Was getting in compliance too burdensome for them?

For every well-behaved pirate, there'd be many ill-mannered pirates if you didn't seize their operations.

<comment><USER6> "Ill-mannered" ? I can't think of anything more ill-mannered than a handful of companies abusing the letter of the law by "owning" all of the licensed spectrum in a given area, and then filling it with lowest common denominator chum in a race to the bottom.

In this day and age where main societal attention has moved past radio, most of the FM band should be put under a regime similar to 2.4GHz. Preserve the few remaining high power commercial broadcasters to maintain the capability for emergency communication, and let a vibrant ecosystem (without the revenue to pay hefty license fees) regrow on the rest.

(edit: Well, the exact 2.4GHz regime might not be the most appropriate, because the obvious play is to broadcast on every frequency for more exposure. But the spirit of my argument remains - "pirate" operations remain vibrant because they can't be bought up and consolidated the way legalized stations do, and so their operation should be _encouraged_ )

<comment><USER7> The problem with that plan is that broadcast radio does not let two stations (in the same general area) share the same frequency, period. So you need to have frequency coordination.

Compare with the ISM bands, like 2.4 GHz, where you can use complex digital signaling (e.g. CDMA/TDMA combined with robust error correction and detection) to effectively timeshare the frequency. The only reason this works well is because the frequencies are two-way and severely power limited - and even then the WiFi channels are congested.

Your home WiFi network has a range of a few hundred feet. A broadcast radio station can easily reach hundreds of miles. The reason those broadcast licenses cost so much is because there's just not enough broadcast spectrum to go around.

A better option for most users is to just stream over the Internet.

(That said, I would certainly love to see a chunk of spectrum set aside for low-power ad-hoc/community stations. But I don't think it would work reliably if it ever got popular.)

<comment><USER6> I was aware of that when I wrote my comment. Also the 2.4GHz has a lower inherent range due to higher frequency and water absorption.

I just don't foresee a huge interest in amateur stations being a problem that couldn't be sorted out informally. So Timmy decides to stomp on the broadcast of Tommy a few doors down - they'll figure it out. It certainly can't be worse than the current situation where Tommy isn't broadcasting at all.

Perhaps I'm discounting the effects of "100W SWR-tolerant FM Transmitter" on eBay for $60 direct from China. But _shrug_ with the current state of radio consolidation, why not cross that bridge when we come to it?

FWIW I would say there is clearly more than enough broadcast spectrum to go around at the current prices, given how much dead space there is.

<comment><USER8> In this situation 1+1=0. If Timmy and Tommy go to war the frequency is effectively useless. Neither will be heard without severe interference.

</comment></comment></comment></comment></comment></comment><comment><USER9> If anything, I think there's a lot of value for having people broadcasting on a community level.

In the era of the internet and hyper-connectivity, we've lost that sense of community and having local broadcasters that don't work for companies and don't have corporate agendas is a step towards restoring it.

The available local broadcast frequencies just need to be shared by people in the community and there has to be a strong sense of accountability for mess ups

</comment><comment><USER10> I like pirate radio but it's illegal by definition.

They completely fail to mention that spectrum is limited and that you are probably causing interface for someone else.

The right thing to do would be to give them free or subsided licenses.

<comment><USER11> If the spectrum is otherwise used for cancers like advertising then I wouldn't consider interfering with it to be a bad thing.

In addition, I don't think these "pirate" operators have any nefarious intentions and wouldn't wish to actually interfere with any station (as it would be counter-productive to their own listeners, since the existing station would scramble their own broadcasts too) so I am not sure this has ever been a _real_ problem.

</comment></comment><comment><USER12> Is there a real problem to be solved by this proposed legislation?

Of course, in theory, it's necessary that radio stations not transmit on the same frequency too close to each other, or there's interference. If this is happening in practice, then increased enforcement might well be called for.

If, on the other hand, interference isn't happening in practice, then increased enforcement seems like both a waste of resources and... is there a name for social benefit coming out of things being in a legal grey area?

<comment><USER13> If demand for spectrum is low in a certain area and there is plenty available for these pirate stations, then just have an easier process to become legit. There obviously needs to be some sort of process to make sure everyone is playing fair, you can't have total anarchy on the spectrum but there could be less burdensome application process for lower power stations that can prove they are operating for the common good. If you are just playing music and running used car dealer ads, you can go through the normal registration process.

</comment></comment><comment><USER14> The Great Translator Invasion of 2003 created a situation where the portions of the band where community radio, run by and for residents ( _local_ information, for _local_ people), was instead occupied by "translators," replicating signals from religious broadcast networks like Moody.

Between that and NPR behaving as if they were about to be blasted off the air by third adjacent-channel interference from tiny station with pitiful transmitters, it is very difficult to come up with situations where the band is being used as promised.

I am not surprised that pirate radio is still a thing, given this kind of outcome.

<comment><USER15> What happened in 2003 and where can I learn more about the translator situation?

It doesn't seem to be limited to religious programming. For example, KUSC, a non-profit classical station, has 4 translators. I don't understand why. NPR affiliate KCRW has 5 translators.

<comment><USER14> "A 2003 FCC licensing window for new translator applications resulted in over 13,000 applications, most from religious broadcasters. Due to the number of license applications, LPFM advocates called it the Great Translator Invasion."

It isn't _limited_ to religious programming but it the major component.

Translators are really just re-broadcast mechanisms, and because of the various oversights in the regulations, the original signal does not have to be over the air or local, so networks can spawn off in parts of the band that were, in the spirit of things, intended for programming created by the same people the LPFM signal could reach: those in the nearby area.

There's a long, long history of lower power stations and tons of inside baseball on the topic. Unfortunately, removing market caps in the nineties caused a wave of consolidation in the radio industry that swallowed up many local stations with higher power. The Great Translator Invasion similarly purged the local stations with lower power.

Despite that consolidation and what you would think would be efficiencies of scale at the cost of programming from locals, many of the media companies that "borged up" the little guys have gone bankrupt. I won't pretend to know too much about all of this, I can only say that due to my contacts in the radio industry I have had multiple points of input giving me an overall negative opinion of how this has worked out over the years.

</comment></comment></comment><comment><USER16> If we could get cognitive radio going over SDRs, mesh networks using automatic frequency hops to the nearest radio whitespace would become drop-dead easy.

From there, the FCC could issue regulations to the tune of 'use any non- military band for up to X seconds, provided you confirm you are not interfering with any other traffic every Y milliseconds' and the entire licensing scheme of "radio bandwidth is a finite good" could be virtually eliminated. It would be like going from IPv4 to IPv6 in terms of total amounts of available IP addresses.

<comment><USER17> The lack of technologies like cognitive radio aren't preventing mesh networks. If you're talking the useful bands for data transmission (ie, VHF and up but mostly very up) then the only thing that matters is height above terrain. Unfortunately except for exceptional situations (coastal mountains or megacity roofs) that height and getting power up there costs a lot of money. That's why neighborhood and city mesh networks don't work. And it's why cell networks do.

</comment></comment><comment><USER18> It would be interesting to see an ISM neighborhood mesh network for broadcasting this kind of thing. With modern openly-licensed codecs you should be able to get decent music quality in 16kbps or less, so a half-duplex channel at 512kbps could carry 32 concurrent transmissions. With mesh nodes every 500 meters, you can use four nodes per square kilometer and spare the mobile nodes from spending battery on forwarding packets when they're not plugged in, or even transmitting signals. If you build the network on a for- profit basis, you can subsidize distribution of $20 radios from broadcasting fees. Is there an equivalent of RTL-SDR for pocket-sized projects yet?

Related: Cory Doctorow's 2003 short story, "Liberation Spectrum": [https://craphound.com/stories/2003/01/10/liberation- spectrum...](https://craphound.com/stories/2003/01/10/liberation-spectrum/) [https://www.salon.com/2003/01/16/liberation_spectrum/](https://www.salon.com/2003/01/16/liberation_spectrum/)

<comment><USER19> A long time ago I used an rtlsdr hooked up via usb-otg in order to track aircraft [1].

I'd be really interested in a minified version that didnt need the otg dongle. Or even a stand alone battery operated sdr that could be controlled with bluetooth? I dunno how big that market is, especially absent a network like you propose.

[1] [https://www.rtl-sdr.com/ads-b-decoder-rtl-sdr-now- available-...](https://www.rtl-sdr.com/ads-b-decoder-rtl-sdr-now-available- android/)

<comment><USER18> If a broadcasting area can be 10 square kilometers with 100,000 people in them, and you need 40 base stations for $5000 to cover that, I feel like the infrastructure investment is insignificant compared to the engineering effort. Apparently the market exists.

In the US you could even transmit FM radio at the legal power levels from the base stations too, reaching like one apartment building from each base station.

A bigger legal problem is the copyright question. You could start with music from Jamendo and the Internet Archive but sooner or later your broadcaster DJs are going to want to broadcast Lindsey Stirling or One Direction, and then you'll have to prove in court that it's legal!

<comment><USER20> > A bigger legal problem is the copyright question.

_Unfortunately_, statutory licensing means that you can license most commercial music for your station for a couple hundred per year ( [https://www.prometheusradio.org/music-licensing- noncommercia...](https://www.prometheusradio.org/music-licensing- noncommercial-broadcasters-and-webcasters) ). Considering the investment of time that goes into scheduling, promoting, etc. a successful station the licensing costs aren't that big a deal.

I say unfortunately because the existence of blanket rates and in particular compulsory licensing has undermined the free market, and as a result new/independent performers have a much harder time getting aired because they essentially can't compete in terms of price (e.g. you can play our stuff free!) because almost every station/venue is already paying blanket rates and doesn't have much marginal cost in playing the commercial stuff.

<comment><USER18> Right, but those rates don't apply to internet streaming. This proposed new service isn't exactly internet-based, but it isn't an FCC-licensed commercial radio station either, and it's digital and packet switched; you can bet your left ovary that sooner or later it would face music industry mafiosi arguing in court that it should have to pay the internet streaming radio rates, not the ones KVIL pays.

<comment><USER20> Follow the link and look midway through it, statutory licensing also applies to non-interactive internet streaming too-- though the rules are somewhat different.

</comment></comment></comment></comment></comment></comment><comment><USER21> FCC interview: [https://www.fcc.gov/news-events/podcast/pirate- radio](https://www.fcc.gov/news-events/podcast/pirate-radio) They minimize the regulatory burden and emphasize the dangers of interfering with air traffic control, and suggest internet streaming as an alternative, among other interesting tidbits.

</comment><comment><USER20> Broadcast radio is dying to the point that it's difficult to purchase a high end FM tuner now-- pretty much anything that exists is old models. Heck, used XDR-F1HD regularly sell for twice their original price. In many places big chunks of the dial are vacant, and where it isn't a few companies own most of the stations.

The public and the industry needs _more_ pirate radio -- if the political will to undo the regulatory capture that's killed LPFM can't be fixed quickly.

Instead of enhancing penalties, they should instead be limited to actual damages for signal interruption to licensed stations plus no more than 2x whatever licensing would have cost had the FCC been willing to issue a license, which they're usually not.

</comment><comment><USER22> I loved listening to the pirate stations in NY in the late 70s and early 80s. WFAT, WFSR, WLAU, etc.

But there are more options today for "broadcasting" over the Internet than there were then.

While I wouldn't want to see any "pirate" face jail time or huge fines for a first or second offence, it still can be disruptive to the legally licensed radio stations that were granted use of those frequencies. Like it or not, the airwaves are a limited resource, and need to be managed and provisioned.

</comment><comment><USER23> I recently got into HAM radio a little bit. I like to believe that radio (aside from wifi and cell service) is still useful, but the use cases are getting pretty thin.

There are lots of ways to deliver news. I get the feeling that a lot of the appeal of using pirate radio is _because_ it's illegal.

I know there are a few benefits, like tuning a car radio to the right frequency, and not requiring someone to know how to set up a streaming audio service. But it seems to be a declining use case.

</comment><comment><USER24> I feel the need to mention the movie "The Boat that Rocked", despite being 99% fiction (based on fact), there's a "spirit of the hacker" to it that provides a level of comfort to my soul.

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

</comment><comment><USER25> A surprising number of radio stations in major cities in the UK started out as pirates. Why aren't lawmakers in the US instead trying to make it easier for pirate radio stations to operate legally?

<comment> seph-reed The U.S. is in the waiting room for a serious house cleaning. As it is, literally everything revolves around some big companies profit margins. If it doesn't benefit that, it's not important.

God I hope we fuck em up soon. They subverted the justice system, and now there's no pressure release for when bad things happen.

</comment></comment><comment><USER23> Maybe the FCC should set aside a few portions of spectrum that are completely unregulated.

Probably a lot of bad actors would show up. But who knows? Maybe most of them would get bored and leave.

<comment><USER26> This is basically what wifi, bluetooth, and garage door openers use. The sad thing is that they carved out chunks of the spectrum that don't reach as far as the already-in-use TV and radio spectrums. We get the leftover bits for arbitrary consumer transmission, the good parts are spoken for by corporations with deep pockets. I'd like to see the whole thing opened up, it would make meshnets easier to get going.

<comment><USER27> >We get the leftover bits for arbitrary consumer transmission, the good parts are spoken for by corporations with deep pockets.

Actually, no. Check out a chart of the usage of the radio spectrum in the US, and you'll find a shockingly huge amount of it is reserved for the military.

<comment><USER26> Fair enough. The deep pocketed corporations do still get preference over little people though, even if Big Daddy Government gets his slice first.

<comment><USER27> If you look at the spectrum, however, the deep-pocketed corporations are only getting preference of a very tiny sliver of the spectrum. They _should_ be getting preference, because they can do a lot more with that spectrum than the rest of us can. I hate to argue for deep-pocketed corporations, but it's true: we simply wouldn't have things like cellphones and 4G without them controlling the spectrum this way. You can't have things like that with massive amounts of interference from amateurs broadcasting whatever they want with low spectral efficiency (the spectral efficiency of old analog stuff is terrible compared to modern protocols). You can't legislate the laws of physics; there's only so much spectrum available.

The solution, to me, is simple: if the little people want to be able to do more with the radio waves, they need to get the government to release some bands to them for amateur or low-power use, instead of expecting everyone to cram anything and everything into the 2.4GHz band. There's a _huge_ amount of spectrum out there, but we're not allowed to use it because it's reserved for military radios. The military doesn't need to control the vast majority of the spectrum; it's not like they're exchanging vast quantities of data with it, the way we civilians do with our phones.

</comment></comment></comment></comment></comment><comment><USER28> I'm curious... if you're mostly doing talk, then wouldn't something around a 32k stream be potentially sufficient these days? I haven't run the numbers, but if anyone has calculated on what it takes to run a web/online stream I'd be interested.

Of course, that precludes music licenses for the most part.

<comment><USER29> From a technical standpoint it costs basically nothing, you can get a dedicated server with 100Mbps speed quota on a 1000 Mbps upstream, for under a hundred bucks a month.

Sufficient to support a very large number of Icecast stream listeners.

All of the software needed to do it is zero dollars and some combination of GPL/BSD/Apache licensed.

</comment></comment><comment><USER30> I really don't think pirate radio would be interesting if it was legal in itself.

Add to that they then might get mainstream advertisers and follow the FCC and syndicate to wide non-localised areas if legal, destroying everything unique about them.

</comment><comment><USER31> Whatever happened to "Community Radio" low-power licensing? Or is a 3 mile radius just too small?

<comment><USER20> They aren't currently issuing LPFM licenses.

Commercial operators and, in particular, NPR have fought incredibly hard against LPFM even with the anemic power/radius limitation.

</comment></comment><comment><USER32> In the days of streaming over the Internet I don't see the need for pirate radio stations.

<comment><USER33> It is harder to track who's listening to which FM station and might be useful if your internet is being blocked or censored

<comment> kube-system On the other hand, internet radio is useful if your FM station is being blocked or censored.

</comment></comment></comment><comment> sh-run I'm completely unfamiliar with this, but could they not get HAM licenses and operate on amateur radio frequencies? Or simply turn what they are doing into a podcast?

Or is the issue that their target audience only has access to AM/FM radios?

<comment><USER34> That, plus Ham radio basically doesn't allow broadcasting. Ham radio communication is (more or less) intended to be between parties that communicate with each other. There are some exceptions, like telemetry, but Ham isn't intended to replace commercial broadcast stations.

</comment></comment><comment><USER35> The FCC's purpose from its inception was to centralize power in the hands of a few powerful capitalists. In a free country, why would the national government have complete control over a radio station that broadcasts solely within a single state or city?

[https://reason.com/2017/04/05/roosevelts-war-against-the- pre...](https://reason.com/2017/04/05/roosevelts-war-against-the-pre/)</comment>


Reinventing Home Directories - <AUTHOR> https://media.ccc.de/v/ASG2019-164-reinventing-home-directories <comment><USER2> Full Disclosure: I am violently opposed to systemd and pulseaudio (before it was taken away from Poettering).

However, I think I'm seeing a pattern, Poettering identifies real issues and actually tries to fix them.

But it seems like his ambition is impeding his ability to consider those who do not want to approach the fix his way. It's never a measured approach, it /feels/ like a "lets write it now and figure out all the problems down the line and fix them" which, for core pieces of software is a dangerous mindset.

After watching the intro here I agree with him, the current state of things is not ideal, and nobody _wants_ to touch user account management on Linux. On MacOS for example, it's much more thought out, and I think Linux could do it better.

As much as I hate poetterings specific approaches (and, subsequent lockout) I have to give credit to him identifying these issues and actually trying to fix them, it's more than I do. Then again I am a lowly sysadmin type.

<comment><USER3> I like the tone of your comment, unlike many others here. But to your remark:

"But it seems like his ambition is impeding his ability to consider those who do not want to approach the fix his way. It's never a measured approach, it /feels/ like a "lets write it now and figure out all the problems down the line and fix them" which, for core pieces of software is a dangerous mindset."

I'd like to say that he forces nobody and so we should not complain about his creative endeavors. The market will decide, and you, will decide.

<comment><USER2> I disagree, you can argue the semantics of if it's him specifically or if it's another project that decides it will only target systemd/pulseaudio. But the fact that if I want a stable distro for server usage in 2019 I _must_ use a systemd distro speaks to the fact that I am indeed forced to use it.

Maybe that's just adoption though, typically the sysadmin community considers the "safe" options to be CentOS/RHEL or Debian Stable. Both of which default to systemd. (and no sysadmin is going to change the init system on production servers unless it presents some abject nightmare, short of eating 30% CPU/Mem-- it's core software, it wont be touched).

Projects like Devuan are simply not considered safe choices by the majority of the sysadmin community, and there's no alternative for RHEL-esque sites.

So, semantically: it's not poetterings fault. But at the same time, I'm still forced.

<comment><USER4> You can use a BSD or Slackware.

<comment><USER5> Or Alpine Linux. I believe it's already one of the best-regarded distributions for the container space, and it uses OpenRC, not systemd.

<comment><USER6> OK, but aren't most Alpine instances running in containers hosted by Linux instances using systemd?

<comment> yjftsjthsd-h That doesn't mean it doesn't work fine as the base layer. I run Alpine on bare metal... actually, I really like Alpine as the thing that hosts KVM and/or Docker, too.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I haven't yet watched the video, but I'm pretty familiar with the concept from previous links, and I had the following thought about the controversy this project will probably create.

Personally I've been consistently happy with Poettering's projects, especially PulseAudio and systemd. Systemd is just an infinitely better way of handling init and service configuration than anything else _I 've_ used on Linux (the weird amalgam of systemd and other service configuration tools you find on a lot of distributions these days strikes me as a particular abomination that hides how nice a cleanly configured systemd setup can be). I would be happy to use a Linux system designed entirely by LP (the infamous systemd/Linux); it would probably be a lot better designed than what we have now. (I'm not really familiar with what the BSDs are doing these days, so I can't comment on them.)

My one complaint, which I think is behind many of the criticisms of systemd, is that I don't see why it needs to be so tightly integrated. I would prefer to see many of the projects under the systemd umbrella (Wikipedia describes systemd as a "software suite", which is telling) broken apart into individual programs that can be run entirely independently. Network management, logging, and container management seem like they could all be separate projects. This new one probably should be too. I get the nagging feeling that if Poettering created PulseAudio today, it would be systemd-audio, and therefore wouldn't be as useful to Linux users universally as PA is.

<comment><USER7> What did you use besides systemd and sysv? Personally, while I'm ok with systemd, I think Upstart was a decent replacement for the pile of scripts of yore, and gained little from the switch from it to systemd (we used Ubuntu Server where I worked).

<comment><USER5> I used Upstart, and I briefly tested systems with OpenRC. I wasn't really happy with the configuration tools or the service file format with Upstart, and actually Ubuntu's attempt to do a kind of hybrid between a traditional SysV init and Upstart, and now a hybrid with systemd (the "service" command somehow still exists on Ubuntu!) was one target of my ire in the comment.

</comment></comment></comment><comment><USER8> Just copied the following from the slides.

It all seems reasonable to me. Linux home directories are a bit of a mess and unportable.

Can someone explain to me the hate for systemd other than: "It's trying to do too much" "I hate Poettering" "I prefer things to stay the same, that's why I use a ThinkPad from 2008"

 _These are their identified problems:_

      Needs writable /etc + Mixes State and Con guration

      UID assignments need to be propagated between systems

      No encryption (Or \mismatching" encryption)

      No modern authentication mechanisms

      Not extensible; plenty \Sidecar" databases (/etc/shadow,

accounts-daemon, samba, SSH, pam limits)

      No resource management

_These are their stated goals:_

      Migratable Home Directories (all the way to the point of

\home-on-a-stick")

      Self Contained Home Directories (i.e. mere existance of a  le

/home/foobar.home synthesizes a user foobar)

      UID assignments as local artifact

      Unification of User Password and Encryption Key

      Extensible User Records

      Lock LUKS on System Suspend

      Yubikeys, from day #1

"Complications:*

      SSH Logins

      Disk Space Assignments

      UID Assignments (chown() on login)

      LUKS Locking

_They have two solutions:_

Concept A: JSON User Records

(Superset of NSS records: struct passwd + struct group)

Queriable via Varlink interface

Convertible forth and back (lossy though, necessarily)

Concept B Encrypted LUKS Home Directories in Loopback Files

(/home/foobar.home with JSON records in ~/.identity)

Managed by systemd-homed.service

Concept A may be used without Concept B though

<comment><USER9> > Can someone explain to me the hate for systemd other than: "It's trying to > do too much" "I hate Poettering" "I prefer things to stay the same, that's > why I use a ThinkPad from 2008"

These are all perfectly valid reasons, you can't just hand-wave them away. The way you phrase them makes them semi-strawmen but they're just the equivalent of conventional wisdom: "do one thing well", "don't put all your eggs in one basket" and "don't fix what isn't broken".

And also, my ThinkPad is from 2012, thank you very much.

<comment><USER10> Just to be clear, "I hate Poettering" is a perfectly valid reason, and not at all ad hominem?

<comment><USER9> "I hate Poettering" is an ad hominem, but also a strawman. It's perfectly legitimate to not trust Poettering, or anyone else for that matter, to have such an individual influence over the entire FOSS ecosystem.

</comment></comment></comment></comment><comment><USER11> Slides: [https://cfp.all-systems-go.io/media/homed- asg2019.pdf](https://cfp.all-systems-go.io/media/homed-asg2019.pdf)

Conference website: [https://all-systems-go.io/](https://all-systems-go.io/) (September 20-22, 2019)

</comment><comment><USER12> I like the idea of logging in with a Yubikey, but this presentation seems out of touch with the requirements of the real world: folks needing to SSH into cloud machines without logging in to a physical console first; IT departments that need to reset a forgotten password or decrypt a hard drive for compliance reasons; people who have multiple Yubikeys; people who change passwords and don't want to spend hours re-keying the encryption on their USB key.

<comment><USER13> He starts the talk with something along the lines of: this is what I want for my laptop, not servers. It's explicitly meant for personal machines, not cloud machines. There is no reason why those should have to change, they're served pretty well by account management as it is today. Laptops are not, and he's trying to fix that.

And by the way, LUKS has multiple authentication slots (you can have multiple passwords for the same volume, for example a long random password that the IT department keeps in a safe place if they ever need to access the volume) and it takes a second to re-key, not hours. This is all well-known. But Poettering brings out the worst knee-jerk reactions in people.

<comment><USER14> While for a laptop many of those problems he describes are non issues. I.e. configuration via LDAP doesn't happen on a laptop.

That said: Integration with encryption and so on is definitely good. So maybe this goes too far in some direction, but too little I. The other?

<comment><USER13> Enterprise-managed laptops need this just as much as my personal machine, they are woefully underserved by current user management.

<comment><USER15> Enterprise managed laptops typically run Windows or OS/X. I haven't seen a Linux laptop in the wild at the enterprise level for years. Which companies use those?

<comment><USER16> > Enterprise managed laptops typically run Windows or OS/X. I haven't seen a > Linux laptop in the wild at the enterprise level for years.

Chicken-egg. If you don't have appropriate management features (like the ones introduced here), then you don't get enterprise deployments.

<comment><USER15> That's RedHat's wishful thinking at work. Linux on the desktop is called 'Chromebooks', not 'RedHat'. They missed that boat by a couple of years and it is not coming back.

<comment><USER16> So which is it?

\- This is going to be so awesome that "everybody and their brother can't stop themselves from tripping over their own feet to adopt".

or

\- Wishful thinking, doesn't matter.

<comment><USER15> Package managers and distro maintainers are not typically the end-users I have in mind.

But if you can't see these groups as different then that's fine, but lets just leave it at that I, an end user was forced to adopt a set of system changes that I had no influence over because of RedHat's continued aspiration to put 'Linux on the desktop' when that had in fact happened ages ago.

That you feel that adoption only happens because something is 'so awesome' is putting the horse behind the cart, stuff gets adopted all the time when better alternatives are available, all it takes is enough clout behind the push and it's a done deal.

If technical merits were the deciding factor DR-Dos and OS/2 would still be around today instead of their lesser alternatives.

<comment><USER17> So, basically, people who maintain the system you use have made decisions on its evolution that you don't like. Keeping the system as it is would have been another, arguable, possibility, not the obvious thing to do.

I can't see any solution to this problem for you apart from another system emerging with features you like (maybe from a fork). Which is not trivial.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> The interesting thing here for me (aside from the actual ideas about home directories) was varlink. Is this the new D-Bus?

It looks like yet another IDL and server/client. Aside from being JSON etc, what are the advantages of gRPC/protobuf, or even ONC RPC and XDR?

Oh and full disclosure: I actually like the various systemd utilities and functions. Things like the resolver replacement can be a pain when you want to do weird split horizon and other things, or for bastions of VPNs, but as systemd has "settled" it compares reasonably well to Sun and Apple's equivalents.

</comment><comment><USER19> Perhaps ironically, here's a link to the presentation PDF that was posted yesterday: [https://news.ycombinator.com/item?id=21036020](https://news.ycombinator.com/item?id=21036020)

And my comments there:

> _What a good idea._

> _Here 's the hyperlinkified link to the {systemd-homed.service, systemd- > userdbd.service, homectl, userdbctl} sources from the PDF: > [https://github.com/poettering/systemd/tree/homed](https://github.com/poettering/systemd/tree/homed) > _

> _Hadn 't heard of varlink: [https://varlink.org/](https://varlink.org/) _

> _Is there a FIPS-like subset of the most-widely-available LUKS configs? > Otherwise home directories won 't work on systems that have a limited set of > LUKS modules. _

</comment><comment><USER20> Slightly off-topic, but why WebM video is larger than MP4? Isn't WebM standard more efficient?

<comment><USER5> WebM and MP4 are containers, not video codecs. You can't assume anything about the efficiency of the video just by knowing the container. In this case, the WebM files contain video encoded with the VP8 codec, which in my opinion is significantly less transparent at the same bitrate than the h264 codec that the MP4 file contains.

But it's more likely that whoever encoded these files did so without trying to hit specific transparency targets, so you shouldn't really conclude anything from the file size.

</comment></comment><comment><USER15> Change for change's sake is the worst possible reason for change. All this systemd stuff can jump off a cliff as far as I'm concerned. The main reason why I chose for Linux on my desktop and laptop machines is because I like the stability of the platform, the lack of non-sensical change and the fact that it makes it much easier to switch between desktop and server environments.

Not that I want my servers to be more like my desktop, but the other way around.

Where Poetering & Co. get it completely wrong - just speaking for myself here - is that the lack of change in the Linux world to me is a good thing. It means that any investment in time will pay back over many years.

<comment><USER16> > Change for change's sake is the worst possible reason for change

Which is not the case here. The slides outline what is currently lacking and why and how improvements are needed. Admittedly this seems more driven by enterprise needs (LDAP, encryption, yubikey support etc.). You can rightfully criticize the systemd project for many thinks, but "change for change's sake" is definitely not among them.

> Not that I want my servers to be more like my desktop, but the other way > around.

In which way are managed, scriptable home directories not more like servers?

<comment><USER15> Yes, you can always come up with a bunch of mumbo-jumbo to justify that which you wanted to do anyway. That's how the whole systemd madness got going and it will continue until all of the system has been consumed.

Take pulseaudio as a nice example: works for 95% of the trival cases, fails for 100% of the more complex cases. The more Linux is dumbed down the harder it gets to do real work.

A desktop on top of a powerful multi-user system is far more capable than a trimmed down Unix under a slick, single person UI. We already had that, it's called Mac OS/X and those who want it have had that option since forever.

<comment><USER7> I don't see how PA is "trimmed down" or "dumbed down". From what I can tell, it provides quite a few more features than ALSA+dmix, which was the solution typically used previously. For example, I can now route the output of mpv to HDMI so someone can watch a movie, while I route other applications to my bluetooth headphones. Was this possible with ALSA?

<comment><USER15> > Was this possible with ALSA?

Sure, but truth be told ALSA required a bit of knowledge to set up properly. But instead of re-doing the whole audio system from the ground up and tossing away the good with the bad it could have been done just as well by making a proper ALSA auto-configurator. No need for all this re-invention in more buggy ways.

Besides that, when PA came out you couldn't do any of that either, it was barely usable and the most frequent PA related activity was 'uninstall'.

<comment><USER7> >> Was this possible with ALSA?

> Sure

Fair enough. I did look and I couldn't find any way to set up independent outputs from different inputs. In any case, I still don't see the dumbing down.

> Besides that, when PA came out you couldn't do any of that either, it was > barely usable and the most frequent PA related activity was 'uninstall'.

Most FOSS software is released to the public at a very early stage. The problem is trigger-happy distros including it by default too soon, but that's not PA's team fault.

<comment><USER15> If the 'trigger happy' distro happens to have a billion dollar company behind it then you can forget about packages competing on merit.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> One thing that will need to be fixed is the ssh access that his current scheme does not allow. I cannot see how I should be logged into my machine on another continent before I can log into it again. Paradoxically this would mean moving the ssh keys, or equivalent, out of $HOME, which is the opposite of what he wants.

<comment><USER22> Indeed. This seems like a very severe limitation. If the computer gets rebooted, either due to updates or power-loss, you effectively lose access to the machine until you can get to it physically.

So for me, his solution only works for computers for which you want casual SSH access to. Which would be the minority of my computers.

<comment><USER23> Workstations, not servers.

<comment><USER22> I routinely log on to my work computer remotely. I couldn't use a system which denied me that just because the computer rebooted for whatever reason.

</comment></comment></comment></comment><comment><USER24>
      Microsoft: Embrace, Extend, Extinguish
      Lennart: Reject, Rewrite, Extend, Extend, Extend

</comment><comment><USER25> oh great, Lennart's here to help again.

<comment><USER3> Seems like his last 2 projects were pretty successful. What was your last contribution that was taken up at such scale?

<comment><USER26> What is the point of such a question? Writing software that is successful in the sense it gets major adoption is not necessarily desired by power users. On the contrary, we have a well known example in systemd. That's why you see sarcasm here, people are afraid of what is yet to come.

If the "successful software" is causing you only problems and upon inspection, you discover it is restricting your computing, you're likely to worry about next project of the author.

</comment></comment></comment><comment><USER27> This systemd train has to stop. Why isn't Poettering just forking the Linux kernel for his very own systemd-OS distribution? If any of the Linux distributions I'm using touches the home directory because of Poettering's say-so in that video I'll cease using and supporting them.

<comment><USER3> Isn't anyone free do make what they want and see if the market takes it up? Anyway, this week's Linux Action News [0] has a nice breakdown of the features, I think it is better to discuss the merit and downsides of this that to just shouting: "Stop the systemd, pulse-audio, any-new-feature-that-scares- unix-natives -train."

[0] [https://linuxactionnews.com/](https://linuxactionnews.com/)

<comment><USER27> No. Because this nonsense will break my systems.

What is this? Some crazy guy makes significant changes to a standard, the distribution maintainers will just gobble it up (as per usual) and then I have to weigh the pros and cons instead of complaining and fixing/adapting my systems e.g. wasting time because of a crazy guy's ideas?

There is no _market_ in OSS. It's either use it or leave it. But even in OSS there are established standards which are relied upon! Poettering doesn't care about that, because he likes change.

<comment><USER28> If systemd-adoption would make it harder to maintain a distro, the distros would not have adopted it.

Instead, systemd solves a lot of problems for distro maintainers. The didn't just "gobble it up", they made a very measured choice to adopt it.

<comment><USER29> Now what were those problems, specifically, for distros, that weren't caused by systemd eating and replacing previous solutions, which suddenly became unmaintained and unsupported?

(I'm looking especially at udev and all the dbus hookery.)</comment></comment></comment></comment></comment>


C++ Algorithms, Boost and function currying - <AUTHOR> http://blog.objectmentor.com/articles/2010/06/12/c-algorithms-boost-and-function-currying

<comment><USER2> The author went from this:

        int Dice::total() const {
          int total = 0;
          for(const_iterator current = dice.begin();
              current != dice.end();
              ++current)
            total += (*current)->faceValue();
          return total;
        }

to this:

        int Dice::total() const {
          return std::accumulate(
              dice.begin(),
              dice.end(),
              0,
              bind(std::plus<int>(), _1, bind(&Die::faceValue, _2))
          );
        }

and shows his intermediate steps. I took his last variant and converted it to the following, using Intel Threading Building Blocks to perform a parallel reduce:

        class Sum {
            const std::vector<Face*>& v;
        public:
            int sum;
            void operator()( const tbb::blocked_range<size_t>& r ) {
                const std::vector<Face*>& a = v;
                for( size_t i = r.begin(); i != r.end(); ++i )
                    sum += a[i]->faceValue();
            }
            Sum( Sum& x, tbb::split ) : v(x.v), sum(0) {}
            void join( const Sum& y ) {sum += y.sum;}
            Sum(const std::vector<Face*>& a ) : v(a), sum(0) {}
        };

        int Dice::parallel_total () const {
            Sum s(dice);
            tbb::parallel_reduce(tbb::blocked_range<size_t>(0, dice.size()),
                                 s,
                                 tbb::auto_partitioner());
            return s.sum;
        }

I had to guess what his Dice implementation contained and if I wrote in from scratch, I may have done it differently (eg, I'd handle that vector in Sum differently). Also, it doesn't really seem worth it performance-wise ;-) but still interesting to see it in action.

</comment><comment><USER3> A more declarative programming style has many potential benefits. The trouble is, the version in that style is supposed to look something like this:

        total dice = sum (map faceValue dice)

C++ is showing its age now, as ideas from other programming styles are entering the mainstream. Modern programming languages, designed with the benefit of hindsight, support those idioms natively and much more effectively than a bolted-on library, the cleverness of the Boost implementers notwithstanding.

In this context, I think one of the commenters on the original article probably had it right: given that C++ is essentially an imperative language, using the new range-based for loops is a more natural way to write this algorithm.

</comment><comment><USER4> Okay, I admit this is the first time I've seen the word 'currying'. I've heard it spoken and thought it was a neologism derived from "courier", but it's apparently named after a man called Haskell: <http://en.m.wikipedia.org/wiki/Currying?wasRedirected=true>

</comment><comment><USER5> This is also currently on HN as part of zedshaw's post on Shedding Bikes: <http://sheddingbikes.com/posts/1276445247.html> <http://news.ycombinator.com/item?id=1427599>

</comment><comment><USER6> why use bind and not a "c++ lambda" if you are using boost?

The expression:

bind(std::plus<int>(), _1, bind(&Die::faceValue, _2))

makes the code harder to read instead of easier, which isn't an improvement.

</comment><comment><USER7> Where functional programming in C++ falls apart is this step:

      bind(std::plus<int>(), _1, bind(&Die::faceValue, _2))

When I first learned the STL, I worked pretty hard to figure out bind, etc., and get rid of all my for loops. The problem is that it doesn't actually buy you that much. The for loop is uglier, but simpler to maintain, read, and debug.

Luckily the lambda syntax from the new standard already appears to be available in experimental gcc. This is going to be a game-changer.

<comment><USER8> The lambda stuff is in g++ 4.5, which is a stable release, right? It's not really experimental.

<comment><USER9> Lambdas are also supported in MSVC++ 2010.</comment></comment></comment>


Hey Ubuntu, Stop Making Linux Look Bad - <AUTHOR> http://www.linux-mag.com/id/7600 <comment><USER2> I might be among those that got a flawless Ubuntu upgrade. The poll now says ( <http://ubuntuforums.org/showthread.php?t=1305924> ) 18.25% had flawless upgrades, 15.19% had flawless install.

Of course Ubuntu has bugs, but I _bet_ its a lot more user friendly that other Linux distro's out there. The processes will certainly improve a lot from here.

And Ubuntu certainly doesn't make Linux look bad.

</comment><comment><USER3> I havn't had any problems at all with the Karmic version. The past two or three Ubuntu releases have installed similarly without fuss (and I've installed on multiple PCs and laptops of varying ages). I don't care about Samba, and I don't have a tablet or Intel graphics.

</comment><comment><USER4> > Linux is meant to be stable, secure, reliable.

Disagree. It's meant to scratch a lot of different itches that a lot of different contributors have.</comment>


Infinitely Scalable Framework with Amazon Web Services? - <AUTHOR> http://blog.nanobeepers.com/2007/04/07/infinitely-scalable-framework-with-aws/ <comment><USER3> This is pretty interesting. I'm not sure I understand what you mean though about separating databases "by user". Could you elaborate on that? How would my application's database change if I were a user of this service?

<comment><AUTHOR> Sure. Basically each user would have their own database file generated on account creation. Then in your app, instead of doing something like:

connectDB("/path/to/db")

you would do:

connectDB("/path/to/$user/db")

Also, if you needed to query all of your users data in aggregate, you would use the 'ATTACH' capability of SQLite to essentially create a master database. Note that you will need to design your scheme appropriately (thoughtful table/column naming, etc) for this to work well. See: <http://www.sqlite.org/lang_attach.html>

</comment></comment><comment><USER4> From what I've read of evaluations of S3, the latency of S3 requests seems significant. Significant enough that using S3 as a backend database doesn't seem feasible. Is this true or am I mistaken?

<comment><USER4> I forgot to mention that I think this is fantastic idea. I'm just not sure if it will be able to replace a local mysql cluster.

<comment><AUTHOR> Thanks, AWS is amazing and has been super fun to play with. This solution will of course only work for a certain subset of apps. Apps that require more database complexity will not be a good fit for this framework. My apps are typically designed so simply that they could just use a flat-file storage system instead of a db. SQLite is awesome because it provides the flat-file storage, but in a format that allows you to query it like a normal database. The simplicity of that model is amazing and hard for me to resist. I've used mysql clusters in most of the projects while working for companies, but I often found that the added complexity did little for us. My last company hired two database guys with fat salaries just to manage it. My goal with this framework is to really reduce the cost of maintenance, backups, etc. S3 is distributed and so really doesn't need much in the way of backups - <USER2> backing up this system is a simple as tar gziping the directory of flat-file databases.

This was interesting from pg's Viaweb FAQ:

<http://www.paulgraham.com/vwfaq.html>

"What database did you use?

We didn't use one. We just stored everything in files. The Unix file system is pretty good at not losing your data, especially if you put the files on a Netapp.

It is a common mistake to think of Web-based apps as interfaces to databases. Desktop apps aren't just interfaces to databases; why should Web-based apps be any different? The hard part is not where you store the data, but what the software does.

While we were doing Viaweb, we took a good deal of heat from pseudo-technical people like VCs and industry analysts for not using a database-- and for using cheap Intel boxes running FreeBSD as servers. But when we were getting bought by Yahoo, we found that they also just stored everything in files-- and all their servers were also cheap Intel boxes running FreeBSD.

(During the Bubble, Oracle used to run ads saying that Yahoo ran on Oracle software. I found this hard to believe, so I asked around. It turned out the Yahoo accounting department used Oracle.)"

</comment></comment></comment><comment><USER5> The terms1 of S3DFS don't work for me so I suggest people look at MogileFS. I just learned about it recently, so I can't give a review... but it looks interesting.

<http://www.danga.com/mogilefs/>

1 Will pay good money for software, their prices are ok, just don't like the feeling I get that they will have my company by the balls.

</comment><comment><AUTHOR> Added this in the hopes of getting some good feedback from the community on this framework I'm developing.

The post is derived from this comment: <http://news.ycombinator.com/comments?id=9991>

</comment><comment><USER6> You may want to take a look at <http://www.enomalism.com,> it provides migration to and from Amazon EC2 as well as the ability to create your own geo-targeted cloud.</comment>


1st Ship Goes Through Expanded Panama Canal - <AUTHOR> http://www.usatoday.com/story/news/world/2016/06/26/bigger-ships-panama-celebrates-opening-its-expanded-canal/86403210/ <comment><USER2> 1st Ship Goes Through Expanded Panama Canal

... and its Chinese!

We are living in a time of change.

On a somewhat different note, the site contains an intrusive script that automatically accesses and updates your FB feed.</comment>


Poll: Are you opposed to smartwatches because bluetooth has to be enabled? - <AUTHOR>

<comment><USER2> I didn't think of this yet and I had hoped there was wifi and not bluetooth - but in the end I don't think this would be a deciding factor, despite me having Bluetooth off since I first had a laptop that had it (2004). Addendum: I am not particularly interested in smartwatches, but I wouldn't mind one.

<comment><AUTHOR> Wifi would certainly drain the battery much more than Bluetooth Low Energy.

</comment></comment><comment><AUTHOR> A lot of people hate having bluetooth enabled because it enables another potential tracking vector.

</comment><comment><USER3> i'm not a fan of smartwatches since it feels like a toy and i don't see a lot of practical use out of it

</comment><comment><USER4> No. Watch is typically used as a piece of jewellery, so it should look like one. I'm yet to see a good-looking smartwatch.

Moreover, idea of a watch that needs to be recharged every two days is ridiculous. A quartz watch can go for months on a single battery.

And in exchange for frequent recharges one basically gets nothing that couldn't be done with a smartphone. It's not like smartwatch allows playing with software-defined radio, which is the case for Texas Instruments.

<comment><USER5> People said that charging your mobile phone each day was ridiculous too, but now we all do it. Besides, I wind my mechanical watch each day - that's never been a problem.

Obviously, whether you like the look of current smartwatches is your view, but lots of people - including those in the watch world - are praising Apple Watch for aesthetics and build quality. There are some nice looking watches on the Android Wear side coming out too, although I question the choice of circular display.

Here's the Apple Watch next to a Patek Philippe perpetual calendar, arguably one of the finest watches in the world. Honestly, whilst it will never match such a classic, it stands up pretty well.

[http://cdn.hodinkee.com/uploads/block/inline_image/content_i...](http://cdn.hodinkee.com/uploads/block/inline_image/content_image/7162/x580x9999__img.jpg) [http://cdn.hodinkee.com/uploads/block/inline_image/content_i...](http://cdn.hodinkee.com/uploads/block/inline_image/content_image/7163/x580x9999__img.jpg)</comment></comment>


Show HN: hulk, an in-browser JSON editor - <AUTHOR> http://github.com/kevinburke/hulk?

<comment><USER2> This may have some appeal, though I much prefer this implementation [1][2] even if it might be less accessible

[1] [http://www.jsoneditoronline.org/](http://www.jsoneditoronline.org/) [2] [https://github.com/josdejong/jsoneditor/](https://github.com/josdejong/jsoneditor/)

</comment><comment><USER3> It seems like there are overlapping conventions.

"null" means null but => is the separator instead of :

<comment><AUTHOR> Agreed! I'd prefer ":" but when I was testing it out it was difficult to pick it out between the input fields. Hence I went with the Ruby convention.

You can change it via the `separator` option in the options menu.

</comment></comment><comment><USER4> There should be some way to specify the type of a field, for example if someone wants to input the string "false" or "true". Also a phone number such as "+00334561111789" would be converted to an integer "334561111789".

<comment><AUTHOR> thanks for the feedback! I'll see if I can make this work. It would be difficult to preserve that value if someone clicks "Add new element" for example but I'll see if I can think of a preference for it.

</comment></comment><comment><USER5> With this kind of editors you loose simplicity. How can you duplicate one of the objects to make another object? How can you move something in a tree? It just doesn't work for me.

</comment><comment><USER6> I would add also this [http://json.parser.online.fr/](http://json.parser.online.fr/) to the discussion, quite useful and nice too.

</comment><comment><USER7> I prefer this kind of visualization: [http://jsonviewer.stack.hu/](http://jsonviewer.stack.hu/)

</comment><comment><USER8> How do I create an array?

<comment><AUTHOR> Hi saraid216, That's not possible at the moment - the current implementation tries to match like with like.

One of my worries with this project is that JSON is so configurable, if you offered every option at every point you have way too many buttons and it becomes an unusable mess. Still though you should be able to add a button for a dictionary where all the values are lists. I'll add an issue for this in Github.</comment></comment>


"What will be Ruby's legacy?" - <AUTHOR> http://rethink.unspace.ca/2008/8/21/what-will-be-ruby-s-legacy <comment><USER2> When will the Ruby fanboys stop being such fanboys? This is just more of the same masturbatory "we're great" bullshit which seems to be so popular in the Ruby community.

Referring to Rails:

 _"we sent out a press release to everyone we knew suggesting that we would be building all future projects on this new open source framework that nobody had ever heard of."_

So I guess I shouldn't expect much level-headed writing from a guy who would make that stupid a business decision. How about taking six months to quietly build some internal sites, a couple pilots for clients, and to actually learn the language and framework? My shop's transitioning into using Drupal for most projects, but it's not as simple as flicking a switch.

I like this nugget too:

 _"Ruby has captured the hearts and imaginations of artists and the poets."_

Both the "artists" and the "poets" links go to blogs of people who are pretty obviously software developers first and foremost.

<comment><AUTHOR> You know, there's a lot of room in the world for people who make sensible business decisions, who don't get caught up in hype, who don't consider their work to be art or poetry or music.

But I hope there will always be room for people who think what they're doing is great and who have an incurable enthusiasm and optimism for it.

If that isn't level-headed, I say _fantastic_. How very dull and drab our world would be if nobody ever fell in love with technology.

<comment><USER2> I didn't say that masturbating is necessarily a _bad_ thing, I just don't like watching others do it.

<comment><AUTHOR> I can't go along with your simile on this one. You sound just as emotionally invested in this issue, but from a very negative, dark perspective. I hope you find happiness elsewhere.

</comment></comment></comment></comment><comment><AUTHOR> _Let's face it, people with access to special power or information are always threatened by a future where their pet special thing is now common and mundane._

</comment><comment><USER3> _In Ruby, it's cool to learn all about things that used to be the realm of the academic elite: functional programming, parallel processing, finite state machines, compiler optimization, MapReduce…_

What does this have to do with Ruby?

<comment><USER4> Not much with the language directly (though Ruby owes a lot to functional programming). But the Ruby culture puts emphasis on learning about these sorts of things.</comment></comment>


Kotlin becomes second most popular language on the JVM - <AUTHOR> https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-become-the-2nd-most-popular-language-on-the-jvm/ <comment><USER2> I started using Kotlin daily about 8 months ago.

Recently had to go back to an older Android codebase, and immediately decided I had to start converting.

The amount of boilerplate is unbelievable. I'm able to cut the number of lines by half while increasing readability. Type/null safety is a huge added bonus

P.S. Kotlin extensions are the best

<comment><USER3> About one and a half year ago we also decided to give kotlin a shot. After a few months my opinion was similiar to yours. Extension-functions, yeah!

Anyway, nowadays you wouldn't see me making the same statements anymore.

My first issue appeared when I was maintaining an Android app written in Java. I needed an library for some functionality. The only maintained ones were kotlin-libs. But interoperability, right? I didn't hesitated to include it. There is no way to use or extend functionality with typealiases in your java code.

IntelliJ can compile Kotlin into Java and it is easily accessible. But there is no adb debugger for kotlin.

Null Safety is just overhead imho. I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it. And its more easily grep- pable the Java way.

Writing Kotlin is not so fluent as one would guess, the tooling only fools you, that it is. You can easily make use of actions like typing pfi (extends to public final int) for java aswell. But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything.

Additionally, i do not like the implicit type on member property declarations used by almost anybody. The benefit of typing less boilerplate becomes annoying when reading sources outside your ide.

Boilerplate in my opinion is code i need to write by myself. When it is generated by any IDE, i do not bother about it. We are so familiar with Java that we can abstract this boilerplate when reading sources.

Spelling Kotlin to somebody via telephone is also strange for me.

I stopped promoting Kotlin as a Java killer. Code style is too different between different developers.

And why are we creating the same libraries once again?

<comment><USER4> > But when your property changes from nullsafe to nullable, you need to > rewrtiging eeevverything.

Isn't the fact that you have to be explicit about null the main feature of explicit null safety?

<comment><USER3> Yes, it is, but the domain req. can change, requiring to handling an nullable result

<comment><USER5> Isn't that the one big situation where null safety _really_ shines? Something that used to be required is now optional, so, you need to visit all the use sites to figure out what a sensible behaviour is when the data isn't there.

Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.

<comment><USER3> Thank you, I shall be more precise when giving any comment. Honestly, I have not considered the advantages from null-safetyness (rated anything..) properly before posting. I just wanted to rant about kotlin, since i hear too many prayers about it and my gud (stomach) tells me different. I am not able to put it into words, yet. I really appreciate your hint.

Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so.

Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily..

Thankfully..!

<comment><USER5> You're welcome!

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Let me ask a question as someone with pretty minimal Java experience. If someone was starting a greenfield JVM project today, is there really any compelling reason _not_ to choose Kotlin over Java?

Because the impression I get is that Kotlin is a strict improvement along every dimension. But as an outsider, I'm not sure if I"m just being blinded by hype.

<comment><USER7> There's also the question of long-term sustainability. Groovy was very cool and popular in 2010. Ten years later, Groovy is still in the production codebase while the language is essentially dead.

I personally wouldn't go for anything but Java (on JVM, that is) for anything that isn't a pet project.

<comment><USER8> Note that with Kotlin, JetBrains created it initially for working on their IntelliJ IDE and are porting their Java codebase to use Kotlin. So that is a good indicator of long-term sustainability.

<comment><USER9> Nowadays there are trying to just get Kotlin anywhere and it remains to be seen how Valhalla and Panama will be usable from Kotlin.

<comment><USER5> Panama would not seem to pose any problems as it's all code generation with MethodHandles/VarHandles. That should be directly callable from Kotlin.

As for Valhalla, it remains to be seen how it's usable from Java, let alone anything else. But Kotlin already has a form of value type (inline classes) so perhaps it'll be an extension of that.

<comment><USER9> Kotlin inline classes are heap allocated, they are just syntax sugar for regular classes.

One cannot just change their semantics after the fact.

<comment><USER10> Kotlin's inline classes (and Scala's AnyVal classes) are syntax sugar for static methods. The object itself is erased completely whenever possible (just like primitive values).

<comment><USER9> Which is not the same as the semantic meaning of doing stack allocations or being stored in registers.

<comment><USER10> The following:

        case class Foo(x: Int) extends AnyVal {
            def square: Int = x * x
        }
        val bar: Foo = Foo(5)
        println(bar.square) // => 25

Compiles down to (the moral equivalent of)

        object Foo {
            def square(x: Int): Int = x * x
        }
        val bar: Int = 5
        println(Foo.square(bar)) // => 25

If the inner value (x, in this case) can be stack-allocated or stored in registers then `Foo(x): Foo` will as well. `Foo(x): Bar` (where Bar is a supertype of Foo) will be autoboxed, but that also applies to primitive types (`5: Any` becomes a java.lang.Integer in memory).

<comment><USER9> Neither of those represent the same semantics of:

        inline class { ... ]

Which is guaranteed to be always stack-allocated or stored in registers, again you cannot retrofit semantics, specially when passing those classes to binary libraries.

<comment><USER10> You're correct that the Scala version isn't ABI-compatible. But Scala doesn't care about ABI between minor releases anyway, so that probably wouldn't stop them from changing it to align with Java.

There is also precedence for this, Scala 2.12 changed the encoding of lambdas from anonymous classes to Java 8's invokedynamic.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I was surprised to see that Clojure scored better than Scala. Is Scala loosing its appeal? Did Dotty scare people away, because it smells like Python 2 vs 3?

<comment><USER12> My feeling is that between sbt being painfully slow and Java 8 getting lambdas, people lost interest in Scala.

<comment><USER13> Maybe. I just wanted to point out that there's Mill as a build tool for Scala: [https://github.com/lihaoyi/mill](https://github.com/lihaoyi/mill)

(by the Scala.js maintainer Li Haoyi)

<comment><USER14> The last time I gave Mill a shot, I couldn't find a way to authenticate into private artifactory repositories, which made it kind of a nonstarter. Do you know if this has since been added?

</comment></comment></comment></comment><comment><USER15> Solid tooling can really boost a language. Clojure advocates should internalize that.

<comment><USER16> emacs and cider are rock-solid tools for Clojure, as are equivalent plugins for other lisps. It's not a very beginner-friendly tool, but I'm pretty convinced it really is the best environment for lisp development there is.

I'm not saying that having more mainstream tooling wouldn't be good, but people should not be discouraged from Clojure or Lisp development because of an apparent lack of tooling.

<comment><USER15> Telling someone new to a language to start with emacs & cider is a disaster. They are rock solid amazing tools for 2% of programmers. I like emacs, but it is harder to learn than Clojure, and trying to teach someone both at the same time is tough. Plus there is no real community unity in editor choice, so you have the community split over emacs, Cursive, VS Code/Calva, Atom. Plus a bunch of dead ends like Light Table or Nightcode.

<comment><USER17> You say that like having 4 or 5 solid editors for Clojure is bad because no unity. To me, it seems great because there are a wealth of choices for people that like different things and many of them are excellent, well above the bar for being a productive developer.

<comment><USER15> It is probably net positive for advanced users who have niche needs that the different editors address, but I'm saying it is bad for beginners/learners. More specifically, I'm saying emacs/cider is bad for beginners/learners, and the more traditional IDE options aren't so solid.

</comment></comment></comment></comment></comment><comment><USER18> Props to [https://ceylon-lang.org/](https://ceylon-lang.org/) for a good effort. It doesn't seem to be on the race anymore, but at the time it looked like a super interesting contender.

<comment><USER19> It was a good example of how to build a language in 4 years but the JVM language space is already filled to the brim. The only way to stand out is by having a large vendor bless it (Kotlin on Android).

<comment><USER5> I'm not sure that's the whole story. Kotlin was blessed on Android because it was growing like a weed, developers didn't need Google's permission to use it and weren't asking for it. The Android team went with the flow (smartly).

I evaluated Ceylon vs Kotlin in 2015, back when Kotlin wasn't even close to a 1.0 release and neither had any adoption. They're very similar in a lot of ways and so the choice came down to a lot of small things added up rather than any one big thing. I chose Kotlin for a lot of reasons, but a few (in no particular order) were:

1\. It had a more convenient syntax. The Ceylon designer felt that autocomplete meant verbose syntax didn't matter but it does. "variable Integer foo = 10" isn't just a typing issue but also a reading issue. "var foo = 10" is better.

2\. Ceylon deviated more from the JVM ecosystem than Kotlin, in particular, it invented its own collections like Scala, but which didn't appear to be much different to regular Java collections. This means idiomatic Ceylon would obviously _be_ a Ceylon library to users and not a Java library. Kotlin uses standard Java collections but enhanced via extension methods. It also provides a bunch of knobs to make the output classes seem like idiomatic Java classes in the few places that doesn't happen automatically, so you can reasonably use it for libraries. This makes a huge difference to Java interop. Kotlin is really the only JVM language that takes Java interop seriously: the rest all treat it as a price of admission to use the JVM at all and minimise their effort on it.

3\. Ceylon was mostly tooled for Eclipse which, in my view, is an inferior IDE to IntelliJ. The tooling was itself not as good as even the pre-1.0 Kotlin plugin.

4\. Ceylon had invested heavily in a complicated module and type system, which was the primary set of things they emphasised. These sorts of features have a relatively poor track record of delivering value; slightly-stronger-than-Java seems to be about the sweet spot at the moment. Much stronger than that and you end up in Haskell. Kotlin went in for more type inference and more usable generics (convenience), Ceylon

5\. Ceylon seemed much riskier to me (correctly). Nothing used it. It was clearly the project of one guy at Red Hat who'd had a previous successful project (Hibernate), but Red Hat weren't talking about it or using it in any way. On the other hand JetBrains had a large team assigned to Kotlin and were explicit that they were creating it to use in IntelliJ itself. The existence of a Java to Kotlin converter tool showed that they were completely serious about this, as J2K was a lot of work to build and would only be useful in a truly serious assault on existing Java codebases. Ceylon seemed far more interested in fancy type systems than the practical details of adoption.

6\. Ceylon had some weird gotchas and interop glitches that weren't normal for Java-like languages, like a sensitivity to the case of the first letter of identifiers (I know Go does this too) and difficulty handling Java arrays. There are named constructors (cool) which don't compile to static methods as is idiomatic for Java but some weird Ceylon specific notation (boo). This sort of thing showed it wasn't trying to be "just a better Java" which is what I was in the market for.

<comment><USER18> Wow, thanks for the analysis! I think it was very astute to pay attention to how Red Hat was supporting (or not) the language, it never occurred to me to look at the project from that POV, a really useful one.

I think the language is quirky in a lot of ways with the verbose syntax being one of them. I liked some aspects of the type system that made it look close to an ML flavor, although the language had heavy OOP syntax. In this way I thought it was similar to Scala.

There are a few nice write ups from the author on the process of coming up with the syntax. The one talking about constructors is a good example [1].

1: [https://ceylon-lang.org/blog/2015/06/21/constructors/](https://ceylon- lang.org/blog/2015/06/21/constructors/)

</comment></comment></comment></comment><comment><USER20> Having recently started writing a bunch of Kotlin to replace Java, I'm happy to hear this! Type inferencing, data classes, and non-nullability make it so easy to use and have helped me catch bugs, too! I don't enjoy it as much as TypeScript yet, but it's a close second :)

</comment><comment><USER9> No wonder, having an whole OS as godfather, with on maintenance Java language support.

However don't party too much, all of them counted together are still a minority versus Java on JVM, as clearly shown.

</comment><comment><USER12> I haven't used Kotlin, but when I read through some examples and guides, it felt like Java with all the messy legacy cleaned up, but it was still familiar.

</comment><comment><USER21> What is the methodology behind these results? If it is what I read in the introduction, judging Kotlin to be more widely used than Scala based on a poll is deceiving and IMO loses any weight this report might carry.

</comment><comment><USER22> We build and scaled a startup based on Scala code and successfully sold it, so - with all the Scala problems [0] in mind - Scala will always have a place in my heart. Using IntelliJ since a decade+ I wish those guys the very best with Kotlin.

[0] Binary incompatibilities, very very slow compilation speed, atrocious build tool

</comment><comment><USER23> Seems like Kotlin is basically "Java: The Do-over", right? Unlike Clojure and Scala, it aims for the same use-cases, a similar multi-paradigm balance, etc to Java, just with an extra 15 years of language design hindsight.

</comment><comment><USER24> My first impression is that Kotlin is being mostly being used by the android community.

Is anyone using Kotlin to write services, what are your experiences with that ?

</comment><comment><USER25> Kotlin is Java done right. It's what Java would have been from the start, if only original Java designers weren't C++ copycats in a rush.

<comment><USER26> Every single popular language was rushed, and every single one borrowed many ideas from elsewhere.

<comment><USER25> Yes, so it's great to see at least some of them get to the 1.0 version eventually (and I mean Kotlin = Java 1.0). Now if only we could get people off the pre-release versions of Java (which for some reason are named "Java 11", "Java 12" instead of "Java 0.9.1", "Java 0.9.2" as they should) and on to the real deal!

Seriously, I have great hopes for Kotlin. It corrects some Java's most egregious sophomore mistakes, it doesn't try (and fail) to be Haskell like Scala did, it's accessible AND has a major company behind it. Kotlin is surely something I wish I could use at work.

</comment></comment></comment><comment><USER27> I do think Kotlin is a 'better java' while Scala fails to satisfy that niche. However, I wonder if we'll actually see some big Open Source projects/platforms released that are written in Kotlin. For Scala you have Kafka, Spark and Flink which are widely deployed in the enterprise. Will Kotlin have a marquee infrastructure project to tout soon?

</comment><comment><AUTHOR> turk73's comment ([https://news.ycombinator.com/item?id=22258252](https://news.ycombinator.com/item?id=22258252)) can't be replied to for some reason so replying at top level:

I agree that switching between languages can kind of drain you of a good touch to your working language. I think this is a real downside about all the other langugaes that a dev today has to deal with too (Ansible, bash, CloudFormation, CSS, etc. I like Clojure because you can use the same good language on the frontend and backend.

> 3) Recruitment for Kotlin devs is impossible. You have to train people and > companies won't do that, so there's no pool of talent ready to go.

Is this really a common problem in the corporate world? In my experience people are to quick to pick up at least dynamic languages. I guess it's possible that Clojure is easier in this respect, or maybe Clojure jobs just attract people with a more exploratory attitude.

</comment><comment><USER28> I wonder how long is it gonna be until Kotlin will have the same fate as Groovy and Scala.

Don't get me wrong, I appreciate both Groovy, Scala as well as Kotlin. History has shown that Java has always managed to move forward and superseed the former.

</comment><comment><USER29> First is Java, 87%. Does anyone here know how JVM ecosystem is governed? Do the needs of Java dominate or can smaller languages get change requests in reasonably easily too?

<comment><USER30> Java dominates, also because that's the main source of engineering capacity.

There are some notable exceptions though. E.g. invokedynamic from JVM 7 was only really used for Java starting at 8 (with the introduction of lambdas), and was partially introduced to better support dynamically typed languages like Ruby on the JVM.

The languages do benefit from JVM improvements. Scala 2.12 had a significant speed-up due to native lamba support from JVM 8, and if project valhalla ever lands you can bet all JVM languages will be happy to use it.

<comment><USER9> Guest languages cannot make use of Valhalla/Panama without having plaform specific extensions.

Basically they will end up with some form of conditional compilation or performance loss emulating those features on other platforms (if at all possible).

</comment></comment></comment><comment><USER31> Yet still can't compile kotlin on android.

<comment><USER32> What would be the use case of compiling Kotlin on Android?

<comment><USER31> Developing on a phone or tablet.

<comment><USER32> But I mean... that must be a terrible developer experience. Why even bother?

</comment></comment></comment></comment><comment><USER33> Well deserved. No academic high browing, no armchair hammocking, just accessible pragmatism.

<comment><USER34> What does armchair hammocking mean? I've never heard the phrase before.

<comment><USER33> I'm referring to the very entertaining, but a bit truism-heavy and patronizing presentations of Clojure's Rich Hickey, for example "Hammock driven development": [https://www.youtube.com/watch?v=f84n5oFoZBc](https://www.youtube.com/watch?v=f84n5oFoZBc)

I like Rich Hickey's philosophy and personal style, but Clojure just falls short in every aspect as an implementation thereof, in my opinion.

For example, it switched from heavily promoting STM as a concurrency primitive to "app state in atom" to new async/channels.

<comment><USER35> I don't think you can call clojure.async as something that was made for switching anything, replacing it. Both ways exist and are being promoted for their use cases. I think Clojure is one of the few languages where things have been very stable for a good while. Maybe it's being developed slower than other languages, but using Clojure is nice because of the trust you have of it remaining the same. Everything else is basically libraries on top of the language itself.

</comment></comment></comment></comment><comment><USER36> genuine question: why Kotlin when Scala already exist[s,ed] ?</comment>


Functional Programs Are Imperative Pumpkins - <AUTHOR> https://blog.eventsourcing.com/your-functional-programs-are-imperative-pumpkins-d722ec1358b7 <comment><USER2> What does the word "pumpkins" mean in this context?

<comment><USER3> I think it is an allusion to the story of Cinderella [0], some versions of which have her carriage transforming (back) into a pumpkin at midnight.

I see the implication being that when all is said and done, functional programs are really just imperative programs in disguise (I don't have an opinion on the matter).

[0] [https://en.wikipedia.org/wiki/Cinderella#Cendrillon.2C_by_Pe...](https://en.wikipedia.org/wiki/Cinderella#Cendrillon.2C_by_Perrault)

<comment><USER4> This pumpkin analogy goes away when you consider a a functional database is one where only writes and reads happen (no updates). Indeed this is what functional means: And object is distinct from its state because, in the real world, we do not consider what something is to be the same as what happens to it. Imperative programming locks the two together inseparably. Imperative is where we are merely the accretion of what happens to us. We have no history and no future.

</comment></comment></comment><comment><USER5> Isn't this article just stating the obvious fact that programs at some point do I/O, so no program can be purely functional?

Every Haskell tutorial seems to introduce the IO Monad to illustrate this distinction.

<comment><USER6> I feel that one of the biggest misconceptions about monads and IO in Haskell is that they are an "escape hatch" in the language that allows you to perform imperative actions. This is plainly false. Monads are just another functional programming idiom, defined by two regular functions, `return` and `(>>=)`.

What monads allow you to do is have a _purely functional_ model to represent IO, among a great many other things. Haskell is, in a sense, the best imperative programming language ever created, because it lets you manipulate imperative statements in a purely functional manner. You can stick statements in data structures, compose them, replicate them, generate them and only evaluate them when you want to.

<comment><USER7> I agree. But this is a misconception about functional programming in general, that its purpose is to somehow replace imperative actions that are done by the computer system with something else which is not imperative.

But that's not the goal. Functional programming is there to provide a better formalism for writing programs, it doesn't want to change the way the computers actually execute the programs (or how the systems eventually internally work).

That means more work for the compilers to figure out how to make the same old imperative program out of a functional one, which is a good thing (it's generally the direction the compilers evolve).

Benefits of functional programming are not in how programs are executed (quite to the contrary - it's actually more effort to make them as efficient as good imperative programs), but in how the programs are written by people. I think the article is a little confused about this.

For another example to see this, even notion of non-pure function goes already in this direction. Today, having lots of (small) functions seems to have negligible downsides, but historically this wasn't the case at all, look at any better program that had to fit into memory of an 8-bit computer. These were rarely written in this style, because compilers were simply not capable enough to produce a reasonably compact spaghetti machine code out of those (by means of inlining, for instance).

<comment><USER8> To sum up: harder to write, harder to compile, harder to make efficient. Hum... difficult to qualify it as 'better' after this.

<comment><USER7> I agree with you. Yet, strangely enough, it is better. Maybe we could say, easier to read, easier to modify, easier to reuse?

Let me return to that last example. Take a program written in procedural style, and an identical program written in a big ball of mud style (all variables are global, one big control flow). This is a discussion from like 1960s. It's harder to write for human, and harder for compiler to compile and make efficient program in procedural style.

Yet, I am sure today, you would prefer procedural style. It makes sense (trust me, I actually work with big-ball-of-mud programs written 30+ years ago at work, AMA). I don't care what work the compiler has to do, I care about my own time.

Functional programming is just another step on that road.

As a side note, I really think people who prefer FP should avoid (over)selling it as more computationally efficient approach, because it still isn't (even though it probably will be in the future). It's a little bit of optimistic dishonesty that IMHO hurts adoption of FP and feeds the misconception that I talk about.

</comment></comment></comment></comment></comment><comment><USER9> This isn't directly related, but if this person wants FP + Java ecosystem, why not use Clojure or Scala?

There are functional options for almost all of the big ecosystems now.

<comment><USER10> I mean, there are tons of features in Haskell that one misses when using Scala. The type system isn't as useful, Scala's version of ADTs (case classes) are really inconvenient to work with, different typeclass system, etc. Can't speak for clojure.

<comment><USER9> I know that Clojure has its warts, but it seems to have a better reputation in the functional community than Scala. Scala seems to want to support all paradigms (or many paradigms simultaneously), whereas Clojure was created to be more tuned to FP.

<comment><USER11> The difference between Clojure and Scala is that Clojure is a dynamically typed LISP whereas Scala is statically typed. In the FP community, in general, statically typed languages have a better reputation and are considered to be more tuned to FP. Yes, Scala mixes OOP and FP but OCaml(famous FP language if you've never heard of it) also does exactly that.

<comment><USER12> I wouldn't agree to that. LISPs were the first Functional Languages as FP has its roots in Lambda Calculus. Scala is much more multi-paradigm, and I think its further away from the FP languages. Even Wikipedia agrees: "An interesting case is that of Scala[28] – it is frequently written in a functional style, but the presence of side effects and mutable state place it in a grey area between imperative and functional languages."

A lot of FP practitioners tend to come from academia and most of the research currently lies in provability, so a lot of the FP community seems interested in strongly typed languages, because they overlap the language research communities, but I doubt anyone in the community would claim they are more tuned to FP, because that's just a lie. In fact, a lot of the challenge of typed FP languages is designing a type system powerful enough to express all types of functions, so they're often more restrictive in how they can implement FP.

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

<comment><USER11> Yes, Scala is multi-paradigm and it support OOP as well as imperative programming but the community is very much dedicated to FP. All I see is typed FP that expands my mind.

</comment></comment></comment></comment></comment></comment><comment><USER13> I think the essence of the point was made for me by reading "C is Purely Functional" [http://conal.net/blog/posts/the-c-language-is-purely- functio...](http://conal.net/blog/posts/the-c-language-is-purely-functional)

Functional and imperative are paradigms that can "encode" the other, so to speak.

<comment><USER14> Appel's classic "SSA is functional programming" offers another interesting way to look at this equivalence.

</comment></comment><comment><USER15> I don't get this. Any program that interacts with the outside world isn't "pure", by this definition. What's wrong with using monads? With monads, you can still do all those side-effecting operations, but be encouraged to separate out the pure bits.

</comment><comment><USER16> From the article: The "Land of purity" lies above the "Dirty sea of data" .

Wouldn't "Dirty sea of state" be more appropriate?

<comment><AUTHOR> Perhaps!

</comment></comment><comment><USER17> Why do people, even obviously skilled and well-read people, conflate functional programming with pure programming?

You so not need to have pure code to have functional code. You don't even need to have pure code to use a monadic approach.

<comment><USER18> What do you think "Functional Programming" means? Obviously people and various groups have their own made up definitions, but a commonly agreed upon definition in the PL community might be "Programming with _Functions_ ". Functions, by definition, are pure.

<comment><USER17> > Functions, by definition, are pure.

That's just not true in our domain. While it may be true in some categories, we do not program in an abstract category. In our domain, "pure" functions are distinct enough that we call them "pure" functions and even in Haskell we draw a line between effectful code and pure code. As a core concept in modern programming, the word "function" makes no judgement about how many side effects are there.

I'm not sure why people think otherwise. Or perhaps all Lisp and OCaml programmers are just liars and cheats.

EDIT: I just had a long conversation twitter about this and I'd like to offer an example of a functional style we commonly use even with side effects: tail recursive loops. We often use this modeling technique even in handling I/O because it dramatically simplifies the logic for consuming a stream.

<comment><USER19> >> Functions, by definition, are pure. >That's just not true.

I think there's some naming confusion here. That's because programmers overloaded the original meaning of "function" so that it's equivalent to "procedure". So now when something behaves like an actual mathematical function, we have to explicitly call it "pure".

PS. i remember seeing you in some Yogscast videos, used to be a huge fan of those. funny to meet you like this.

<comment><USER17> It's perhaps confusing because people think the constructs they read about in category theory have 1:1 mappings to the world of programming and they don't. It's why we talk about the category Hask.

Every single concept is overloaded.

P.S., Wow. Someone here who knew about my hobby? I figured it'd never happen.

<comment><USER6> > people think the constructs they read about in category theory have 1:1 > mappings to the world of programming and they don't.

Of course they don't. But they can still be considered a useful model for programming in the same sense that Newtonian physics is a useful model of our world.

<comment><USER17> Of course, but I still think it's important to remind people that functions need not be pure to invoke the benefits of functional programming.

The article in question acts like it is a big surprise gotcha that functional programs have imperative elements. This shouldn't be a surprise to anyone and in fact it's a feature! The accessibility of that feature is often a major component of what languages are judged on.

This isn't a point of semantics, it's definitely the case that we use functional techniques in an imperative paradigm to great success.

<comment><AUTHOR> Thanks for the feedback!

It's not that functional programs have imperative elements or not. That's kind of besides the point.

The point is that putting functional components into workflows that deal with arbitrarily mutable data is reducing the potential we have with the functional model.

The article is simply an open-ended invitation for a discussion on how to do this (and it spark a little bit of that conversation) with some of the proposed options on the same blog.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Why has this been upvoted? The author is a novice and provides no insight. This just reads like he finally got to the second page of your standard book on functional programming and somehow came to believe that everyone else is still on page one. What village is this guy from?

<comment><USER21> > _What village is this guy from?_

I know this thread is about functional programming and so condescension is the norm, but isn't it about time we change that part of our culture a bit?

You offer significantly fewer insights than the OP. Zero arguments, just name calling. The author reads this thread and is a real person. Are you proud?

I, for one, found the article an insightful articulation of things I kinda sorta already knew but hadn't acted on. Also our team is in the middle of building an Elixir backend with a classically designed mutable DB so the article helps me reflect. Maybe now is the better time to change this.

<comment><USER22> I liked Elixir, other than it wasn't statically typed, but I found the ecosystem quite young which means you will have to spend a bunch of time purely keeping your code up to date with libraries as they change and if your tech integration doesn't exist, you are on your own.

After a bit of consideration, I figured F# makes more sense for me. It has a large ecosystem covering many technologies, its all moving to open source / any platform. It also has lightweight processes, and lots of tooling.

<comment><USER21> I agree that there's little point in using Elixir currently if you don't need its concurrency/robustness story.</comment></comment></comment></comment>