tlack

Good points. Some rebuttals:

First, in the context of this argument, I'm talking about work in high level languages like Python, JS, fairly expressive C++, etc. If we were coding in assembler -- LEA, LDR, JNZ.. -- I'd definitely want a ton of low level comments!

When I say wasting space, it's not about disk space, or shrinking your screen size, or even formatting. It's more about what you can see all at once.

Think back to a recent time when you had a tough to fix bug. Like something really not trivial that you beat yourself up about for a while.

I bet it involved you working through various levels of libraries, opening them side by side or paging back and forth, trying to figure out what went wrong in the logic.

It probably wasn't cuz you misunderstood what a variable did. We have great ways to document that, like the function header.

Now imagine that process if it's all on the same screen. If everything feels "tangible" to you, because each level of logic (to some reasonable point) is visible, accessible.

When I encounter a code base with hundreds of source files in various folders and some flimsy abstraction tying it all together, such that I can't see a clear delineation between parts, I go nuts!

Here's a very practical example. Imagine you have some library that wraps a remote API. Something important, like Payments. The hard part there is understanding failures (does it retry?), edge cases (whats diff when i run a test CC#?), stored state (can I resume this from a different part of the code?).. those things are mighty hard to glean even from good statement-level comments, even if I could take the time to read all 3,000 lines of code.

We need higher level great docs.

I'd love to code in English or something like it, but looking at the code on my screen right now, those would be some really complex sentence structures. :)

Strongly disagree but upvoted for the conviction of your delivery. :)

Writing robust programs relies on unquestionable understanding of the logic. The specific variable and argument names are neither here nor there.

It's almost impossible to understand program flow when code is extremely verbose and heavily abstracted. Little comments like "add 1 to x!!" are not only useless in practice but they are toxic to code understanding.

The code already tells you what it does. As a maintainer, I need to understand why, and to what ultimate purpose. "tmp2 -> temporaryFailedCustomerRecordsCounter" wastes precious space making the obvious infantalizing.

It's ok to expect people working on your complex, important software to be knowledgeable about the domain and its' standard terminology. I expect my Lyft driver to have a drivers license.

Given the physical access, could the device be taken over to discover the specific identity of the surveillors? IP addresses, malware implants..

Vector language users are passionate about their power and heartbroken that so few have had the transformative opportunity to really get to learn them.

It's more about expressiveness and the ability to stay at a "high level" than actually the ability to just do some computation that is really hard elsewhere.

After all, most programming languages can do "the same stuff" - but no one would compare Haskell to PHP.

In most of the examples in the article, the author is using just one or two verbs put together. Imagine if all of the verbs in your language worked seamlessly at the "concept" level, rather than the "write the loop" level.

Even functional constructs like map/filter/reduce take up a lot of words. One or two characters can do the same thing, and be read faster and more idiomatically by an astute practitioner.

That's my take on it (as an on and off Q/Kdb user, not a J dude -- yet..)

ESP32 is very good if you can work around 3.3v. The M5Stack [0] is particularly nice and modular.

C, Lua, and some Python works well. Supports WiFi including split AP and node mode. BLE on chip as well. Get cheap LoRa chip for mesh net.

[0] https://m5stack.com/

Well as I recall there were a few reasons that people focused on reliability in hardware in the late 90s:

1. Shared state storage systems that supported replication were rare (I think Oracle and Informix maybe?)

2. Virtualization software was in its infancy (did SunOS have something before Solaris?)

3. RAM and hardware were waaaaay more expensive, meaning you often had to buy more pure metal just to answer questions fast enough

At least that's my take on it based on my dim faded memories

Got it here as well (in Miami, FL)

Does anyone have similar data for missed commercial lease or mortgage payments?

Because of the age old warning about premature optimization, a lot of software that runs critical parts of the internet infrastructure is dreadfully slow. You could pick something that is deployed on millions of servers, speed it up 20%, and the win would be significant.

An example is the progress bar used in `npm` during install operations. Someone discovered that it was extremely wasteful of resources. https://news.ycombinator.com/item?id=10974929

Little things like that add up. You could do even more by focusing on optimizing overall resource usage rather than just wall clock time. Perhaps even write software to automatically optimize others' software.

You want to find a community that is open to change and optimization, though - some maintainers are too busy or are afraid of change.

Pretty exciting stuff! The Github repo is here: https://github.com/google-research/google-research/tree/mast...

Don't forget mine! https://glorp.co

Definitely an odd exterior aesthetic but it's a lot more rational on the inside: https://www.architecturaldigest.com/gallery/jim-jennings-sli...

I think a savvy manager would look at your soup-to-nuts experience as a good thing, perhaps in a product lead or management role, if the tech resume isn't up to snuff.

Sounds like you've built something amazing - just keep going!

I've had to do this a few times and I'm not sure there's ever a single "best way to do it"

1) The webserver can be configured to respond for any domain. Then your application software can look at the HTTP host header to decide which client you are working with.

2) I've used DJBDNS in the past because it's very easy to generate the necessary config files and if I recall didn't require restart (since the config is stored in a "database file" - binary flat file in this case). You could also try dynamically rewriting the BIND config and restarting it via a cronjob every 10 minutes.

3) No clue here but it should be easy to automate

The worst part of all this is having to write the DNS docs for users so they can point their domain correctly. DNS is incredibly confusing to setup for "mere mortals" due to the many different registrars with varying DNS editing capabilities. Caching and IP address perplexity makes it worse.

Not to mention building a service network. People are going to expect a lot of regional white glove shops for a $100k truck and it's not easy to find enough qualified EV techs.

One option for fast math in a BEAM setting might be to use a NIF based vector library like Matrex[0]

[0] https://github.com/versilov/matrex

The patches are sent as pure data and a small client-side Javascript library (morph-dom) patches the DOM accordingly, so the template itself doesn't get sent.

I've been doing some experiments with WebRTC applications -- like many others on HN, it seems -- and came across this excellent research about the scalability of popular open source WebRTC servers.

I’ve used Paperspace.com a bit. It’s cheap if you don’t leave it online all night :)

Be sure to use their “ML in a box” image for least hassle

Here's the github repo for this interesting work: https://github.com/starstorms9/shape

(I couldn't find it in the linked article, might have missed it)

In most cases I've seen, the model lives on its own, with only very surface-level connections with your system. It can't "look up" stuff it needs, such as the query you mention.

There are graph-based systems but I think they're more interested in understanding relationships in the graph itself - grouping like things together, predicting relationships and distances, etc., rather than attributes of the nodes.

I assume you want the system to learn something like "if parent A is type O, and grandparent of parent B is B+, child is more likely to be tall" or similar. I don't think the network can learn things like that in terms of understanding the linkages to predict numbers. It might be able to predict it simply by being given enough examples after "flattening," though, so the functional result is similar.

I've found Reddit's MLQuestions [0] group to be interesting and sometimes accessible for a non-academic ML enthusiast. Some Youtube content can be useful too, but most are just repeating the content of papers. I'm still seeking a real commoner-level message board to discuss this kind of stuff without dumbshaming.

What I've learned most from is downloading example code and actually using it, reading parts of it, and trying to apply it. It's easy to dip your toes into stuff on Google Colab notebooks.

Uber Ludwig [2] is an interesting all-in-one low-code system that lets you try out different ideas quickly. At least in theory. They give an example cases for all the different types of networks they support along with matching YAML to specify the model details. So you can sorta just throw some data in there and build a command line to try ideas, rather than learning a lot about Pytorch, Keras, etc., and potentially introducing subtle bugs.

Email me (addr in profile) if you want to chat more.

[1] http://reddit.com/r/mlquestions/ [2] https://uber.github.io/ludwig/

1. You can predict multiple values, but it still has to be trained on target values for those features. So, you could predict "D", "P", and "Z", but not any at random - you'd have to design it that way. Look into "multidimensional regression"

2. That seems logical -- supplying a "confidence level" with the training data itself -- but I haven't heard of it, and can't seem to find anything on the search engines.

I'm still learning too, so take the following hand wavey reply with a grain of salt..

What can ML offer?

ML allows you to more easily make predictions from data you already have. An example is taking search terms and grouping them into their subject matter, or taking images and identifying things inside them visually. If you deal in sales, you could predict future sales based on other factors that you believe are correlated (weather? clicks?). If you deal with customers, you could more quickly identify what type of issues people are having (hardware issues? card failures?), or proactively suggest solutions.

Better than programming:

It works better when, to code a new feature, you'd need an abundance IF statements whose logic you'd have to work out by hand. In a very broad way, the machine is figuring out how to approach your task just with lots of examples and scary math. You can get a lot of different "answers" without having to write that much more code, just by trying different data and structures.

Practically it's easier than programming to keep updated as well, because if you can find example inputs that it guessed wrong, you can get automatic improvements to results by retraining with correct predictions.

But of course, the ML system itself is very complex, and it involves a lot of resources to design it, curate input data, and train on costly GPUs. This combination of the system's design, and the learned state of the systems innards, is called "the model".

Input data:

There are many different ML systems designed to use different kinds of input. Some use pure text, image data, audio data, graphs of interconnected thingies. The easiest is when the data is very uniform in structure, grouped into labeled columns (called "features"), with each column having a meaningful value. To train the system, you must also supply a "target" feature for each record, which are examples of what you'd like the system to predict. Anything that fits naturally in an Excel sheet might be a starting point. Generally, you want quite a few examples, but the exact amount of data you'd need varies with how difficult your task is.

Bad input, bad results:

Varies. From the practical side - ML systems usually produce confidence scores which you can use to avoid embarrassment. You can then manually label those confusing examples and feed them back in for training. In terms of the model itself - there are many ways of interpreting and evaluating accuracy, and the system can give you examples that confuse it.

Results, two common examples:

Some systems produce a number as their output - called regression. (Picture a sales prediction.)

Others group things into a set of pre-defined categories - called classification. (Picture a system that can tell if there's a giraffe in an image.)

What those outputs mean, and how they are to be used, is part of the design of the model.

What about documentation? Often times its easier to improve the docs than to improve the code. And let's face it - most open source projects have awful documentation!

If you don't want to interact with open source project maintainers, you could try writing example programs, tutorials, or guides for products you like - that's another form of contribution.

Python is definitely on an undeniable upswing, but you might find your mind more tingly taking a look at Elixir [0] with Phoenix-LiveView [1].

Here's a video that introduces the framework (April 2019): https://www.youtube.com/watch?v=8xJzHq8ru0M

It's based on Erlang which has always felt a little rough around the edges, but rock solid and very fast. With Erlang, service boundaries become a thing of the past and tangible state makes debugging a breeze. It's still on the upswing after 20 years in industry.

Elixir greatly improves Erlang's tooling and creature comforts and adds syntax that many find more enjoyable.

As a guy with web dev PTSD, I've been testing Phoenix and Live-View a bit lately and it really hits a sweet spot between Node's speed and evented nature and the simpler end of React's interactivity.

And jobs seem to be appearing too.

Plus Elixir is surprisingly simple to setup[2] so you won't be spending all night fighting Python module dep issues. :)

[0] http://elixir-lang.org/

[1] https://github.com/phoenixframework/phoenix_live_view

[2] https://elixir-lang.org/install.html

Another option in this very interesting space is GNES[1], which attempts to do the encoding/decoding on its own, rather than just working with feature/embedding vectors.

[1] https://gnes.ai/

For the record, I'm more open to this style now so I'd like permission to take a few steps back from that statement in 2009 (and probably most of my others that year!).

Coding in a terse style really does have some benefits. You can understand more program flow at one time and you can easily see larger patterns.

Another recent discussion https://news.ycombinator.com/item?id=21890259

From what I understand there are two networks in a GAN like this one.

One (the discriminator) is trained with a bunch of images showing what beetles can look like. It detects a real or fake image of a beetle.

The other (the generator) is just generating images with a convolutional neural network. The generator optimizes itself based on how close it is to passing the discriminators test - that is its "loss function".

So over time, the generator gets better and better at making things that look like beetles. The process takes a very long time and is aided by many GPUs (as mentioned in the article)

It's really easy. In the chat context menu, go to Export Chat History. You can then pick what kind of media to export (aside from just the messages themselves). It produces semantically tagged HTML (mostly divs with .date, .from_name, .text, etc, wrapped in a basic head/body tag) in a folder of your choosing which you can then parse with Cheerio, BeautifulSoup, etc.