jwhite

For anyone interested in the "critical" aspect mentioned by h0l0cube, please consider also reading "Farmers or Hunter-Gatherers? The Dark Emu Debate" by Peter Sutton and Keryn Walshe.

Peter Sutton is an anthropologist and linguist (>50 years); Keryn Walshe is an archaeologist (>35 years). Peter Sutton in particular has spent large amounts of time living with indigenous people in the far north. Their book describes many deficiencies in Dark Emu, and also gives a huge amount of interesting information about how aboriginal people lived, and the way they curated the land and the food resources available to them.

https://www.amazon.com/Farmers-Hunter-gatherers-Dark-Emu-Deb...

Maybe watch the video. Artists have to eat, and they relied on patronage and commissions. The church and the nobles were the only ones with the free cash and the motivation to fund artists and their creations for much of the Christian age in Europe, regardless of their looks.

But also: something changed in the 16th century: do you contend that the monarchs suddenly got uglier to the point that artists didn't want to paint them anymore?

Postponed to 1944, in 1943 it would have failed.

Reading your comment made me feel like someone had been spying on me in my car. I go through this same thing in my Lexus every time I drive it as well. It is such a relief to know I am not the only one.

I think SK's numbers are becoming more reliable by the day though. The new case rate has stabilised to a small number in the range of 50 to 150 per day and the active case count is dropping at a rate of over 200 per day. The daily death rate has been below 10 the whole time I believe. If that trend continues then SK's CFR will be well known soon and I would guess not dissimilar to current estimates. Though it's always possible a false sense of security will set in and people will relax their habits and send it higher again.

Compare to Germany: weeks behind SK but already more than three times as many cases, new case rate in the last few days of 2500-4500 (SK's max: 851), daily deaths in the last few days 10-29 and heading north. Actually the death rate must reflect an amazing health care system given 30k cases, but it's early days for Germany. Their pipeline is very full, agreed I wouldn't want to make a prediction there.

EDIT: sensitivity.

s/Nullabor/Nullarbor/ (no trees).

The Nullarbor is a vast, arid, unpopulated plain over 1000km wide. I think the comment was meant to suggest that infrastructure projects like this are challenging in Australia, because the distances involved make them expensive, but the low population density makes them much less profitable than in places like the US and Europe with high population densities.

Many tourists from other parts of the world come to Australia thinking they can "just drive" from Melbourne to Cairns or Perth to Adelaide, not realizing how much of an undertaking that is because they don't have a good sense of the distances involved.

I don't disagree with the general realpolitik you describe, but it's not clear that damaging Huawei isn't damaging the USA as well. American companies supply Huawei, and their business is being harmed; and American consumers buy Huawei equipment -- if Huawei is excluded from the US market then presumably that may have an inflationary impact on substitutes, so American consumers will be paying more for certain goods.

Wouldn't this also have been considered as part of the decision to ban Huawei? And yet the administration proceeded anyway.

I agree.

Something that might be worth noting: two minutes of googling didn't turn up the author's age, but I recall seeing this photo on his website when I bought it some time after it was published in 2008: https://hcsw.org/contact.php

Here's a more up-to-date photo: https://hoytech.com/about

It's possible he was quite young when it was published. If that's the case, then I think the book is all the more a towering achievement. It's abrasive, and it smells a bit of 2000s forum fanboy discussions, but mature people should be able to read past the more opinionated parts and find the gems in the technical treatment.

On your first point: I seem to remember plenty of companies that failed that were not telecom. In fact when I went looking just now I found a bunch of listicles about retail startups that failed.

The telecom bubble and crash was almost a side-effect. The telco executives saw the web taking off and used it to justify wildly over-inflated projections of traffic demand growth, and then began building out debt-financed networks to meet it. When the traffic didn't materialize (partly because the dotcom bubble burst), they had a bunch of overcapacity not generating revenue to service the debt that financed it, and that killed them.

I was so hoping the guy's name would turn out to be Richard.

Most residential customers don't have static IP addresses -- how does that work when a customer's IPv4 address changes?

That's more a matter of experience and attitude -- even simple things like reference types are nice. Also, templates offer a lot of abstraction power that can be used to model the hardware nicely, without sacrificing efficiency.

Many embedded programmers come from a background that doesn't expose them to those sorts of ideas though.

Nothing. I've worked on Cortex-M4 projects in C++. It's nice in many ways. The people working on the project had a much more diverse background than the typical EE who learned C as an undergrad mentioned in another thread.

"Real engineering" also runs on a different (slower) cadence, in part due to the longer timescale between inception and realisation of ideas, and due to the costs involved in making physical things.

Sorry this comment is so late; ATS is also interesting because it has linear types that allow compile-time resource tracking similar to Rust's ownership and lifetime tracking. If you use linear types you can opt out of the garbage collector. That makes it very attractive for systems programming, and in particular embedded systems. I believe there is a demo of ATS running on an Arduino of some sort.

I haven't had the time to learn it yet, though I would like to.

Well, SBCL does not ship with an interpreter, for example. Expressions entered at the REPL get compiled directly to machine code, so there's no difference in performance for a function entered at the REPL (or via SLIME C-c C-c) and one built as part of a batch compile.

Contrast that to Haskell's ghci interpreter, which is slower (last time I checked) than the same code built on the command line with ghc, the compiler. But I would still consider Haskell a compiled language, not an interpreted one, since you never run code in production under ghci, you always ship your binaries.

I suppose it's about perception. To me "interpreter" refers to a language implementation strategy. It's fuzzy, I know, since there is some continuum between interpreting an AST directly, compiling the AST to bytecode and running the bytecode on a VM, JIT compiling the bytecode to machine code on the fly, and compiling offline direct to machine code (like C/Go/Rust). To some ears, "interpreted" can sound synonymous with "slow", which is I guess what prompted my comment.

Finally, to me the place where you can enter expressions to try out your program interactively is the REPL, not the interpreter.

Anyway, thanks for explaining your position to me. (Also, good to know Python dev environments have improved, but I guess it's to be expected, 10 years is a long time :-) .)

Interpreted language? Common Lisp is typically compiled. Besides which, why is interpreted a particular advantage? e.g. Python was interpreted 10 years ago when I was using it, but Common Lisp felt far more flexible and powerful, because you can compile single functions with a key press in SLIME and seamlessly load them into your running (compiled) image... shortest feedback loop I've ever experienced. Maybe Python has caught up in the mean time, I haven't used it seriously for a long time though, so I don't know.

A little cheesy, but whenever I hear about this sort of thing I always think of this scene from Saving Private Ryan:

https://www.youtube.com/watch?v=dKbdE5LOGNQ

Yes, I've noticed that about myself too. Reading is a high investment / high reward activity, and you have to make an effort to do it. One approach is to set aside a time slot daily where you just read, like the hour before bed time for example. You could also set goals for your self (e.g. read a book a week, a chapter a night, etc.) but that might turn it into a chore and make it less likely that you'll stick with it. It depends on your personality I suppose.

I've also noticed that reading in the office attracts strange looks sometimes. I don't know what to do about that. Reading research papers and text books related to what one is working on should be encouraged in a knowledge profession, yet I almost never see colleagues doing it. I guess if your hands aren't on the keyboard those JIRA tickets won't get closed.

Ha! I should have been more precise in my language. I was avoiding learning how to write more substantial shell scripts and programs, not the command line per se.

I also got my start on pre-GUI computers (a VIC-20, specifically).

Thank you. Looks like you've packed a lot of good stuff in there already.

I only skimmed so far, but this quote stuck out:

"Programming is fundamentally a way to save human labor, and that includes our own labor."

I'm continually amazed at how many software engineers seem to miss this point.

Thanks for those links, I think I will enjoy them. I was actually thinking about Forth as well when I was writing those comments about functional programming. I'll be interested to read your take on it.

Every language has its warts, but C is a pretty small language when it comes down to it. Compare that to just the number of different ways you can expand a parameter in bash:

https://www.gnu.org/software/bash/manual/html_node/Shell-Par...

That's the sort of thing that turned me off. I still tend to avoid those nooks and crannies, although they are sometimes useful. I'm not an expert.

I'm not sure about Unix shells being inspired by C semantics. I actually started out on csh or tcsh, I forget which, two decades ago. I'm not sure that making a shell language "C-like" is a useful goal, and those two shells both fell out of favour because they have many flaws. I switched to bash quite quickly.

Here are a couple of thoughts:

- I used to spend a lot of time stuffing things into variables and then trying to operate on those, which is how you do things in imperative languages. Shell is better thought of in dataflow terms, i.e. pipelines. So I started using pipelines more and more.

- The corollary is that you start thinking more about data (passing between pipeline stages) and less about control flow.

- Compare an if statement in C, for example, to an if statement in a functional language. In C an if statement has no value per se, but in functional languages if "statements" are actually expressions that have a value:

f :: A -> String f x = if isFoo x then "foo" else "other"

In shell an if statement is just another command, so you can do things with its "value", i.e. its stdout:

    if do_test
    then
        cat file1.txt
    else
        cat file2.txt
    fi | grep pattern

Also if you think carefully, that last pipe to "grep pattern" has the flavour of partial evaluation in functional programming.

- I tend to think more in terms of building up an execution environment these days, in the same way that lexical scope works in regular programming languages. In shell, of course, that means command invocations, sub-shells, etc., because the shell doesn't really have good lexical scoping. The simplest example I can think of is executing some commands in another working directory with a sub-shell:

    (
        cd $dir
        run_test > "${f}.log"
    )

Those are just some examples.

EDIT: Also, have a read of the links in chubot's post: https://news.ycombinator.com/item?id=14012453 . That's the sort of mentality that will change your approach to shell programming.

Yes, totally agree. But it offers something different to say Python, as the video points out. Some things are more compact in shell than in Python, because it's not the same sort of programming language as Python. And I reach for Python as well, when it's the right tool.

I appreciate your point, but I think the choice to write all or parts of an application in shell depends a lot on what you need to achieve. Writing 100 lines of shell to glue parts of your application together may be the best way to ship something today, even if you plan to replace that with another language in 3 or 6 months time.

Would you care to give a link to your guide? I'd be interested to read it.

I spent many years avoiding shell, in large part because all the arbitrary-looking syntax and features (like quoting rules) the speaker highlights make it frustrating and difficult to master, and I felt like it was a treacherous enemy to be overcome through desperate struggle, rather than a tool and ally to rely on. I know some people thrive on mastering complex and intricate rules, but that's not my forte. I do better with overarching principles and a unified set of orthogonal constructs, such as C (ok, debatable, but compare to C++), Lisp, Python or Haskell.

It took a lot of pushing from a mentor for me to finally click with the overarching principles of shell and see how to master it and become productive with it. He really forced me into it as well, I wasn't a willing pupil for quite some time, but he kept persisting and finally I started listening to him. I'm so glad I did. I've never read any book or tutorial or guide that teaches what he taught me either, despite searching several times. Also, I don't think I could have learned to master shell if I hadn't learned functional programming first. The day I realised how amenable shell is to higher-order thinking was a real epiphany.

These days shell is a really important tool in my toolkit, and I can see just how much some of my colleagues are held back by not knowing it.

Anyway, I really enjoyed the video, it was a nice exposition.

Agreed!

Just being a SoC has another advantage: reduced part count, so you can fit more functionality onto a smaller PCBA.

Another commenter mentioned the Cyclone V and Zynq SoCs. My day job is in the telco industry. The equipment vendors we sell to are always pushing for higher and higher densities in their chassis and line cards, and it drives a lot of our design decisions. Chips like the Cyclone V and Zynq help a lot in achieving those aims. Our PCBAs have shrunk dramatically (with increasing functionality) over the last decade.

The continual pressure to reduce costs and power consumption also leads to choices like minimizing the other available system resources (e.g. clocks, memory bandwidth, RAM, flash), which can end up reducing the effectiveness of a GPU.

As with everything in engineering, there are many different problem domains, each with unique constraints dictating different solutions.

I'm not sure failing FizzBuzz means you lied on your CV. I suspect that many programmers go straight into an environment where they never have to think about algorithmic problems (even algorithms as simple as FizzBuzz), because others have already developed the platform and all the low-level fiddly bits (like containers, string types and functions, etc.), and they just spend their days plugging them together (query this API, update this database table, call this method on the view class).

I have interviewed candidates like this (not web, embedded systems) who talked a lot about the in-house frameworks of their previous employers, and could sketch how they would solve a problem in that environment in hand-waving terms, but couldn't implement strlen() (which would be much closer to the kind of coding they would have to do in our environment).

I work in embedded systems. We mainly write C. We ask candidates to implement strlen() in the phone screen. A surprising number are not able to. It's a very low bar, but still a useful filter.