91–100 of 270 posts
Excel is probably the quintessential vessel. When people are trying to solve a need they have, they will invest the effort to figure out the tools, including learning enough programming to solve their problems.
I wish PLT was a viable path for more programmers.
Earlier quoted context omitted.
This is (in principle, at least) why we have public funding of basic research.
Which right now is mostly going to the deep learning train :(. There are some academics working in this area right now, Ravi Chugh, Phillip Guo, to name a couple.
This is the same man, Chris Granger, that did a Kickstarter for Light Table, a so-called "next generation IDE," with promotional materials touting as new and revolutionary features that had been standard in IntelliJ, Visual Studio, and even Eclipse for years: http://chrononsystems.com/blog/light-table-concept-vs-realit... Light Table was also ultimately abandoned before completion. Perhaps Granger should rein in his…
Perhaps, but it's pretty easy to make judgements from the sideline about what people should or shouldn't do. I was the PM on Visual Studio. I can assure the things I showed in Light Table weren't there. Nor were they in Eclipse, as I studied that as well. You can pick and choose any number of things from our work over the years and say "Hey, but this looks like that" - I'm sure it does, but the question is does it wo…
Earlier quoted context omitted.
You are being a bit harsh. These were ambitious undertakings with high levels of risk going into them, which, I bet, were well known. I've struggled in this field for 10+ years now and there are lots of dark alley ways that end in walls. Then everyone constantly tells you this has already been done when, no, it really hasn't (at best, the technology is there but so piss poor designed that it isn't useful). If you rei…
> You are being a bit harsh I know, and I rewrote my post several times before submitting it, trying to minimize the harshness. But the pattern with Granger is pretty obvious, isn't it? Grandiose ambitions, over-commitment, and a resulting failure to ship.
While Eve is an interesting problem, the main issues that makes programming hard are the same thing that makes law hard: 1) Specifying something in an unambiguous way. 2) Knowing what assumptions you are making. 3) Anticipating contingencies. Read a contract or the tax code. Even though they are using English (in the US), it requires an advanced degree to be able to craft such legal documents well. It is the same thi…
Agreed, it's hard and it takes a certain type of person to be effective at it. I'd go a step further and say that tools designed to make programming "easier" or for the masses not only are a wasted effort but actually detrimental (I'm not taking about learning environments such as MIT Squeak here, that is altogether different). We need better tools that let someone who masters programming to take their vision and rea…
Earlier quoted context omitted.
Really agree with that last part about framing it as a better spreadsheet first. What's the language you're working on? care to share a link?
I've always wanted to make a programming language, but I just tell everyone it's a shell, since that is more understandable and less "threatening" [1]: http://www.oilshell.org/ The thinking is that if I fail to make a new programming language, which is the 99% case, then at least I can make a "better bash", which I know people will use if it works. It was on the front page last week, although this is the second time…
We need to have a conversation about the possible paths to make programming more widely accessible. Chris saw the problem clearly and tried to fix it. Respect. I am most impressed with the number of iterations he was able to crank in the context of a startup. But ultimately a startup may not be the best place to start, because low-end programming is not a short-term growth play. We have to play the long game.
What if programming is just hard?
"we need to add certificats and raise the bar, quality over quantity"
Im not sure why that comment was delete, hn is becoming very authoritarian
While Eve is an interesting problem, the main issues that makes programming hard are the same thing that makes law hard: 1) Specifying something in an unambiguous way. 2) Knowing what assumptions you are making. 3) Anticipating contingencies. Read a contract or the tax code. Even though they are using English (in the US), it requires an advanced degree to be able to craft such legal documents well. It is the same thi…
And an upper bound to how long it can theoretically take to build something is the same as the time to transmit that information for a human plus some small epsilon: computers can run very fast.
So getting a computer to do what you want ideally should not be close to as slow and difficult as it is today. This is sort of the true goal, rather than formally specifying what you wish the computer would do. If you believe the goal is formally specifying what the computer does on top of bulletproof abstractions, we're already very far away from that - programmers today don't tell a CPU how to do branch prediction, or a compiler how to optimize their code, for instance.
Probably a really good system could do even better than the upper bound above - what if you knew what someone wanted before they could even describe it to you, and you built that for them?
Earlier quoted context omitted.
I've always wanted to make a programming language, but I just tell everyone it's a shell, since that is more understandable and less "threatening" [1]: http://www.oilshell.org/ The thinking is that if I fail to make a new programming language, which is the 99% case, then at least I can make a "better bash", which I know people will use if it works. It was on the front page last week, although this is the second time…
Are you worried that you might end up reinventing Perl?
https://www.reddit.com/r/linux/comments/7lsajn/oil_shell_03_...
I mentioned I would write a post called "Python Is Not an Acceptable Shell". I think it's also clear that Perl isn't an acceptable shell, simply because shell still exists. And awk and sed still exist -- in fact I believe it's common these days to use shell/awk/sed but NOT Perl, which means that Perl fell short of its mission. (I certainly prefer shell/awk/sed to Perl.)
There is overlap between Oil and Perl, which is ironic because I've written probably 100x-1000x the Python code that I have Perl code. But I would say I'm tackling some of the same problems, but not using the same solutions.
An obvious thing is that Oil will not be nearly as line-noisey as Perl, which is the thing that is most often complained about (rightly or not).
Perl also doesn't have some obvious shell constructs like pipelines. I'm pretty sure you just "shell out" for such things, which isn't a good solution.
I've been looking at Perl 6 too, and there is overlap there too. But I honestly think a new shell has more of a chance of being adopted widely than Perl 6. There is apparently still an unresolved schism between Perl 5 and 6:
https://www.reddit.com/r/perl/comments/7r1b33/an_open_letter...
As far as I can tell, Perl 6 is even further from a shell than Perl 5 is. Python 3 is also less suited for shell-like tasks than Python 2 is (due to its Unicode conventions).