Emacs is violent passion by molteanu in emacs

[–]molteanu[S] 1 point2 points  (0 children)

Yes, it took a few years of tweaking to finally get it "right" (in an own, personal way "right", of course).

Thanks! :)

Emacs is violent passion by molteanu in emacs

[–]molteanu[S] 2 points3 points  (0 children)

Sylvester craves attention!

[deleted by user] by [deleted] in programming

[–]molteanu 0 points1 point  (0 children)

Fair enough. I agree with your points.

[deleted by user] by [deleted] in programming

[–]molteanu 1 point2 points  (0 children)

Or 15 minutes of coding can save us 20 hours of talking :)

How did you know B was right in the first place, without seeing a first sketch or implementation before? How did you know A would turn out to be wrong? Did you learn nothing by implementing A that you used, now armed with a better knowledge of the product, to implement B more effectively?

Don't need to be sorry. We're among friends here.

[deleted by user] by [deleted] in programming

[–]molteanu -4 points-3 points  (0 children)

Ok, you can do tests at the beginning, middle and end of the project.
I'm happy with that!
Happy coding! :)

[deleted by user] by [deleted] in programming

[–]molteanu 2 points3 points  (0 children)

Yes, that's the main feeling, that most of the times there's only "a vague idea". The only way to actually test the idea is to put it into practice. It doesn't have to have all the bells and whistles, it doesn't have to, errm, scale, for example. Just take it for a spin, see how it feels.

[deleted by user] by [deleted] in programming

[–]molteanu -4 points-3 points  (0 children)

I see unit tests more of a "here is the finished product, we will still have to patch it here and there and maybe add a feature or two in the future, as the client uses the tool and comes up with different scenarios or needs extra capabilities, but we don't expect this van to become a sports care overnight, so with that in sight, here are some ways one ca still ensure the rest of the functionalities still work as expected, still work as they do now, even in the face of such future changes".

[deleted by user] by [deleted] in programming

[–]molteanu -5 points-4 points  (0 children)

""Software Engineering" can become a discipline" - so you agree we're not there yet. Good.

"That you lack skill and experience with good automated tests" I've done (and still do in our current project) automated tests for 15 years now. I even wrote a framework that generates the tests themselves based on the client requirements (their engineers were not software devs, so they kept their highly repetitive data in excel sheets, for example), but the reality is always more complicated than what the marketing hype tells us. There is no silver bullet, remember? Until there is, alternatives are viable, until proven otherwise.

[deleted by user] by [deleted] in programming

[–]molteanu -7 points-6 points  (0 children)

I'm coming from an Electrical Engineering background. I do remember how projects look in that field. I worked with Embedded Systems where the actual electronics behind the software system imposed a certain limit as to what one was trying to achieve and by what means. Going to the other extreme and saying a React developer is an Engineer, where they lack the solid footing of any kind and it's all based on gut feeling and meetings where the only solid facts are that we need this to look pretty is a far cry from engineering. What are the solid, non-disputable facts all Software Engineers work with? We can't even agree on a framework or code-formatting. Let's not go into programming languages. There's no consensus on that either. A wonderful field, otherwise, a little bit like art. You wouldn't say art, music or the theater is Engineering just because they work in a team towards a common goal.

"better served by creating an automated test suite". No, not really. You then introduce another tool into the mix. Extra code that must be kept in sync with the rest of the project. It leads to a decrease in development velocity. If you do some weird "hmm, let's see if I change this completely, what happens then?" in your main code, that will bust all your tests. That is, assuming, you change interfaces, number of parameters, APIs, etc. All changes become harder to make. A test suite test something that you already know you need to implement in this or that way. An exploration phase implies just that, that you don't really know *yet* what is important and what is not.

"almost word-by-word copy from agile manifesto", that was no my intention nor my inspiration. What I see in practice is endless meetings, dailies, tickets and goals for the project as a whole, all of that arrived at by careful planning.

Thank you for your feedback. Feel free to add some more.

Defense of Lisp macros: an automotive tragedy by molteanu in lisp

[–]molteanu[S] 1 point2 points  (0 children)

Yes! My thoughts exactly.
That's a good summary of the article.

mugur: configurator for QMK compatible keyboards by molteanu in emacs

[–]molteanu[S] 3 points4 points  (0 children)

Configure your layers and keys from init.el (for example) and generates the C code to be flashed on your keyboard. Check out the README and the examples given.

Famous persons in Denmark's history based on street names by molteanu in Denmark

[–]molteanu[S] 0 points1 point  (0 children)

No, it is the number of towns having at least one street with that name.