Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
Object orientation is downloading flash to participate in off-topic meta discussions.
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On 24 October 2011 12:52, Florian Limberger wrote: > Are you talking about Windows PowerShell? It's even object oriented!111 Object orientation is what happens when people who don't understand higher-order functions or multiple dispatch try to invent a programming language and end up with a clusterfuck of mutable state and inheritance. cls
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On Sat, 22 Oct 2011 09:35:00 +0100, Connor Lane Smith wrote: [...] So I think the necessary next step would be to have a strongly typed shell. To pretty-print you'd need to add a polymorphic "à la carte" (multiple dispatch) pretty-printing function for the given data type. The type inference would be done per command, so cat(1) would be of a type such that if you were to try catting an image (directly) to wc(1) it would fail, because the types (Image, String) would not match. You could also have awesome higher-order functions, so 'map' would remove the need for find(1), etc. I know, Unix purists will rage about this added complexity. And it's true, it would be rather more complex. But in my opinion we ought to optimise for effectiveness of use by the user, not efficiency of execution by the machine: we should look at where we want to go and determine the simplest way of getting there, not succumb to nihilism because "it's simpler to stay where we are." [...] Are you talking about Windows PowerShell? It's even object oriented!111 SCNR flo
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
Greetings. Connor Lane Smith wrote: > On 22/10/2011, Patrick Haller <201009-suckl...@haller.ws> wrote: >> Hickey kicks unix because although pipes = composability, output and >> input = free-form text. We combined data exchange with user interface, >> and user interface usually won that fight. >> >> Say data exchange won; would it help us to rewrite our programs to >> output JSON and our shells to pretty-print* JSON? > > You pretty much just described TermKit [1]. I think there is something > wrong with the shell paradigm, but I'm not convinced JSON-structured > IO is the right approach. My suggestion in the earlier mailing list > discussion was to allow programs to draw directly to the terminal, in > little Xembedded frames, but of course that change only improves the > interface: to avoid "let's all write parsers" you'd also have to come > up with some kind of typing system like TermKit's MIME headers. Also, > the representation of data would be a concern of each program, not of > the terminal, which would probably result in ugly. There were escape codes that allowed drawing basic things in a terminal. Another example how to do it is w3m[0], but this requires too much legacy code. It's still less than having more than one parser and a whole VM for the description lang- uage, like the web would require. Sincerely, Christoph Lohmann [0] http://w3m.cvs.sourceforge.net/viewvc/w3m/w3m/w3mimg/
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On Sat, Oct 22, 2011 at 01:07:38PM +0200, hiro wrote: > > What's suckless about software as a service? > > useful services? > Sorry if I'm not using these buzzwords ansi conform. At least I wouldn't call software/services which depend on the availability of one IP/Domain on the internet suckless! If you do, then I agree with you in the following... > suckless people suck more and more. v4hn pgpIb5ZZ5smEV.pgp Description: PGP signature
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
> What's suckless about software as a service? useful services? Sorry if I'm not using these buzzwords ansi conform. suckless people suck more and more.
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On Sat, Oct 22, 2011 at 12:12:09PM +0200, hiro wrote: > > rtmpdump -r > > 'rtmpe://video.infoq.com/cfx/st/presentations/11-sep-simplemadeeasy.mp4' -o > > simple_made_easy.mp4 thanks too. > Thanks, now I don't have to restart my web browser, but compiling > still sucks on this machine. > Is there still no cloud service taking > random URLs and bringing you download links to all embedded media? What's suckless about software as a service? v4hn pgpcmESQVwtYZ.pgp Description: PGP signature
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On 2011-10-22 09:35, Connor Lane Smith wrote: > > the representation of data would be a concern of each program, not of > the terminal, which would probably result in ugly. Let's separate the concerns: UI and Data UI = users should be able to be retarded && dd if=/dev/zero of=/dev/face This is a good thing. Data = we don't have good backwards compatibility protection; we insert another column output to `ls -al` and all hell breaks loose. Our current workaround = run POSIX only commands and don't change. > The type inference would be done per command, so cat(1) would be of a > type such that if you were to try catting an image (directly) to wc(1) > it would fail, because the types (Image, String) would not match. You > could also have awesome higher-order functions, so 'map' would remove > the need for find(1), etc. It seems like too much; probably only need a few generic ones: string, number, binary, list, hash. Too many types will hurt us just like re-inventing tar as MIME as output delimiter hurt us. > we ought to optimise for effectiveness of use by the user Absolutely; perhaps by reducing the output options of our programs. ;) Patrick
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
> rtmpdump -r > 'rtmpe://video.infoq.com/cfx/st/presentations/11-sep-simplemadeeasy.mp4' -o > simple_made_easy.mp4 Thanks, now I don't have to restart my web browser, but compiling still sucks on this machine. Is there still no cloud service taking random URLs and bringing you download links to all embedded media?
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
Connor Lane Smith once said: > So I think the necessary next step would be to have a strongly typed > shell. To pretty-print you'd need to add a polymorphic "à la carte" > (multiple dispatch) pretty-printing function for the given data type. > The type inference would be done per command, so cat(1) would be of a > type such that if you were to try catting an image (directly) to wc(1) > it would fail, because the types (Image, String) would not match. You > could also have awesome higher-order functions, so 'map' would remove > the need for find(1), etc. Then someone will ask for sub-typing and someone else will want ADTs and we'll wake up one day and have to learn category theory just to use a shell. :) A while ago I thought about doing something similar in a more general way. Say we modified the Plan 9 pipe(2) system call to check the current process's namespace for /dev/pipe instead of using the hard- coded pipe(3) device. This would allow us to build custom type-safe pipes as user-space filesystems. You could then do something like: % jsonpipefs -m /mnt/json % ls /mnt/json data data1 % bind /mnt/json /dev/pipe % produce | consume # these commands expect a serialized JSON stream The beauty of this is that the stream typing logic is separated from individual programs and, of course, the shell. Cheers, Anthony
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
b...@methodlogic.net a écrit : > Is there a downloadable version of this, or something that I can point > mplayer to? Flashplayer == fail for me. rtmpdump -r 'rtmpe://video.infoq.com/cfx/st/presentations/11-sep-simplemadeeasy.mp4' -o simple_made_easy.mp4
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On 22/10/2011, Patrick Haller <201009-suckl...@haller.ws> wrote: > Hickey kicks unix because although pipes = composability, output and > input = free-form text. We combined data exchange with user interface, > and user interface usually won that fight. > > Say data exchange won; would it help us to rewrite our programs to > output JSON and our shells to pretty-print* JSON? You pretty much just described TermKit [1]. I think there is something wrong with the shell paradigm, but I'm not convinced JSON-structured IO is the right approach. My suggestion in the earlier mailing list discussion was to allow programs to draw directly to the terminal, in little Xembedded frames, but of course that change only improves the interface: to avoid "let's all write parsers" you'd also have to come up with some kind of typing system like TermKit's MIME headers. Also, the representation of data would be a concern of each program, not of the terminal, which would probably result in ugly. So I think the necessary next step would be to have a strongly typed shell. To pretty-print you'd need to add a polymorphic "à la carte" (multiple dispatch) pretty-printing function for the given data type. The type inference would be done per command, so cat(1) would be of a type such that if you were to try catting an image (directly) to wc(1) it would fail, because the types (Image, String) would not match. You could also have awesome higher-order functions, so 'map' would remove the need for find(1), etc. I know, Unix purists will rage about this added complexity. And it's true, it would be rather more complex. But in my opinion we ought to optimise for effectiveness of use by the user, not efficiency of execution by the machine: we should look at where we want to go and determine the simplest way of getting there, not succumb to nihilism because "it's simpler to stay where we are." But I suspect this approach is too Haskell-like for most people here... [1]: http://acko.net/blog/on-termkit cls
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On 2011-10-22 00:08, Connor Lane Smith wrote: On 21/10/2011, Pierre Chapuis wrote: > > http://www.infoq.com/presentations/Simple-Made-Easy > Thanks, I enjoyed watching this. "Let's all write parsers." Hickey kicks unix because although pipes = composability, output and input = free-form text. We combined data exchange with user interface, and user interface usually won that fight. Say data exchange won; would it help us to rewrite our programs to output JSON and our shells to pretty-print* JSON? Patrick [*] The cynic points out that people would then spend time customizing their pretty-printers.
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
> Hey, > > On 21/10/2011, Pierre Chapuis wrote: > > http://www.infoq.com/presentations/Simple-Made-Easy > > > > Excellent talk with a good take at the difficult problem of > > trying to define simplicity (in software). > > Thanks, I enjoyed watching this. Is there a downloadable version of this, or something that I can point mplayer to? Flashplayer == fail for me. -bch -- Brad Harder Method Logic Digital Consulting http://methodlogic.net/ http://twitter.com/bcharder
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
Hey, On 21/10/2011, Pierre Chapuis wrote: > http://www.infoq.com/presentations/Simple-Made-Easy > > Excellent talk with a good take at the difficult problem of > trying to define simplicity (in software). Thanks, I enjoyed watching this. cls
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
On 10-21 11:11, Pierre Chapuis wrote: http://www.infoq.com/presentations/Simple-Made-Easy Wow, 2789 LOC in the 100K HTML! -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
[dev] Simple made Easy (Rich Hickey at StrangeLoop)
http://www.infoq.com/presentations/Simple-Made-Easy Excellent talk with a good take at the difficult problem of trying to define simplicity (in software).