61–70 of 73 posts
Earlier quoted context omitted.
Ah just saw the reason for the name on github. I thought you chose it out of the blue. What about a line from Anchorman: "Great Odin's Raven!" or something to that effect :P
@Metapony: you're hellbanned, for quite a while now.
Earlier quoted context omitted.
A service like this needs booth. Writing processes in a programming language AND a possibility to reuse them for different stuff. IFTTT is a nice idea, but I can't do stuff like: 1. check rss feed for new stuff 2. generate links to the real data from the links in the rss. (most RSS feeds just suck, because they don't have the full articles and sometimes they link to crazy pages where the article is split in 10 sub-pa…
Most of the time the real stuff isn't easily crawleable without writing a pice of software just for the source. But you're right, there should be a possibility to get such apps to work without any code. If I wrote a crawler for images from a DA-artist, I didn't want to rewrite it for every other one... Shameless offtopic plug: that's exactly what we at http://import.io are trying to solve. We're in Developer Preview,…
Earlier quoted context omitted.
Heh, I'd forgotten about that one :D. I've had the idea kicking around for a long time, and have spiked it in a few different languages (the Haskell version was mainly to try out FRP and reactive-banana; I've got the furthest on a Python one that hinges around agents tied to RabbitMQ as my current "production" deployment). I'll try and get the Elixir stuff cleaned up and published over the next week :). The only sour…
Would you care to open the Python implementation? (and thx for open sourcing the Ruby one)
Good stuff, although I'm not a Ruby user. Tools like this should be much more widespread. Code Is Bad because you can't write code without a minimum level of vocabulary and syntax, and that excludes a lot of people. True, code offers the most flexibility, but 99% of the time people don't need all that flexibility and want to accomplish fairly straightforward tasks - which is why GUIs are the norm. With GUIs and visua…
>> The oft-repeated cry that 'everyone should learn to code' is wrong, wrong, wrong. It is right, right, right. We don't tell our children, it's ok to stop at crayons and comic books. Yes, DSPs and CAD are much more productive at their niches than coding in a "normal" language. I find Chrome more productive than "telnet 80" - but knowledge of coding helps me structure my excel spreadsheets more usefully than those pr…
Yet in CS there are very smart people such as Alan Kay and the Constructivist types such as former-OLPC now-Sugar, all screaming about how we're learning brain-dead languages on machines doing their worst to make it impossible to become useful and literate without a ten year breaking in period until we become journeymen codesmiths. These machines & languages are not trying to help all of us become fluent about what it is that is running: they are there so that those who already know the language and the program can continue advancing it, until it's shippable, at which time it will execute: when we say learn to program, more often than not we mean learn to fit yourself in to that production cycle.
I'm not trying to argue one way or another about the learning to code merits, but it's important not to think of coding as this completed worthwhile thing in the way we do it! OP is an example of systems research to allow us to create agency in systems: that is programming, coding of behaviors, and one who gets good at it has gained a coding literacy. Ditto for spreadsheet wizards!
My point is that we are free to build entirely new forms of literacy both akin and unlike the programming languages we have now, and that the one's we have now are arbitrary. And, judging purely from the size of assumed knowledge passable programmers rely on, I'd contend, as do others, we'd do a lot better at making a literate society with different languages and forms, more tailored to introspection and mirroring their behaviors than towards producing a running application artifact: if we want people to learn systems, make the systems be more about being learnable and meddle-able than about being execution engines. It's our agency we need to see reflected, and IFTTT and OP are great examples of coding where seeing our agency at work at the end is far more of a direct path: it is radically different than how programming today works, in a good, different and fundamentally very important way.
In leaving, I'll point to a perspective on these better machines: these are machines that build agency by way of using APIs of other machines. I'm convinced that machine to machine interface is the key to making programming not suck, not a drain for this planet, for those who would be composers of code. rektide's gentle suggestion- machine to machine systems interfacing is the way to beget human/machine interface.
Earlier quoted context omitted.
>> The oft-repeated cry that 'everyone should learn to code' is wrong, wrong, wrong. It is right, right, right. We don't tell our children, it's ok to stop at crayons and comic books. Yes, DSPs and CAD are much more productive at their niches than coding in a "normal" language. I find Chrome more productive than "telnet 80" - but knowledge of coding helps me structure my excel spreadsheets more usefully than those pr…
No one would call crayons and comic books bullshit, because they are artistic mediums where the expression can stand by itself, has the intrinsic value of being expressive. Yet in CS there are very smart people such as Alan Kay and the Constructivist types such as former-OLPC now-Sugar, all screaming about how we're learning brain-dead languages on machines doing their worst to make it impossible to become useful and…
In the spirit of understanding, can I try to summarise your points as I get them
1. Programming as it is currently practised is still very focused on implementation / procedural.
2. Anyone who uses a DSP / other system to perform a task they want (agency) is doing some form of programming, and that is valid, as it is a step on the path of literacy.
3. The path of literacy might not be towards the current endpoint of neckbeards and Assembler and 10 years to be good.
4. There is likely to be new languages, new systems that will enable people to do programming / achieve agency at different points and with different degrees of abstraction
5. Its Lisp isn't it :-)
I agree with you. Which tells me I may have misunderstood!
But I am perfectly happy to agree that some form of code literacy is a good thing, and that the language of the future has not yet been invented I am also quite prepared to believe.
Aw, hell, it is Lisp :-)
Edit: I like the idea of OLPC etc being about how to meddle. I suspect that the machine you are referencing might be the one in Nand2Tetris - an interesting project that takes undergrads from Nand gates through to compilers and languages on a virtual machine interpreting the CPU built from the interpreted Nands.
Earlier quoted context omitted.
Heh, I'd forgotten about that one :D. I've had the idea kicking around for a long time, and have spiked it in a few different languages (the Haskell version was mainly to try out FRP and reactive-banana; I've got the furthest on a Python one that hinges around agents tied to RabbitMQ as my current "production" deployment). I'll try and get the Elixir stuff cleaned up and published over the next week :). The only sour…
Would you care to open the Python implementation? (and thx for open sourcing the Ruby one)
Good stuff, although I'm not a Ruby user. Tools like this should be much more widespread. Code Is Bad because you can't write code without a minimum level of vocabulary and syntax, and that excludes a lot of people. True, code offers the most flexibility, but 99% of the time people don't need all that flexibility and want to accomplish fairly straightforward tasks - which is why GUIs are the norm. With GUIs and visua…
>> The oft-repeated cry that 'everyone should learn to code' is wrong, wrong, wrong. It is right, right, right. We don't tell our children, it's ok to stop at crayons and comic books. Yes, DSPs and CAD are much more productive at their niches than coding in a "normal" language. I find Chrome more productive than "telnet 80" - but knowledge of coding helps me structure my excel spreadsheets more usefully than those pr…
This is really fantastic. I've been working on a new UI for something like this and I'd love to compare notes once I dig in a little bit. Great stuff!
Earlier quoted context omitted.
No one would call crayons and comic books bullshit, because they are artistic mediums where the expression can stand by itself, has the intrinsic value of being expressive. Yet in CS there are very smart people such as Alan Kay and the Constructivist types such as former-OLPC now-Sugar, all screaming about how we're learning brain-dead languages on machines doing their worst to make it impossible to become useful and…
Thank you. In the spirit of understanding, can I try to summarise your points as I get them 1. Programming as it is currently practised is still very focused on implementation / procedural. 2. Anyone who uses a DSP / other system to perform a task they want (agency) is doing some form of programming, and that is valid, as it is a step on the path of literacy. 3. The path of literacy might not be towards the current e…
Well, it's the path to literacy in signal processing (or whatever domain it happens to be). I learned to code >25 years ago and I still sort of like doing small things in assembler or throwing something together quickly in C. But I really don't like dealing with collections of big lengthy text files for projects of any magnitude. It's like reading a description of a painting that begins in the top left corner.
Put another way, text is the problem. Why, I ask myself, don't IDEs automatically generate dynamic flowcharts? Why do I have to spend so much time typing to create structure, when I want to focus on algorithms? Have a look at this software, which is aimed at roboticists but has other applications; it has modules that let you drop into Ruby as needed (and there's another version that allows entry of C or assembler) but doesn't require you to work that way if you don't need it. this is what an IDE ought to look like.