Exactly. Good ads are a service to me that inform me of things I want to buy. They aren't tricking me into buying stuff. Sometimes I see an ad and immediately believe the product would improve my life and it does.
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.
I have thought of that possibility, but find two things strange about it.
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.
> Finding qualified programmers and having access to libraries so you don't reinvent the wheel.
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.
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.
Hello, everyone. I would have responded sooner but I spend most of my workday in a closed network for security reasons (defense contractor), and don't have much internet access over the course of the day.
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.
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.