skysight-inc/HackerNews huggingface dataset:
I just don't see what kind of useful programming you can do without knowing anything about the machine it runs on.

If "a = b + c" takes a second to execute, you have to take that into account. The programs that people wrote for 1950s computers were very different from today, even though the language semantics might be essentially the same.

On the other hand, this discussion is helping me understand why the web development world is full of weird database-backed Rube Goldberg machines that can spend milliseconds to access a few bytes of data that were already in RAM.
"Man's nature is indeed so malleable that it may be on the point of changing again. If the computer paradigm becomes so strong that people begin to think of themselves as digital devices on the model of work in artificial intelligence, then, since for the reasons we have been rehearsing, machines cannot be like human beings, human beings may become progressively like machines. During the past two thousand years the importance of objectivity; the belief that actions are governed by fixed values; the notion that skills can be formalized; and in general that one can have a theory of practical activity, have gradually exerted their influence in psychology and in social science. People have begun to think of themselves as objects able to fit into the inflexible calculations of disembodied machines: machines for which the human form-of-life must be analyzed into meaningless facts, rather than a field of concern organized by sensory-motor skills. Our risk is not the advent of superintelligent computers, but of subintelligent human beings." - Hubert L. Dreyfus, What Computers Can't Do 1972
That doesn't sound right.

By all means correct me if I'm wrong, but I recall learning that there's a semantic difference between b/strong (as well as i/em).
For the most part, in the United States, this kind of notice is a courtesy not 100% required.
All his major claims seem correct to me, but my experience in fusion-related research was on the theoretical side. Is there a written summary of what is supposed to be incorrect?
Microservices are here to stay, especially in large engineering orgs. NodeJS and Javascript, on the other hand, I'm not so sure about... Many of the engineers I know view this technology as a "cancer" when compared to Java, Go, etc. Their reasoning is that Javascript doesn't offer the safety or maintainability that other languages do.
I think someone needs to let bill gates know about this video. It's very promising and well planned and it really just needs a minimal investment.

Also someone needs to write this stuff up into an engaging article. It's hard to spread the word with an hour long video.
Quit your job and work the rest out later. Ask your parents and friends for support. I'm a total stranger and I'd rather you not be dead, so imagine how the people that know you would feel.

We have this problem in our American culture: If we're not careful, we begin to derive our self worth from our work. You can choose not to do that. Quit, and when you're ready to go back to work, work to live, not the other way around. Fuck it, take something menial for a bit that doesn't follow you home.
Instagram is growing faster than ever and now has 700M users
I know very little of COBOL but I have often wondered if bank COBOL software could be transpiled (a quick googling shows there are transpilers). That is COBOL -> Some_Other_language and perhaps Some_Other_language -> COBOL.

Then in theory you could write unit tests in some language to test the real COBOL and the transpiled COBOL.
Under a VM, or a BSD jail?
Your asterisk got interpreted as italicization and screwed up your post.
You can check the Spamhaus lists. It's a non-profit org dedicated to all-things-spam. https://www.spamhaus.org/
Are you sure it's the exact same? There have been studies looking at quality/purity of medications manufactured in different countries, and they don't all have high standards of purity.
One factor is that "Adrenaclick" is not a generic EpiPen. It is a different branded epinephrine autoinjector, with generic versions available. The FDA regulates epinephrine autoinjectors so that a prescription for EpiPen must be filled with an injector that has the same operating instructions as EpiPen. Adrenaclick and generics do not have the same operating instructions as EpiPen.

It's not a completely ridiculous regulatory decision, but it certainly factors into people not using the alternatives.
I can really only use Spice on Linux. The Mac client is unusable. Haven't tried the Windows build.

It would be a nice protocol if there were functional clients, but I fear that train has sailed.
Unless the parallel operations you're running interweave nicely with the CPU pipeline, there are many instances where a hyperthreading enabled 4-core CPU performs no better than a non-hyperthreading enabled 4-core CPU.

On average, a setup with 4 logical cores and 4 physical cores performs 15%-30% faster than a setup with just 4 physical cores.
Nothing critical (banks, military, factories) runs on NodeJS/JavaScript/AWS so probably nothing. Do you think a lot about some old BASIC Accounting Software?

There are probably only two languages which might face similar problem as COBOL: C and Java. For now they are both actively maintained and used for new projects - so we are fine for at least next 50 years.
Free Python Resources
you are right - I will rewrite it to use HTML Tidy lib or something like that and it will be compliant
Compared to COBOL, that IBM PC is a whippersnapper. An IBM 370 would have been a better match.

https://en.wikipedia.org/wiki/File:IBM_System_370-145_und_Ba...

My dad programmed in COBOL for the Army, and he retired in 1975. That's how old COBOL is. Knowing my dad, he probably still has his manuals, though finding them might prove an archaelogical exercise
That is step 3) usually marked as '???'. Step 4 is profit.
and a $100 dollar yearly stipend
Jack Dorsey on Donald Trump
>> The waves of offshoring in the '00s left many thousands of unemployed COBOL developers

If you were a developer affected by stuff in the '00s, you're probably nearing the end of your career (unless you'd just started)
The problem here is the lack of a NEW talent pool.
The problem is, when you have 10M lines of complicated COBOL, transpiling it to JavaScript will make things completely unmaintainable.
Source of said standard? Older cars (pre-1990) had pretty inaccurate speedometers, 5-10% off. Modern cars are very accurate.

There is no such need for cop to "prove" you "knew" you were speeding. Ignorance of the law (or the condition of your vehicle, or whatever) is no excuse, as the saying goes. When you sign up for a driver's license (in the US) you agree that you will abide by all traffic laws.
This old argument again? It seems like every 25 years somebody brings this up....
Except there is very little "free market" about the medical device industry, which is heavily regulated and also able to abuse the patent system.
gave up around 15 tries on my first attempt because I refreshed to review the instructions again but my 2nd try on easy I did it in 7
> We really need a better solution to fighting spam.

I rarely receive email spam these days. The spam I get is on my voice line. I'm getting several robocalls per day. If you have the skills to work on this stuff, I'd love to see a solution to phone call spam because email spam feels solved.
> requires some agreed-upon rendezvous point — i.e., a server.

Or a P2P network with a DHT. This can be done right now with a dedicated client (BitTorrent, BitCoin, FreeNet, IPFS, etc.). There are existing browser plugins which will opportunistically use a P2P protocol instead of HTTP, e.g. if you get the IPFS firefox extension, enable the "DNS lookup" option, and visit chriswarbo.net it should fetch the page via P2P. Projects like IPFS are currently experiments, but are aiming for browsers to eventually support (something like) them natively, alongside HTTP/HTTPS/FTP/etc.

Projects like WebTorrent are trying to implement this kind of thing in JS.

> Without servers, how will I see your edits when your browser is offline, or simply no longer visiting the page?

Again, distributed storage (DHT, etc.).

> I thought the whole point of Ward's Wiki was to be a neat place to discuss computer science & programming — in your analogy, to be the supermarket.

I've been told many times that my analogies are terrible ;) In this case, the supermarket represented some commercial Web site, with a clear separation between business and customer, where the business wants as much ownership and control as possible, and will go out of its way to keep customers happy (as long as it's profitable).

From what I can tell, Ward is doing this for the love of it. There is no profit to chase, so any project costs (like running a server) are a drain, and make it more likely to collapse. Removing those costs helps the project, even if it inconveniences visitors. Like the botanist, who wants to get on with their research rather than spending time growing produce for others.

Likewise, the visitors are contributors, not customers. They're not just after some product with as little transaction friction as possible (at least, the most valuable ones aren't; I assume most visitors just read something then leave). They're already investing their time into the project, so making things a little less convenient might be acceptable, if it means the project can stay afloat.

> It's strictly worse if

That's not how "strictly worse" works. If you claimed it's worse, I would emphatically agree (I hate single page JS "apps"!)

"Strictly worse" means that it is not better in any way; that the old version is a pareto improvement over the new one. It's not. There are reasons one might choose to do this. Those reasons are not ones that a commercial Web site should choose (exactly the opposite, in fact; they're like the supermarket); they're not ones that a static informational site should choose (e.g. they might choose to host on IPFS, but shouldn't go down the JS route); they shouldn't be chosen if identity/ownership are the goal (like indieweb, where self-hosted/managed servers make sense).

They do make sense if you want to throw a collaboration platform out into the world, with the only goal being to see what happens. That's what wiki was, so it makes sense.
I've been using this for a while now.
https://github.com/JsonCSharpClassGenerator/JsonCSharpClassG...
How do you message to your existing customers that you're holding their life savings on fragile 1970s tech?

Also, you'll still have to write wrappers for the old tech (iPhone apps which access the COBOL core) in order to maintain feature parity with the other banks.
My view is anything we have technology to cure we shouldn't worry about.

The more problems we can treat with technology the smaller the genetic search space becomes. evolution can focus just on the things we can't easily solve.
NodeJS and Javascript yes, but critical things absolutely run on AWS.
> It doesn't even take abusive bosses who don't like you, although that just makes it far worse.

Far worse.

I've worked at startups where we had to bust ass to get things done... mid-90s... sleeping at the office, going weeks without a paycheck to get the product to launch, living off Jolt and pizza -- and trying to build something that we honestly weren't sure could be built. And even if the work wasn't always done the exact way I would have suggested or agreed with, if I had a boss that took 5 minutes to explain why we were doing it... it was fine. No stress, just get it done.

I've worked at places that didn't require anywhere near that level of focus or time commitment that left me feeling just drained and miserable. Miserable to the point of wanting to pack it up and never see a computer again. Miserable to the point of acting out... little self-destructive things like sending snarky emails, calling in sick to play hooky, or indulging in office gossip. All because I had a boss who just demanded I do things without giving any reason, or who wasn't consistent with their stories.

Now I know enough, years of therapy / career coaching... and just age... when I see someone in a leadership position who just says, "Do what I say..." I start shopping for a new job. Or if they pull any manipulation crap like, "Sally and Mike know about X, but John thinks it's Y, and Sally can't know that Mike knows..." Or just simple lying... if they tell you something different than they tell anyone else. Life's too short to deal with those people.

Transparency, integrity, honesty... without those things in a boss, it doesn't matter how much work there is to do -- it'll be very stressful. It took me 10+ years to really nail down why I was successful at some jobs and not at others... for me, it all came down to the sort of boss I had. Didn't have much to do with me liking the person (or the scope of the work), or vise versa, as long as they weren't Machiavellian we could work well together.
I wonder what banks would do if it wasn't for those genius suggestions in the article... /s
Oh man, the days of needing to go to a conference to pick up Linux CDs. Yes, I definitely remember Caldera. Only thing from that list I haven't done is meet Linus though I guess I will get around to it at some point.

Actually come to think of it, Ubuntu really hit the CD nail on the head with Shipit, those of you with 28.8 modems will know this feeling. I still have my 7.04 CD.
Dog bites man, film at eleven.
This 'Auvi-Q' thing... I don't get it. It's just a rectangular EpiPen.

Oh wait, it talks to you. Why do you need an EpiPen to talk to you? You literally just take the cap off, whack it to your (or their) thigh, and count to 5.
I will make the disclaimer that I don't think I am an "expert", but I do some coaching for API.AI and have been helping a couple of clients build out simple chatbots.

I keep hearing this question a lot, and I think right now the best way to teach chatbot programming seems to be by using the simplest examples and this is a little misleading (is that all?). You can use regexp to build out a chatbot, but it might be a good idea to consider some pros/cons of using a service like API.AI.

Under the hood, API.AI (and similar bot programming frameworks) allow you to go much further:

1. Their entity matching system will let you start with a few examples and then keep matching many more similar examples (remember Google Sets?) without you explicitly defining every single one of them. The best example for this seems to be the food/recipe & geographical locations stuff for now, but if they can get it right for more domains that can be quite useful.

2. There is a way to use templated definitions of "here is what the user might say" which is quite powerful. Sure, you could probably do the same yourself, but think about it: you will be handling so many corner cases with such a system that if there were a prebuilt service already doing that work for you (and which is improving quite rapidly) you could probably build it out faster with the external service.

3. There is also enough flexibility where you can add webhooks (like the author has done) and basically put a lot of business logic into your chatbot.

4. Assuming API.AI will soon be acquiring some of the ML knowledge which Google already has, it is reasonable to expect that the intent mapping (the process of figuring out what the user said) will only keep getting better.

Having said that, here are some advantages of rolling out your own:

1. You don't typically get the full picture of what is going on under the hood with an external service. Unlike the case where you write your own code, this means when things fail (and they will), you sometimes don't know what is the cause, and worse, how to get around it.

2. There is always the inherent risk that the service you rely on might shut down some day :-(

3. The current tooling around moving your chatbot from staging to production in API.AI is fraught with risk. I don't know if it is the same with the other ones too. If you roll out your own chatbot, you don't have such issues.

4. There are also some features which have been added to API.AI which are sort of all or nothing. A good example is the small-talk feature which you can import into an agent. The trouble is, you cannot really customize it much, so when it doesn't give you the behavior you expect, it can become a bit of a liability.

Hope that helps!
Glad to see someone else pointing this out.

The problem with these systems is that they are very old, and thus do not benefit from many of the more modern developments in the field nor do many quality developers learn the language.

The benefit with these systems, though, is that they are very old. With that age comes completeness. They're battle hardened, thoroughly tested, and a known quantity within the institutions that leverage them.

History is littered with companies that attempted to replace the core of their business with one big project written with newer technology, only to fail catastrophically.

During my first gig with a bank, I was appalled to see the ancient technology in play at the heart of the bank's systems, and the retired developers coming in part time on schedules they set for outrageous hourly rates to do maintenance tasks on that system. Over time, though, I came to realize that this was the most reliable and cost effective solution the bank had available.

The third option listed is what I see happening, but at a much slower pace than the article suggests:

> Basically, Döderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems. However, the key thing is how the connection to the old system is made.
> Gradually banks will be able to address each and every product need that they have with new platforms that will replace the overly complicated COBOL add-ons. This compartmentalizes the banks’ COBOL-problem and makes it cheaper to fix, as it won’t have to be done all at once.

It's a glacial pace, but it's being attempted. The heart of the old systems, though, were still untouched last I had visibility into those inner workings.
Thanks for the feedback - I updated it to make that available for preview.

I would recommend checking out Egghead.io if you haven't. They've got a lot of courses covering a range of stuff. Specifically, if you want to get into Redux, Dan Abramov's courses [0] [1] are great. Dan is the creator of Redux and a great teacher too. They're meant to be taken in order and they're available for free.

[0] https://egghead.io/courses/getting-started-with-redux

[1] https://egghead.io/courses/building-react-applications-with-...
EpiPen prices occur in a heavily regulated market. Mylan has a patent on the mechanism they sell (no generics from other companies) and there are all sorts of regulations surrounding the production of any drug offered for sale in the US.
Just tried it on Linux, and… all these features work pretty much exactly the same way.
Most (keyword: Most) self-taught programmers / hobbyists start with high level languages like Python, Ruby, PHP, JS etc and work their way "down" out of interest and intellectual stimulation (like myself). It might be counter-intuitive to those with CS backgrounds but the truth is for most things, you don't really need to know the implementation details of variable assignement if you're only interested in scraping the NYT.

Believe or not, pointers can be difficult to grasp as a concept for people who aren't used to this type of mental model.

If you didn't struggle with it, good for you. But there's no need to look down on others who are trying to learn. I should also add that Software Engineering and Programming aren't necessarly synonyms. Some programmers aren't SWE and that's OK.

If you're a "fake programmer" like the parent is trying to imply, don't lose hope. Continue to learn at your own pace and you'll eventually catch up.
No, they haven't, not even in single events, although their press releases claim that they have. Their actual papers make it clear that the claim of >1 energy gain is a result of somewhat arbitrary definitions. There has not been a single shot on the NIF where more energy was supplied by the fusion reaction than was used to fire the lasers - it's not even close.
I'm interested in the approach being investigated at LPPFusion, on a shoestring budget no less.

http://lppfusion.com/

LPPFusion is attempting to harness hydrogen-boron fusion, which doesn't produce neutrons, only gamma radiation and helium nuclei (alpha particles). Both the gamma radiation and the alpha particles can be directly converted into electricity. There are many potential benefits of this approach, but a primary one is that with no neutrons, there is no nuclear waste (or potentially plutonium) produced.

I hope LPPFusion can secure substantially more funding, it's doing more worthwhile research than the majority currently being done.
Democrats: weakening unions and anti-monopoly law since 1974.
All US traffic laws come from the Uniform Vehicle Code. Keep right rules are meant for absolutely slow traffic and not for driving the speed limit. The UVC has keep right exceptions for divided highways with multiple lanes going in one direction.

Passing left laws were intended for two way streets with one lane in each direction when the only way to pass is by driving on the lane going the opposite direction.
Even your mac will say 10 if you get to speak out Mac OS X. But I have had many a people insist it was not pronounced as Mac OS 10, but as Mac OS X.

I could understand the confusion.
Startups wanting to scale with an part-accelerator part-accounting firm
We are a maverick accounting and advisory firm for startups and scaleups and almost function as a part-accelerator to many. Check us out if you're in the market for some proactive advice on how to scale effectively and leave us feedback! www.fulllstack.com.au
> there is nothing like TextExpander

We use ubuntu at work and I was VERY worried about this. But autokey is actually good enough. The UI is not quite as slick but the rest of it is a little better. The exception is the little pop up form fill things which are cool but I found I did not really miss. https://github.com/autokey-py3/autokey
Surely it's not that simple. The sidebar alone indicates otherwise.

EDIT: To be clear, I'm pretty much the opposite of a 'red-piller', or whatever they call themselves. I find this whole thing utterly fascinating, to be honest, as well as a bit scary/concerning.
Is it just a hype, or is there any real advantage for the user?
From the point of view of the interaction, why should I chat with a bot instead of using a more classical gui?
I'm asking because i teach ux/hci, and a student just asked me to be her supervisor for a chatbot based interface, and I'm trying to understand if - in a user centered perspective - this approach makes sense
Hanging up my spurs
> Which is I think an important aspect of understanding the "billion dollar mistake", by the way; it is easy to deconstruct that mistake as being two mistakes rolled in to one, which may perhaps explain why it was such a big mistake.

If it's two mistakes, it's one big one (having null pointers at all) and one tiny one (the fact that calling methods on null pointers is undefined behavior in C++). The latter is yet another C++ gotcha, but not nearly as pernicious as the former, which causes nearly all the null pointer-related bugs in the wild.
When a reporter calls their credibility into question in the second sentence, there's a problem.

"they would produce vast amounts of energy with little radioactive waste, forming little or no plutonium byproducts that could be used for nuclear weapons."

Fusion products are helium, neutrons, and neutrinos. Stars eventually fuse products up to iron.

To generate plutonium requires a supernova...
Never mind the fact calling an undocumented API within your app could lead to really bad things for the user.
Sneaking in FP by the back door! The main features they mention are classic FP techniques: pattern matching and (block your ears, children) monads. Interesting they didn't talk about memory management till towards the end.