It goes beyond "programming" though. If the issue was that there's not a lot of programmers in general in Senegal you would have a point. However the article specifically talks about how women are discouraged from these careers and the main issue stems from systemic sexism in Senegal as a whole.
I think you misunderstood. A dialect of lisp is a fairly trivial exercise. We were able to do it in a single lecture back in college. Now that dialect had trivial and essentially useless functionality but allowed us to easily build on and create new languages, but lisp was designed to allow for these dialects to be made and to be made easily.
Did you make an interpreter in one lecture? Or did you just add a new macro to an existing language? S-expressions are tidy, tidy things, but just the underlying tech used to build a lexer, parser and interpreter takes a good while to understand, much less learn to write that quickly.
Lisper just reminded me of some HN commenter who once wrote that "any idiot can build Youtube, it's making it scale that's hard", and that guy gets on my nerves. Sorry about projecting that onto lisper.
There's tutorials to manually or automatically derive parsers for whatever you can clearly define. LISP's syntax makes this trivial. From there, you just need a few functions and tree operations for interpreting/compiling. LISP is designed for tree operations with tutorials and code for those. From there, a GC and I/O with many examples in papers and on the web with doc's plus code. Additionally, there's a ton of LISP/Scheme interpreters to draw on.
Hard to imagine an easier one to interpret. Compiling isn't that difficult if you target C as it basically takes two techniques. Takes a few more to target native and you don't get that in 90 minutes like one Scheme-to-C compiler presentation.
What is your counter-example in terms of mainstream languages that's easier to lex, parse, interpret, compile, or link than LISP? Or even as easy? Even Wirth's languages are more complex and difficult to compile despite being brilliantly simple.
Oh, I do agree Lisp is the simplest. No contest there. Hm, I guess it may be because building a new language (with some interesting properties) was my master thesis and it was really unpleasant. I guess I am reluctant to realize how much easier it would have been with a lisp.
That's a fair point. It's never easy and I had that rough experience, too. I mean, I wasn't a real expert on these things so mine was a reimplementation of existing work but still hard.
Curious, what was your language's interesting properties?
"I guess I am reluctant to realize how much easier it would have been with a lisp."
It might help if you see a modern example. The recent language impressing me the most with its features is Julia:
So, they appear to have built a simple LISP, then used it to incrementally build a compiler for a complex language. They just represent the syntax internally in a LISP form and work with it from there. Don't know much more than that but it shows the power of the concept.
Better demo is the one below as it goes step-by-step in stages. One commenter (Orion63) pointed out the author was re-using the proven cheat: "build a LISP, do it all in LISP, profit." Haha. I've considered duplicating that work with different language options.
My language's main feature was deterministic multithreading, of the synchronous school. It also forced a certain structure: All threads started and the shared variables they can write to have to be in the same area, arguments are always named, and sequence doesn't matter (optional in Python), shared variables can only be written to by one thread, but read by all. In contrast to some other deterministic multithreading solutions, the sequence in which IO is effected is also deterministic, not only the sequence of application to shared variables. The compiler had a typechecker and compiles to C++, using GCC to do the rest. I guess I should submit it to HN sometime...
That sounds interesting. Might be a decent stab at real-time programming and concurrency as it would need most of that.
"All threads started"
In many languages, the threads kind of sleep unless activated explicitly. Do you mean just the activated threads started or did you choose to have them all run at once for some reason?
"shared variables can only be written to by one thread, but read by all"
Good idea. BeOS also had read-many, write-one in form of benaphores: semaphores that only locked for writing. Strategy made it really fast.
"the sequence in which IO is effected is also deterministic"
What do you mean by that?
"compiles to C++"
The compile to C++ was my trick, too, since I knew I couldn't out-code GCC team. Although I wrote mine to avoid using C++ while being compatible lol...
"I guess I should submit it to HN sometime..."
You should. Either that or a forum where people discuss various language tradeoffs.
As far as security is concerned a unikernel with lower attack surface will beat out a general kernel. A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work. Shell attacks like heartbleed won't work because there is no shell. Given that there's a single process, even if you did compromise the system there's not a whole lot you can do with it.
> A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work.
If unikernal systems do become popular, it's very likely this would not be true because AppX and AppY would likely share a popular library that they've both been statically linked against. (Ex: An HTTP library with TLS). Granted, the footprint of exploitable features would be considerably smaller
I agree more with the the latter point that a compromised system would probably offer very little for an attacker to leverage.
I imagine that a unikernel management system would have all the modules -- http, tls, the user facing app, etc -- just as object files, so that an update of the TLS library would entail little more than relinking and restarting the new unikernels.
I think you mean shellshock, but people were only vulnerable to shellshock if they were actually using bash for something. And anybody using bash is, by necessity, going to include it in their virtualunicontainerimage.
Did it actually have much of a "realistic simulation" though? One of the main reasons I didn't buy the game is because people tore it to shreds for utilizing the same exact algorithm for determining traffic as they did water and other utilities. Also people pointed out that like people themselves weren't actually simulated in anyway they just woke up in the morning found the first open commercial job to work at and at night left and found the first house to live in.
It was a realistic simulation of a dystopian society in which people had no long term jobs or housing but were simply assigned to one each day based on proximity.
Well, maybe not "real" as in the "real world", but "real" enough to have fun. SimCity 5 faced an ordeal in trying to be too real; they traded off other vital entities (map size, gameplay features) for getting this simulation right!
It's also been stated that this game has, by default, a very "easy" gameplay which may have contributed to siding to being a bit less realistic but sufficiently real for playing and having fun.
The traffic is a mess, true. They'll patch it up with a better algorithm hopefully. It's still fun though. I recently had a couple of industrial buildings burn to ashes because the firetrucks were caught up in a jam! Now that's quite possible!
But I'm curious what actual 'realism' did it have?
Like the above poster said, the agent model may have been intended to be more realistic, but in practice you couldn't follow a single sim and see a facsimile of reality: they would go to the nearest workplaces and return to the nearest house even if it wasn't 'theirs'.
So where did Sim City 5 succeed that no others have?
The problem is the consumer has expectations. If you tell them they're getting X and you give them Y and Y is demonstrably of lesser value than X they're going to be pissed off. He just over promises and under delivers.
Now with that said of course he doesn't deserve threats, and I agree that gamers tend to be quite the vicious bunch. It's pathetic on their part. I still bought Godus, I was disappointed by it and believe Molyneux deserves criticism for once again delivering something that's not what was promised but I don't understand how/why people go to such extremes.
I met one guy who was essentially a audiophile zealot. He had a ton of money, very little knowledge but it was like a game to him. He spend something close to a quarter million dollars on his NYC apartment's audiophile system. He described how the engineers "specially tuned" the wi-fi so that he could maintain the right fidelity.
The quality of Uber/Lyft drivers and the service in general has plummeted so much lately that I've just switched back to local car services. I just had a nice conversation with a car service driver, who also does Uber, and he said he prefers the car service over Uber because they pay better and only uses Uber when he isn't getting anything else but the pay has dropped over the past year pretty significantly for him whereas when he had started it was pretty good. That's an anecdote so take it for what you will but I just don't see how lowering prices further helps anyone out long term.
Because there is an entire generation of driver now weaned on Uber. They're all over London: guys who got a foot onto the driving ladder and know no other way. They take what they're given.
The disaffected professionals are probably the ones who bitch and gripe about money compared to the old days. Uber is now trying to swallow up huge amounts of market share by creating mammoth demand which will presumably lead to more drivers (who haven't been weaned on better-paying services).
Agreed. I was told to lead a team in all but title, but without the title I was consistently told that I didn't have the seniority nor have I proved myself. Maybe it's different at Delphix, doubt it, but if it is different at Delphix is there just the "Engineer" title and that's it? If so, that's great. If there are titles like Infrastructure Engineer and Front-End Engineer and Chief Architect, etc. then thats on the company culture for being contradictory.
