Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A hierarchy of software engineering discourse

uvwx.github.io

Post reply on HN
Print view View original

21–30 of 54 posts

Re: A hierarchy of software engineering discourse

#21

Post by Kapura »

The idea of "notation" falling into this hierarchy is really fascinating to me. Typically, if starting a new project, I will select a language from those that I am already familiar with based on my comfort in the language and the performance characteristics of the problem.

The idea of the language you're using to solve the problem being one of the things you're developing is an exciting and scary thought. Exciting because you can immediately implement any ideas you have into the new language, scary because stack overflow won't save you if you paint yourself into a corner.

In modern times, I can think of two languages that seem to have been built to provide solutions in specific problem domains: Go and Jai. Go is a fantastic language in certain problem domains, and I wish I had more excuses to use it. Jai isn't available publicly yet, but the creator of the language builds games for a living, has built (and shipped) multiple successful games, and he's building the language so that games can unchain themselves from C++.

I believe the article of the linked article is correct that this should be part of more engineers' toolkits. It may feel like it's easier to just use keep using C++ (or whatever) but what feels easy now doesn't protect you from the inevitable problems of the future.

Re: A hierarchy of software engineering discourse

#22

Post by jimbokun »

I'm not sure the "Environments" he cites are good examples for most types of software development.

Mathematica, MATLAB, Lisp, Smalltalk, are all development environments where there are a lot of questions around how to best deploy the software after you have written it. Maybe in some cases you have enough control over the customer environment where you can tell them "Just install MATLAB, then run this code we are giving you."

But what if the requirements are to deliver an iOS or Android app? What if you are building a web service? Or an embedded system? Or a game for a specific console?

Continuous integration and deployment are too very important problems that need to be carefully considered when deciding on or creating an Environment.

Re: A hierarchy of software engineering discourse

#23

Post by tboyd47 »

jimbokun wrote: post #22

I'm not sure the "Environments" he cites are good examples for most types of software development. Mathematica, MATLAB, Lisp, Smalltalk, are all development environments where there are a lot of questions around how to best deploy the software after you have written it. Maybe in some cases you have enough control over the customer environment where you can tell them "Just install MATLAB, then run this code we are giv…

Yes, and "environment" issues can certainly become fixations for some people. For example, VMs. It all comes down to the reason a person holds a certain view and how broadly that view is supported in their own specific programming sub-community.

I like the author's overall point but I think it breaks down in the very narrow way they define fixations.

Re: A hierarchy of software engineering discourse

#24

Post by raiflip »

taude wrote: post #13
pooktrain wrote: post #12

Seems like the spirit of this article is "don't debate test coverage, code design, etc. and just get the job done because meeting requirements is all that matters" and that we should focus on making code shorter. No evidence is offered that shorter code is somehow better than code that adheres to "best practices" or has higher test coverage. Has anyone here fit an entire enterprise software system into half a page, t…

I think it depends on the problem set and where one works, etc. There's a lot of use cases where getting it over the wall is perfectly acceptable and what the business needs. I can cite numerous incidents where a lot of code was design, written, and then out of circulation less than a couple years later. I also know of instances where some crappy code stuck and is in use 14 years later. The hard part is knowing which…

> where some crappy code stuck and is in use 14 years later

I think this boils down to a roll of the dice. Its possible that some code is simple enough, or some engineer is smart enough, that tests are not really needed, but given the choice to not unit test would be made early, and its very hard to know the complexity of the solution at the beginning, you're really just rolling the dice with regards to whether it would work out. Sometimes you get a huge payout by delivering good code fast, but sometimes it can really blow up in your face with lots of prod errors.

Personally, I'd rather smooth out that large payout vs large explosion curve by just writing tests. If we could have pushed out the code faster, that is a loss, but if the code would have had many errors, thats a gain. So probability distribution with regards to payoffs is smoothed out.

Re: A hierarchy of software engineering discourse

#25

Post by jones1618 »

It's odd that he incidentally refers to "architecture" a couple of times but doesn't include that in the hierarchy. I'd put architecture above models because it defines not just how your models are partitioned and connected but how they communicate. Also, good architecture isn't an answer to here-and-now requirements but anticipates how an entire system might need to adapt to _future_ requirements.

Re: A hierarchy of software engineering discourse

#26

Post by iamthepieman »

jrochkind1 wrote: post #3

> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want. Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon. The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger. On the other hand, when it works, it works. I'd say Rails is an example.

The thing that makes the thing I want IS the language simply put.

More completely it's the environment, architecture, language, requirements, customer, experience and team.

I've rarely found a need for a generator that wouldn't be more simply and universally solved via a configuration pattern.

Re: A hierarchy of software engineering discourse

#27

Post by TeMPOraL »

Kapura wrote: post #21

The idea of "notation" falling into this hierarchy is really fascinating to me. Typically, if starting a new project, I will select a language from those that I am already familiar with based on my comfort in the language and the performance characteristics of the problem. The idea of the language you're using to solve the problem being one of the things you're developing is an exciting and scary thought. Exciting be…

New DSLs/notations aren't conceptually different or more difficult than different libraries with differing APIs. In fact, each time you're coding to an API of a library, you are coding to a DSL - the API is the language. Writing real DSLs via code transformators/generators (e.g. macros in Lisp) just removes the noise caused by the mismatch between the API and the language syntax, making things potentially cleaner once you understand the API.

Documentation is still crucial, whether you're dealing with a library or a DSL.

Re: A hierarchy of software engineering discourse

#28

Post by a_c »

Software engineering is the blend of software, business and people. When the business is itself purely about software, and the sole team member is yourself, then I agree with the article.

The ultimate currency in software engineering is time. Time spent on ideation, time spent on requirement gathering, time spent on designing, time spent on communicating ideas, time spent on iterating features, time spent on maintaining existing codes.

If going through the hierarchy saves you time, by all means do it.

Re: A hierarchy of software engineering discourse

#29

Post by ken »

jimbokun wrote: post #22

I'm not sure the "Environments" he cites are good examples for most types of software development. Mathematica, MATLAB, Lisp, Smalltalk, are all development environments where there are a lot of questions around how to best deploy the software after you have written it. Maybe in some cases you have enough control over the customer environment where you can tell them "Just install MATLAB, then run this code we are giv…

With Clojure, the answer is straightforward: here's a jar (or war), or some JS. It's no worse than mainstream languages like Java -- and much better, if you might also need to target JS.

Everyone likes to bash Lisp and Smalltalk for this, but what are you going to do with all your Python/Ruby/Java code if you need to deliver an iOS app? Or target an embedded system, or a game console? Every language has environments where it's difficult or (nearly) impossible to support. It's not unique to those funny languages that don't use curly braces.

Re: A hierarchy of software engineering discourse

#30

Post by ken »

"What we want is a vehicle for exploring that space -- something like an IDE for your problem domain. It's been joked that any problem in computing can be solved with another level of indirection, but I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want."

To this Lisp programmer, this sounds like plain old bottom-up design. I'm making primitives and syntax for The Thing I Want. My IDE essentially is an IDE for my problem domain.

It's a bit harder in other languages, but still more or less feasible. I think many people would be surprised by how much of my software is written in itself.

Post reply on HN