gorgeous.

however, given just an expected output there will be lots of conforming inputs. you still need to figure out which of those randomly generated functions not only produces the same output by chance, but actually conveys the expected operation. in short, you would have to run the test for all possible inputs.

that's for a single unit test. imagining integration test just gave me a shudder :)

the demand of functionality however is also getting more. did you expect anyone to ask you to do elgamal encryption on a cell phone browser back in the day?

there will be always problems to be solved. the trivial stuff you can give to 'key punchers'. or robots, for that matter, once we have created the right tools. i don't think we have. article is bs (if it is even remotely related to the summary. didn't bother to read)

hey, we will have to invent some sort of agilatronics to plot the value of that onto our powerpointatrons!

yeah but his signature is cool!

there, FTFY

you can, just don't expect it to be widely adopted. plus your niche shouldn't have security and usability concerns.

also, be aware that applet support isn't likely to last much longer. several plugins aren't supported anymore on the desktop, and there aren't any at all for mobile devices or tablets. since java 1.7ish even running signed privileged applets on supported browsers on desktop is a pain. in short: maintaining applet support is problematic and nobody seems to bother anymore, specially since there is no benefit: js can now handle most of what applets did in the browser in the past, right out of the box and better.

there still are a few very specific usecases for applets like, for example, to access smartcard readers from a webapp. but even then, applet maintenance and deployment is hardly optimal and you'd probably will end up ditching the whole idea and lookig for a workaround.

and of course you don't have to learn "every language out there" if you don't want. however, if you want to do stuff for the web today (that's what applets were for) you simply won't get away without learning js. it's not optional.

"did you just say lisp?" XDDDD

very true for the "npm" constellation, and possibly for the particular projects/products you have experienced. but this just reflects that it's a new platform and a hyperactive ecosystem. sure it has it's fair share of hipster crap, but just keep looking, there's quite solid stuff too. and there is a lot you can do with pure node.

besides, running java applications on linux has sufferd the very same problems for years (hell, it still does sometimes!), even when java was more mature back then than node is now. and you sure will remember what a complete dependency nightmare java was before maven was adopted.

well, i'd say just avoid that software and ... it's my impression that you are overestimating what "professional" means nowadays. :-)

this is not about applets, which have been dead for years already. it's about javascript as back-end platform.

but TFA (without reading it) is pure nonsense. back-end js (= node.js/io.js) is very interesting but far from competing with java. java's installed base is simply too big to even speak of that, and the paradigm shift is also considerable: node.js is based on monothreading and non-blocking io, a completely different model. it's also very new technology just emerging. but still a very interesting architecture. it's also much more fun and exciting. :)

i guess we have about 4-5 years of fun ahead until node gets it's share of certifications and "experts" and best practice bullshit, and until someone comes up with some moronic idea like java's generics (yes, 1.5 already signalled java's decadence and oracle had nothing to do with it (imagine!)) and everything starts to rot and turns to yet another boring, stupid, ugly cobol, sorry, i meant java. industry never had a heart. but we irredent coders do!

i actually meant better as in designed for collaboration from the start.

which is what was asked for. and it's pretty obvious that these users *need* to start doing things differently.

*troll mode*

someone might also consider a plus to get rid of the load of superflous and bloated crap that ms has piled for years on top of basic table, text and graphic processing, which is what people usually needs. but then someone might have some very bizarre use case (*) and want to call that 'features', then it's clearly not for him.

* i routinely have to refuse to accept documents, prompting the source to reformat them, get rid of incompatible crap or provide them as html or plain text or even pdf or else get lost. they get it, i usually only have to ask once. of course, this depends on being in a work environment where the focus is on communication and content and where you can reasonably expect your collaborators to not act like psychotic monkeys in microsoftofficeland and produce content that can be also shared outside of that zoo, ymmv.

chance. next.

doesn't solve concurrent edits = you have no single source of information = you can't just pick the last.

i don't think their problem is solvable just with tools. they need to understand collaborative workflow: you either block or are prepared to merge often. i don't know of any such tool that doesn't require a minimum of training and thought. i've heard microsoft claims to have such thing in office 365. and i wouldn't recommend ms to my worst enemy but since it looks like they are on the hook anyway they may as well get raped to the end, won't hurt that much more.

another radical alternative is google docs. yes, sheesh, but better than office.

dunno if you realize that web sites started to spectacularly suck just about the time the UX buzzword came out. i guess real accessibility and usability were too boring and too hard to get right, so the whole UX nonsense was invented. users, you know, will swallow anything you throw at them anyway.

on the topic: what engineering skills??? you're really talking about web development??? just about 1 in 10.000 sites even cares about engineering topics. OP must be smoking waaaaay too much github.

this could be easily added without breaking compatibility. you could even write a preprocessor, if it bothers you that much. it is indeed a big constraint with little or no benefit, but most python users seem not to mind, or even like it. many languages have made some of such arbitrary decisions that are purely idiosyncratic, usually pointless but defended with zeal. if the language has other values you simply live with it or hack your way around.

what's the point of having a dba simply copypasting the queries you write?