skysight-inc/HackerNews huggingface dataset:
If one likes the article, as do I, there are couple of cool lisp projects related to the 6502 chip.

Brit Butler has written a 6502 emulator[0] and is now writting a NES emulator in lisp[1]

Henry baker wrote a compiler for a simple lisp named 'comfy' for the 6502 chip which intended to replace it's assembly in emacs lisp[2] which has been ported to common lisp[3]

[0]: https://github.com/redline6561/famiclom

[1]: https://github.com/redline6561/cl-6502

[2]: http://home.pipeline.com/~hbaker1/sigplannotices/sigcol03.pd...

[3]: https://github.com/jaoswald/cl-comfy-6502
To ensure a lot of creativity and passion I think the way to go is to add as little structure and hierarchy as possible.

So I suggest getting smart people in one place, with only informal ties (including informal mentorship, rather than a God-like status of advisor). And then degree based on publications (whether in one institute, or another). PhD thesis is an outdated thing from times, where people didn't publish much and it was (often) their first publication. We should move one and update workflow not believe blind in old one only because it was there for more than a century.
> Using debuggers and crash dumps to reason about your running program is not fast or interactive at all.

Says you. Using core dumps is a different kind of interactive. Rather than testing out what a program would do or could do (as in a REPL), you're iterating on theories of what it did do. It definitely takes getting used to, but I'm often much faster debugging (even non-fatal problems) from a core file than iterating with a step-through debugger or rerunning the program.

It also helps a lot when the tools within the core dump debugger are good -- you should be able to quickly dump what's relevant to your program (not just threads and stacks and individual objects).
Distressingly true. I despair that 20 years from now, absent an utterly wrenching change, we will all still be playing whack-a-mole with a seemingly infinite number of security bugs, many of monumental severity, all because we are unable to move away from our memory unsafe foundations.

And the endless supply of ignorant C/C++ programmers (of which I am not suggesting Damien is a member) who profess to management that they can easily write secure code does not help.
You run a farm in northern Vermont that raises turkeys. You can get a decent price for your birds by selling them locally but a much better price and can sell many more if you take them to the folk in Boston. There are no trucks to speak of, as they haven't been invented yet, so you gotta walk the 200 miles with such a boisterous load. There's no ice block big enough to keep your birds cold for that long of a journey and if there was, you couldn't pull it. The birds gotta get there alive, and they can only do 10 - 12 miles a day. You get a few neighboring farms to come with so you can watch each-other's birds and have some company on the 3 week on the road. Along the way you loose about 10% of your flock to foxes, rivers, robbers, and your own hunger. You arrive in Boston and get a fair price for your troubles, just enough to make the trip worth it. You spend a few days getting back to Vermont and by the time you get back it'll have been about a month on the road. You settle in for a rough winter. You're gonna do it all again next year. At least there's plenty of maple syrup.
For starters, moving the majority of the world's population uphill to escape the rising oceans is going to be kind of expensive.
Could it propagate from computer A with an infected Emacs to computer B with a clean Emacs, simply by opening a file saved by A on B? If so, I would be pretty surprised and impressed. If not, I don't think I would consider it a virus.
Anyone spot the bug? Of course

(AND ((...) (...) ...)))

should be

(AND (...) (...) ...)

I haven't run the generated code once, yet I can debug it: such is the power of the HN development environment.

The fix, of course, is to splice the comparison expressions into the AND:

`(let ,lets
(and
,@(loop for ... ))) ; comma splat, not comma
Honestly, sometimes I think that the best solution for fixing the security quagmire we're in would have been not by creating a new system programming language like Go, Nim, Rust, D or even reviving one of the Wirthian languages (though having them on the table is very much a good thing), but by creating a memory safe dialect of ANSI C, and perhaps standardize on a better string handling library.

In fact, such an effort was started at AT&T back in 2001. The language was named Cyclone [1]. It met its 1.0 release in 2006. It has since been abandoned. Which is a damn shame, because it looked like it had real potential.

Is C a primitive language? Yes. In fact, it's almost stupidly simple compared to most modern languages. But its greatest weakness also proves to be its greatest strength. The main cognitive overhead from using C is in its manual memory management model and certain gotchas in standard libraries. It being bare bones as it is (but not too much) also makes it surprisingly pleasant at times. I get the feeling that plenty of modern languages try too hard to be novel and, for all the freedom you get from not having to worry about anything below program logic itself, you still end up expending a lot of effort into complicated high-level patterns that are frequently interspersed with arcane PL theory.

But that's not even the main reason why something like Cyclone is much needed. No. It's that we've pretty much perfected a ton of our APIs, like POSIX, to work with C. It simply feels most natural to work with POSIX in plain C. FFIs and bindings vary, some of them like Nim's actually feel quite clumsy (otherwise Nim makes it absolutely trivial to create FFIs, which is great).

Finally, refactoring 30 years worth of code into Cyclone sounds far more realistic than rewriting the world in Rust.

[1] https://en.wikipedia.org/wiki/Cyclone_%28programming_languag...
There is also https://github.com/vimwiki/vimwiki for writing notes and https://github.com/vimoutliner/vimoutliner for outlining.
I don't think he wanted safety, he wanted fast runtimes. Is there any way to achieve speed without sacrificing safety? Ada?
> yet another syntax to learn! ++: \ ~> and so on...

Syntax? Not seeing any syntax here.
Just because C++ is a superset of C doesn't mean that all C++ features are in a way comparable to C (in compiling and at runtime).
A Billion Here, a Billion There: The Cost of Making a Drug Revisited
"Stapler theses" are common in some European countries, e.g. Germany and the Netherlands.
Places that are self aware enough to realise that no one really cares about your thesis anymore. It's all about your publication list.
To clarify, these are fat arrow functions, which uses a lexical `this`.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But he said "mainstream statically typed language". Is there one such with a REPL?

Would Scala be mainstream? OCaml or Haskell probably not.
Yes, I'd say Haskell and ML are mainstream languages by now.
Rubinius has been traditionally lagging behind in features (e.g. for a long time didn't implement 1.9 string encoding properly) and wasn't necessarily _that_ much faster.

Also, people that do want to work at the core of a language usually have knowledge of multiple and don't mind using C or any other implementation language.

Ruby stdlib is mostly written in Ruby, btw.

Still, with Rubinius 3.0 coming up, I'm very interested what is coming there.
Thankful for the amazing friends I've made this year, and the opportunities the universe has given me.

Thankful for my son's (and my) continued good health.

Thankful for all the resources I've come across, things that have made me better at what I do.
C is a great language, for fun I'm slowly working on my own highly C like langage - https://github.com/g-programming/glang.

Its basically C with Go like syntax, and a package system instead of headers. I aim to fully interop with existing C code and have no runtime requirements beyond what C has.

I'm not trying to go crazy with extra features over what C has though. An important part of what will make it work, is perfect interop with existing C code.

Yes I understand memory safety issues, but there is always a need for machine independent assembly languages. which C essentially is.
It is hard to be a good supervisor. Almost no supervisors have received any training in how to be a good supervisor and usually their only frame of reference is their own experiences as a student.

One of the things that makes being a good supervisor so hard is there is no one right way to do it as what each student needs is different. Some students need a lot of guidance and micromanagement, while others flourish when just pointed in the right general direction.

The one thing I would like to see is a limit on the number of students a supervisor can have at anyone time. Students need more than an hour a month with their supervisor. I would try and always spend an hour a day for my students (a lot of that time was group discussion), and at least an hour a week one-on-one time. I have to say I did this mostly for selfish reasons (I really enjoyed talking with my students about what they were doing), but I like to think they benefited from it too.
And what is the big picture? What is the effect on human beings? Fortunately, we have the data on this.

In the last 80 years, global deaths caused by climate (droughts, floods, hurricanes, cyclones, tornados, typhoons) have declined by 98%, all because people had cheap, reliable energy provided by fossil fuels.

Source: http://www.emdat.be/advanced_search/index.html - click on "Natural," and add subgroups "Climatological," "Meteorological," "Hydrological."

Because I prefer being alive, I'd much rather live in a warmer world (or one with weather that has changed is some unnatural way) than to lose the cheap, plentiful sources of energy that serve to protect me from an inherently dangerous climate.
Let's just say that it's not C's fault. It's just that C is particularly well suited for creating security problems. The base semantics is dangerous, the undefined behaviors are lurking everywhere, and the compilers writers don't care ("it's the user fault if they go in undefined behavior that we put everywhere, and they'd better says thank you that we didn't ring their phone while they were in the bath the last time they did an integer multiplication without checking overflow, because the spec said we could have done it").

Sometimes I think the ebola crisis is created by a GCC developer. "I'm sorry for those people, but I was entitled to it, that guy there dereferenced a wild pointer, I could have cured cancer instead, but no".
Hubble Uncovers a Baby Galaxy in a Grown-Up Universe (2004)
Why? It's generalisation of binary operator <= to many arguments. Works as well with <, >, >=.
This could be solved with a simple fuze or lockout bit that is set. "if you enable this mode you void your warranty, your drive will be marked as such"
Well, we can debate how mainstream Haskell is, but especially if you mean ML in the sense that does not include also OCaml, then ML definitely is not a mainstream language.
Ask HN: Have a hard time working at home. Co-working an alternative?
Hi, friends.

I'm funemployed at the moment and it feels like I can't work at home at all. I either get super distracted or tired or just run-down and dejected.

Do others in similar situation ever experiment with co-working spaces? Do they work out?
Which means it could be done, but the relational operators (any one of which could be the leftmost constituent) have to all be defined as macros which analyze the rest of the expression with alternative evaluation rules.
Thanks for a great document.

I think in the future all protocol diagrams should use colored lego blocks. That was fantastic.
A short history of typography [video]
Nature and the opportunity to explore it.
It's very restrictive, but the compiler is unbelievably fast because of that.

I'm not going to argue that Pascal is somehow superior to C, it's far more limited, but there's lessons here to be learned on how to make a compiler rip through code.
I think it's a shame (and painful) how the major Unices have all significantly diverged on things like event handling, I/O multiplexing and file system watching.

I find the BSD kqueue(2) interface to be much more elegant than any of Linux's *fd() functions or epoll(7). On the other hand, Linux's inotify(7) is, I find, cleaner to use for file system event notifications than kqueue(2). But then there's also fanotify(7) on Linux, which seems to have sort of been neglected since its initial hype. Then OS X has FSEvents.

I guess this is why one may need libraries like libevent and libuv.
Strictly speaking, you are correct. But saying C is not at fault is like finding the trivial solution to a polynomial -- it is correct but not very useful.

No, C is not at fault. The programmers are at fault. But it is prudent to ask, when some of the world's foremost programmers produce an apparently limitless number of CVEs as they do, whether they could use some help from the language. If the answer is yes, we should recognize that such help cannot come from C.
From the other comments, I feel more alone in this camp than I thought. I've taken the stance to not even consider a user, browsing sites I develop, with javascript off. It's such an integral part of the web by now, and without it, interactivity doesn't really exist.

Is it really so prevalent to browse without JS (I doubt the casual user would do that, since they're probably not even aware that JS exists)?

The only reason I'd care about displaying content without JS, is specifically for crawlers.
Sorry, I realised I sounded negative. Nothing against you, it's just my private opinion.

It's not about performance, but about one more incidental step when reading the code. Small cost, but it's there.
Borland used to tout the virtues of their single-pass C/C++ compiler too, even as far back as version 2.0.

Most modern C compilers have used an integrated preprocessor for quite some time, and Clang/LLVM can emit machine code directly without going through a separate assembler.
I highly recommend a coworking space without-a-doubt. I personally don't find the same issues with working at home, but coworking spaces have a lot of benefits including; fast internet, access to printers/scanners/faxes, conference rooms, private booths, amenities (showers, mouthwash, razors), foosball/ping pong tables, coffee/tea, snacks, events and more.

I just did a two month stint at WeWork in Seattle and I must say, as far as coworking spaces go, WeWork was the most enjoyable. You got all of the aforementioned benefits and on-top of that, free beer. People from other startups and businesses would regularly socialise, play foosball together and events were happening all of the time.

If home life is getting you down, definitely consider a coworking space as they are not even that expensive considering the benefits and support that you get.
They write:

"It is the 2013th year in the Common Era at the moment of this writing and you might think that people should have came up with something better in terms of signal handling at this time. The truth is that they did. It is just not that well known yet due to a huge momentum of outdated information still overflowing the Internet."

Then they talk about kqueue.

The above paragraph emphasizes how much Unix programming still relies on old ideas.

Likewise, sockets are an old idea, and newer libraries, such as ZeroMQ, do a lot to fix the old problems. ZeroMQ is often described as "Sockets on steroids". It implements a lot of patterns that Unix itself does not give us:

"It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. "

But I am left wondering, what would the world of programming be like if we had a new operating system that incorporated some of the new ideas and patterns that have developed over the last 25 years? Instead of depending on libraries, would we not be better off if we had an OS built around these newer ideas?
the python interpreter, CPython, is uh, written in C. CRuby, too.

if C was so insecure, you would expect that interpreting python would be just as "insecure" as writing C.
Channels look pretty awesome, how do they work?
In short, the OP's need for capital is the product of her decision to manage her vision based on "bigger is better."

Are we sure this is her vision or that of her investors? The need for VC to generate "outliers" is wrecking a lot of really good businesses.
I want to take this and go further. Have a mini linux distro running on my drives :D
Hapi Thanksgiving; It is about systems of nodes scaling, not node scaling
Greentech center
one of the best things C has to offer was omitted herein - the preprocessor ;-)
Org mode files are plain text so your friends will see beautifully organized text files.
"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

- Joe Armstrong

One could argue, easily, this is true for many of the popular garbage collected languages. It is certainly why I do not care for them. It is also why I do not care for some of the popular OS's, or most of the popular "software solutions". It is the unwanted delivery of the kitchen sink when all I want is a glass of water.

The OP says he's frustrated with C "because it seems to be trying (with limited success) to move to being a higher level language. There are times when I really do want a "thin layer
over assembly", and C seems to have evolved to a place where that is no longer possible."

"seems to have evolved"

Some of my favorite programs that continue to work reliably, year after year, are written in what I guess some would call "primitive," K&R-like C and with little need for "the" standard libraries. I am not an expert C programmer, but I have no complaints when reading and editing this "primitive" C. I have seen others complain about it in forums.

One of my favorite source code comments is in the netcat source where the author says he's going to write the program as if he's writing in assembly. In my mind C should be just a thin layer over assembly. Essentially, to me, it should be a kind of "shorthand" for writing assembly. (That implies the author should think as if he's writing assembly. And C just takes away the drudgery of actually typing out all those lines of assembly instructions.) Now, that is just my opinion. I am not an expert C programmer. I know nothing.
The best optimizing compilers are C and C++ compilers (as far as I know), perhaps Fortran but even that is getting more esoteric. I think that's why the assembly idea persists.
Go has the fastest build/run cycle I've seen. You can usually compile compile to a binary and run it quicker than it takes a python runtime to start up. It's totally viable to use Go as a scripting language while compiling to binaries from source.
Yes that is what he is been saying.
http://sp.parallels.com/products/parallels-containers-window..., not free but around for a while
I agree with this, but I also feel torn by it. A PhD is one of the few opportunities in academia to do true, unconstrained, open ended research. With no hard deadline, no constant "publish or perish" pressure, students can take a bit more risk and look a bit further over the event horizon than other researchers who have to make every bit of research count towards a publication.

Students don't realise it because they are so focused on getting through, but this opportunity doesn't come again. You are suggesting they should jump straight on to the slavish publication treadmill that academics already spend their lives on. In a pragmatic sense it's good advice, but it's also failing to make the most of the opportunity presented by a PhD.

Maybe I'm just idealistic.
"C has the fastest development interactivity of any mainstream statically typed language."

I wonder if this statement is true since the invention of Go. A very fast compile was one of the design goals of Go, and its authors could afford luxuries (esp. In terms of memory use and object file size) that were unthinkable in the days of C. For example, IIRC object files contain the compiled code of their source plus the top hierarchy of modules called.

People have mentioned that changing a .h file in a large C project could trigger a lengthy recompile. AFAIK, Go minimizes this problem, so if the hype is correct there should be lots of projects where similar situations will be handled faster in Go.

My own empirical experience is very limited. I can confirm that Go compiles much faster than Java for my code, but that will surprise no one and it doesn't help us compare with C.

Does anybody have more tangible data regarding Go's alleged speed demon nature esp. as compared to C when compiled with e.g. VS or gcc?
How the Bitcoin Protocol Really Works
Wow... programming in Lisp is already not that mainstream... and on top of it, for the NES?

Impressive.

I so want to start learning to program in NES now. Not really in Lisp as I would like to learning curve to be gentler, but this article definitely sparked my interest into learning one of the devices I used most during my childhood.

Great work!
You said you were just trying to finish up online.

Arizona state seems to have a good selection of programs.
http://asuonline.asu.edu/online-degree-programs/graduate

NOTE: If you decide to go in for a tech degree ABET accreditation is the standard for tech accreditation, and will allow you to transfer courses between other ABET schools.
Build a Reddit Bot Part 3: Automate Your Bot
go has a very, very fast build cycle, partly due to the language and partly due to conventions (the standard preprocessor in C is absent in go). But, that might not have been on Damien's radar when he wrote this.

And, go is built by some of the same people who built C for some of the same purposes (plus some new ones, like concurrency and networks), so it's arguably a "better C", and probably prioritizes some of the same goals. Simplicity and small surface core language area, in particular, but removes some of the dangerous aspects of C (which might be a problem for something performance-oriented, since well-written C is still faster than well-written go for most tasks, and may always be).

But, as you note, if you don't have to build, the cycle is even faster. I still consider a compile phase a slowdown over dynamic languages that don't compile.

Then again, so many people have introduced "compile" like stages into their dynamic process (SASS, LESS, test coverage checks, etc.). It may be difficult to completely get away from a compile like stage in any app of significant size.

Anyway, a large project in go is faster to compile than a large project in C, in my experience, but my experience is exceedingly limited.
"I always have it in the back of my head that I want to make a slightly better C. Just to clean up some of the rough edges and fix some of the more egregious problems."

This is called Go. Brought to you by the same people who gave you C.
Show HN: Skimming HN, PH, BetaList, AngelList, CrunchBase &Kickstarter Made Easy
"One could argue, easily, this is true for many of the popular garbage collected languages [...] It is the unwanted delivery of the kitchen sink when all I want is a glass of water."
Exactly. It's basically like forcing people to throw all their garbage on the ground and then forcing them to pay for the garbage men who collect said garbage. It would be easier for everyone to just go to a bin and dispose of the trash themselves.
And yet on OSX Yosemite:

$ git --version
git version 1.9.3 (Apple Git-50)
C is a great language but have you tried go? Feels very c like with a lot of very nice conveniences.