IRC channel logs

<mark_weaver>dunno, it may be that you have to work on a project that's too complex to keep in your head to understand what he's getting at.

<mark_weaver>when a project approaches that level of complexity, that's when it becomes crucial to be more disciplined

<mark_weaver>for simple things, it doesn't matter. programming without much design can be sufficient.

<ArneBab>I agree with that point. I disagree with the huge focus on software engineering and disregarding the programming.

<ArneBab>I saw people in university learn software engineering and not being able to produce working software.

<mark_weaver>well, I don't see what that proves. every university is full of people who aren't going to be able to do much.

<ArneBab>and I consider good programming to make it easier to have more lightweight design.

<ArneBab>at a certain size, you need design which limits the effects of each part of the code on other parts.

<ArneBab>with the size of the Linux kernel, you definitely do.

<mark_weaver>just because many people are taught software engineering and can't do it doesn't mean that software engineering is not worthwhile. there are also plenty of people who learn programming and can't do it in practice.

<ArneBab>but with bad programming, you have to have a very heavyweight design to compensate for problems coming from the programming.

<ArneBab>(I listened to the talk a few hours ago, so it’s not completely fresh anymore)

<mark_weaver>I don't know what you mean by "I consider good programming to make it easier to have more lightweight design". doesn't design precede programming?

<ArneBab>I found an analogy to that (drafted an article in my analog notebook)

<ArneBab>when you build a house, good craftwork makes it easier for the architect to design it. Bad craftwork means that the architect has to design all kinds of safeguards for breaking pipes and so on - which take up space and would not be needed with good craftwork.

<mark_weaver>do you think he was advocating for bad programming?

<mark_weaver>I don't really understand how your comments relate to his talk.

<ArneBab>it sounded to me as if he generally talked against taking care to do good programming.

<ArneBab>how I took it might be connected to the title, though…

<mark_weaver>I didn't get that at all. if anything, the opposite.

<mark_weaver>but to him, the very term "programming" suggests a process by which one simply starts coding and doesn't design carefully or try to prove anything.

<mark_weaver>it also refers to trying to fix bugs without fully understanding the existing design.

<ArneBab>yes, just that. This is what he labored over again and again.

<ArneBab>and I think this is what irks me.

<mark_weaver>out of curiosity, tell me about the most complex software project you've been significantly involved in?

<ArneBab>that depends on what you call significant - main developer or does it suffice to contribute to parts of it?

<mark_weaver>well, the issue is whether the work you did would have required deep knowledge of the design, such that you could get into trouble by not being able to keep it all in your head or reliably predict the effects of your changes.

<ArneBab>for the latter: the tm5 transport model. I debugged it’s OpenMP implementation for the sun fortran compiler.

<mark_weaver>(as can happen in several subsystems of a modern kernel, e.g. the virtual memory system or concurrency synchronization mechanisms)

*mark_weaver looks it up

<ArneBab>and Freenet - I still need to finish a fix there, because I needed to first discuss the best place to add mime-type information

<ArneBab> http://tm5.sourceforge.net/

<ArneBab>(for freenet: the current testing release broke uploads by plugins. We need to get that fixed, before we can ship the update)

<mark_weaver>okay, well, nevermind. maybe you have enough experience to know.

<mark_weaver>dnuno

<ArneBab>I think I have enough experience to know that in a big system I agree with him.

<ArneBab>but that there aren’t only big systems. And ideally the systems should be kept small enough that the design can be kept simpler.

<mark_weaver>okay, well, he was talking in the context of linux (the kernel) development, where the complexity is frankly out of hand.

<mark_weaver>c/o the RCU mechanisms that Paul McKenney talked about in that other video I linked.

<ArneBab>(or rather: small enough that the design is inside the interaction of different tools - like in the commandline interface)

<ArneBab>I only listened to the RCU talk on the side (about an hour ago), but when I heard that when all stick to the rules it works, I grew worried.

<dsmith-work>mark_weaver: Ever read those "code as design" essays? http://www.developerdotstar.com/mag/articles/reeves_design_main.html

<mark_weaver>no

<ArneBab>mark_weaver: I’ll see whether I can turn my draft about the text into a short article tomorrow.

<ArneBab>s/text/talk/ ← I’m already too tired to go deep enough.

<ArneBab>it’s 0:25 here and the night ends at 5:30…

<ArneBab>mark_weaver: thank you for the discussion! I hope we can continue it later (or another day).

<mark_weaver>np!

<mark_weaver>and likewise

<mark_weaver>it seems to me that the increasing complexity of software (shared-mutable-memory multiprocessing is a *big* part of the problem here) is already a very serious problem, and is going to get much worse over time.

<mark_weaver>unless we become more disciplined in our work. and that criticism is directed at myself as well, btw.

<mark_weaver>it would be good to have software that's not full of holes for the NSA to get in.

<mark_weaver>and given the way we do things today, it feels almost hopeless about that problem. it would be nice not to feel so hopeless about it.

<mark_weaver>s/it feels/I feel

<mark_weaver>maybe I'm just talking to the wrong people about this :-/

<dsmith-work>mark_weaver: I hear you.

<mark_weaver>:)

<dsmith-work>mark_weaver: Functional languages (or style) are very attractive to me. I don't want to have to keep the whole thing in my head.

<dsmith-work>mark_weaver: There was some dos bbs thing that did uucp. I tried to change a few things in it. It was HORRIBLE. Nothing but globals. Like no functions had arguments! Ugh!

<dsmith-work>I never did figure out what was going on.

<mark_weaver>yeah, there's no shortage of terrible code out there.

<mark_weaver>much of which we depend on

<mark_weaver>but I'm also deeply concerned about stuff like those RCU methods in linux, even though I guess the code probably looks about as nice as one could hope for given that design, and I guess that Paul is extremely smart.

<mark_weaver>or even more mundane multithreaded programming, where it seems that very few people understand the implications of weakly-ordered memory models used in modern machines.

<mark_weaver>even extraordinarily talented hackers mostly don't understand this stuff

<mark_weaver>it's a recipe for disaster

<mark_weaver>well, I take that back. it's a recipe for unreliable software with tons of security holes.

<mark_weaver>I guess we'll muddle through somehow, with the NSA owning all of our systems.

<dsmith-work>Yep

<paroneayea>:(

<adhoc>mark_weaver: this is where the whole non-blocking stuff is gaining traction

<adhoc>becuase spinlocks and semphores are hard

<adhoc>so lets not do that

<adhoc>not to mention don't scale well on manyway SMP or distributed CPU systems

<mark_weaver>indeed!

<jgrant`>Hm; Skribilo will export html, but not a pdf.

<jgrant`>I have all of textlive installed that is available for GSD, but nothing.

<jgrant`>Hm, maybe there isn't a builder for pdf?

<jgrant`>It's available via Latex.

<jgrant`>Yeah, the 3 builders I see is for html, lout, and latex.

<davexunit>go from latex to html

<davexunit>perhaps you could write a new builder that runs latex builder followed by pdflatex?

<ijp>worst case scenario, export to html + pandoc

<jgrant`>Unrelated to this chat, but my Emacs session evidently can't view pdfs on GSD. :^P

<ijp>but if it comes to that, a revolver with one bullet can be found under your chair

<jgrant`>I've heard of Skribilo before, sticked my head in a tiny bit once or twice, but as a whole -- it's pretty stellar and not really ever talked about.

<jgrant`>One of my favorite things about Lisp/Scheme is how easy it is to shape the language to do stuff that in all honestly probably "shouldn't do".

<davexunit>civodul wrote it :)

*jgrant` plans to rewrite his blog in Skribilo eventually and then yeah, add a pdf exporter.

<jgrant`>I'm not sure what else one/could should add thereafter.

<jgrant`>Looks pretty complete, for what it is -- but I may just be ignorant.

<jgrant`>Most of my issues currently are minor aeshetic ones.

<nalaginrut>morning guilers~

<nalaginrut>oh nice, master merged stable-2.0?

<adhoc>are there other irc channels for guile stuff ?

<ijp>##guilesupersecretpartyfuntime

<davexunit>shhhhh

<adhoc>=/

<xjgrant>adhoc, #sly? :)

<adhoc>yeah, there alread =)

<xjgrant>#guix , somewhat obviously.

<adhoc>ah

<adhoc>on the guix mail list

<adhoc>i doubt it

<adhoc>oops

*xjgrant might start a skribilo channel, if ludo is not interested in messing with that.

<xjgrant>There are not a ton of channels for Guile yet, that I am aware of.

<xjgrant>Guile projects, rather.

<adhoc>ok

<davexunit>yes, there's the #sly channel that I run for my Guile game engine.

<xjgrant>I suspect that the future os real bright, for projects using it. dave and ludo are always doing cool things. :-)

<xjgrant>Is

<xjgrant>I hate autocorrect is so presumptuous...

<jgrant>Does Racket even have a lot of seperate IRC channels?

<jgrant>Not that I'm aware; and they are marginally larger comparitively -- currently.

<nalaginrut>I've updated guile before lunch, now I finished and bought a lemon juice back, it's still compiling...

<nalaginrut>last time I enjoy such compiling time is compiling linux kernel for a ARM board...

<nalaginrut>on a x86 board...

<daviid>mark_weaver: about your paste: (don't have much time, and will go afk very soon, need to sleep, but wanted to give you a quick feedback): so, sure, but that would be a (terrible) user bug. exactly the 'same' bug(s) as if 2 export a procedure from 2 different modules, bearing the same name twice ... do _not_ name 2 classes using the same name, and it is easy enough to check that, using clos/goops... with that as a rule of thumb, you

<daviid>will never create a bug by merging generic functions (in guile/goops). in clos, iirc but don't quote me on that one, I don't have time to recheck with a clos system, your example would actually trigger a class redefinition (since everything land in a specific name space), and there would be 1 class only in the end (which unless the user really knows what he is doing, could/would also later raise bug(s)...), cheers and good night

<civodul>Hello Guilers!

<artyom-poptsov>Hi civodul

<ArneBab>mark_weaver: I often feel that the complexity of software is to some degree a failure to define the responsibilities: Why does this program need to do X on its own?

<ArneBab>for me problems get much easier to solve if someone else already solved part of it - and defined an API I can use.

<nalaginrut>ArneBab: sometimes it's not so idea, for an instance, the author of the libs has something difficult to communicate, or other complex situation

<ArneBab>nalaginrut: sure - I don’t mean that it’s always bad to write a lib yourself (replicate work). Just that it’s often not needed. Or that there are often commandline programs you can use to solve a large part of the problem.

<nalaginrut>ArneBab: yes, at least to me, I prefer use even cmd tools to solve it in prototype stage

<ArneBab>same for me — and if installation were a solved problem, I’d keep doing it

<nalaginrut>but in long term, I seems can't stop myself to write everything as possible...

<nalaginrut>s/seems/seem

*nalaginrut should hack himself first...

<ArneBab>:)

<ArneBab>(lifehacking ☺)

<ArneBab>nalaginrut: or - if you enjoy writing everything yourself, why not do so. It can be pretty useful to others.

<zacts>davexunit: hey, I just got a new copy of SICP in real book form

<zacts>I also got the instructor's manual

<davexunit>zacts: :)

<zacts>I've noticed I've had problems with the design of software, and I'm looking for projects to learn this with

<zacts>I may decide to make a game

<zacts>rather than my editor idea right now

<zacts>the thing that scheme and the lisps are giving me, are like a blank canvas within which I can be totally creative and think of design almost exclusively. No other languages have done this for me.

<zacts>It's showing me directly where I'm weak at in terms of design

<nalaginrut>mats is making a new language similar to shell based on stream (frankly, it'll be easier if he use Guile for designing it)

*nalaginrut has not time at present to design a new language...

<nalaginrut>s/not/no

<dsmith-work>Wednesday Greetings, Guilers

<zacts>lo dmsi

<zacts>dsmith-work:

<danielszmulewicz>Hi, Hi, I know very little about guile (but I'm a Lisper). I

<danielszmulewicz>Sorry for the line breaks.

<ijp>guile-scsh has been reimplemented at least three times, but they are probably all dead

<ijp>default guile does not

<danielszmulewicz>Does it have a a story for POSIX interaction?

<danielszmulewicz>Thanks by the way.

<ijp>whatever you want is probably there

<ijp>(info "(guile) POSIX")

<ijp>for processes, you can also look at (ice-9 popen), but that's a bit crappy

<danielszmulewicz>Thanks! Looking into it. Also, I'll be comparing with Racket for POSIX. Any thoughts?

<danielszmulewicz>ijp: How do I import "info" in a running REPL?

<ijp>sorry, that's an emacs command, not a guile one

<ijp>I should find out how to get the http link from it

<ijp> https://www.gnu.org/software/guile/manual/html_node/POSIX.html#POSIX

<danielszmulewicz>Thanks!

<ijp>guile posix support is probably more direct than racket, but other than that, not really

<ijp>try it, make up your own mind. Don't ask a pig what he thinks of bacon.

<dsmith-work>heh

<danielszmulewicz>ijp: yes, guile is close to the metal, wrapping the C interface, while Racket is more high-level with its own abstractions.

<danielszmulewicz>Too bad scsh has no geyser support. Actually it has, but for 0.6.7, not 0.7

<danielszmulewicz>From the docs about the scsh abandonware: "This bitrotting is a bit of a shame, as there is a good deal of well-written Scheme code in scsh. Adopting this code and porting it to current Guile should be an educational experience, in addition to providing something of value to Guile folks."

<zacts>hi guilers

<zacts>I for one, would love to see a guile-scsh

<zacts>mark_weaver: davexunit: I also purchased a physical book of sussman's functional differential geometry

<mark_weaver>ah, cool!

<mark_weaver>I've read some of the PDF

<zacts>and I hope to get the SICM classical mechanics book next month

<zacts>mark_weaver: how did you like it so far?

<mark_weaver>I have dead tree versions of SICP and SICM, but not yet their calculus book.

<mark_weaver>I like it a lot.

<davexunit>zacts: I have never heard of "functional differential geometry"

<davexunit>sounds cool

<zacts>yeah davexunit it's a book by sussman

<mark_weaver>it aims to teach some of the fundamentals needed to work with general relativity, among other things.

<zacts>I'm also getting interested in Ant Colony Optimization algorithms and the study of ants social and work behavior in terms of computational algorithms, I hope to study this with scheme in the future

<zacts>I mean I'm interested in learning about ACO algorithms, not that I know much about it yet

<mark_weaver>there's another relevant book along those lines: Calculus on Manifolds, by Spivak, which they cite in SICM. beautiful little book, but apparently very challenging.

<zacts>oh really cool mark_weaver

<zacts>let me add that to my wish list

<mark_weaver>yes, ACO is fascinating stuff

<zacts>Yeah I hope to improve my maths a lot this year

<zacts>I also like the idea of making pedagogy / syllabus for upper calculus and applied math using scheme

<mark_weaver>zacts: one piece of advice: make sure you do a lot of practice problems. merely reading about difficult math will be nearly useless.

<zacts>right

<zacts>I will take this advice to heart for sure

<zacts>(I've been guilty of this before, not doing enough practice problems while reading a ton)

<davexunit>hard to actually do the exercises when you can't flunk anything ;)

<zacts>hehe

<zacts>davexunit: well that's what #guile is for

<zacts>I will get ridiculed

<davexunit>:)

<zacts>which can arguably worse than flunking

<davexunit>time to head home. I commuted into downtown boston today when it turns out that I didn't have to. missed a perfectly good free work-from-home day.

<zacts>but seriously, yeah we'll see. I'm getting into this SICP stuff too, and yes I'm working on the exercises

<zacts>mark_weaver: what other books have influenced the way you think about programming?

<zacts>I mean I think I'm pretty much set for this year on reading, but for next year perhaps

<mark_weaver>zacts: dunno, apart from SICP it mostly hasn't been books, but rather papers and experience that have influenced me.

<mark_weaver>(at least since I've been interested in Scheme and functional programming)

<mark_weaver>"The Reasoned Schemer" is worth reading also, if you haven't yet.

<zacts>ah cool

<zacts>I hope to study some domain specific scheme / comp sci papers too.

<zacts>I've been thinking about this a lot lately

<zacts>I also found this book

<zacts> http://www.info.ucl.ac.be/~pvr/book.html

<zacts>but I think I may agree

<zacts>after I really live SICP for a while, I'm thinking that research papers and experience will be my greatest influence too

<zacts>also Godel Escher Bach

<zacts>and sentential logic

<zacts>but I did pass that logic class at my college, it was fun

<zacts>I even mentioned the reasoned schemer and minikanren to my professor, and he became way interested

<mark_weaver>cool!

<mark_weaver>zacts: ah, that book you just cited is based on Mozart, an implementation of the Oz programming language. I looked at Oz and Mozart about 20 years ago and found them quite interesting, but then I got distracted by other things.

<zacts>yeah I dislike OZ, but I like the concepts presented in the book

<zacts>it's like a sequel to SICP in a sense, well not really a direct sequel.

<zacts>It elaborates upon many of the ideas of SICP apparently

<zacts>and provides modern research in many of the paradigms

<zacts>and it extends many ideas in SICP more fully

<zacts>like OOP

<zacts>the books I'm getting next month I think will be the MIT press book on ACO ant stuff, the SICM, and this concepts / techniques book with OZ

<mark_weaver>fwiw, I'm not a big fan of OOP except for a few limited applications.

<zacts>yes, well concepts doesn't focus on OOP, it's just one of many paradigms

<zacts>but it elaborates in detail many of the paradigms. The base from which concepts/techniques works from is pure functional

<zacts>it then only adds to that for various other ways of thinking / paradigms.

<zacts>it actually goes out of its way to point out that OOP isn't the only one true way

<mark_weaver>okay

IRC channel logs

2015-01-28.log