I think the problem with HN/Engineer types is they basically never see ads designed to appeal to them because they aren't a large enough audience.

1. Half a dozen companies being dishonest in exactly the same way is tough to believe. It's too much coincidence. I don't see a reason for dishonesty in that area. Technically insufficient solutions should be easy to explain as a rejection reason.

2. Having attended the interviews in question, I rarely choked on that kind of question and earned plenty of praise from interviewers with little assistance. I'm not long out of school and typically have a knack for those kinds of problems. While I can't see how strict the standards are and what the other candidates are like, I'm not seeing the negative feedback that indicates improvement needed.

Approaching the six month mark, I feel down about my prospects. I have found plenty of interviews, but the only offers come from big contractors like I am trying to escape.

I recently got several onsite interviews[0] with startups in the Bay Area and elsewhere. Frustratingly, even when companies thought I was technically excellent and a good cultural fit, they rejected in favor of candidates with closer matching professional experience.

How can I find work in a new industry?

[0] Triplebyte referral link: https://triplebyte.com/iv/K1tBqiw/cp/out_a. The overall experience was amazing even if it didn't work out, and I would appreciate the referral money if anyone is looking.

Comments URL: https://news.ycombinator.com/item?id=20407122

Points: 6

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=19566559

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=19551322

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=19549607

Points: 5

# Comments: 0

Lots of niche languages have the same problem, notably lisp, but it doesn't do to say they aren't popular for those reasons. It's circular reasoning. Languages get those things by being popular. They get popular by having those things.

Every current "popular" language with good libraries and a large userbase started with no popularity, no libraries, and no users. They built these things over time.

The problem is these languages can't create a robust community. They are powerful, so people don't need large teams to do what they want. They are different, so it is a bigger investment to understand them. The combination means they attract the kind of elitists who are not willing to help newcomers or write basic libraries, the kind of people who are perfectly capable of reinventing every wheel and doing it better than last time.

No one teaches these languages. How popular could they get if companies and universities spent millions of hours collectively drilling even the most marginal programmer on how to use them like they do for C++ and Java?

They would never do it though. Large companies don't want more powerful languages. They will take the productivity loss for fungible employees. It's part ego. Middle managers look much more important if they have 20 programmers write 1,000,000 lines of code over 5 years than two programmers write 10,000 over six months even if functionality is equivalent. It's part bargaining and risk. If you only have a few programmers, the individual programmer is worth a lot more. It is also riskier to employ one because she could leave or get hit by a bus at any time.

I could write versions that worked on 32-bit, but I don't have a 32-bit machine to test on.

What Forth is best at is boostrapping from bare metal to a reasonably high level language with the simplest design possible. Forth was first written at a time when there was a staggering amount of hardware in existence, so reimplementing the base language as quickly as possible was a huge plus. It's got a low floor but a high ceiling. It is a free-wheeling language that allows both very clever and very stupid things.

Unfortunately, this legacy means lots of fragmentation. There is not one cohesive community or set of standard libraries. Forth is very much a "do it yourself" language.

Forth can be very concise because all parameters are passed implicitly on the data stack by default. Parameters and arguments lead to a lot of duplication of expression in traditional languages because you need to give them explicit names both inside and outside the function.

If you prefer, it helps to treat it as a functional language where all functions take a stack and return a stack. All programs are a space separated list of function names. Of course, nothing stops you from using all the global variables you want.

There is nothing stopping Forsh from being used that way. The convenience words from the README use a global variable to tell them where to build commands and overwrite the memory for every new command because the common case is that you as a user don't really care much about having arbitrary history (In any case, gforth already uses readline, so I get history for free). The words underneath all take that location as an argument on the stack. You could write some words that allocate space for each new command without changing the underlying libraries.

The key to thinking about pipe words in Forsh is that they execute a given command and consume and/or leave a file pointer to a command's stdout on the stack. This is why there are multiple pipe words. They have different stack effects.

`>|` (begin pipeline) only leaves a file pointer. `|` (continue pipeline) consumes and leaves a file pointer. `|>` (end pipeline) only consumes a file pointer.

This allows the pipe words to interoperate with any file I/O words in gforth.

If you want to "save a command to a variable", you just use a regular Forth word. [bracket] words make things work in compile mode.

`: hack [c] echo [p] hack! $ ;`

Executing hack will then build and execute the command. This also works with arbitrary pipeline fragments.

I did my best with syntax, but existing shells have already aggressively minimized typing for short commands. The most I could do was have people type `l ` instead of `--` for long options and `s ` instead of `-` for short options. However, I find quoting much improved over existing shells. You specify the quote character when you type the command, so there is no escaping. You just pick a character that doesn't exist in the string. You are ok as long as your string does not included every printable ASCII character.

Comments URL: https://news.ycombinator.com/item?id=15709671

Points: 76

# Comments: 20