OT: on IDEs and code writing on steroids

[BCS]

Hello Yigal,

> BCS wrote:
> 
>> Reply to Yigal,
>> 
>>> BCS wrote:
>>> 
>>>> Hello Yigal,
>>>> 
>>>>> C# assemblies are analogous to C/C++/D libs.
>>>>> you can't create a standalone executable in D just by parsing the
>>>>> D
>>>>> source files (for all the imports) if you need to link in external
>>>>> libs.
>>>>> you need to at least specify the lib name if it's on the linker's
>>>>> search path or provide the full path otherwise.
>>>> pagma(lib, ...); //?
>>>> 
>>> that's a compiler directive. nothing prevents a C# compiler to
>>> implement this. In general though this is a bad idea. why would you
>>> want to embed such outside data inside your code?
>>> 
>> Because it's needed to build the code
>> 
>>> info needed for building your task should not be part of the code.
>>> 
>> IMO it should. Ideally it should be available in the code in a form
>> tools can read. At a minimum, it should be in the comment header. The
>> only other choice is placing it outside your code and we have already
>> covered why I think that is a bad idea.
>> 
>>> what if I want to rename the lib,
>>> 
>> So you rename the lib and whatever references to it (inside the code
>> or outside) end up needing to be update. Regardless, you will need to
>> update something by hand or have a tool do it for you. I see nothing
>> harder about updateing it in the code than outside the code.
>> 
>>> do I have to recompile everything?
>>> 
>> Nope. pragma(lib, ...) just passes a static lib to the linker and
>> doesn't have any effect at runtime. (if you are dealing with .dll/.so
>> libraries then you link in a export .lib with a pragma or load them
>> manually and don't even worry about it at all)
>> 
>>> what if I don't have the source?
>>> 
>> It's pointing at a static library so source doesn't matter. If you
>> are working from source then you don't need the pragma and what
>> matters is DMD's import path (if it is an unrelated code tree in
>> which cases the path can be developer specific and needs to be set up
>> per system).
>> 
>>> what if I want to change the version?
>>> 
>> In that case you change the pragma. (again assuming static libs and
>> the same side note for dynamic libs)
>> 
>>> what if I want to switch a vendor for this lib?
>>> 
>> I have never heard of this being possible without major changes in
>> the calling code so it don't matter.
>> 
> What I was trying to say is that you're hardcoding the lib name and
> version inside the code. I see two problems with this: if the pragma
> is
> in my code than I need to re-compile my code if I want to edit the
> pragma (rename lib, change version, change vendor, etc...)
> if the pragma is in some 3rd party component which I don't have the
> source for than I can't change the pragma.
> either way, it conflicts with my work-flow and goals.
> I do not wish to recompile a 1.5GB standalone executable if I just
> changed a minor version of a lib.

I see you point but I think it is invalid.

For starters, I could be wrong but I think that the use of pragma(lib,) can't 
be detected in object code, I think It just instructs DMD to pass the lib 
on to the linker when it gets called by DMD. If I am wrong about that I still 
think it doesn't matter because (as far as static libraries go) I think it 
would a very BAD idea to try and switch them out from under a closed source 
lib. Third, if you really want to go mucking around with those internals, 
you can always copy the new lib over the old one.

> 
> IIRC, the math lib in C/C++ comes in three flavors so you can choose
> your trade-off (speed or accuracy) and the only thing you need to do
> is just link the flavor you want in your executable.

Everything needs a math lib so there will be a default. I'd not willing to 
second guess the original programmer if they choose to switch to another 
lib. The same goes for other libs as well. If you start switching to libs 
that the lib's programmer doesn't explicitly support, your already on your 
own and you have bigger problems than what I'm talking about.

> you seem keen on combining the build process with compilation which is
> in my experience a very bad thing. it may simplify your life for your
> small projects but as I was telling you before it's a pain in the neck
> for the scale of projects I work on. I don't get why you refuse to see
> that. what you suggest is _not_ a good solution for me.

What I want is a language where most of the time you build a project from 
only the information in the source code. What I don't want is a language 
where the only way to keep track of the information you need to build a project, 
is with an external data file. I don't want that because the only practical 
way to do that is _force_ the programmer to use an IDE and have it maintain 
that file.