Interesting article. The second paragraph was a tad confusing so I thought I'd share what I found: I think there's maybe confusion between two "camel AIs":
> CamelAI is an open-source, modular framework for building intelligent multi-agent systems for data generation, world simulation, and task automation.
> [...] said Miguel Salinas, CTO, CamelAI.
1. CamelAI, where Miguel Salinas is CTO, their website is camelai.com, but it's not a an open source framework they offer. Their "AI data analyst" tool seems cool though.
2. CAMEL-AI, camel-ai.org, the actual open source multi-agent framework, and it also looks like some nice technology right there.
Some day we will recognize that some areas of "programming" are very different and require different skill sets, and eventually different titles.
We tend to call everything "software engineering" so that everybody can feel proud of such a title ("I'm an engineer"), but engineering is certainly not about figuring out how to vertically center divs with CSS (and it's also not about proving algebra theorems either -- even if it can be essential when it comes to specific problems that require it).
I can't imagine Linux and PostgreSQL being built without "science", they use a lot of it, and I'm pretty sure the authors all have read SICP and those theoretical books.
Poking at things proved to be efficient to building things quickly, but it's just not how one builds critical systems/software that are robust, efficient and maintainable.
Engineering (no matter whether mechanical, electrical, software...) is the process of designing an artifact to be constructed out of available materials, which meets a set of requirements while minimizing cost.
In mechanical engineering you design your artifact using off-the-shelf bearings, motors, pumps, etc.
In electrical engineering you design your artifact using off-the-shelf cables, contactors, relays, VSDs etc.
In electronic engineering you design your artifact using off-the-shelf ICs, resistors, capacitors, resonators etc.
In IC engineering you design your artifact using off-the-shelf silicon wafers, etching chemicals, core/logic designs etc.
It's turtles all the way down, and software is no different.
Most engineers are working under some quantifiable or standard set of requirements, rather than ad hoc "make it work good and look pretty" requirements. Most engineering disciplines also have processes to ensure that its adherents take the proper precautions to avoid poor and unsafe designs, delivered in standardized sets of guidelines and recommendations.
And many programmers aren't engineers, they're just interested tinkerers; people who play around in their free time enough to know how to make something work. Not unlike if you went to the store, bought some wires and batteries and tools, and then played with them until you got hired as an electrician.
Sharing culture is instinctive. People will do it. You might as well try to tell people they can't have sex without your permission unless they pay first. Oh wait, that's the porn industry. Everyone pays for porn, right?
> I can't imagine Linux and PostgreSQL being built without "science", they use a lot of it, and I'm pretty sure the authors all have read SICP and those theoretical books.
Unless you restrict "authors" to the people that worked on the original Postgres95 (and maybe not even then), I'm certain that that's not generally the case (being a postgres committer and not having read SICP).
Software Engineering is more about methodically solving software problems than it is about which problems are being solved. A web developer who writes rigorous formal tests for a new page is engineering just as hard as an embedded developer writing rigorous acceptance tests for a board-support package. The engineering comes from the rigor and the fact that there is a controlled process for how software features get implemented.
I agree with that. The engineering process can be applied on every type of problem.
Yet, for that specific web dev problem, I haven't seen any way of formally testing the rendering web pages, which would make it consistent on every browsers. The testing process (almost) always leave that up to the developers themselves, and refreshing pages is the norm.
> learning about a new language (without becoming proficient with it)
Mostly true, but there are languages which are completely useless without becoming proficient with them. In my experience Forth and J are such languages: you can "learn about" them, but you won't really understand them without using them for some time. So I suspect APL, K, Q and Eli here are similar; the question is what will I gain from becoming proficient with one of them or alternatively is it worth becoming proficient in one of them if I'm already proficient with another.
Most text editors operate text substitutions (like "<-" turning to "←" automatically), so ASCII doesn't seem inevitable anymore (and I believe it's even truthier with virtual keyboards).
I worked in a company where APL used to be very strong (large french truck manufacturer) and they even had lots of programs written in Scheme for assembly-line optimisations in the late 90s. Most of those have been rewritten (should I say... painfully rewritten, and now buggy) in Java in 2005.
I feel like APL/CLisps/etc. were the right solutions but developers/managers were/are scared when they saw some of the mathematical/proof concepts they had to use, and were afraid of when they learned about them at the university.
We had an APL implementation and it was replaced 5 or so years ago.
It wasn't because of scared management. It was because they were paying for language knowledge not business knowledge. What replaced it, mostly C++ and Python, had better tooling and a wider pool of subject expertise to draw from.
While you're definitely right when it comes to printed books, self-published books tend to be pretty up-to-date (as an example, I believe "Agile Web Development With Rails" runs a test suite against Rails and the author gets notified the moment something's not accurate with the book, maybe it's the case for this one).
Not yet.. I've set up a GitHub clone and had to patch OpenSSH: the authorisation process can execute an external command (AuthorizedKeysCommand option IIRC) but doesn't provide enough information to do a DB lookup à-la-GitHub.
AuthorizedKeysCommand doesn't scale. Particularly for Github and Bitbucket because they would need to return a few million lines.
From the man page:
Specifies a program to be used for lookup of the user's public keys. The program will be invoked with its first argument the name of the user being authorized, and should produce on standard output AuthorizedKeys lines (see AUTHORIZED_KEYS in sshd(8)). By default (or when set to the empty string) there is no AuthorizedKeysCommand run. If the AuthorizedKeysCommand does not successfully authorize the user, authorization falls through to the AuthorizedKeysFile. Note that this option has an effect only with PubkeyAuthentication turned on.
The AuthorizedKeysCommand script is invoked with the user name of the connecting user, which isn't enough to do a database lookup, as, for example, on GitHub all incoming connections are from user git.
The patch basically makes OpenSSH send the incoming user key to the script's stdin, and from the key it's trivial to match it against a user.
Post author here, unfortunately no, after some time, we realized it was quicker to develop a complete SSH server than patching some legacy C code. It was really confortable to work with go to do that.
It's true yet it's going to be free as in "build it for yourself and maintain it all your life".
I tend to forget how I've built some tools I'm using and I sometimes spend hours re-understanding what I've done.
Regarding the price, services like feedly - disclaimer: I've been a paying subscriber in the past - cost $45 per year, and it's not been clear to me what value it was providing me (except some integrations with 3rd party tools maybe).
Anyways, I would certainly love to see an integration with RSS readers like the one mentioned above (which would also mark as read all the posts I received in a digest).
When private views become public, one should expect to be "judged" by others, especially when this person is explicitly enlisting the company he is working for in such a campaign and is a well-known field activist.
AFAICT he _had_ to tell what company he was working for. On that very moment, I'm curious to known what went through his mind. Was there any hesitation? Was he realizing he was bringing Mozilla into this debate?
My personal believes is that whether this was deliberate (bringing Mozilla explicitly) or not (being "forced" to list his employer), this was a really bad move you - as a board advisor or investor - will have to deal with and take public actions against.
> CamelAI is an open-source, modular framework for building intelligent multi-agent systems for data generation, world simulation, and task automation. > [...] said Miguel Salinas, CTO, CamelAI.
1. CamelAI, where Miguel Salinas is CTO, their website is camelai.com, but it's not a an open source framework they offer. Their "AI data analyst" tool seems cool though.
2. CAMEL-AI, camel-ai.org, the actual open source multi-agent framework, and it also looks like some nice technology right there.