As much as your overall impression of the alpha-quality of the whole “develeopment environment” is correct, I wouldn’t be so quick as to assume this must induce that the language is underwhelming. And I don’t see any concrete arguments/critique regarding Luna as a language in your post!

Personally, I see Luna currently as an “early adopters”-stage technology, a.k.a. “bleeding edge”. Presence of the “bleeding” adjective in this phrase is telling. I totally admit it’s not “production ready”, but I strongly believe it’s noteworthy and has future, and I’m very excited to already have access to it, at this early phase of development. (More specifically, personally I believe it will be revolutionary.)

Academia and research gate are more like Facebook for academics where you post your papers instead of cute pictures of your cat. I don’t think there is much discussion about the papers there.

Source: I have an account on both websites.

I used to be a maths researcher, and would just like to point out that some of the people who define division by zero to mean infinity do it because they’re more interested in the geometric properties of the spaces that functions are defined on than the functions themselves. This is the reason for the Riemann sphere in complex analysis, where geometers really like compact spaces more than noncompact ones, so they’re fine with throwing away the field property of the complex numbers. The moment any of them need to compute things, however, they pick local coordinates where division by zero doesn’t happen and use the normal tools of analysis.

Thanks for laying this out and pointing out the issue with +/- Inf

Could you summarize here why +Inf is a good choice. As a practical man I approach this from the limit standpoint - usually when I end up with a situation like this it’s because the correct answer is +/- Inf and it depends on the context which one it should be. Here context means on which side of zero was my history of the denominator.

The issue is that the function 1/x has a discontinuity at 0. I was taught that this means 1/0 is “undefined”. IMO in code this means throw an exception.

In practical terms I end up adding a tiny number to the denominator (e.g. 1e-10) and continuing, but that implicitly means I’m biased to the positive side of line.

I think Pony’s approach is flat out wrong.

Just curious, but why isn’t 1/0=1? Would 1/0=Inf not require that infinity exists between 0 and 1?

I…that day might be sooner than we think! In fact, it could already be possible if we use this as a primitive.

Each description is a frame, or maybe better, a “section” of a scene. Then these are interpolated to create scenes transforming from one to another.

The best that I’ve found is to just ask them to explain some tech that’s listed on their resume. You’ll really quickly be able to tell if its something they understand or not.

My team does basic networking related stuff and my first question for anyone that lists experience with network protocols is to ask them to explain the difference between TCP and UDP. A surprising number of people really flounder on that despite listing 5+ years of implementing network protocols.

A sample of actual work expected of the prospective employee is fair. There are pros and cons to whether it should be given ahead of time or only shown there, but I lean towards giving it out in advance of the interview and having the candidate talk it through.

Note that this can be a hard sell, as it requires humility on the part of the individual and the institution. If your organization supports an e-commerce platform, you probably don’t get to quiz people on quicksort’s worst-case algorithmic complexity.

I recently went through a week of interviewing as the conclusion of the Triplebyte process, and I ended up enjoying 3 of the 4 interviews. There were going to be 5, but there was a scheduling issue on the company’s part. The one I didn’t enjoy involved white board coding. I’ll tell you about the other three.

To put all of this into perspective, I’m a junior engineer with no experience outside of internships, which I imagine puts me into the “relatively easy to interview” bucket, but maybe that’s just my perception.

The first one actually involved no coding whatsoever, which surprised me going in. Of the three technical interviews, two were systems design questions. Structured well, I enjoy these types of questions. Start with the high level description of what’s to be accomplished, come up with the initial design as if there was no load or tricky features to worry about, then add stresses to the problem. Higher volume. New features. New requirements. Dive into the parts that you understand well, talk about how you’d find the right answer for areas you don’t understand as deeply. The other question was a coding design question, centered around data structures and algorithms you’d use to implement a complex, non-distributed application.

The other two companies each had a design question as well, but each also included two coding questions. One company had a laptop prepared for me to use to code up a solution to the problem, and the other had me bring my own computer to solve the questions. In each case, the problem was solvable in an hour, including tests, but getting it to the point of being fully production ready wasn’t feasible, so there was room to stretch.

By the time I got to the fourth company and actually had to write code with a marker on a whiteboard I was shocked at how uncomfortable it felt in comparison. One of my interviews was pretty hostile, which didn’t help at all, but still, there are many, far better alternatives.

There are extensive resources to help with the evangelism side of things.

Are they not allowed to have their smart phones in these exams?

Generally they aren’t, as the networking would make it very easy to cheat.

In my experience, the good calculator apps on phones are simply emulators of physical calculators. There’s always wolfram alpha, but I haven’t seen a good native calculator app.

That being said, I enjoy using physical calculators much better than emulators. There’s something about a device which is designed for one purpose and doesn’t have to make compromises…

The new C++ features are execllent. The problem is the legacy of bad defaults and backward compatibility at all costs. This is probably the right decision overall, but it makes for an uglier language. I would also point out that you do pay for features that you do not use. Why? Well it might be used by code that you call, triggering weird behavour (e.g. const casts) and it makes tooling considerably hard to build (see Clang’s code complexity).

I have three comments:

1. I think it’s natural for any language to eventually buckle under the weight of Amdahl’s law, which in this case is making common idioms faster to write and recognize.

2. The author seems to simultaneously criticize modern C++ for having too many ways to do something (as in the vector insert example), but also criticizes modern C++ for attempting to make idioms that guide you towards a few ways to do something. In that sense, I’m not sure which he’s arguing for/against.

3. I agree having too many syntactical features/sugars can create cognitive overhead (one of my pain points with learning Haskell), and I assume that’s why the community has rallied behind guidelines like: https://github.com/isocpp/CppCoreGuidelines

1. There are scoping blocks where you can tell the compiler not to optimize things. e.g. #pragma optimize or function attributes

Though note that as of 7.1, GCC’s documentation describes __attribute__((optimize(...))) as “[to] be used for debugging purposes only…not suitable in production code” (and given that the corresponding pragma is described in terms of the attribute, the same would presumably apply to it as well).

It was extra interesting to me given I had a 28.8Kbps line with AOLHell. Enjoyed every song I got off that line given how long they took.

Far as cheating, I do know many games keep global state on server instead of client to avoid that kind of cheating. I know WoW particularly had boys that pesk into memory. I found them when designing a semi-automated, goldfarming operation. Never did it: just toying with how it would work technically, financially, etc.

I used to love Descent. Thanks for article. I’ll read it tonight.

Yeah, beamer / beamerposter is awesome! I just didn’t like the way the default themes / existing third-party themes looked, so I made my own.

You must have WRISTS OF STEEL.

Those Apple laptop keyboards, at least the newer ones, are the squishiest awfullest (IMO :) key feel EVER in the history of keyboards.

Only keyboard that eclipses them is the membrane keyboard of the Atari 400 (Which I blame for giving me the propensity to POUND THE FRACK out of the keys :)

Yes there is a GIL and parallelism is currently doable with c bindigs as in python, but there is ongoing work for multicore (and algebraic effects) support: https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june-2018-development-meeting-in-paris/2202

The work is still ongoing, and went through some iterations in the past few years, but the first bits should start landing by the end of the year

Although Ocaml ignored multicore a long time, the Standard ML community keeps doing interesting projects in that space. MultiMLton is one example.

Although GIL seems like a huge limitation, I’ve been actually quite impressed by how infime it was for most tasks (except if you do require huge throughput).

This is exactly the attitude that leads to maintainers’ burn outs.

Do realize this:

• Adding syntax variations is not done at the expense of performance, different volunteers are working on what’s more interesting to them.
• Python is not a product, and you’re not a paying customer, you don’t get to say “do this instead of that” because none of the volunteer maintainers owes you to produce a language for you. Just walking by and telling people what to do with their project is at the very least impolite.
• If you want something to happen in an open source project, volunteer to do it.

(None of this is aimed at you personally, I don’t know who you are. I’m dissecting an attitude that you’ve voiced, it’s just all too common.)

please stop adding these tiny edge case syntax variations and do something about performance.

There’s a better forum, and approach, to raise this point.

Have you tried Pypy? Have you tried running your code through Cython?

Have you read any of the zillion and one articles on improving your Python’s performance?

If the answer to any of these is “no” then IMO you lose the right to kvetch about Python’s performance.

And if Python really isn’t performant enough for you, why not use a language that’s closer to the metal like Rust or Go or C/C++?

I appreciate you writing the code, and I realize this only uses publicly available information, but it makes me minorly queasy.

(To emphasize, in the following text, I’m not really criticizing you, or this application specifically, just voicing my fears of what technology allows us to do)

This falls into that class of things where computers make it so much easier to violate privacy in spirit, if not law. If I were to do this by hand, it would be very tedious and time consuming, so I would probably not do it. But now, very easily I can develop a profile of sorts of a person - a stranger - without them knowing, or perhaps even wanting it.

Again, totally legal, but in my opinion in a gray zone like a surveillance state. Sure license plates are public information, but in the old days the KGB would have to physically tail you to figure out what you were upto, and they can’t tail all the dissidents.

But now, every police officer can collate information from license plate readers and track your movements and build a profile of you with minimal resources and oversight. Not technically a violation of privacy laws, but it sure as hell should be a violation of something.

I think the problem is that in C++ you end up having lots of code in header files, such as class members and templates. Then when you have dependencies between different source files and of course on the system headers, you end up including recursively lots of headers. That means a change in a single header file causes a cascading recompile which pretty much eliminates the benefits of incremental builds. Of course you have some crazy rules about includes (it’s in C though) to try to alleviate the problem.

I have to admit I don’t have firsthand experience in maintaining unity builds but seems like it’s worth it in larger projects.