molteanu

> I don't see code generation as a bad smell at all.

Well, exactly!

> At my job we use the JooQ code generator...

And in Lisp one would use the...Lisp code generator. That is, the macro. And the beauty of it is that it doesn't work with pure strings but 'understands', parses, manipulates the code as expressions in its own language. That is, it has at its disposal the entire language for manipulating those expressions.

And I think that is one of the "aha" moments. At least, it was for me. When you realize the reason for having those code generators, regardless of the project and language, in the first place. That is, something missing from the language. Some extra feature that can't be implemented. Some solution that works really close to 99%, but not beyond. Something that one would like to express, but can't. Some piece of code that you want to be parameterized like you would a function, some piece of code that you want to use in multiple places but you don't want to write the same boilerplate or copy/paste it all over the place with the risk that when you modify something, you'll need to modify in all those places. Or some piece of code that you want to be auto-generated when you build/deploy/etc.

The examples are countless. The world of meta-programming offers enough of them. The article gives the control statements as an example, as a hint to build the appetite, as is suggested in the intro, in fact.

I find it is a real challenge to come up with a good title. On the one hand it should, probably, convey to the potential reader something about the contents of the article, on the other hand it should be something to differentiate it from the rest of the articles published on the same subject.

I like those that read something like a punch-line, that come across as something different that just a summary of the article. But these maybe work best for literature, prose, movies, etc.

The solution, which I often seen in practice, is to eventually write code generators, which is what Lisp macros are, after all. I've seen it in C and wrote a big piece about it that was posted here some time ago[1], about the extra tools, code generators, special formats and standards employed and needed to make up for C's deficiencies (in respect to meta-programming, at least).

Everywhere I see code generators it means a feature is lacking in the main language used for the project. Then you bring in other tools to make up for that deficiency. Only, usually, we don't call that deficiency, since we are used to things being that way. It is called day-to-day business. I think that's what I've tried to convey in the article.

[1] https://news.ycombinator.com/item?id=41066544

If we would really have a chance to ask an official, whomever that may be, either from government or the tech companies, the (scripted) answer would probably go like this:

By 2030, AI will make revolutionary advancements in water management which will reduce our total water consumption, reduce waste, improve the wastewater treatment efficiency by 15x, so that, overall, the industry is not consuming but producing water.

Had I decided to call it quits, I would have probably asked myself, even to this day, questions like: did I make the right choice, what if things would have improved, what would have happened if I've tried harder, maybe there was just a misunderstanding, maybe it was my fault, maybe working at the University would have been the smart choice, etc.

I actually still have the emails asking for the project coordinator, the one responsible for scholarships for all of us (I've searched them out, out of curiosity while writing this article and their CV is 12 pages long and, naturally, this project is listed there as a success) for ways to abandon the whole thing. I didn't even get a reply. I was already 2 years in so I've would have had to return the whole sum back, money I didn't have. I was penniless, as all PhD candidate seem to be. So I did what I had and could do, which is summarized in the post.

Please share, if you feel inclined to.

I don't wanna name and blame the country, and I didn't do it in the article as I don't think it matters that much, but the other replies are correct in their assumption, is all I can say.

Yes, fifteen years after the fact, during which time my mind constantly bombards me with, "Why did I happen? Did I do something wrong? It was not fair! I did my best!" and such, I can't help it but write in in a humorous manner, otherwise it's hard to put it behind you and forget about it.

On the second point, yes the total number of PhD graduates for a similar time period was 12.000 (official Government numbers) so this was a doubling of PhD's just like that, out of the blue. No wonder it was chaotic. There was also enormous political pressure regarding "the Government is incompetent as it cannot absorb what is basically free EU money". So, ok, they've absorbed it, sort of.

I think you are right. Reading the online articles and official documentation from that period, which is really scarce (there is no such program available on the EU official website, for example, or I wasn't able to find it), it feels like this was a big experiment, the success of which is not mentioned in the news either.

What I could find is that it was part of the Lisbon Strategy [1], also mentioned in the official documents published by the Government. From the linked wikipedia article: "Its aim was to make the EU the most competitive and dynamic knowledge-based economy in the world capable of sustainable economic growth with more and better jobs and greater social cohesion, by 2010. It was set out by the European Council in Lisbon in March 2000. By 2010, most of its goals were not achieved. It was succeeded by the Europe 2020 strategy."

[1] https://en.wikipedia.org/wiki/Lisbon_Strategy

I agree with the other comment. Ignore them all, go with the fundamentals. Heck, ask chatgpt what do they think are the fundamental ideas in computer science and go from there. Look for classic books written on those subjects. There have been plenty of smart people around the sw field who took years of their lives to write succint and valuable technical books! Use them! Ignore the poison-mixers who probably didn't write a single line of code in their whole life!

Go for a decent text editor, learn how to type! It's incredible how we use ai tools to write code for us but some don't know how to actually write themselves! Again, look it up, there are plenty of resources out there. If in doubt, search for said resources here on hn. If still in doubt, ask chatgpt what does the hn community recommend for x or y.

Well, if the Chinese can do it, probably the Americans can do it, too. Nice!

It would probably be fair or "normal" if for every pro-article, regardles of the subject, there would be room for the contrary opinion, for the downsides. That would inject some dose of realism into the discussion.

Otherwise the journalism, in general, is not in such a great shape if it can only regurgitate the same thing over and over, the same words from the same mouths.

Just an idea. I donno.

I have another idea! It's just an idea or a feeling.

My feeling is that work interaction has decreased lately, with all these assistants. I, for one, don't get any questions and don't have any technical interactions not even with junior developers. I don't get asked "how can I implement this, give me some clues" or "do you know a book or some articles I can read on this or that subject?"

I feel the slack channels have also kinda dried up. There's the occasional meme or dog pictures but very little technical discussion, asking for an opinion, framing one's ideas and thoughts on a subject in writing, exchanging opinions with others, etc.

There is still the occasional code review, sure. At this point, I can spot the code written with AI. It has the same feel, the same verbosity, always the same try/catch for everything, always awaits everything, same doxygen-style of comments, always assigning variables for everything. I gave my opinions in the beginning, some things were adapted. But it's a loosing battle. AI can write code faster than I can review it.

Three years ago, some colleagues would ask on slack to proofread their client-facing documents. Now they don't.

Tldr: human interaction is decreasing due to people not needing help from other people that often, similarly to ordering your food and not knocking on your neighbors door to ask for a slice of bread since you've ran out of and everything is closed (we did that, and the neighbors too, 30 years ago)

Don't let hacker news become habituated with politics.

For a similar set of ideas, see "A high-velocity style of software development".

https://news.ycombinator.com/item?id=42414911

Late reply, but I've found I reason why one might need to stop using Emacs,

https://www.reddit.com/r/emacs/comments/1glqfa3/my_company_d...

Yes, I do this kind of thing in JavaScript, too. I actually forgot it is a feature. Not all JS projects I work on take advantage of it in this way.

"conversationally irrelevant things" - nice way of putting it. Important things, because they are there, the project is built on them but they are actually just details from a requirements or project-feature-wise point of view. Nicely said!

One way to look at it is that, if I rely on a debugger and the style of development it promotes I will not try to make those reload times shorter for my project and that will result in a different style of developing software, tool-wise.

One thing I saw happen in C development is, because the projects were so big and a reload after a code edit would also require a re-initialization phase to bring you back to that point in the code you were before you made the change, is that at one point you introduce the scripting language the debugger offers. Small files, at first, to set-up global state, to call the right functions, etc, since the project was meant to be debugged as a whole and not worked on in individual buildable and runnable code files. Like the classic maths library, for example, extracted into a different file and developed individually, without taking into account the rest of the project. That speeds up the development velocity, for example. And you can test it against locally available sets of data, like lists, matrices and what have you.

Yes, I've used the Common Lisp debugger. But I also use JavaScript to pay the bills, so to speak. I've wrestled for months on end with the nodejs debugger and its integration with Emacs. Lost connections, wrong configs, random errors, etc.

I still think the debugger is an extra tool, like a code editor is an extra tool, the finished product doesn't have any trace of what code editor you've used in the process. So if you can make your life easier without one, why not, there is no absolute requirement that you should use a debugger, for our example.

Anyway, that is my reasoning. It might be wrong, it might be right, but it's taken from actual practice. Some people might have different experiences and that is fine, too.

It is shorter than what I've had initially, really. And yes, these are a bunch of ideas I try to make clearer for myself, as well. Like, there is a feeling inside and you've seen things and experienced different scenarios and now you try to put them into actual words that makes sense, as a whole. If you are successful at that, that's another story. Add to that that other people's experience are different and they come from different backgrounds, things get even messier. I think there was a piece from antirez a few days ago where he was being surprised, among others, on how much harder writing is, in general, than coding. I feel the challenge of that sometimes.

That being said, I appreciate your answer and insight.

Edit: why did you stop writing, if I may ask you? (I'm assuming now that not publishing for the whole world to see equals not writing at all, which might not be the case)

Yes, `2-3 other people can work on it with you` would be splendid. But then you have to be on the same page with your colleagues on how to go on about doing things. You know how that goes, when good ideas are then made mandatory and all the team must follow suit. Then the original motivation is kinda lost in the background and then part of the team only does the moves because "someone told me to".

If you say, yes, `2-3 other people...`, let's get together and do this thing, approval or no approval, then we might be getting somewhere.

As an extreme example, if I'm using Emacs, and assume it offers some advantage in the project development velocity department (ignoring any reasons as to why, for the sake of the argument) but cannot convince the other team-members to use it, should I stop using it?

No, I'd like you to read the whole of it. Or, at least, every author lies to themselves that they have the most devoted of readers.

But yes, you are right with your summary. It is based on an observation that some of the solutions I've seen developed are developed inside our own heads only. Or are written down in documents or slack channels or meetings where we talk, we agree on things but they are not enforced anywhere. Or where we dream "what if's" scenarios, put all those side by side and vote, based on our power of imagining the outcome, and decide what to next implement and spend our time with.

And part of the problem, and I say part as I don't have access to everyone's environment to see how they work at their computer now that we work from home, but part of that is a real fear of the computer (or lack of mastery, I donno), thus the bits about changing code often, some ideas on how to achieve that and make the environment you're using to write code, explore the project and your ideas your own, regardless of how it looks from the outside.

As an extreme example, one client was sending us both the authentication library as .c and .h files to be compiled on our side and an add-on to be installed on a tool we were already using. When there was a new version of the .c and .h files, which always happened as this authentication feature was under active development, the add-on changed too. There were instructions as PDF files on how to install this add-on, which were slightly different every time. When the project started up, before one could send any commands to it, the authentication procedure had to be successfull.

My thinking was that, since I don't work on that part of the system and the features that I'm responsible for only work after the authentication was successful anyway, I can identify the part of the code that does the authorization and hard-code an authorization successful implementation, which was simply returning <q>true</q> from the correct function. I would thus reduce the number of steps needed to reload the system after a code change and thus reduce the reload time. In short, I would just assume the authorization worked and concentrated only on my stuff. I didn't commit this code, of course. But to my surprise, even though I've presented this to colleagues and even PM, the reply was that well, we sorta have to work with the whole system and make sure the whole system works. And yes, we did that, only on our daily activities we didn't have a reason to test the authentication part every single time, dozens of times per day since we didn't change it, we worked on the part of the code that comes after authentication. But no luck. So a lot of time was spent and is spent with these steps.

I say "an extreme example" as automotive software seems to e to be a special example. I wrote about it on another post on my blog. It got pretty long and uncovered all the messiness. But that's another topic.

Well, yes! I'm trying my best to make your wish come true by spreading the word.

Good to know I'm not the only one finding it a bit too complicated and sad. Do share your experience with it, if you will.

> as you can see by the lack of comments addressing any specific part of the article

Yes, rightly so! I would have been more than glad to address and discuss any of the points made or tools mentioned in the article but that happiness has been stolen from me by the lack of such comments. You're right.

> I think the article was pretty convincing. Even painfully so as it went through the atrocities people are doing in this particular industry to achieve things that, you're completely right, would be trivial in Lisp.

Yes, some of these tools I've mentioned I've also worked with for years. It has been a few years since I've exited from that industry and now I've tried to bring back the feelings and remember the tools and standards so I've had to do some research. It slowly came back. But I did discover some new tools and languages that I haven't used so the horror was even greater than what I've remembered and then I couldn't stop digging for more. Good observation.

I am writing for myself. I've also worked in the automotive industry as a consultant for a few years and I've seen the effects of these extra tools I'm mentioning in the article on me and my colleagues and the industry as a whole. I've gathered all the observations in one place. It has been a nice experience for me writing it, it has cleared up some ideas, brought to life new ones, as it always happens when you think you see something very clearly only to change your opinion and see new angles once you put it in words or once you try to articulate it.

I am glad if it's useful to others as what others write and wrote over the years, including about Lisp, was useful to me. It's just free food, if you will. They've charged nothing for it, even if they worked for years on producing it, I'm grateful for that and now I'm returning the favor. If it's good food or not, I can't say. If you don't like it, leave it to others, no harm in that.

No, it just means you can't avoid the reality and the complexity of the problems you'll be dealing with and you won't be able to tackle them unless you bring in more tools or programming languages, be them visual or special languages invented just for the purpose, or some clever way to use excel sheets and generate code from that, for example.

Or it means that, yes, you can choose the easier language, the more intuitive one instead of the abstract beasts and it all goes well for a while. But eventually you'll have to go past the "they did this and then they did that", past the simple to understand if's and else's of everyday life. Then you'll realize that yes, we need this special extra feature here, this clever way of doing things there and before you know it, you've developed dozens of tools, standards and languages just to make up for the lack of power of your initial language. Or you could have chosen the harder language, harder to learn and wield, that is, and it would have offered you better abstractions, it would have offered you better means to develop your ideas and put them into practice without you needing to invent your own tooling.

That's how I've seen it happen in practice. I've expanded it in this article, but it came the other way round. I had a feeling that all this tooling is actually unnecessary or just the result of having bad tooling to start with. Once I've developed these ideas I've remembered about Greenspun's Tenth Rule that I've read and heard about all these years without quite understanding it 100%. Now I think I do. You have to see it with your own eyes, though. If you read it once and it doesn't make sense, re-reading it probably wouldn't.

I hope this helps.

I've linked this thread from HN in the article about visual programming, if you find it useful or insightful,

https://news.ycombinator.com/item?id=14484244

Well, software developers in the embedded field of automotive use Matlab and Simulink quite extensively. I haven't worked with it myself but the "excuse" for using it was that "we have complicated state machines that would be difficult to write directly in C".

Just to add another angle to this: of course you can have CS classes and all that good stuff, but would the businesses only employ these kind of graduates? Or would they spread even thinner to grab market share or increase profits and hire non-experts as a result, for which "easy" and intuitive tools have to be developed and employed? I mean, I see this problem with abstraction, maths, compilers, Lisp, etc, you know, the fundamental stuff. That is, the deeper you go it will become that much harder to find people willing or able to dive deep. So eventually you run out of manpower and that what? Use these "intuitive" tools, probably.

That would only mean we'd add even more tools on top of the tools that currently sit themselves on top of C (in this particular case) to fix our 'sloppy' ways, no?

I would take it as just marketing. One has something to sell so one now finds some good angle of why that product is better or desirable.