Live data from Hacker News

Uncomfortable Truths in Software Engineering

buttondown.email

391–400 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#391

> ...statically-typed languages are better for large projects than dynamically-typed languages... > Formal methods will never be mainstream... Say what? these two statements are written just 2 lines apart?

What’s confusing about it? In this context, “statically-typed languages” refers to things like Haskell, and “formal methods” refers to things like TLA+. The two are not at all the same, nor are they intended to be.

One would say that static types has grown out of research in formal methods, and hence, is a consequence of formal methods.

Re: Uncomfortable Truths in Software Engineering

#392

Earlier quoted context omitted.

> It's not common now! It is [1]. Over 60% of Javascript developers use it somewhere, and over 1/3rd of all developers use it for something. Almost all widely used npm modules have @types annotations as well. Outside of node, it's arguably the most ubiquitous voluntary extension of the JS ecosystem ever. [1] https://redmonk.com/jgovernor/2019/05/07/typescriptexploding...

The key of my point is "niche of a niche", which is seemingly the exact point you're making in arguing that typescript is common. Common among JS developers != common among programmers != common among professionals in the software industry

> Common among JS developers != common among programmers != common among professionals in the software industry

Not sure if you're a troll, but as I pointed out, as of 2019 over 1/3rd of all developers in the software industry were using it. It's higher now.

That's common. Find me another technology used by more developers in the software industry.

Re: Uncomfortable Truths in Software Engineering

#393
post #376
post #334

Earlier quoted context omitted.

If I'm understanding you correctly, this is basically what we have with Typescript, and it's...fine, but it's not great. The difference between what you're suggesting and what Rust does is that in Rust the unsafety is lexically scoped - it concerns static code, not live data, so it can't escape the unsafe code block. Whereas in Typescript, as soon as you let an `any` flow back into the rest of the system, all bets ar…

So, IANAPLT, and I think that must be definitely clear now if it wasn't enough so before... but then, who says I can't dream! :D and in this dream of mine, those things seem to indeed be lexically scoped, apparently... :) As to the next thing, I feel I don't understand completely the details of what you wrote in the ETA section, but wouldn't it be similar like with unsafe in Rust? AFAIU, it's on the writer of the cod…

What's IANAPLT?

I googled and got nothing.

Re: Uncomfortable Truths in Software Engineering

#394
post #388

Earlier quoted context omitted.

Clojure is strongly typed and dynamically typed, not "untyped". Much of its core behavior is built on interfaces like ISeq. It's not uncommon to use a spec library like clojure.spec or malli, whose benefits overlap those of static typing. I'm not sure if there is a measured improvement from their use, but they have either advantages like facilitating generative testing that do help one to write more correct software.

The term "untyped" means anything that isn't statically typed (or just "typed"). This is because (static) types and dynamic "types" are two very different objects, and only the former is called "types" in programming language theory and formal languages in general. I am well aware of clojure.spec, and it, as well as many other techniques employed in development, are probably among the reasons why types don't actually…

Thanks for the explanation. What are some of the other techniques?

Re: Uncomfortable Truths in Software Engineering

#395
post #393
post #376

Earlier quoted context omitted.

So, IANAPLT, and I think that must be definitely clear now if it wasn't enough so before... but then, who says I can't dream! :D and in this dream of mine, those things seem to indeed be lexically scoped, apparently... :) As to the next thing, I feel I don't understand completely the details of what you wrote in the ETA section, but wouldn't it be similar like with unsafe in Rust? AFAIU, it's on the writer of the cod…

What's IANAPLT? I googled and got nothing.

I Am Not A Programming Language Theorist (Theoretician?...)

Re: Uncomfortable Truths in Software Engineering

#396
post #177

Earlier quoted context omitted.

Are you above 35?

I'm curious to learn how that is relevant to my post and what assumptions you make about people around this topic based on age

The parent topics were talking about those older than 35 getting into the field because they loved it and those under mixed. Wondering where you fit into this worldview.

Re: Uncomfortable Truths in Software Engineering

#397

Is mobbing really better than pairing? I've never done it. Sounds awful. I got into this game to have long stretches of solitary work, that's when I'm at my best. Not entirely obviously, I still work on a team. Anyway, pairing can work well under the right circumstances, curious to hear anyone's take on whether mobbing works or not.

Mobbing can be easier for people that pairing, and can be a way to observe the skills required for good pairing before being on the hook for practicing them.

Re: Uncomfortable Truths in Software Engineering

#398

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…

Anecdotal: I find pair programming great for my productivity, and I'm generally a shy/reserved person. Making things explicit by talking them out loud makes programming way safer imho. I almost never solo program if it's a life-and-death code and I have a trusted partner who enjoys pair programming.

Re: Uncomfortable Truths in Software Engineering

#399

Well if we're just gonna bash software guys here.... The arrogance stands out for me. I have worked in many different fields and with a range of engineers (EE,ME,CE), none come close to the general aura of big ego and arrogance around software guys. It's similar to the levels seen in finance guys. Its like there has to be some relationship between compensation and true value, where ego makes up the difference. Of cou…

This is simply because it is an intellectual field that is not subject to professional norms of cognitive workers. You will likely find, if you read period pieces or biographies of similar situtations e.g. 19th century EM engineers, that they too had an inflated sense of the scope of their understanding of matters. This is likely (imo) due to the fact that mastery is gained somewhat independently and not subject to a…

> This is simply because it is an intellectual field that is not subject to professional norms of cognitive workers. You will likely find, if you read period pieces or biographies of similar situtations e.g. 19th century EM engineers, that they too had an inflated sense of the scope of their understanding of matters.

Engineering education in the 19th century was a crucible; only the best and brightest successfully graduated. The following excerpts are from a blog entry[0] on the book The Great Bridge.

In three years’ time he had also to master nearly a hundred different courses, including, among others, Analytical Geometry of Three Dimensions, … Calculus of Variations, Qualitative and Quantitative Analysis, Determinative Mineralogy, Higher Geodesy, …, Orthographic and Spherical Projections, Acoustics, Optics, Thermotics, Geology of Mining, Paleontology, Rational Mechanics of Solids and Fluids, Spherical Astronomy, … Machine Design, Hydraulic Motors, Steam Engines, Stability of Structures, Engineering and Architectural Design and Construction, and Intellectual and Ethical Philosophy.

A century later, D.B. Steinman, a noted bridgebuilder and professor of civil engineering, would write, “Under such a curriculum the average college boy of today woul be left reeling and staggering. In that earlier, era, before colleges embarked upon mass production, engineering education was a real test and training, an intensive intellectual discipline and professional equipment for a most exacting life work. Only the ablest and the most ambitious could stand the pace and survive the ordeal.

… Of the sixty-five students who started out in [Roebling’s class], only twelve finished. And among those who did not finish there had been some rather severe breakdowns, it appears, and one suicide.

[0] https://philip.greenspun.com/blog/2006/01/26/favorite-extrac...

Re: Uncomfortable Truths in Software Engineering

#400
post #285

Earlier quoted context omitted.

It is unfortunate that parent latched on to capitalism. Point number 13 from the post resonated with me the most since the software I write can damage the environment or expensive machines that are difficult to replace if there are errors, and as a professional electrical engineer I do sign off that it is built correctly and am liable, and therefore I limit the scope so I can manage the workload, document test result…

>"Imagine if you could sue software vendors for lost revenue due to bugs" It does happen when software is made under specific contract. You do pay an exorbitant price for such software though. For generic software - this is the dumbest idea I've ever heard. Go sue your politicians instead. I am pretty sure you'd find enough cases of lost revenue / income coming as the results of their actions.

Why should software be unlike other industries that are held accountable for their products? Imagine everything in your life had no warranty and click through eula type terms and changed uncontrollably to improve some metric for the manufacturer. I suppose it all comes down to when life and environment are on the line instead of just revenue, and for revenue as you say the people who can afford it pay for it and enforce it with their contracts. To me therein lies the difference between programming and software engineering.
Post reply on HN