LaPingvino's comments

LaPingvino | 3 years ago | on: Sapling: A new source control system with Git-compatible client

I'm going to be blunt and state that what most people want is not what they actually need. If you use Git for how it was designed, the commands remain generally pretty clean. If you come from an SVN mindset, you are probably not really using Git the way it was designed, and Mercurial fits better.

I have used (actually introduced) Mercurial before at a company and considered them basically equivalent enough, only to get stuck in some horrible design choices of early Mercurial (named branches and not having rebase by default). I am happy to see these elements corrected in Sapling, giving me enough confidence that I might actually use Sapling over time...

LaPingvino | 3 years ago | on: Sapling: A new source control system with Git-compatible client

There are two reasons Git is better, and the UI is NOT one of them: speed and repository format. I think Keith Packard wrote about this best: Git is technically under the covers way superior over Hg, it's not even a competition. For usability, I think with Sapling we finally get some real competition and that might be the user interface alternative we need, as well as the monorepo approach it was basically made for, but let's just say that I don't trust people who think Mercurial is technically even close to a good idea.

LaPingvino | 4 years ago | on: How generics are implemented in Go 1.18

They have mentioned that you don't really need it as an explanation after they already said for a long time that they do consider it, from the start. They never strayed from that POV.

LaPingvino | 4 years ago | on: How generics are implemented in Go 1.18

No, the documentation stated that Go was designed for reading without backtracking. That results in single pass compilation being possible and thus being faster, but that was never a limitation that was imposed. The reading without backtracking is still valid: go generate DOESN'T work on .go files, only on any other tool that generates .go files.

About the second part, you seem to mix up goroutines and channels. In a concurrent system, you would need locks for your example, and channels fix this. Goroutines are just the representation of independent processes and can be implemented and ARE implemented differently per compiler, check e.g. how tinygo and gopherjs do this.

Your example point 2 doesn't make any sense, check fan in and fan out patterns with channels. Go supports message passing, that is what channels are. You really didn't try Go and it shows.

LaPingvino | 4 years ago | on: How generics are implemented in Go 1.18

They never rejected it. In the very first post launching it they commented that they considered Generics but didn't add them because they didn't find a way that works well with Go's principles. I'm happy it took them the time it did to get to the current design. They did have a vector type before version 1 too, they intentionally removed it for similar reasons.

LaPingvino | 4 years ago | on: How generics are implemented in Go 1.18

Generics were considered at the very release. Go just focuses on getting it right. And I love it for it, because to this day Go is the only language that got OOP right, and now Generics.

Go is a language made for the human factor.

Go generate by the way is mostly NOT used for generics. Check for example Vugu, which compiles UI documents to pure Go code. Go generate is made to incorporate any random external tool without making it complicated for the humans using it. And it makes sense because the goal was not single pass compilation, it was single pass parsing, which is exactly WHY Go generate is useful. It is still true to the exact way this has been defined. Go is simple in ways that matter.

LaPingvino | 6 years ago | on: The dystopian world of software engineering interviews

I've designed an interview test before and I am ironically now doing a very similar interview test to what I designed for the company I used to work at. It worked extremely well for where I used it and I am absolutely thrilled to work on it now for this company. The key element here is indeed relevancy to the job you apply for and not looking for a perfect answer.

For anyone doing programming tests, I would like to give some advice, too, based on the tests I did and got through successfully:

- Always give it a try - Always explain what you do and what you are trying to do - Don't worry about sending in an incomplete test when you don't manage to do it - Be verbose about what you are trying to do to solve it - Don't be afraid to ask questions

My first great programming job was at a place where I got a hard mathematical problem to solve, and I didn't manage to solve it at the moment, so I asked if I could take it home. I didn't manage to solve it at home but sent in the broken code that I had either way.

I got the job.

Why? Because the broken code I sent in showed that I understood recursion (it was for a Common Lisp job, that code was in Clojure) and the other people, even if they did manage to solve it, used more common languages and iterative solutions. He wanted someone who got the spirit of what they were working with, so that got me in. I asked my boss later how to solve that question, and he didn't manage either.

When I did the interviewing myself, the situation was similar. One candidate sent in a huge resume that looked impressive, but didn't send in the test. Immediate fail. Two others had a hard time with the test, but they showed that they cared about making it work, and that was enough for us to accept them: the core thing we wanted to see was that they could learn and cared enough to learn about what they needed.

One of those became main programmer and leader of many others later on, and made the company hugely successful.

LaPingvino | 11 years ago | on: Debian package management, the Arch way

What you see there is very early, I wrote that in a day, the point is to build on it and provide more shortcuts for things that suck to do/type in Debian. One thing I am planning to tackle on the long run is building packages, as in creating an option to install efemeral packages like you can with the AUR in Arch. Other than that, it's mostly a mapping with combined commands (`jogurto -Syu aptitude` updates, then upgrades, then installs aptitude). See it as a kind of alias file.

I wrote it because I love Arch package management, but I don't like the fragility of it, found that out the hard way... I try to bring most of the bliss over via this tool.

LaPingvino | 12 years ago | on: Can 10,000 hours of practice make you an expert?

playful engagement can also be useful or even important. I think open-mindedness is more important here: you need to be able to absorb new concepts and accept experience into your action during the practice. I think that's why people with autism (looking at it through the Intense World glasses) can learn some things really fast, although they don't intentionally train certain things.

LaPingvino | 14 years ago | on: 1995 DOS game opensourced, needs hacker love

All related files are Apache-licensed, as by consent of Abe Pralle (and in case of doubt, just mail him!)

I will include the data-files in the repository. This is the very first release, and it's far from perfect as it is of course.

LaPingvino | 14 years ago | on: 1995 DOS game opensourced, needs hacker love

You can find it on Home of The Underdog. The official site got lost some rewrites ago, but there will probably come some new site again. I could add compiled versions to the repository for reference... It's a sokoban-like game, but a lot more enjoyable.

The .exe and the data files: http://plasmaworks.com/files/pits/pits95.zip

The level editor (Source Code got lost, but Apache-license is also valid for this one. If someone can disassemble it and create some maintainable sourcecode from it, very welcome) http://plasmaworks.com/files/pits/pitsedit.zip

Screenshot for reference (more googling for puzzle pits): http://www.google.com/imgres?imgurl=http://www.old-games.com...

page 1