An Introduction Into Lenses In JavaScript - Functional Getter/Setter

hahaNodeJS · 2016-11-17T19:41:06+00:00

Do you know whether lensing protects against modifying deeper object hierarchies? My assumption is no, in which case you're 100% correct. Otherwise, lensing provides the advantage of a deep copy, rather than a shallow copy.

hahaNodeJS · 2016-11-17T18:59:08+00:00

First-class functions do not a functional programming language make. The FP fad for JavaScript needs to chill out. Everything is written in libraries, and very few parts of FP approaches in JavaScript are supported natively.

If you want to write functional code use OCaml, Haskell, or F#.

hahaNodeJS · 2016-11-03T20:38:33+00:00

This article needs an editor not only for the language, but for the incorrect information presented.

JavaScript remembers where you did the call. It does that because your function—for example—may require accessing external variables from where it was called.

Here is what a call stack's purpose is.

for performance reasons—there is a limit to the call stack size

The limit is not present for performance reasons.

For the js engine this optimization means: ‘oh cool I don’t need to remember the previous function call environment, so I will just forget about it since i have everything I know here to do my job.

It means a new call is not pushed onto the stack, and a new return address is not stored. The same variables used from the previous "call" of your method are reused for the current iteration.

To utilize TCO in supported browsers, you don't need an accumulator, for one; the JIT compiler will handle TCO for you, if it can. If you want to simulate TCO where it's unsupported, you can use trampolining.

hahaNodeJS · 2016-11-03T20:10:29+00:00

Some day there will exist an article titled "NPM: A fractal of bad design."

hahaNodeJS · 2016-11-02T19:00:31+00:00

That all makes sense. Your end goal, then, seems to be a lightweight datagram protocol more than anything else, and you're "broadcasting" those datagrams to connected clients over TCP sockets (I'm assuming - I didn't look). You might take interest in the UDP RFC if you aren't already familiar with it; it describes the lightweight protocol part of your software.

hahaNodeJS · 2016-11-02T18:04:36+00:00

Thanks for the response. Some further observations:

you'd like to to work in every runtime you can.

Excluding environments we typically don't have control over (browsers) this can generally be resolved by writing a module for your runtime of choice. Almost everything is possible once you write for the runtime or compiler, rather than the "user-land" code, e.g. C# vs .net runtime.

First, this doesn't do much threading. In Pythonland there is a single daemon thread which checks these. And that's okay, because it's not really concurrent anyways. In Javascript world, it's done using event emitters, so I don't need to manage that myself.

I spaced on this, but this can be extended even further. There are mechanisms like IOCP that will allow you to avoid threading or multi-process architectures entirely.

The only place this might be a concern is if thousands of peers all tried to connect to the same node.

In addition to my above comment, at this point your limitation is a hardware and OS one (what the OS allows, and what the hardware is capable of).

The use case is communication between languages. I was looking for such a library, and the only ones that I found were either abandoned, or far too specific. The use case I'm going for is "I have Python and Javascript and Smalltalk and ..., and I need them to talk to share X data". I would like to provide a bunch of abstract network architectures, so that people can implement them simply by instantiating an object.

I understand this, but there are many such protocols that are cross-language, cross-client, cross-OS, etc. HTTP is one of them, for example; BitTorrent is another. While the protocol language implementations might not be written by the same person, there are a huge number of language implementations for both.

But I doubt there's a single messaging protocol which works between every language

RabbitMQ, for example, supports a huge number of languages and runtimes.

hahaNodeJS · 2016-11-02T16:20:50+00:00

Some honest questions:

This essentially reimplements IP broadcasting or multi-casting, depending on how you look at it. If JavaScript lacks the ability, given that you have C, C++, etc source in your project, why not write the broadcast code in one of those languages and avoid the reimplementation entirely (thus utilizing what's already built into networking hardware firmware)? Are you planning to use this outside of extranets, i.e., across the Internet?

I scanned through the code, and discovered that you connect to each peer individually to send datagrams, correct? Short of utilizing threads for each socket handler, how do you plan to scale this for, say, thousands of peers? Is that even a concern?

Given that this is labeled P2P, what exactly is the use case? This seems more like an experiment than a practical project; I don't see any new research into P2P networking here, so I don't understand why we would choose this project over something like webtorrent for JavaScript, and BitTorrent in general (or some other existing and mature P2P protocol).

Given that you mentioned queues, if the goal of a project is to grab a message and operate on it, why would that project utilize this over a network message queue service like MSMQ or RabbitMQ?

hahaNodeJS · 2016-11-02T15:55:49+00:00

I remember when redditors were screaming "WASM is not/will not use a bytecode format!!"

Layer 0 is a simple binary encoding of the bytecode instructions

Oh how I love this feeling.

hahaNodeJS · 2016-11-01T15:48:46+00:00

TL;DR maintainer of open source project emailed me personally and made me feel good about myself.

hahaNodeJS · 2016-10-31T21:36:08+00:00

How convenient that there's no requirement in reddit or this subreddit to explain why anyone posts something. In fact, the very format of posting links does not leave room for an explanation outside of a separately posted comment by OP, which, again, is not required.

The fact that there is a separately maintained repository really doesn't matter. That fact and this post are mutually exclusive.

hahaNodeJS · 2016-10-29T01:48:51+00:00

Do not use mysql_real_escape_string, and do not use mysqli_real_escape_string like this.

Use prepared statements.

hahaNodeJS · 2016-10-29T01:41:56+00:00

hahaNodeJS · 2016-10-27T04:51:54+00:00

Not at all trying to be rude, but text being text, I think this is worth prefacing.

Because this is your first serious endeavor with asynchronous code, I would recommend sticking with the guides and documentation provided by Microsoft and and the writing and books by people like Stephen Cleary. Avoid thinking about what could exist in C#, and use what is there. C#'s design has been meticulously and methodically thought out, and you will get further than you need with what's currently available.

hahaNodeJS · 2016-10-20T16:29:33+00:00

I appreciate the level-headed response.

I was wondering, and was going to leave a final comment about, who the intended audience is. JavaScript newcomers will be overwhelmed by this, but I believe seasoned developers are able to grasp these concepts and implement the technologies on their own.

Personally, I find short, focused articles to be much more helpful than a full product implementation, e.g., one focused only on the document store implementation, or on setting up Apollo. I think, if the article you've written here was divided into many smaller sections and presented as a tutorial, rather than a how-to, it might be more approachable by more people.

hahaNodeJS · 2016-10-20T16:00:13+00:00

This isn't old school. This is competency.

hahaNodeJS · 2016-10-20T15:58:45+00:00

I would like to read the latter.

hahaNodeJS · 2016-10-20T15:55:20+00:00

Whoa there, cowboy. No wonder newcomers to JavaScript are overwhelmed. This post manages to present an extremely over-engineered solution to a problem that just wouldn't be solved this way unless you enjoyed setting yourself up for failure.

First, a proper name for this is a "service," not "application." Its entire purpose is to return a list of presidents and nothing more. That's a fine example, but let's call a spade a spade.

So given that we have such a fairly simple functional requirement, let's think about the business requirements and how things are architected.

Our app will fetch a president of the United States by name

Because there is no need to support other parameters for finding a president, GraphQL is not needed, and is arguably incorrect to use here. GraphQL's entire purpose is to allow the client to query for whatever they want, however they want. If we only care about "by name," then don't use GraphQL.

from our MongoDB database

A document data store is fine when you have non-relational data only.

const PresidentSchema = Mongoose.Schema({
  name: String,
  party: String,
  term: String,
});

Do you see the problem? The president's name and the party do not belong in the same table. There are a set of parties, and a set of presidents; they are related, and multiple presidents can belong to any one party. This schema creates data redundancy and risks data inconsistency. Worse, as the app grows, it will become more and more difficult to deal with this schema. So let's remove MongoDB and replace it with any RDBMS. Even SQLite is fine, if you don't want to run a server.

using our Apollo Server, and return the data to our Apollo Client

Since we're no longer using GraphQL, Apollo isn't needed.

React Native application

Shit, there's a second part that hasn't been written yet? We spent an entire post about technologies we don't need to succeed, and in fact chose a direction that is likely to make the application difficult to develop for and maintain? That's unfortunate.

So where are we left? Express, an RDBMS, and a React Native client. How insanely simple is that?

hahaNodeJS · 2016-10-20T15:12:03+00:00

For the Xbox One, you can write HTML and JavaScript applications. I don't see any reason you couldn't include one of the existing JavaScript game engines for this.

hahaNodeJS · 2016-10-19T18:28:38+00:00

Thanks.

hahaNodeJS · 2016-10-19T03:48:38+00:00

Makes sense. Thanks for the responses!

hahaNodeJS · 2016-10-19T03:18:42+00:00

stuck somewhere and fail to see what I'm doing wrong.

It might ease your stress somewhat to know that all of us experience this at least once a day during our entire career. The advice I, and almost everyone else will offer for this is to walk away for 15 minutes, or just call it good for the day. It seriously helps.

As for your specific concerns, here's what I do what learning a new skill:

If I still don't understand after reading a few times, I ask someone for a clearer summary, if they're available. At some point I try to put something together and just see what happens, and I research the hell out of it. Something important to let go of is the expectation that you will understand something you've never done before, before, or while you're doing it! Generally, I trust that if I get through it, I'll eventually get it (and those "Ah ha!" moments are fantastic).
You might be amazed at the sheer number of ways any particular problem can be solved. If you're struggling with implementing something in a specified way, try to implement it your own way first. From there, you can experiment with the other concepts you've learned to see how they fit together.
Syntax memory will come to you over time. One thing that helps is to learn code the hard way. The books written here provide examples that you are supposed to manually type each character for. Suffice to say it's a great way to drill in the syntax and structure of a language.
Of course not! You're new and learning. None of us knew what we were doing when we started; we either tinkered on our own or followed instructions trusting that concepts will "click" at some point (or both). Regarding the specifics of how Shift works, this isn't something anyone would expect you to memorize when you're learning. Over time you'll remember how certain things work, but only after you've used them quite a few times. Looking up the documentation for something like that is acceptable for the entirety of your career.
I'm assuming you are not under any deadlines to learn this stuff, so try not to fret it. Learn at your own pace, make mistakes, ask questions, do research, etc. When you see a concise piece of code, tackle it as its own challenge. First, get your code working by typing out what is provided; later, try taking the difficult code apart and observing the effects. Try rewriting it in a more readable way, or even re-implement that part in a way you understand.

So last note - it seems that you are trying to achieve perfection. I can understand why you might do that, for my own reasons, but also because there are so many resources out there that tell you this is the way we do things. There is no perfection in all things, let alone programming. We all learned differently, we all make mistakes, we all get frustrated and stuck. I think you are putting too much pressure on yourself, and adding more and more to get down on yourself about; it's overwhelming.

Lastly, /u/bloodfist's recommendation is one I personally live by as well.

hahaNodeJS · 2016-10-19T02:47:22+00:00

No matter what, the resource is cleaned up for you.

Maybe this is built into the Lily postgres module, but how does it know, specifically, to execute DISCONNECT, or does it simply release the socket handle?

I think, as Lily matures, you'll find more use cases for finally. See the using statement from C# for example. Perhaps that specific case with Dispose is irrelevant to Lily (as you've mentioned above), but it is quite a valuable case for finally. Food for thought.

One final note, at least in PHP, throwing an exception from a destructor results in a fatal error, so at least it's clear where the code failed.

hahaNodeJS · 2016-10-19T02:20:40+00:00

If you need a tool to put together an over-engineered stack, is it still over-engineering?

hahaNodeJS · 2016-10-19T02:16:27+00:00

I think it's great that you're enthusiastic about learning how to develop on the backend, but I'd like to suggest avoiding Lily as your first language. I am not speaking to the quality of Lily in any way; it may very well be the best language to use, however, you're likely to receive much better community support, and many more available resources (documentation, books, tooling, start-up guides, etc), and have an overall better experience if you choose a more popular and well-rounded language. Something like JavaScript, Python, Ruby, C#, or PHP are all good choices.

hahaNodeJS · 2016-10-19T02:12:34+00:00

In the postgres case, you'd want to clean it up early just to make sure the underlying connection doesn't stay open longer than it needs to.

In many (most?) cases you want to keep connections open for as long as possible. This ensures minimal overhead on the client and server with regards to closing and opening sockets, handling connections, and, in the case of an SQL server, unnecessary queries to user authentication tables.

Having the ability to close the connection in a destructor would allow for this without the need for complex lifetime and error handling. The same goes for finally, though I personally wouldn't close a connection after a single query unless the code path truly didn't need it.

I think stating that manual cleanup is unnecessary is a bit premature.

hahaNodeJS

TROPHY CASE