|
This was sent to me by one of our DBAs, from our old VB codebase.
|
#
?
May 14, 2014 16:54
|
|
|
|
| # ? May 31, 2024 20:41 |
|
|
The Insect Court posted:The "argument" for NodeJS was that there were a shitload of JavaScript "developers" and NodeJS let them spread to doing server-side stuff without using a sensible language. Ah, yes, the sensible languages to write server-side code in: Python, Ruby, PHP, and Java.
|
|
#
?
May 14, 2014 16:55
|
|
|
Voted Worst Mom posted:Ah, yes, the sensible languages to write server-side code in: Python, Ruby, PHP, and Java. Yes.
|
|
#
?
May 14, 2014 18:12
|
|
|
I find it acceptable that, when multiplying matrices that have inconsistent dimensions together, an exception is thrown. (Having that information at compile time would be great, but we don't live in a perfect world.) I'm even happier when the exception message tells me what the particular inconsistent dimensions are. But this:code:
|
|
#
?
May 14, 2014 19:32
|
|
|
Documentaion. 
|
|
#
?
May 14, 2014 19:38
|
|
|
Aleksei Vasiliev posted:Admirable ideas. Let's take a look at this easily auditable code. This code is part of tweetnacl, which is a compressed, portable version of NaCL which fits into 100 tweets. http://cryptojedi.org/papers/tweetnacl-20131229.pdf
|
|
#
?
May 14, 2014 20:34
|
|
|
Hammerite posted:I thought the argument for NodeJS was that you could write the client-side and server-side code in the same language, and potentially share some code libraries between the two. I can't see what the argument would be for having JavaScript code running on an Arduino-like device. As with many things in life: It depends. Node kicked off because V8 happened. A separate, easy to embed JIT. At the time, very few good jits existed for dynamic languages, or the popular implementations in use were just bytecode interpreters. As a result, you could in theory write faster javascript than you could write faster code in other comparable languages. The next big difference is that node's http interface wasn't built around CGI. i.e, you could use modern features like websockets. Meanwhile, python, ruby et al, with WSGI, Rack were stuck with the "call this function, return this status code and data" interface. This is what some people meant when they said "closer to the metal", it was easier to use websockets in Node, and many more HTTP shenanigans. So someone bolted a http server to a javascript runtime. It made sense for a bunch of small http toy backends. Low demands and often fun to build. Node is a lot newer than Python or Ruby, and learned from their experience - getting some form of package management far quicker than they did. So for someone who wanted websockets, or maybe just wanted to start moving from client side code to server code, Node made it obscenely easy. Similarly, PHP let people move from HTML, to templates, to web applications talking to databases incredibly easy. Like with many pieces of popular software, it has a contingent of assholes and zealots. Rails has DHH and mountains of hacker news posters, and years before Perl had an army of slashdot posters. The zealots will make the "web scale" arguments about any old poo poo, but don't assume everyone who is using a language or tool falls into that camp. I used to be incredibly cranky about node, and I do catalogue it's flaws, but, hey, some people are having fun. The arguments for and against software haven't really changed much, but the zealots have moved camp. If I were doing a one day demo of programming, i'd probably teach them Javascript. They will have it on their computer at home. Being able to use it in other contexts for hobby or toy projects in and of itself is not a real criticism of it. "HEY THOSE PROGRAMMERS OVER THERE ARE MAKING A DEVICE FOR FUN AND PLAY, GET EM".
|
|
#
?
May 14, 2014 20:50
|
|
|
i just wanted to bbe a reactionary
|
|
#
?
May 14, 2014 21:29
|
|
|
I think I found a horror when I did a line count on some of our files today (names omitted to protect the  Why yes, that is a 19,000 line source file.
|
|
#
?
May 14, 2014 22:16
|
|
|
tef posted:As with many things in life: It depends. This is an excellent post and exactly how I feel, thanks. Also, Node is great at some things and awful at other things. It's a platform with plenty of positives and negatives. It's come a long way since it started.
|
|
#
?
May 14, 2014 22:30
|
|
|
WHERE MY HAT IS AT posted:Why yes, that is a 19,000 line source file. Is that supposed to be uncommon or something?
|
|
#
?
May 15, 2014 00:06
|
|
|
Node.js is totally fine as long as you only use it ironically.
|
|
#
?
May 15, 2014 04:41
|
|
|
Strong Sauce posted:"Man I really hate those 'developers' using javascript" That is literally correct, the fact that a lot of effort has been sunk into making working with javascript suck less doesn't mean it isn't a lovely language that gets used because of path dependency. Basically javascript is a turd that has been polished to have a mirror-like sheen but it's still a polished turd.
|
|
#
?
May 15, 2014 06:30
|
|
|
One team at work has spent about 6 months writing an entire application using Flex as a front end which has produced an end result that makes a polished JavaScript turd look like a delicious fruit basket. Even at a basic level it fails as an app interface because they've somehow made it synchronous and asynchronous at the same time by adding a middle layer that communicates with data sources over SOAP but arbitrarily caches data for some things then not others which leads to random 10 second waits for some things to load. Edit: This is the same app that uses the hand coded xml parser in the web services I posted pages ago and there's no preloading of data so unsurprisingly, performance seems to be wildly erratic. Powerful Two-Hander fucked around with this message at 10:51 on May 15, 2014 |
|
#
?
May 15, 2014 10:45
|
|
|
The Insect Court posted:Basically javascript is a turd that has been polished to have a mirror-like sheen but it's still a polished turd.
|
|
#
?
May 15, 2014 11:41
|
|
|
tef posted:The arguments for and against software haven't really changed much, but the zealots have moved camp. If I were doing a one day demo of programming, i'd probably teach them Javascript. They will have it on their computer at home. Being able to use it in other contexts for hobby or toy projects in and of itself is not a real criticism of it. "HEY THOSE PROGRAMMERS OVER THERE ARE MAKING A DEVICE FOR FUN AND PLAY, GET EM". So long as I don't have to maintain, use, listen to Node.js devs claim they invented callbacks or crawl the resulting web of crap I'm cool with this.
|
|
#
?
May 15, 2014 12:25
|
|
|
WHERE MY HAT IS AT posted:Why yes, that is a 19,000 line source file. What is the best number of lines to have?
|
|
#
?
May 15, 2014 13:00
|
|
|
If I see more than a thousand lines in any file that's not a stylesheet I tend to freak out.
|
|
#
?
May 15, 2014 13:06
|
|
|
revmoo posted:If I see more than a thousand lines in any file that's not a stylesheet I tend to freak out. Yeah, at my current job, we only have two source files longer than a thousand lines. One is written by someone who isn't really a Haskell programmer, and therefore writes pretty verbose code, and the other... well, the other one should probably be split up. The median number of lines per file is 144; the average is 229.
|
|
#
?
May 15, 2014 13:29
|
|
|
The thing I don't get is those who unironically suggest writing scripting tools in Javascript / Node. Out of every interpreter that is already installed on a system we should chose not to use any of them but instead install a web framework? There's someone where I work writing a node based file watcher to communicate via growl to the OSX desktops of non-technical people.
|
|
#
?
May 15, 2014 13:37
|
|
|
You are forgetting business justification. You can have the most elegant system in the world written in finely tuned C++ but if it took six months to build and a slapped together Node version can be done in a week and do the same stuff and make the company more money, then it's the better choice.
|
|
#
?
May 15, 2014 13:40
|
|
|
revmoo posted:You are forgetting business justification. You can have the most elegant system in the world written in finely tuned C++ but if it took six months to build and a slapped together Node version can be done in a week and do the same stuff and make the company more money, then it's the better choice. Which is fine until your slapped together apps start eating all your CPU and you can't buy servers fast enough.
|
|
#
?
May 15, 2014 13:54
|
|
|
I think Hughlander is referring to the fact that you could write the same script in python or ruby or bash or whatever, which are all already included in the OS and probably better suited to the task.
|
|
#
?
May 15, 2014 13:56
|
|
|
Those are reasonable arguments but I think they miss the point. If Ruby/Python/whatever is the easiest then use THAT. My point was that sometimes whatever is easiest varies from company to company and developer to developer. Also I've seen a lot of apps get scaled out and rarely is performance the number one issue. Business cost/time is.
|
|
#
?
May 15, 2014 14:06
|
|
|
I don't understand how if Javascript/Node/NPM are bad, you suggest Python/Django/Pip and Ruby/Rails/RVM|Gems are somehow a better alternative. All of these toolchains seem to have mostly the same problems, except the JS toolchain excels in lack of maturity and doesn't have enough C bindings to be included on your lovely OS by default. Well, I do understand, it's probably because you get paid to write in it and it fits your world view for some reason.
|
|
#
?
May 15, 2014 14:49
|
|
|
Sneaking Mission posted:What is the best number of lines to have? Zero, obviously.
|
|
#
?
May 15, 2014 14:57
|
|
|
revmoo posted:Those are reasonable arguments but I think they miss the point. If Ruby/Python/whatever is the easiest then use THAT. My point was that sometimes whatever is easiest varies from company to company and developer to developer. Also I've seen a lot of apps get scaled out and rarely is performance the number one issue. Business cost/time is. I don't think downloading and installing a Javascript interpreter is ever going to be a better option for a one-off script than just using Python or Perl or some other scripting language which is installed by default on most systems. Choosing Javascript for that is literally "well I have this hammer..." syndrome.
|
|
#
?
May 15, 2014 15:02
|
|
|
Jabor posted:I don't think downloading and installing a Javascript interpreter is ever going to be a better option for a one-off script than just using Python or Perl or some other scripting language which is installed by default on most systems. Still missing the point. And if that hammer gets the company to where it needs to be in the right timeframe, then it WAS the right tool for the job. BTW I don't even like Node, I'm not defending it. I'm simply pointing out that there are often non-technical reasons to use one tool over the other, even if that tool in question might be deemed "less good" by outside observers.
|
|
#
?
May 15, 2014 16:00
|
|
|
We're going a little past "we only have web devs and need tools" when people are mocking C bindings and taking pride on their tower of abstractions. It's like that scifi short where people declare primary sources a waste of time and all research becomes secondary/tertiary analysis.
|
|
#
?
May 15, 2014 16:28
|
|
|
JawnV6 posted:"we only have web devs and need tools" This is what PHP is for, though
|
|
#
?
May 15, 2014 16:46
|
|
|
revmoo posted:Still missing the point. And if that hammer gets the company to where it needs to be in the right timeframe, then it WAS the right tool for the job.
|
|
#
?
May 15, 2014 16:59
|
|
|
Plorkyeran posted:You are claiming that any project which did not fail by definition used the right tool for the job. What then would be a tool that would have made the project finish in half the time be? The righter tool? Don't be obtuse, that's not what I said. I said any tool that gets the company "to where it needs to be in the right timeframe," which can mean any number of things to a company, is the right tool. I don't think that you can really formulate an argument against that.
|
|
#
?
May 15, 2014 17:11
|
|
|
I'm not being obtuse. That sentence is so vague and handwavey that I have no idea what the gently caress it's supposed to mean if it isn't "any tool that's good enough is the right tool".
|
|
#
?
May 15, 2014 17:28
|
|
|
Look, it's pretty simple. Any tool that is good enough is good enough.
|
|
#
?
May 15, 2014 17:31
|
|
|
Plorkyeran posted:I'm not being obtuse. That sentence is so vague and handwavey that I have no idea what the gently caress it's supposed to mean if it isn't "any tool that's good enough is the right tool". You know, I don't actually think you are, you just don't understand what I'm saying. Let's adjust your comment to reflect what I said: "any tool that's good enough is the right tool if it allows a company to accomplish what it needs in the timeframe required to be successful in the marketplace"
|
|
#
?
May 15, 2014 17:36
|
|
|
Still have no idea what the gently caress you're trying to say. Are you defining "good enough" in a way that a tool could be "good enough" despite not allowing a company to be successful in the marketplace? If not, everything you added is completely redundant, because that's all covered by "good enough".
|
|
#
?
May 15, 2014 17:42
|
|
|
All praise the free market. The free market giveth and the free market taketh away.
|
|
#
?
May 15, 2014 17:46
|
|
|
revmoo posted:You know, I don't actually think you are, you just don't understand what I'm saying. Let's adjust your comment to reflect what I said: Um... that's not correct either. Let's say that I've written some code in PHP; the site was delivered on time and did what it was meant to do in given scale. By this definition then PHP is good enough and my code is good enough. But then a million of users registered, started populating the site and suddenly my code and PHP isn't good enough any more, because the site stops down to a crawl. Now - even though the project fails atm, it doesn't mean that PHP wasn't the proper tool to do the job. It might boil down to my code. It might be that PHP shouldn't be used, as for example Python would do given task better (with better performance). Then client comes back and says to add this functionality, and this and this. Some of these things might be easy to implement, some of them might be impossible - again it might stem to my code and to how the language is used. I think the gist is - "well, instead of researching what should be the most proper thing to use here and then training people to use it (and even then - how to ascertain what is the most proper tool to use?), people went with something familiar that still produced good results". As such in my example I don't really need knowledge of PHP to write in node.js (and I wouldn't need to learn the language) if I know JS. It might just be the matter of scalability and how extendable given thing is (as I'd say this is the most obvious thing that jumps to my mind atm). Taking it to the ground of databases: I don't really need to buy Oracle DB if MySQL is good enough for me. canis minor fucked around with this message at 18:03 on May 15, 2014 |
|
#
?
May 15, 2014 18:01
|
|
|
revmoo posted:You know, I don't actually think you are, you just don't understand what I'm saying. Let's adjust your comment to reflect what I said: One can succeed despite use of the wrong tool, and fail despite use of the correct one. Your argument is vacuous.
|
|
#
?
May 15, 2014 18:14
|
|
|
|
| # ? May 31, 2024 20:41 |
|
|
Steve French posted:One can succeed despite use of the wrong tool, and fail despite use of the correct one. Your argument is vacuous. Actually I think what you just said perfectly illustrates the point I was trying to make.
|
|
#
?
May 15, 2014 18:22
|
|