Author Topic: Discussion: Cost of hiring an AutoLISP developer compared to a .NET developer  (Read 2468 times)

0 Members and 1 Guest are viewing this topic.

Rustabout

  • Newt
  • Posts: 135
I'm not sure if this is in the correct forum or even allowed (apologies if that's the case, I'll take no offense if this post is moved or deleted; these discussions can sometimes turn into a bit of a mine field  :2funny: ).

I know that at least a couple AutoLISP programmer's for hire hang around these forums. I'm currently learning .NET (C#) and really enjoy it. I can however already see that the cost to create and maintain any programs is much higher than AutoLISP. Programming for myself is more of a hobby. I'm actually learning C# because I didn't want to be confined to just CAD with my programming skills. I can create console programs useful to myself and nobody else, but not much beyond that.

Exposure to both languages has taught me that the cost benefit swings in AutoLISP's favor for simpler programs. For more complicated stuff it swings towards .NET's favor. I'm also making the assumption that the .NET API is more extensive than AutoLISP's.

Not too many people are learning AutoLISP, and there seems to only be a select few 'gurus' out there. C#/.NET would draw from a much larger pool of programmers and in theory this would create more competition. In other words it's really hard to say if an AutoLISP developer would/could undercut a .NET developer.

What are your thought's/opinions?

BIGAL

  • Swamp Rat
  • Posts: 1396
  • 40 + years of using Autocad
It all depends on the requirement, it could be as cheap as a couple of hundred maybe running into a couple of thousand for development.

I sold civil design software back in the early 90's $9500 a copy you an buy the same now for like $3000 + $CAD eg Bricscad. The user base is big enough through support fees to pay for programmers. Yes its .net based.

Its a tough business if your looking at it as a career opportunity, unless you get into a big company with like a 100 licenses its hard to make lots of money irrespective of lisp or .net.

Compiling lisp is the way to go.

As a guide a 3d house suite has like 130 lisp programs. Took 2 years to develop, its still getting stuff added.

Just look at how much stuff is out there either free or like $25.

Re .net v's lisp can generally find a VL answer to a problem.
A man who never made a mistake never made anything

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8659
  • AKA Daniel
Should be the same right?

You need a routine to do a specific task, it shouldn’t really matter what language is used as long as the requirements are met.
The reason a developer might use .NET over AutoLisp is because .NET has deeper access to CAD’s API or has some special GUI requirement.
There are reasons to use native ARX/C++ as well. I.e.  Custom objects, An even deeper level of access to the API, or the need for top performance. etc.

I jump between all of them, depending on the task, I would charge the same hourly rate regardless  :laugh:


MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
What Daniel said is spot on. Regardless of language your rates should be the same, half the battle with any programming is knowing the API and experience.
This relates to another point you mention, while there is certainly a lot of C#/.Net dev's out there, not many know the CAD API so really the pool of Lisp developers and resources like sample source code is much larger. The C# API is a lot different then AutoLisp so it will take you a fair while to get comfortable banging out quick code. You can't beat Lisp for that, especially if you have some experience.
Use Lisp for quick fix code and short routines etc, use C# for more enterprisey type app's where there's a lot of dialogs and external data services etc that combine to make an 'full' application. You can can call Lisp-> C# and C#->Lisp so use both if it makes sense :)
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

d2010

  • Bull Frog
  • Posts: 323
What Daniel said is spot on. Regardless of language your rates should be the same, half the battle with any programming is knowing the API and experience.
This relates to another point you mention, while there is certainly a lot of C#/.Net dev's out there, not many know the CAD API so really the pool of Lisp developers and resources like sample source code is much larger. The C# API is a lot different then AutoLisp so it will take you a fair while to get comfortable banging out quick code. You can't beat Lisp for that, especially if you have some experience.
Use Lisp for quick fix code and short routines etc, use C# for more enterprisey type app's where there's a lot of dialogs and external data services etc that combine to make an 'full' application. You can can call Lisp-> C# and C#->Lisp so use both if it makes sense :)

The main problem, you share the VLISP 'program full-source-identically 100%
 with the source.lsp-think-inside-mind-of-developer.CAD.
That reason the business employers,  pay you as developor much less  per hour$ (from 20$/hour ) down to  pay you,(to 5-7$ per hour) !!!
 :2funny:

Code: [Select]
E.g. business employer=ProgeCAD Team
None companies in world-wide-web,  do not buy the
inside.lsp-of-the-developer's mind-of-CAD,
they, at means the bussines companies buy only the results-packed-zip,
or buy the programLISP hiring you as developer,
 after 10hoursX5$-perhours-as-LISP-developer.
--------
Nici o firma IT(e.g Amazon, AutoDesk.Store, ....) nu finanteaza banii$ in
 interiorul mintii tale ca programator.lsp, ci doar rezultatele tale dupa 10ore ca programator VLISP.?
 

« Last Edit: March 17, 2022, 11:11:27 AM by d2010 »

Rustabout

  • Newt
  • Posts: 135
Thanks for all the quality replies!

I'm currently exploring C#'s string manipulation functions. Being a more modern language definitely has it's advantages. I've done well manipulating strings in AutoLISP (well usually... had some battles too...) but in C# I can do a lot more with a lot less code.
The potential with WinForms and WPF seems quite high as well, but comes with a very steep learning curve (at least for me).
I'm also finding that you can't just start writing code like with AutoLISP. You actually have to organize your code properly (learnt that lesson the hard way after moving a file in VS), learn about the different Framework versions - which to use and when, and in general, understand at least the fundamentals of software architecture. With AutoLISP I had next to no clue what I was doing when I started but somehow still got very useful routines working :2funny:

Quote
I jump between all of them, depending on the task, I would charge the same hourly rate regardless

That surprises me as there aren't too many C++ developers out there. But I guess if someone wants that sort of development you'll also be justified in logging far more hours compared to the more managed API's. Sometimes I day-dream about learning C++ but C# is proving to be more than challenging enough.

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8659
  • AKA Daniel
Thanks for all the quality replies!

I'm currently exploring C#'s string manipulation functions. Being a more modern language definitely has it's advantages. I've done well manipulating strings in AutoLISP (well usually... had some battles too...) but in C# I can do a lot more with a lot less code.
The potential with WinForms and WPF seems quite high as well, but comes with a very steep learning curve (at least for me).
I'm also finding that you can't just start writing code like with AutoLISP. You actually have to organize your code properly (learnt that lesson the hard way after moving a file in VS), learn about the different Framework versions - which to use and when, and in general, understand at least the fundamentals of software architecture. With AutoLISP I had next to no clue what I was doing when I started but somehow still got very useful routines working :2funny:

Quote
I jump between all of them, depending on the task, I would charge the same hourly rate regardless

That surprises me as there aren't too many C++ developers out there. But I guess if someone wants that sort of development you'll also be justified in logging far more hours compared to the more managed API's. Sometimes I day-dream about learning C++ but C# is proving to be more than challenging enough.

On drawback with using .NET is that Microsoft depreciated .NET framework for .NET Core, but Core isn’t available as a CAD API.
I’m sure smaller programs written today will port easily, however, I’m guessing by the time Core is available for CAD, migration is going to be pretty bumpy with large apps.

There’s migration issues too in C++, but so far they’ve been relatively painless

Autolisp will probably exist forever, unchanged lol.

Rustabout

  • Newt
  • Posts: 135
Quote
...however, I’m guessing by the time Core is available for CAD, migration is going to be pretty bumpy with large apps.

For that reason now might be the right time to start learning C#... by the time I can actually code something useful I'll avoid any and all of that (hopefully).

It might just be marketing but there are some great things on the horizon for .NET (Maui, etc...) and the Core/Framework nonsense will likely disappear in the future.

I think ACAD 2022 is ".NET Framework 4.8" but correct me if I'm wrong. But ya a little behind the latest and greatest.

Atook

  • Swamp Rat
  • Posts: 1027
  • AKA Tim
On drawback with using .NET is that Microsoft depreciated .NET framework for .NET Core, but Core isn’t available as a CAD API.
I’m sure smaller programs written today will port easily, however, I’m guessing by the time Core is available for CAD, migration is going to be pretty bumpy with large apps...

Daniel, I'm curious on your thoughts regarding migrating to Core in the future. I'm maintaining a C# app now; are there code habits I should get into to make migrating to Core more seamless? I think it'll be a while, but if moving to Core meant my .NET app would run in Mac/Linux, I'd welcome the switch tomorrow. :)

d2010

  • Bull Frog
  • Posts: 323
The problem must exist differences between the (source/s  a* b*..) of same
program. That mode , you can keep



« Last Edit: March 21, 2022, 01:15:25 AM by d2010 »

MickD

  • King Gator
  • Posts: 3619
  • (x-in)->[process]->(y-out) ... simples!
On drawback with using .NET is that Microsoft depreciated .NET framework for .NET Core, but Core isn’t available as a CAD API.
I’m sure smaller programs written today will port easily, however, I’m guessing by the time Core is available for CAD, migration is going to be pretty bumpy with large apps...

Daniel, I'm curious on your thoughts regarding migrating to Core in the future. I'm maintaining a C# app now; are there code habits I should get into to make migrating to Core more seamless? I think it'll be a while, but if moving to Core meant my .NET app would run in Mac/Linux, I'd welcome the switch tomorrow. :)

Not Daniel but I can shed a bit of light here.
.Net Core is all about portability between OS's, what this means is MS are pulling out all the Windows specific stuff like WinForms etc out into other/new API's. They're also working on new GUI libraries that are very similar to Xaml et al that are also cross platform. I use ASP.Net Core with EF Core etc for a web app running on a Linux server and developed on my Windows box and all works well.
So, going forward you will be porting GUI code to new API's mostly and Windows based stuff shouldn't be too bad for the most part, just ref' in the new library and fix up a few namespaces etc and all good. Having your code organised into its 'separate concerns' like GUI and business logic will be a good head start :)
"Short cuts make long delays,' argued Pippin.”
J.R.R. Tolkien

d2010

  • Bull Frog
  • Posts: 323
Both , even VLISP and even C# ,
other problem is the price of kitt?
If the price is too low, then how high is the price of developer-Lisp!!!
The AutodeskTeam, must work on eMarket.
 :rolleyes2: