weff_

>All of these seem like very reasonable justifications to rethink the way we build software, to change what's standard practice or to invent new tools that solve old problems in a modern context. To some degree the clock on when our industry starts accumulating stable knowledge won't start ticking until these kinds of changes stop happening.

But we already have stable knowledge that's simply not considered valuable. Your list of changes over the decades is of course a change but I don't understand why the attitude is "unless things stay stable over the next 30 years, there's no point in trying".

All those SOLID, agile, TDD, DDD, micro-services memes that are being implemented so superficially and cargo-cultishly are actually grounded in a real understanding that has a context, constraints, and trade-offs. The issue is that superficial and cargo-cult application. "Software engineers" that decide they're going to do micro-services without understanding what it solves, how it solves it and what they're trading off. And a business that doesn't care or know enough to ask for better. Maybe they don't need better! Maybe it's ok to slap together and the product will be equally mediocre whether the devs use cargo-cult pattern X or not. Maybe the quality doesn't matter that much to the business. In which case the devs being hired also don't need to actually know that much software engineering. In which case maybe the idea of electrical engineer vs electrician makes sense here too.

That's a definition of engineering.

How isn't that like claiming you're a chef because you have a catering company where you serve microwaved foods, and claim it's silly to try to distinguish degrees of cooking skills.

>the discipline is all of 20-30 years old.

How do you define software engineering such that it's 20-30 years old? Why isn't it 50 years old? I ask because I've heard the argument that software engineering is a young discipline but it feels like you're really stretching it with those 20-30 years.

>When the S-curve of hardware progress flattens, software engineering will gain in importance.

But a lot of software engineering issues are entirely divorced from the underlying hardware. So I'm not sure how the shape of hardware has any significant bearing to our current situation.

>Engineering is very much about the accumulation of experience

I would argue that we actually know a ton about how to build software. It's just that it's not really being taught or valued or applied. I would argue that's an important distinction because it strengthens the analogy of electrical engineer vs electrician. So it's more about just an accumulation of experience.

That's fair, thanks for answering, cheers :)

If you will, could you speak more to

> we have people who create studies to test our efficacy and help inform future course development. We care about proving the efficacy of our approaches and constantly improving."

I'm curious how that works, what the results are. For instance, is the endpoint metric how many more students pass standardized testing? If so, how does that leak into the definition of 'mastery'?

The 'living in harsh conditions makes you a crazy good fighter" is a meme though, as this historian explains: https://acoup.blog/2020/01/17/collections-the-fremen-mirage-...

I think Go tries to reduce its dependence on libc but, by default, it will still link to it.

For instance, this code:

  package main
  import "net"
  func main(){
    net.Dial("tcp", "golang.org:80")
  }

When compiled with go build main.go does link:

  linux-vdso.so.1 (0x00007ffe3d7f0000) 
  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc7ac05a000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7abc69000)
  /lib64/ld-linux-x86-64.so.2 (0x00007fc7ac279000)   

There are of course compiler options to truly statically compile.

That's interesting. I don't think as optimized memory manipulation via convoluted casting and such as "complex stuff". I think of that as optimization.

I thought what the author meant by complex was a gigantic system that needs to use many design patterns for good reasons; the code models a very complex, convoluted domain.

So when is it appropriate to do complex things?

At the end of the day, it boils down to dependency management, wouldn't you say? That is, Python2 could be running forever if the environment is maintained. In the same vein, a messed-up OS or libs can stop a C app in its tracks.

I heard so much about the actor model, I should really try it in its intended glory one day.

Very true, I had not even thought about the multiprocessing package; it's sometimes not as convenient as multithreading but it'll get those other cores working.

Can you expand a bit on that? I'm not familiar with the issue you're describing.

Is that like the relationship between C# and PowerShell?

> the right tool for the job!

Hear, hear!

Is that a bit like Go's `go` keyword?

edit: that is, as far as I can tell, after a quick Google, it's not too different from Python's Thread object.

As I've posted above, I'm a bit confused by CPU-bound work being processed in a scripting language. If you're planning on doing intense CPU-bound work, maybe use a lower-level language? I'm not saying abandon Python: you can extend Python with C or just use IPC to transfer data between a Python front-end and a computation back-end.

as I posted above:

I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?

I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?

Ovid2 said Perl6 has a good concurrency model

lliamander replied that Elixir does too and it's worth a look

To that, 7thaccount replied that Perl6 and Elixir fill different niches.

So far, it seems Perl6 fills a niche that requires scripting and first-class concurrency. My question then is: what is this niche that requires very solid concurrency but also scripting. In other words, what does Perl6 have in terms of concurrency that Python does not (given they are both scripting languages)?

I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?