Fork me on GitHub

I think it was back in the seventies when there was a big AI hype and with it all the lisps appeared. Also I think it was that lisp was the language considered to be used when doing AI.


Anyway, what came was the invention of JS 20 years later and another 20 years later this is how we use it today. Given these experiences I doubt AI will make it this time ­čśä


As an AI outsider, I see 2 practical problems with application of ML: - it's terrible at explaining "why" (Computer says "NO".) - people in the industry who know ML are mostly recent grads. Humble programmers recognise problems that just need a bunch of ifs/dispatch tables. And what I've seen about total newcomers, they tend to like complexity (it it is "their" complexity).


Plus it introduces another class of vulnerabilities - see noisy images that get recognised as the face of Her Majesty.


@sveri: when you look at all the people that a manager no longer needs because of AWS/GCP, doesn't it appear that programmers are next?


I'm sure at some point, people believed that setting up servers was complicated (all the things you have to configure, how much swap space, how many partiitons, which file system, which packages to isntall, etc ...) -- and AWS has basically reduced it down to "okay, choose one of these 4 standard options"


at one point, we thought: database management is ahrd -- and AWS has changed it down to "do you want mysql, postgresql or auroradb -- how many cores and how much RAM" "okay, wiat a few mins while we boot it up for you"


@qqq First I would like to remember you the problems you self have with GAE. What these tools are good for right now is to get a small prototype up quickly. Then, if you want to stay with GAE or AWS or whatever you need programmers that know the ins and outs of these platforms. So yes, they abstract stuff away, but the abstraction is not free and has a cost in itself. And while we automate a lot of stuff I think the total numbers of developers still is rising and still the demand for programmers is larger than the raw resource, I would say. And yes, there will surely be more automation, because this is what we do, most of the times, but I dont see programs righting programs any time soon.


@sveri: I'm not quite convinced of that, I think 100% of my problems are due to (1) I'm using Clojure and (2) I'm not willing to pay for support. I suspect in the future, most hardcore engineers will be inside GAE/AWS, and many managers, instead of hiring engineers, just pay for support (which would acbually be cheaper).


@qqq The ticket I linked to, that showed these problems are existent, talked about Java having the same problems and python too. So I dont see how clojure should be at fault here.


It also showed, that the problem is tangential to the support, it just exists and seems to not go away anytime soon, following the comments on thet icket


I recall a ticket, but I don't remember the contents.


I would advise to have another look again as it was related directly to your problem.


Also, if I was to evaluate GAE I would not pick it anymore for anything that uses the JVM after reading the ticket


Yeah, I'm looking for it


but slack scrollback UI is not optimal at all


thats true -.-


anyways (1) I'm sticking with GAE


(2) despite the problems, I feel like GAE has reduced my need for engieners by 90%


i.e. I can build this using only 1/10th the people I would need if say, I were forced to use DO


Thats fine and Iam not arguing that, all I say is that you will run into different problems.


I think I know where this went wrong.


I started out making the argument "will computers replace human programmers"; whereas the point I'm really arguing for "computers will eliminate 99/100 programming jobs; and the reamining job will be really complicated"


I think we are still in the phase where all the automation is an enabler. GAE enables people to achieve more in less time. But there is still the need for more and more software.


I feel the need to say that clojure is awesome. I'm learning golang, and every step of the way can't help but think... "clojure does this better". I've never had that with Ruby or Python when learning a new language.


Currently doing the go thing for some tooling. Clojure is great. I get core.async, The syntax in go for the same thing still confounds me.


They also still haven't quite figured out dependencies yet. Spent far too long debugging why a vendored dependency was being ignored. Apparently only vendor/ in GOPATH gets searched, nothing else. So I still must follow their directory conventions which don't align with my own.


The way Go diverges from common practices worries me.


I can tell when some CLI tool has been written in go.


Dependencies has been a source of frustration in go for me as well. On the plus side, the presentations and documentation about goroutines is far superior to what is available to core.async, and learning about that helped me understand core.async much better.


not-raspberry: When you say diversion, do you mean the way that it handles cli type things?


@jstew -help instead of --help, not recognizing --as "Hey, everything to the right is positional" etc.


When some standard is established and good, diverging from it is just arrogance.


Basically, when CLI is botched, it's safe to assume Go. Most languages have standards-compliant argv parsers.


Of course, go has libs like that, but they are not standard.


@not-raspberry Leiningen does something I think is worse: lein repl :connect 7036 instead of lein repl --connect 7036


it's worse. And java isn't better. But tools.cli is fine.


tools.cli works fine for me. I've heard that boot has a pretty good cli library but I haven't tried it yet.


Boot also has the nifty adzerk.boot-jar2bin plugin that makes writing self-executing jars, much like boot itself, easy peasy


yeah, that's super handy, Lein has lein-binplus which is similar


tools.cli is for clojure, not just for lein


I was referring to defclifn inside of boot. It appears to be really nice for handling subcommands. I remember reading that you can use it outside of boot as well by requiring [boot.cli]


Could be it's more Powershell-ian philosophy? Don't know. That would come along with a lot of other baggage, I expect.


indeed, unless you're already using boot.


It appears to make some assumptions for you as well, which may or may not fit into what you want to do.


Totally agree with @jstew: working on a react/redux es6 project. The current tooling in javascript is very good but clojure/clojurescript as a language is a freaking amazing thing. I was very surprised by the amount of dependencies that you need to get a basic thing going in es6: I have 999 dependencies in my node_modules.


I would bet noop is a part of that:


No doubt you've got a number of copies of Idleness.txt too: