Show HN: Gif2sprite – Convert animated GIFs to image sprites and CSS - <AUTHOR> http://gif2sprite.com

<comment><USER2> Whoa, cool!

The gif integration would be what appears to separate this from little libs like Motio[0].

_Question for HN_: is there a reliable cross-browser way to use the sprited background-image approach with _responsive_ elements?

I'm thinking specifically about responsive images, where you want to fill a certain amount of space.

Because of IE's lagging support for various background-... css properties, my impression was that unless you can say goodbye to IE8 it's not an option (maybe not even for non-sprited bgimage, but actually I think there's a DX transform that can stand in for css background 'cover').

But in fact I don't believe I've _ever_ actually seen a demo of a responsive, animated, _sprited_ background-image! I might have just missed it. I've just been preloading images and animating the src property.

\----

[0] [http://darsa.in/motio/](http://darsa.in/motio/)

</comment><comment><USER3> Neat! I like the minimalism. Might not hurt to have an example of the output on there. It would be cool if it was an API that was easy to hit from curl.

Ran into an issue with this gif though: [http://i.imgur.com/5NGvn30.gif](http://i.imgur.com/5NGvn30.gif) \- top of the page says "Warning: chmod(): No such file or directory in /var/www/gif2sprite.com/public_html/index.php on line 36".

<comment><AUTHOR> Thank you and sorry about that. The GIF you were uploading was over the 2mb limit, but error messages as pointed out below weren't showing. I've hopefully fixed the error messages now, so it should be more clear if your GIF is too big.

</comment></comment><comment><USER4> This is really cool shame about the lack of style though, but it seems to work really well. I could see use in this for being able to pause, play and rewind animated gifs. Seems you also reduce the size of the original gif converting it which could offer some benefits, I uploaded a 1.5mb gif and it reduced it to a 700kb sprite. If you supplied a Javascript plugin to be able to use the sprites as gifs in the zip download, it would make this so much better. Good job, nice and original idea.

<comment><AUTHOR> The lack of style was intentional, it took me less than the better part of an hour to build this. I built it because I needed to convert a GIF to a sprite and didn't want to have to use Photoshop. I am planning on a bundled JavaScript library with weekend actually so you'll be able to pause, play and rewind the sprites as if they were videos. I have some code for another project that does this, but it's not in a form of easy to use drop in code. And the reduced file size is because I am compressing the JPG images when the GIF is split, then once the frames are combined, I am compressing further. At first I thought this would result in poor quality sprites and not make a difference, but it seems the double compression works really well.

Thanks for the nice words, I hope someone finds it useful. If people find it of use, I might devote more time to making it a little nicer and more feature- packed besides the JavaScript library I'll be making for it this weekend.

<comment> super-serial A javascript library would be extremely useful.

I was thinking of extracting the gif parsing code from this project: [https://github.com/shachaf/jsgif](https://github.com/shachaf/jsgif)

Then I looked at the code. I've never seen such callback hell in js without there being a server... so I abandoned that idea and was eventually planning on writing my own.

<comment><AUTHOR> It's funny you say that, I've been looking at this: [https://github.com/buzzfeed/libgif-js](https://github.com/buzzfeed/libgif-js) — it's a fork of jsgif, but doesn't require a server though. You call the library on the GIF and it handles the rest.

</comment></comment></comment></comment><comment><USER5> Good job!

I just integrated it with a super simple SpriteSpin ([http://spritespin.ginie.eu/](http://spritespin.ginie.eu/))

[http://jsfiddle.net/madhuvana/PYBDu/1/](http://jsfiddle.net/madhuvana/PYBDu/1/)

<comment><AUTHOR> Ah, nice one. I didn't know about SpriteSpin, really cool library.

</comment></comment><comment><USER6> This is fantastic. I needed an app like this a couple of months ago, shame it wasn't around then. Good job!

</comment><comment><USER7> Hrm, opening the CSS I find ^M chars at the end of every line. Why the windows linebreaks?</comment>


Facebook considering $3-4Bn buyout of Skype - <AUTHOR> http://mashable.com/2011/05/04/facebook-buy-skype/

<comment><USER3> The Skype app on Android is really only barely functional, and what is more, the total lack of support or interest in fixing bugs from their side is almost comical. A couple of months ago I fixed a problem where the sound was coming out of the back speaker rather than the earpiece, a problem that seems to affect many people.

I located the problem and fixed it using baksmali/smali. I then opened a ticket on their public Jira server describing the problem, solution, and even attached the patched .apk. Months later they _still_ haven't merged it into Skype proper, even though it's literally a two-line fix. In the meantime loads of people cannot use Skype on their phones.

The fact that a company that is supposed to be worth 1 trillion USD doesn't have the manpower or interest to fix such a simple bug that totally breaks their product for a lot of people should tell us something. From the outside it looks like all the skilled people have left a long time ago, and I wonder if they'll be able to maintain their market position like this.

<comment><USER4> > The fact that a company that is supposed to be worth 1 _trillion_ USD...

"Billion"

<comment><USER3> Yeah, non-native speaker here, the system works a bit different in my language, hence the confusion. I spotted the mistake but couldn't edit my post.

Luckily you can always count on the internet to point out your typos.

</comment></comment></comment><comment><USER5> I don't see many reasons for Facebook to buy Skype:

1) Technology: Skype's core technology is their P2P technology. They have their own clients for PCs and mobiles. Facebook resides in the cloud, and it works from the browser. This is a huge difference on PCs/Macs, but less so on mobiles, where Facebook also has apps.

2) Price: At $3-4Bn Skype would be by far Facebook's biggest acquisition, as all the others have been under $100M. As they don't have the amount of cash that public companies like AAPL, GOOG or MSFT have (at least not yet), it's quite a big effort for them. There need be a lot of synergies to justify paying this kind of money.

3) Culture: Skype is older than Facebook, and has European roots. Facebook has so far made small acquisitions (more like acqhiring), they don't have any experience with integrating a big company like Skype.

4) Business model: Skype is going for the enterprise market (see the appointment of the new CEO last autumn), and selling subscriptions. Facebook is going for consumers, and selling ads.

Overall, I think a better option for Skype would be an IPO, a telco acquisition, or maybe a Google acquisition.

</comment><comment><USER6> Andreessen was an investor in Qik.

Andreessen did a huge deal to buy Skype.

Andreessen is an investor in Facebook AND on the board.

He sold Qik to Skype for $100M and now he's going to sell Skype to Facebook for billions?

"No conflict, no interest" indeed.

<comment><USER5> I am not sure that Marc Andreessen has so much influence at Facebook. He has one of the 3 board seats that are controlled by Zuckerberg. And Skype would be Facebook's biggest acquisition so far, so it wouldn't be easy for him to convince Zuckerberg to do it.

</comment></comment><comment><USER7> I _really_ hope that there's no forced integration, logging in with Facebook or anything.

<comment><USER8> are you kidding, that will be the first thing they will do

</comment></comment><comment><USER9> Ha ha, remember when Skype pulled this scam with eBay? Good times!

<comment><USER10> Yeah - but this is actually the most brilliant move that Facebook can make - and makes such greater sense than eBay.

You have a service of 500 MILLION accounts that _actually_ talk to eachother.

The play here is so fucking obvious: the facebook Social technology portal page: It is a smartphone on fucking steroids.

You get voice, an extensive contacts list, all the apps on the platform, updates of actions etc...

There is no way why this is a stupid play on facebooks part.

If this goes through - they will have a phenomenally significant advantage to google. Millions of users that now have every tool they need to communicate. The additional services that facebook shall deploy only further lock in that user base: payments, planning, groups, organizations... eventually it will be about fostering and incubating companies and startups via facebook frameworked group app support.

The next step is the facebook phone... all it has is a data connection - <USER2> all your contacts in-system, and the ancillary apps that they can end up providing through the platform in 5 years will take on apple.

</comment></comment><comment><USER11> Perhaps what Facebook want is all of Skype's customers' credit card numbers. Linking them with Facebook accounts may help boost all of their future 30-percent-comission endeavors.

</comment><comment><USER12> In the event of this actually happening, what are some alternatives to Skype's video chat?

<comment><USER13> Person-to-person video chat is a commodity. If there's a problem it is that there are too _many_ solutions.

<comment><USER14> Yep. It seems Skype just won on brand name.

<comment><USER15> They won on NAT traversal, ease of installation and lack of obnoxious ads.

I've learned about Skype _from my aunt_ who managed to install it and get it working without phoning me.

</comment></comment></comment></comment><comment><USER16> Upcoming mashable/techcrunch/other-tech-gossip-site headlines to be linked at HN:

        * Why Facebook will buy Skype
        * This is not a bubble
        * Facebook buying Skype is the dumbest thing ever
        * Skype's two hundred competitors that Google will buy
        * That settles it, we're in a bubble
        * Why Google/Microsoft/Yahoo/Apple should buy Skype
        * How I flipped my VOIP company for $4 billion in funny-money

<comment><USER17> You're doing their work for them!

<comment><USER16> They've merely rightsized their organisation to wikify their newsroom with crowd-sourced insight. It's totally thinking outside the paradigm, a true hack on pivoting.

</comment></comment></comment><comment><USER18> At first I wasn't sure how Skype played into FB's strategy but I guess it makes sense. Skype would come with a plethora of talent, which facebook is known to spend money for. Also, the Skype technology would allow FB to fill out the video communication side of things that they have yet to tap.

<comment><USER19> Do you have any names in mind for this "talent" that Skype currently posess? I'm not familiar with the company's staff at all but from how the OSX client 5.0 release was such a failure & how bad the android client is I'm inclined to think there isn't much left at all.

</comment></comment><comment><USER20> Does Facebook have $3-4B in cash? I didn't think they had that much money. And even if they do, they wouldn't have much left after the deal to move other big plans forward. I guess if they go public first, then it could happen.

<comment><USER5> Facebook may make $2B in profits this year. So I think they could come up with this cash. Also, they can give some of this amount in stock.

<comment><USER14> In profit? Source? (Not saying you're wrong - I just didn't know and would like to read about it)

<comment><USER5> Here it is: [http://www.bloomberg.com/news/2011-05-03/facebook-is-said- to...](http://www.bloomberg.com/news/2011-05-03/facebook-is-said-to- expect-2-billion-in-2011-adjusted-earnings.html)

To be more precise, it's $2B in EBITDA, not net profit.

</comment></comment></comment></comment><comment><USER21> it's not overly surprising considering the recent Facebook<-> Skype integration and Skype's expansion to the USA (new office in Brisbane, CA).

I'd say it's more like likely a 'strategic partnership' than a buy-out. Having said that though, they're both private companies, so it may not as straight forward as a normal 'merger'

<comment><USER22> Its makes more sense for Facebook to buy Skype instead of Google. Here are some of my points.( snippets from my article).

•Enhance their messaging platform with support for Voice and Video powered by Skype. Off course Facebook can develop its own Voice and Video infrastructure. Too me it's a stretch. Instead by buying Skype they get instant access to VoIP/SMS/Video features •Support Voice/Video will boost the messaging platform, which doesn't seem to have gained much traction •With Skype Acquisition they also get QIK Live streaming capabilities. That's an added plus •Instant Access to more than 500 million users. The chances of Skype users having Facebook account are high. There might be an overlap •Facebook can really become a global operator providing Voice/SMS/Video/IM communication to all its users. Off course PSTN access will still be short coming, a partnership with one of the operator can offset this shortcoming •A Facebook phone becomes a reality. Most of the operators are moving towards 4G/LTE, it's a matter of time that all Voice calls will be carried via IP network. With a partnership with one of the access network, Facebook's ambitious phone becomes a reality. So constant monthly revenue for basic phone service becomes a reality. Voila! •Patronize Innovation by opening up the Skype platform for developers (Telco 2.0 Platform). Something similar to Twilio, Voxeo etc •Who said Facebook is only for Consumer market, with Skype acquisition they can venture into Enterprise market and become a threat to some of the incumbent Video/VoIP provider like Avaya, Cisco etc •According to CDC Straw Poll 75% of the companies will adopt, Video Conferencing by 2012. Skype already supports consumer video conferencing which can be extended /enhanced for enterprise •Voice conferencing is another big Enterprise feature. So armed with these powerful features, facebook can look beyond consumer market •It makes sense to have different revenue stream instead of relying only on advertisements •Everybody wants a piece of Facebooks social graph including operators. T-Mobiles recently launched Bobsled , a one touch calling within facebook. In fact Facebook can do a better job than Third Party service providers.

</comment></comment><comment><USER23> I'm curious what the sources would have to gain by leaking this information? In the Reuters article it says they had "direct knowledge of the discussions", why would they risk their jobs to leak something like this? I don't get it.

</comment><comment><USER24> beedogs considering no longer using Skype.

<comment><USER12> if FB buys skype I'm out

<comment><USER25> fear of centralized access to personal information? is there a _secure_ easy voip solution ?

<comment><USER12> not so much fear...more of a well placed reluctance to trust a company which has no regard for privacy

</comment></comment></comment></comment><comment><USER26> the first thing i thought of was video chat integration into facebook chat exactly the same way google video chat is integrated into gchat. from there, they could monetize on paid group chats, calls to numbers since fb's new messaging is tied to mobile, etc.

</comment><comment><USER27> Perhaps they will improve the new Skype client.

</comment><comment><USER28> skype is only a good option if they want users. because the only appeal of skype is the userbase. really.

if facebook has the penetration everyone believes they have, skype would be irrelevant. buy any other media streaming company with an actual decent codec and the rest is commodity.

<comment><USER29> Assuming you are right about the tech (I have no idea), it's not necessarily a simple 'user acquisition.' I have a facebook account that I rarely use and a skype account that's always on.

If logged in to skype meant logged in to facebook I would become a very active facebook user.

I can't gauge the value of that to facebook because it's still not entirely clear how they make money (at least not the kind of money investors are aiming for), but it's possible skype is very valuable. Who I call, how long, what hours, these all tell facebook a lot about me. Possibly more than my facebook account does.

Different people use facebook for different things. Photo sharing, address book, networking, chat, email (sort of), social news, games. Skype can add another big bullet point to that list.

Again, it's hard to say good or bad for facebook's bottom line at this point. If you are going by their current revenue model, you would have to relate everything to demographically segmented pageviews but these kind of numbers assume bigger value than that.

<comment><USER28> that was mostly my point too.

I was mostly questioning how much users (or actual real users that actually uses the site) there are in reality. not in the make believe news lives in.

</comment></comment></comment><comment><USER30> What? Skype is worth so little?

</comment><comment><USER31> I don't fancy Facebook buying Skype.

<comment><USER32> Why?

<comment><USER33> i don't have any positive sentiment towards facebook. i use skype a lot and would resent suddenly being forced to use facebook.

</comment></comment></comment><comment><USER8> I know this is off the topic.any body knows a skype like program that runs on lan only thanks

<comment><USER34> iChat/w Bonjour

</comment></comment><comment><USER35> "It's the end of the world as we know it." However, I don't feel fine.

<http://www.youtube.com/watch?v=Z0GFRcFm-aY></comment>


My notes/pics on looking over the Cr-48 (and the discovery of a hidden switch) - <AUTHOR> http://simonsarris.com/blog/268-looking-over-cr-48

<comment><USER2> "Developer Mode"

[http://www.google.com/support/chromeos/bin/answer.py?answer=...](http://www.google.com/support/chromeos/bin/answer.py?answer=1086551)</comment>


My manager says your buttons are too small (2012) - <AUTHOR> http://code.google.com/p/zaproxy/issues/detail?id=351

<comment><USER2> Manager: "What have you been doing all afternoon?"

Underling: "Oh well I was in communication with the software company trying to resolve the button issue you raised this morning. Good news though they're adding it to the next release."

Manager: "Good job, way to take the initiative. Now let's talk about this TPS report problem."

</comment><comment><USER3> Interesting that I have almost the opposite experience.

My previous manager thought bigger buttons made the system look like it was 'designed for idiots', so smaller buttons made users feel clever and advanced.</comment>


Functional Programming Isn't the Answer (2014) - <AUTHOR> http://degoes.net/articles/fp-is-not-the-answer <comment><USER2> Sorry for trolling, but sometimes I just have to.

"Look at my intentionally non-thread-safe, spaghetti _imperative_ implementation. It sucks! So FP sucks."

<comment><USER3> You're missing the point.

The author used that example to demonstrate that just using FP languages is not enough to ensure good code, because it is possible to write bad code in FP languages.

Therefore, FP programming languages are not going to guarantee you good code by themselves. They will only get you good code if you use them to write good code. By the way, the author never said "FP sucks," and that's a very uncharitable and unreasonable interpretation of the argument.

From the article:

> My view is that although FP makes it easier to write good code, just because > something's functional, or even "purely functional", doesn't necessarily > mean it's any good. Stated differently, as software engineers trying to > improve our craft, we shouldn't latch onto or defend something just because > it's "functional" or "purely functional". Although it's possible to write > good code using techniques from functional programming, it's also possible > to write bad code. FP doesn't protect us. We need a different measure for > "good code" than just "functional".

You may think that "FP guarantees good code" is a strawman argument, but it isn't. A quick search of this site will turn up people who make that very argument. It's useful to have a realistic corrective to the pseudo-religious fervor of some FP proponents, and this article provides that.

<comment><USER4> But isn't that arguing against a strawman? Nobody is arguing that FP code is automatically good by virtue of being written in an FP-oriented language.

For example, you can write a beautiful algorithm that solves the _wrong_ problem. No language will help you with that.

Or you can write a program in language X that ignores every convention or practice -- you can write code that makes an extraordinary effort at subverting the type system, for example -- but that's more of an argument against your understanding of X.

I do agree with the author that FP, good as it is, is not _enough_. That's not an argument against FP, it's an argument in favor of devising even better tools, practices and the theoretical underpinnings for building correct software.

<comment><USER3> > Nobody is arguing that FP code is automatically good by virtue of being > written in an FP-oriented language.

People do say that, so it's not a strawman.

> I do agree with the author that FP, good as it is, is not enough. That's not > an argument against FP, it's an argument in favor of devising even better > tools, practices and the theoretical underpinnings for building correct > software.

The article was not an argument against FP. Why do you think it is? It is simply an argument against a certain justification for using FP, namely that it guarantees good code.

<comment><USER4> > _People do say that, so it 's not a strawman._

Who says this? No-one who is a serious practitioner of FP (as opposed to someone who just reads about it in blogs) will tell you that FP automatically guarantees good code. You'll hear that FP goes a long way at reducing some common sources of errors, which is a pretty big deal, but automatically correct code? No-one will claim that.

> _The article was not an argument against FP._

I didn't say the article was. Besides the clickbait title, and some dubious assertions (and a poor example with QuickSort), I do agree with the overall assertion that "FP is good, but not enough".

<comment><USER3> > Who says this? No-one who is a serious practitioner of FP (as opposed to > someone who just reads about it in blogs) will tell you that FP > automatically guarantees good code.

No true scotsman fallacy.

<comment><USER4> The problem with the No True Scotsman fallacy is that it's impossible to apply to the internet, where there is always someone out there who will claim _anything_ about _anything_.

Therefore, in order to have a rational discussion about this, we must apply some sort of filter.

I propose this filter: no-one who is an actual practitioner of FP (someone who uses it to build software, not someone who just talks about it in the internet) will not make the claim you mentioned, i.e. "FP guarantees good code" (I'm quoting you verbatim).

I hope it stands to reason that it doesn't matter what people who've never used FP claim about FP.

<comment><USER3> It's still a fallacy. Being on the internet doesn't change that.

> I hope it stands to reason that it doesn't matter what people who've never > used FP claim about FP.

That doesn't matter. An argument is not a strawman if it has been made by anyone, anywhere, anytime, for any reason. You can't just filter out the people you think don't count.

An argument is only a strawman if it is a false argument, e.g. one that has been invented by the person who is arguing against it.

If you want to have a discussion about the merits of FP, feel free to filter out whoever you like. But you said the argument mentioned in the article is a strawman, and it isn't.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Title is a bit bait-y. A better title might be, "Functional Programming isn't enough". tl;dr He says that FP is good, but you can still write bad functional code (which is fairly obvious).

<comment><USER6> And you can write good non-functional code as well.

</comment></comment><comment><USER7> I love how the author gives comprehension and composability as goals for code over adherence to any dogma.

One interesting note is that the quicksort code in Haskel illustrates a very important point about code evolution. Suppose you wanted to avoid the worst case quadratic behavior. There is not a good evolution strategy that goes through median of 3 pivot, median of 3 pivot with randomization, and introsort. With the equivalent imperative code, the evolution strategy is pretty easy by just adding a few if statements.

<comment><USER5> Comprehension and composability _are_ dogmatic.

There are people who criticize code that isn't concise enough, even if being concise would make it harder to comprehend. Using lots of magic or overly- terse languages are also valued by some people and not by others.

Composability is also something that is totally alien to large sections of the OOP community. If you've ever dealt with a legacy PHP or Java framework, you'll know what I mean. They heavily use inheritance over composability.

</comment></comment><comment><USER8> tl;dr - You can write bad, hard to understand code in any paradigm (or language).

That said, I tend to prefer functional patterns over OO... there are times where OO/classes as a syntax expression is easier, I would say in most cases, it isn't. It really depends on what you're trying to create, where and how.

</comment><comment><USER9> While i could criticise some points and recognise others, i want to add the following:

Function Programming is fun (mostly ;))

and i think even in corporate setting that is a valid argument. It may not the the most important, but it is one nonetheless. Happy developers are more productive in my experience.

</comment><comment><USER10> I also find it strongly problematic that functional languages with customizable infix operators (e.g. Haskell and OCaml) have lines of code like this:

      whileM ((<=) <$> readLeftIdx <*> readRightIdx) $ do

And, from what I've seen in a few Haskell codebases, this isn't all that uncommon. I refuse to believe that there's not a better way to express these kinds of programming patterns. I recognize that applicatives, functors, etc. have their value in creating well-engineered interfaces, but when they manifest themselves in obscure operators, it feels self-defeating.

<comment><USER6> Do you really think it would be clearer to write

        cond = do
          li <- readLeftIdx
          ri <- readRightIdx
          return (li <= ri)

        -- ...
        whileM cond $ do ...

Personally, I don't think it adds much clarity. It just makes the code more verbose.

<comment><USER11> As someone who doesn't know Haskell, I can understand your version. I had no idea what the other one does.

Maybe that's not a reason to avoid the more concise syntax, but a language that is more comprehensible and intuitive to people unfamiliar with it is more likely to capture mind-share.

<comment><USER6> Both versions are equivalent. The reason why you didn't understand the original version is that, as you say, you don't know Haskell. But, if you learnt Haskell, the original version would've been just as easily comprehensible.

<comment><USER11> I get that and agree with you. My point is that it's easier to evangelize for a language that is intuitive and comprehensible with only limited exposure to the language. Languages like go are a good example of this. If you've ever done any programming, you can read go code and know what it does. even if you've never written a single line of go code in your life. I'd say Elixir, a functional programming language, is also good in this regard.

<comment><USER12> Interesting. I wonder to what degree that influences language popularity.

I suggest the following plausible points:

1\. Nobody is born knowing a programming language. Languages have users to the degree that they convert non-users into users.

2\. Sometimes people are forced to use a language for a job (which is, I suspect, somewhat common, but less common than hiring someone who already knows the desired language). Others are forced to learn it to pass a course. Other than those cases, though, languages convert non-users into users in proportion to how much a non-user gets rewarded for the first attempts to write code in that language. This was one of the virtues of BASIC, for example. I picked up BASIC from the TRS-80 manual in an hour, and was writing code that afternoon. I got immediate feedback (we didn't call it a REPL on BASIC, but it had one). You could just _read_ BASIC code.

But if I have to learn a mathematical notation, or a 1000-page book, in order to be able to do anything that I want to do, I have to _want_ to learn that language more before I'm going to _bother_ to learn that language.

Other than university people, Haskell seems to attract people who have been around the block enough times to know why they might _want_ to learn FP, and therefore who care enough to make the effort.

</comment></comment></comment></comment></comment></comment><comment><USER13> Question: I totally agree that the second version is much cleaner. But, how does the performance of the two compare in Haskell?

"Premature optimization is the root of all evil" and all that. But, a sorting routine is something everyone would expect to be as efficient as possible, right? (Maybe it was just for the sake of the example?)

I heard 1 or 2 things about Haskell being lazy, etc. Does it makes the second version less inefficient than it looks?

</comment><comment><USER14> I think it's a bit of a mismatch when people talk about maintainability and comprehensibility, but only on very local levels, and the examples they bring up are also very local.

System maintainability and comprehensibility owe more to architecture than to local readability. It doesn't matter if local code is completely functional, or if Scala secretly uses imperative algorithms underneath. What matters is if the code module / division / unit is keeping its contract or API with respect to the rest of the system, because if it is, then you can actually hope to comprehend your system at a useful level of abstraction. Local vs system comprehensibility are not in tension, but an unfair amount of focus has been placed on local clarity.

So a question I'd have is what architectural solutions to some problem domain are natural and special to the functional style. To that end, it's more interesting to see a skeleton project tackling a generic problem, as an inspiration for a generic architecture, than to talk about whether it's possible to write locally bad code with an FP language.

</comment><comment><USER15> > well, filter should really be replaced by partition, because filter destroys > information; use of filter requires manual negation of the boolean predicate > < p, which represents duplicated information content

More seriously, `>=` is not the correct negation of `<` due to NaNs. The code as written will return a list with all NaNs removed, because NaNs are neither greater than nor less than any other number.

It's interesting that an in-place sort that uses only comparisons and swaps cannot have bugs like duplicated or removed elements, regardless of any bugs in the algorithm or comparison predicate. The "shuffle via sort by random" approach [1] is a nicely insane test case.

[1] [http://javascript.about.com/library/blsort2.htm](http://javascript.about.com/library/blsort2.htm)

<comment><USER16> You only have to deal with NaNs if they are valid values of the type the array is made out of. In Haskell an 'Int' can not be NaN. Only types of the 'RealFloat' class can be NaN.

</comment></comment><comment><USER17> I agree with the author that blind religious devotion to a paradigm in not healthy. I see FP and imperative as complimentary and we also see that manifesting by FP idioms being baked into traditionally imperative languages.

Use the tool where it shines. Here is a doc that I have bookmarked for Haskell: [https://github.com/Gabriel439/post- rfc/blob/master/sotu.md](https://github.com/Gabriel439/post- rfc/blob/master/sotu.md)

</comment><comment><USER18> I don't understand this post. "With that said, brace yourself, and take a look at my contrived, deliberately-obtuse strawman implementation of Quick Sort:"

<comment><USER19>
        > I don't understand this post.

The point is, as the author states quite clearly, that it's not enough to say "I wrote it in FP".

<comment><USER20> Which is of course a straw man. Find me a credible FP proponent that would disagree with that point?

Yes, bad code is possible in any language or paradigm. We don't judge languages by their worst examples. We never have expected FP to magically solve all problems. Heck, this disclaimer exists in a slightly different form even in the Backus paper!

I don't understand the point of this article either.

<comment><USER3> > Find me a credible FP proponent that would disagree with that point?

What distinguishes a credible FP proponent from a non-credible one? This is getting close to the territory of the no true scotsman fallacy.

If someone makes the argument, it's not a strawman. It doesn't matter if you consider them credible or not. The author of the article responded to a real argument made by real people.

<comment><USER20> Who? Who has made this argument? What actually is the argument? FP literature is full of this admonition. FP papers constantly cite the primary benefits of FP and it's not the functionality.

Who specifically is he arguing against? You cite "no true Scotsman" but we lack even a false one to point to.

<comment><USER3> You wrote:

> Find me a _credible_ FP proponent that would disagree with that point?

By including the word "credible," you are pre-emptively excluding some FP proponents as not being "true" FP proponents. So you've already committed yourself to applying the fallacy to evidence that anyone might present to you.

<comment><USER20> Let me actually commit a logical fallacy before I have to own up to one. Don't worry, I'm sure it won't take very long.

But this pre-emptive strike thing is just a way to avoid providing any sort of example, I suspect.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I read the title and I think, "OK, FP's not the answer ... what's the problem it's not the answer to?"

I think the problem is dysfunctional workplaces in general -- things like open plan office dogma, "full stack" destroying the value held in specialization of labor and compartmentalization, everyone trying to data mine "insights" that are really serving political agendas instead of customers, users, clients, or really even shareholders, and so on.

Writing good software systems inside a bureaucratic system constantly throwing wrenches into the gears is _really_ hard, and just changing the language paradigm, even if the paradigm comes with really great tools for correctness and quality enforcement, generally isn't enough to overcome badly structured, uncreative, un-turn-off-ably oversaturated with "collaboration" working environments.

I love FP and hope I get to use it more in the future. I also love simpler OO or even module-oriented programming with lots of mutation. You can write great software in any of these paradigms, and you can have great teams.

But I think first we all have to unite and utterly refuse the horrible working conditions pervading the industry. Put our debates about language or tool superiority to the side and see if we can improve functionality and basic humanity-affirming healthiness of workplaces and team structures.

</comment><comment><USER22> Despite the (somewhat heated) discussion below, this article is actually quite pointless.

Having good tools does not make you a good craftsman, I'm not sure this is contentious.

I don't think that anyone would argue that (good tools => good craftsman) is valid. This isn't an argument against FP, just the statement that FP cannot transmute a bad programmer into a good one.

</comment><comment><USER6> "Strong types" (a term that hardly means anything, now that everyone and their dog claims their favorite language is "strongly typed") don't have anything to do with functional programming. And the fact that algebraic data types were originally used in functional languages is just a historical accident.

<comment><USER23> Strongly typed was never really a useful description of any language. Eric Lippert nicely points out [1] that descriptions like statically typed, type safe and memory safe are a lot more useful when one wants to compare programming languages than those fuzzy terms strongly and weakly typed.

[1] [https://ericlippert.com/2012/10/15/is-c-a-strongly-typed- or-...](https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly- typed-language/)

<comment><USER6> A more useful term is "sound": does the type system protect the language's basic abstractions?

(0) Standard ML: Yes.

(1) Java: No, but dynamic checks are used to patch the type soundness holes.

(2) C: No, and if you do anything wrong, may God help you.

<comment><USER23> If you don't use casts, then you should come pretty close to soundness, at least in Java. Array covariance is really the only exception I can ad hoc think of. I am not really sure of C without casts.

<comment><USER24> What about null?

<comment><USER23> You could say all Java reference types are sum types - either a real instance of that type or a null reference. A function returning a string guarantees that you either get a string or a null reference, I don't think that has (necessarily) implications for soundness. But then again the theory of type systems is not something I have a deep understanding of so I may actually be wrong.

<comment><USER6> > You could say all Java reference types are sum types - either a real > instance of that type or a null reference.

That's not true. There are two fundamental differences:

(0) Options can nest. Nullability doesn't nest.

(1) Options are manipulated by pattern matching (or direct application of their induction principle, that is, Haskell's `maybe` function). In Java, you just assume a nullable variable isn't null, and if it is, well, you get an exception.

<comment><USER23> That is certainly a limitation but I don't think that makes this view wrong. I also can not have List<int> but that does not mean List<T> is not a generic list type just because there are some constraints on what T can be.

<comment><USER6> In the vast majority of situations, when a Java programmer has a value of type `Foo`, he or she expects it to be a non-`null` reference. Having a `null` one is a possibility, but it's an error. Dictating that reference types are in actuality option types is creating a gigantic mismatch between the prescriptive semantics of the language and the actual model inside the heads of programmers, which is the worst sin a language's semantics can commit. Witness the flame wars about whether it would be a good idea to remove some undefined behavior from C.

<comment><USER23> That is certainly true, but the point was whether nullabilty has any bearing on soundness. I just tried to argue that the fact that a reference may be a null reference does not (necessarily) defy soundness - the compiler guarantees that you get an instance or a null reference and that is exactly what happens at runtime.

<comment><USER6> If you take the view that object references are options, then it's plain unsound to manipulate object references as though they weren't options! `NullPointerException` is just a dynamic plug on a static type safety hole.

This blog post (I'm not the author) explains the issue (item 3) very well: [http://www.sebastiansylvan.com/post/language-design-deal- bre...](http://www.sebastiansylvan.com/post/language-design-deal-breakers/)

<comment><USER23> Maybe I (or you or both of us) have a wrong understanding of soundness. I understand it as follows - the specification of a programming language (or its implementation) is sound if the guarantees made a compile time hold at runtime for all inputs. The guarantee for calling a method on a reference in Java is that you either invoke that method or a NullPointerException gets thrown in case the reference is a null reference.

After thinking about it again, unless you made an error in the specification or implementation, every programming language should actually be sound. You can always weaken your guarantees until they (trivially) hold at runtime. But that actually worries me a bit, soundness suddenly seems not such a useful concept. Maybe because I am wrong with my understanding?

Note that this also possibly contradicts what I wrote previously, I may not have thought carefully enough about some of the things.

<comment><USER6> > Maybe I (or you or both of us) have a wrong understanding of soundness.

I'm using my own interpretation of "soundness = progress + preservation", originally due to Wright and Felleisen. "Progress" means "not getting stuck" (a term is either in normal form or further reduces). "Preservation" means that, if a term `t` has type `T` and reduces to a term `u`, then `u` also has type `T`.

From a purely technical point of view, raising a NPE is a well-defined execution step, different from getting stuck. But I contend that this is just a technicality, and not really how a programmer thinks about his code. For practical purposes, in most situations, throwing a NPE is reaching a stuck state, and thus a violation of type safety.

<comment><USER23> Which then brings us all the way back to the first comments - without agreed and accepted definitions statements about programming languages may be way more up for interpretation then one hopes.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> That rouge FP implementation would get negative credits in a good FP class. At least, that's what our TA used to do.

</comment><comment><USER26> To make your case, please don't set up one side as a "religion".

</comment><comment><USER27> It's simple and effective. It's not design to answer everything.</comment>


pigz: A parallel implementation of gzip - <AUTHOR> http://zlib.net/pigz/ <comment><USER2> Funny - my first thought on seeing the name 'pigz' was the parallel decompression algorithm put 'gzip' in the wrong order!</comment>


Time Is the Ultimate Success, Not Money - <AUTHOR> https://www.entrepreneur.com/article/305389 <comment><USER2> I've found that having control of schedule is one of the top things in life.

</comment><comment><USER3> A son of David wrote:

A man may have a hundred children and live many years; yet no matter how long he lives, if he cannot enjoy his prosperity and does not receive proper burial, I say that a stillborn child is better off than he.

<comment><USER4> I have to say I disagree with the son of David.

If a man has a hundred children and lives many years but cannot enjoy his prosperity, a licensed therapist and possibly medication to deal with depression would be much preferable to being stillborn.

<comment><USER3> Joy cannot be prescribed

<comment><USER4> If the lack of joy is caused by a chemical imbalance in the brain it absolutely can be prescribed.

Cliche nonsense or outdated Biblical advice actively hurts people in this case.

<comment><USER5> Chemical imbalance theory still disproven

<comment><USER4> Definition of a theory is rational explanation that is unproven.

</comment></comment></comment></comment></comment></comment><comment><USER6> Hey I appreciate the share! Really cool of you :)</comment>


Robot makers push growth agenda - <AUTHOR> http://www.thomasnet.com/journals/machining/from-promat-2013-the-robotics-impact-on-economic-growth-with-dr-henrik-christensen/

<comment><USER2> >>> Christensen broke down the costs of adopting robotics for a typical SME:

        Basic robot system: 20 to 30 percent of cost
        Auxiliary hardware (cabling, wires, etc): 20 to 30 percent
        Software: 40 to 60 percent of cost

Even though a low-end robot may be about the price of a new car, they wont make it into your typical small machine shop until the "programming" component disappears.</comment>


How digital technology is destroying your mind - <AUTHOR> http://www.washingtonpost.com/opinions/healine-here/2015/02/13/a78172e0-855e-11e4-9534-f79a23c40e6c_story.html

<comment><USER2> The article is just a review for a book.

I've never read the book mentioned but if this is a topic you're interested in I'd highly recommend, 'The Shallows' by Nicholas Carr.</comment>


Show HN: Skypad – Simple and Sharable Real-Time Collaborative Notepad - <AUTHOR> https://github.com/skygear-demo/skypad <comment><USER3> Looks really good already. Think there actually is potential to target people for who Google Docs is too overloaded. Like the idea of supporting markdown.

It might also be really useful to support syntax highlighting as I see one use-case for really quick and uncomplicated pair programming.

<comment><AUTHOR> A quick update - Skypad now supports code highlighting! See it live here: [https://skygear- demo.github.io/skypad/#a4bdd786-a950-4be2-88...](https://skygear- demo.github.io/skypad/#a4bdd786-a950-4be2-8845-b28c87e05956)

</comment></comment><comment><USER4> Hey this looks great! Does Skygear handle the synchronization logic?

I built my own notepad a while ago too using ShareJS as the syncing library. ([http://www.madpad.me/](http://www.madpad.me/)) [https://github.com/sifxtreme/madpad](https://github.com/sifxtreme/madpad)

<comment><AUTHOR> It handles both the saving logic and the pubsub logic. You can view the source in app.js . It took me around 2 hours for this quick project.

</comment></comment><comment><USER5> Nice tool. I like the simplicity in code and interface.

We did implement real-time collaborative editing for Teamemo ([https://teamemo.com](https://teamemo.com)) and the real challenge was to support rich text editing.

Are there plans to support rich text?

<comment><AUTHOR> Nice one! It's a hack project for now - but I actually prefer Markdown support and collaborator indicator next.

</comment></comment><comment><USER6> It looks like a clone of etherpad to demonstrate skygear. Is that about it, or am I missing something cool (except for the very nice visual design)?

<comment><AUTHOR> Thanks for the liking the visual. This is a quick hack in an hour to demonstrate how [http://skygear.io](http://skygear.io) 's real-time sync and cloud database feature. Yet I am thinking to add more feature to it - <USER2> support and collaborator marks. Do you have any ideas on that?

</comment></comment><comment><USER7> Doesn't work for me on Firefox (latest)

<comment><USER8> same for me, the edit window is very small actualy

<comment><AUTHOR> Just fixed, appreciate if you'd try again ;)

</comment></comment></comment><comment><USER9> Very nice. [https://github.com/hackpad/hackpad](https://github.com/hackpad/hackpad) is decent as well.

<comment><USER10> There is also [https://github.com/ether/etherpad- lite](https://github.com/ether/etherpad-lite)

<comment><USER11> I wish GitHub used something like that to edit its wikis. Telling me somebody else saved a new version of the doc I'm working on is so uncool.

<comment><USER9> Pro tip: git clone the wiki and work on it locally. Easier to merge as well

<comment><USER11> I know, but it's hard to resist editing the document in the web page while talking about it with a remote coworker. No commit, no push, only save. Then I discover he made another edit to the page :-(

I liked much more the workflow when a customer decided to use Google Docs for the technical documentation. We were editing and checking documents live with multiple cursors in the same screen.</comment></comment></comment></comment></comment>


The Startup Toolkit - for founders in search of a business model - <AUTHOR> http://thestartuptoolkit.com/ <comment><USER2> I don't get it. Why would I need a "complex" tool like this, when I can simply note down the most important questions on a piece of paper or in a simple text file? Yeah, I can collaborate with people remotely, but a simple skratchpad does the same job. For me, it feels like another way of procrastinating instead of simply getting the job done, as I have to deal with an interface (even if it is relatively simple) instead of just letting my ideas flow.

<comment><USER3> I think it helps you focus and work through a business idea in a structured way. Have experienced it that I just fell in love with an idea. It helps you think about it in a more rational way. If you end up doing the process with this tool or with a sheet of paper doesn't matter. But I like it as it "forces" you to think of it from different angels.

<comment><USER4> I never understood why the boxes are shaped the way they are. Is the area proportional to importance? Why is market on the left and not the right? Why not just do a boring row of boxes?

Or is it just arranged in a way the visual cortex finds interesting? That would add weight to the idea that this is just a meme.

<comment><USER5> It looks more scientific that way

</comment></comment></comment></comment><comment><USER6> Put the crown jewels in the cloud? No thanks.

Maybe these forms can be turned into downloadable templates (with TheStartupToolkit branding) and you can continue to fill the toolbox with other useful tools?

</comment><comment><USER7> It scares me that we have founders in search of business models, not business models seeking founders.

</comment><comment><USER8> I wish I could see what it was before signing up.

<comment><USER5> Right, the registration thrown in your face has got to be a conversion killer. I know I left instantly.

<comment><USER9> It previously used randomized urls with no registration required and the #1 request by a huge margin was that people wanted to feel more secure before beginning to type in their biz model and that registering would achieve that.

We live in a world of trade-offs.

<comment><USER5> No tradeoff needed. Let me try it with fake data without registering. Which is exactly what I planned to do. Until faced with the registration page, whereupon I fled like the morning dew.

</comment></comment></comment></comment><comment><USER10> It's a great domain name.</comment>


Writing Complex Macros in Rust: Reverse Polish Notation - <AUTHOR> https://blog.cloudflare.com/writing-complex-macros-in-rust-reverse-polish-notation/ <comment><USER2> So it looks like people repeat how C++ templates are bad, and Rust macros are good. Can someone tell me what's the real difference? I'm not sure I get it, but I feel like both are good or both are bad.

<comment><USER3> C++ templates are bad because they are untyped generics (e.g. C++ doesn't check that the key type for an hashmap is hashable, and instead you get a bunch of errors that there is no "hash" overload accepting certain arguments when you try to call a method on the hashmap).

C++ tried to add a type system for templates with "concepts" but it was scrapped.

Rust instead has properly typed generics instead using the trait system, resulting in proper static checking and proper error messages (although without higher kinded types and const generics currently, that C++ instead supports).

Rust also has a powerful macro system, which is unrelated to templates, although you can use them to have kinds of abstractions that the language doesn't support directly (like higher kinded types, const generic or abstracting over mutability), at the cost of having to explicitly perform instantiation, not having inference and having a higher cognitive burder.

<comment><USER4> Concepts are on track for C++20 and they are already available on gcc to play with.

Besides that, it is already possible to use typed templates in C++, at least with any C++14 compiler and even better on C++17, even if it requires a bit more of effort for the implementer of the generic code.

Basically by making use of type traits, static asserts, constexpr if and enable_if.

Yes, it isn't as clean as Rust but as shown by Andrei Alexandrescu with D, it opens the door for very powerful designs.

<comment><USER5> But the C++20 concepts is only concept lite. It does not check the implementation of the template function that it only uses operations available for the conceps.

suppose you have a concept Hashable that is only enabled for type with a hash() function. But you can still in the code of your HashMap do a comparison with the < operator, which the Hashable concept don't ensure. In that case you woud only have an error at instentiation type for Hashable types that don't have '<'

In Rust, the compiler make sure that your generic function only use operations that exits in the traits declared in the function signature.

</comment></comment></comment></comment><comment><USER6> I didn't actually try out the code, so I don't know whether it actually works regardless, but this looks _really_ suspicious:

        = note: expanding `rpn! { @ op [ 4 , 3 + 7 , 2 ] * }`
        = note: to `rpn ! ( [ 3 + 7 * 4 , 2 ] )`

Is that not, like, operator precedence gone really wrong? Or is this the rust stringifier in trace_macros messing up without anything going wrong in the actual AST?

<comment><USER7> The trace_macros! stringifier isn't inserting parens when required: due to the use of 'expr' the macro is treating 3 + 7 as a single node _X_ , and then the multiplication with 4 is, in the AST, _X_ * 4 (i.e. correct). The thing that is being printed there is the recursive rpn invocation in the @op branch, and specifically the '$a $op $b', which is a "disconnected" sequence of AST items/token trees. Once it's forced to be parsed as an expression (that is, when matched against the recursive '$... : expr' rules), the printer handles it correctly. For instance, the last 'to' line of the output in the example you quote, or, if that example is changed to 'rpn!(2 3 7 + 4 * 5)', the trace_macros output includes:

       ...
       = note: to `rpn ! ( [ 5 , (3 + 7) * 4 , 2 ] )`
       = note: expanding `rpn! { [ 5 , (3 + 7) * 4 , 2 ] }`
       ...

</comment></comment><comment><USER8> Rust macros strike me as closely related to Scheme hygienic macros; is there a compare-n-contrast anywhere?

<comment><USER9> The original designers of the macro system absolutely had Scheme firmly in mind (source: I was there). The most telling giveaway is that the identifier for declaring macros, "macro_rules", is a reference to Scheme's "syntax- rules". As for a comparison, Rust macros have to jump through hoops to account for the fact that Rust has syntax (and types), and the Rust system isn't entirely hygienic yet (work in progress).

</comment></comment><comment><USER10> As an hp-er I'm all for RPN but that code is making my eyes bleed. I'm assuming it's just an example and not some kind of endorsement.

<comment><USER11> Yeah just used it as a (hopefully) simple and familiar example to explain macro mechanics.

</comment></comment><comment><USER12> Here is my ten minute implementation in TXR Lisp:

Trying _rpn-compile_ at the REPL:

      $ txr -i rpn.tl
      1> (rpn-compile '(3))
      (let* () 3)
      2> (rpn-compile '(3 4 +))
      (let* ((#:g0266 4)
             (#:g0267 3)
             (#:g0268 (+ #:g0266 #:g0267)))
        #:g0268)
      3> (rpn-compile '(3 4 + 5 6 + *))
      (let* ((#:g0269 4)
             (#:g0270 3)
             (#:g0271 (+ #:g0269 #:g0270))
             (#:g0272 6)
             (#:g0273 5)
             (#:g0274 (+ #:g0272 #:g0273))
             (#:g0275 (* #:g0274 #:g0271)))
        #:g0275)
      4> (rpn-compile '(3 4 + dup *))
      (let* ((#:g0276 4)
             (#:g0277 3)
             (#:g0278 (+ #:g0276 #:g0277))
             (#:g0279 (* #:g0278 #:g0278)))
        #:g0279)

Code in _rpn.tl_ :

      (defstruct rpn-compile-time nil
        temps
        lets
        stack)

      (defun allocate-temp (rct)
        (push (gensym) rct.temps)
        (first rct.temps))

      (defun compile-expr (rct expr)
        (if (member expr rct.temps)
          expr
          (let ((temp (allocate-temp rct)))
            (push ^(,temp ,expr) rct.lets)
            temp)))

      (defun compile-dup (rct)
        (let ((top (compile-expr rct (pop rct.stack))))
          (push top rct.stack)
          (push top rct.stack)))

      (defun compile-swap (rct)
        (swap (first rct.stack) (second rct.stack)))

      (defun compile-binop (op rct)
        (let* ((left (compile-expr rct (pop rct.stack)))
               (right (compile-expr rct (pop rct.stack)))
               (sum (compile-expr rct ^(,op ,left ,right))))
          (push sum rct.stack)))

      (defvar *compile-table*
        ^#H(() (dup ,(fun compile-dup))
               (swap ,(fun compile-swap))
               (+ ,(op compile-binop '+))
               (- ,(op compile-binop '-))
               (* ,(op compile-binop '*))
               (/ ,(op compile-binop '-))))

      (defun rpn-compile (exprs)
        (let ((rct (new rpn-compile-time)))
          (each ((word exprs))
            (iflet ((fun [*compile-table* word]))
              [fun rct]
              (push word rct.stack)))
          ^(let* ,(reverse rct.lets) ,(first rct.stack))))

Having this function, making the macro is trivial. At the REPL again:

      5> (defmacro rpn (. exprs) (rpn-compile exprs))
      rpn
      6> (rpn 2 2 +)
      4

<comment><USER13> Does the evaluate at compile time to a constant or does it produce that series of let bindings?

<comment><USER12> Nope; it makes the _let_ bindings. The job of reducing to a constant is better left to the processing of the _let_ rather than duplicated in the macro.

If you have a compiler which can reduce (let ((x 3)) ((y 4)) (+ x y)) to 5, why replicate that in a macro.

If you do not have one (as is the case here), then it's better to work on getting one than compensating for it in macros.

Yet, with the following small change to _compile-expr_ , whereby we avoid generating temps for constant expressions, we can at least get some nicer- looking output:

      (defun compile-expr (rct expr)
        (cond
          ((member expr rct.temps) expr)
          ((constantp expr) expr)
          (t (let ((temp (allocate-temp rct)))
               (push ^(,temp ,expr) rct.lets)
               temp))))

      1> (rpn-compile '(3 4 + 5 6 + *))
      (let* ((#:g0266 (+ 4 3))
             (#:g0267 (+ 6 5))
             (#:g0268 (* #:g0267 #:g0266)))
        #:g0268)

</comment></comment></comment><comment><USER14> Rust is probably the most advanced programming language with the worst syntax. Prolog and Erlang are a joy after Rust.

<comment><USER15> What is so terrible about the syntax? My biggest problem with Rust isn't the language, but the tooling which is still not quite there yet.

I find the syntax ok, and you do get used to the snake_case.

<comment><USER16> My impression has always been that it probably feels right at home for people with mathematical backgrounds, and mildly line-noisy for people coming from traditional programming backgrounds.

Stuff like this:

      fn map<T, U, F>(vector: &[T], function: F) -> Vec<U>
        where F: for<'a> Fn(&'a T) -> U {
        ...

It's not too hard to read once you're in the ecosystem, but there's a lot of non-alphanumerics in there, and you know each one of them is super important to getting the thing working.

<comment><USER15> While I like the functional style you actually did bring up one of the cases where I find the syntax a bit too much. Why can't we have the functional interface information on F directly in the signature?

Why not something more akin to ML?

        fn map<T, U, 'a>(vector: &[T], function: &'a T -> U) -> Vec<U>

</comment></comment></comment></comment><comment><USER17> RISP

</comment><comment><USER18> It looks like Rust doesn't have your dad's Lisp macros and more like C-style macros on steroids. Disclaimer: I haven't read The Book.

<comment><USER19> Well C macros work at the text-level, Rust macros run at the AST level (but not the type level, that is you cannot construct syntactically incorrect stuff but you can construct wrong-typed stuff).

So I don't really know lisp macros but I guess it's still closer than to C.

<comment><USER20> Rust macros actually work more at the token level than at the AST level.

<comment><USER11> They work on both - for example, if you specify $expr:expr, it will actually parse it as an expression node and won't allow to simply pass it into another macro as $pat:pat because of AST node type mismatch even if actual tokens are still compatible.

<comment><USER20> That's a good point. What I was trying to get at is that Rust macros don't let you manipulate ASTs in any straightforward way. So they are not best thought of as AST -> AST transforms.</comment></comment></comment></comment></comment>


Ask HN: Terminate an employee without feeling like a tool - <AUTHOR> I've got a few employees reporting to me in our product development team and for the first time I need to release someone. He is a little senior and has a family and kids. I've been putting it off because I feel bad about doing this. But his cost is high and doesn't justify his output. He's hardworking but simply not able to perform up to the expected standard.<p>How do you get yourself to pull the trigger?<p>(Throw away account for obvious reasons) <comment><USER2> If you haven't yet, document asuch as you can stand about 1) your expectations of him and 2) how he's not meeting those expectations.

Additionally, it would probably be worth trying a performance improvement plan. Your ideal is not to fire him, but to get what you expect out of him. Give him a chance to explicitly try to meet that.

<comment><USER3> I support offering a PIP. It worked for me: [https://news.ycombinator.com/item?id=13061160](https://news.ycombinator.com/item?id=13061160)

</comment></comment><comment><USER4> If you simply cannot afford him, don't bother with wasting 6 months on a PIP. Give him an extremely generous severance (at least 6 months). If possible also offer him some kind of training course options on exit to assist him as these can be tax favourable and $1K to $2K may be chump change for your company but it will be extremely valuable for him. More importantly it will give him some sense of a goal to occupy his time. Career-wise, it also allows him to sell a story to the next employer about leaving you "to further training".

Having managed senior employees before who go through difficult times either through family commitments or health issues, I would say try to think about it on a human level. Not everyone is a 10x fresh grad and I can guarantee you will one day go through the same experiences. I say this as a top school grad who used to be very arrogant in my early 20s but now discovering life's challenges can take a toll on your performance and mental state.

</comment><comment><USER5> >> But his cost is high and doesn't justify his output.

I read this as the cost is affordable to the company but not worth his output.

>> He's hardworking but simply not able to perform up to the expected standard.

May be he is not assigned the correct role/responsibility. Not every employee is going to be proactive to ensure the correct fit. If that is not an issue, then obviously PIP is the more humane way to go and combine it with a cut in his salary and revert it back when he meets the expected standards.

Suggesting a cut for the duration of PIP will also tell you how much he values the job, agrees with the areas of improvement and is willing to the work on it. If he is not willing to take a cut, then may be he knows he is not producing the expected output.

<comment><USER6> or maybe hes just not willing to do the same job for less money.

</comment></comment><comment><USER7> > He's hardworking but simply not able to perform up to the expected standard.

Does he understand your standards? Has the quantity/quality of output been clearly articulated?

It's relatively easy to fire someone. Confronting a direct report, managing/measuring work performance, and motivating individuals is hard. This stuff can be very personal, first try bringing him into your world, explain your thinking. A candid conversation might surprise you.

</comment><comment><USER8> Finding new hardworking employees is difficult.

If he's hardworking and senior he probably deserves a performance improvement plan to improve output and meet goals.

Sometimes employees need a refresher on what their goals are in this case they have probably changed/increased over time.

So meet with him and lay out some goals, expectations. Document them and have a monthly meeting to go over them stress it's important to increase productivity to keep his position.

Good luck.

</comment><comment><USER9> Its a little obvious, but how well do you know him and how happy do you think he is in this job?

There isn't enough detail here, but usually one person not performing could be a lot to do with his manager.

Standard UK procedure is to engage HR and get their advice, which would be you documenting everything and lengthy PIP.

</comment><comment><USER10> There's some good stuff about this in Ben Horowitz's book "The Hard Thing About Hard Things." I definitely recommend reading it for advice on this, and many other topics.

</comment><comment><USER11> What is a little senior? Does he now he is not performing enough?

</comment><comment><USER12> If your not willing to meet with him and let him have the opportunity to try to meet your requirements. I suggest that you offer him a genorous severance package to avoid a claim against your company as from your message it seems he is unaware that his performance is below your requirements.</comment>


Show HN: The Rapportive for Email Lists - <AUTHOR> https://mailmatch.io/

<comment><USER2> I loaded in a MailChimp list with ~150 names but didn't get any preview, just a loading screen with an overlaid button that says "Fetch all 25 emails for $5.00"</comment>


Why has CPU frequency ceased to grow? (2014) - <AUTHOR> https://software.intel.com/en-us/blogs/2014/02/19/why-has-cpu-frequency-ceased-to-grow <comment><USER2> That was a bit misleading in some ways. First, in pipelining you'll typically measure how long a pipeline steps in FO4s, which is to say the delay required for one transistor to drive 4 other transistors of the same width. Intel will typically design its pipeline stages to have 16 FO4s of delay. IBM is more aggressive and will try to work it down to 10. But of those 10, 2 are there for the latches you added to create the stage and 2 are there to account for the fact that a clock edge doesn't arrive everywhere at exactly the same time. So if you take one of those 16 FO4 Intel stages and cut it in half you won't have a two 8 FO4 stages but two 10 FO4 stages. And since those latch transistors take up space and energy you're got some severe diminishing returns problems.

One thing that's changed as transistors have gotten smaller is that leakage has gotten to be more of a problem. You used to just worry about active switching power but now you have to balance using higher voltage and lower thresholds to switch your transistors quickly with the leakage power that that will generate.

And finally velocity saturation is more of a problem on shorter channels making current go up more linearly with the gate voltage than quadratically.

<comment><USER3> I don't think anyone uses U/LVT transistors in low geometries, the leakage would be a nightmare .

<comment><USER4> I know a lot of people using LVT transistors in 28 and 16/14nm processes, including relatively low power (mobile and embedded) designs. I personally have used LVT variant SRAM blocks for both our 28nm and 16nm designs, and ULVT cells manually placed for critical path for Neo's FPU for our 28nm chip.

<comment><USER3> I should've rephrased: I don't know of anyone* who uses ULVTs exclusively, to answer the parent of using ULVTs to increase speed.

 __* Okay, I know of _some_ people, but their design is different.

</comment></comment></comment></comment><comment><USER5> I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardware system to exploit it to keep things going forward. I find the apparent stagnation extremely depressing.

<comment><USER6> [https://golang.org/](https://golang.org/)

In case you dont know, Golang _goroutines_ are a marvel of parallelism. They are coroutines which are dispatched on a few OS threads. So you can use 100% of a multi-cores CPU and yet, spawn, say, 10K of those _light threads_ without worrying about context switches PLUS have them all run concurrently. I've found that golang is one of those rare language, like Lisp, that actually change the way you think about programming. Makes you feel really more powerful.

If you dont know that language, I suggest to run the following and watch your cpu activity and memory (or any metric):

      import "time"
      func main() {
        for i := 0; i < 10000; i++ {
          go func() {
            for {
              time.Sleep(time.Second)
            }
          }()
        }
      }

<comment><USER7> Your example will _not_ run in parallel. The go runtime will schedule your goroutines _concurrently_ , but they will be run by a single OS thread, and consequently on a single CPU core.

Once you execute truly on multiple CPU cores (by increasing GOMAXPROCS), you'll be having the same kind of race conditions in Go as in any other imperative language (inb4 Rust Evangelism Strike Force saying "except Rust").

<comment><USER6> Wrong. Goroutines are _not_ simply coroutines.

GOMAXPROCS defaults to number of cores.

<comment><USER7> Prove it.

Prove it by replacing Sleep in your example with some number crunching, and show how it scales with the number of cores in your CPU.

<comment><USER8> [https://imgur.com/a/DNpw3](https://imgur.com/a/DNpw3)

Running the following code.

[https://play.golang.org/p/k_rRxNAyb0i](https://play.golang.org/p/k_rRxNAyb0i)

I can assure you that go runs across all processors by default.

[https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3...](https://docs.google.com/document/d/1At2Ls5_fhJQ59kDK2DFVhFu3g5mATSXqqV5QrxinasI/edit)

<comment><USER9> That's not what he's saying. He knows go can use all processors if GOMAXPROCS is set correctly, the argument seems to be that there will be race conditions just like any other threading, which seems pretty self evident to me: yes, multi-threaded code can have concurrency issues, film at 11...

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Seems like an incredibly long winded way of saying 'To go faster you either need to split up each instruction into lots of parts or increase the voltage for the transisters. We've split the instructions as much as we can, and power consumption is proportional to Voltage cubed, so it's not a scalable plan.'

<comment><USER11> More importantly than mere power consumption, we don't have a way to remove the waste heat generated. Dennards law (like Moore's law but for power consumption per transistor) ended 10 years ago. Exactly the same time clock speeds stopped improving. There are actually a few computers out there that run around 10Ghz but they all have impractical cooling systems.

If there ever were a return to exponential scaling, we would very soon run into the Launder limit.

<comment><USER3> > If there ever were a return to exponential scaling, we would very soon run > into the Launder limit.

No we wouldn't. We're around ~10,000X off and would run into thermal danger zones long before.

<comment><USER11> BUT....The Launder limit is over optimistic because unless your computer runs at absolute zero you need to keep redundant copies of each bit for error correction. Transistors are implicitly error correcting in the sense that each bit is represented by a current of a few thousand electrons.

Factoring in the redundancy requirement we are likely only off by somewhere between 100x and 1000x. If there were ever a return to exponential technological improvement, we would run out of road after a few years.

<comment><USER3> That's my point though, the bottleneck is not going to be Landauer's Limit.

</comment></comment></comment></comment></comment><comment><USER12> Re: all the programming replies.

Preface, I'm not a programmer, I'm a hardware guy.

It's all well and good to make sure your programs and future programs are able to be run in a parallel fashion but there is a big hole to that and it's the operating systems methods of handling cores and threads.

Let's use folding@home as an example. Very multithreaded. Now let's use, at first, Ryzen 1800x as the hardware we'll run it on. We have 8 physical cores. We also have two separate dies. Each die has four cores. Each die module has their own level 3 cache. As you use your system and you are also folding, even in the newest Linux kernel, data and instructions might get evicted and bounced around and take latency hits and thus performance hits. Nothing really locks the work to the cores or threads taking into account locality. You can adjust this with HTOP and set each thread of folding manually.

Beyond AMD, even Intel has similar issues still with the 8700k. Hell, in general just efficient multithreading seems like a tough compromise for OS development. "Users" want things to be smooth upon interaction, so you have preemption. Work wants to get done but it also wants to be a good citizen to the rest of the system.

Developers are going to have to learn about, and keep up to date with, much more then a fancy new language. You're going to have to learn each new CPU inside and out and how each OS treats it.

<comment><USER13> How did the BeOS designers make the BeOS so good at multiprocessing? I remember how well the operating system scaled with more than one CPU.

<comment><USER14> Probably because it ran on PowerPC. If I remember my systems design class from 20 years ago, RISC makes implementing or scaling multiprocessing easier.

<comment><USER15> Intel processors essentially are RISC now internally. They just expose more complex instructions as a higher level API.

<comment><USER16> They are not RISC internally. In fact I read an interview with an intel engineer that an intel cou has >10,000 uops. That's not in any sense reduced!

And it doesn't make sense to apply the term "risc" to internal CPU design anyway.

</comment></comment></comment></comment></comment><comment><USER17> Notably, single-thread performance of code that is not friendly to vectorization has not stagnated despite stagnant clock frequency. Indeed, SPECint performance continues to grow exponentially, albeit more slowly since ~2004.

[https://www.karlrupp.net/2018/02/42-years-of- microprocessor-...](https://www.karlrupp.net/2018/02/42-years-of- microprocessor-trend-data/#more-760)

<comment><USER18> Depends on the code, you can write ASM that's as fast on an old P4 as a modern i7. Just access random RAM locations and modern CPU's suck.

<comment><USER17> Increasing CPU clock speed also does not reduce DRAM latency.

<comment><USER18> We are talking about the sum of latency's. The CPU needs to do something _AND_ you need to fetch from DRAM. Modern CPU's have increased the worst case overhead to fetch form DRAM to decrease the average case.

That's usually a good trade-off until someone wants to make your CPU look terrible.

</comment></comment></comment></comment><comment><USER19> My senior design course focused on asynchronous (clock-less) cryptography circuits; after learning of these, I looked into asynchronous general purpose processors, and learned that ARM actually designed an asynchronous processor back in the 2000's [0].

While they've never quite taken off (the extra gates decrease speed and our harder to manufacture), with the recent side-channel attacks on processor pipelines, I've been hopeful that I would see something pop up. Imagine a world where our processors run without a clock!

[0] [https://www.eetimes.com/document.asp?doc_id=1299083](https://www.eetimes.com/document.asp?doc_id=1299083)

<comment><USER20> Wouldn't asynchronous CPUs increase the amount of side-channels? AFAIK in an asynchronous circuit every aspect of the calculation may affect the time it takes to complete.

<comment><USER19> The attacks I'm aware of use processor timings to measure the effects their programs are having. However, because an asynchronous circuit doesn't complete tasks in a reliable cycle, you can't measure how the pipeline is being effected by your program in the same way. You could find new ways to force the processor to act in a reliable manner that you could measure, but that may change quite randomly from processor to processor, or even from moment to moment, depending on external environmental factors.

</comment></comment></comment><comment><USER21> I understand that companies heavily invested in silicon would like to portray it that way, but CPU frequencies haven't ceased to grow.

DARPA manufactured a THz transistor made of InP back in 2014.

Silicon isn't the only semiconductor in nature, and others are actively being researched.

Also, "when you increase the frequency you increase the power" (which is their argument) doesn't explain why they can't increase the frequencies. That was always the case even back in 1960s.

What they actually need to explain is why they can't make the silicon more power-efficient anymore; all toy-physics arguments (such approximations/linearizations work only for a very limited range of frequencies, if they do at all, anyway meaning their scaling-relations aren't universal like they're trying to portray and those coefficients they ignore aren't constant across voltage, frequency, materials, ... either; you almost never get such simple and universal answers in condensed matter physics even for much simpler problems) mentioned there could have been made 50 years ago as well, but silicon CPU frequencies did go up.

<comment><USER22> Transistor switching frequency has almost nothing to do with processor clock speeds which are almost entirely limited by wire RC delay. You will get increased drive currents by switching to higher mobility materials but the performance improvement over strained silicon isn't that large.

<comment><USER21> That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved.

But if your switching frequency is slow, it doesn't matter if you use a superconductor for wires. It is the switching frequency that truly determines the limits for gate times, which in turn determines how fast your CPU is.

For the record, SiGe is also very promising in terms of switching speeds. There were experiments which shows near THz frequencies.

<comment><USER3> >That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved.

No it's not. What is this magical material with ultra low resistance? And how do you plan to reduce capacitance?

Btw, manufacturing terahertz speed transistors is very difficult. There are Mott FETs which will switch at 10 terahertz, but they're incredibly hard to manufacture and very power hungry.

<comment> d-sc I can't speak on their usability in circuits. However, materials that show properties characteristic of zero resistance exist. I've used them at work before.

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

<comment><USER3> And how do you propose to cool every chip to cryogenic temperatures?

Not to mention the manufacturing challenge of integrating superconductors into chips (I think InP would be the easiest candidate, and that's saying something...)

</comment></comment></comment></comment></comment></comment><comment><USER23> In some cases because not necessary. Take the Gen 1 Google TPUs. They use a 700 mhz clock rate but are processing 65535 things at the same time. Very simple instructions.

Here is a great paper on comparing to silicon using far higher clock rates.

[https://arxiv.org/ftp/arxiv/papers/1704/1704.04760.pdf](https://arxiv.org/ftp/arxiv/papers/1704/1704.04760.pdf)

Now what will be interesting is this new architecture can be used for more traditional CS functions.

I love this paper from Jeff Dean on using the TPUs instead of a CPU to replace a b-tree for example.

[https://research.google.com/pubs/pub46518.html](https://research.google.com/pubs/pub46518.html)

This also solves our multi-thread issue. Basically it done in a multi-thread manner from the ground up.

We get a round peg for a round hole.

</comment><comment><USER24> Let me take the opportunity to plug my favorite computer architecture course from ETH, who was published here recently.

[https://www.youtube.com/playlist?list=PL5Q2soXY2Zi9OhoVQBXYF...](https://www.youtube.com/playlist?list=PL5Q2soXY2Zi9OhoVQBXYFIZywZXCPl4M_)

[https://safari.ethz.ch/architecture/doku.php](https://safari.ethz.ch/architecture/doku.php)

</comment><comment><USER25> I find their explanation of the pipelining issue slightly confusing, probably because they tried to simplify it to the extreme:

>One could object to this and note that due to shorter clock ticks, the small steps will be executed faster, so the average speed will be greater. However, the following diagram shows that this is not the case.

Said diagram shows that the two-clock-tick step locks the pipeline, that is you can't execute the first clock tick for the next instruction if you're still running the 2nd part of the previous one. When would this be the case? Isn't entire point of pipelining to divide a function into smaller steps that can be run in parallel? If you can split "step 3" across two clock cycles, couldn't you effectively subdivide it into two steps that could run in parallel?

I suppose that eventually you run across the issue that adding additional pipelining stages increases the logic size which in turn causes it to run slower or something like that. I wish the document was a little more specific, after all it doesn't hesitate to throw the physical formulas for power dissipation in the 2nd part so clearly it's not afraid to dig into technical details.

<comment><USER26> > If you can split "step 3" across two clock cycles, couldn't you effectively > subdivide it into two steps that could run in parallel?

There is a difference between splitting "step 3" across two clock cycles and splitting "step 3" into two separate steps. The underlying assumption here is that "step 3" is indivisible. E.g. say "step 3" was memory access and the latency for that is 500 picoseconds, it's not like you can just split it into two steps and make it load faster.

</comment></comment><comment><USER27> > But remember, wrong overclocking can harm not only processor but you as > well.

Don't date robots!

</comment><comment><USER28> They fail to mention that dividing instructions into more pipeline stages means greater branch penalty which in turn prompts reckless speculative execution schemes to compensate.

</comment><comment><USER29> The rule of thumb in chip design: your chip clock is as slow as your slowest logic pipe. Complex logic circuitry slows down potential clock rates significantly. You can make your logic gates switch faster, thus allowing longer signal paths, but it has a huge energy trade-off, as the article states.

Multi-core design seems now to compensate for slower clock rates, but it also has its trade-offs. It makes software more complex. In case of the CISC arch Intel established it's a huge trade-off, since CISC is supposed to make its processors easier to program, as opposed to RISC. I don't think that CISC is a good choice when it comes to massive parallelism.

But, since chip design is so expensive and is considered state of the art high-tech, we'll need to deal with everything that chip makers throw at us. Or do we?

<comment><USER30> The RISC/CISC "tradeoff" is mostly a non-issue at the higher end of processor design: everything is now a hybrid. You have ARM64 with its SIMD and floating point extensions that hardly qualifies as "reduced" on one side, and Intel systems that have a suspiciously RISC-like internal architecture fed by decoder of the "legacy" CISC instruction set.

It still matters at the small end, which is why Cortex-M exists.

> Or do we?

A startup can design its own chips, but good luck getting anyone to _use_ it.

<comment><USER31> It worked for P.A. Semi (eventually).

</comment></comment></comment><comment><USER32> The article doesn't answer the question at the fundamental level. The closest it gets is this: _" Increased frequency depends heavily on the current level of technology and advances cannot move beyond these physical limitations."_

Certainly, Moore's law is just an observation and cannot go on forever. Would it fair to say that we've simply reached the point where we can no longer "keep up" with Moore's observation because the technology is getting harder and not because we've actually reached any limit of _physics_?

<comment><USER33> You're skipping over the main point of the article, which is that the reason it's hard to increase the clockrate is because it is dependent on the slowest instruction that can be done in one tick.

And the main method of making an instruction faster is by splitting it, but all instructions have now already been split as much as is possible, while still having them operate correctly.

<comment><USER34> But this shouldn't be true for a superpipelined processor, right?

Or put it another way, let's say phase 3 contains several important instructions that cannot be reduced to a length of less than 1.7 clock ticks. If the pipeline stalls you have other pipelines that won't.

Or you get crazy and put in 2 copies of the slow paths of phase 3 and one takes the even ticks and the other the odd ones.

</comment></comment></comment><comment><USER35> Until we have another material that could replace silicon. Not sure if we will see this happen in the next ten to twenty years.

<comment><USER36> The 60 mV/dec limit applies to all materials, not just silicon. Beating it will require a fundamentally different type of operation. Agree that changes in materials will require massive investment and learning.

<comment><USER2> Sure, but many materials have _much_ higher electron and hole mobility than silicon has.

<comment><USER3> He's talking about the Boltzmann limit of MOSFETs

</comment></comment></comment></comment><comment><USER37> Exponential growth can't be infinite. Who knew! Mind blown!

</comment><comment><USER38> I've been looking at Haskell, Rust and Go for helping with parallelism but decided to go with a less known language: Pony. Not used actors a lot right now but looks really promising.

<comment><USER39> Particularly given you haven't used actors, what advantages does Pony give you over Haskell?

<comment><USER38> Right now I found Pony more approachable than Haskell. Maybe because that I never fully grok monads (probably my fault not persevering enough), I always had problems composing monads.

Also the promise of Pony is a garbage collection that is concurrent with program execution and since I want to write low latency server code this feature sounds very appealing.

</comment></comment></comment><comment><USER40> Funny to read comment section in russian source article. People argue about need of multicore processors in a desktop pc. Especially when I read those comments from 16 core machine.

</comment><comment><USER41> >temperature

Using a proper thermal interface material in their CPUs would be a start...

When you can decrease the temps of Intel CPUs by 20°C with delidding, the heat argument seems quite constructed.

</comment><comment><USER42> "Only _you_ can prevent overclocking fires!"

Nicely written. Seems like the intended headline was "why it's bad to overclock", though!

</comment><comment><USER43> It's a matter of cost and cooling really, IBM z13 is 5GHz, z14 is 5.2GHz.

<comment><USER44> No, it's a matter of economics. Those zXX chips are not cheap, nor is what they interface to.

</comment></comment><comment><USER45> There is a new relevant episode of changelog's podcast that talks about CPU advancements.

[https://changelog.com/podcast/284](https://changelog.com/podcast/284)

</comment><comment><USER46> Cost/benefit AFIAK-- higher clock speeds require advanced cooling, use more power, etc., and it's been possible to get more speed by increasing transistor count instead at lower cost.

</comment><comment><USER47> Are there any CPUs out there with FPGAs tacked on that are available to the hobbyists/gamer/build your own PC crowd?

<comment><USER48> There are some hobbyists using the 28nm Xilinx Zynq, a hardened circa-2009-cell-phone dual-core ARM with on-die FPGA. One popular board is the [https://www.crowdsupply.com/krtkl/snickerdoodle](https://www.crowdsupply.com/krtkl/snickerdoodle)

</comment></comment><comment><USER49> Asynchronous CPUs or bust.

Or, better yet, wave pipelining...

</comment><comment><USER50> It's there if you want it, but liquid helium doesn't come cheap.

</comment><comment><USER51> "CPU manufactures will not allow a meltdown to happen."

No one in the office understands why i'm laughing....

<comment><USER52> The spectre of meltdown is haunting CPU manufactures.

<comment><USER53> Great, now I have to clean all that tea off of my display. ;-P

<comment><USER54> and i thought that humor is verboten around here... Does HN have an exception in the book that applies to Intel ?

<comment><USER55> I don't think humour as such is frowned upon on HN - if I was to attempt to write down the unwritten, I would say that posts that are just jokes tend to go down badly, but jokes that make a point or serious posts that are written with some wit are generally accepted.

</comment></comment></comment></comment></comment><comment><USER56> _> But there are also strong concerns that the increased frequency will raise the CPU temperature so much that it will cause an actual physical melt down. Note that many CPU manufactures will not allow a meltdown to happen_

<comment><USER57> At least they have a sense of humor.

Edit: Oh, 2014. The sweet irony.

</comment></comment><comment><USER58> (2014)

<comment><USER59> Thanks! Updated.

</comment></comment><comment><USER60> guys, I'll be honest: I found it really odd that the article didn't talk about the speed of light, and die size constraints. (c / 4 ghz = 7.49 cm only, if you double that frequency you have half that size to put components it between any two clock ticks.)

But there are limits to my hubris - this is on intel.com, so I'm going to go with "I'm the one missing something". Is the speed of light and number of transistors you can put in that path (due to die size) just not a practical constraint? Neither is mentioned.

<comment><USER30> The key factors in integrated circuit delay are more to do with capacitance; in order to change a gate's transistor from off to on, the driving gate has to charge the capacitance of the driving wire and the driven gate. Making features closer together increases their mutual capacitance.

(source: worked on this for a chip design software company. The delay approximation was based entirely around R/L/C modelling and had no terms for the speed of light per se. If I remember rightly it was calculated in integer pico-meters; I definitely remember it emitting an error message if you had more than 2cm of wire in any one net!)

<comment><USER61> I.e. the problem is the state of processor, which need to be erased. So we can make stack of stateless processors, which will readily accept fresh data, because they will need to fill capacitors only, not discharge, and then discharged after use. Kind of multicore design, but with each core used for only 1/n of time at e.g. 1Thz frequency. Unlike parallel system, sequential calculation will work faster in such setup.

<comment><USER20> discharging and charging capacitance is generally pretty symmetric. I don't think what you're suggesting would provide much benefit.

<comment><USER61> But heating and cooling is not symmetrical. We can heat a processor much faster than cool it. So, if we need to cool a processor 10x faster than we can, just use 10x more processors, and switch them in order, to allow them cool after use in overclocked mode. Using this simple technique, frequency can be raised by few GHz, which is important for serial computations.</comment></comment></comment></comment></comment>