It's very sad to read this. Often you read comparisons from Westerners comparing UK privacy laws to China's and it's easy to brush it off as being sensationalist. But to hear that from someone living in China is really worrying.
Only yesterday I was raging at Flash for continually chewing up my CPU and RAM. I hadn't even considered setting limits on the processes. So thank you for the suggestion.
Whichever you're most competent in. Any of those languages (and many others) would be a suitable option, so it boils down to what you are most proficient in.
I would amend that. Start with whichever you're fastest (not necessarily most competent) in. Once you discover whether the whole thing is worth the effort, move towards safe languages. That's basically Rust, Scala, or (functional-language-of-your-choice-or-) Haskell.
EDIT: Personally, I would start in something like Haskell or Scala just to do a proof-of-concept without having to worry too much about undefined behavior (C/C++) or absurd verbosity (Java), but then I am pretty familiar with those two languages. Maybe it would be worth learning one or two very terse languages to start with, just in case you hit upon a great idea? (Btw, I think Python or Perl qualifies.)
EDIT#2: As a sort of second or third order bit of advice, I'd encourage anyone to brush up on programming languages that might make you faster. It's a sort of "propellant" and can increase your speed exponentially.
I'm interested in more information about why you decided to alter GOMAXPROCS and what your results were from testing.
I've had a play with this myself and found that it cause sporadic and unpredictable crashing (very different style of application though - I was building a webserver). However this was an earlier iteration of Go (possibly Go 1.1 but likely 1.2) so things may have improved since then, or you might have found a saner way of tweaking it.
When GOMAXPROCS > 1, your program goes from "everything is executed sequentially" to "everything is maybe executed in parallel." This can expose data race bugs in your code that aren't present when GOMAXPROCS = 1.
You know, that's entirely possible. I was playing around with different methods of passing data between goroutines for increasing performance and I knew one of the methods I was testing wasn't idiomatic Go. However since I wasn't getting race conditions normally i assumed that the GOMAXPROCS fault wasn't down to my shonky code.
The weird thing is I thought I'd read somewhere that said Go defaulted to a process per CPU core (like the OP has hardcoded ib this project). I'm guessing that isn't the case then? It sadly wouldn't be the first time I've misread something! :(
You don't need support for complex data types for a shell to be described as "REPL".
REPL is just a Turing-complete real time interpreter. Which means even the VBA "Immediate" panel in (as seen in MS Office) is REPL. And it means Bash is REPL too.
The question you're raising is whether all REPLs are equal. Lisp machines definitely had more control over the host than VBA does. But that doesn't mean that VBA's immediate panel isn't REPL just because a more powerful example exists.
As for Bash, that's a bit of a weird one because Bash wouldn't be much without the accompanying GNU / POSIX userland. But if you're willing to include a UNIX / Linux userland into scope then Bash has just as much control over the host as Lisp did on Lisp machines. But even without the aid of forking additional executables, Bash can still modify the state of the kernel directly. eg
You are missing the part about manipulating other applications or controling GUI elements, like Powershell kind of allows via DLL interop and OLE Automation.
As for /proc/sys, not all UNIXes have such features.
In Oberon I could pipe selected text from any application into any command that had a GUI aware type signature, for example.
> You are missing the part about manipulating other applications or controling GUI elements, like Powershell kind of allows via DLL interop and OLE Automation.
There are lots of command line hooks for GUIs. Want to copy data to the clipboard from the command line? xclip. Want to pop up a notification in your desktop environment's notification bar? notify-send "hello world!" etc
> As for /proc/sys, not all UNIXes have such features.
That example of mine was clearly taken from Linux - so it goes without saying that most UNIXes would behave different in that specific regard. Even so, they'd still have command line tools for doing the same thing (and to be fair, Linux does too, even with a vaguely-Plan 9 virtual file system)
> In Oberon I could pipe selected text from any application into any command that had a GUI aware type signature, for example.
Well like I said, I'm not trying to say that all REPL's are equal, but most of what you're describing is still possible in at least Linux. I'm not saying it's as intuitive nor "pretty" as it would have been on the Oberon, but it's certainly possible.
To be quite honest, most of what you've been posting on this topic has really just been elitism. And I do actually sympathise with your point as working in Bash can be a complete hateful mess at times (even without comparing it to the old Lisp machines). But that doesn't change the fact that Bash is a REPL environment.
I hear this argument time and time again and it's simply FUD. Bad Perl is no different to bad C++ or any other language with a flexible syntax. But it's also the same visa versa.
The problem with Perl is most times people are exposed to it, it's either from code golfing sessions were code is deliberately obfuscated; or when it's basically been used as a shell scripting language and thus often written by aging Perl hackers who don't care much for code cleanliness. And sometimes people just run away screaming because they simply don't understand all the regular expressions (but to approach Perl without an understanding of Regex is a little like trying to code Java without understanding classes then moaning about the weird surplus boilerplate code)
I'm not trying to say that Perl doesn't have it's faults. It has a great many problems. But to state that Perls syntax makes it impossible to write clean code, is just a daft flamewar argument.
In both Perl and Python, "object" is a glorified hash, and its attributes are entries in that hash. Python just allows for a deeper level of syntactic sugar.
Perl's pseudo-objects are, in my opinion, one of the weakest aspects of Perl. So I'm not going to disagree with you that many other languages do that one thing better. But it's not always appropriate to nest your objects that deeply anyway (in any language, that can quickly become a mess).
In my personal opinion, I prefer C-style braces over whitespace formatted blocks. Which means I find reading function and iteration blocks much easier to read in Perl than I do in Python. I'm not saying one is "better" than the other, but just offering a counter argument for how subjective language aesthetics really is.
Just to counter your points, having done many years of Perl, and now a Python.
Perls OOP does feel like a bit of a hack. But it does make it transparent how everything works. I learned Java at University, and everything OOP was a black box and I had no real understanding of how it worked. After learning the Perl way, its really obvious what is going on because it is so transparent. Your current object doesn't have a method? Just look along the @ISA array until you find an object that does have it.
Pythons whitespace is a pain at first, but having used it for a few years, one problem I do not miss is loosing a brace, when reorganizing blocks of code. You cut a few lines of code and paste it somewhere above or below, and your IDE shows you you are missing a brace somewhere. The indentation looks fine, so you can't see where it is.
The whitespace thing is worth it to get rid of that problem alone.
Aren't there just as many problems with cutting and pasting python and getting either slightly off indentation or mixed spaces/tabs? If the IDE fixes the problem, I don't see why it's any different for braces as it is for whitespace. There's easy ways to identify both.
Arguing that one is better than the other is like arguing over which colour the best. Which is why I get so utterly sick of Perl being compared with Python - they are all going to have their strengths and weaknesses so at the end of the day, the "better" language / syntax boils down to personal preference.
I wasn't arguing that either way was better, just seeing the positives where negatives have been noted.
I personally haven't wasted anywhere near as much time with Python indentation compared to missing braces. I hated the whitespace thing at first, and it was only after going back to doing some Perl I noticed that the problem wasn't present in Python.
Though the fact that most other languages use braces is a pain, as it makes swapping between Python and Java / Perl / JavaScript / etc tricky, as I tend to get into the habit of using or not using semicolons at the end of a line.
I'm going to disagree with you: as someone who has worked in an extensive Python codebase, based on the snippet above, I have zero clue what is actually going on. Those could just be attributes in the object, or they could be properties with arbitrarily complex code to calculate the resulting object. It could be the same object, or a freshly-allocated object, or an object that exists already. The index operator could be on a list, dictionary, or custom class with, again, arbitrarily complex code. All of that code could even be written in pure C for all I know! That single line of code could be a rats nest of a thousand lines of Python, or C, or both. And that's not even getting started with the possibility of metaprogramming or creating new classes by wrapping an existing class at runtime.
Saying that the snippet is obviously not using method calls is naive. Python is too flexible and allows programmers to do too many clever things for that, all hidden under "nice" syntax.
EDIT: Forgot a case for what that code could be doing: it could be accessing a module with globals.
I know this is possibly the saddest thing anyone has ever said, but the computing museum is one of my favourite places on earth.
It's a joyful place with so much old technology yet a refreshingly hands on attitude. I don't think there was a single exhibit that wasn't interactive by one method or another - which really matters when you're talking about technology that is largely at an age where kids are too young to have grown up with so it gives them a chance to play with the predecessors to their much loved consumer hardware - and it gives us adults a chance to do more than just reminisce about the fun days experimenting with emerging technologies.
I'd highly recommend that museum on it's own merit; let alone spending the day exploring the site and Bletchly Park as well.
On the subject of early technology I highly recommend 'The Centre for Computing History' in Cambridge. They have a good collection and a lovely atmosphere.
They're currently located in an industrial estate in Cambridge, I'm sure if/when they move they will get much more attention.
> I would also recommend it for studying operating systems
Perhaps not if you plan of contributing code to any open source OS. Practices like this can leave projects exposed to intellectual property violations.
This is why reverse engineering usually requires more people, each who isn't privy to the previous persons source material.
