1. 18

    Probably worth considering the authors followup when reading this, posted a week later: https://dev.to/jimsy/please-keep-using-ruby-4771

    1. 7

      I ended up away from my PC for a bit much sooner than I expected, so I didn’t get to take part in the discussion here, but I rather feel like most of the comments here missed the point.

      While I’m not disputing that no programming language in practice can be turing complete, the mistake is jumping into thinking about implementations when the article is considering instead the abstract specification of the C language. In particular, the reason why C is not turing complete is because the specification requires pointer semantics that bake in enough implementation details that instead of breaking turing completeness, it’s required that no C implementation could ever be turing complete, even in the face of changing basic rules about computing.

      In another thread of comments, there is the request as to a language that would satisfy the authors definition of turing completeness “in theory”: Brainfuck. If you consider brainfuck as “a bidirectional infinite tape with the following operators […]”, then we have a language specification that is turing complete, even if no implementation can be. One could argue of course that this means that the specification can never be fully and correctly implemented and that’s true, but you can also write specifications that equally state neither behaviours that force turing incompleteness (C), nor make explicit demands that are impossible to fulfill (brainfuck), and instead leave such details out entirely (imagine a language that deals only in objects and operations on them, without reference to their representation in any implementation whatsoever).

      1. 1

        Thanks for clarifying this a bit. I’m still confused.

        the specification requires pointer semantics that bake in enough implementation details

        If I understand, here you are saying there’s “too many details included in the spec”. But I don’t understand the next sentence fragment at all.

        that instead of breaking turing completeness, it’s required that no C implementation could ever be turing complete, even in the face of changing basic rules about computing.

        On its own, “it’s required that …” could make sense but the two sentence fragments don’t match and make no sense (to me) together.

        In another thread of comments, there is the request as to a language that would satisfy the authors definition of turing completeness “in theory”: Brainfuck. If you consider brainfuck as “a bidirectional infinite tape with the following operators […]”, then we have a language specification that is turing complete, even if no implementation can be.

        Could you say what the equivalent for C is here? Consider C as “a [???] with the following operations”?

        1. 3

          Could you say what the equivalent for C is here? Consider C as “a [???] with the following operations”?

          The problem is that what the gp said isn’t quite true. Brainfuck isn’t a bidirectional infinite tape with the following ops. Brainfuck has a bidirectional infinite tape, and the following operators. C has a declarations, expressions, control flow, functions, memory, macros, etc. etc. It’s tempting to say that brainfuck is the bidirectional infinite tape, but it’s not, it’s a programming language that has only a couple of things.

          1. 2

            Could you say what the equivalent for C is here? Consider C as “a [???] with the following operations”?

            The problem is that in C, there is required to be a maximum number of valid pointers and as a result there is required to be a maximum number of valid addressable bytes, of a maximum bit length. This means memory is bounded and the C specification describes a finite state machine.

            You can implement a turing machine in Brainfuck. You cannot implement a turing machine in C.

            1. 1

              A programming language specification can leave the harsh realities of the real world to the implementation, and if you were to find some bizarre reality where genuine turing completeness is possible, you could in essence be able to implement some languages in a way that exploits this new theory of computation and create a genuinely turing complete language implementation.

              In C, however, there are specific rules about how pointers must be implemented that mean even in this world, you’d have to choose between correctly implementing the spec, or being turing complete, as the rules themselves have implications that mean you could not exploit the new reality to achieve this. These restrictions aren’t apparent to us everyday because we don’t have a world where turing completeness is possible, but that doesn’t mean the specification has to reflect those limitations - by choosing to leave the details of representation to the implementation, implementors could choose to make it as strong as their current reality allows.

              So, overall, what I mean in that sentence is that in C, implementations do not lose potential for turing completeness as set out by the spec, limited by reality, but instead start from a spec where it is already by definition not permitted.

              As for what C “is” in comparison to brainfuck, really Elronnd has it. The language I used is a little bit of a red herring in that brainfuck isn’t the tape in the same way the closest thing that C would “be” is some abstract machine you could build from the spec. It’s easy to build a mental model where the only object is a tape/machine, but the language specs really instead have the machine and also have rules to about how they work and are manipulated. I can only apologise for being so relatively casual in a discussion where the language needs to be precise.

          1. 6

            As well as the link above, if you are affected by +r in the channel, please have a look at our registration FAQ, which makes the above mode irrelevant to you, allowing you to talk past it: https://freenode.net/kb/answer/registration

            As always, apologies for the issues we have right now, and we have a number of our volunteers working hard to deal with it.

            1. 2

              No apologies needed. Dealing with such an irritating and sadistic troll must be dispiriting, I’m sorry you have to deal with it. We’ve really appreciated Freenode’s reliability and support for years now.

              I haven’t seen spambot attacks in a few hours. I’ve removed +r from #lobsters in the hopes this is done.

            1. 0

              Redmine anyone.

              Trust me. I like this too. But I guess I am a Redmine convert.

              1. 17

                If you want to suggest redmine, that’s ace. It’s good to know about the alternatives - but please back it up with why you think it’s a strong competitor. If you’re supporting it here, you probably have insight worth sharing with us.

                1. 1

                  Well it has a nicer interface I think. Has support for plugins from what I remember and yeah. May as well check out their site. I used it a while ago, so I cannoy remember much.

              1. 3

                Why did this end up a slack channel rather than IRC? Many, to most, of these tools have IRC presences and frankly I just like not having to run multiple slack instances, which have numerous drawbacks.

                1. 1

                  IRC works really well when you have a core team who spend a lot of time in a topic-specific channel where visitors can stop by and engage with them. That’s great for channels focused on individual open source tools, as you point out. One of Slack’s strengths for community channels is that it handles low volume conversation better because you can check it intermittently and catch up on what you missed. Being able to respond to questions that were asked when you weren’t around is a big plus.

                  Our intention here definitely wasn’t to try to take the place of project-specific IRC channels at all. We just felt that there wasn’t really place to talk about experiences with different tools and tactics at a higher level. We get emails from people all the time about topics like this, and our hope is that making these sort of discussions public will be helpful to the community.

                  1. 2

                    It’s absolutely not the the case that I fear that you’re trying to displace people from project channels to slack, apologies if it’s come across that way. It’s more frustration that for a community that’s fairly well established on IRC, there’s pressure to fragment across platforms.

                    While you present the argument that Slack is better for low-traffic communities, I’m not sure I agree. You mainly rely on these points:

                    • You can check slack intermittently and catch up on what you missed
                    • You can respond to things that happened when you weren’t around

                    Both of these points are well covered by IRC. While it’s true that the core protocol doesn’t cover it, it’s now the standard practically to use a bouncing service that permits it, or self host your own. A bunch of ZNC specific providers can be found here: https://wiki.znc.in/Providers , and additionally there’re services like https://www.irccloud.com/ that provide the entire system including a web client.

                    Slack has some downsides, like really poor community management, instead deferring to out-of-band systems to deal with things like harassment as well, essentially showing it’s colours as a business service offering. For example, there’s no ability for an individual user to ignore another they do not get along with or are being harassed by, with Slack instead suggesting this be resolved with HR policies.

                    1. 1

                      “Slack is better than IRC” is like saying “gmail is better than SMTP”.

                      Slack is owning:

                      • the server (that replaces the IRC server)
                      • the heavy client (that replaces the IRC client / bouncer)
                      • the light web client / application (that replaces an SSH server)

                      People who appreciate running themself the programs they use go to IRC (get its hand dirty).

                      People who prefer not be involved in maintaining anything go to Slack (living in the “cloud”).

                      This is how I get my hands dirty: on a server: $ abduco -A irc weechat.

                      You can even have this in a laptop .bashrc:

                      alias irc='ssh user@your-server.tld abduco -A irc weechat'
                      

                      And then you have the same feature of “being able to respond to questions that were asked when you weren’t around”. :)

                  1. 1

                    As mentioned by a few people, there are some flaws in this in what it means for you and your readers following it. Something I’ve considered a worthwhile approach, however, is similar to this.

                    We have a paired group at university where each week we pair off and learn about a particular subject. Later, we come back together and teach each other what we’ve learned. It’s useful to go head to head on the misconceptions you’ve each picked up, and you can correct and work with each other to both develop a better understanding.

                    1. 14

                      On the IRC side, the groups team received an email from a Void representative that was resolved, I’m unsure why they’ve included that they are still hoping to get access to their channels, because we believe the issue was sorted :(

                      If there’s anything we still need to do, you can catch me as kline on freenode, or email us at projects@freenode.net

                      edit: we managed to reach out for them, it looks like the post was written ahead of time, before we had resolved the issue. The Void channels on freenode should be safe and sound and back with active Void contributors!

                      1. 4

                        Something this paper touches on is that ultimately, we’ve made it so that compilers don’t work for us, because we’ve set them toxic goals.

                        By making compiled code size and speed the be all and end all of how we compare compilers, we’ve driven compiler developers to USB/IDP/UB hackery that means they can chase the benchmarks we pretend to care about, when really we should be encouraging compiler devs to instead develop for correct-in-practice.

                        1. 2

                          The example code is in Java – I’d like to see a version of this in C!

                          1. 1

                            Is there a C hashmap implementation you’re particularly thinking of?

                            1. 1

                              I was going to say CPython’s hash tables with string keys. That might work, but they’re pretty complicated, and with the methodology he uses, I don’t know how you would take out the bytecode dispatch overhead. It looks like he just directly calls the hash function (hash('abc') in Python) in a loop and subtracts.

                              However I seem to recall that Python was actually faster than Go in some hash table benchmarks. (early Go at least) That is, if you wrote a simple loop to insert into hash tables like this one, Python’s highly tuned hash tables would outperform a compiled language! They’re both of course written in C – in some sense you’re comparing C to C, but it shows that the interpreter overhead sometimes doesn’t matter.

                              (And I don’t have a reference unfortunately.)

                              Maybe an easier one would be C++ unordered_map which I use here with a similar hash function:

                              https://github.com/google/rappor/blob/master/analysis/cpp/find_cliques.cc#L81

                          1. 1

                            The background to this [lobste.rs] post is, I imagine, the recent controversy surrounding the inclusion of Elasticsearch.

                            Elasticsearch has been included in the reference Mastodon client as an optional extra to allow better searching. While this is nominally a good thing, and likely used honestly, there exists a subset of users concerned that Elasticsearch has an awful lot of features that now exist alongside search, and help to find trends and produce datamining insights.

                            Many people left Twitter to escape that platforms omnipresent analytics and monetisation of users. These same people are concerned that the current direction of Mastodon is moving towards that, even if through honest decisions, by the inclusion of software that enables it.

                            1. 4

                              No, that’s quite unrelated to it :)

                              1. 1

                                I don’t get that impression at all. I see this post as outlining an alternative to Mastodon for folks who may want a simpler approach to solving the same problem while offering users similar features.

                                1. 1

                                  I should probably clarify, I mean this being posted specifically to lobste.rs. That said, while Pleroma is a fully featured implementation that existed before the concern of elasticsearch, it’s being touted especially as being free of the concerns recently raised.

                              1. 2

                                Yeah, I had a play with this a while ago and it works pretty well: in a field trial among ~20 mostly non-tech friends, only one noticed that there was no way to set a password.

                                1. 2

                                  One of your comments is that cookie security wasn’t taken seriously. Could it be the case that you can include in the cookie a per-browser fingerprint as well as a key, and then use a HMAC to hide this information and ensure the authenticity and integrity.

                                  If an attacker were to steal the cookie, the server could identify that even though the secret is valid, the browser has changed significantly enough (cookie theft in the positive case, a sufficiently serious upgrade in the negative case) and force a new login for the browser?

                                  1. 1

                                    I thought this way too until I started tracking our users’ browser fingerprints. Then I discovered that they changed way more than you’d expect; I never investigated why but saw that it was unreliable enough to not pursue.

                                    1. 1

                                      Yeah, I think the very fast browser update cycle these days might stuff this idea up.

                                1. 7

                                  This is such a sad story.

                                  This is also a good example of why making an android level user friendly desktop Linux distribution should be number one priority for FOSS developers. We need UX designers, Artists, and non-technicals in FOSS.

                                  1. 7

                                    Development is one of the few “creative” areas where working for free is considered not-strange (it’s still not common). For various cultural reasons that essentially stem from the abuse of artists, most higher creatives strongly resist working for free.

                                    If my phone were charged I’d take a picture of the document that discourages free work of just about any form to the creative students at my university.

                                    1. 6

                                      A big part of this is probably the existence of copyleft licenses which provide a legal mechanism to guarantee that continued work will be contributed back to the community. I wonder if a similar mechanism exists for artists (perhaps creative commons?).

                                      It’s also important that software has a useful notion of “contributing back to the original work”, and that contributing is both standardised (my copy of git and the language compiler probably works the same as yours) and idiomatic (diffs, patches, and PRs are all well-known tools). It seems possible in theory to have large, open source, collaborative design projects (where many designers contribute back to a single project under copyleft terms), but I’m not aware of a “standard” design format with both a critical mass of users and good support for decentralised contributions.

                                      1. 2

                                        I think free work should be discouraged if someone else is profiting. However if it such a taboo because they have a history of being abused and low quality of life perhaps we should start an money pool to pay for contributors who don’t have a higher paying job like software development.

                                      2. 2

                                        Personally, I don’t think FOSS is a good fit in that situation.

                                        Just my opinion, but I feel the open source model works best when the contributors are working on the project because it’s something they want or need themselves, OR because the project offers some kind of unique and interesting challenge.

                                        A novice friendly desktop doesn’t fall into either category.

                                        1. 2

                                          Funny because the android OS gets a LOT of contributions. Just because something is novice friendly doesn’t mean it has to be crippled in any way. Also there’s a lot of unique and interesting challenges in making a user friendly operating system.

                                      1. 2

                                        The software here sounds like it could be Dragon with the Verbal Vim commands? It sounds almost identical to this 2013 PyCon talk by Tavis Rudd: https://www.youtube.com/watch?v=8SkdfdXWYaI

                                        1. 4

                                          From the article:

                                          “The silver bullet” came when Moyher found a video presentation by developer and coder Travis Rudd, which appeared online in 2013 shortly after his diagnosis, that took viewers step-by-step through Rudd’s own RSI experience. The 28-minute video shows Rudd breaking down exactly how he customized Dragon NaturallySpeaking, a voice-recognition software suite, to write code in the Python language using nothing other than his voice. This countered the wisdom Moyher had seen in forums about RSI and coding, declaring that Dragon’s usefulness in coding was limited. “Don’t do it, it’s impossible,” was the common wisdom, Moyher said.

                                        1. 2

                                          Suggest visualization.

                                          Is this really a privacy thing? This is behavior explicitly advertised by the product.

                                          I’m not sure that getting a lot of “look at this totally expected behavior of modsern products” posts here is good. Tends to lead to clickbaity stuff.

                                          1. 5

                                            I think really this isn’t the advertised behavior. While Strava does advertise activity tracking, it’s not until you mix in the occupation related PT required in the military that this emergent behavior appears where you can see very regimented fitness activity often in areas that otherwise wouldn’t have it. Together, you see the initially surprising - but entirely reasonable in hindsight - ability to locate bases. It’s something that makes you go “huh!”.

                                            Strava advertises fitness activity tracking. The military takes fitness seriously. Combined, Stava can be used to identify the location of abnormal areas of activity, ie, military bases.

                                            This is the tweet that really sums it up: https://twitter.com/gavinsblog/status/957786002751332354

                                            1. 1

                                              The users of these devices had an expectation of privacy which has been violated. I doubt they believed their use of a fitness device could reveal their position to the enemy.

                                              I think it’s decent news and worthy of attention/discussion.

                                              1. 3

                                                Have you used Strava? I have, and it is very clear when you are posting an activity publicly. (My understanding based on discussion elsewhere is that private activities are not included in the heat map. Strava also provides a feature whereby you can post an activity publicly but hide the start/end points so that your home address isn’t apparent; my understanding is that these hidden sections of public activities are also omitted from the heat map.)

                                                I have no more expectation of privacy when I post a public activity to Strava than when I post a public photo to Instagram, or a comment to Lobste.rs.

                                            1. 1

                                              Has anyone been able to find the supplementary materials? I’ve had a poke around on archive.org, as well as probing through the current Notre Dame site, but I haven’t had any luck yet.

                                              1. 4

                                                For the next couple of weeks I’m going to continue to hack on the Thymio, Aseba, and Jetson stuff I have for my Masters.

                                                I’m working with one other on an (academic) year long project to implement SLAM to map unfamiliar environments, and then use evolutionary algorithms to identify the best strategy to achieve various goals. Since the bot hardware is cheap and cheerful, the main challenges we’re facing is developing any kind of useful SLAM output, and navigation through it. For simulating and developing improved strategies, the plan is to handoff to the Jetson strapped on top and use the GPGPU cores (OpenCL) to be quicker than the PIC device in the bot itself.

                                                1. 1

                                                  Cool projects. I don’t know what SLAM is in this context. Turning it into a link would be helpful.

                                                  1. 3

                                                    They probably are talking about Simultaneous Localization and Mapping

                                                    1. 1

                                                      Oh, OK. That makes sense. Thanks.

                                                1. 2

                                                  The slug in the URL here has somehow become notes-of-cpython-lists, when it should actually be notes-on-cpython-lists, not the of vs. on.

                                                    1. 1

                                                      Actually decent article.

                                                  1. 10

                                                    Honestly, I can’t help but to feel very bearish on ETH. I really like the idea, but I think the implementation is poor, and the community is poorly aligned in values to making it a success.

                                                    The most important construct in ETH that sets it apart from other currencies is the Smart Contract. I don’t believe though that these are either smart, nor contracts. Whether or not you agree with the resolution of the DAO hack or not, the fact that we consider it a hack to be in some way resolved indicates we do see smart contracts as programs that can and should be changeable to better meet the intent.

                                                    Based on the DAO and a number of other issues with smart contracts, I don’t think they are smart based on the design of the language being so poorly adapted for the kind of verification needed to make robust contracts. It isn’t smart.

                                                    Based on the communities willingness to fork over contract actions they don’t agree with means they aren’t contracts. In real life, if you’re duped by a creative but legal (as judged by the legal process, or in this case the execution on the blockchain) interpretation, you need to suck it up and move on. In Ethereum, you can fork, and in practice the group that lead to the fork of ETH were a minority. Smart contracts aren’t contracts because by the decision of a few they can be rewritten without the agreement of all involved parties.

                                                    Ultimately, if I were looking to do non-hobbyist business, either as the business or a customer, for these reasons I wouldn’t feel comfortable using Ethereum.

                                                    1. 19

                                                      I am not a lawyer, but I did grow up with one, and I’m pretty sure a legal but clever and tricky contract has legal grounds to be thrown out in court.

                                                      As a kid I was curious if the “tiny fine print that you couldn’t read” could really be used to trick someone. It can’t. The legal system is very aware of the distinction, it’s called acting in good faith.

                                                      Again, not a lawyer, not legal advice, don’t make choices based on what I’ve said, but it’s not as cut and dry as you claim it is.

                                                      1. 15

                                                        And contracts with “bugs” in them (i.e., that don’t accurately represent the intent of the parties) aren’t taken literally either. There are rules/principles about how to interpret them that are much more nuanced than that. Only a programmer who doesn’t get out much would think that a better approach is to eliminate the potential for ambiguity and then always interpret contracts literally.

                                                        1. 7

                                                          I generally understand your point and agree with it, but what I’m suggesting is that the execution of a smart contract is the legal process in this context.

                                                          It’s not that it’s right or wrong that the contract was interpreted/executed in a given way, it’s that after the field has been set and the dice cast, then going back in time and writing out the execution because some definition of majority (usually a minority in practice) didn’t win is the issue.

                                                          Changing how the outcome played out after the fact that it was interpreted and executed feels (in the context of a smart contract being interpreted by the legal process of the block chain) like an extrajudicial action by people who lost out.

                                                          1. 5

                                                            The legal system has been dealing with smartasses since before your ancestors were deloused.

                                                            Think of it like the efficient market hypothesis: People have been banging on legal systems for so long that you can reasonably assume that all of the interesting stuff has been found, and is either a known technique or is already illegal. There might be exceptions to this, but the fact the system is administered by humans who exercise human judgement closes a lot of novel loopholes, as well.

                                                            1. 3

                                                              I’d go one step further and assert that, in legal systems that have been functioning for centuries and are thoroughly debugged, some obvious glaring flaws will continue to exist, but they are those that are actively maintained by some group which has an extraordinary amount of power and stands to gain an extraordinary amount of wealth from them.

                                                          2. 4

                                                            I used to think this way, until I realized that all these high-profile bugs in applications on Ethereum have very little to do with the code in Ethereum.

                                                            The DAO is a good example. It was not written by the core Ethereum project. It was a distributed application written by unrelated developers, and crowdfunded by a token sale. Blaming the Ethereum project for DAO’s code quality is like blaming the Unix developers for a segfault in some third-party app.

                                                            1. 3

                                                              You don’t have to blame the core developers for the DAO contract code’s bugs to blame them for forking the block chain to “fix” the bugs for THE DAO developers.

                                                              Those are two separate acts from two separate groups of people.

                                                              1. 1

                                                                On the other hand, one of the Ethereum founders was responsible for the Parity bug.

                                                                1. 1

                                                                  I agree with you but think the conclusion you draw is incorrect. While Solidity itself is not a bug, the language itself is part of the design of Ethereum, and by using a language (Solidity) that is so poorly adapted to verification, it’s made it easier for users to write buggy contracts.

                                                                  1. 1

                                                                    C is buggy, but that didn’t kill Unix.

                                                                    Unless a credible competitor appears, I think Ethereum will continue to dominate the smart contracts space.

                                                                    1. 2

                                                                      C isn’t buggy. Solidity isn’t buggy. Their use in the systems mentioned have lead to more bugs, and an environment more user- and developer-hostile than had they instead been replaced with other languages.

                                                                      I agree that Solidity won’t kill Ethereum, but a credible competitor will. I think it is almost a certainty that the biggest shining star of a more mature smart contract blockchain system will be better verifiability in the language. It might not be the immediate killer of Ethereum, it might not even be the technology that kills the Ethereum killer, but I really do think that a verifiable in practice language will be a requisite feature for a smart contract technology that isn’t as known for being a massive footgun as Ethereum is.

                                                                      1. 1

                                                                        Wait, since when is C buggy?

                                                                        1. 1

                                                                          I should have been more precise.

                                                                          While C itself is not a bug, the language itself is part of the design of Unix, and by using a language (C) that is so poorly adapted to verification, it’s made it easier for users to write buggy programs.

                                                                          Buggy programs didn’t kill Unix, so I doubt Ethereum is in danger.

                                                                1. 2

                                                                  Why does the option have a -unknown-unknown suffix?

                                                                  1. 14

                                                                    Compilers often consider their target as a triplet in the form machine-vendor-os, such as x86-pc-linux, which would describe a compiler targeting x86 IBM compatible machines running Linux. In the case of webasm, the machine target is webasm, but the vendor/OS are irrelevant and not known at compile time.

                                                                    1. 3

                                                                      Thanks for the clear explanation :)

                                                                      1. 2

                                                                        The Rumsfeld of platforms?

                                                                    1. 5

                                                                      Things I have to do this week - mostly coursework:

                                                                      1. Continue my work on the evolutionary algorithm for my classes - probably going to add simulated annealing as well has hillclimber strategies and see where they suit being applied.
                                                                      2. Finish up my implementation of rfc1149, which should be a laugh, again for class
                                                                      3. Prepare and run the completathon at my uni (hackathon, but the theme is no new projects - polish off those side-projects you’ve had wasting away for months!)

                                                                      I’ve been speaking to some of my friends about further embedded stuff, but it needs to take a bit of a back seat for this week. Between uni work, extracurricular work, and my non-tech stuff, I’m struggling a bit to keep my head above water.