/tech/ - Tech

Technology.

catalog
Mode: Reply
Name
E-mail
Subject
Message

Max message length: 8192

Files

Max file size: 80.00 MB

Max files: 5

Password

(used to delete files and postings)

Misc

Remember to follow the rules


(104.85 KB 837x803 1501117252661.png)
cybersocialist planning poll Comrade 08/11/2019 (Sun) 06:27:35 No. 3240
https://forms.gle/3sBQnaFXdv5jhBAa7

answer some questions about how you would like the hypothetical open source software to be written.
For Java:
- Cockshott's existing program is written in it
- Speed is acceptable, especially if you use something like Vert.x for backend
- Cyberproles around the world all know Java
Against Java:
- It lacks a lot of nice features
- Slower than non-GCed langs (bad for the environment)
- Null pointers
- Bourgeois OOP idealism
- "Everything is a reference" guarantees cache pollution
- Shitty build systems and package management

For Rust:
- As fast as C, plus easy to multi-thread (good for environment)
- Memory management is safely centrally-planned by the borrow checker
- Many modern language features, advanced type system, nice macros, etc
- No OOP
- No null pointers, mandatory checked errors (far fewer runtime errors)
- Futuristic, in communism bourgeois scripting languages and GC would be phased out to save electricity and CPU time
- I already wrote ~170 loc of code for labor time calculation in it
Against Rust:
- Harder to learn than Java/Python/etc, not as popular
- Would have to rewrite Cockshott's program (~500 loc)
- Fewer frameworks/libraries
Also, the repo should be hosted on a non-14-eyes git host. Github has banned our comrades in Donbass, Iran, Syria, Cuba, DPRK, etc. China and Russia have some good git websites.
>>373
>Bourgeois OOP idealism
what about Clojure + Scala
>>374
suggestions?

what do you think about other source control systems like subversion, mercurial, etc
>>374
>>375
>>373
one advantage of something like clojure with the java interop is that you could seamlessly call cockshott's code from it.
ill also comment again about microservices vs monolithic: a monolithic app is way easier to maintain as everything is just a function call, if you split it into microservices, you are basically splitting your program into multiple little programs, which means you are essentially doing distributed programming (calling another service over tcp, http, w.e.). not to mention each of which needs to be replicated in various environments (DEV/STAGE/PROD).

Load balancer + monolithic app is way easier to maintain and understand.
>>375
They have a lot of nice aspects, the barrier to entry is higher than bracket langs though, and there is a GC penalty. Wouldn't be against it.

>>377
>you could seamlessly call cockshott's code from it.
True, though looking at cockshott's code, I kind of want to rewrite it...
https://github.com/wc22m/5yearplan/blob/master/plancode/planning/Harmonizer.java
You can see he didn't make it for readability.

>>376
>suggestions?
I would just google for git hosting in x country. Pick the one that seems nicest.

>>379
I'd just say, keep in mind that the problem domain naturally lends itself to splitting up services. Like, the labor time calculation is separate from the plan calculation is separate from the data entry (labor times, dependencies, quantities) is separate from the metadata (like photos, description etc).
Even if the initial app is written as one big backend, it should be easy to split up when the time comes.
>>380
>true, though looking at cockshott's code, I kind of want to rewrite it...
yeah, doesnt look like hes a fan of inline comments. Nevertheless its a good basis.
>>380
if thats the case, i don't see why the app shouldnt be written as a monolithic app in a jvm language which calls cockshott's code, but after it scales or is worked on for a while the labor time calc/harmonization could be a separate service/program written in RUST or another low level language. After its done calculating it can update the DB with the new labor values.
current labor calc code:
https://pastebin.com/3zATBFHR
It is a bit messy rn, as I was rewriting it to be a more complete API, sanitize data, etc while also learning more Rust and learning Actix+Diesel (to write the server).
>>383
looks good so far. I assume this is going to be accessable via RESTful api?

The type of programming we are doing here is very different than the usual 'take stuff out of a database and show it to the user' type web programming as it is involved with computationally expensive computations.
>>382
>if thats the case, i don't see why the app shouldnt be written as a monolithic app in a jvm language which calls cockshott's code,
Is anyone ITT /are you familiar with a JVM backend framework? If so, you could go ahead and start prototyping. I would get onboard if it picked up some steam. I know Java pretty well, though I've never touched Spring or w/e. The main drawback is, when you pick a lang+framework and write a lot of code in it, there's a lot of inertia against rewrites or changing to something faster or nicer. Facebook even made a PHP-to-C++ transpiler for this reason.

>after it scales or is worked on for a while the labor time calc/harmonization could be a separate service/program written in RUST or another low level language. After its done calculating it can update the DB with the new labor values.
A fine option, though it could increase deployment complexity. Would give me the option to keep working on my project, and if it's just a service, the scope is more manageable.

>>384
>I assume this is going to be accessable via RESTful api?
I plan to write a REST API, yeah. I'm working on a simpler (in terms of data layouts/consistency) project using Actix right now to learn it.

>The type of programming we are doing here is very different than the usual 'take stuff out of a database and show it to the user' type web programming as it is involved with computationally expensive computations.
Yes, but not only that. There are a number of issues when it comes to consistency:
- Need to regularly save the whole data set to have a "price" history
- Any update to a dependency quantity that increases the quantity (and only this kind of update) requires three calculation runs on the entire data set to determine whether it is valid (at least with my current dependency checking algorithm)
- Need to translate the ID key in the database to the index of the Vec element (what if a product is removed?)
- some other issues I don't have off the top of my head
>>385
also,
In a real world situation, most people would just update the labor time and dependencies involved at their workplace. The data they enter could be compared to the estimated time and resource usage of the open source blueprint for their production methodology. Relatively few people would directly update the data set used for calculating indirect labor, and it could be automated a lot (by averaging the user-entered values).
>>385
>Is anyone ITT /are you familiar with a JVM backend framework?
I have been writing java for a while as well but my experience is in legacy code (proprietary extension of JSF 1 from back in the day - terrible shit, worst framework ive ever used

my personal vote is to use Clojure + the Luminus microframework (im the clojureanon as well, you can check out the sources im using in the clojure thread here on /tech/)

but overall we should wait for the survey results and see what peoples input is and go from there.
>>389
I guess one other thing for anons to consider is front-end. Depending on the language you pick for backend, you can share code and data structures between them. I believe Clojure has this advantage through transpilation, and Rust actually does as well (wasm frameworks like Yew), as do JS and a number of JS transpiled langs like ReasonML or TypeScript.
Like people pointed out in your thread, Clojure is dynamically typed. While it's not as big of an issue in FP with immutable state, it can still cause problems for verification, soundness, and refactoring.

>my experience is in legacy code (proprietary extension of JSF 1 from back in the day - terrible shit, worst framework ive ever used
Yikes, I guess I should cherish my remaining time as a student... though uni sucks in a different way.
(28.11 KB 1004x759 flowofcontrol.gif)
(45.23 KB 666x770 gs_adf_jsf_lifecycle.png)
>>392
>Yikes, I guess I should cherish my remaining time as a student... though uni sucks in a different way.
yeah, there are alot of jobs out there where you work on a terrible java enterprise app that is internal for the company only, the accounting or hr department or w/e use it. and if you've ever seen this shit, its usually written in something like ASP.net or JSF or fucking SALESFORCE where you dont even write front end javascript, just an XML file that gets run thru a codegen tool that gets turned into a jspx that gets interpreted by the app server into crappy bloated proprietary javascript that looks straight out of the 90s. And every page is sluggish as fuck and looks terrible, but all the internal employees are forced to use it for their job.

**bosses love it because they were sold the pipe dream of 'oh, i can just drap and drop i dont need to code! why do we even pay you'. then once it comes time to do something that actually does require customization they drop it on you, this crappy framework that makes WYSIWIG programming easy for bosses but INSANELY COMPLICATED AND DIFFICULT for devs to customize.

The fucking page lifecycle looks like something you need to attend graduate school in software engineering to understand. You look at a stack trace and notice the error occured in oracle.jsf.lifecycle.proprietary.wizard.binding. you click on it and get a message in your IDE 'ERROR: METHOD NOW BROWSABLE'. thats right. this poorly documented piece of shit that doesnt have any documentation online other than 1 pdf from 2004 that you have to register/login to the oracle forums to download, is incomplete, and they DONT EVEN LET YOU INSPECT the method where its going wrong because thats PROPRIETARY ORACLE MAGIC/WIZARDRY(TM). i legit feel sorry for the internal employees of these fortune 500s that are forced to use this shit thats nigh impossible to fix or even improve. the literal only way to even understand the code is learn from a senior engineer whos been around so long they know the code, and to copypasta similar things from other parts of the codebase and/or try to read the incomplete documentation or blogs if you can.**
>>392
doesnt rust transpile to WASM tho?
everyone make sure to vote in poll
>>395
WASM is a compilation target, like an ASM. I guess technically all compilation is transpilation if u rly think about it

>>394
>bosses love it because they were sold the pipe dream of 'oh, i can just drap and drop i dont need to code! why do we even pay you
This is basically the motivation behind pretty much every common stack. Java itself got popular because porky thought OOP would make it easy to replace programmers. COBOL, similar deal. JS, "everyone learns it, why not put that shit in backend then outsource"
>>365
>Hiring servers.
>>392
if only there was a stronk statically typed, immutable, functional language that you could write APIs with and automagically derive clients in a host of languages, where a host of errors are avoided by the compiler slapping across your bitch face if you present it with unsound code.
λλλλλλλλλλλλλλλλλλλλλλλλλλλλ
λ MADE BY HASKELL GANG λ
λ λ
λ BOTTOM TEXT λ
λλλλλλλλλλλλλλλλλλλλλλλλλλλλ
>>403

ever tried writing lisp interpreter in haskell?
>not programming in cubical type theory
>>403
Hasklel actually does seem to have some nice frameworks, idk about perf though.
>>403
>>408
except you have to have a phd in category theory to understand its extremely complicated type system
>>409
You don't need to understand the whole thing to make proper use of it. You need a PHD in Qabbalistic templates and constructors to understand C++, and as a result nobody understands it, yet they use it.
>>410
>nobody understands it, yet they use it.
which results in crappy code
we have 8 responses so far
when does everybody think the poll should close?
(830.38 KB 320x180 rust.gif)
cRUSTaceans are winning the poll so far
I would prefer .net over Java because in .net we have amazing, smooth, easy interop between F#, C#, which allows us to write in functional what is usefull to write functional and procedural what is procedural.
Also because type erasure is retarded and trying to package manage java is like masturbating with sandpaper.

>>379
Creating a monolith for software that potentially has to calculate entire economies is just putting shards of glass in your own shoes.
Microservices are much easier to distribute, scale and also decentralize.

>>409
No you dont. You dont need to learn the entire greek math shit of catagory theory to understand how to use monads or functors, in the end its just writing clever abstractions and having functions that accept and return other functions.

>>413
Noooo rust is so autistically verbose and unusable. That retaded language lets its good features suffer so much from trying to hard to be a systems language. I dont want to deal with lifetime autism again just to use the conceptually very simple borrowing system.
>>403
>be able to write statically typed, immutable, functional code
>Also have great two way interop with procedural language
>Also able to break functionalness and use mutability if needed
F# gang.
>>405
no.
but I have this bookmarked, which is 10% of the work. https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours
>>406
not as hot as HOTT 🔥🔥🔥 (homosexual-topy type theory) https://homotopytypetheory.org/
>>408
performance is usually par with any other GC language. Can be hand optimized to be close to C. We have fast enough computers,
correctness >>>> speed, especially when dealing with national level shit. No room for errors. Even better when dependent types arrive. We'll be building luxury space castles of abstraction.
>>409
wrong.
haskell is the language of the people.
it's for brainlets that can't program for shit. The compiler grabs them (us) by the hand and helps them write correct programs that are easy to re-factor by more experienced engineers if needed. The compiler does a lot of work for you, just write type holes and the compiler tells you: "hey little shit, did you mean to write this [thing you need to write]?". Or if you're doing something stupid, it will tell you "fuckface, you can't add an integer with a function. try again." to which you must answer, "thank you glorious Glasgow Haskell Compiler", unless you want to be sent to dependency hell.
It's also for wizards that write libraries for us mere mortals like Saint Kemett.
>>410
>PHD in Qabbalistic templates and constructors
lmao
>>415
>Also able to break functionalness and use mutability if needed
<Also be able to stick a chopstick through your urethra
haskell has pure mutability as well. F# is Object Oriented Cope.
OP HERE I WILL BE CLOSING THE POLL TOMORROW SO EVERYBODY GET YOUR RESPONSES IN
>>417
>correctness >>>> speed
yeah but when you are dealing with calculating a sparse matrix of 500 million commodities speed does end up mattering.

Albibaba (Chinese amazon) has like 2 billion individual goods and services), its likely that we will have to drop to a lower language like C/C++/Rust in order to make that computation fast enough
>>414
>Microservices are much easier to distribute, scale and also decentralize.
they're also harder to write, debug, maintain, and test. Not to mention harder on the OPS side as well (replicating dozens of dev environments on localhost)
>>417
more serious, I only use imperative languages at work, and I'm learning haskell as a hobby.
When I used C# for work, it was a really nice language, LINQ is great. F# is probably even better. Very frustrating that it's MSFT shit and not extremely portable. I wish I could use F# natively on unity.
I haven't tried rust, but I hear it's a good C++, that's nice.
>>419
lazyness can be a godsend with shit like that.
also haskell can be hand tuned to be almost just as fast, afaik. haven't done it myself.
I haven't read dickblastt, I've seen his awful code on github though. Is there a specific algorithm you're referring to?
>>421
>Very frustrating that it's MSFT shit and not extremely portable.
ASP.net CORE is FLOSS now actually
MS says they plan to unify asp.net and asp.net core to make the whole .net platform floss in .net 5
>I haven't tried rust, but I hear it's a good C++, that's nice.
like C++ if the smart pointers were the default
>I haven't read dickblastt, I've seen his awful code on github though. Is there a specific algorithm you're referring to?
just general sparse matrix calculation methods

if you havent read dickblast and want a more technical introduction to him try reading 'Calculation in-Natura, from Neurath to
Kantorovich' and 'Application of Artificial Intelligence Techniques to
Economic Planning'

links

http://www.dcs.gla.ac.uk/~wpc/reports/standalonearticle.pdf
http://www.dcs.gla.ac.uk/~wpc/reports/plan_with_AIT.pdf
>>413
Nice!

>>414
>Noooo rust is so autistically verbose and unusable.
Don't exaggerate, anon. It has lots of nice type inference, syntax sugar, and abstractions that can result in very clean, simplified code. In terms of verbosity and complexity, it is somewhere between C and C++.

>I dont want to deal with lifetime autism again just to use the conceptually very simple borrowing system.
You learn to really appreciate the lifetime stuff if you understand that it goes hand-in-hand with good performance design. Read this:
http://www.dataorienteddesign.com/dodbook/

>Creating a monolith for software that potentially has to calculate entire economies is just putting shards of glass in your own shoes.
The actual calculations are really fast. For instance, my benchmarks showed that the labor time calculation takes .7 seconds on 1 million products. And that's single-threaded. Cockshott's stuff is fast too. Our initial data sets will likely have less than a thousand items. And again, these parts of the program are not coupled, so splitting them off into separate services would be easy down the road.

>I would prefer .net over Java because in .net we have amazing, smooth, easy interop between F#, C#, which allows us to write in functional what is usefull to write functional and procedural what is procedural.
I've heard good things about both of these, but IDK how many people here have any experience with .net stuff, and often it's not as well-supported on Linux (EG, it's not in Arch's main repos).

>>417
>We have fast enough computers, correctness >>>> speed
It's possible to have both correctness and speed though, and the meme of "just throw more CPUs at it" is not acceptable for ecological and cybernetic communism IMO. This attitude is why modern computers are so fucking laggy at basic tasks even though they are basically supercomputers.

>>419
Case in point. We would at very least want the big calculations to be in Rust. Though I will point out, many of the "2 billion individual goods" are actually redundant. There are 100,000 results for "coffee mug" on Amazon, but most of them are the same damn porcelain cup! Realistically speaking, I think the number of genuinely unique goods is definitely below a billion, probably in the low to mid millions.

>>421
>lazyness can be a godsend with shit like that.
Not really, I don't think the harmony planning or labor calculations really lend themselves to it.

>>422
>like C++ if the smart pointers were the default
Rust has a separate smart pointer type, Box. Most of the code you write in Rust follows a paradigm of "Everything is a move or a reference." Not completely comparable to smart pointers.
>>424
>Not really, I don't think the harmony planning or labor calculations really lend themselves to it.
this, functional programming comes from the programming language theory tradition wheras numerical computing is a totally different discipline. mutable data is needed for space efficient brute force matrix/linear algebra computations that underlies cybercom and basically all of machine learning.

attempts to combine it lead to something like julia, which ends up being some unholu hybrid of python and fortran

even in langs like rust the functional versions are way less efficient than the imperative versions
>>429
where i do think FP is helpful is in Web dev where the server side is essentially just doing transformations on data while passing them to and from a database (mostly pure stateless functions) and this is why serverles/function as a service has taken off in recent years as most realize this is essentially the only thing most web dev does anyway
>>429
>numerical computing is a totally different discipline. mutable data is needed for space efficient brute force matrix/linear algebra computations that underlies cybercom and basically all of machine learning.
yeah if you look at the iteration function here:
https://pastebin.com/3zATBFHR
It's just indexing into an array a bunch (barely even using Rust features, could break logical consistency if it was implemented wrong). I can't even think of a way to use Rust's fancy map functions or iterators for it. But it's about as fast as it can get, barring SIMD maybe.

>even in langs like rust the functional versions are way less efficient than the imperative versions
Rust's iterators and map/filter stuff are actually extremely optimized, they can be faster than plain loops in most cases. However, they're only useful for a subset of operations.

>>430
True.
>>432
maybe all this autistic arguing about choice of programming language is moot anyway since in a microservices architecture technically every service is a separate prorgram (meaning can be written in a different language and use a different internal data store) the only thing they need is some common communication like tcp or http. other than that you could write like 12 different microservices in 12 different languages (although that it probably not the best thing to do since it would require your programmers to learn 12 different languages)
>>380
>google for git hosting in x country. Pick the one that seems nicest.
looked it up, bitbucket, gitea, and beanstalk. I have no clue where are the merits for it.
>>435
what countries are those in?

and if we're using bit bucket why not use MERCURIAL to btfo linus
>>434
>maybe all this autistic arguing about choice of programming language is moot anyway since in a microservices architecture technically every service is a separate prorgram (meaning can be written in a different language and use a different internal data store) the only thing they need is some common communication like tcp or http.
You are right, I've already said I will probably keep going with my program, it would work fine as a service just for calculations.

>>435
>bitbucket
Yank servers, it is an option for self-hosting, but I think we don't want self-hosting rn.

>Gitea
self hosting

>Beanstalk
Yank company

Here are a couple Chinese git hosts:
https://gitee.com/
https://coding.net/ (this seems not to have English)

I suspect there must be Russian competitors, but IDK what to search for.
>>437
Thank you. the search engine must be absolute shit.
>>437

maybe ask space nicely and he might be interested in hosting cvs/git/mercurial server along with bunkerchan? This place would be more /cyb/ than lain/arisu combined at that point.
>>439
Good point, if Space could let us host some repos that would solve the problem. But gitee looks ok too.
>>439
>>440
git.bunkerchan.xyz incoming
>>417
>haskell has pure mutability as well. F# is Object Oriented Cope.
You have pure mutability in fsharp as well.
>>417
> Even better when dependent types arrive.
Oooh when?
THE POLL IS CONCLUDED, HERE ARE THE RESULTS
(21.64 KB 604x289 apptype.png)
(17.84 KB 547x290 arch.png)
(46.83 KB 690x289 hosting.png)
(36.02 KB 690x289 cache.png)
(39.25 KB 690x289 datastore.png)
(38.81 KB 671x312 proglang.png)
(11.65 KB 285x238 proglang2.png)
>>444
Also does that mean that I can finally write an abstraction for an array with a certain size?
According to the poll, the software should be a web app - a bundle of microservices based on RUST, using POSTGRES as the data store, and enabling its built in caching.

The web stack will be OPENSTACK bespoke cloud.

second place for language is python, just 1 vote behind.
>>450
would have liked to have seen a tie, runoff vote
>>451
>not shilling for approval voting
lib
>>444
in a few years lmao
>>449
you can clumsily do that now, I believe. more "powerful stuff" and you'll be jumping through hoops or plain impossible.
>>446
>>447
So, like 12 of us voted?
>>463
I think most people don't bother to check /tech/.
>>464

or not fan of polling language of choice.
>>373
>- Would have to rewrite Cockshott's program (~500 loc)
sure hope this is monospaced

-------------------------------------------------------------------------------
Language.....................files..........blank........comment...........code
-------------------------------------------------------------------------------
TeX..............................4.............98..............0...........3032
Pascal...........................7............268............390...........2725
Java............................10............131............251...........1610
make.............................2.............21..............0.............42
Bourne.Shell.....................4.............22..............0.............36
C................................1..............7..............9.............31
-------------------------------------------------------------------------------
SUM:............................28............547............650...........7476
-------------------------------------------------------------------------------
>>468
the core harmony planning code is a relatively small part of the repo
>>470
what's the rest of the java code?
fucking bump
is there any repo I can contribute to? extra points if it isn't Java crap
This seems like a fairly odd process to arrive at a language for a communal project. Wouldn't it have been better to recruit dedicated competent programmers first, and then see what programming languages there were common competency in? I can't help but think that most individuals that participated in the poll have no intention of contributing.
>>555
common lisp?
>>555
Linear programming isn't feasible for large-scale planning, it has cubic worst-case time complexity. Cockshott's algorithm is different.
>>558
>Linear programming isn't feasible for large-scale planning, it has cubic worst-case time complexity. Cockshott's algorithm is different.
The actual program he has published for 5 year planning does use Linear programming, and doesn't scale. You need to use iterative successive approximation to work at scale the mentioned algorithms are the Jacobi method, and the Gauss-Seidel method.
>>559
No, there are two different systems. One of them uses a linear programming problem solving library, the other uses his custom harmonious planning algorithm. It runs in linearithmic time, which is a vast improvement.
>>560
>No, there are two different systems. One of them uses a linear programming problem solving library, the other uses his custom harmonious planning algorithm. It runs in linearithmic time, which is a vast improvement.
My bad, you are correct. Transitioning from polynomial time to anything less is indeed a exceptional improvement.
Labor time anon here, I am practicing the Rust Actix + Diesel + Yew stack with another project right now, plus schoolwork. It will be a while before I post more progress.
>>571
rustanon, whats wrong with the rocket framework? seems more intuitive than actix
(270.29 KB plan_with_AIT.pdf)
>>562
Cockshott's plan, also detailed here in this (PDF), is a bit confusing in the sense that hes using a neural net for something non typical. Neural nets under capitalism are typically used for machine learning tasks like classification, regression etc. Wheras he is using it for a very atypical purpose (tractable solution to an LP problem).
>>572
As far as I can tell, Rocket and Actix-web have mostly the same layout for projects. Rocket just has a few more nice macros. On the other hand, Actix is much faster at the moment due to having async capability. Rocket says they're implementing the capability right now, but it's not there yet.

Delete
Report

no cookies?