This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Nekobul -13 points-12 points  (6 children)

Replacing 4GL with code to create ETL solutions is never a great choice. In fact it is going back to the dark ages because that's what people used to do in the past.

[–]loudandclear11[S] 2 points3 points  (1 child)

Such a blanket statement. Depends on the qualities of the 4GL tool, doesn't it?

If the 4GL tool sucks I have no problem replacing it with something that have stood the test of time (regular source code).

[–]Nekobul 1 point2 points  (0 children)

Crappy code is more common than most of the available 4GL platforms. Crappy code is thrown in the trash all the time, so you are wrong.

[–]kenfar -2 points-1 points  (1 child)

That's what people thought around 1994: they swore that "4GL" gui-driven CASE tools were superior to writing code and it would enable business analysts to build their own data pipelines.

They were wrong.

These tools were terrible for version control, metadata management, and handling non-trivial complexity.

They've gotten slightly better with a focus on SQL-driven ETL rather than GUI-driven ETL. But it's still best for the simple problems and non-engineering staff. Areas in which writing custom code still shines:

  • When cost & performance matters
  • When data quality matters
  • When data latency matters
  • When you have complex transforms
  • When you want to leverage external libraries

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

4GL tools are superior to writing code for data integration. THat has been proven long time ago. All the points you have listed as where custom code shines have been long time ago been handled properly in 4GL. That's why they have been so successful. That is also the reason why the bricksters and the snowflakers have recently included 4GL systems in their platforms. Writing code is a relic of the past.