> ...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.
Uncomfortable Truths in Software Engineering
391–400 of 400 posts
Re: Uncomfortable Truths in Software Engineering
#392Earlier 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
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
#393Earlier 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…
I googled and got nothing.
Re: Uncomfortable Truths in Software Engineering
#394Earlier 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…
Re: Uncomfortable Truths in Software Engineering
#395Earlier 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.
Re: Uncomfortable Truths in Software Engineering
#396Earlier 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
Re: Uncomfortable Truths in Software Engineering
#397Is 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.
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…
Re: Uncomfortable Truths in Software Engineering
#399Well 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…
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
#400Earlier 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.