Hacker News new | past | comments | ask | show | jobs | submit | tluyben2's favorites login

Scoopex has a video series of Amiga demo programming starting all the way from the basics of using an assembler: https://www.youtube.com/watch?v=p83QUZ1-P10

I would have killed for this back when I had an A500. It seemed like dark magic and all I could find was a book on ASM game programming tricks, which was too advanced for me.


I discuss this pretty deeply in my indie founder bootcamp but the main point is, if your revenue goals are something like $20k/month (and not to build a unicorn) then one of the lowest risk decisions is to try to get a very tiny percentage of a “proven” very large market.

The reason is that getting a few hundred or a few thousand customers in a proven market with millions of customers is a very achievable goal over a few years.

No need to compete on price, just compete on great customer service and support. Be someone that your customers know and like and love dealing with.

And of course you do need to make a great product and find a marketing channel(s) to reach that small segment of customers.


I don't understand why so many people glorify hand-written parsers. Maybe because they never used good parser generators (not unlike type systems and Java) ?

Personal opinion: writing parsers is the least interesting part of an interpreter/compiler, and your grammar should be boring if you want your syntax to be easy to understand by humans.

Boring, in this case, mean LL(*), LR(1), or another well known class. Just pick a damn parser generator and get the job done quickly, so you can spend time on the really difficult tasks. The grammar in this article is LR(1) and is trivial to implement in yacc-like generators, locations tracking and error messages included.

Bonus point: since your grammar stays in a well known class, it's much easier for other people to re-implement it. You can't introduce bullshit ambiguous extensions to your grammar (C typedefs, anyone ?). This article gives a good explanation of this: http://blog.reverberate.org/2013/09/ll-and-lr-in-context-why...


Exactly, this is a language that they want to run a new economy, not just payment processing, but banking, title transfer, legal resolutions, and the metric it was judged on was "looks like javascript" and not say:

* Compiler time safety (type safety, capabilities, rust and/or haskell style features).

* Built in formal verification features to ensure a function does what the developer (and reader!) thinks and no cases are missed.

* Explicit language design (so that the compiler isn't even required to do strong safety: every action must be spelled out, even if a compiler could deduce it).

* Paying attention to the fucking history of the field (and not doing things like: insane name mangling, case sensitive semantics (not even just names by convention fucking semantics are case sensitive), hard to reason about VMs). Like come on people, at least learn from 20+ year old mistakes.


Quoting:

"For more than 30 years, our design lab has seen that no IC greater than 16 pins (except memory) has worked according to its documentation"

That matches the experience of every single embedded engineer I have ever known.


You (and Ola ...) really should take a look at the APL / J / K family. All are 10-100x times more expressive than Ruby/Python, and 100x-1000x times more expressive than C and Java.

They are all quite fast, with K being super-blazing-fast.

I can't do these languages justice in a comment -- but have a look at https://github.com/kevinlawler/kona/wiki/Idioms and https://github.com/kevinlawler/kona/wiki - you are in for a shock about how unexpressive everything you've used so far is (and you don't have to give up speed to get that)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: