The evolution of Lua - <AUTHOR> http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf# <comment><USER2> One serious thing Lua is still missing is native Unicode support (correct me if I am wrong).

When I discovered Lua the first time I was enthusiastic. The JIT is so fast, and everything seems to be fine. But missing Unicode is a big disadvantage for Lua. Unicode is a must to have for modern languages. It makes things so much easier when you know you don't have to convert any fonts because they are all presentable in Unicode.

<comment><USER3> After having worked with Ruby 1.8 (no unicode support in String) and Ruby 1.9 (added unicode) rather extensively, as well as C/Obj-C and a variety of other languages with varying ideas on Unicode support, I am of the opinion that Lua has the right approach. If your built-in string type does not account for encodings, you can always build one on top of it that does. If, on the other hand, your built-in type has to carry the constant burden of encoding information, you'll never get away from that (indeed, I've been talking with ruby-core about adding back a string-like library with no encoding information in Ruby 2.0).

<comment><USER2> As long as you handle usual letters it is no problem to miss Unicode.

How nice Unicode is I always realize when I copy and paste some foreign text from somewhere into Emacs or Racket Scheme and everything works just fine.

<comment><USER4> What he's trying to say is that Lua's strings are capable of storing Unicode characters (they're "8-bit clean"), but that Lua's string manipulation functions aren't Unicode-aware. If you want to paste Unicode characters into a string and print it later, Lua can handle it. If you want to do a pattern match on a Unicode string, you need to bring your own pattern matcher.

</comment></comment></comment></comment><comment><USER5> As someone who values simplicity, minimalism, portability, and good performance, Lua is a constant source of inspiration to me. I frequently look at its design for ideas.

<comment><USER6> Please say more. What are some inspiring things you've found in Lua's design?

<comment><USER5> I'm having trouble answering your question eloquently. I'll think about it more and hopefully write a blog post about it before long.

<comment><USER6> Please do. I'd like to read it.

It seems to me the outstanding feature of Lua's design history is its designers' determination to make the core ever simpler and more general. That takes vision and courage over a long period of time. What emerged is truly interesting and inspiring (much more so than cobbled languages that grow only by accretion of features) and is likely to grow in importance.

<comment><USER5> Yes, that is very much how I feel about it. They boil every concept down into its purest essence, and always avoid having two abstractions when one will do. Other languages grow when they need new features, Lua refines.

But in a blog entry I'd like to address several of Lua's core abstractions and how they are cleaner and more general than competing languages. For example, the Lua thread data structure encapsulates all necessary state for a thread, but is general enough that it actually allows for multiple thread execution models. By default only coroutines are provided (which use the thread data structure). But you can implement lua_lock()/lua_unlock() to have a Python- like model with preemptive threads and a GIL. Or you can use lua_sethook() to implement a "green thread" model where multiple pre-emptive Lua threads run inside a single OS thread.

Three options for threading models (probably more if you dig in), one core abstraction and implementation. Remarkable!

<comment><USER6> I wonder what examples one could dream up where manipulating that thread data structure in an application-specific way would be a win. i.e. some kind of domain-specific threading model.

<comment><USER5> Manipulating the thread data structure _directly_ would violate the encapsulation of Lua and prevent you from being portable to eg. LuaJIT. But there are still lots of opportunities for building custom threading models; see:

[http://kotisivu.dnainternet.net/askok/bin/lanes/comparison.h...](http://kotisivu.dnainternet.net/askok/bin/lanes/comparison.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> If you enjoyed this, you will probably also like the same author's "The Novelties of Lua 5.2"[1].

[1] <http://www.inf.puc-rio.br/~roberto/talks/novelties-5.2.pdf>

<comment><USER6> I absolutely love how they are making such major changes as late as version 5.2. I also love that one of them is goto.

Lua is terribly impressive. Someone needs to make a transpiled language targeting Lua and JS. They're semantically close enough that this might not be too complex. If it worked well, it would be an interesting alternative to Node.js, since you could write the server-side for Lua coroutines and so on. Not to mention its performance.

<comment><USER8> Lua does have lots of metaprogramming that js lacks, and adding into js could be tricky since you'd essentially have to rewrite existing js code into new code that allows this.

However, the grammar rules are fairly convertible. I've converted a parser that normally targeted javascript, to target lua instead (it was for a project to convert lua code into json).

<comment><USER6> The easy way would be to make a language that compiles to the semantic intersection of Lua and JS; that is, don't expose things that you can't easily generate both Lua and JS for. Such a subset would cover approximately everything I for one want to do in JS anyway.

You could make it easy to take advantage of Lua-only features like metaprogramming by denoting them server-side only. You'd have to do that to get coroutine support anyway.

The idea seems so exciting and obvious that I wish I had time to do it. Lua doesn't seem to be used much for server apps, though. Why? Are there technical limitations that make it unsuitable, or is it just that it hasn't been exploited yet?

Another thing I'd like to know, given how embeddable Lua is, is whether one could embed it as a browser plugin and then get the power of Lua client-side as well. Obviously, one wouldn't demand this of users, but it would be a pretty sweet option to offer: "install this little plugin to make the program faster and more responsive".

One final thought. I wish Google had gone with Lua instead of making Dart. Lua is basically JS done right. Seems to me they could have built a compelling case around it.

<comment><USER9> I had this idea too -- I wanted to share code between command line clients, web clients and servers. Having a language that compiled to both Lua and JavaScript seemed eminently doable because their semantics are quite similar (and even the syntax is pretty similar).

The thing is that Node.js has kind of solved this now, as long as you can put up with JS. JS is ugly, but Lua is also not without its annoyances (1 indexing, and to me begin/end is a big pain over {}).

v8 probably doesn't perform as well as LuaJIT, but it's by far good enough for most purposes.

JS is ugly, but it's even uglier to have to worry about the transliteration to 2 different languages. 99% of it will work, but it won't be "write once run anywhere" -- we all know what a fallacy that is.

But since CoffeeScript became popular, I wonder how easy it would be to port a subset of CoffeeScript or a slight alteration of CoffeeScript to Lua (or even Python). I've seen MoonScript (<http://moonscript.org/>)

A third thing is that libraries would be totally different. You would have to bind the same libraries to JS and Lua to get any kind of portability. In the end I think that's not worth it for any project.

There's a node.js style API for Lua, but again it won't be "write once run anywhere".

<https://github.com/luvit/luvit>

A last motivation was the C API of Lua, which is nice and simple and portable. It seems way easier to work with that extending Node, which is tying your code to a particular JS implementation.

<comment><USER6> I knew someone else had to be thinking about this!

 _The thing is that Node.js has kind of solved this now_

The question is whether Lua's advantages over JS (more powerful, faster, excellent FFI) can be exploited server-side to create significant value beyond Node.js. If the answer is no, the idea is pointless.

 _Lua is also not without its annoyances (1 indexing, and to me begin/end is a big pain over {})._

1-indexing is the sort of thing that could screw up cross-compilation. That's a worry. Begin/end - I agree with you, but don't have to deal with it because I write my JS in Lisp. Personally what I have in mind is a Lisp that compiles to JS and Lua.

 _it's even uglier to have to worry about the transliteration to 2 different languages._

Right. The idea lives or dies on how bad the semantic delta is between Lua and JS (in some subset of both languages chosen for compatibility). The impedance mismatch has to be really small to make it worthwhile. It's not obvious if that's the case.

 _But since CoffeeScript became popular_

I don't see how the impedance mismatch argument is any different for CoffeeScript/Lua than it is for JS/Lua.

 _A third thing is that libraries would be totally different. You would have to bind the same libraries to JS and Lua to get any kind of portability. In the end I think that's not worth it for any project._

Projects that don't depend heavily on client-side JS libraries wouldn't suffer too much.

 _There's a node.js style API for Lua, but again it won't be "write once run anywhere"._

I don't find it very interesting, since you can just use Node.js for that style. The goal here isn't to cross-compile to Lua and Node.js. It's to cross- compile to Lua on the server and JS in the browser.

 _A last motivation was the C API of Lua_

Right, that's potentially a big deal. For example, you could run your server app in Lua embedded in Nginx. I know people have been working on this.

<comment><USER9> Yup. For semantics, I'm sure you can find some corner cases where closures behave differently, and the prototypal inheritance also probably differs in some significant ways. I haven't thought about it in awhile.

I'm not concerned too much about performance because I don't think Python is too slow 99% of the time, and node.js is faster than Python.

So personally I don't think there is a strong motivation anymore, but if anyone tackles it I'll try it out for sure :)

Another motivation I forgot to mention was sandboxing. Actually that was motivation for the same idea with Python <-> Lua. I have a ton of of Python code lying around. A lot of it can be extended by the user. I want to expose some of these things as network services, but it is hilariously insecure to accept Python code from users in any way. I also have a bunch of coworkers who already know Python. So it would be cool if I could somehow have a sandboxed Python interpreter (this has been talked about MANY times on pyhon-dev, etc.; not doable with CPython).

One way to get that is to try to compile Python to the Lua byte code (not portable across versions), or to Lua source code. I think the semantic delta is even higher, so it's probably not going to work very well. You would end up halfway to writing a Python interpreter in Lua (e.g. semantics of dictionaries)

PyPy has some sandboxing I hear but it's too heavyweight/early right now.

Lua is really nice. I want to use it, and has advantages over Python and JS, but I can't seem to justify it for any project. The network effects of tools/libraries in Python and JS always win out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> One thing I didn't like after a quick look at Lua is that all variables are global by default.

        j = 10         -- global variable
        local i = 1    -- local variable

( from <http://www.lua.org/pil/4.2.html> )

Same with functions. To declare a function that is restricted to the local scope, you must explicitly use "local":

        local f = function (...)
          ...
        end

Can any Lua aficionados explain why this is the case? Surely a better design would be for variables to have local scope by default, and to require an explicit "global" prefix to be globally visible? Does this ever cause problems in real-world code?

<comment><USER11> This discussion comes up on the mailing list occasionally.

Well, the first answer to why we have global by default is history. Lua started out as a data description where global by default was a convenience.

Local by default doesn't work so well either with nested scopes. Suppose we do have local by default and then consider this code:

      x = 0
      function a()
        x = 1
        function b()
          print(x)
        end
      end

It is impossible to refer to a's x variable. This makes it harder to return a simple counter function, for example. This is regular Lua:

      function create_counter(initial_val)
        local count = initial_val or 0
        local print_count = function() print (count) end
        local increment = function() count = count + 1 end
        return print_count, increment
      end

Every time you call make_counter() you get a new pair of functions with their own internal count variable.

See also PEP 3104 for more: <http://www.python.org/dev/peps/pep-3104/>

<comment><USER12>
        Every time you call make_counter() ...

create_counter()

If, local was the default, you would have:

        function create_counter(initial_val)
          count = initial_val or 0
          print_count = function() print (global count) end
          increment = function() global count = global count + 1 end
          return print_count, increment
        end

Something like that, it doesn't seem that much worse. Also, why wouldn't the print_count function inherit the scope of the containing context so you wouldn't even have to have the "global" keyword.

        function create_counter(initial_val)
          count = initial_val or 0
          print_count = function() print (count) end
          increment = function() count = count + 1 end
          return print_count, increment
        end

<comment><USER11>
      ... create_counter() ...

That's what I get for writing code on a small phone screen. :-)

        function create_counter(initial_val)
          count = initial_val or 0
          print_count = function() print (global count) end
          increment = function() global count = global count + 1 end
          return print_count, increment
        end

You might not want to use 'global', because that implies global scope. And in this case, this is not what was intended. For Python, keywords like 'outer' or 'nonlocal' were proposed.

All in all, I'd be OK with 'nothing by default', but I'm also OK with global by default as it is now. If accidental creation of globals is a problem I can use the 'strict' module.

        function create_counter(initial_val)
          count = initial_val or 0
          print_count = function() print (count) end
          increment = function() count = count + 1 end
          return print_count, increment
        end

If local was the default, wouldn't the assignment to count in increment() create a new local variable (which is then discarded)?

</comment></comment></comment></comment><comment><USER13> I was surprised to learn that coroutines were new in 5.0 until I also learned that 5.0 was released in 2003.

</comment><comment><USER14> Interesting for me to know that Lua has been used seriously for game development. What are the main limitations?, how come people aren't developing more in Corona rather than straight objectiveC. I'm guessing the Corona environment itself is the limitation?.

<comment><USER15> Lua is pretty minimalistic. There are few batteries included. The standard library is very basic. There is no native object system, though implementing one is trivial.

That said, I friggin love Lua for its flexibility and transparency. Once you grok its few basic mechanisms, everything else just falls in place. In contrast, understanding Ruby or Python is a lot more difficult since the languages themselves are a lot more complex.

In fact, if I were to teach programming, I would teach it using Lua. Implementing your own object system is increadibly instructive. Learning about coroutines and lambdas is, too. And Lua is still small enough to just read its source when in doubt. It's bytecode consists of just a few dozen instructions.

Honestly, Lua is a marvellous language and I just love to use it!

<comment><USER16> >In fact, if I were to teach programming, I would teach it using Lua. Implementing your own object system is increadibly instructive. Learning about coroutines and lambdas is, too. And Lua is still small enough to just read its source when in doubt. It's bytecode consists of just a few dozen instructions.

If these things appeal to you check out lisp (clojure is my personal recommendation)

<comment><USER11> If I were using a Lisp these days, I'd really miss the Lua table.

Lisp is built around cons cells and the linked list. But it has seperate containers of various types.

Lua is built around the Lua table, which can function as a list, array, and dictionary/hash table. You can then build any other data structure from tables easily. With a metatable, you then also get read-only tables, objects and classes, and more.

Now if someone were to design a modern Lisp based around tables...

<comment><USER16> >Now if someone were to design a modern Lisp based around tables...

Check out clojure - advanced data structures/primitives + immutability(functional programming)

<comment><USER11> I don't really want multiple data structure primatives though, just the one. And have the language built up around it.

I have been mulling over better support for immutable data structures in Lua, but I haven't figured out a good and clean design yet.

</comment></comment></comment></comment></comment></comment><comment><USER17> I have such a strange love for Lua. It was one of the first languages that I learned and used to program homebrew for the PSP. It's really where my journey as a programmer began and was the first language that I programmed with for fun. I don't think you can ever stop loving the first language you got your hands dirty with.

<comment><USER18> Unless of course it's C++

</personalopinionwithouttryingtoinstigatereligouswar>

<comment><USER19> Technically, my first programming language was C++, and I really don't love it. ;) But that might not count: I actually started with a _markup_ language, HTML, which I use daily.

</sameDisclaimer>

</comment></comment></comment><comment><USER20> If you want to tinker with Lua, Codea on the iPad lets you code in it and create little iPad apps (for your own enjoyment).

</comment><comment><USER21> Warning: this links to a PDF.

<comment><USER22> Usually PDFs get reposted to Scribd or a similar service - it's somewhat unusual that it wasn't in this case.

<comment><USER23> Strange but much appreciated!

<comment><USER24> Perhaps the trailing octothorpe (#) threw off the HN functionality that does this. Noteworthy.</comment></comment></comment></comment>


Let's win together Virgin #VOOM and contribute to a better society - <AUTHOR> https://www.vmbvoom.com/pitches/jobs-without-borders <comment><AUTHOR> We are so excited ! Transformify is taking part in Virgin #VOOM, UK and Ireland's most valuable competition.

Why is This Competition so Important for Us?

The participation in Virgin #VOOM will increase the public interest in the social cause of Transformify. More businesses will be interested in transforming regular jobs into remote jobs and more people who need a job will get a remote job.

Ready to #VOOM? Vote for Transformify by clicking below: [https://www.vmbvoom.com/pitches/jobs-without- borders](https://www.vmbvoom.com/pitches/jobs-without-borders)</comment>


Is Artificial Intelligence going to take over the world? - <AUTHOR> https://qnswer.com/questions/read/Is-Artificial-Intelligence-going-to-take-over-the-world <comment><AUTHOR> I think this does start to show that non tech people are starting to hear about AI quite a bit and the Hollywood movie plots and are starting to tie them together and ask a few questions. Somewhat humorous though, but what can we really say!

</comment><comment> a-fried-egg Depends. If it's built without boundary conditions, it'll go everywhere and do anything since we'd no longer be able to control it and understand what its doing on the backend.</comment>


FatELF is no more.  Linux developer community owned Ryan Gordon. - <AUTHOR> http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&date=2009-11-03&time=19-08-04 <comment><USER2> As someone who has actually built binaries to run across multiple distros, this doesn't address even half the issues. Very few people are concerned about binaries that run on more than one architecture when distributing binaries that run on more than one distro is a harder problem.

This solution doesn't solve the hard problems, but solves an easy one in an uninspired fashion. Rejecting these patches wasn't a case of holding back innovation, but merely holding back solutions that more experienced developers felt were not appropriate for the platform.

There was a good reason for that and playing armchair critic after reading a sympathetic story from a developer who is understandably hurt after getting his feature rejected just doesn't help anyone.

The kernel is more well managed than most people give it credit for, and it's exactly because of this that hacky incremental solutions get rejected, even when they might legitimately produce a small benefit. Eventually the overall solution to the problem FatElf is trying to solve is going to have to be something different.

I feel sorry for the developer, no one likes getting a feature rejected. But it was the wrong solution and the technical merits must trump other concerns.

<comment><USER3> _But it was the wrong solution and the technical merits must trump other concerns._

Your post is very long, but I'm curious to hear _why_ universal binaries are the wrong solution?

On the Mac, it's the cornerstone of their transparent multi-architecture support.

Apple (and previously NeXT) inarguably demonstrated its value and ease-of-use over the past 20 years. Producing x86-32, x86-64, armv6, armv7, and PPC binaries all from the same source code -- and having them work the first time -- is incredibly simple on Mac OS X.

NeXTSTEP (the OS) ran on 68k, x86, PA-RISC, and Sparc processors, and it was equally easy to build software that ran on those machines.

<comment><USER2> OS X has a unified set of libraries to work with, Linux does not. This means the problem is much more complex. Creating a binary that simply runs on different distributions all on the _same_ architecture is a fundamentally hard problem. Simply stacking together binaries for multiple architectures together doesn't result in a universal binary. At worst you have to stack together different binaries for different combinations of libraries and different architectures and if you assume even just the latest versions only of the top 5 distributions running on the top 5 supported architectures for Linux you may well end up with 25 different binaries that FatELF would glue together resulting in every program being a cool 2500% larger. This is unacceptable in terms of space and unacceptable in that it still isn't universal after all that as not all arches are supported and you only get the latest versions of the popular distros.

This is why I claim FatELF does not solve the hard problems with universal binaries. The only thing it might solve is someone could distribute a binary for a particular distro that could run on multiple architectures for that distro, but they can already do this with shell scripts and this is an uncommon case and most people would just rather download and store the one appropriate binary.

(This last is easy with a functional package management system. You should keep in mind that OS X does not have a functional complete package management scheme that allows users to discover, acquire and manage 3rd party packages. Not all Linux distros do either, but those that do are less in need of universal binaries. This is really a separate discussion though that gets to the heart of how software ought to be distributed. There are many blind spots in OS X's software strategy some of which Sparkle is making a half-baked (not sparkle's fault) attempt to fix.)[1]

At the end of the day you can't simply assume that the solution for OS X is the right one for Linux and you'd make a much bigger mistake assuming that the developers who rejected these patches weren't both entirely aware of OS X's excellent use of this technique and were doing this for anything but sound technical reasons. (I.E. It's not just NIH, they would happily adopt this if this was a reasonable solution to Linux's unique[2] challenges with binary compatibility across "Linux")

[1] There are many things wrong with this and most package management systems do not incorporate third party repos/packages as well as they should, which IMO is the larger problem here. Not that corporations should have to manage repos for every distro, but that becomes a separate mess.

[2] Perhaps read as special.

Aside #432: As you noticed my replies can often be anything but concise. I apologize if that makes things hard to follow.

</comment></comment></comment><comment><USER4> This is sort of an interesting counterpoint to the whole "Open source forsters innovation" meme open source types love to throw out.

Open source can foster innovation, as long as ego's don't get in the way. Sadly there are a lot of ego's involved in open source.

NB: I think the idea of fatelf is a very good one. Mainly for binary applications though. Which OSS guys tend to dislike.

<comment><USER5> He could write the patch, he could try it and persuade mainline kernel (and glibc and gcc, and...) developers to include it. If the feature is really that useful, he can even maintain it separately, or some Linux distribution can. All of which would be impossible with closed software. Innovation in the oss way, sadly, means, that there are lots of ideas, and most of them thrown out.

Hostile reaction from kernel developers? Well, maybe it's little sad, they could trash the patch more politely or something, but eventually they have to. Fatelf adds stuff to kernel, glibc and few other parts of system without really solving much. He could try something with binfmt_misc and completely userspace, not add junk into kernel and glibc itself. (With junk I mean something unnecessary that can be done in userspace. (or not at all))

<comment><USER6> > without really solving much

On a German Linux news site (prolinux.de), a commercial Linux game developer -- Ankh2, IIRC -- once commented that they could not get their game running on about 2-3% of their customers' Linux computers, despite their best efforts.

I dunno whether FatElf would have solved problems like this in the long run, but there are problems. You may not be affected but this doesn't mean others aren't.

<comment><USER5> No, I don't think it will solve this kind of problem. It can do the only thing: pack two different binaries into one file, which is also binary, and the kernel has some extra logic to choose, so it is 'transparent'. While this makes some thing easier (if you really don't know whether you want to download that strange 'i386' file or even stranger 'x86_64' file, you download one larger 'fatelf' containing both), it doesn't solve the real problems. Distributions spent quite a lot of effort to make both 32 and 64-bit binaries run on a single system. This is just a hack, nothing more. And it can make the mess even worse. Do I have x86_64 binary in this? Is there a correct elf packed somewhere? How do I know.

<comment><USER3> _This is just a hack, nothing more._

Well, it is the cornerstone of Apple's highly successful and entirely transparent transition from PPC to x86, including drag-and-drop application installation/uninstallation. Couple it with Apple's compiler drivers and well- designed multi-architecture SDKs, and it becomes dead-simple to support multiple architectures and OS releases. Just build your binaries with -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk

It also supports Apple's transparent selection of armv7/armv6 binaries on the iPhone 3GS.

I'd say it's pretty useful, and not really a hack at all.

The only arguments I've heard against it involve package managers and shell scripts, which demonstrates such a remarkable lack of understanding of ease of use and user behavior that I don't even know where to start, other than to say: This is why popular adoption of Linux on the desktop is not going to happen any time soon.

<comment><USER5> Apple, on the other hand, doesn't have anything even close to a package manager, for example. Also, "transition". There is no transition for Linux. Nobody is really interested in completely phasing out an old platform and port everything to a completely different new one, which is what Apple did. Apple's Mac OS has rather limited hardware support, in fact you shouldn't even try to run it on anything that doesn't have Apple sticker. Linux is expected to run everywhere on everything.

I can't see _any_ possible difference for the fatelf solution and the package manager and scripts solution for an end user. It's not about the ease of use, because there is no difference.

<comment><USER3> _Also, "transition". There is no transition for Linux._

ARM netbooks? That said, part of why there's no 'transition' is that providing easy-to-use (for consumers) third-party application binaries is this side of impossible given the lack of stable APIs across distributions and releases.

 _I can't see any possible difference for the fatelf solution and the package manager and scripts solution for an end user. It's not about the ease of use, because there is no difference._

I can drag-install any third-party application I want to download, and I can expect it to work on any machine. The author doesn't have to wait to get it packaged by a distribution, set up a package repository, etc. I don't have to wait 3-12 months for the latest version.

I can drag it over to my PPC iMac, and it'll work there, too.

How is that not 'different'?

<comment><USER5> ARM netbook with its limited SSD disk space is really a great usecase for something that makes binaries two (three, or even more) times larger, while I need only the binary for ARM. (Yeah, it's not that much for > 100G HDD, still, it can be quite a lot for 4 or 8G SSD. Especially when it is completely useless for the computer.)

It's not different, because fatelf doesn't help with this. You can still make some tiny wrapper, and have completely the same thing. Vendor still have to make a package fit for your system, for the set of libraries that you have, correct versions of them, and so on. Yes, Mac OS X system has two or three recent different versions, mostly mutually compatible. If you were trying to make a package for only one or two mostly compatible Linux distributions and one or two of their versions, then it would be also that easy. But it is not, and fatelf doesn't make any difference.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Look on the bright side: they saved him a lot of time. Usually the Linux developers tell you to redesign and rewrite your patch from scratch. :-/

</comment><comment><USER8> FatELF seems like a bad idea for Linux. The "benefits" listed on <http://icculus.org/fatelf/> fail to persuade me to want to pay any additional cost.

<comment><USER9> Oh, so having future commercial packages that many people depend on, like Adobe Photoshop or 3D Studio Max ... packaged and distributed as a universal binary for every major distribution and every architecture ... is of no importance whatsoever?

This is a major roadblock for commercial third-parties that would like to distribute ports of their software for Linux.

<comment><USER5> You can do this without fatelf. Put everything you have into a single package and add "shell scripts and flakey logic to pick the right binary and libraries to load". (He fails to mention, that fatelf is nothing more than this, only hardwired into kernel.)

<comment><USER3> How are shell scripts and flakey logic an improvement on Apple's cross- platform development/usage model?

      gcc -arch i386 -arch ppc -arch x86_64 -isysroot <SDK path> example.c -o example

Done.

      > file example
      example: Mach-O universal binary with 3 architectures
      example (for architecture i386):	Mach-O executable i386
      example (for architecture ppc7400):	Mach-O executable ppc
      example (for architecture x86_64):	Mach-O 64-bit executable x86_64

I can even transparently _run_ PPC binaries on my x86 Mac.

Universal binaries are a core component of this easy-to-use (for developers and users alike) architecture independence.

<comment><USER10> What you are demonstrating is the userland toolchain. What was suggested above is an improvement by not requiring meddling with the kernel. Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications.

<comment><USER3> _What you are demonstrating is the userland toolchain._

No, what I'm demonstrating is an end-to-end architecture-transparent platform, which includes a complete userspace toolchain, a universal binary format, and necessary kernel and dynamic linker support.

 _What was suggested above is an improvement by not requiring meddling with the kernel_

I'm not sure I understand how "meddling" in the kernel is a bad thing when it provides for user-transparent execution of multi-architecture binaries, including transparent emulation of binaries that lack support for the host architecture.

It's not as if it's complex or dangerous to parse the Mach-O or FatELF formats, and if you take a page from Mac OS X or qemu, you can even do transparent emulation in userspace.

 _Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications._

How is it useful to build an easy-to-use multi-architecture binary if the kernel can't actually execute it?

Why are you afraid of doing simple parsing[1] of the binary? The kernel already does this -- how do you think ELF loading and shell script execution works?

I can imagine this conversation 30 years ago[2] -- "Why should we add shell script shebang parsing/execution support to the kernel? Why not just glue together loader executables that load the shell script"

[1] The dead simple Mach-O universal binary loading code: [http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-...](http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-1228#L563)

[2] The introduction of shebang in UNIX: <http://www.in- ulm.de/~mascheck/various/shebang/sys1.c.html>

<comment><USER5> It shouldn't be hard to make an binfmt_misc handler that would rip the correct elf from the fatelf thing (or rather a simple tar) and feed it to kernel, so you can just type ./fatelf-something. You can also make it a shell script with the binary in it, that will choose the correct one and execute it. Both these solutions works without a single kernel line (really), and I can't see anything that fatelf has and these doesn't.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I think this guy is trying to solve a problem that doesn't exist in Linux. In Linux, every piece of software is compile for the architecture you want, so there is no need for a fat binary. Mac OS X needed this because they Mac users mostly run commercial software, so it is better to have a single binary for all platforms.

</comment><comment><USER12> I don't believe this is the way it should end, leaving one enthusiast all broken.

Anyway I'm not really aware about background details of the matter.

<comment><USER13> Enthusiasm is not a substitute for pragmatics; all the other contributors are just as enthusiastic, but they know their patches are not entitled to merger with the main tree willy nilly, without there being a very _good_ reason.

</comment></comment><comment><USER14> I don't see what's stopping him from forking Linux and glibc. If this is really better, everyone will just use his fork. (It worked for my fork of cperl-mode, anyway...)

<comment><USER15> The point is to get patches accepted without forking. Linux and glibc aren't exactly small. Do you honestly see a single man maintaining millions of lines of forked code as well as handling packaging and stuff?

<comment><USER16> It's not as bad as it sounds, basically great many of the <http://git.kernel.org/> repos are actual forks of the kernel, regularly pulling changes from vanilla, resolving the occasional conflicts and maintaining/developing their own patches.

<comment><USER15> Actually it _is_ as bad as it sounds. Although git makes it easier to merge with mainline, in the end it still requires an active maintainer who manually merges and tests stuff once in a while. Maintaining a fork requires one's constant attention and diverts one from doing other - maybe more useful - things.</comment></comment></comment></comment>


Send Aliens Modern Messages of Earth's Equality and Diversity, Say Scientists - <AUTHOR> http://www.theguardian.com/science/2015/sep/10/aliens-modern-messages-earths-equality-diversity-seti-yuri-milner

<comment><USER2> *Honest message.

As an advanced race I'd be pretty annoyed if I arrived on a planet which, as I'd been lead to believe, had finished sorting out all the primitive ways that we have when it had not.

"Equality is one of our most important problems, and we are making progress with it."

</comment><comment><USER3> Notwithstanding the assumption that aliens would care about human ethics at all, these messages _might_ be detected thousands of years after being sent, and then it might take thousands of years to get a response. Humanity could just as well have regressed to post-apocalyptic stone age barbarism by the time they show up, for all anyone knows.</comment>


Optimizing Clojure Code the Right Way - <AUTHOR> http://clj-me.cgrand.net/2009/11/17/life-of-brian/

<comment><USER2> Anyone have benchmarks on implementations of this in other languages? It seems sufficiently non-trivial to be an effective benchmark.

<comment> cgrand-net There's no such thing as an effective benchmark. Plus cell automatons are easy to write efficiently in an imperative/low-level language (eg an asm impl is easy) and are only representative of a small specialized class of programs: I don't think I have evere wrote such a thing in a business app. You may find similar programs in image processing though.</comment></comment>


Helsinki to Begin Anonymous Recruiting - <AUTHOR> https://finlandtoday.fi/helsinki-to-begin-anonymous-recruiting/ <comment><USER3> Recently I've been thinking about inherent biased towards applicants based on their prior work / educational history, in terms of organizations they have been to.

I get that it acts as a moderate signal of how tenacious and inherently able that applicant might have been in the past if she went to XYZ school or ABC company. But there will be so many false negatives!

A lot of folks who probably would be otherwise capable of the job at hand would be dismissed for not having the right pedigree. Also, past performance is not always the best Intuit if future success.

And then of course is the issue of how do you even define success, especially in case if university graduates. How does a Yale or Harvard define our measure success for its students... Probably in terms of potential impact they have on the world or how good their names may look on the rolls 10 years down the line.

A lot of the issues, especially in terms of job applicators but also applicable in admissions process, ultimately comes down to information and numeric asymmetry between the organisation and the applicant.

If there was a way to somehow capture the readings - however brief - <USER2> rejection or selection of applicants or a documented scoring methodology, that itself would bring a lot of change.

I would love to know if some resources to further explore the alternative models of applicant assessment which does not place as much importance on the past organisations / schools they have been to.

Any suggestions would be much appreciated

<comment><USER4> Professor Iris Bohnet of Harvard wrote a fascinating book called "What Works" that you might find interesting. What I really like about the book is right from the jump Bohnet basically says all this "diversity training" and "PC culture" stuff is a waste of time and an uphill battle. We all like to pretend we're unbiased but Bohnet tells the truth from the outset: _everyone_ has biases. The book focuses on systems that emphasize equal opportunity and remove some of those inherent biases we all have.[1] Bohnet's premise is that we'll get better results if we stop designing systems with the faulty assumption that most people/systems/institutions _aren 't_ biased in some way or another.

There's a chapter about "blind auditions" that Orchestras began to implement in the 1970's that you might find interesting.[2] After reading that chapter I remember wondering how much we're overthinking a lot of these issues and whether we might be overlooking some pretty easy changes that could have a significant impact.

One interesting fact from the blind auditions study was that even without being able to see the musician they were able to demonstrate bias (likely unconscious) when women wore high heels to their audition because the sound gave away their gender. It's really fascinating some of the ways we unconsciously "judge" those around us.

[1][https://hbr.org/2016/07/designing-a-bias-free- organization](https://hbr.org/2016/07/designing-a-bias-free-organization)

[2][https://www.theguardian.com/women-in- leadership/2013/oct/14/...](https://www.theguardian.com/women-in- leadership/2013/oct/14/blind-auditions-orchestras-gender-bias)

<comment><USER5> I know that as a result of diversity training and guidelines I am 10x as cautious about my behavior at work in front of women as with just men. That means there is a camaraderie that the men have that the women are left out of. When I worked on Wall Street this divide didn't exist but there was definitely a culture of sexually hostile work environment and sexual hatrassment.

<comment><USER4> This is really interesting because I've worked on Wall Street as well and I know exactly what you mean but have never really been able to articulate the difference you've just pointed out. Working on Wall Street I had lots of male _friends_ , not just colleagues. For the most part I felt included and was treated as competent. I also dealt with a fair amount of sexual harassment. Most of it was under the guise of joking/"locker room talk" that I just ignored. Sometimes, particularly from the older men, it was more physical and made me feel very uncomfortable.

The allegations against Google actually really caught me off guard because, in my experience, a lot of men in Silicon Valley seem like they're almost too... _progressive_ (if that's the right word) to overtly harass their female peers the way men on Wall Street sometimes do. On the other hand I really struggle with inclusion in tech in a way that I never did in finance. I often feel dismissed by my tech colleagues. Both personally and professionally. Experiencing that sort of divide is much more difficult to explain and, to your point, much more difficult for me to navigate. Not to diminish women who have been sexually harassed at work, I'm one of them, but this silent divide takes a much bigger toll on me personally.

Thank you for pointing it out.

<comment><USER5> It's simple - either people act however they want, or they watch their behavior. In the former they develop stronger bonds with each other. In the latter they are more respectful of each other.

</comment></comment></comment></comment></comment><comment><USER6> I've long suspected this was the only remotely feasible way to remove bias from recruiting (and possibly interviewing itself) -- I'm interested to see how this will go.

Politics about bias and diversity aside, if your goal was to objectively disable people from being biased, the simplest solution always seemed to be to remove their ability to apply any of their biases.

<comment><USER7> >the simplest solution always seemed to be to remove their ability to apply any of their biases

Bias will exist regardless of which information you present, the most you can hope for is shifting and limiting the types of bias that come into play to eliminate useless or harmful bias. Even if you grant anonymity to the applicant, recruiters can still be biased against or in favor of the school somebody went to, what they studied, the organizations they were involved in, etc.

<comment><USER8> For thia reason I hire based on anonymized data that also discards all place name locations and institutions. The result is quite effective, as you are presented with an applications that show only the bare bones of someone's experiences without context that might bias you.

<comment><USER9> Do you continue to ignore this information in the interview phase?

</comment></comment></comment></comment><comment><USER10> This had been tried before, and it failed spectacularly. Women did even worse.

[https://www.abc.net.au/news/2017-06-30/bilnd-recruitment- tri...](https://www.abc.net.au/news/2017-06-30/bilnd-recruitment-trial-to- improve-gender-equality-failing-study/8664888)

<comment><USER11> Don't you mean, succeeded spectacularly? If the composition of candidates was changed when less biased/irrelevant information was displayed, arguably the selection could only be _more_ meritocratic, not less.

<comment><USER12> That is only true assuming the selection criteria that _weren 't_ blinded were themselves free of bias. That's very rarely true.

And if it's not true, arguably what you've done is removed the adjustment variables that could correct the bias, rather than the bias itself.

<comment><USER13> > were themselves free of bias.

At what point do we start growing people solely for the purpose of leading unbiased existences away from all of humanity? Of course these existences are isolated from all humanity lest they associate the human that gives them food with positivity, or someone having a bad day with negativity. And of course, we kill these _unbiaseds_ shortly after every selection process, since the mere process of selection itself, generates bias.

Some SF writer must have beaten me to this right?

<comment><USER12> Note that, like many machine learning examples of the recent past, the evaluator themselves need not be biased. Just the data.

</comment></comment></comment></comment></comment><comment><USER14> > Anonymous recruiting entails that the ... date of birth ... are not included > in the job application

If I write on my application that I have 25 years of experience, does that have to be excluded due to it revealing that my date of birth is likely more than 40 years ago? Can they really believe that the amount of experience isn't important?

<comment><USER15> I'm 46, and people my age talk about leaving off earlier experience, so as not to look too old. I condensed my earlier experience (the first 10 years) into a couple sentences describing the roles--not to look younger, but because with an average stint of 2.5 years, there are just too many jobs to list.

Other steps people my age take are to stop listing dates--either select dates like university graduation, or--in extreme cases--all employment dates.

Keep in mind that there are different biases at different screening points along the way. The manager with the open position may want someone older and more experienced, but the people recruiting, screening, and filtering the candidates may be biased or simply not familiar with the value of experience that doesn't match today's buzzwords.

<comment><USER16> I've got about 14 years of development experience and I also leave off some of my earlier experience on my resume. I do it not to conceal my age, but because the stuff I was doing 10 years ago is so much less interesting and relevant to my applications today.

Does my outlook not resonate with you/other older employees?

<comment><USER15> It does with me, but I'm less picky about traditional experience than most people. I'd prefer a list of technologies that someone knows, a list of things they want to work on, and a blurb about how they might fit in to the role I'm hiring for.

The cover letter seems to have fallen out of fashion, but I find a couple paragraphs of prose far more revealing about a person's abilities than a resume. Of course it's also more work to craft one for every position you're interested in, and doesn't help much if you're looking to put yourself into a database for recruiters (e.g. LinkedIn or any other job site), where they force you to iterate your experience in chronological order and list technologies with no context.

I think it's important to leave off things you're not interested in. I did Perl for years but there is no amount of money that would get me to do it again, so I minimize or eliminate its presence on my resume, and put extra emphasis on the technologies I want to work with now.

</comment></comment></comment></comment><comment><USER17> People are going to fake a lot more degrees and other qualifications.

When they come in for an in-person interview racial/gender/age/whatever bias is still going to be there.

Only way to prevent this would be to forbid in-person interviews before hiring/signing a conract, but then companies would presumably simply stop hiring from applications, because the qualifications are unreliable and they can't get a character impression of the applicant.

Hiring by reference from existing employees would become the norm (maybe it already is).

<comment><USER18> Why would someone do that if they know the faked degrees or qualifications won't pass the background check eventually? Just to get an onsite interview?

<comment><USER19> Yes, just to get an onsite interview. I saw this many times and it's very sad.

Also, I relate this to culture. Not to offend anyone, but from my personal experience lying in CV is much more common for some countries, that for others.

Scale maybe terrible, like multiple certifications in some field with no actual basic knowledge or skills. Like Certified Senior (sic!) Software Developer who can't tell you difference between stack and queue, or CCIE certified network engineer who has no idea what is DNS and how it works (real case).

<comment><USER18> And what makes it different for those people without anonymous recruiting?

</comment></comment></comment></comment><comment><USER8> I hire on anonymized data. I can tell you that it works well. The only flaw is that if your pool of application sifters is not diverse, bias will start to creep back in. For instance, in a group of several application sifters of a single gender who are collectively deciding which applications to progress to interview stage, one may frequently encounter presumptions of gender and age of the applicants due to implicit bias by the sifters.

The organisation must have a very respectful culture in which colleagues feel comfortable calling out others on their biases when this happens.

<comment><USER20> "ooooh this person has _MIT /Stanford/Harvard_ on their resume, just like I do!"

"eh, midwestern state school"

"what even is an HBCU are those accredited?"

"fortran though?"

the initiatives are at least conscious of sensitivities in the space, but we have a long way to go

</comment></comment><comment><USER21> Economist here. This will bake in bias that affirmative action and other programs seek to counter. Inequality of opportunity unfortunately isn't countered by this approach. Why? The same group(s) facing discrimination at the employment point also face discrimination earlier in life, or have baked in social discrimination (such as the US justice system overpenalizing blacks relative to whites/Asians, or Ivy League admission rates for Asians versus other groups).

It would be nice to build a group-blind world, and the more we adopt these specific approaches the better can can iterate towards. However, care should be taken to ensure the baked in biases don't further entrench.

<comment><USER22> I'm sorry, but this sounds absurd. Correct me if I'm wrong, but what you're saying implies that employers should hire people that are less qualified for a job just because they belong to a group, members of which on average are more likely to be discriminated earlier in their lives than others?

Engineer here, and no, blind hiring will not bake-in any biases, because that's exactly the problem this approach solves - it aims to hire the best candidates regardless of their race, origin, religion, accent and other irrelevant characteristics.

<comment><USER23> > Engineer here, and no, blind hiring will not bake-in any biases

Yes, it will: if you're born to a well-off family, you'll go to better schools before college. Due to this, you'll have a better chance at succeeding in college, have more resources to delve deeper into your field of study, better manage studying abroad, &c. All of these factors will make your list of skills more attractive to employers.

Compared to someone who was poor who went to worse schools, didn't study abroad, and couldn't afford to spend more time on their field of study due to having to work to pay for college. This will make your list of skills less attractive to an employer.

Right out of the gate, there is a bias against people who grew up poor in the hiring process.

> it aims to hire the best candidates regardless of their race, origin, > religion, accent and other irrelevant characteristics.

It does so by devaluing repressed classes of people. This is a societal cost to benefit businesses.

<comment><USER24> This is how I mainly take it. A lot of comments about how this will make it "bias free!" and "nondiscriminatory" when really what it will do is give advantaged people even more advantage. Those who were not able to go to the better school and get more life experiences and obtain connections are going to be even further behind.

There seems to be this implied belief that there's a conspiracy in the West to hire white males above all. This simply isn't true. By having access to race and gender and even age in some cases it allows us to select for a diverse set of candidates. So although we may not (or we may!) end up with an outcome that is as diverse as the set we started with, we at least made the effort to give different people an equal _opportunity_.

If I'm only allowed to recruit based on the best credentials then those with a socioeconomic advantage will continue to.

<comment><USER25> You have no idea what someone's advantage in life is, and you're turning "diversity" into "diversity of race and gender" which is about nothing but immutable physical characteristics. Life is not constant. People move through various conditions all the time. Are you going to deny someone who grew up poor and then got a scholarship to Harvard?

Putting people into permanent "social classes" is far worse than letting people use their abilities and become competent independently.

<comment><USER24> > Are you going to deny someone who grew up poor and then got a scholarship to > Harvard?

This is the exception to the rule and not really relevant to anything I said I think? What about the kid who grew up poor and could have gotten into Harvard but didn't go because their parent was sick and couldn't afford care and they attended a local college to be home with them? This is more likely.

> Putting people into permanent "social classes" is far worse than letting > people use their abilities and become competent independently.

I agree - letting people use their abilities to advance themselves is best. If anything, I support blind screening of applicants. But I think the approach here has different intentions than what will very possibly occur - those with access continue to compound that.

<comment><USER25> What about it? Life isn't fair.

There are trillions of decisions and situations in your life that accumulate, and there is absolutely no way you or anyone else can judge that to engineer some kind of fair outcome. It is good intentioned but not realistic, and it ends up causing _far more bias_ because you think you're doing the right thing, while basing it on a faulty perception.

<comment><USER24> > What about it? Life isn't fair.

Right, which means we shouldn't cry when it turns out to be unfair as you are here.

> There are trillions of decisions and situations in your life that > accumulate, and there is absolutely no way you or anyone else can judge that > to engineer some kind of fair outcome.

When have I even once said there should be "fair outcomes"? I don't believe in equal outcomes. I do believe in equal opportunities.

> It is good intentioned but not realistic, and it ends up causing far more > bias because you think you're doing the right thing, while basing it on a > faulty perception

What is the "faulty perception"? I'm simply stating that if the goal is to have a diverse workforce then removing the heuristics we are told make us diverse from the recruiting process makes it difficult to achieve this goal. If I want to fill a position and my company has given us a goal of eventually having the ideal diverse workplace without sacrificing the quality of our people then I need tools to do this. I will use the, possibly arbitrary and political, heuristics they give me (age, gender, race, etc) and ask my recruiting staff to give me a group of 12 candidate for in-person interviews.

From these 12 there must be at least 1 attribute from each heuristic across the group. So maybe we say there are 3 races we optimize for, 3 age bands and 2 genders. This means that my set of 12 could have a black woman who is 41, for instance, and a white male who is 25, and an Asian male who is 55. This has all of these covered and the remaining 9 candidates can be any combination. But at least I have committed to creating an equal opportunity in the way the company and a large part of society see as "diverse". Even if I don't agree with it 100%.

Does this create _far more bias_ when the goal is to create the ideal, diverse workforce? By systematically including certain biological features of people in the candidate pool are we at least _ensuring_ we gave a diverse group of individuals an _equal opportunity_?

<comment><USER25> You're defining diversity as only diversity of race and gender, irrelevant and unchangeable physical characteristics that have nothing to do with a person's individual character. You're making decisions not on competence but on subjective biases and your perception of wrongs that have nothing to do with merit.

There is no "ideal diverse workforce". By forcing a particular set number of people in each arbitrary group, you are absolutely designing for an outcome, not opportunity. You did not give anyone who applied an opportunity to be hired, you demanded a specific "heuristic across the group" based on nothing but what someone looks like, on biological features that nobody has control over.

This is completely opposite of making things as fair as possible, and I am truly lost at how you are rationalizing this.

<comment><USER24> > You're defining diversity as only diversity of race and gender

I didn't make the definition. The company leadership makes it based on internal feedback, advice and general societal beliefs in what "diversity" means.

> irrelevant and unchangeable physical characteristics that have nothing to do > with a person's individual character

I agree - everyone should be judged by the content of their character, not the color of their skin. However, it is difficult to judge someone's character alone from a CV.

> You're making decisions not on competence but on subjective biases and your > perception of wrongs that have nothing to do with merit.

Every person I'd hire deserves to be hired. There are no bones thrown to fill a quota (which doesn't exist). However, to help achieve the goal of a "diverse workplace" a systemic method needs to be incorporated to ensure that a diverse set of candidates were given an opportunity to join the interview pool. With a large enough pool we can reasonably assure that every hire is hired on merit alone as they will be competing with other people that have different immutable physical characteristics. This also means if the hires tend to all look a certain way I can reference the systemic method used to ensure that in fact we actually _removed_ bias from the selection process by ensuring certain attributes were included in the overall pool.

> There is no "ideal diverse workforce".

Ask 1000 people and you'll get 1000 answers.

> By forcing a particular set number of people in each arbitrary group, you > are absolutely designing for an outcome, not opportunity.

No, you are creating a pool that is defensible in terms of who you end up hiring. No one is guaranteed a job because they are in the candidate pool. They will compete with their cohort on equal grounds.

> You did not give anyone who applied an opportunity to be hired, you demanded > a specific "heuristic across the group" based on nothing but what someone > looks like, on biological features that nobody has control over.

See, this is where you're making a mistake. The specific heuristic across the group includes everyone. It doesn't say "not white males in their 20's" \- in fact 9 out of 12 candidates could be just that so long as the other 3 candidates somehow cover every other enumeration of attributes. But with a large enough pool you can ensure that each characteristic the company determines is "diverse" is somehow included in the candidate pool without diluting it in terms of merit. This doesn't mean the outcome looks anything like the candidate pool.

> This is completely opposite of making things as fair as possible, and I am > truly lost at how you are rationalizing this.

Fair enough - I don't know your thoughts but it could be from the point of view you're looking at if from. To me, you sound like someone who thinks a systematic method of candidate pool selection sounds like _exclusion_ of certain people. And it would be if we _excluded_ certain candidates because they didn't possess an arbitrary diversity attribute. However, this process is _inclusive_ because it demands that each enumeration of each diversity attribute be included at least once. And with a large enough candidate pool (this is key - you need to do the work here interviewing enough people) this means there are still very many seats for the dominate attribute enumeration - white guys that are youngish as it happens to be.

However, it would be an illegitimate candidate pool if there wasn't a white person in it, or a male in it, or a young person in it as well! That would be _exclusionary_.

This is a pragmatic approach to fulfilling a diversity goal (regardless of if my personal beliefs are different) while ensuring that there is no exclusion, that the quality of hires remains at the level desired and most importantly that nobody who is hired or anyone they work with has any reason to believe they only got the job because they won diversity bingo.

<comment><USER25> Regardless of who made the definition, that's the definition you're following.

We're going in circles here as long as you fundamentally believe diversity of physical and biological details is important. If that's what you want to enforce in your workforce, even though it is meaningless to the job, then you're designing for an outcome, and not opportunity. Inclusive does not exist in a vacuum; to include some means to exclude others.

<comment><USER26> Not the parent commenter, but for what it's worth, I appreciate you taking the time to write your responses in this thread. I am honestly baffled (and a little alarmed) that more people don't understand the points you are making.

<comment><USER24> Please explain why?

From my perspective what makes sense is we have large groups of people that believe diversity as defined by certain attributes is important. We also have large groups of people that don't. And both groups have some good and some poor reasons for their beliefs. Both "sides" are legit. So how do we reconcile this?

To me, the most agreeable aspect of each side is that:

1) We live in a diverse society whether we like it or not, which has a history of certain exclusion and we should try and improve on that to make all of our lives more peaceful.

2) Not everyone has an advantage or disadvantage because of certain immutable attributes and we should be conscious of this as well. Social engineering is less engineering than politics.

The idealist approach is to optimize one way or the other; mainly for political reasons which results in resentment and bitterness. The pragmatic approach is to try and create a system that is __defensible __one way or another - even if it is flawed in both regards. The perfect system is impossible anyhow and a matter of opinion.

So, you design a system that takes into account both points above. You ensure you interview across certain enumerative attributes generally agreed upon as important. But you don't optimize across it as it can turn into an exclusionary system in its own right with awful side effects such as legit resentment, meritless and simply political. You don't exclude any of the apparent important __diversity __attributes - they all are important. You also create a reasonable metric around what this means. This ensures you, in some way, have at least given the opportunity to a vast range of of people. It doesn 't mean you've given an outcome to anyone.

The trick becomes in keeping it honest - that you don't assume that a certain set of attributes is more important than another. Where a lot of similar systems get it wrong is they define that a certain subset of attributes must be included. They should demand that over the entire pool _all_ attributes must be included. And only to a limit and after that it's fair game.

I'm only saying that we should at least try and ensure we speak with everyone in terms of various individual attributes that are generally accepted, albeit arbitrary, when opening an opportunity. And that's it. What is alarming about this? How is this not pragmatic? Who is this stealing from? How is this bad for anyone?

<comment><USER26> First, and most importantly, thank you for the friendly reply.

Regarding your questions, I can't think of a clearer explanation that the comment that I initially replied to. Fundamentally, the core argument is that the moment you start using immutable characteristics as part of your heuristic, you've already lost- there _will_ be resentment, because now, by definition, you've given something to someone that they did nothing to earn, and that position is coming from someone else.

That these exact things happened in the past, and happen now, doesn't mean that reversing the arrow makes things better- it just breeds a new generation of the same thing.

In terms of how do we move forward as a society, and speaking strictly as just my own opinion: we need to focus on what our _commonalities_ are, not our _differences_ , and go from there.

I had the great luck of growing up as the child of a diplomat, and thus getting to see a much wider variety of countries and ways of life than most people do. One of the most important lessons I took from the experience is that people are far more alike than different, even in areas that have had little previous cultural exchange. It takes some time to find out how to translate across different givens, but once you understand the shared local model of how things work, people's decisions make sense.

The catch is that if you don't agree with some of the base assumptions, then some decisions will seem utterly abhorrent, and the same is true in reverse. Some are mutually exclusive, in that there is no such thing as a middle ground. That is the problem of diversity, and it is a very real one.

So, moving forward- these schisms exist because the world used to be far more closed off from itself than it is today. I'm only in my mid-40's, and yet when I was a child, a letter to the US and back was a 3-month round trip. Now I can hop on any of a dozen free webcams if I felt so inclined and look at who is walking down the street where I used to live. All we can do is start talking to those now so close, find out what we _can_ agree on, and try to forge something we can all live with.

(I realize this is a bit further afield than the original subject of applying for jobs, but I think a friendly reply deserves an honest answer.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> > the name, date of birth, address, mother's tongue, gender and any other > personal information [are] not included

[...]

> when much of the information in the application has been hidden, it's hard > to establish a clear picture of the know-how and capability of the applicant

So they base their assessment of know-how and capabilities on age, gender, mother's tongue, and other personal information that has been hidden? I feel like I must reading this wrong.

<comment><USER28> I don't think you are reading that wrong. People use all sort of pseudo science to make inferences on people's competencies. Like if you are a woman in a male dominated field you're likely to be highly competent. Or when hiring for a leadership position an older candidate may be subconsciously preferred over a younger one with more experience. It's all generally bunk and this is imo, an admission that they have been using the wrong criteria to judge candidates.

<comment><USER27> > if you are a woman in a male dominated field you're likely to be highly > competent

In my experience it's the opposite. Like with small countries: the odds they produce someone extremely good at a certain sport is just smaller than in large countries, so large countries are more likely to win some world cup or the Olympics. I know only a handful of women in IT to begin with, but most of them aren't great at it.

But that's not your point. You're saying that there are biases in hiring, and I agree. What I'm surprised by is that the article quotes them saying that they now find it very hard to judge someone. Who would say, alongside a press release about anonymous applications, that they find it difficult to base their judgement solely on only relevant information?

</comment></comment></comment><comment><USER29> Recently was using coderpad, I believe, and after the session ended it had an advertisement for some similar scheme - a blind technical interview (with Uber, Lyft, or Facebook! it advertised) that, if you do well in, you can choose to "unmask." Was thinking about doing it, anybody else tried it? Probably would be disadvantageous to me - I generally pitch myself as a moderately skilled engineer with very good soft skills, as opposed to a tremendously skilled engineer straight up (maybe in a couple years...). Can't demonstrate soft skills anonymously.

<comment><USER30> I'd like to think I'm more skilled in soft skills than others but I always demonstrate that at the on-site interviews. How do you market those skills on a resume?

<comment><USER29> Well, like this: [https://docs.google.com/document/d/1A3Ns93sbE8v70hCt7yWJigoi...](https://docs.google.com/document/d/1A3Ns93sbE8v70hCt7yWJigoiL0sQZNTtMPr9zVtkoqM/)

Best I think I can do is certain descriptions for projects highlighting my role, as well as stick a little section at the bottom describing a personal experience and showing a bit of my personality and value system. Stuff like "Led hackathon team of 4 to develop a serverless app integrating several APIs." It's really quite tricky to show off your soft skills on your resume. I think the resume should be more to just get your foot in the door. If I can get on the phone, I'm usually good to go.

<comment><USER30> Based on your resume, I think you can present all of these skills anonymously as well.

Of course, there might some clear marks that will give away your gender and age, but that's up-to the interviewer to decide. All the things you have on your resume can be done by a woman or 20-year old as well as 60-year old.

So, I don't this would hurt you in any way and you can still demonstrate your soft skills.

</comment></comment></comment></comment><comment><USER31> I'll just laugh when it ends up being majority of white males, simply because that's what there are mostly available. Perhaps it'll finally shut the patriarchy blaming people up.

<comment><USER32> It's Helsinki. It's impossible for the majority not to be white, whether they're male is another matter though.

</comment></comment><comment><USER33> As a tall, handsome young white man with a great employment history at internationally known companies I do not like this at all.

There is no perceivable bias that would penalise me, besides the fact that I do not fulfil diversity quotas... Or do I? I am not straight! I really am the full package.

<comment> fake-name Soooooo..., you're angry you no longer will get a illegitimate boost in front of your peers?

Can you hear that? It's the sound of the worlds tiniest violin playing you a sad song.

<comment><USER33> I am not angry, but I do not support changes to hiring practices that are bad for me.

</comment></comment></comment><comment><USER34> The most shocking part of this to me is the last line:

"The City of Helsinki is Finland's biggest employer with around 38,000 employees."

Is this common for governmental organizations to be such large employers? Even in Europe, this is surprising to me.

<comment><USER35> NHS (Great Britain - state owned health provider) is on a track to reach 2mln employees.

<comment><USER36> Precious few of them nurses but there's always room on the org chart for more middle managers.

</comment></comment></comment><comment><USER19> To me it seems counterproductive. Either whoever lies in CV more will win (be interviewed at least), or bias will show itself during personal interviews. You can't look at a person without realizing sex/age/race.

<comment><USER37> Of course you're going to know who you're interviewing. The whole idea is to anonymize the PRE-interview phase, specifically, selecting candidates. That selection post excludes personally identifying information.

If someone lies on their CV and is caught out another/more candidates will be chosen to interview, no?

<comment><USER24> > That selection post excludes personally identifying information.

Here's the cognitive dissonance of it all. How can we achieve the goal of a "diverse" workplace (which is based on certain attributes like gender, race, age, etc) when we can't select a candidate pool with these things taken into consideration? Will this have a net negative effect on at least creating an _equal opportunity_?

I'm not saying I'm for or against this blind screening. But I am skeptical it will work as intended. If anything, those with the most advantage due to their socioeconomic status from birth will simply advance in the system even more quickly.

<comment><USER25> >> "diverse" workplace (which is based on certain attributes like gender, race, age, etc)

That's not a good goal. Diversity of what you look like is absolutely terrible.

</comment></comment></comment></comment><comment><USER38> What about doing the same for politicians running for office? show us your "accomplishments", we don't care about the rest, LOL.

</comment><comment><USER39> Quite interesting how such a thing affects salaries as all yearly personal incomes data is public in Finland.

<comment><USER40> Always how they got away with that with the Eu's Data Protection laws and now GPDR.

Do I have an overriding "need" to know what my neighbour is earning and its certainly open to abuse eg other UK media organisations using it as a stick to beat the BBC with.

</comment></comment><comment><USER41> This could be a form of discrimination against native born applicants. A person's "mother tongue" is not some trivial matter. Many Indians I've worked with are not as fluent in English as they claim to be. Communication skills matter. Trying to even the playing field so that people who are not native speakers of the local language is ridiculous. I have worked hard to improve my own communication skills and consider it a very valuable skill when searching for employment.

<comment><USER42> Communication skills are tested in the interview.

</comment></comment><comment><USER43> If employers are looking for a radical utopian reform, I'd rather see them do away with the interview. Interviews slant hiring toward personal charm, and toward the cultural uniformity of the workplace, at the expense of competence.

<comment><USER44> We need the same set up that the Turing Test has during interviews to remove the factors you enlisted.

<comment><USER21> Something like a civil service exam?

</comment></comment></comment><comment><USER45> Like in Turkey. I gues more than half of the Turkish civil servants are recruited via tests/exams, and then randomly selected via computer. Here 37000 teachers are selected randomly via a software [https://youtu.be/vwYjqp_aNak](https://youtu.be/vwYjqp_aNak)

</comment><comment><USER46> This will backfire, as in previous experiments: [http://www.abc.net.au/news/2017-06-30/bilnd-recruitment- tria...](http://www.abc.net.au/news/2017-06-30/bilnd-recruitment-trial-to- improve-gender-equality-failing-study/8664888)

</comment><comment><USER47> The UK Civil Service already does this. They ask you to remove all PII, school/ university names. That said you can leave your previous employer names in it.

They call it "name-blind" recruitment.

</comment><comment><USER48> Now if they do what paper submissions do in academia and also require you to discloser 1st and 2nd degree conflicts of interest.

</comment><comment><USER49> > "A key challenge is that when much of the information in the application has > been hidden, it's hard to establish a clear picture of the know-how and > capability of the applicant," the city's resolution says.

What exactly do you learn about a candidate's know-how and capability by knowing their name, gender, etc? Unless you are so deep in denial that you'd just blatantly say "Men are more capable than women".

<comment><USER48> Depends on what's considered identifying information. There is Google you know.

But I applaud the concept. I'd be interested in the results.

</comment></comment><comment><USER50> So you remove bias from the resume-screening process and then do exactly what during the interview process?

</comment><comment><USER51> Does it really not bother anyone else that we are heading down a rather dystopian world of a kind of hyper-meritocracy that eschews with all other rights and privileges as it commoditizes humans to nothing but a function of their skills and abilities as put on paper, or even exhibited in practice?

It does not seem all that healthy to just dismiss and ignore and totally negate compounding value of cross-generational achievements and accomplishments ... that you are not better than the last widget you created compared to the next person you are compared in preparation for creation of the next widget.

Does anyone else realize this is really just a sneaky way of introducing the degenerate nature of communism into the equation? ... that your humanity means nothing if you are not a featureless and characterless humanoid with zero of your own "biases" that contributes to the hive mind collective. I really don't think people have thought this thing through and the ways in which it can go wildly out of control once edge cases start gripping.

So you are hiring totally blindly, without consideration for anything but merits ... it doesn't matter that you are a Native Fin and your competitor

None of that seems remotely healthy or sane to me, and really just smacks of the idealistic and self-deluding narrow view of the effete and decadent who live sheltered in a bubble, without any fear of their own replaceability (whether rightful or not), let alone possessing event the remotest understanding for the wider consequences of their actions and outcomes, even fore themselves, if that bubble were to burst.

This type of technocratic and authoritarian mentality that somehow you can inhumanely simply strip humans of their humanity in order to craft a perfect specimen of humans, ideally in their minds, a mixed master race devoid of "bias" and therefore devoid of their humanity; is really a rather detestable and clearly inhumane ideology by its inherent characteristics.

<comment> core-questions It bothers me a great deal. It seems that the only constructive ways that progressives have been able to come up with to equalize the unequal has been to flatten, to push down, to dehumanize and to remove the differentiation between people, by administrative fiat if necessary.

The thing is, if you decide that Applicant #42 is a good candidate, you're going to bring them in anyway. If you have a ton of biases, you still have just as much of an opportunity to enact them as you would have before, though you might have to be a bit more subtle. This doesn't solve the problem; it's a patch on top of it designed to feel good while accomplishing nothing.

> Does it really seem all that healthy to just dismiss and ignore and totally > negate compounding value of cross-generational achievements and > accomplishments

If by this you're referring to the heritability of traits, yes, it's a shame that things that are statistically and demographically visible have to be erased in the attempt to flatten everything.

> somehow you can inhumanely simply strip humans of their humanity in order to > craft a perfect specimen of humans

I don't know if this is the ultimate goal; my instinct is that this is the projected goal, because it is at least somewhat defensible philosophically even if I dislike it. The actual behind-the-scenes goal might be as simple as reducing people to more-manageable consumers that cause less trouble and more reliably produce the quarterly numbers we need.

<comment><USER52> Progressives have to do that because employers continue to be racist and sexist and discriminate on age, purely based on a resume. So removing that first filter is a good thing.

</comment></comment></comment><comment><USER25> The problem is you think you can judge who is repressed, usually based on group identity, but that never ends well.

Life isn't fair, some will be rich. Judging by capabilities means that anyone can learn to do the job well, even if they have to work harder to overcome their circumstances, and it'll always be down to the individual. People move between classes all the time, and in the US you'll see many people going in both directions.

<comment><USER53> We detached this flamewar from [https://news.ycombinator.com/item?id=18545520](https://news.ycombinator.com/item?id=18545520) and marked it off-topic.

Please don't foment flamewars on HN.

<comment><USER25> Can you please tell me how that comment does so? Is it the use of the word "you" in the first sentence? If so it was meant as generic pronoun, but I guess that can be misunderstood.

<comment><USER53> I was referring to the entire subthread, in which you posted several flamewar comments. You did it elsewhere too. Please don't—it's exactly what we're trying to avoid on HN, as you surely know.

The GP comment wasn't so bad, but the problem is that generic comments about ideological topics usually lead to flamewars.

<comment><USER25> Several? Generic comments about ideological topics seems to describe everything in the entire thread so it's unclear to me what exactly can be said then.

Respectfully, the discussions are valid, received upvotes, and seem to end on their own just fine. Outside of a few personal tangents, which are rightly disallowed, the rest don't seem to need any moderation.

</comment></comment></comment></comment></comment><comment> black-tea Great. This should stop the "wage gap" arguments. It will mean even fewer women in tech, but apparently that's what they want.

<comment><USER54> Affirmative action could be made compatible with anonymous recruiting. Set up a point system. After all the subjective points are set in stone, unmask the applicant and apply any modifiers.

<comment><USER55> So the worst of both worlds? You're trying to both eliminate irrelevant bias and emphasize it. Your result will be "we hire the least white, white males"

<comment><USER21> Depending on the legal criteria (if quotas) decided by society, that could be true.

It could not.

It really comes down to implementation (of which "doing nothing"/autarky is one choice).</comment></comment></comment></comment>


There's an easy way to make lending fairer for women. Trouble is, it's illegal - <AUTHOR> https://www.technologyreview.com/s/614721/theres-an-easy-way-to-make-lending-fairer-for-women-trouble-is-its-illegal/ <comment><USER2> The article says that men default more than women, controlling variables such as payment history and income, so models should be allowed to account for that (with a gender dummy variable?). But would the same argument be made if current models overpredicted men's defaults compared to women's?

</comment><comment><USER3> The entire argument is ludicrous and hypocritical. I am surprised such an obviously sexist idea makes it even into anything that reaches more than a handful of people, but then it shouldnt surprise these days.</comment>


80s throwback photo of Steve Jobs and Bill Gates - <AUTHOR> http://www.tuaw.com/2013/02/20/80s-throwback-photo-of-steve-jobs-and-bill-gates

<comment><USER2> Expect to see more of them together when the new Steve Jobs movie featuring Ashton comes out.

Cool photo although my favorite gates/jobs photo is from the Macintosh dating game in the early 80s</comment>