Recent Forum Posts
From categories:
page 1123...next »
yoshi_120 (guest) 16 Feb 2017 15:40
in discussion Hidden / Per page discussions » SRE's review of Democracy

The probleme with these points is that what you call "democracy" has never been democracy. Democracy not exist in modern nation bacause The Founding Fathers of USA and most influent people during French Revolution has never be democrate. On the contrary they describe democracy like chaos and Plebe dangerous power;

The word democrate is during dark age a rare word and used by few erudite and describe Ancient Greece political model. The using of word increase during modernity but the original sens has been perverted.

Worst, the Old Regime of France during monarchy is more democratic than modernity. The King of France not really manage his kingdom. He prefer fuck woman and hunting. Their is a great autonomy of township with votation of things with hands or black and white balls. Even during plague people made assembly across river.

Francis Dupui-Déri (Quebec)
UQAM Interview
Démocratie Histoire politique d'un mot aux USA et en France

Cornelius Castoriadis - Une leçon de démocratie (Chris Marker 1989)
http://www.derives.tv/Cornelius-Castoriadis-Une-lecon-de

by yoshi_120 (guest), 16 Feb 2017 15:40
Apostolis (guest) 12 Feb 2017 10:25
in discussion Hidden / Per page discussions » SRE's review of Democracy

Consider this for your next chapter.

A. The software is rewritten in a literate programming style, like a book that can be understood by people.
B. Create an issue tracking system, that is easy to use by society in which society provides feedback.
C. Provide a "croudfunding" site where society takes decisions about and funds changes in the governing structures.
D. Have programmers do the changes.

This might look like fiction but it is exactly what I am working on. So maybe people will call you the next Jules Verne after that :)))) .

by Apostolis (guest), 12 Feb 2017 10:25

Hm, it's a fantasy, don't take it too seriously. My point was to attack the idea that the democracy as we know it is, in Winston Churchill's words: "The worst form of government, except for all the others." In reality, if you look at the system from system-engineering perspective, it's easy to imagine piecemeal improvements to the system that would make it work better. For example: More transparency. More checks and balances. Better feedback loops etc.

by martin_sustrikmartin_sustrik, 12 Feb 2017 09:26
Apostolis (guest) 11 Feb 2017 17:13
in discussion Hidden / Per page discussions » SRE's review of Democracy

Who is the reviewer and who appointed him in that position?

You see, the problem is the democratic change and control of the governing structures.

In the foundation series, there were scientists that were able to predict the future of society and alter its course.

I think that it is time to incorporate in our fiction that the all-seeing eye that is able to view society from above and take decisions is society itself.

by Apostolis (guest), 11 Feb 2017 17:13
catbrainland (guest) 10 Feb 2017 21:42
in discussion Hidden / Per page discussions » Be just or be data-driven?

One bit martin (perhaps intentionally to spark the discussion) left out. The machine can most certainly become racist, because our current ML techniques pretty much amount to "generalizations box" - it's a magnifying glass of our collective data, including prejudices - but not true consciousness making its own decision.

In practice - because of institutional racism, a lot of black people are overrepresented in crime in the US. We feed this past overrepresented data as the learning dataset and the machine creates neuron weight circuitry for "aha! black person, most likely a criminal!". Incidentally, it's the exact same mechanism how prejudice self-amplifies in the general population, too.

One possible approach could be "opinion affirmative action". Basically introduce reverse bias in the input data against known prejudices - even if it counters past statistics. And hope that it will break the previous feed-back loop of self-fulfilling prophecy (fe. assumptions that black people are criminals is what actually may set em on criminal path).

Same goes for a lot of ML systems. You won't get justice, only a coarse statistical estimation based on previous observations - but not true rational reason, unless you give it far, far more data (as well as advanced reinforced ML training techniques such as generating hypotheses from the corpus and testing those). This is far more difficult than just dumping some narrow database data from the past, yet is what most commercial "screening" oughta do, otherwise they merely automated the coarsest of human prejudice.

by catbrainland (guest), 10 Feb 2017 21:42
Apostolis (guest) 06 Feb 2017 14:25
in discussion Hidden / Per page discussions » Few thoughts on current political situation

You consider that it is political corruption that people do not like.
Let me generalize it to say that it is political decisions that are against the majority of the people that they do not like.

Now why does political corruption exist? Politicians have political power but they cannot benefit from it individually. The only thing they can do is to sell their political power for money. If the organizations that give them money are democratic, then in a limited sense, we would have some sort of democracy.

But companies are not democratic. They are not accountable to the people for what they do. People work 1/3 of their life in them. Moreover, the Capitalist economy is in crisis, something that the people cannot control.

In conclusion, it seems that the lack of democracy in both the company level, as well as the whole economy level is at fault.

2. Not direct democracy but real democracy.

There are statistical methods to check whether the opinion of the people coincides with the decision of a governing body. We need to build evolvable decision making structures and check whether those structures take decisions that are in agreement with the people's.

If they are not, we evolve them again until we have the correct structure. Each field of inquiry requires a different structure.

by Apostolis (guest), 06 Feb 2017 14:25
Thomas (guest) 06 Feb 2017 11:34
in discussion Hidden / Per page discussions » Few thoughts on current political situation

Hi Martin

I agree with most of your overall analyse but I have doubts about your proposed solution.

Many issues require in depth studies, analysis, and extended debate - something you can't expect everyone to invest into on all matters.

The complex nuances will make the vast majority of voters susceptible to "easy solutions", populism, appealing rhetorics and slogans.

Strategies involving multiple steps will be launched simultaneously just to be down voted by supporters of another strategy, leaving behind half-attempts. Each step would have to be championed even though people agreed on the overall strategy.

We would have constant fundraising and lobbyism leading to democracy-fatigue.

Smaller/frequent elections would mean less turnout which would make each vote more susceptible to both legal lobbyism and corruption.

Let's use foreign policy on the Middle East as an example. How many people do you know, have the actual knowledge about history, politics, anthropology, war, finance, strategy, relations among the countries, groups, etc., etc. in that region to have a qualified opinion? I certainly don't. Would you feel comfortable about answering a question such as: "Should we impose a sanction on X" followed by pages specifying exactly what, who, when in details only 0,01% of the population have ever heard about?
Would you want to spend weeks studying this in detail to vote qualified?
Anyone saying "X caused war, Y will fix it" does not have a clue.

I don't believe in direct democracy. Quite the opposite. I think we might need more layers - some that are closer and thus easier to hold accountable and debate with.
The first layer should be so close that you can pick someone you trust by their values to represent you, someone close enough that you can talk to them. Their votes should be transparent, and when you don't understand or is worried, you can debate with them and either be settled or move your vote.

by Thomas (guest), 06 Feb 2017 11:34
Martin Sustrik (guest) 05 Feb 2017 08:00
in discussion Hidden / Per page discussions » Code Generation & Visual Smog in Code (part I)

I am not sure. Imagine LISP writing LISP. The problem is that while you can easily read the code of the generator, the generated code is spread throughout the source code and thus not easily readable.

by Martin Sustrik (guest), 05 Feb 2017 08:00

Hello Martin,

Having come here after discovering nanomsg, I have ended up spending the last two evenings reading multiple articles (almost all of them) from your blog, which I find very interesting and thought provoking.

I just wanted to mention that for the problem of writing code which writes code which writes code … which solves a problem, also fitting would be perhaps a homoiconic language.

CG

by Papa RoachPapa Roach, 04 Feb 2017 01:07
Martin Sustrik (guest) 02 Feb 2017 12:45
in discussion Hidden / Per page discussions » Structured Concurrency

Unfortunately, I have no experience with Rust. But generally speaking, yes. Structured concurrency is just a programming paradigm and should be doable in any language that supports concurrency.

by Martin Sustrik (guest), 02 Feb 2017 12:45
Greg Edwards (guest) 01 Feb 2017 00:13
in discussion Hidden / Per page discussions » Structured Concurrency

Your description sounds very close to how Rust https://www.rust-lang.org/en-US/ handles concurrency via the borrow-checker etc., so I wonder if Rust could be extended to implement what you are recommending.

by Greg Edwards (guest), 01 Feb 2017 00:13
Sean Charles (guest) 31 Jan 2017 12:48
in discussion Hidden / Per page discussions » The Second Use Case for Literate Programming

I used noweb many years back to produce a series of Fully documented Drupal 6 modules to great effect. Admittedly I am a big fan of LP and fortunately the client only wanted a solution that worked. Armed with Leo editor (an awesome tool) and the notion of LP I wrote and delivered a dozen custom Drupal modules that integrated with external systems.

The beauty of LP in this case was, as the author states, in being able to describe the intention of each part of the code and I also highlighted key areas where external changes might affect things e.g. a different URl endpoint or database or such like.

I think there *is* a future for LP but not in the mainstream. Having worked in that stream for many years, and trying not to be disrespectful, the "main stream" doesn't care about a beautiful thing like LP, all it wants is a solution on time and on budget and it doesn't care how it got there.

If you have done LP you know that it can be very slow BUT you don't get issues (well not many) later. You could say that current BDD/TDD/CI tools make LP redundant but I am not sure. If there is one thing I truly hate it is "docblock comments" that are out of date or just plain wrong. This is not to say that somebody couldn't just hack the code part of an LP file and not update the text, or, worse, edit the code directly because they didn't understand how to use tangle and weave and in that one second they broke the entire thing because the LP source is now no longer accurately describing the live code base.

There are so many issues to resolve, there are no tools to support LP in the sense that PHPStorm or RubyMine support development.

A long way to go… but I think LP will live on… at least in my heart anyway!

by Sean Charles (guest), 31 Jan 2017 12:48
hyfrey (guest) 23 Jan 2017 16:03
in discussion Hidden / Per page discussions » Structured Concurrency

gRPC is rpc framework open sourced by google that support context between client and server. It support many languages.

by hyfrey (guest), 23 Jan 2017 16:03

Maybe a suitable proxy question is "do you use Emacs"?

I ought to love Emacs: it's a fully programmable environment. But I just can't cope with memorising Ctrl-A Meta-B Meta-A sequences. I can't even exit the damned thing; I open a new shell, use 'ps' and send it a 'kill'.

All I want to do is edit a file. I want to be thinking about the interesting problem in hand, not the tool.

But of course, there are others who absolutely love Emacs and couldn't be without it. I think their brains are wired differently. Perhaps I just have a mental block against multiple modifier keys, particularly when there is no such labelled key on the keyboard - although thinking of the sequence as "Ctrl-A ESC B ESC A" doesn't really help either. Does an editor *really* need to be that hard to be productive?

Reference: doing this for nearly 40 years. I started back in the days of things like PET Basic and Borland Turbo Pascal. Hence I can cope with sequences like Ctrl-K X, and for preference I use the "joe" editor which still has them :-) But for complex searching I'll still shell out to the command line and use grep.

by Brian (guest), 19 Jan 2017 15:22
Brian (guest) 19 Jan 2017 13:33
in discussion Hidden / Per page discussions » The Cost of Abstraction

A common unhelpful abstraction is the implicit polymorphism in dynamically-typed OOP languages - when in the majority of cases it's not even needed.

Consider a function like this pseudocode:

func foo(s):

do something with s.length()

This is polymorphic: which length() method is called depends on the type of 's' at runtime. You may have a lot of trouble locating the correct length() method in the source, especially if this code calling point is deeply nested and you have to work backwards to try to infer the type of 's'.

But in many cases, func foo may be written only to make use of objects of class Bar. It could have called the one possible function explicitly:

func foo(s):

do something with Bar.length(s)

Bar.length is exactly one function and can be quickly located in the source code. (Its implementation *might* even do different things depending on the type of s, but this would be localised)

In statically-typed languages you write func foo(Bar s) of course, restricting the type of s. What I'm saying is, you *could* have made the intent clear even in the dynamically-typed language as well; but most people don't, relying on dynamic method dispatch to save a few characters of typing.

The OOP approach also leads to unnecessary design quandries. If you have code which acts on an instance of a and b, should it be a.foo(b) or b.foo(a)? I would rather just write foo(a,b) and the problem goes away. foo is still an abstraction, but at least its implementation (and hopefully documentation) can be easily located.

by Brian (guest), 19 Jan 2017 13:33

Have to say, you have a great bias against China.

by RocWay (guest), 14 Dec 2016 08:33
Daniel Tracy (guest) 13 Dec 2016 03:14
in discussion Hidden / Per page discussions » Why should I have written ZeroMQ in C, not C++ (part I)

Martin Sústrik,

I really enjoyed your May 2012 post "Why I should have written ZeroMQ in C, not C++ (part I)".

I agree with your assessment of C++ exceptions. Many commentors don't quite get what you did not explicitly state: a far-away error-handling method designed to handle multiple exception types for convenience is unlikely to be able to handle errors in a fully recoverable way. Exceptions are designed to decouple error handling away from the immediate caller, which is the only context that truly understands the API and the state it is dealing with. An exception is a goto to a (statically) unknown destination at the worst possible time (a crisis moment).

Good points have been made that C-style error handling:
1. can be ignored without run-time error
2. take up your only function return value.

Newer languages seem to be eschewing exceptions in favor of a more C-like approach that solves the above two issues based upon tuple-like return types ("value or nothing", or "value or error code") that have to be decomposed and checked for error explicitly to receive return values. This also allows the compiler to guarantee that an error code is checked, rather than relying on run-time detection. Progress is being made, but too late for C++.

My perspective is that exceptions were designed to solve a local problem (consolidated error handling) in a way that introduces a bigger problem "in the large" (on the scale of the project, rather than the function). In fact, I find that a few C++ features (especially the early ones) make this kind of bad trade-off.

Interestingly, I was recently developing an in-memory database as a library (in support of a game) and I began by using plain C. There were many good reasons in my mind to do so:

1. I would very much like to avoid exceptions and OOP (inheritance, virtual functions), probably more "features" as well
2. A C API can be used from C, C++, or scripting languages (C++ has no standard name-mangling, making linking to C++ generally unsupportable)
3. A plain C interface eliminates library-seeping-into-interface problems with boost types, smart pointer types, etc that cause version/linking issues for the main application (which may use many libraries, each of which may want different versions of the same sublibraries!)
4. probably more I don't remember

However, as the project evolved, I found *some* C++ features to be very desirable, so the project evolved to a subset of C++. The main subset I use are:

1. function overloading (application changes a type? they don't have to change all function calls in project)
2. generic programming (via templates): eliminates code duplication, works well with #1. makes for smaller code base
3. C cannot do callbacks performantly or well (lambdas via #2)

Note that I still do memory management C-style (no constructors, destructors, or methods: plain functions only). This has better encapsulation properties than C++ methods-in-a-class approach, which must declare its internally-used data types "publicly" in the header file! (& therefore must also include all headers needed to describe those types: the difference in header file size is striking)

Of course I also use C-style error handling. The API is technically C++ (for function overloading), but is kept to a plain, no-library style.

So question, Martin: did you ever consider (for nanomsg, for example) using C++ but simply limiting your feature use to a small, useful subset? Do you not find any features of C++ compelling enough?

by Daniel Tracy (guest), 13 Dec 2016 03:14
Duncan Bayne (guest) 29 Nov 2016 02:51
in discussion Hidden / Per page discussions » Centrifugal Governor or Why I am not a Libertarian

You're starting from a false premise, at least according to the Austrians, who argue that an economic 'centrifugal governor' is actually impossible:

https://en.m.wikipedia.org/wiki/Economic_calculation_problem

by Duncan Bayne (guest), 29 Nov 2016 02:51
Keith (guest) 26 Nov 2016 21:16
in discussion Hidden / Per page discussions » The Cost of Abstraction

I think the cost/benefit is primarily determined by your group EVERYONE. Unlike yourself, I haven't worked on OSS projects, so haven't encountered the social and political project issues at that scale. In such contexts, where folk turn up from everywhere, with wildly different levels of skill, competence, experience … more formalism is what's required to keep the motley group together. But because we get enough of that in our day jobs and just want to get things done, I expect that's the last thing people want.

It's human to use abstractions. But abstractions are cultural. English in England uses the word Binge. But that word has no real meaning or use outside of British English.

Similarly, some C++ cultures clearly know what they expect to happen in the face of an exception, while others know and expect a different model, while some never really think too much about it up front.

Culture. Abstractions without culture. I think that's where things begin to breakdown. I think abstractions are defined within a culture.

Your inheritance hierarchy, for me, demonstrates a different problem. Using the wrong tools, abstractions included, create problems of their own.

by Keith (guest), 26 Nov 2016 21:16
Gerard Toonstra (guest) 08 Nov 2016 18:00
in discussion Hidden / Per page discussions » The Cost of Abstraction

Very insightful. I like thinking about software complexity and one of the concerns there to deal with complex software is that the design and intentions should be communicated (which means either documentation or exist as a common understanding of purpose and function).

From your perspective, it means that there is also a need to establish agreements on the levels, depth and ways abstractions in the code are formed. Indeed, I worked with software where the functions and operations weren't implemented in a messy way per sé, but the many levels of indirection, abstraction (and obscurement) made things just really difficult to read and a real tail-chaser when it came to maintenance.

Those levels can also make it much more difficult to understand the flow and the operations that are happening, because in many languages you pass references to data objects, so data gets changed in many ways.

Nice article, puts me into thinking mode again! :)

by Gerard Toonstra (guest), 08 Nov 2016 18:00
page 1123...next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License