6 ms·
> kOS is coming. Nothing will be the same afterwards. There seems to be this strange idea going around that if we just get the right tool, everything else is g
by jeffreyrogers 12y ago
> kOS is coming. Nothing will be the same afterwards.
There seems to be this strange idea going around that if we just get the right tool, everything else is going to change forever. I see this a lot with people trying to create IDEs that let non-programmers create programs without really knowing how to code.
But the thing is, most people just don't have anything worth coding. The problem isn't that the tools don't exist. They do, even if they aren't perfect. It's that making something that matters isn't an easy thing to do. And no tool can change that.
- dustingetz 12y agoI don't know, think bigger. The internet changed things forever, and before that computers. Revolutions have been happening at exponentially increasing rates. The explosion of software complexity we see today is perfectly ripe for innovation and maybe even could cause another revolution. The software industry isn't exactly mature when you take a longer time perspective.
- sounds 12y agoPart of what made the internet such a big change to "things" was that it didn't attempt to replace "everything" wholesale. I'm fairly sure that form of the idea was tried -- for example, PC/GEOS -- but the idea that succeeded was the one that allowed the most people to try it out and see what it did. I'm trying not to add more words to that paragraph, though I could/should.
- dkarapetyan 12y agoNot knowing how to code is not really an issue because we can and do teach people how to code the same way we teach people how to count and do basic algebra. What we can't do well is teach people how to solve novel problems that they haven't encountered before.
- eggy 12y agoThe reason k, q or other array languages like J (which I use) help, not teach, people to solve novel problems is that they give you abstractions to quickly play with in order to tackle novel problems. My take on this whole thing is that these array languages (APL, k, J, q) are a perfect fit for things that are essentially arrays - big data, images, etc... And to those who shy away from the seemingly 'noisy' syntax, I point them to mathematics. Until you understand the sigma symbols and others, it is noise too. Why are all the new languages getting hot on 'vectorization' - Julia and company - because GPUs and data are all array-based. To have the array as your lingua franca puts you in a good position for all sorts of attacks on modern computing needs. And for those who cannot live with the syntax, and say how can you create a dsl - you can. Here is a J example of computing averages: +/%# You can set this up as: avg=: +/%# or tally =: # divide =: % sumall =: +/ How's that for a dsl? Which allows this now: avg=: sumall divide tally avg 2 4 6 4 EDIT: I forgot to add that these operations, as others in J or APL, work on scalars, vectors and arrays without any special typing or handling. See this presentation for at least the first 5 minutes to see J in action with explanation: http://www.infoq.com/presentations/j-language http://www.infoq.com/presentations/j-language The conciseness allows you to start seeing the small patterns in the small expressions just like mathematics, hence bringing clarity and speed of abstraction to your concept manipulations.
- KayEss 12y agoI think part of the difficulty here is that it's almost like Haskell's point free style, but not quite. It isn't really clear where the arguments to avg go. It seems that it's meant to be a bit like this: avg list -> (sumall list) / (tally list) I guess you just need to know how the argument you give to avg when you use it distributes over the functions that comprise the expression. The list argument to tally isn't a problem, but why does sumall get it's own copy of it? Or is the execution model something else entirely?
- avmich 12y agoIn J there are two special ways to combine functions which are written using special syntax. Namely, 1) when you want to calculate f(y, g(y)) , you write (f g) y - this is "hook" of one argument (monadic, in J terms) 2) when you want to calculate f(x, g(y)) , you write x (f g) y - this is "hook" of two arguments (dyadic) 3) when you want to calculate f(g(y), h(y)) , you write (g f h) y - this is monadic "fork" 4) when you need f(g(x, y), h(x, y)) , you use x (g f h) y - dyadic fork 5) when you have a train - say, (a b c d e) x - longer than 3 elements, then you consider rightmost 3 functions (functions are called verbs in J) as a single fork - say, f - and then consider (a b f) x . So (a b c d e) x is b(a(x), d(c(x), e(x))) If the train length is even, the last operation becomes hook - so x (a b c d) y is a(x, c(b(x, y), d(x, y))) You can express any computation as a sufficiently complex train.
- geocar 12y agoIf I am from another planet, and say I don't know why programs are so big and slow and buggy, and the most complicated program you see I've produced is a glorified calculator, it's too easy to be patronising and say well, that's because you haven't done anything complicated. However if I then show you a programming language, a database engine (similar in capability to SQL but around 1000x faster), a graphical desktop with icons, mouse, editors, filesystems, ISR, and so on- and it's still under 400 lines of C code, then maybe it's easier to have this conversation that I think we need to have: That maybe all you programmers have simply been doing it wrong, and there's something fundamentally wrong with the way you and everyone else programs computers. I think most programmers take so much offence from the thesis: that everyone programs wrongly (or badly) and that a fundamental shift in the way we program could make programming much better, that it's been difficult to actually work on this problem. Just look at all the people who are complaining about the text editor being difficult to read without saying I can't read this, and I want to get better. And I think it should be obvious: You've built bridges for thousands of years, so you expect you're pretty good at it now, and yet there are still improvements in bridgemaking today; why do you expect programming to be any different? Why do you have "best practices" for programming if you've only been doing it for a few decades and don't really know how to do it yet? Maybe it's much easier to think we're working on giving non-programmers the ability to program, but we're not: we're trying to make programming suck less.
- beagle3 12y agoI think Douglas Adams' SEP[0] field is a good description of this. Most people ignore what doesn't fit with their logic - doubly so if fitting it in would show them that they have been wrong/wasted money/wasted time in the past. (The Upton Sinclair quote about "it's difficult for someone to understand something when their salary depends on not understanding it" is also relevant). It's that way with religion, paradigms in medicine, and even chemistry/crystallography (see e.g. Shechtman vs Pauling[1]). It's human nature. It is also worth pointing out that while this specific version of K is new, K itself is 20, and it is mostly purified APL, itself over 60 years old. People have been ignoring this since forever (APL found stellar success in the OR community in the 70s and 80s on its own, in trading floors in the 80s and 90s thanks to Arthur Whitney, but has since mostly disappeared) [0] http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem#Fiction http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem#Ficti... [1] http://www.theguardian.com/science/2013/jan/06/dan-shechtman-nobel-prize-chemistry-interview http://www.theguardian.com/science/2013/jan/06/dan-shechtman...