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

41–50 of 54 posts

Re: A hierarchy of software engineering discourse

#41

Post by wolco »

frankish wrote: post #38
jshowa3 wrote: post #33

I disagree with code style as a fixation. It's much better to have a uniform style if it improves the readability of the code. I think the most important thing is to not make a fixation a 20 hour discussion.

Yeah, I think there's a neglect to address that these fixations and best practices are meant to address collaboration and maintenance in a code base. Just cranking out a solution without regard to how others will have to maintain your code does not work so well on a team IMHO.

Are we focusing on making the next teammate's job easier and not focusing on delivering a solution quicker?

Re: A hierarchy of software engineering discourse

#42

Post by g8oz »

breck wrote: post #37
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…

You might be interested in our project ( https://treenotation.org ). Gone are all syntax characters like {}[](), which turn a 1D stream of tokens into an AST. Instead you simply write your source in 2-dimensional notation. Makes it far easier to build new DSLs. (Evidence: see all the DSLs in GitHub.com/treenotation/jtree/langs)

FYI The only DSL with a readme is the poop one.

Re: A hierarchy of software engineering discourse

#43

Post by merlincorey »

jshowa3 wrote: post #33

I disagree with code style as a fixation. It's much better to have a uniform style if it improves the readability of the code. I think the most important thing is to not make a fixation a 20 hour discussion.

I was thinking similarly, but rather that the process should be front-loaded.

If you are working on a team of engineers to produce a piece of software, and large amounts of time are being spent discussing a fixation such as style guidelines and linter exceptions then I would wager there was not enough (or perhaps even any) time spent on deciding and documenting those things at the start of the project.

If you find yourself having discussions on fixations repeatedly, it's almost certainly time to take a step back, as a team, and come up with the guidelines everyone can live with, and then, most importantly, document those guidelines.

This makes future discussions on fixations really quite simple: "It's in the documented guidelines for the project so either follow that, or propose a change to the guidelines as part of your pull request".

Re: A hierarchy of software engineering discourse

#44

Post by thecupisblue »

jones1618 wrote: post #25

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.

If your structures are good, your architecture is provided out of the box.

Re: A hierarchy of software engineering discourse

#45

Post by merlincorey »

wolco wrote: post #41
frankish wrote: post #38

Earlier quoted context omitted.

Yeah, I think there's a neglect to address that these fixations and best practices are meant to address collaboration and maintenance in a code base. Just cranking out a solution without regard to how others will have to maintain your code does not work so well on a team IMHO.

Are we focusing on making the next teammate's job easier and not focusing on delivering a solution quicker?

In an ideal world, I would prefer most every bit of code was written with your fifth replacement in mind.

This means that you've taken the time to document what you've done, test what you've done, and even included any relevant design and architecture concerns for why you have done it.

Without this information, your fifth replacement is likely to have many frustrating "why did they do that this way?" reactions which sometimes will lead to rediscovery of exactly why when they try to remove or change it and are confronted with the context.

Re: A hierarchy of software engineering discourse

#46

Post by billman »

jimbokun wrote: post #20
w_t_payne wrote: post #2

Very interesting. I would have treated "requirements" differently - considering them as a mechanism to capture all levels in the hierarchy rather than a distinct level in their own right.

Disagree. Need requirements to define what you want to achieve, before there is any point in discussing models, notations, etc.

How's that going for you ;)

Re: A hierarchy of software engineering discourse

#47

Post by breck »

g8oz wrote: post #42
breck wrote: post #37

Earlier quoted context omitted.

You might be interested in our project ( https://treenotation.org ). Gone are all syntax characters like {}[](), which turn a 1D stream of tokens into an AST. Instead you simply write your source in 2-dimensional notation. Makes it far easier to build new DSLs. (Evidence: see all the DSLs in GitHub.com/treenotation/jtree/langs)

FYI The only DSL with a readme is the poop one.

Whoops! Thanks for the reminder. We can get this fixed. https://github.com/treenotation/jtree/issues/63

Re: A hierarchy of software engineering discourse

#48

Post by jrochkind1 »

TeMPOraL wrote: post #18
cle wrote: post #11

Earlier quoted context omitted.

We have a lot of progress to make here. Writing a language isn’t nearly as simple as writing a mere lexer, parser, type checker, and compiler/interpreter. You’ll spend just as much, or even more, time worrying about developer ergonomics (IDE integration, frameworks, toolchains, etc.). Projects like Language Server Protocol are great steps in the direction of making languages easier to implement, and LSP in particular…

That's intentionally making the problem three orders of magnitude more complicated than it should be, though. In Lisp world, you start your DSL with a simple defmacro, and iterate from there. Lexer, parser, type checker and compiler is already handled for you, you only need to add some code where the rules differ. For a DSL you create within your codebase, you almost never need to do extra work here.

In ruby a DSL is just ruby as well, although it perhaps ends up having to _look_ more like ruby than a Lisp DSL would. (Not sure, only vaguely familiar with lisp). But at any rate it's the same thing as far as "create within your codebase", no extra work of a lexer, parser, etc. This is a thing people do in ruby and call it a "DSL", when they are using fancy techniques to make it especially concisely expressed and well-fit for the domain (but it's still really just ruby under the hood, no parsing step but parsing ruby code with your ordinary ruby interpreter).

Which has always made me think... so HOW is this different than an API anyway, why does it have a special name? Aren't all API's "domain-specific languages" of a sort? Certainly they can be good or bad APIs, in a variety of ways, including being a good or poor fit for the domain of work they are trying to enable. But if in the end the implementation is just (ruby) calling methods on instances, or (lisp) calling macros and lambdas (or however you'd describe it in lisp if i've gotten it wrong)... isn't that what every API is, what's the difference?

Re: A hierarchy of software engineering discourse

#49

Post by jrochkind1 »

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…

> In modern times, I can think of two languages that seem to have been built to provide solutions in specific problem domains:

The obvious one to me is `R`!

Re: A hierarchy of software engineering discourse

#50

Post by closeparen »

jshowa3 wrote: post #33

I disagree with code style as a fixation. It's much better to have a uniform style if it improves the readability of the code. I think the most important thing is to not make a fixation a 20 hour discussion.

It’s really bad to fixate on code style. That’s why you have a linter and autoformatter: so that it no longer takes up any cognitive space.
Post reply on HN